On 6/5/07, Montgomery, Mike <[EMAIL PROTECTED]> wrote:
I like the idea of an icon that is activated when microformat content is available as mentioned by Paul. It would provide an immediate visual cue that information is available without direct user interaction such as having to hover of content or right-clicking. It would also provide a way to indicate information that may be hidden on the page. I picture it being similar to the RSS feed icon. Maybe it is something that also appears in the address bar.
I'm considering experimenting with putting a microformats icon on the URL bar similar to the RSS icon, but that would be Operator only. The Firefox folks specifically don't want to clutter up that bar. The basic problem with Firefox is that they don't want to clutter the UI with something that might not be used a lot (this is a statement about all microformats in the UI)
For the record, I actually like the way the Operator add-on works in Firefox. It provides the mircoformat information broken down in different categories (contacts, calendar, maps, etc.) in the tool bar and the Options menu, it provides the ability to Highlight microformats on the page when you mouseover them (similar to the cursor concept). I also like the fact I can turn off this feature. However, I know that an entire tool bar takes up a lot of browser real estate and something more compact would be better.
That was really my goal to provide as many UI paradigms as possible in Operator so that people could decide which they liked the best. If people don't like the toolbar, they can use the Operator toolbar button or the Operator status bar icon. One of the ideas I have which isn't done yet is to provide certain microformats as standalone toolbar buttons (like a Contacts toolbar button).
One last thing, are there any thoughts on which microformats would be supported by the Firefox UI? Would it be all of them? Maybe it would only be those that are specs and not drafts?
Yes. At this point it will probably be hCard, hCalendar, Address and maybe geo. There will be no rel based microformats. The reason for no rel based microformats is because if you think about it, they are difficult to detect efficiently. For instance, detecting XFN requires seeing if the rel attribute contains one or more of 18 different things. Not very efficient. Detecting classes is much more straightforward. The reason I'm doing Address is the same reason I put it in Operator - it doesn't make sense to do things like "search google maps" on an hCard, since the hCard is not the address, and the hCard can contain more than one address. Mike Kaply _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
