RE: [uf-discuss] Microformats and Firefox 3
> Alex Faaborg wrote a clever mail about this earlier and > presented a few issues and a few possibilites related to > protocols. It was then discussed that perhaps there should be > one protocl for each microformat? > That would if so enable different programs to easily take > care of different microformats. > > You'll find Faaborg's mail here (is this the usual way to > share an older mail on a mailing list or how is more common?): > http://microformats.org/discuss/mail/microformats-discuss/2007 > -August/010536.html Yes, apologies, I do lurk on this list, but sometimes it is just too overwhelming so sit back and watch. Am up for posting today, so probably repeating whats been said before. Just browsed the archives a bit and quite like Scott's approach of http://mozilla.org/add_to_address_book";>... Instead of a protocol, FF could intercept this url. Rather than opening up a webpage, it carries out the action. It degrades better so that FF2/IE/Safari users are directed to an actual page describing microformats in Firefox 3 rather than receiving an unknown protocol error. Easy to add plugins/extensions to these other browsers to intercept the url as well. One might want to use a browser agnostic url though. So FF3 intercepts the url click of an href of http://actions.microformats.org?q=add-to-address-book, stops the propogation if appropriate, grabs the q param, looks for the parent container and adds it to the addressbook. Other browsers will be directed and get to read a nice page describing hcards and how you can add them to an address book as vcards using FF3/IE with this plugin/FF2 with Operator 0.9/Safari with that plugin if ever Apple create a decent plugin architecture etc. If not in the parent hcard container, add another param for the hcard id, this would allow you to put actions anywhere on your page and FF can assess the url to say, ok, this is a uF action, you want to add to the address book, and it is that hcard, ok. http://actions.microformats.org?q=add-to-address-book&id=hcard-id http://actions.microformats.org?q=map-address&id=hcard-id http://actions.microformats.org?q=add-to-calendar&id=hcal-id Similar to the way RSS feeds are handled in FF2/3 by choosing live boookmark, google reader, bloglines etc, a pref pane decides what happens, is it added to thunderbird contacts, some address book website etc That's enough repeating from me today. T. + The Forestry Commission's computer systems may be monitored and communications carried out on them recorded, to secure the effective operation of the system and for other lawful purposes. + The original of this email was scanned for viruses by the Government Secure Intranet (GSi) virus scanning service supplied exclusively by Cable & Wireless in partnership with MessageLabs. On leaving the GSi this email was certified virus-free ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Firefox 3
Farndon, Tony wrote: And I'm with Tony (and others) on the protocol approach. I should, however, add that I do have one concern about the protocol approach; it does not degrade gracefully. Users of FF2, or IE7 or Safari etc will just get a big old unknown protocol error. This is easily countered by the designer checking for the navigator with js or using
RE: [uf-discuss] Microformats and Firefox 3
> And I'm with Tony (and others) on the protocol approach. I should, however, add that I do have one concern about the protocol approach; it does not degrade gracefully. Users of FF2, or IE7 or Safari etc will just get a big old unknown protocol error. This is easily countered by the designer checking for the navigator with js or using
Re: [uf-discuss] Microformats and Firefox 3
Dimitri, That was exactly why I suggested :target instead of :focus. I think ufs shouldn't _require_ links or other focus-eable elements. And I'm with you with the worries on pushing the meaning of the spec... is there a more meaningful alternative I don't know about? And I'm with Tony (and others) on the protocol approach. My concern is: how do we keep the actions "standard"? The user-agent must be able to recognize it so we can't have some of us publishing "export.hcard" and others "save.hcard". An API would be nice. Also, don't forget about languages. If it's up to the user agent to insert action buttons it's imperative that all languages are supported. It would be so not-cool to have a page in mandarin sporting action-buttons in english, don't you think? Cheers, André Luís On 9/5/07, Dimitri Glazkov <[EMAIL PROTECTED]> wrote: > Thanks for the comments on the margin-marks concept. I sincerely > appreciate that. > > I really like the idea of allowing additional control over > presentation via pseudo-classes, but I am worried that :target isn't > quite right, at least if we follow the spec to the letter > (http://www.w3.org/TR/css3-selectors/#target-pseudo), specifically > since this pseudo-class is not dynamic and there may or may not be a > fragment identifier on the microformat. > > Can :focus be used somehow instead? This would require an element to > accept keyboard or mouse focus, though... > > :DG< > ___ > 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] Microformats and Firefox 3
> Thanks for the comments on the margin-marks concept. I > sincerely appreciate that. Credit where credit is due! > I really like the idea of allowing additional control over > presentation via pseudo-classes, but I am worried that > :target isn't quite right, at least if we follow the spec to > the letter > (http://www.w3.org/TR/css3-selectors/#target-pseudo), > specifically since this pseudo-class is not dynamic and there > may or may not be a fragment identifier on the microformat. I have no interpretation of this I'm afraid. I would say that no solution should break css specs, even ever so slightly. Does *adding* to css break spec compliance Eg .vcard:uftarget or -moz-whatever ?? (if so, scrap everything I said in my previous posts!) Tony + The Forestry Commission's computer systems may be monitored and communications carried out on them recorded, to secure the effective operation of the system and for other lawful purposes. + The original of this email was scanned for viruses by the Government Secure Intranet (GSi) virus scanning service supplied exclusively by Cable & Wireless in partnership with MessageLabs. On leaving the GSi this email was certified virus-free ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Firefox 3
Thanks for the comments on the margin-marks concept. I sincerely appreciate that. I really like the idea of allowing additional control over presentation via pseudo-classes, but I am worried that :target isn't quite right, at least if we follow the spec to the letter (http://www.w3.org/TR/css3-selectors/#target-pseudo), specifically since this pseudo-class is not dynamic and there may or may not be a fragment identifier on the microformat. Can :focus be used somehow instead? This would require an element to accept keyboard or mouse focus, though... :DG< ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Firefox 3
On 9/5/07, André Luís <[EMAIL PROTECTED]> wrote:
> Hello everyone.
>
> - when the user hovers on the margin-mark, the user-agent should
> 'target' to the (root?) element (like what's done with the #anchor in
> urls) and that would allow the publishers to specify the
> looks/highlight accordingly. Like:
>
> .vcard:target {
> border:1px solid red;
> }
>
> or even
> .vcard:target .actions{
> visibility: visible;
> }
>
> (without constraining the publisher to a specific class name or element)
I agree with many of the previous sentiments. Dimitri's mockups are
an excellent idea and I also think it would be great to style the uf
targets via CSS :target as suggested by André. I would just like to
suggest we keep in mind the way Tails Export displays the available
microformats on a page. As opposed to Operator (which is an
invaluable tool) which uses perhaps too much menu nesting, I feel the
sidebar is the perfect place to organize this type of content.
Coupled with Dimitri's margin-marks, we could have a winner.
Jason
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Microformats and Firefox 3
To try and give where I am coming from some context, this is how I see
it all working in my head:
FF3 has a set of (3?) methods for alerting/displaying/provding actions
for uF
1) An Operator style toolbar
2) An Operator Style status icon
3) Within the content of the page (+1 and then some for dimitrys margins
approach, best I've seen yet, visible yet unobtrusive whilst still
provding some sort of location on the page display - aside: default next
to scrollbar, statisically more content on lefthand side of page)
Users can choose any or all of the three options. However, option 3
might well place something on a webpage that the designer feels strongly
against (for example a left navigation pane that keeps getting hidden by
the margin marker approach for people that prefer margin markers on the
left).
This is where you turn to css and a designer can simply declare
.vcard {
-moz-uf-display: none;
}
This tells FF3 NOT to display the margin markers for that page
regardless of whether the user has it on. This then allows the designer
to add his own uF icons.
Now onto actions. And this is where I like the protocol approach. As a
designer, you can turn off all the option 3 page uF icons as above, add
you own div/a/img etc eg Add to Address
Book
In 4 simple lines, you have told FF3 to stop adding stuff over your
page, given the control of the action to yourself and where it appears.
T.
+ The Forestry Commission's computer systems may be monitored and
communications carried out on them recorded, to secure the effective operation
of the system and for other lawful purposes. +
The original of this email was scanned for viruses by the Government Secure
Intranet (GSi) virus scanning service supplied exclusively by Cable & Wireless
in partnership with MessageLabs.
On leaving the GSi this email was certified virus-free
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Firefox 3
Hello everyone.
Great work thus far.. just want to drop my 2cents.
1) I don't think Dimitri's text was very clear on this aspect in
particular, but I believe it would improve the UXP and still give
control to the publisher.
Why not mixing the suggestion of dimitry (which seems like a very
well-thought solution) with the CSS one:
- when the user hovers on the margin-mark, the user-agent should
'target' to the (root?) element (like what's done with the #anchor in
urls) and that would allow the publishers to specify the
looks/highlight accordingly. Like:
.vcard:target {
border:1px solid red;
}
or even
.vcard:target .actions{
visibility: visible;
}
(without constraining the publisher to a specific class name or element)
2) Also, should there be only ONE way of displaying uf content? or
should the user have an option? I believe the operator's default way
(toolbar) is also pretty darn good and should not be ignored or would
it go against/collide with the work Michael has been doing?
Cheers,
André Luís
On 9/5/07, Pelle W <[EMAIL PROTECTED]> wrote:
> Farndon, Tony skrev:
> >> 2. Microformats are in page, and there needs to be some way
> >> to indicate the microformats are available on the page that
> >> doesn't offend page authors. How can we accomplish this?
> >>
> > I second the opinion that this is a design issue and therefore should be
> > handled by css in some way. This would fit into the web design paradigm
> > of markup for data, css for design. My slightly different css approach;
> > create custom css property:value pairs, such as that of
> > -moz-border-radius.
> If something should add anything it should be added by a javascript
> which the Firefox people may very well supply. To have CSS instructing
> Firefox to add something into the HTML-data seems wrong, it doesn't
> really separate the data and content from the design. If something
> should instruct anything to add new HTML-data to a document it has to be
> either the HTML itself or JavaScripts. CSS can be used to style what's
> added, but should do nothing more than that in my opinion because it's
> only purpose is to add a deisgn and if it's removed the page should work
> equally well - only not as beutiful as with the CSS added.
>
> Let's just have a javascript like the one here below. If Firefox
> supplies a microformats object by default then all webpages can rely on
> that in Firefox it can easily be extended to add support for newer
> microformats like Prototype and other javascript frameworks today
> extends basic DOM-objects and such. If someone would like they could
> even code their own implementation of such a solution which can be used
> in other browsers than Firefox until those browsers adds support
> themselves either directly or indirectly through extensions.
>
>
RE: [uf-discuss] Microformats and Firefox 3
> If something should add anything it should be added by a > javascript... CSS is frequently used to *add* and place onto a page, be it a background image, a border, etc What I am saying is rather than add say, a background image, you use CSS to add/place a microformat icon. How this icon behaves when you click on it is designed by FF, what you are saying to the web designer is where do you want this dropdown/menu/action/whatever container to appear, if at all. > If something should instruct > anything to add new HTML-data to a document it has to be > either the HTML itself or JavaScripts. This is where I have got confused over what this whole topic is this about: the UI or adding actions (hence my reply was to point 2 from Mike). My impression is that it is a UI issue of how you notify the user that there is uf present, where it is on the page and what actions are available, without stepping on the toes of the designer and the users browsing experience. This is a *design* issue which to me implies a css solution. > There are probably better arguments for choosing a solution > like this over a CSS and/or HTML based solution, I hope > someone more experienced than me can tell us some of them. There are of coarse many valid reasons for a non-js approach. How many turn off, or control js with extensions compared to turning off/controlling css?? I would wager less for the latter. Tony + The Forestry Commission's computer systems may be monitored and communications carried out on them recorded, to secure the effective operation of the system and for other lawful purposes. + The original of this email was scanned for viruses by the Government Secure Intranet (GSi) virus scanning service supplied exclusively by Cable & Wireless in partnership with MessageLabs. On leaving the GSi this email was certified virus-free ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Firefox 3
Farndon, Tony skrev: 2. Microformats are in page, and there needs to be some way to indicate the microformats are available on the page that doesn't offend page authors. How can we accomplish this? I second the opinion that this is a design issue and therefore should be handled by css in some way. This would fit into the web design paradigm of markup for data, css for design. My slightly different css approach; create custom css property:value pairs, such as that of -moz-border-radius. If something should add anything it should be added by a javascript which the Firefox people may very well supply. To have CSS instructing Firefox to add something into the HTML-data seems wrong, it doesn't really separate the data and content from the design. If something should instruct anything to add new HTML-data to a document it has to be either the HTML itself or JavaScripts. CSS can be used to style what's added, but should do nothing more than that in my opinion because it's only purpose is to add a deisgn and if it's removed the page should work equally well - only not as beutiful as with the CSS added. Let's just have a javascript like the one here below. If Firefox supplies a microformats object by default then all webpages can rely on that in Firefox it can easily be extended to add support for newer microformats like Prototype and other javascript frameworks today extends basic DOM-objects and such. If someone would like they could even code their own implementation of such a solution which can be used in other browsers than Firefox until those browsers adds support themselves either directly or indirectly through extensions.
RE: [uf-discuss] Microformats and Firefox 3
> 2. Microformats are in page, and there needs to be some way
> to indicate the microformats are available on the page that
> doesn't offend page authors. How can we accomplish this?
I second the opinion that this is a design issue and therefore should be
handled by css in some way. This would fit into the web design paradigm
of markup for data, css for design. My slightly different css approach;
create custom css property:value pairs, such as that of
-moz-border-radius.
So some poor examples that give an idea (and would warrant derivation
from someone better than I):
#hcard1 {
-moz-uf-hcard-display: block bottom; //instructs FF3 that the author
wishes ff3 to show an hcard icon after the hcard
-moz-uf-hcard-margin: 5px;
}
#hcard2 {
-moz-uf-hcard-display: block top; //author wants this icon to be at the
top to fit in with page design a little better
-moz-uf-map-display: block top; //author wants a view address map icon
as well
}
#hcard3 {
-moz-uf-hcard-display: none; //author wants this icon hidden
}
.hcard {
-moz-uf-hcard-icon: icon(thenicesmallgreenicon); //all hcards have the
small green icon
}
.hcard:hover {
-moz-uf-hcard-menu: dropdown; //hovering the icon shows an action drop
down menu
}
Tony
+ The Forestry Commission's computer systems may be monitored and
communications carried out on them recorded, to secure the effective operation
of the system and for other lawful purposes. +
The original of this email was scanned for viruses by the Government Secure
Intranet (GSi) virus scanning service supplied exclusively by Cable & Wireless
in partnership with MessageLabs.
On leaving the GSi this email was certified virus-free
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Firefox 3
On 9/4/07, Alex Faaborg <[EMAIL PROTECTED]> wrote: > I really like this idea, I just forward the post and mockups to the > rest of our UX team and our lead engineer. > I agree with Alex. This is a really great idea. Thanks for posting. Mike ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Firefox 3
I really like this idea, I just forward the post and mockups to the rest of our UX team and our lead engineer. This is not particularly transient If the margin marks bar only appeared on pages with recognized content, then I think this would certainly count as being transient. Or, to be even less intrusive, a small mark could indicate content was recognized, and clicking on that could cause the margin marks bar to slide in. Dimitri: this is a great idea and the mockups are really well done, thanks for posting it! -Alex On Sep 4, 2007, at 2:31 PM, Manu Sporny wrote: Dimitri Glazkov wrote: This is not particularly transient, but it addresses #2, methinks: http://glazkov.com/blog/margin-marks/ Mike, Alex - I think you should take a very serious look at Dimitri's Margin Marks idea. Check out the screen mock-ups here: http://flickr.com/photos/dglazkov/sets/72157601860335196/ Implementation would be a bit of a headache, but he has proposed a very elegant solution on, IMHO, the right way to display semantic data items on a web page. It is the best approach that I've seen so far, over all of the UI concepts for Microformats in Firefox 3. This is the same way that Eclipse shows the developer warnings, comments and errors via the code editor. It would do well as a transient UI AND wouldn't be intrusive on the browsing experience when the UI is active. Exciting stuff... -- manu -- Manu Sporny http://wiki.digitalbazaar.com/en/haudio-case-study ___ 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] Microformats and Firefox 3
Dimitri Glazkov wrote: > This is not particularly transient, but it addresses #2, methinks: > > http://glazkov.com/blog/margin-marks/ Mike, Alex - I think you should take a very serious look at Dimitri's Margin Marks idea. Check out the screen mock-ups here: http://flickr.com/photos/dglazkov/sets/72157601860335196/ Implementation would be a bit of a headache, but he has proposed a very elegant solution on, IMHO, the right way to display semantic data items on a web page. It is the best approach that I've seen so far, over all of the UI concepts for Microformats in Firefox 3. This is the same way that Eclipse shows the developer warnings, comments and errors via the code editor. It would do well as a transient UI AND wouldn't be intrusive on the browsing experience when the UI is active. Exciting stuff... -- manu -- Manu Sporny http://wiki.digitalbazaar.com/en/haudio-case-study ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Firefox 3
On 9/4/07, Mike Kaply <[EMAIL PROTECTED]> wrote: > I think some folks here are missing the point in the > Microformats/Firefox 3 discussion. > > We are trying to foster a discussion about what to do with > microformats in Firefox 3, we are not trying to tell you what we are > going to do. > > This is a very difficult problem to solve and we need input on it. At > this point, the microformats community has primarily been focused on > marking up microformats. We want people to start thinking about how to > communicate microformats to the user. > > So here are a few discussion points to get people focused: > > 1. Microformats UI in the browser needs to be a "transient UI." That > is, dedicating permanent space in the browser to a technology that is > not available on most sites probably doesn't make much sense (at least > at first). What does transient UI in a browser look like? > > 2. Microformats are in page, and there needs to be some way to > indicate the microformats are available on the page that doesn't > offend page authors. How can we accomplish this? > This is not particularly transient, but it addresses #2, methinks: http://glazkov.com/blog/margin-marks/ :DG< ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Firefox 3
On 9/4/07, David Mead <[EMAIL PROTECTED]> wrote: > I would love to see a new button in the URL bar, like Flock has for > when there is RSS, media streams or a SE plugin on the page. That is > one feature of the new Flock I find I'm using a lot now. Note that Operator does have a URL button option in 0.8 > I also think there should be something to check in the options panel > so I can choose to have any action based on a microformat in the page, > open a new tab or window, if it doesn't involve an external > application. Maybe that's on a new tab within options where I can set > the default handlers for different microformats? Actually, we honor the Firefox keystrokes for this. Try holding down the Ctrl button when you click on an action or using the middle mouse button. See: http://www.mozilla.org/support/firefox/mouse Thank you for your comments! Mike ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Firefox 3
Mike, I must say the way I'm using Operator in Flock & Firefox at the moment (using the auto-hide function for the toolbar) is working well for me. I think one way to go is to utilize the same functionality as the "this site wants to open pop-up windows" that Firefox has. A small toolbar-like message that appears above the page, but not seemingly part of the chrome, that informs you there are microformats on the page. This could then disappear after a short time or after a click to "highlight" them on the page or open a sidebar/toolbar to interact with them. I think automatically highlighting by use of a icon (webcards) or change of cursor is cool to start with but I personally tired of it after a while. I would love to see a new button in the URL bar, like Flock has for when there is RSS, media streams or a SE plugin on the page. That is one feature of the new Flock I find I'm using a lot now. I also think there should be something to check in the options panel so I can choose to have any action based on a microformat in the page, open a new tab or window, if it doesn't involve an external application. Maybe that's on a new tab within options where I can set the default handlers for different microformats? I'm really looking forward to this being part of the new Firefox. Dave On 9/4/07, Mike Kaply <[EMAIL PROTECTED]> wrote: > I think some folks here are missing the point in the > Microformats/Firefox 3 discussion. > > We are trying to foster a discussion about what to do with > microformats in Firefox 3, we are not trying to tell you what we are > going to do. > > This is a very difficult problem to solve and we need input on it. At > this point, the microformats community has primarily been focused on > marking up microformats. We want people to start thinking about how to > communicate microformats to the user. > > So here are a few discussion points to get people focused: > > 1. Microformats UI in the browser needs to be a "transient UI." That > is, dedicating permanent space in the browser to a technology that is > not available on most sites probably doesn't make much sense (at least > at first). What does transient UI in a browser look like? > > 2. Microformats are in page, and there needs to be some way to > indicate the microformats are available on the page that doesn't > offend page authors. How can we accomplish this? > > Discuss. > > Incidentally, Operator was always intended to be a UI experiment in > microformats. I'm finding that most people use the toolbar (probably > because it's the default). But there are six different ways to > interact with microformats in Operator > (http://www.kaply.com/weblog/operator). > > Mike Kaply > ___ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- David Mead www.dmwebsites.com www.viewfromw6th.com www.refreshcleveland.org ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Firefox 3
Ok Mike. Thanks for clearing it up. I'd like to know one thing... Have you discussed the option of using the notification box as a first notification to the user of the presence of microformats in the current page and _there_ provide a button to reveal them? I've searched but found nothing similar... but what do you guys think? This wouldn't require any permanent space on the UI... and it wouldn't inject anything until an action from the user was performed. (to avoid confusion i mean the notification box like this drawing points out: http://people.mozilla.com/~faaborg/files/20070204-detectionUI/anatomyChrome.jpg_large.jpg) Cheers, André Luís On 9/4/07, Mike Kaply <[EMAIL PROTECTED]> wrote: > I think some folks here are missing the point in the > Microformats/Firefox 3 discussion. > > We are trying to foster a discussion about what to do with > microformats in Firefox 3, we are not trying to tell you what we are > going to do. > > This is a very difficult problem to solve and we need input on it. At > this point, the microformats community has primarily been focused on > marking up microformats. We want people to start thinking about how to > communicate microformats to the user. > > So here are a few discussion points to get people focused: > > 1. Microformats UI in the browser needs to be a "transient UI." That > is, dedicating permanent space in the browser to a technology that is > not available on most sites probably doesn't make much sense (at least > at first). What does transient UI in a browser look like? > > 2. Microformats are in page, and there needs to be some way to > indicate the microformats are available on the page that doesn't > offend page authors. How can we accomplish this? > > Discuss. > > Incidentally, Operator was always intended to be a UI experiment in > microformats. I'm finding that most people use the toolbar (probably > because it's the default). But there are six different ways to > interact with microformats in Operator > (http://www.kaply.com/weblog/operator). > > Mike Kaply > ___ > 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
[uf-discuss] Microformats and Firefox 3
I think some folks here are missing the point in the Microformats/Firefox 3 discussion. We are trying to foster a discussion about what to do with microformats in Firefox 3, we are not trying to tell you what we are going to do. This is a very difficult problem to solve and we need input on it. At this point, the microformats community has primarily been focused on marking up microformats. We want people to start thinking about how to communicate microformats to the user. So here are a few discussion points to get people focused: 1. Microformats UI in the browser needs to be a "transient UI." That is, dedicating permanent space in the browser to a technology that is not available on most sites probably doesn't make much sense (at least at first). What does transient UI in a browser look like? 2. Microformats are in page, and there needs to be some way to indicate the microformats are available on the page that doesn't offend page authors. How can we accomplish this? Discuss. Incidentally, Operator was always intended to be a UI experiment in microformats. I'm finding that most people use the toolbar (probably because it's the default). But there are six different ways to interact with microformats in Operator (http://www.kaply.com/weblog/operator). Mike Kaply ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
