why-using-existing-matters - Revision history

Btrem: Removes self-reference.

2022-12-05T20:28:17Z

Removes self-reference.

← Older revision		Revision as of 20:28, 5 December 2022
Line 12:		Line 12:

	* Add <em>existing</em> microformats to your sites like [[hcard\|hCard]] for your contact info etc., [[hcalendar\|hCalendar]] for your events, [[hatom\|hAtom]] for your episodic content (e.g. blogs). See [[get-started]] for more specific examples of adding microformats to your sites.		* Add <em>existing</em> microformats to your sites like [[hcard\|hCard]] for your contact info etc., [[hcalendar\|hCalendar]] for your events, [[hatom\|hAtom]] for your episodic content (e.g. blogs). See [[get-started]] for more specific examples of adding microformats to your sites.
	* This will help familiarize you with how [[POSH]] and [[microformats]] currently work. Such "real world" experience will greatly help you with the development a new microformat~~. For more on this see [[why-using-existing-matters]]~~.		* This will help familiarize you with how [[POSH]] and [[microformats]] currently work. Such "real world" experience will greatly help you with the development a new microformat.

Chris Messina: formatting touch ups

2007-11-24T07:27:47Z

formatting touch ups

← Older revision		Revision as of 07:27, 24 November 2007
Line 11:		Line 11:
	Thus the process page encourages the reader to:		Thus the process page encourages the reader to:

	Add <em>existing</em> microformats to your sites like [[hcard\|hCard]] for your contact info etc., [[hcalendar\|hCalendar]] for your events, [[hatom\|hAtom]] for your episodic content (e.g. blogs). See [[get-started]] for more specific examples of adding microformats to your sites.		* Add <em>existing</em> microformats to your sites like [[hcard\|hCard]] for your contact info etc., [[hcalendar\|hCalendar]] for your events, [[hatom\|hAtom]] for your episodic content (e.g. blogs). See [[get-started]] for more specific examples of adding microformats to your sites.
			* This will help familiarize you with how [[POSH]] and [[microformats]] currently work. Such "real world" experience will greatly help you with the development a new microformat. For more on this see [[why-using-existing-matters]].
	This will help familiarize you with how [[POSH]] and [[microformats]] currently work. Such "real world" experience will greatly help you with the development a new microformat. For more on this see [[why-using-existing-matters]].


	Success in developing microformats requires both creation but more importantly adoption; any effort to create new schema depends upon your prior support for and implementation of existing formats.		Success in developing microformats requires both creation but more importantly adoption; any effort to create new schema depends upon your prior support for and implementation of existing formats.

	One rhetorical question to consider about using existing microformats vs. creating a new one.		One rhetorical question to consider about using existing microformats vs. creating a new one: ''How can you have a chance of convincing others to use a ''new'' microformat (that you would develop) on their sites, if you can't convince yourself to use ''existing'' microformats on your sites?''

	How can you have a chance of convincing others to use a ''new'' microformat (that you would develop) on their sites, if you can't convince yourself to use ''existing'' microformats on your sites?

	~~Or put in a more positive sense:~~

	If you adopt microformats and develop your own with the microformats process, you have a greater chance of being successful, whereas, if you develop your own format without implementing prior formats, you are more likely to fail.		Or put in a more positive light: ''If you adopt microformats and develop your own with the microformats process, you have a greater chance of being successful, whereas, if you develop your own format without implementing prior formats, you are more likely to fail.''

	Failures may even take strange forms that are hard to recognize until it is too late. I.e. if you don't first familiarize yourself with existing microformats (most of all, by using them in actual production sites), you're likely to make lots of mistakes while developing your own format. It's likely to take a lot longer for you to develop your microformat. It's likely your microformat will be needlessly complicated. And because you won't be familiar with both whole existing microformats and their vocabularies, you will more than likely re-invent chunks of microformats and terms, rather than re-use from existing microformats.		Failures may even take strange forms that are hard to recognize until it is too late. I.e. if you don't first familiarize yourself with existing microformats (most of all, by using them in actual production sites), you're likely to make lots of mistakes while developing your own format. It's likely to take a lot longer for you to develop your microformat. It's likely your microformat will be needlessly complicated. And because you won't be familiar with both whole existing microformats and their vocabularies, you will more than likely re-invent chunks of microformats and terms, rather than re-use from existing microformats.

Tantek: added see also

2007-11-24T07:17:21Z

added see also

← Older revision		Revision as of 07:17, 24 November 2007
Line 27:		Line 27:

	Failures may even take strange forms that are hard to recognize until it is too late. I.e. if you don't first familiarize yourself with existing microformats (most of all, by using them in actual production sites), you're likely to make lots of mistakes while developing your own format. It's likely to take a lot longer for you to develop your microformat. It's likely your microformat will be needlessly complicated. And because you won't be familiar with both whole existing microformats and their vocabularies, you will more than likely re-invent chunks of microformats and terms, rather than re-use from existing microformats.		Failures may even take strange forms that are hard to recognize until it is too late. I.e. if you don't first familiarize yourself with existing microformats (most of all, by using them in actual production sites), you're likely to make lots of mistakes while developing your own format. It's likely to take a lot longer for you to develop your microformat. It's likely your microformat will be needlessly complicated. And because you won't be familiar with both whole existing microformats and their vocabularies, you will more than likely re-invent chunks of microformats and terms, rather than re-use from existing microformats.

			== see also ==
			* [[get-started]]
			* [[why-are-content-standards-hard]]
			* [[principles]]
			* [[process]]

Tantek: drafted to expand upon a key point from process

2007-11-24T07:16:43Z

drafted to expand upon a key point from process

New page

<h1>Why using existing microformats matters</h1>

When many folks first hear of [[microformats]], they are quite inspired by the possibilities and potential that microformats present.

Nearly everyone seems to have a problem in the back of their minds, or specific to their application, site, or service which could benefit from a microformat to represent the information.

Thus immediately there is a desire to jump to creating a new such microformat, perhaps seduced by the ease of use of existing microformats. It's easy to misconclude from the simplicity of existing microformats that it is also simple to create microformats. Ironically, the opposite is true. As with many things, it's actually quite challenging and difficult to make simple, easy to use things. This is a known axiom in [[user-interface]] design circles. It's no different with formats. See [[why-are-content-standards-hard]] for some general thoughts on why good and simple formats are actually quite difficult to create.

The motivation to create a new microformat might lead some here, to the microformats [[Main_Page|wiki]] or perhaps even the [[process]] page before proceeding.

Thus the process page encourages the reader to:

Add <em>existing</em> microformats to your sites like [[hcard|hCard]] for your contact info etc., [[hcalendar|hCalendar]] for your events, [[hatom|hAtom]] for your episodic content (e.g. blogs). See [[get-started]] for more specific examples of adding microformats to your sites.

This will help familiarize you with how [[POSH]] and [[microformats]] currently work. Such "real world" experience will greatly help you with the development a new microformat. For more on this see [[why-using-existing-matters]].

Success in developing microformats requires both creation but more importantly adoption; any effort to create new schema depends upon your prior support for and implementation of existing formats.

One rhetorical question to consider about using existing microformats vs. creating a new one.

How can you have a chance of convincing others to use a ''new'' microformat (that you would develop) on their sites, if you can't convince yourself to use ''existing'' microformats on your sites?

Or put in a more positive sense:

If you adopt microformats and develop your own with the microformats process, you have a greater chance of being successful, whereas, if you develop your own format without implementing prior formats, you are more likely to fail.

Failures may even take strange forms that are hard to recognize until it is too late. I.e. if you don't first familiarize yourself with existing microformats (most of all, by using them in actual production sites), you're likely to make lots of mistakes while developing your own format. It's likely to take a lot longer for you to develop your microformat. It's likely your microformat will be needlessly complicated. And because you won't be familiar with both whole existing microformats and their vocabularies, you will more than likely re-invent chunks of microformats and terms, rather than re-use from existing microformats.