<a href=”loaction:90_N_0_E”>North Pole</a>

You do not need this microformats. You need this URIs.

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

http://glazkov.com/blog/margin-marks/

http://flickr.com/photos/dglazkov/sets/72157601860335196/

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.

Too late! Such a dumping ground for information that Mozilla is trying to defend it by stripping favicons. Tsk tsk terrible UI design

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.

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.