Re: [uf-discuss] invisible content OK?
On 9/4/07, Catherine Devlin [EMAIL PROTECTED] wrote: Hi, everybody! --- welcome to the list, you have come to the right place to get microformats questions answered. One question I haven't seen addressed is whether it's considered good practice to hide information from the as-displayed webpage while including it in the microformat. --- much of this has been discussed before, a quick search of the mailing list archives pulls up over 100 results. That is probably the best place to start and read-up on the topic. If you still have questions then feel free to ask them here again. http://www.google.com/search?q=site:http://microformats.org/discuss%20hidden%20data There is also an FAQ page, which does not currently have an Q A for this, feel free to add one and answer it. Then we can all itterate and help the next person to find the answer. http://microformats.org/wiki/faq -brian -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] events (was: invisible content OK?)
In message [EMAIL PROTECTED], Catherine Devlin [EMAIL PROTECTED] writes Hi, everybody! Hello. I'm a new enthusiast to the Microformats world. I volunteered to present them to our Web Standards meetup ( http://webstandards.meetup.c om/122/ ) You might like to add that to: http://microformats.org/wiki/events -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Microformats UI in Firefox 3
sorry for busting in late on this conversation, but let me get this straight, I'm not sure I follow. 1. You guys are proposing a radical change in microformats, and in the way microformats work, and have given us just a week to discuss/ object 2. If radical change is implemented in firefox, all existing microformatted content will fail to work in firefox3 3. said radical change includes inline styles- functionally identical to presentational html tags. 4. In order to play nice with firefox 3, all publishers of microformatted content would need to add extra stuff to their markup. 5. That extra stuff would *only* be necessary for firefox Are any of the above points incorrect? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Microformats UI in Firefox 3
Breton Slivka wrote: 1. You guys are proposing a radical change in microformats, and in the way microformats work, and have given us just a week to discuss/object 2. If radical change is implemented in firefox, all existing microformatted content will fail to work in firefox3 3. said radical change includes inline styles- functionally identical to presentational html tags. 4. In order to play nice with firefox 3, all publishers of microformatted content would need to add extra stuff to their markup. 5. That extra stuff would *only* be necessary for firefox It's more of an addition than a radical change to the microformats which enables the designer to add Firefox-actions right into their own design although such actions will always also be available through Firefox own UI and the suggested addition wouldn't change how any existing microformats would work or should work. It would be totally voluntarily. If it would be part of microformat standard it would work in any tool which implements it. Although I think the suggestion that was made at first wasn't that good, the core problem it tries to solve is relevant: A need for a standardized way for a webdesigner to add interaction between the microformatted data and the parsers actions into their own designs. Could the Microformat community come up witha standard way of interacting with the parsers through JavaScripts or perhaps through new URL:s like mailto: or feed: or in another way? Or is such a standard perhaps out of this community's scope? / Pelle W ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Microformats UI in Firefox 3
Okay well, that's a relief.
It's amazing though, that we're talking about enabling designers to
design, but have only so far mentioned html, javascript and urls.
What about putting the design into the design code: css? Would it not
be a simple matter of adding selectors for the firefox mf ui elements?
example:
x-mozilla-add-hcard {
visibility:visible;
background:orange;
border: 1px solid black;
}
which would select whatever element is the button/link for adding an
hcard.
-breton
On 04/09/2007, at 9:50 PM, Pelle W wrote:
Breton Slivka wrote:
1. You guys are proposing a radical change in microformats, and in
the way microformats work, and have given us just a week to
discuss/object
2. If radical change is implemented in firefox, all existing
microformatted content will fail to work in firefox3
3. said radical change includes inline styles- functionally
identical to presentational html tags.
4. In order to play nice with firefox 3, all publishers of
microformatted content would need to add extra stuff to their markup.
5. That extra stuff would *only* be necessary for firefox
It's more of an addition than a radical change to the microformats
which enables the designer to add Firefox-actions right into their
own design although such actions will always also be available
through Firefox own UI and the suggested addition wouldn't change
how any existing microformats would work or should work. It would
be totally voluntarily. If it would be part of microformat standard
it would work in any tool which implements it.
Although I think the suggestion that was made at first wasn't that
good, the core problem it tries to solve is relevant: A need for a
standardized way for a webdesigner to add interaction between the
microformatted data and the parsers actions into their own designs.
Could the Microformat community come up witha standard way of
interacting with the parsers through JavaScripts or perhaps through
new URL:s like mailto: or feed: or in another way? Or is such a
standard perhaps out of this community's scope?
/ Pelle W
___
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] Marking up table rows
How would I mark-up the second table row (based on a real-world advocacy example): trthLongitude/ththLatitude/ththHeight/ththFooobar/ththPlace/th/tr trtd16.30/tdtd61.07/tdtd140/tdtdzzz/tdtdWidgetsville/td/tr with both hCard and geo? The real example has ~50 rows. Is it feasible to wrap each in: tbody class=vcard? is there an alternative? (When we have an answer, suitable also for hCalendar and other microformats, I suggest this be added as a FAQ) -- Andy Mabbett ** via webmail ** ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Marking up table rows
How would I mark-up the second table row (based on a real-world advocacy example): trthLongitude/ththLatitude/ththHeight/ththFooo bar/ththPlace/th/tr trtd16.30/tdtd61.07/tdtd140/tdtdzzz/tdtdWi dgetsville/td/tr with both hCard and geo? The real example has ~50 rows. Is it feasible to wrap each in: tbody class=vcard? is there an alternative? Maybe I'm missing something, but what's the problem with tr class=vcard ? Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Marking up table rows
On 9/4/07, Nick Fitzsimons [EMAIL PROTECTED] wrote: trthLongitude/ththLatitude/ththHeight/ththFooo bar/ththPlace/th/tr trtd16.30/tdtd61.07/tdtd140/tdtdzzz/tdtdWi dgetsville/td/tr with both hCard and geo? Maybe I'm missing something, but what's the problem with tr class=vcard I suspect it's the fact the lon/lat need a @class=geo wrapper. that would have to go on the TR meaning the vcard gets pushed up a level. The lack of anything to wrap table columns in is quite a frustration. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Marking up table rows
How would I mark-up the second table row (based on a real-world advocacy example): trthLongitude/ththLatitude/ththHeight/ththFooobar/tht h Place/th/tr trtd16.30/tdtd61.07/tdtd140/tdtdzzz/tdtdWidgetsville / td/tr with both hCard and geo? The real example has ~50 rows. Is it feasible to wrap each in: tbody class=vcard? is there an alternative? Would it be feasible to add the class=vcard to the tr instead? Also, just out of curiosity, why you would mark this information as an hcard? I assume that one of the columns would contain a name, email, phone number, etc. and that would be the reason. Otherwise, I'm not sure why you would use class=vcard instead of just class=geo. If there is a reason, I would like to know for my own reference. Thanks, Mike ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Marking up table rows
I suspect it's the fact the lon/lat need a @class=geo wrapper. that would have to go on the TR meaning the vcard gets pushed up a level. tr class=vcard geo or is that naughty? :-) Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Marking up table rows
On Tue, September 4, 2007 16:16, Montgomery, Mike wrote: How would I mark-up the second table row (based on a real-world advocacy example): trthLongitude/ththLatitude/ththHeight/ththFooobar/th thPlace/th/tr trtd16.30/tdtd61.07/tdtd140/tdtdzzz/tdtdWidgetsville /td/tr with both hCard and geo? The real example has ~50 rows. Is it feasible to wrap each in: tbody class=vcard? is there an alternative? Would it be feasible to add the class=vcard to the tr instead? Then what would you wrap with geo? Also, just out of curiosity, why you would mark this information as an hcard? Geo on its own has no label. By using hCard, and applying class=fn org to the place-name, the Geo is, in effect, labelled. -- Andy Mabbett ** via webmail ** ___ 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
Re: [uf-discuss] Marking up table rows
On 9/4/07, Nick Fitzsimons [EMAIL PROTECTED] wrote: I suspect it's the fact the lon/lat need a @class=geo wrapper. that would have to go on the TR meaning the vcard gets pushed up a level. tr class=vcard geo or is that naughty? :-) I believe that vcard child properties have to be on child HTML nodes. -Ciaran McNulty ___ 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
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] Marking up table rows
Hello Nick,
On 9/4/07, Nick Fitzsimons [EMAIL PROTECTED] wrote:
I suspect it's the fact the lon/lat need a @class=geo wrapper. that
would have to go on the TR meaning the vcard gets pushed up a level.
tr class=vcard geo
or is that naughty? :-)
I actually do stuff like that all the time... for things like
signatures... it makes it very compact... for example...
-- a class=vcard fn n url href=http://changelog.ca/;Charles Iliya
Krempeaux/a
(It makes it so I don't have to add any extra tags... like span's...
and adding hCards is as simple as just adding classes.)
I've heard some people complain because... my impression was... that
they weren't sure how to style it... but, for example, if you wanted
to style the url of an hCard, you could with...
.vcard a.url, a.vcard.url {
/* style goes here */
}
So I'd say do it that way. (Others may disagree though.)
See ya
--
Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/
Vlog Razor... Vlogging News
http://vlograzor.com/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Marking up table rows
On Sep 4, 2007, at 8:39 AM, Nick Fitzsimons wrote: I suspect it's the fact the lon/lat need a @class=geo wrapper. that would have to go on the TR meaning the vcard gets pushed up a level. tr class=vcard geo or is that naughty? :-) It's not naughty, but it just doesn't mean what you hope it means. :) -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Marking up table rows
tr class=vcard geo or is that naughty? :-) I actually do stuff like that all the time... for things like signatures... it makes it very compact... for example... -- a class=vcard fn n url href=http://changelog.ca/;Charles Iliya Krempeaux/a Strictly speaking it actually isn't correct according to the hCard spec: The basic format of hCard is to use vCard object/property names in lower-case for class names, and to map the nesting of vCard objects directly into nested XHTML elements http://microformats.org/wiki/hcard#In_General The explicit statment that nesting is to be achieved by the use of nested (X)HTML elements makes it clear that assigning the properties at the same level as the vcard declaration (for want of a better word) is not correct. This is confirmed by such statements in the following subsection as The properties of an hCard are represented by *elements inside* the hCard and Some properties have sub-properties, and those are represented by *elements inside* the elements for properties (my emphasis). On the other hand, is it necessarily a bad thing to use a construct such as p class=vcard geo if it doesn't lead to ambiguity? After all, the spec isn't written in stone (it's written in a Wiki, which is pretty much the opposite of being written in stone...) so maybe this restriction could be relaxed? Without giving it the extensive consideration that other, doubtless wiser, heads have already given it I can't be certain that such constructs might not lead to ambiguity to the extent of making it difficult if not impossible for parsers to correctly interpret the structure of an hCard. But if in fact the mimicking of the nested structure of the vCard format need only be represented by a kind of virtual nesting within HTML, where the presence of a property name at the same level as its container is taken as implying containment, rather than containment depending on an actual nesting of elements, then perhaps the spec could be relaxed to make it permissible. Something to think about down the pub ;-) Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Marking up table rows
On Sep 4, 2007, at 12:26 PM, Charles Iliya Krempeaux wrote: tr class=vcard geo or is that naughty? :-) I actually do stuff like that all the time... for things like signatures... it makes it very compact... for example... -- a class=vcard fn n url href=http://changelog.ca/;Charles Iliya Krempeaux/a (It makes it so I don't have to add any extra tags... like span's... and adding hCards is as simple as just adding classes.) I've heard some people complain because... my impression was... that they weren't sure how to style it... but, for example, if you wanted to style the url of an hCard, you could with... Styling is only one practical problem (IE 6, still the most popular browser, doesn't support multi-class selectors). More importantly, I'd say, is the theoretical problem of hierarchy semantics. HTML defines hierarchy by nesting of elements, so that's what microformats do. Putting several classes together in a single element identifies the content of that element as belonging to each class, but it doesn't tell us anything about the hierarchy of those elements. With the markup above, how do we know if FN is a property of vCard or vCard is a property of URL? As the number of atomic microformats and the ways in which they might be nested in each other expands, this will move from a theoretical to a practical problem. We could certainly define our own method of establishing hierarchy, e.g. order of classes, but HTML already has a method that generally works well. In the above example, only one extra span is needed to clarify that vCard is the container for the other properties. With tables (and lists) HTML's hierarchy method doesn't work as well because there are nesting limits imposed (e.g. nothing is allowed between tr and td), but I think we should more thoroughly investigate alternative solutions to this problem (e.g. colgroups), before reinventing the wheel on hierarchy semantics. Peace, Scott ___ 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
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] Re: Microformats UI in Firefox 3
1. You guys are proposing a radical change in microformats, and in the way microformats work As Pelle mentioned, we are discussing the possibility of allowing designers to add UI widgets to act on microformats in the content area. I certainly don't think this constitutes a radical change since they would be optional, and we are working closely with the microformats community to make sure we get it right. and have given us just a week to discuss/object If these changes land in a release of Operator that we heavily promote at the Firefox 3 launch, then we will have considerably more time to discuss the various options. If the microformats community really wants to see this feature land in Firefox 3, then we unfortunately will need to move rather quickly. 2. If radical change is implemented in firefox, all existing microformatted content will fail to work in firefox3 Not at all, these microformats could potentially still show up elsewhere in the browser UI, for instance in a toolbar, or sidebar, or a right click context menu on the microformatted content. 3. said radical change includes inline styles- functionally identical to presentational html tags. We are open to all suggestions. Thanks for the css example, I've added it to our list of possible solutions. The user-action-x class, action:// protocol, and navigator.send javascript method were only proposed to get the conversation going. 4. In order to play nice with firefox 3, all publishers of microformatted content would need to add extra stuff to their markup. This isn't about a requirement for playing nice with Firefox 3, if Web designers decided they wanted to create buttons to act on their microformatted content, then they would potentially be able to do so. 5. That extra stuff would *only* be necessary for firefox I would be very happy to see the other browsers add similar support. Unfortunately since they aren't developed in as transparent of a manner, we have no idea if they are currently considering this type of functionality or not. One guaranteed way to get them all to seriously consider adding the feature is for us to ship it in Firefox. I hope that clears things up, and my apologies for the confusion. -Alex On Sep 4, 2007, at 4:27 AM, Breton Slivka wrote: sorry for busting in late on this conversation, but let me get this straight, I'm not sure I follow. 1. You guys are proposing a radical change in microformats, and in the way microformats work, and have given us just a week to discuss/ object 2. If radical change is implemented in firefox, all existing microformatted content will fail to work in firefox3 3. said radical change includes inline styles- functionally identical to presentational html tags. 4. In order to play nice with firefox 3, all publishers of microformatted content would need to add extra stuff to their markup. 5. That extra stuff would *only* be necessary for firefox Are any of the above points incorrect? ___ 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] Margin Marks UI Concept, was: Microformats and Firefox 3
To keep the threads clean.. Posting this as a separate message. http://glazkov.com/blog/margin-marks/ Comments, discussion appreciated. :DG ___ 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
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
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
