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

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.

<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