why-using-existing-matters: Difference between revisions
(drafted to expand upon a key point from process) |
(Removes self-reference.) |
||
(2 intermediate revisions by 2 users not shown) | |||
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. | |||
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 | |||
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?'' | ||
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. | |||
== see also == | |||
* [[get-started]] | |||
* [[why-are-content-standards-hard]] | |||
* [[principles]] | |||
* [[process]] |
Latest revision as of 20:28, 5 December 2022
Why using existing microformats matters
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 wiki or perhaps even the process page before proceeding.
Thus the process page encourages the reader to:
- Add existing microformats to your sites like hCard for your contact info etc., hCalendar for your events, 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.
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 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.