Re: [uf-discuss] hidden microformats
On 28/09/06, Paolo Negri [EMAIL PROTECTED] wrote: I won't provide partial uformats because I'm afraid of that the user can be confused by different versions of the data for the same event/person. I agree on that even a partial information is semantic, but since now the usage of uformats is more like a transformation/download of vcards/icalendar (and my application is likely to encourage this type of usage) than an highlighting of the semantic of the page, I just want to provide one version of these objects. I don't think you should really focus on what the *current* use of uformats is - let's face it, most web users aren't even aware of them right now. I don't think users are confused by different versions of data - for instance, on the home page of one site I've worked on, we have some succinct descriptions of events; when you click through the page, you have the fuller description. Both should be marked up as microformatted data, imho. However, it's only the full description that we submit to pingerati, for instance. But there are still reasons for putting the ufs onto the limited version, on the front-page - it provides a very simple scrapi to upcoming events, for instance. That said: if you've got multiple representations of the same data on the same page (which I don't think you do, but wanted to check), then it's probably confusing for a user from a visual/usability perspective, let alone a uf one. That's the design for humans first mantra... once that's sorted, it's not too hard to design for the machines second. Usage vs purpose is chicken-and-egg, and I don't think you should limit implementation based on current usage patterns. I don't think I'm going to add link to uformats because I like the idea to have them as a rich collateral presence of data on the page more than a sort of resource that need to be pointed. Obviously this is just my opinion and is related to this specific application perspective. No, that sounds about right to me! ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hidden microformats
On 28 Sep 2006, at 01:15, Paolo Negri wrote: On some pages I have all the infos about these items and I can produce very complete uformats. On other pages I render let's say just the name and the email of someone and it doesn't make sense to provide a less complete hcard than in a different page, and I absolutely can't add the extra information (address, role) as visible. Perhaps the better solution for this would be to revive (and perhaps conclude) the ‘linking to a definitive microformat’ idea which has popped up every so often. In short, provide a rel value to contain within an hCard or hEvent which links to the page with the full information. Parsers are then instructed to follow that link where appropriate to get complete information. That's still a work-in-progress though, so my advice for now is that as Ernie Prabhaker says, there's nothing wrong with having smaller, less complete hEvents, they're still valid microformats. For now, just make sure you're linking to the full page from them and if in the near future a suitable rel value is designed to parse those links, you can add it in with no destruction or reworking required in your application. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hidden microformats
On 28/9/2006, Ben Ward [EMAIL PROTECTED] wrote: Perhaps the better solution for this would be to revive (and perhaps conclude) the linking to a definitive microformat idea which has popped up every so often. In short, provide a rel value to contain within an hCard or hEvent which links to the page with the full information. Parsers are then instructed to follow that link where appropriate to get complete information. That rather depends on whether the objective is to publish discoverable information, or to make published information discoverable. My primary goal is always the latter, with the former a noble secondary objective. That's still a work-in-progress though, so my advice for now is that as Ernie Prabhaker says, there's nothing wrong with having smaller, less complete hEvents, they're still valid microformats. For now, just make sure you're linking to the full page from them and if in the near future a suitable rel value is designed to parse those links, you can add it in with no destruction or reworking required in your application. More than nothing wrong with - there's everything right with publishing smaller, less complete hEvents. If it's an event then it should be marked up as an event in the best way possible, regardless of the fact that more comprehensive information is available elsewhere. If I were to publish a list of some of Shakespere's plays, I'd still mark it up as a list even though Wikipedia has a more comprehensive list than mine. In the first instance we must be concerned with adding the correct semantics to the data we're publishing, not with how it may or may not be used. drew. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hidden microformats
Hi all Sorry for late reply I can just tell how I sorted out my stuff. For the tricky structure of the divs I've just reviewed with the smallest possibile set of change the structure of the page to have the content to build the uformat included in a div which is really semantic now. I wasted some hours doing this but now I can sleep at night. I decided to provide uformats just where the most complete infos are available. It makes sense for the user to expect complete infos where they actually are. My idea is uformats will probably be where you would look to take physical notes Now you'll say that I can't tell where the users would look, and this is a good point... I won't provide partial uformats because I'm afraid of that the user can be confused by different versions of the data for the same event/person. I agree on that even a partial information is semantic, but since now the usage of uformats is more like a transformation/download of vcards/icalendar (and my application is likely to encourage this type of usage) than an highlighting of the semantic of the page, I just want to provide one version of these objects. I'll be happy to change this approach when I'll see more clearly how uformats are going to be used and how the users will be helped by browsers/apps in using them. I'll just keep an eye to have a sort of uformats aware page design, just to be ready, even if I have to say, excluded 2 tricky cases adding microformats to my content was pretty natural. I don't think I'm going to add link to uformats because I like the idea to have them as a rich collateral presence of data on the page more than a sort of resource that need to be pointed. Obviously this is just my opinion and is related to this specific application perspective. Well, and in the end I have to thank you all for this really interesting discussion. Paolo On 28/09/06, Drew McLellan [EMAIL PROTECTED] wrote: On 28/9/2006, Ben Ward [EMAIL PROTECTED] wrote: Perhaps the better solution for this would be to revive (and perhaps conclude) the 'linking to a definitive microformat' idea which has popped up every so often. In short, provide a rel value to contain within an hCard or hEvent which links to the page with the full information. Parsers are then instructed to follow that link where appropriate to get complete information. That rather depends on whether the objective is to publish discoverable information, or to make published information discoverable. My primary goal is always the latter, with the former a noble secondary objective. That's still a work-in-progress though, so my advice for now is that as Ernie Prabhaker says, there's nothing wrong with having smaller, less complete hEvents, they're still valid microformats. For now, just make sure you're linking to the full page from them and if in the near future a suitable rel value is designed to parse those links, you can add it in with no destruction or reworking required in your application. More than nothing wrong with - there's everything right with publishing smaller, less complete hEvents. If it's an event then it should be marked up as an event in the best way possible, regardless of the fact that more comprehensive information is available elsewhere. If I were to publish a list of some of Shakespere's plays, I'd still mark it up as a list even though Wikipedia has a more comprehensive list than mine. In the first instance we must be concerned with adding the correct semantics to the data we're publishing, not with how it may or may not be used. drew. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hidden microformats
HI Paolo, In general hidden microformats are frowned upon, as they cause all sorts of problems. Could you give an example of the types of hidden information you want/need to provide? -- Ernie P. On Sep 27, 2006, at 2:56 PM, Paolo Negri wrote: Hi there This is my first post here, sorry if I'm not posting in the right place. I'm adding uformats support in my application and I have to say I'm quite intrigued but I'm facing with 3 problems 1) Sometime I have to change the code of my pages in places where I would prefer to have a more clean structure. 2) Sometime I would like to to the uformats on my pages information that I have in my application but that are not rendered in the current page, and adding/hiding these information in the original structure to complete the rendered information, make my page really dirty. 3) In some cases I would like to add a uformat containing informations that are not present at all on the page but that are deeply connected with the context of the page. Now, what I was thinking is to add in the footer of my pages a sort of container (let's say a div) with all the microformats that I want to provide to my end user. Basicly this div will be not visible because of style setting , it will be just available for parsing purpouse. What I'm wondering is if this approach makes any sense since microformats are more oriented to give semantic/parsability to the visible content. I was thinking as an alternative to provide the possibility to download directly the vcard or whatever, but I still would preferer microformats since they sounds for me a bit more discoverable than a link to the vcard or to the final object. One last question that I have is about the screen reader for impaired user. Is there already a standard/proposal to signal that a section of the page is dedicated to microformats, or maybe I should just use something to avoid the processing of the container by the screen reader. That's all, thank you for the attention. Paolo ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hidden microformats
Hi Ernie Thanks for replying The application I'm working on is rich in calendar items and people. On some pages I have all the infos about these items and I can produce very complete uformats. On other pages I render let's say just the name and the email of someone and it doesn't make sense to provide a less complete hcard than in a different page, and I absolutely can't add the extra information (address, role) as visible. Another problem is that there are a lot of data on the page and the bits to build the uformats are well spreaded on it so I have to put the main div or whatever at a very high level of the dom which is not really nice because it tends to group even some items that are not really in his context. Paolo On 27/09/06, Dr. Ernie Prabhakar [EMAIL PROTECTED] wrote: HI Paolo, In general hidden microformats are frowned upon, as they cause all sorts of problems. Could you give an example of the types of hidden information you want/need to provide? -- Ernie P. On Sep 27, 2006, at 2:56 PM, Paolo Negri wrote: Hi there This is my first post here, sorry if I'm not posting in the right place. I'm adding uformats support in my application and I have to say I'm quite intrigued but I'm facing with 3 problems 1) Sometime I have to change the code of my pages in places where I would prefer to have a more clean structure. 2) Sometime I would like to to the uformats on my pages information that I have in my application but that are not rendered in the current page, and adding/hiding these information in the original structure to complete the rendered information, make my page really dirty. 3) In some cases I would like to add a uformat containing informations that are not present at all on the page but that are deeply connected with the context of the page. Now, what I was thinking is to add in the footer of my pages a sort of container (let's say a div) with all the microformats that I want to provide to my end user. Basicly this div will be not visible because of style setting , it will be just available for parsing purpouse. What I'm wondering is if this approach makes any sense since microformats are more oriented to give semantic/parsability to the visible content. I was thinking as an alternative to provide the possibility to download directly the vcard or whatever, but I still would preferer microformats since they sounds for me a bit more discoverable than a link to the vcard or to the final object. One last question that I have is about the screen reader for impaired user. Is there already a standard/proposal to signal that a section of the page is dedicated to microformats, or maybe I should just use something to avoid the processing of the container by the screen reader. That's all, thank you for the attention. Paolo ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hidden microformats
Hmm. Might it work for you to have an Address Book or Calendar page (or subsection) with the full information, and simply link to that from the mention? The reasons is that hidden microformats tend to be (i) be fragile and hard to maintain, plus (ii) susceptible to spam, and this overlooked by search engines. -- Ernie P. On Sep 27, 2006, at 5:15 PM, Paolo Negri wrote: Hi Ernie Thanks for replying The application I'm working on is rich in calendar items and people. On some pages I have all the infos about these items and I can produce very complete uformats. On other pages I render let's say just the name and the email of someone and it doesn't make sense to provide a less complete hcard than in a different page, and I absolutely can't add the extra information (address, role) as visible. Another problem is that there are a lot of data on the page and the bits to build the uformats are well spreaded on it so I have to put the main div or whatever at a very high level of the dom which is not really nice because it tends to group even some items that are not really in his context. Paolo On 27/09/06, Dr. Ernie Prabhakar [EMAIL PROTECTED] wrote: HI Paolo, In general hidden microformats are frowned upon, as they cause all sorts of problems. Could you give an example of the types of hidden information you want/need to provide? -- Ernie P. On Sep 27, 2006, at 2:56 PM, Paolo Negri wrote: Hi there This is my first post here, sorry if I'm not posting in the right place. I'm adding uformats support in my application and I have to say I'm quite intrigued but I'm facing with 3 problems 1) Sometime I have to change the code of my pages in places where I would prefer to have a more clean structure. 2) Sometime I would like to to the uformats on my pages information that I have in my application but that are not rendered in the current page, and adding/hiding these information in the original structure to complete the rendered information, make my page really dirty. 3) In some cases I would like to add a uformat containing informations that are not present at all on the page but that are deeply connected with the context of the page. Now, what I was thinking is to add in the footer of my pages a sort of container (let's say a div) with all the microformats that I want to provide to my end user. Basicly this div will be not visible because of style setting , it will be just available for parsing purpouse. What I'm wondering is if this approach makes any sense since microformats are more oriented to give semantic/parsability to the visible content. I was thinking as an alternative to provide the possibility to download directly the vcard or whatever, but I still would preferer microformats since they sounds for me a bit more discoverable than a link to the vcard or to the final object. One last question that I have is about the screen reader for impaired user. Is there already a standard/proposal to signal that a section of the page is dedicated to microformats, or maybe I should just use something to avoid the processing of the container by the screen reader. That's all, thank you for the attention. Paolo ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
