Re: [uf-discuss] Re: Apple Data Detectors
On the other end, if, as I type this, I get an intellisense-like list of my contacts that I can select from, then I can just select Joe from the list and have the microformat markup added for me I've been thinking a lot about how a Web browser could help end users author microformatted content in blogs and wikis, and I think we need to consider the user's goals and motivations. I can't imagine people associating a contact in their address book with Joe as they casually mention him in a blog post just because they have an appreciation for the beauty of structured data. However, if their goal is closely aligned with the goal of their readers, then I can see users going to the extra effort. For instance, let's say you want to review something, and because you want your vote to count and other people to be able to take advantage of your review once it gets aggregated, I can see users going to the extra effort of filling out a form like the hReview creator (http://microformats.org/code/hreview/creator) to get information into the structure of an hReview. The same goes for people who want to promote an event: since their motivation is for people to attend, they make it easy for users to add the event to their calendar. We already see this type of behavior in applications like Outlook or Zimbra, where people create events for other people, so they are easy to accept. Microformats allow to take that interaction out of closed systems, and apply it to HTML emails, blog posts, wikis, etc. I'm all for building systems that attempt to infer structure from natural language, because like we see in Apple's 1998 article, and now in Mail.app, these types of systems can be really useful when they work. But I also don't think we should discount situations where the user may actually have a clear motivation for creating structured data by filling out a form. In case anyone is interested in reading more about Data Detectors, you might find this paper interesting. It catalogs all of the research done throughout the late 90s, and discusses a prototype system that leverages large knowledge bases like Stanford's TAP and MIT's ConceptNet to disambiguate natural language and provide structure to unstructured text: http://alumni.media.mit.edu/~faaborg/files/thesis/draft/complete/CHI06_goalOrientedWebBrowser.pdf -Alex On Feb 8, 2008, at 8:40 AM, Guillaume Lebleu wrote: Toby A Inkster wrote: Guillaume Lebleu wrote: What I have been thinking more and more and what this tells me again is that the same way we talk of POSH and microformats, we could talk of plain text or plain old english formats, essentially standardizing how people write dates, addresses, etc on the Web or on their emails. Asking people to write Tuesday, February 5, 2008 in this order, with the commas, etc. is very likely even simpler for normal people than writing abbr class=foo title=2008-05-02Tuesday, February 5, 2008/ abbr. One problem with that is that it will find matches on people who aren't even intending to use your plain-old-english format. They may happen to be including Tuesday, February 5, 2008 on their pages with a different intended meaning. 2008 could refer to eight minutes past eight PM in military time -- unlikely, but possible. And as you move away from dates, phone numbers and postcodes which have relatively parseable formats, towards locations, people's names and job titles and so on, the likelihood of false matches increases. The use of explicit tags to mark up information do make microformats slightly harder to use, yes. But the key is that they also make microformats much easier to explicitly not use. Toby, I understand the challenge of disambiguation and the value microformats bring in terms of easier parser implementation and more reliable information consumption experience. The challenge for average people writing microformats can't be underestimated though. I strongly believe that the time where disambiguation costs are the lowest are at publishing time, but this is also the time where you are focused on the english content, not the microformats. This is why in the second part of the post you cited, I suggested the use of Apple Data Detectors' like functionality, not to detect objects in plain old english (POE) in published content, but to detect objects in POE at the time they are written and ask for the user for disambiguation at the same time, in a way that the underlying microformat markup is generated, but without the user having to know the syntax. I'm thinking of this particularly in the context of writing a blog post: writing 1 hCards just to say My friend Joe is way too much for normal people. On the other end, if, as I type this, I get an intellisense-like list of my contacts that I can select from, then I can just select Joe from the list and have the microformat markup
Re: [uf-discuss] Firefox 3 (was: Icons of MF wiki)
do you have any plans to support rdf-a in the interface? In 4.0, 5.0, 6.0? We haven't decided yet, and I would love to hear people's opinions both in favor of and against including RDFa support in a future release of Firefox. -Alex On Jan 11, 2008, at 2:02 AM, Michael Smethurst wrote: On 10/1/08 18:03, Alex Faaborg [EMAIL PROTECTED] wrote: By next release, do you mean 3.0.1 (or some such) or 4.0? The next major release (point releases are primarily used for security updates). In general we try to do a release every 12 months, but since 3 has turned into a longer cycle (starting to look like 16-17 months) and focused on a lot of backed changes, the next release may potentially be a shorter cycle and be more about front end changes. However, that plan hasn't been formalized yet. Since we are completely focused on 3 right now, we don't have an estimated schedule of exactly when we would like to ship 4.0 -Alex Hi Alex Sorry to be a pain but do you have any plans to support rdf-a in the interface? In 4.0, 5.0, 6.0? On Jan 10, 2008, at 9:28 AM, Andy Mabbett wrote: On Thu, January 10, 2008 16:48, Alex Faaborg wrote: In order to maintain the current ship schedule for Firefox 3, we won't be exposing microformatted content in the user interface. Much as I'm keen to have FF3, that's a shame. we will only need to worry about finishing front end changes for getting microformat support into the next release. By next release, do you mean 3.0.1 (or some such) or 4.0? -- Andy Mabbett ** via webmail ** ___ 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 http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ___ 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] Icons of MF wiki
All of the icons coming out of mozilla are likely going to be full public domain, since CC attribution licenses are not compatible with the mozilla.org license policy. Also, we want to reduce any possible barriers to entry for using the icons for basic types of information (similar to what happened with RSS). Unfortunately it might be awhile before we begin releasing microformat icons into the public domain. In order to maintain the current ship schedule for Firefox 3, we won't be exposing microformatted content in the user interface. We will however still ship with the microformats API implemented by Mike Kaply (of Operator fame), so it will be considerably easier for Firefox extensions to experiment and innovate with microformats. The API that Mike landed for Firefox 3 also means that we will only need to worry about finishing front end changes for getting microformat support into the next release. We tend to release new versions of Firefox pretty regularly, so while I'm personally disappointed that Firefox 3 won't have native support in the interface for detecting microformats, the next release isn't too far over the horizon. -Alex On Jan 10, 2008, at 7:57 AM, Chris Messina wrote: Was thinking... I don't have a problem with PD for my text contributions, but for graphics and artwork, I feel that there should be proper credit given for derivative works (i.e. the microformats icons that Wolfgang Bartelme did). Is it possible to license artwork under a different license and keep it on the wiki (i.e. CC+)? Chris -- Chris Messina Citizen-Participant Open Source Advocate-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412.225.1051 IM: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ 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] Firefox 3 (was: Icons of MF wiki)
By next release, do you mean 3.0.1 (or some such) or 4.0? The next major release (point releases are primarily used for security updates). In general we try to do a release every 12 months, but since 3 has turned into a longer cycle (starting to look like 16-17 months) and focused on a lot of backed changes, the next release may potentially be a shorter cycle and be more about front end changes. However, that plan hasn't been formalized yet. Since we are completely focused on 3 right now, we don't have an estimated schedule of exactly when we would like to ship 4.0 -Alex On Jan 10, 2008, at 9:28 AM, Andy Mabbett wrote: On Thu, January 10, 2008 16:48, Alex Faaborg wrote: In order to maintain the current ship schedule for Firefox 3, we won't be exposing microformatted content in the user interface. Much as I'm keen to have FF3, that's a shame. we will only need to worry about finishing front end changes for getting microformat support into the next release. By next release, do you mean 3.0.1 (or some such) or 4.0? -- Andy Mabbett ** via webmail ** ___ 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] 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
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 UI in Firefox 3
are you saying that the blogger/webmaster is deciding the actions rather than fx3 or an Operator like extension. No, the browser should still act as a mediator between data and applications, otherwise people will tie there information to particular apps (like what is currently happening with RSS and podcasts). This results in a lot of problems, like a complex UI, lock in, content creators having to regularly update their sites, etc. However, I understand your confusion, the fact that there are multiple actions that can be applied to an hCard messes up my example. What if we agreed on some basic default application types (map, calendar, address book, etc.), and so the example would then have two actions (assuming they both made sense in context): div class=user-action-addressBook style=visibility:hiddenAdd to Address Book/div div class=user-action-map style=visibility:hiddenMap/div And third party extensions could register additional user actions (here is a genetics example): div class=user-action-geneSearch style=visibility:hiddenLook up Gene/div -Alex On Aug 28, 2007, at 1:33 AM, Farndon, Tony wrote: Not sure I quite understand this (so a good example of a general 'blogger' wanting to put uf on their blog/site), are you saying that the blogger/webmaster is deciding the actions rather than fx3 or an Operator like extension. Using your example code, would I be required to put in a multitude of actions at the webpage level: div class=user-action style=visibility:hiddenAdd to Address Book/div div class=user-actionB style=visibility:hiddenView Address in Google Maps/div div class=user-actionC style=visibility:hiddenView Address in Yahoo Maps/div div class=user-actionD style=visibility:hiddenAdd to some Address Book Website/div Then, along comes another web service/app and I have to go back and add another user agent to all my previously marked-up uf div class=user-actionE style=visibility:hiddenAdd to some other Address Book Website/div A bad analogy, but is this not slightly akin to target=_blank which imho is wrongly taking the decision of the browser/user away and forcing it upon them? 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Nested Microformats and Operator
Should there be a way for people to have this information but not make it available as a vcard or vevent? The user-action class or new protocols proposed in the Firefox 3 thread could address this problem (10 hCards in an hResume). Since these pieces of microformatted content probably would not contain a user-action (or link with a particular protocol), the browser would not expose them to the user. -Alex On Aug 27, 2007, at 7:14 PM, Mike Kaply wrote: I wanted Jason to bring this up on the list because it is an interesting discussion. We display lots of stop in Operator (especially in hResume) that can't actually be used. hCalendars for experience are interesting, but unuseful as hCalendars. And hCards for my employment at a past employer aren't terribly interesting either. Should there be a way for people to have this information but not make it available as a vcard or vevent? Mike On 8/27/07, Jason Calabrese [EMAIL PROTECTED] wrote: I've recently started to look into using some microformats on one of my projects and have been playing with Operator to get an idea of how they are being used elsewhere. Operator is a great way to see what microformats are contained on a page, but I think it might confuse the average user when a page contains a lot of nested data using core microformats such as hCard, adr, hCalendar, etc. For example on a LinkedIn public profile: http://www.linkedin.com/in/steveganz You see 1 hResume, 1 adr, 10 hCard's, and 7 hCalendar's. In this case all the hCalendar events are from the experience part of the resume. I don't see any use for adding these to Google Calendar or exporting them. Also 9 of the hCard's wouldn't make sense to export or add to Yahoo Contacts since they contain only very basic information. An other example is a Google Maps search. In this case each result produces a hCard and contains an adr. Ideally these would be combined and shown as Contacts with addresses. Then each contact could be exported or viewed in Google or Yahoo maps. Have these types of issues been discussed before? Is there a way that a user script can hide nested data? I understand the value of reusing the core microformats and creating composite microformats. I think that in many cases users will want to interact with the primary composite format while still preforming actions based on the nested content. ___ 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] Microformats UI in Firefox 3
Instead of having to checking whether the userAgent is right or
wrong in my javascript - wouldn't it be possible to check for the
presence of any hCard-related function instead?
Yeah, if we wanted to solve this problem with javascript, that is
probably what we should do. But I'm a little weary of requiring
javascript for exposing microformatted content to browsers due to it
commonly being blocked on most wikis, and it potentially being
unfamiliar to content creators.
Perhaps a good compromise would be to just break backwards
compatibility on wikis, since they can't use javascript to figure out
if the action is going to actually work.
There are really two separate issues here:
1) backwards compatibility
-navigator.userAgent
-style=visibility:hidden hack
-if (navigator.microformatAware(hCard)){document.write( )}
2) instructing the browser to take action on a piece of data
-user-action-app class
-protocols
-third solution?
Couldn't another solution be to add some kind of a protocol?
The general uf:// protocol wouldn't distinguish what the user wants
to do with the content (for instance, hCards could be sent to an
address book, or a map). So this might result in some really
implementation-level UI, like links that say Send hCard to your
Browser.
We could create protocol handlers for each generic application type
(map://, addressBook://, calendar://). The only thing that seems a
little unusual is that normally content creators would expect to send
the data by value instead of my reference, for instance:
mailto://[EMAIL PROTECTED] is the subject?body=this is
the body
(although I'm not really sure how commonly known this is)
Like uf://foobar.com/foo.html#bar-hcard Firefox could process such
a link by extracting the hcard with the id bar-hcard
I do like really like the idea of being able to reference
microformats elsewhere on the page, or on any other page. Something
else that makes this is a little unusual is that the browser may not
get a 404, but the data is still missing. Also, since the
information is still being transported using http, using a new
protocol in the URI would be technically inaccurate.
This design might encourage people to reference information instead
of duplicating it. I honestly don't know if that is a good thing or
a bad thing.
One potentially major problem: if you change the scheme from http,
you can't have a relative URI, you have to create an absolute one:
Relative URI references are distinguished from absolute URI in that
they do not begin with a scheme name. Instead, the scheme is
inherited from the base URI
http://www.ietf.org/rfc/rfc2396.txt
This could be a problem for content creators because in most cases
they would want to reference the microformat they are currently in,
but they may not know what its URI is going to end up being, or they
don't want to take the time to figure it out. It would also be
impossible for creators (like the hCard creator) to know what the URI
is eventually going to be.
I think overall using protocols is conceptually simpler, because what
you are creating is in fact a hyperlink. But what we would need is
relative URIs with different schemes, maybe something like:
a href:map:#the-idMap/a
Unfortunately this twists the definitions of relative and
absolute. It's likely that other people from Mozilla (or on this
list) won't be too fond of breaking a bunch of RFCs from the 90s.
What do other people think about using protocols for microformat
handling?
-Alex
On Aug 27, 2007, at 10:54 PM, Pelle W wrote:
Alex Faaborg skrev:
This is a bit of a hack, but it is also considerably easier than
asking the author to write javascript to check
navigator.userAgent, know which browsers handle microformatted
content (and subsequently update this as it changes), and then
display the link accordingly. Also, I'm interested in allowing
user generated microformatted content to be added to blogs and
wikis where javascript is not commonly allowed.
A bit of friendly fedback here, not saying that I would be right at
all only sending out some thoughts that may be useful or may be
garbage.
Instead of having to checking whether the userAgent is right or
wrong in my javascript - wouldn't it be possible to check for the
presence of any hCard-related function instead? This way it would
at least be theoretically possible for any web browser to add such
a function, either officially or through a third party plugin, and
so trigger the website to view the possible actions.
It seems a bit unusual to me to have a class like user-action
which the browser should find and change to visible and make a link
out of or something. Couldn't another solution be to add some kind
of a protocol? Like uf://foobar.com/foo.html#bar-hcard Firefox
could process such a link
Re: [uf-discuss] Microformats UI in Firefox 3
I've understood that it's inserted by the web developer to enable him/her to implement the Microformat-actions in their own designs and it's suggested that the class user-action should be used to indicate that something is meant to be a link to such an action. Yes, while previous Firefox designs have focused on the browser injecting UI into the page, this discussion is about how the content creator should provide links and buttons for acting on microformatted content. Another problem might be that the browser will be changing the visibility property because that disables the designer from turning of the action-div's visibility. For example - the designer wants the action-button/link to only be shown when you hover over the hCard it's connected to, therefor the designer hides it by setting the visibility property to hidden and changing it upon hover. If the browser then changes the visibility the design won't look like it was intended to. Yeah, that's a good point. -Alex On Aug 28, 2007, at 4:53 AM, Pelle W wrote: André Luís skrev: One thing I need someone to clarify: Is that div.user-action inserted by the user-agent, in this case, Firefox 3? Or do the authors have to include that code on their pages? This wasn't very clear to me... I've understood that it's inserted by the web developer to enable him/her to implement the Microformat-actions in their own designs and it's suggested that the class user-action should be used to indicate that something is meant to be a link to such an action. On 8/28/07, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Alex Faaborg [EMAIL PROTECTED] writes The last class is new: div class=user-action style=visibility:hiddenAdd to Address Book/div The text Add to Address Book is hidden by default, unless the browser (or an extension) recognizes user-action ...or unless the user agent has no CSS functionality available. Is that degrading gracefully? What I don't understand in thate example is that the user-action is applied onto a div which doesn't contain any links or buttons. An action is most often initiated by clicking on either a link or a button. Will the browser add such a control? If so the control over the design won't be completely handed over to the designer which it should be. Another problem might be that the browser will be changing the visibility property because that disables the designer from turning of the action-div's visibility. For example - the designer wants the action-button/link to only be shown when you hover over the hCard it's connected to, therefor the designer hides it by setting the visibility property to hidden and changing it upon hover. If the browser then changes the visibility the design won't look like it was intended to. If a class is to be used it should only connect an action and not add anything or change anything about the site. / 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
Re: [uf-discuss] Microformats UI in Firefox 3
Perhaps instead of new classes and protocols, we could just do this
completely in javascript. Here is a general example, probably all
the function names would end up being different:
div id=hcard-Alex-Faaborg class=vcard
span class=fnAlex Faaborg/span
div class=orgMozilla/div
div class=adr
div class=street-address1981 Landings Dr. Building S/div
span class=localityMountain View/span
,
span class=regionCA/span
,
span class=postal-code94043/span
script type=text/javascript
if (navigator.microformatAware(hCard)){
document.write(a href='#' onclick='navigator.sendToAddressBook
('hcard-Alex-Faaborg')'Add to Address Book/a);
document.write(, )
document.write(a href='#' onclick='navigator.sendToMap('hcard-
Alex-Faaborg')'Send to Map/a);
}
/script
/div
It seems you'll still need a way for the browser to inject UI for
actions the content creator didn't foresee.
We can include these actions on context menus, and in the browser UI
(similar to Operator's interface). However, I'm not sure content
creators would be too happy with Firefox modifying their pages by
literally injecting UI.
-Alex
On Aug 28, 2007, at 6:37 AM, Scott Reynen wrote:
On Aug 28, 2007, at 6:33 AM, Alex Faaborg wrote:
Yes, while previous Firefox designs have focused on the browser
injecting UI into the page, this discussion is about how the
content creator should provide links and buttons for acting on
microformatted content.
It seems you'll still need a way for the browser to inject UI for
actions the content creator didn't foresee. And for that you'll
need to know 1) whether a given action is already labeled by the
content creator, 2) where to put it if it's not, and 3) what to do
with actions the content creator labels but Firefox doesn't
understand. For #1, each action will need a unique identifier.
URLs make good unique identifiers on the web, and could point to
somewhere useful (#3), removing the need for hidden content. For
#2, it might be useful to have something like class=put-actions-
here. I'd suggest something like this:
ul class=user-actions
lia href=http://mozilla.org/add-to-address-book/; rel=user-
actionAdd to Address Book/a/li
lia href=http://random-website.org/crazy-unknown-action/;
rel=user-actionDo Something Crazy/a/li
/ul
So if Firefox has two actions it could apply to a given hCard, it
could do something like this:
1) find where the content creator wants user actions inserted,
ul.user-actions
2) check all a[rel=user-action] for already-labeled actions
3) compare those against available actions and update UI accordingly:
3a) the action identified by the URL http://mozilla.org/add-to-
address-book/ is already added and available, so update the link to
point to the action rather than the identifier
3b) the action identified by http://maps.google.com/firefox/add-to-
map/ is available but not added, so add the action with default label
3c) the action identified by http://random-website.org/crazy-
unknown-action/ is added but not available, so offer a prompt to
install the new action
Peace,
Scott
___
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 UI in Firefox 3
My apologies if I'm reopening a long closed debate, I'll be sure to review the wiki page. Side A: Publishers should be able to specify UI elements for their Microformatted content in their HTML. Side B: The browser should be solely responsible for injecting UI into the page I should note that people inside Mozilla have argued these two sides as well. I'm personally in favor of A, or B if it is represented as a modal overlay. It is important that the Firefox developers not only think of Microformats, but eRDF, RDFa, and other semantic markup technologies that are coming down the pipeline. Yeah, it would be great if whatever solution we came up with scaled across different semantic markup technologies. The latest version of Operator now supports eRDF and RDFa. -Alex On Aug 28, 2007, at 8:09 AM, Manu Sporny wrote: Alex Faaborg wrote: Yes, while previous Firefox designs have focused on the browser injecting UI into the page, this discussion is about how the content creator should provide links and buttons for acting on microformatted content. I'm probably being a bit dense, but it looks like we're entering into a philosophical debate. Without taking sides, it looks like the philosophical rift is this: Side A: Publishers should be able to specify UI elements for their Microformatted content in their HTML. Side B: The browser should be solely responsible for injecting UI into the page? This debate has been tracked on the wiki: http://microformats.org/wiki/audio-info- issues#Historical:_Graphic_buttons_in_rel-patterns The current resolution is to leave implementation for user actions up to the browser and uF plug-ins. Without going into the nasty details, which are fully documented on the wiki, there is opposition to directly specifying UI through uF markup. Microformats are about data, not UI. That being said, if there is a desire to add generic UI actions to any sort of semantic data (keep in mind eRDF and RDFa), the one idea that seems to be most compatible with Microformats are about data but able to give the publishers of any semantic data some control over the UI is the uf:// protocol idea. Perhaps a generic set of actions that are defined by all semantic data communities (uF, eRDF, RDFa, etc.). The assumption is that some sort of ID mechanism is utilized. So for data like this: div id='alex-faaborg' class='vcard'.../div Something like the following: a href=action://addressbook/add/alex-faaborgAdd to address book/a a href=action://addressbook/mail/alex-faaborgE-mail Alex/a Here are some other examples: action://map/find/eiffel-tower action:// The above mechanism would allow people to specify default behaviors for actions. Some could specify that action://map/ is handled by Yahoo Maps, while others might choose Google Maps or Microsoft Streets and Trips. It is important that the Firefox developers not only think of Microformats, but eRDF, RDFa, and other semantic markup technologies that are coming down the pipeline. -- manu ___ 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 UI in Firefox 3
Sorry for the long delay in posting an update to this thread, we are still working on finalizing the UI for interacting with microformats in Firefox. Here is something Mike Beltzner, Mike Kaply and I have been considering for microformat handling in Firefox 3, in terms of the content area. We would like to propose a way for content authors to add actions to their microformats, without having to worry about backwards compatibility. For instance: div id=hcard-Alex-Faaborg class=vcard span class=fnAlex Faaborg/span div class=orgMozilla/div div class=adr div class=street-address1981 Landings Dr. Building S/div span class=localityMountain View/span , span class=regionCA/span , span class=postal-code94043/span div class=user-action style=visibility:hiddenAdd to Address Book/div /div The last class is new: div class=user-action style=visibility:hiddenAdd to Address Book/div The text Add to Address Book is hidden by default, unless the browser (or an extension) recognizes user-action, in which case the text is rendered as a hyperlink, and clicking it sends the structured data in the hCard to the user's address book. user-action is just an example of what we could call this class, it seemed to make sense. Also instead of a hyperlink the author could use an image, like Wolfgang's icons (http://factorycity.net/projects/ microformats-icons/). This is a bit of a hack, but it is also considerably easier than asking the author to write javascript to check navigator.userAgent, know which browsers handle microformatted content (and subsequently update this as it changes), and then display the link accordingly. Also, I'm interested in allowing user generated microformatted content to be added to blogs and wikis where javascript is not commonly allowed. Since this is something we are thinking about for microformat handling in Firefox 3, we would really like to get feedback from the uF community before we consider implementing it. -Alex On Aug 1, 2007, at 11:40 AM, Alex Faaborg wrote: Mike Beltzner, Mike Kaply and I are going to try to finalize the user interface for interacting with microformatted content in Firefox 3 this week, possibly later today. If anyone has any last minute suggestions or thoughts, please post them soon. I'll also update this thread with mockups of what we've decided on so we can get feedback on the proposed interface. -Alex ___ 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 metadata no microformats
One question invisible metadata raises is if it's not worth seeing, why is it worth publishing? I can imagine Web designers wanting to associate invisible metadata with a button (that says Add to Calendar or Map), so that a microformat aware Web browser would detect the metadata and register down clicks on the button as acting on the metadata. This information would likely appear elsewhere on the page (probably also using microformats), but the button provides a visual affordance for the action. In our current designs, we are considering changing the mouse cursor when the user hovers over microformatted content, but that doesn't present the user with any indication that they can act on the data until after they have moved the mouse over it. So in this particular case, I think leveraging invisible metadata makes the interface more usable overall. -Alex On Jul 2, 2007, at 11:41 AM, Benjamin West wrote: http://tantek.com/log/2005/06.html#d03t2359 Principles of visibility and human friendliness. One question invisible metadata raises is if it's not worth seeing, why is it worth publishing? -Ben On 6/30/07, Andy Mabbett [EMAIL PROTECTED] wrote: Several editors on Wikipedia are calling for the modification of the templates which implement microformat, to use hidden metadata. I thought there was a prohibition on hidden metadata in the specs, or at least somewhere on the wiki, but all I Can find now is: visible data is much better for humans than invisible metadata on: http://microformats.org/wiki/ microformats#the_microformats_principles Can someone remind me what I'm missing, please? -- Andy Mabbett ___ 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] microformats for normal people, like my mum
They imply opening or saving a completely separate document/file The interface model doesn't necessarily have to actually match the implementation model, but yeah, I'm still not a huge fan of the attachments idea. Some other interface specific names I've been thinking about Pointers for: http://tinyurl.com/278y8g Hyperlayers for: http://tinyurl.com/26mqf3 (or layers for short) Both of those names have previously been shot down inside Mozilla, ironically enough because some people felt that the interface-level name should emerge out of the microformats community. In the past Web browsers have lagged far enough behind the evolution of the Web that names have already been established (like with Feeds). -Alex On Jun 29, 2007, at 12:04 AM, Joe Andrieu wrote: Alex, I would suggest that attachments are definitely a bad idea. They imply opening or saving a completely separate document/file and are, as you state, danger waiting to happen. LiveData HyperData SmartData WebData MagicData LiveBits HyperBits SmartBits WebBits MagicBits Bits being a combination of both bits/bytes and tidbits. Someone somewhere is going to name this thing. It might be a journalist. It might be FF. It could be a blogger. The idea that there is data embedded in a web page that the browser can consistently interact with beyond the hyperlink is new. Especially when that embedding and the interactions are consistent across many many webpages, but not all web pages. Users will name it something. I think people understand data but rarely have a need to speak of data generally--we talk about contacts or events or people or reviews. But when my brain is full: it's got too much stuff. Too much data. I think people get that. Data is generalized digital bits in some way that's useful. hCards, hCalendars, GEO, XFN and other uF or POSH generalize to data. Semantic data. Of course, bookmarks were a pretty innovative metaphor. Perhaps there is something completely different that works. Maybe something from tidbits. Or morsels... Anyway, good luck. I expect you might have more luck with the FF crew. -j -- Joe Andrieu SwitchBook Software http://www.switchbook.com [EMAIL PROTECTED] +1 (805) 705-8651 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Faaborg Sent: Thursday, June 28, 2007 11:40 PM To: Microformats Discuss Subject: Re: [uf-discuss] microformats for normal people, like my mum I've been giving some thought to framing microformatted content as attachments, along with a little paper clip icon. This would resonate with users who are familiar with email, but on the downside, a lot of people have been trained that attachments=danger. -Alex On Jun 28, 2007, at 11:29 PM, Pelle W wrote: Paul Wilkins skrev: From: Alex Faaborg [EMAIL PROTECTED] | Mozilla's user experience team is going to continue brainstorming the best way to expose microformat detection to end users, along with the rest of the mozilla community. I'll post updates to this list from time to time, and it will be interesting to see what interfaces and names other people come up with as well. The RSS feeds are accessed in the browser through the feed button. So it makes sense that the microformat data should be accessed through the data button. I do like data, it's concise and is easy to explain. Q: What kind of data can I get from the data button? A: Contact details, calender entries, geographic locations, . . . Q: Does the data button always get the information? A: No, only when the page author has specially marked out those parts of the page. Data sounds good but since RSS also is data the RSS-feed should perhaps be reached from below the data-button to emphasize the similarities. / Pelle ___ 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
Re: [uf-discuss] microformats for normal people, like my mum
couldn't it rather be a description of an action - like data extraction? Yeah, maybe just name the button/menu Send Data. I think the sending is probably more important than the extraction. -Alex On Jun 29, 2007, at 1:19 AM, Pelle W wrote: Alex Faaborg skrev: They imply opening or saving a completely separate document/file The interface model doesn't necessarily have to actually match the implementation model, but yeah, I'm still not a huge fan of the attachments idea. Pointers for: http://tinyurl.com/278y8g Hyperlayers for: http://tinyurl.com/26mqf3 (or layers for short) Those names sound very catchy - but in my ears perhaps a bit too much like something coming from a classic PR-campaign. At least Hyperlayers - image an ad with the text Increase your productivity with the all new Firefox 3 now with hyperlayers. Very cool - but does it actually tell us something? Can't it be kept simple? Does it have to be a new name - couldn't it rather be a description of an action - like data extraction? (Don't know if thats the right spelling though) That would tell what it does and it would be less PR-like and more honest(?) - it's just plain simply describing what this new thing does and that's what I think is most important. Keep it simple. Both of those names have previously been shot down inside Mozilla, ironically enough because some people felt that the interface- level name should emerge out of the microformats community. In the past Web browsers have lagged far enough behind the evolution of the Web that names have already been established (like with Feeds). Well - that is ironic :) Perhaps the real place for this would be among the comments on a YouTube-movie featuring this in action or in blogosphere? But that does however not stop us from having this discussion... / Pelle ___ 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 for normal people, like my mum
Therefore, uFs don't need a user-facing name - their applications do. Right, we need a general user facing way of describing microformat detection, in order to describe the various applications (like Web browsers, feed readers and extensions like Operator) that let the user take actions on microformatted content. For instance, this description would finish the sentence features of Firefox 3 include support for offline Web applications, private browsing, blocking malware, and __[user facing way of saying microformat detection]__ ...data detection? ...semantic browsing? ...data browsing? ...semantic data detection? ...semantic data browsing? ...semantic data navigating? If Operator and Firefox 3 are in a category of uF enabled applications, what should that category of applications be called? Or another way of putting it: Feed Readers :: RSS __ :: microformats -Alex On Jun 28, 2007, at 2:39 AM, Frances Berriman wrote: On 28/06/07, Pelle W [EMAIL PROTECTED] wrote: On 6/27/07, Tara Hunt [EMAIL PROTECTED] wrote: Although I heart the idea of language for non-experts, I'm wondering how public facing Microformats, as a general term, is. I've thought about this before...I can see the specific microformats, like hCard and hCal and hReview being public facing...and, in reality, these are pretty descriptive. Maybe they just need some sort of iconic marker (like RSS has)...which I think has been attempted before. I agree with Tara here. Microformats is interesting for developers because it tells us in what way the solution works but for my mum it would tell nothing. My mom knows however what an address is and what a calendar is and because of that it's the microformats in itself that should be given common names like web feeds for RSS. I don't know but have XML been given a humane name yet? Because XML is to RSS what Microformats is to hCard. I concur on this line of thinking. Microformats are the technological name - my mum should never have to come across the term any more than she should have to come across the term XML. I think Operator does a good job of hiding the term in that it simply shows what you can actually do with data in the page (add this to my google calendar etc.). Therefore, uFs don't need a user-facing name - their applications do. If Microformats should be given a more humane name then that would be something about semantics. Semanticdata perhaps - but it wouldn't make anyone happier I think because the only ones who would be interested would be those who already knows what Microformats is. As far as talking about Microformats under one banner, I don't know if the distinction really needs to be made. i think that may be what POSH was trying to say: use plain old semantic html...but even that is talking to developers and advanced content producers. I've said it before, but I don't think there's any need to reiterate what semantic HTML for is via *another* name, for developers. POSH is bad enough. -- Frances Berriman http://fberriman.com ___ 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 for normal people, like my mum
One reason to consider having both an implementation-level name and an interface-level name: Mozilla has had multiple inquiries from reporters in the mainstream media who wanted to cover microformats in stories about the future of the Web browser, but they then later backed out because they felt the term microformats would only appeal to developers, and not the average reader. Also, from a user interface design perspective, we really shouldn't expose implementation-level terminology to end users. -Alex On Jun 28, 2007, at 4:35 AM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Alex Faaborg [EMAIL PROTECTED] writes this description would finish the sentence features of Firefox 3 include support for offline Web applications, private browsing, blocking malware, and __[user facing way of saying microformat detection]__ ...data detection? ...semantic browsing? ...data browsing? ...semantic data detection? ...semantic data browsing? ...semantic data navigating? data extraction Though it strikes me as odd that we expend efforts trying to raise brand awareness for microformats, then start top discuss renaming them... We should think long and hard about whether that's a good idea. -- Andy Mabbett ___ 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 for normal people, like my mum
Probably none of us here is the right ones to decide something like this... Fair enough, several other people have made this point as well. We are always open to feedback about microformat detection in Firefox 3, so if anyone has any comments, please feel free to post them to this list or email me directly. FF3 perhaps shouldn't call it something The menu which contacts, addresses and locations are listed under will need some form of name. Also, journalists will probably want a feature name in press briefings and when they make product comparison tables, etc. We aren't likely to call it SuperHyperMetaMagic, but we are going to need to call it something. Everybody can choose their own name and it will - by the power of web 2.0 which microformat is very much a part of - become a good word in the end. Mozilla's user experience team is going to continue brainstorming the best way to expose microformat detection to end users, along with the rest of the mozilla community. I'll post updates to this list from time to time, and it will be interesting to see what interfaces and names other people come up with as well. -Alex On Jun 28, 2007, at 12:24 PM, Pelle W wrote: Ryan King skrev: On Jun 28, 2007, at 6:13 AM, Frances Berriman wrote: On 28/06/07, Thom Shannon [EMAIL PROTECTED] wrote: Exactly! We need a brand and a website that introduces people to the concept, tells them where to get the plugins or the right browsers and possibly encourages them to put pressure on their web guys to implement them, Want x's on your site? Then use Microformats I think better encouragement would come from putting energy into creating tools, plug-ins, examples and tutorials for those people - rather than trying to re-brand something that's already something else re-branded. I couldn't agree more. I think this discussion is rather unproductive for this community. Just build the tools, design them well and get people to use them. If you never use the word 'microformat' in your application, that's fine. No harm, no foul, no need to build a new brand. To use a cool name for this - do it web 2.0 - we as a relatively small group of which I'm relatively new can't decide what people will call this and FF3 perhaps shouldn't call it something. Everybody can choose their own name and it will - by the power of web 2.0 which microformat is very much a part of - become a good word in the end. Probably none of us here is the right ones to decide something like this... / Pelle ___ 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 for normal people, like my mum
Off topic slightly: given that FF3 will (may?) have native support for microformats, will Thunderbird? The thunderbird developers have been asking about microformats, so they are definitely looking into it. Previous discussions have been about hCard, but other formats could of course be sent in HTML emails as well. Mozilla is adding microformat detection to our rendering engine, so any Gecko-based Web browser will be able to leverage our microformat parsing (Camino, Flock, etc.) -Alex On Jun 28, 2007, at 8:06 AM, Rickards, Julian (NDM) wrote: Off topic slightly: given that FF3 will (may?) have native support for microformats, will Thunderbird? -Original Message- From: Thom Shannon yes, it's a thing, it's different. FF3 can't just add any address you see to your address book, its a specific kind of address that just looks the same, and you need a browser or plugin or something that understands that specific thing ___ 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 for normal people, like my mum
I definitely agree that the microformats community should consider a user facing name. Similar to how RSS is exposed in Firefox to the user as Web Feeds and microsummaries are exposed to the user as Live Bookmarks, microformat detection in Firefox 3 is going to need a name. What does everyone think it should be called? -Alex On Jun 27, 2007, at 4:04 PM, Charles Iliya Krempeaux wrote: Hello Thom, On 6/27/07, Thom Shannon [EMAIL PROTECTED] wrote: [...] Just an idea, but maybe we could have a secondary name, and an end user facing site showing what you can do with these things. We could call it: Intelligent Web Pages or Smart Web Pages Web pages that are intelligent enough or smart enough to do stuff :-) -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ All the Vlogging News on One Page http://vlograzor.com/ ___ 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 for normal people, like my mum
I'm a little wary of associating microformats too closely with Smart Tags or IntelliSense given the massive public outcry Microsoft received when they considered including the feature in IE6. There are obviously some very important distinctions between the two systems, (microformats are open and extensible, and web site creators place microformats in their pages instead of the browser injecting them). But these distinctions may be subtle enough to cause some initial confusion if the user facing name is similar. -Alex On Jun 27, 2007, at 4:52 PM, Thom Shannon wrote: Yeah, exactly that kind of thing. A lot of the power of MF reminds me of Smart Tags in Office XP, maybe we could look to the way that was marketed and some of the UI stuff it did was really good. IntelliTags Infolets Infobits Open Smart Tags? ;-) Charles Iliya Krempeaux wrote: Hello Thom, On 6/27/07, Thom Shannon [EMAIL PROTECTED] wrote: [...] Just an idea, but maybe we could have a secondary name, and an end user facing site showing what you can do with these things. We could call it: Intelligent Web Pages or Smart Web Pages Web pages that are intelligent enough or smart enough to do stuff :-) ___ 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 for normal people, like my mum
For me, the question is what does the non-developer end-user perceive when they see the SmartData icon? How does that relate to their world? It isn't about the formatting or the HTML tags... Those are things that end-users don't really care about or even conceptuallize. In case anyone is curious what is going on with microformat UI design for Firefox 3, we are considering presenting microformatted content to the user with an icon in the location bar, similar to RSS (and possibly RSS and microformats will be grouped into a more generic send data to application icon, which was brought up in a different thread on microformats-discuss): http://people.mozilla.com/~faaborg/files/20070204-detectionUI/ locationBarMenu.jpg_large.jpg Additionally, when the user hovers the mouse over an area of the page that contains microformatted content, we will change the cursor to display the associated application (or a generic icon if no default has been selected): http://people.mozilla.com/~faaborg/files/20070426-detectionUI2/ cursorChange.jpg The mouse cursor change will also hopefully apply to file types and protocols (mailto:, webcal:, etc.) I've thought about this before...I can see the specific microformats, like hCard and hCal and hReview being public facing...and, in reality, these are pretty descriptive. In our designs we avoid showing the user the microformat name, and focus on the associated application. Instead of seeing geo or adr the user will only see Google Earth (or a generic picture of a globe if they haven't chosen an application yet, probably on microformat green). Due to privacy concerns the browser can't expose the user's default applications to Web sites, so I think Web developers should be encouraged to design based on actions, not data. A green button that says Send to Calendar is considerably more useable than a green button that says hCal (actually these are often red for some reason, http://microformats.org/wiki/icons). Also, I personally think Web designers should be encouraged to use images instead of acronyms. In addition to being more descriptive, they localize better. Here are some I've been showing in various talks: http://people.mozilla.com/~faaborg/files/20061213-fundamentalTypes/ fundamentalTypesStatic.jpg_large.jpg -Alex On Jun 27, 2007, at 6:14 PM, Paul Wilkins wrote: From: Tara Hunt [EMAIL PROTECTED] Personally, I'd love it all to be invisible and have more tools for non-expert content producers to input plain text into stuff that spits out properly marked up pages and other tools (like browsers and plug ins and sites) that consume these well-marked up pages properly. This means that the tools people use to create their web pages will need to provide a mechanism for them to add microformat data to their content, without necessarily having to dig into the code. So, first steps. Select an area of text to be used as an hCard and click an hCard button When an hCard area of text is defined, buttons become available to define different sections Select text to be the persons name and click a name button - if the name appears to be parsable as a fn, ask if the given name is one of a series of example formats - if the name isn't a correct format, let them pick and choose which parts are what Select phone number and click a phone number button - if an appropriate type is not included with the selected phone number, but one is nearby, ask if that should be included as the type It should look like magic. What's that Arthur C. Clarke quote about technology and magic? it's not rocket science that we're doing here, it's tougher - usability for the masses. -- Paul Wilkins ___ 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] geo in Firefox 3 (as: Microformats gets strong showing in Firefox 3 UI)
The problem with geo is that it is horrible to show in a UI Mike: I think we should still try to support geo. Exposing the user to geographic coordinates isn't ideal, but I think that it is considerably better than hiding the action entirely. I've been talking to Mike Beltzner (UX lead at Mozilla) about microformats UI over the last week, and we are now considering a UI similar to the one Pelle proposed (http://pelle.vox.nu/koncept/ locationBarMenu_pelle_small.jpg), in addition to the mouse cursor change. Regarding the mystery meat navigation concern: I think this is fair, but I would say it is the web site's fault instead of the browser's fault. I think web sites should be encouraged to add UI elements for the user to click on to invoke an action on a microformat, similar to the RSS icons and links that currently appear on web sites. The reason we are changing the mouse cursor is because that's the only part of the UI we control in the content area, we really can't start injecting affordances. We are also thinking about using the cursor change for other types of content handling, like links with specific protocols (mailto:, webcal:, etc.) and files that will either download or launch a particular application. So this UI is not specific to microformats, but content handling in general. -Alex On Jun 7, 2007, at 2:00 PM, Colin Barrett wrote: It would be nice though, to be able to take something marked up with geo and have it generate KML and get handed off to Google Earth or to have it open up Google Maps (with the web-app content handler stuff in the WHATWG webapp proposal). -Colin On Jun 7, 2007, at 11:04 AM, Mike Kaply wrote: The problem with geo is that it is horrible to show in a UI. The microformat only specifies a lat/long (no title) and there is no guarantee there is anything interesting to show in the UI. For a typical end user, geo just doesn't make a lot of sense. It's a geek feature. You will be able to add geo support similar to how Operator works, with a user script. Mike On 6/7/07, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Mike Kaply [EMAIL PROTECTED] writes 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. Why only maybe geo? I think there is a strong case for including geo, especially once KML and GPX export are available. Where is this being discussed, and how is it best to make one's views known, or to vote? -- Andy Mabbett ___ 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
Re: [uf-discuss] Microformats gets strong showing in Firefox 3 UI
The visual presentation is an affordance that tells users that clicking on it navigates. Without the blue underline, you are back to the mystery meat navigation. I certainly agree that the interface for interacting with microformats in the context of the page would be considerably easier to use with a visual affordance, but we should probably leave these visual affordances (buttons, etc) up to the Web designer. If Firefox were to proactively detect microformats and then modify the appearance of the page, that is a line that Web browsers usually don't cross. Of course we have certainly considered doing this, here is a pretty complete list of all of our design mockups that people might find interesting: http://wiki.mozilla.org/Microformats/UE/ideas We are still in the design phase for this feature, and looking for lots of feedback and ideas. Changing the mouse cursor is currently my favorite design, but we are completely open to new ideas. -Alex On Jun 6, 2007, at 1:13 AM, Joe Andrieu wrote: Colin Barrett wrote: On Jun 5, 2007, at 10:57 PM, Paul Wilkins wrote: Strictly speaking it isn't MMN because navigation itself isn't involved. The problems surrounding the cursor change though are identical. If it is the only mechanism to find microformat content, it won't be found until someone chances across it if they notice it changing when it crosses such content. I was thinking about this, and I wonder -- how did people learn the behavior that you can click on a blue, underlined piece of text? Think about a pre-web world where nobody knew what hypertext was. People needed to figure out somehow that you could click on links to make them activate. Enter, the hand cursor. If you think about it, it tells you nothing about what's actually going to happen when you click -- instead, it looks like someone about to click the mouse, so I suppose it's inviting for people to mimic the gesture? This still doesn't answer the question of how people would discover this. My guess is that people scan the page with their mouse as they read. I know I do that sometimes. Anyone have actual evidence? Perhaps we don't need to worry about discoverability of microformats further than just changing the cursor, after all. Blue hyperlinks are an idiom, which, once learned, was easy to understand. However, they are far more than just the hover effect on the cursor. They are /also/ blue and underlined. Let's not under value the importance of that. The visual presentation is an affordance that tells users that clicking on it navigates. Without the blue underline, you are back to the mystery meat navigation. Even today, if the text isn't blue underlined, it better have some other affordance for me to understand it's a link. IMO, cursor effects should /support/ affordance, rather than being the primary indicator. The visual presentation should show that something special happens and then the cursor effect confirms it. My gut instinct for Firefox is that we probably need three steps (1) an RSS-like microformats indicator (2) a way to activate uF and (3) a way for users to then interact with said uF. We might need offer multiple options for (2) and (3), we should certainly consider several. I like highlighting on a page, but that can be annoying and certainly hard to control from the HTML designers perspective. But it could be a glyph appearing near the corner of a uF rather than a full highlight effect around the uF container. Clicking on the glyph or the highlighted section then lets the user interact with the uF in some way. Unfortunately, this messes with the design and potentially puts the user in weird-mode where clicks do abnormal things compared to the non-uF highlighted mode (normal web interaction). I think I prefer the idea of populating a list in a pop-up or sidebar window with all of the uF available on the page. This avoids the problem of design-clash and provides an obvious place for a variety of interaction capabilities, like a right-clight to select an application to send the uF to. -j -- Joe Andrieu SwitchBook Software http://www.switchbook.com [EMAIL PROTECTED] +1 (805) 705-8651 ___ 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 gets strong showing in Firefox 3 UI
Hey, I'm working with Mike Kaply on microformat support in Firefox 3, and I would love to get feedback from this group on the user interface design. To answer a few questions that have been raised in this thread: if you could tell me the correct place to let the Mozilla folks know about this - they should be careful about changing the cursor for a microformat - sometimes an hCard, for example, will be the whole page Yeah, Mike Kaply and I have been thinking about edge cases like this. One possible solution would be to create some heuristics for determining if a microformatted content area is too large to change the cursor, and also provide a way for Web sites to directly control if the cursor changes or doesn't change. I'm still waiting for someone to come up with the perfect microformats UI. Changing the cursor isn't perfect, but it is the only way for the browser to provide a visual cue of contextual action without directly modifying the page itself, which is why this is the best solution I have heard so far. I think there are a few things we could do to improve the interface further include outlining the microformatted content on hover (Operator 0.7 and later tried this), and possibly flashing the microformatted content areas on page load. I also like the user interface for viewing tagged sections of images on Flickr: http:// flickr.com/photos/titanium-white/379894665/ If an on-hover cursor change could indicate microformats for mouse- users, how might keyboard access to microformats work? We will need to provide a keyboard interface in secondary UI for accessibility. Overall, microformats are great for accessibility due to the number of steps they eliminate for tasks like adding something to your calendar. The cursor thing could be in addition to other ways (that don't exhibit MMN) of getting at Microformats. The cursor change isn't technically mystery meat navigation, since you can hopefully see what you are hovering over, and the icon of the application that is going to launch is appended to the cursor. However, I have heard this UI compared to a mid 1990s adventure game :) We will likely have some type of interface to view all of the microformatted content on the page, but we haven't decided on what. A rather comprehensive list of various options is here: http://wiki.mozilla.org/Microformats/UE/ideas I hope that the Operator will show the Firefox crew that Microformats isn't clitter. The creator of Operator, Mike Kaply is also writing the microformat implementation for Firefox 3, so technically Operator and the Firefox crew are the same person. In terms of clutter, the right side of the location bar is quickly turning into the equivalent of the Windows system tray: the random place where you stick your extra stuff (locks and RSS icons and microformat icons, etc). As we start to rethink the overall browser UI, we will hopefully find a better place to put these types of notifications. only if the users don't use it it becomes clutter If the user is viewing a page with microformats and RSS through a secure connection, they will have a yellow location bar containing a favicon, lock icon, feed icon, and microformat icon. We are worried that this is too much visual clutter. Options include things like merging the feed icon and microformat icon, taking security UI out of the location bar, moving some of these things to secondary UI, etc. what would clutter Firefox is when it intrudes into my webpage In a lot of cases it is easier to directly interact with information in the page than it is to find it in a menu somewhere. For instance, if you want to map a single item in a list of 100 items, you don't want to do a visual scan for the same item in a menu, you just want to click on it. We are of course going to allow Web sites to provide their own UI for interacting with microformats as well, but I personally think we should provide a good default interface. Discussion of microformat support in Firefox 3 in the Mozilla community is going on here: http://groups.google.com/group/ mozilla.dev.apps.firefox/browse_frm/thread/19660ddf0589e15e/ d600f125dcc8b845#d600f125dcc8b845 -Alex On Jun 5, 2007, at 1:24 PM, Pelle W wrote: 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 also agree with Mike, Paul and others here. I read that someone raised the question about keyboard navigation and the only real
[uf-discuss] The UI of microformat detection
I've posted a variety of conceptual mockups of microformat detection in Firefox 3 to my blog: http://blog.mozilla.com/faaborg/2007/02/04/microformats-part-4-the- user-interface-of-microformat-detection I would love to get some feedback on what designs you think work well, or don't, and if there are any other UI ideas I should be considering. Cheers, -Alex ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Operator: Microformat detection for Firefox 2
Greetings, This is my first message to the list, so to introduce myself, my name is Alex Faaborg and I am a user experience designer at Mozilla working on our microformats strategy for Firefox. Today Mozilla Labs released a microformat extension for Firefox 2 named Operator. The extension was developed by Michael Kaply at IBM, and detects hCard, hCalendar, geo, hReview and rel-tag. You can read more about the extension on the Mozilla Labs blog: http://labs.mozilla.com/2006/12/introducing-operator And you can download Operator here: https://addons.mozilla.org/firefox/4106/ Cheers, -Alex ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
