User:Auk/History Model

From MozillaWiki
Jump to: navigation, search

Integrate a graphical representation diagram of the path taken from page to page. I take the word flow from a bugzilla comment I read, which I think fits perfectly. Flow represents a string of links, the path traveled to get to the current point.

You can create an entirely new flow, or you can branch an incumbent one. Flows are branched upon:

  • Tracing your steps back and continuing from that point upon a different route (e.g. back to your google search and investigating a different result).
  • Opening a new tab or window from a link within a current t/w.

New flows are spawned upon pressing Ctrl+T, Ctrl+N, or selecting an according menu entry.

History should appear in a seperate History window (Ctrl+H), with a secondary (more limited) sidebar interface, like the bookmarks work. As sidebars are cramped on space, we may not want a diagram there, in favor of a flat-level list.


Manifesto: Allow sessions to be restored at a time later than directly after a crash/force-quit.

Menu layout for this explains much of it:

A page
Another page
On to ten pages
Recently Closed Tabs  ->
Sessions              -> [Date] [Time*]
----                     22 Oct 2006           ->
Show in Sidebar          18 Oct 2006 8:21 AM   -> Firefox/Features Brainstorming - MozillaWiki
                         18 Oct 2006 4:15 AM   -> User:Auk - MozillaWiki
                         17 Oct 2006           -> GNOME - Wikipedia, the free encylopedia
                         ----                     Linuxart » Blog Archive
                         Save Current Session     ----
                         Edit Sessions...         Open All in Tabs

\* Only appears if two sessions in the list share a date and must be differentiated.


Specifically, the b/f buttons on the toolbar, and their drop-down menus.

The back and forward buttons, when selected once, should concur directly along the current flow. When the drop-down menu is selected, the current flow should be presented, containing sub menus at the branching nodes of other flows.

This begs the question: How to evidence and provide navigation functionality to parallel history flows in b/f dropdowns, while retaining navigation to all pages in the current flow?

The most likely solution is to present the entire area as a drop-down activator on hover, and a small go-to activator area which when clicked (perhaps the menu icon space, with a GOTO icon), takes the browser to that web page. Concerning the keyboard:

  • Go-to
    • SPACE
    • Ctrl+ENTER or possibly ENTER
  • Drop-down
    • right-arrow
    • ENTER

Another solution is to present the drop-down activator only over a small part of the menu entry (e.g. a small arrow on the far right). Disadvantages of being non-discoverable and wierd.

Bookmarks integration

This is one of those things that I first thought "Hey, that's a great idea! That would be so cool!". Then, a little while later I thought "What a stupid idea. That would be so wasteful of space, so cluttered." The next day I relapsed: "Hmm, that might work out after all." Then I thought "Naww..."

So, I don't really know yet. It would be nice to keep a simple record of where you've been, and which you liked, but also would crowd the pages you really want.

I'm leaning towards no.