Previously
Part 0: Introduction to Microformats
Part 1: Structured Data Chaos
Part 2: The Fundamental Types
Part 3: Introducing Operator
Part 4: The User Interface of Microformat Detection
Now that I’ve posted about what microformats are, why the browser should natively detect them, which microformats should be detected, and Mozilla Labs has introduced Operator, it’s time to take a look at how microformat detection could potentially appear in the user interface of a future version of Firefox.
20 conceptual mockups of Gran Paradiso and a wealth of UI discussion and debate after the break…
Technorati Tags: Firefox 3, Gran Paradiso, microformats
Please note that all of these images are only conceptual mockups of Gran Paradiso (the codename for Firefox 3). The final design may be entirely different, or the idea may not be implemented at all. This point is particularly salient since some of the ideas in this post are likely to be controversial. The purpose of these mockups is to explore a variety of different ideas and generate feedback. However, if you are really curious about what Gran Paradiso looks like, some actual images of Gran Paradiso are available here. (note: that photo is geotagged, if you have Operator, check out the satellite view with your favorite mapping application).
This post is pretty long, so if you are short on time you may want to just scroll down and look at the mockups. On most of them you can click through for the full image. Inspiration for many of these designs came from the microformat community.
Integrating Microformat Detection UI into the Browser Chrome
Right now Operator appears as a toolbar, or (with version 0.6.1 and later) in the status bar. There are a number of other places in the chrome that could potentially be used to display the detection of microformatted content:
Location Bar
For instance, a 
icon could appear in the location bar next to the feed icon:
I’ve previously stated that I really don’t want to let the right side of the location bar spiral down into Firefox’s equivalent of the Windows system tray (which after getting a new computer from an OEM is usually inundated with meaningless little device driver icons that blink and flash at you without reason or consequence). At the very least we could integrate all of the detected microformats into a single plus icon to reduce the overall visual complexity:
Note that similar to the design of Operator, microformats are each displayed using the icon of the associated application. In Firefox mockups for Vista, microformatted content is shown paired with a mixture of Microsoft and Google apps. In the mockups for OS X, geo and adr happen to be associated with Google Earth, hCard with Address Book, and hCalendar with iCal, (which are just the apps I personally use). These are just examples, the application associations will be up to the user.
All of these mockups display application icons instead of the generic microformat icons shown in part 2. This is because application icons are more visually unique, they are personalized to each user, and they hold a strong connotation of what will happen when you click on them.
In addition to the fundamental types of microformatted content that are natively supported, these mockups also display microformat detectors added by the user. In this case the user has added Skype, but they could have added something much more domain specific, like an extension that detects human genes, or wines. Some of these third party extensions will detect specific microformats, others could potentially use regular expressions, or detection lists to locate data and associate it with an action. It is important to note that even if we support detection based on regular expressions or detection lists, these would probably all be user-installed extensions. Integrating detection into a single UI is more consistent and usable than than having different interfaces for each data type.
Sidebars
The Content Sidebar
One way to expose microformated content in the browser chrome is with a sidebar:
The idea of a Content sidebar could also improve the user experience of batch downloading media (images, movies, etc.) from the Web.
Sub-Page History
Microformated content that users encounter on the Web should also be stored in history. This information should be searchable, and users should be able to browse their history for particular types of information. There are a variety of cases where this might be useful. For instance, imagine you are searching for apartments across a variety of different sites, and then at the end of the browsing session, you want to send everything you saw to Google Earth:
This mockup also displays an idea for redesigning history that is described in a separate post.
Sub-Page Favorites
What if you could use the same tagging scheme for bookmarks, and saved pages, as well as people, locations and events you encounter on the Web? In this conceptual mockup I have tagged some Web pages related to my upcoming recruiting trip to MIT, but I have also tagged events (my flight to Boston, the career fair), locations (my hotel, the career fair), and people (who I am going to meet while I am there). I am able to very quickly retrieve this data because all of it has been tagged with “MIT recruiting 2007.” In this mockup I am only using Google apps.
The Need for Microformat Detection, In Context
Here are some different ways you may wish to interact with microformatted content you encounter while browsing the Web:
Acting on one item out of a small number of items
Let’s imagine you are reading your friend’s blog post about a concert that is coming up, and you want to add the event to your calendar. Since there aren’t any other events on the page, or only a few other events, you can easily send the event to your calendar using a menu based interface like the one Operator provides.
Acting on all items
You are looking at your credit card statement and are wondering what a few of the charges could be. You send the 117 events to a new layer in your calendar so you can see the bank statement overlaying what you were up to at the time. Again, this is easy to accomplish with a menu interface, it just needs a Send All command. (Getting banks to update their statements for microformats is of course a separate challenge.)
Acting on one item out of a large number of items
You are viewing your company’s online phonebook with 80 entries and want to send a particular coworker’s contact information to your cell phone so you can call her when you are away from your computer. This is difficult with a menu interface because even after you locate the information on the Web page itself, you need to find the same entry in a menu that contains 80 items. It would be considerably easier if you could search the Web page, then click directly on the phonebook entry to send it to your phone. You really need to be able to act on the information in the context of the page.
Acting on a selection of items
You are browsing a Web site for a new apartment, and of the 50 search results returned, 15 of the apartments look like places you could see yourself living. You want to select the 15 apartments and send them to Google Earth to compare their locations. What you need for this scenario is not just the ability to act on information on the page itself, but to command/control-click items to select a subset, and then take action on that subset.
Because of the last two interactions, it would be very useful to display detected microformatted content, in context, on the Web page. However, a Web browser modifying the content area is a little controversial.
Learning From Past Mistakes
With the exception of highlighting search terms in the page, Web browser UI generally doesn’t extend into the content area, except for one time, awhile ago. Before the release of Windows XP, Microsoft was planning to integrate Smart Tags, a feature previously in Office, into Internet Explorer 6. Of course there are several considerable differences between Smart Tags and microformat detection, most notably that content creators are personally adding microformated content to their sites because they want it to be detected. However, from the IE6 Smart Tags fallout, we can learn several lessons about how to more respectfully handle the user experience:
1. Don’t use color
The Web is a big place, whatever color you choose (including purple) is bound to clash.
2. Don’t leverage an existing monopoly in an effort to redirect users solely to properties that are controlled by your particular corporation
Users deserve choice, and application developers deserve an open and extensible platform
3. Don’t take control of the Web page’s presentation away from the Web designer
Web designers should always have total control of what their site looks like. They should be able to stop the browser from overlaying UI on top of their page, or decide to customize the overlays so that they will match the page’s visual design.
The nature of microformatted content creates some additional design constraints:
4. Hyperlinks won’t work very well
Hyperlinks are designed for navigation on words, or short phrases, not for large sections of text. Microformats (locations, events, and contacts), will each contain several pieces of information, and the pieces themselves may already be hyperlinks.
5. Single icons won’t work very well either
Adding single icons (
) to a Web page does not work well because in many cases it is not always clear exactly what information on the page the icon maps to. To avoid ambiguity, the presentation of microformated content needs to rely on area, and not proximity, in terms of the gestalt principles of grouping (PDF link, see page 25 if you are curious). This is also important so that microformat detection appears to be overlaid on top of the Web page, as opposed to injected into the Web page.
Taking these five considerations into account, here are a some conceptual mockups of ideas we’ve been thinking about over the last several months.
So you can note what is being added, here is the page without any overlaid UI.
Modal Designs
First, I proposed the idea of rendering transparent panes of glass over areas of the page that contain microformated content in a mozilla.dev.apps.firefox thread back in August. Note that in these modal designs, the overlays only appear after the user has requested to see microformatted content in the page. In this case by selecting one of the items in the toolbar, or 
. Here is what the panes of glass idea might look like:
This design technically violates the first rule, because the shade of grey created by the transparent pane of glass is a color. Mike Beltzner had the idea that on dark pages these panes of glass could actually produce a light source:
Mike Shaver also proposed shining spotlights on the page, similar to the search in OS X’s system preferences:
If this looks too fuzzy, we could black out the page and then outline the microformatted areas:
Another slightly more wacky idea I had was to literally push the page towards the user in areas that contained microformated content. Ideally, this design would be implemented with graphics acceleration (which may potentially be possible with Cairo). It’s hard to get the whole idea from a static mockup, but imagine the raised sections have blocks behind them that push towards you when you ask the browser to display microformatted content:
Since the user will be launching an application (either online or locally) when sending it microformated content, perhaps we should have a design that is reminiscent of each platform’s UI for application launching. Here is a design that contains visual elements of the dock for OS X Aqua:
And the same design on a black Web page:
One nice thing about the dock is that it is designed to provide strong visual cues regardless of the background image it is superimposed over. In case you are curious how the back of the dock is implemented: the center of the dock is white with a 40% opacity, followed by a single pixel border of white with 50% opacity, followed by a single pixel border of black with 13.5%(ish) opacity.
This idea doesn’t really carry over as well to Windows. Here is a design that uses visual elements from the start menu to match Vista’s Aero:
Another approach would be to match the appearance of each platform’s UI for file selection. Here is what that could look like on OS X:
And Vista (violating the rule about color to be consistent with the user interface of managing files):
Taking considerably more creative freedom (and this time really violating the rule about color), here is a design created to compliment Ubuntu’s Human theme. This design could have an interesting appearance animation if the outer parts expanded while the center faded in:
In these modal designs, clicking outside of the highlighted areas will return the page to it’s normal display, like the Dashboard in OS X. This is referred to as a spring-loaded mode. Also, all of these designs support multiple selection (with some visual indication that an item is selected), and copy and paste (through a contextual menu, the edit menu, and keyboard shortcuts).
An issue that these mockups don’t resolve is what happens if the user attempts to click on a hyperlink that is under an overlay. We would need to treat the action as selecting the item, but this will result in mode errors. This issue, in addition to others, is why we probably want to go with a non-modal design.
Non-Modal Designs
The modal interfaces described above do not proactively modify the Web page, the user has to actively ask for the microformatted content to be displayed. This UI has the advantage of getting out of your way when you are not interested in acting on pieces of content, but the disadvantage of not being discoverable. When microformats first start to appear on the Web, people may regularly invoke the microformat display mode just to see if they can perform an action on a particular piece of data, or they may forget about the feature entirely. Since neither of these situations is ideal, another approach is to always display application icons next to microformated content, but in a less obtrusive manner. For instance, just the icons would appear on the page, and then an overlay indicating the outline of the microformated content would appear when the user hovers over the icons:
The user hovers their mouse over the icons and the entire area is highlighted:
All of the above designs could be adapted to a non-modal interaction (although blacking out the page on hover might be annoying, so we would likely want to avoid those designs). Initially I preferred the modal design, but Mike Beltzner successfully convinced me last week that non-modal is a better solution. Note that even with a non-modal display the user could still turn the overlaid UI on and off (and we are back to modal), so the issue is really if microformatted content should be displayed by default, and how intrusive the display should be. Which type of interaction style do you prefer?
Acting on Content
In all of the designs above the icons for each associated application were displayed. This strikes me as the most simplistic and intuitive approach. However, there are a few other things we could do:
Descriptive Text
This design simplifies the initial display, and provides the user with textual descriptions of the available actions.
Pie Menus
For these types of contextual actions, pie menus provide a great UI because they are are faster and more reliable than linear menus. Another advantage of pie menus is that over time you will learn which direction particular actions are. This makes interacting with them essentially a small mouse gesture, and you don’t even have to focus directly on the menu to hit the right target, you can be viewing the information you are acting on.
Pie menus have been around for awhile now, they date back to at least 1988, and in terms of the Mozilla project, back to 2002. In the past, pie menus have been a popular UI control for contextual actions in video games.
Why Should Firefox Display Microformatted Content in the Page?
I realize that extending the browser UI into the content area is a controversial decision, and whatever default graphics we overlay on top of the page have to be respectful to Web designers. Also, it is not clear if any of the above designs achieve that, since it is difficult to overlay user interface without modifying the appearance of the Web page.
However, here are some additional reasons why I believe Firefox should display microformats in context:
Personalization
If Firefox takes care of the user interface for in-page microformat detection, we can display the icons for the specific applications the user has associated with different types of data. We can’t expose that information to the Web site without violating the user’s privacy.
Consistency (of the interaction, not the appearance)
If Firefox takes care of the user interface for acting on microformatted content, then the interaction model will be the same across all Web sites. Providing a consistent interaction model will improve usability. Note that the actual appearance should be easily customizable, as described below.
Low Barrier to Entry for Web Developers
Adding microformat support to a Web site needs to be as easy as we can possibly make it for Web developers, otherwise no one will bother to use microformats. Sites on the bleeding edge of the technology adoption curve like Upcoming.org, Flickr, Eventful and Ma.gnolia are going to integrate microformat support into their sites (all of those already have), but what about your local bank that last updated its Web site in 2001? What about someone who quickly wants to put microformated content on a blog or wiki? (This is the topic of my next post on microformats). If people only have to add a couple of divs and spans to support microformat detection, that is an order of magnitude easier than asking them to provide the entire user experience. Supporting microformat detection needs to be easy enough that all Web developers need to do is just write a couple of lines of code in between a database and Web site to generate the additional semantic markup. Otherwise, most sites are not going to go to the effort of supporting microformats, and users will not be able to take advantage of using their favorite applications for particular types of data.
Compatibility
Another issue to take into consideration is: what if you are viewing a site that contains microformatted content in a Web browser that doesn’t support microformat detection? Of course the Web developer can detect what browser the user has and adjust the site accordingly, but that is just additional work. However, if the source just contains a few extra divs and spans, microformat enabled sites are completely backwards compatible.
Security
The final reason I believe Firefox should provide the user interface for microformat detection is security. If we allow Web sites to initiate the action of sending data to particular applications on the user’s computer, we expose all of these applications (instead of just Firefox) to attack. Plus, Web sites could attempt to passively send information, which means we would need to popup a dialog box to make sure the user actually wanted the transfer to take place, and we all know how those can both get annoying and condition the user to always click yes.
Giving Web Designers Control
While Firefox needs to provide a good default interface, we will of course allow Web designers to easily skin the detection so that it can match the look at feel of their site using CSS, or disable it completely. To allow some customization with less work, perhaps we could also ship Firefox with a variety of simple appearances for microformat detection, and allow Web designers to specify which they would like used for their site. In addition to selecting a design, perhaps they would also customize a single aspect, like the color. There would of course have to be a few checks for security. For instance, we couldn’t allow hit areas that cover the entire content area and are completely transparent.
If we ship with multiple styles of microformat detection, we may also want to let the user choose which one they want to use in preferences. It would also be great if the detection interface was extendable and contributers could create new designs, similar to how you can currently develop new themes.
Overall, I believe that regardless of what design we eventually end up going with as the default (if we decide to implement this feature in Gran Paradiso), it is important for the Web browser to provide users with microformat detection in the context of the page. Detecting microformatted content on the Web is going to significantly streamline the way we explore, share, archive, and interact with information.
A New Version of Operator Has Been Released
Can’t wait to try these features out? Operator 0.6.2, which was released recently by Michael Kaply, includes in-page microformat detection.
Comment
Should Web browsers go ahead and render UI over a Web page, if it makes life easier for users? Modal? Non-Modal? Location Bar? Toolbar? Sidebar? Pie! Which designs do you like? Which designs do you hate? Please voice your opinion below.
Contribute
Open source isn’t just about contributing code, any UI designers out there are welcome to contribute mockups. Please add your ideas and mockups (at any level of fidelity) to this page on the Mozilla Wiki.
That pie menu is kickass.
Awesome stuff, very cool to see your thought process and this evolution of Firefox (if not the web). Thank you!
Right before that pie menu, the “descriptive text” menu resembles a smart tag in Microsoft Office.
Fascinating stuff.
I recently stumbled upon an extension called Link Alert that adds an appropriate icon to the cursor when mousing over a link, letting the user know what type of file it is.
This way of presenting the information is both highly discoverable and unobtrusive, and though I don’t know to what degree it could be successfully integrated into microformats, I’m certain it’s something worth looking at.
http://conlan89.googlepages.com/
conlan89 – Conlan’s Home Page
Hi!
I thought about Microformats UI a lot in the past, and concluded that showing the information outside of the browser page is a bad thing, because you then don’t know *what* the information is about, or where on the page it can be found.
Showing an icon within the page on the other hand can make it difficult for webdesigners to have the icons shown in the way they *want* it.
So, the best thing would be to give web developers and web designers the option to have control over how Microformats are shown on their sites – whoever creates Microformats on his site will also take the time to integrate them properly.
On the other side, everything that’s integrated to the page by the browser is a bad thing. Therefore I suggest a combination between the two things – show the contents in the sidebar, and give me a easy discoverable option to see *where* on the page the Microformats appear, through graying out everything else but the Microformatted text, or so.
For the future, I think that much more should happen within the browser sidebar. Monitors get bigger, and I think there’s the need for a context-sensitive sidebar that shows whatever information is available, like for example Microformats, but also social stuff, notes, page verification information, and so on.
I prefer http://people.mozilla.com/~faaborg/files/20070204-detectionUI/layer_bubbles.jpg_large.jpg and http://people.mozilla.com/~faaborg/files/20070204-detectionUI/nonModal2.jpg_large.jpg (maybe in combination with the pie menu).
In general, a background is more visually pleasing than a border.
“While Firefox needs to provide a good default interface, we will of course allow Web designers to easily skin the detection so that it can match the look at feel of their site using CSS”
Not if that means that Firefox has already hijacked the website. Whatever it does, it shouldn’t modify the DOM and add style rules. The UI shouldn’t only visually sit on top of the page, but also technically.
Hi Alex,
I think problem of showing the microformats to the user is a tough one, particularly because we are talking about altering the content of the page.
In my view decorating the page with additional clues automatically is problematic, because a page may contain many microformats and other things so the browser would be adding a big burden to the page without knowing if it is useful.
It seems to me that some sort of user gesture, perhaps a few seconds mouse over, needs to occur before you add the these buttons to the page.
For example, I think that what Skype extention is doing now is just not friendly to the user or other extension. They add the pretty Skype buttons to the page, but they in a way shut out any other extensions that might want to interact with the phone number.
Using context menu (right-click) is the safest and most standard way right now to interact with the content in the page. Users know where they click / you know where the user clicks, and while it is possible that a little ambiguity is still there, you can clarify it via a question.
Alex
I would opt for Modal. As you have mentioned UI should not be in proximity of content and as a user i would prefer to have it at one place. In essence its kind of Web page summary.
“Integrating detection into a single UI is more consistent and usable than than having different interfaces for each data type.”
Aren’t feeds just another form of microformat? Of course integrating feeds into the same UI as microformats would mean replacing the feed icon in the interface with the icon for whatever app/service the user has chosen for feeds, I don’t think that’s necessarily a bad thing.
Even if you opt for modal you could still do something like placing the associated application’s icon next to the mouse cursor when in is over a microformat.
Another thought.
Instead of using a separate icon for microformats why not cycle between the different icons for the formats on the page. This has the benefit that if there is only one icon to display the user will know exactly what will happen when they click it. Of course if it was to just cut sharply from one icon to the next it would be very distracting for the user, so in a similar vein to the way the iPhone “uses audio fades when you’re listening to music (iPod mode) and a call comes in.” http://headrush.typepad.com/creating_passionate_users/2007/01/iphone_and_the_.html
you could make it fade slowly from one icon to the next with ample pauses between fades. But then as that might make users hesitant to click on the button when it’s not displaying the icon they want it should probably automatically pop up if they hover over it for too long.
I’d prefer
http://people.mozilla.com/~faaborg/files/20070204-detectionUI/nonModal1.jpg_large.jpg
and the pie menu.
Nothing should preclude them from being modal too, if the user chooses so.
Alex -
More great work on microformats – it’s exciting to see the process continue and I hope it does make it into Gran Paradiso. Some thoughts to continue the dialogue:
Location Bar
I agree that we should avoid turning the location bar into a Windows systray like dumping ground for icons. I think there’s some weight to the idea of having a single icon there which indicates that there is additional information (meta information?) about the page. Clicking on that icon could show a drop-down menu (as the feed icon does now when there are multiple feeds), which could then include feeds, microformatted data, etc. (not unlike what you’ve shown with the Operator mockup).
Sidebar
I like your sidebar ideas – all of them actually – but particularly that you can have sub-page history as well as tagged content. Have you thought about how this might integrate with Places (if at all)?
Modal in the Content
I think there might be an in-between step between fully modal and non-modal, using your idea of having data appear in the sidebar. What if mousing over the abstracted list of microformatted data triggered the main content window to highlight that data in either the bubbles or spotlight modes? That way you gain the advantage of not having to figure out how to implement a fully modal mode (with security implications, etc.), and you get the organization of the sidebar with context indication.
Pie Menus
I’ve always heard them called “marking menus”, which is Bill Buxton’s term for them (e.g.: see User Learning and Performance with Marking Menus). My concern here is that the muscle memory effect is only applicable if the number of items in the menu doesn’t change – if you add detection for a new format or a block of microformatted content has five types of data instead of three, the size of the slices of pie has to change and so their location also somewhat changes. Add a lot of formats and the slices end up being very narrow and harder to hit (the same problem exists, of course, in places where you’re showing three action icons, which could grow to five or six). They are also not a very familiar type of control to most users out there and not used elsewhere in Firefox – not a reason to avoid them forever but perhaps, rather, to caution their sudden introduction.
Thanks so much for your great posts about microformats.
For publishers or web authors it would be cool if there would be some sort of tracking capability, so e.g. exports of contacts would be logged.
Greetings from Austria!
I think the sidebar is the most powerful, especially with history integration, and could easily include a “find in page” feature for each microformat. Calling out microformats in content is problematic, as you describe, and I’m not sure if there are advantages that outweigh the fact that you’ll be intruding on the display unless you make it a difficult to discover feature. I wonder about sidebar discoverablilty as well, unless there was some sort of button in the chrome that lets the user know there is microformat information available. (I think Jay’s idea of a single “meta information” action item is pretty interesting).
That being said, I feel like I’ve just described a process that would require multiple steps (click icon, spawn sidebar, find in page or act on microformat), so that might not be a very good experience either.
Exposing this kind of feature is a real challenge, since it applies to a specific part of a page, and yet web authors (rightfully) want to be able to control the appearance of their page, including (these days) rollover behaviors.
I wonder if there’s some way to figure out when the user is in a situation in which microformats would help them accomplish their goal, and only show the contextual UI then?
Specifically, it seems like microformats are best at adding intelligence to copy/paste, so what if we only showed the contextual UI when a user selected an area on the page that was wrapped in a microformat? Then they could either continue copying the selection to the clipboard as usual, or interact with the contextual UI to get smart microformat behavior.
I proposed an alternative design direction that would allow the page author more control in displaying Microformat UI.
A summary of some of the discussion and ideas is here.
http://www.raizlabs.com/blog/?p=176
Instead of having the browser promote the UI we could allow page authors to provide semantic tags to enable these types of actions.
Browser widgets such as Operator still have a place but the page author needs to be in control of the page’s user experience.
Greg, great post. I agree with all the points you made. Assuming we make sure there is no way for the page to simulate the user clicking, then I think this is a good compromise. This design will still be susceptible to things like the “punch the monkey game” attack, but that’s probably worth giving Web designers more control.
Great post!
I think a sidebar is *the* place for non-modal display of microformat information. I’d hate to see pages spattered with persistent icon-overlays, and I don’t like the idea of the browser providing webmasters with a proprietary CSS properties to style those overlays. …ick! :-)
I like the idea of making the sidebar items hoverable to expose the corresponding part of the HTML page (with either a bubble or a spotlight), and I’d also opt for some way (keyboard shortcut, mouse gesture, or a context-menu command) to turn on “microformat discovery” mode – which would be very useful for people who have turned off the sidebar.
It would also be nice to see some sort of icon/indicator (similar to the XML feed icon) to indicate that the current page has some microformatted content.
By that I meant “turn it on temporarily — for example until the user hits the “Escape” button, or clicks somewhere outside a bubble/spotlight area, or reloads the page, etc…
Why not changing the appearance of the cursor like when one points a link?
Over a microformat, the cursor change and a right-click gives the access to the operators.
By pressing a key (control or else), one inhibits the microformat tag, hence one can select the context as text.
This behaviour is nowadays widely known and that doesn’t clutter the design.
A suggestion on the UI considerations.
Why not follow a paradigm similar to the RSS feed detection in FF and Safari? I have a pretty strong opinion that the UI for displaying microformat actions should not be displayed by default; it should act similar to OS X’s dashboard and appear when summoned by the user. To get around the problem of users having to guess when microformat content is present, just display a little glyph on whatever affordance you provide to toggle the microformat “heads-up” display on and off.
So, let’s say there’s a button in the toolbar or address bar that lets users toggle the heads-up display on and off. When a web page containing microformat content is displayed, some icon or glyph could be added to this button to indicate the presence of that content. The user could then click on it to see the heads-up display with highlighted areas and application icons. Click outside a highlighted area or on the toggle button to turn the heads-up display off.
This way, users don’t have to guess. They don’t have to waggle their mouse over likely info on the page — the browser tells them when there’s something worth looking at.
You could still allow web designers to customize the heads-up display. But this way, the microformat heads-up display is discoverable without cluttering up the visual design of the page. And you’re leveraging an already learned behavior introduced with RSS feed detection.
Anyway, great work, I’m looking forward to seeing this evolve and ultimately implemented. I love it.
Well, I’d prefer some kind of tiny sidebar (with a width of about 16px + a natively-styled edge) that floats icons next where microformats are detected.
I know this questions must have been asked before: but won’t it be a lot easier to gather personal information on the web via microformats? And because personal informations are stored in the h-Card format, spam bots would even get pre-formatted information, so that they could address with your real name. Google might introduce an address search using microformats.
I think that sounds scary, it’s like making the web a better and worse place at the same moment.
Oh, and it may even allow automated real-world spam.
“I agree that we should avoid turning the location bar into a Windows systray like dumping ground for icons.”
Too late! Such a dumping ground for information that Mozilla is trying to defend it by stripping favicons. Tsk tsk terrible UI design
Toolbar
I really like the idea of the tabbed-navigation-toolbar and the idea with the icon in the location bar next to the feed-icon.
The later might get easier to implement, because in the current implementation the navigation toolbar might not be on the top.
Maybe an additional toolbar like Operator uses might work better for this reason.
Sidebar
The sidebar ideas should get realised additionally, but not exclusive.
The idea with the subsections is really great.
Content Plane
Highlighting in the content plane is dangerous, bacause it might break bad page designs. Highlighting should only work when requested by the user. Also the highlighting-style might get controlled by a propritary firefox-spefific stylesheet.
For the content plane I prefer the Contextual Menu, because its small (and thus less intrusive) and easy to extend with new microformats.
Icon
For reasons of pretty design I would avoid the plus-icon of the Operator plugin and use the microformats.org logo instead.
Recusrsive Microformats
Also be aware that microformats might be recursive. Thus, a single ‘hcard’ might include a calendar with multiple events, and multiple ‘adr’ addresses and ‘geo’ locations (each event, work, home, etc.).
A good microformat design has to respect this fact, but the operator and tails extensions doesn’t do so. A Tree-Menu will be better suited for this.
I think that Dimitri Glazkov hit the nail on the head with his Margin Marks mockups.
http://glazkov.com/blog/margin-marks/
http://flickr.com/photos/dglazkov/sets/72157601860335196/
I really love Dimitri Glazkov’s Margin Marks idea, linked in post 26. I wonder, however, if there is a feasible way to merge his idea with the scroll bar. To preserve the functionality of the scrollbar, the “margin mark” would probably have to jut out from the scroll bar rather than span it.
I also think that perhaps just the tip of the margin mark should jut out from the scrollbar to indicate that there is microformatted content there, and when you hover the mouse in the area near the margin mark, the margin marks expand to show the icons and the numbers as you have mockup. The reason I suggest this is so that the margin marks are even less intrusive, but are reactive, so that you can interact with them when you need to.
Some Pros:
- This would mean even less screen-size impact than adding another margin or toolbar;
- The scrolling properties of Dmitri’s idea are already intuitively linked to that segment of the browser;
- Offscreen microformat content that is can be represented by a small pip or marker on the scrollbar. This would alert the user to the fact that there is microformatted content in a separate area of a large page;
Problems:
- The scrollbar may be a fundamental institution that you just don’t want to mess with;
- This would potentially complicate a vital control feature. As it is, most people don’t have to take their eyes off the content to operate the scroll bar. Adding this feature would almost certainly cause unwanted results from mouseclicks that miss their mark.
I wish I had the graphic design skills to make a mock-up myself.
-Andy L
I hate Applications names, really. I want a clean apt icon, not a silly application icon. Thanks.
<a href=”tel:650-961-966″>(650) 961-966</a>
<a href=”loaction:90_N_0_E”>North Pole</a>
You do not need this microformats. You need this URIs.
I think directly placing the UI on the website is the way to go and, as long as the web developers preferences are considered, you’ve listed several great reasons why in page implementation is the best way.
I very much like the non-modal concept, that grays the area on hover. I think aesthetically I would prefer a third design with the smaller, neater icons extending from the green arrow horizontally, and the descriptive text to be displayed, on hover-over, immediately under the icon list. I really do no like the pie menu.
This way of presenting the information is both highly discoverable and unobtrusive, and though I don’t know to what degree it could be successfully integrated into microformats, I’m certain it’s something worth looking at.
Well, I’d prefer some kind of tiny sidebar (with a width of about 16px + a natively-styled edge) that floats icons next where microformats are detected.
… and as more and more information is add to the microformat scheme, exactly ‘how’ will it not become confusing and unusable?
Please explain to me how more Firefox buttons will do it.
I can see the future now… hundreds of Firefox buttons, and only enough room for one line of web page content.
DCStrain