In Part 2 of his Ubiquitous Firefox concept, David continues
explaining his ideas, process and explorations:
http://mzl.la/kfD6tz

Do check it out and get involved in the conversation, today!

Dees / @cyberdees

--
Desigan Chinniah
Firestarter, Innovator & Geek @ Mozilla Labs
http://desiganchinniah.com
+44.77.8643.3785

'cyberdees' on Twitter, Lanyrd, Upcoming, Last.fm, Flickr, LinkedIn

Hi David,  You've got an interesting approach to this problem.  I like a lot
of it, but here's something that occurred to me.  By merging history and
tabs, don't you lose the distinction between (1) history pages that I'm
*done* with (all the pages I wouldn't currently open in a new tab), and (2)
pages I am *not* done with (those I would usually want to keep open in a
separate tab).  So with this design if I want to go back (scroll back) to a
page that I'm not done with, I have to find it among all the pages that I
*am* done with, since these two types of pages are now intermixed in the
timeline.

In other words, merging history and tabs will result in more items in the
timeline(s) than there are currently open tabs.  Whereas before I could
close a tab and remove one page from the pages I'm dealing with, now I would
have to close the whole timeline, but couldn't close or remove individual
pages in it that I was done with.  I guess you could manually re-order the
timeline putting the pages you're not done with at the bottom...  But maybe
you have another means to keep this helpful distinction between pages I'm
done with (currently history) and pages I'm not done with (currently open
tabs)?

I haven't thought this through, but maybe it would be worth having all three
options for opening new pages:

1. open in-line in the current tab (new, as you're proposing)
2. open in a new tab (like current option)
3. open and replace current page (like current option, former page goes
away, into hidden history list? accessible by button, etc?)

And maybe including a way to close a page, removing it from a timeline when
you're done with it?  But I guess that introduces a lot of things I haven't
thought through...

Anyway, curious to hear your thoughts on this, and nice work!
-Paul

Great question, Paul! I’ve been thinking a lot about the trade-offs between
the current system and my proposal, and I don’t have any simple solutions.
With the current system, you know what you’re done with and what you’re
still using. The downside is that there’s an added mental burden of needing
to close tabs a lot in order to maintain this order. It’s a lot of tab
management, and it would be nice if it weren’t necessary. Additionally,
since closed tabs are no longer visible, you lose the clear visual sense of
your history that you get in my system. The general idea is that you *
usually* read linearly, so this interface is optimized towards that
workflow. So, going back to read something you haven’t read yet *should*,
theoretically, be less common. Of course, seeing how this works in real life
requires working code and data, so I cannot know for sure if it’s possible
to handle those other situations well.

I have some ideas to help deal with these issues:

   - In the article, I mentioned that pages that you have not yet read
   should be indicated in the History Scroller. I think your point makes a good
   case for distinguishing between read and unread pages very strongly. After
   all, if you’ve finished reading a page, you probably want it to blend into
   the background until you need it again, which will probably be rare.
   Meanwhile, you want to see clearly where you need to go next.
   - Perhaps the Scroller should slide away and auto-hide most of time, with
   the exceptions of during scrolling and when there are unread pages.
   - We can make sure that read pages older than one page ago get scrolled
   away behind the top arrow in the Scroller. That way you are not bothered by
   old pages you may no longer need, but you still see the most recent page
   (since going back one page is actually very common), you still get some
   context, and going back more than one page is still fairly easy. This would
   be part of a more sophisticated algorithm (which I haven’t figured out yet)
   that would determine what to show in the History Scroller at any given time.
   - A command to keep a page unread would also be useful (possibly exposed
   in the content area, kind of similar to what Google Reader does, but not
   necessarily with the same placement).
   - Also, if you really want a page to stand out, you can always drag it to
   the tab bar to make it into a separate tab.
   - You could just delete unwanted items from the history. That action
   should be necessary *only* when the page is completely irrelevant for
   future page recall, however.
   - Another question would be how Firefox would know if you’re done reading
   a page. Perhaps a page shouldn’t be considered read unless you’ve scrolled
   through it completely. Then again, I probably don’t do that for most Web
   pages, so most pages would remain “unread’. Or perhaps the unread indication
   in the Scroller should be more detailed, showing how much of each page
   you’ve read. Then again, that could just lead to too much unnecessary
   information and clutter.

It’s a tricky problem. It’s especially tricky because I don’t think I have a
good understanding of the nature of the problem and how much of a problem it
actually is, due to that the aforementioned lack of working code and data.

In other words, merging history and tabs will result in more items in the

The ability to reorder is definitely important. The ordering is supposed to
indicated how pages are related and their reading order. So, if you open
them in a suboptimal order, you should be able to reorder them. That should
partially alleviate the above problem, though I can’t say how much.

An alternate possibility would be automatically rearranging pages so that
unread pages are always at the bottom. That would destroy that natural
ordering, however, and your spatial sense of what’s in a tab would be
harmed.

I haven't thought this through, but maybe it would be worth having all three

That could solve the problem for people like you and me. But it would be
more ideal to minimize how many options you need to think through every time
you click on a link. I still see people who don’t know that they can open
links in new tabs, so giving them three options instead of two probably
wouldn’t help them with good tab/page management. Even the way tabs work
now, there’s a Hick’s Law
<http://en.wikipedia.org/wiki/Hick%27s_Law>penalty every time I have
to decide whether to left-click or middle-click a
link. I find that I often just default to middle-clicking no matter what,
followed by closing the current tab when I’m done. What I’ve tried to do
with my design is to remove the need for these options. *Ideally*, opening
links in new tabs should be unnecessary. The default is to open a page below
the current one. If you don’t want to read it yet, you interrupt the
transition by scrolling up; if you want to keep it around in a different
tab, you drag it. But you can always just click normally and make those
decisions afterwards. Of course, ‘ideally’ is the important word here.

Let me describe an alternative behaviour I recently thought of. No mock-ups,
so I hope it’s clear. Open in New Tab is the default operation (like how I
described my current behaviour); pages are, thus, never replaced by new
ones. When you’re done with a page, you close it. So, 1 tab = 1 page.
Instead of Back/Forward buttons, revisiting closed pages is done via
Recently Closed Tabs (which would be redesigned to fit this model better).
Finally, New Tab always opens up a new group in Panorama (and that button
would be moved there as well). The purpose of the last detail is to make
unrelated tabs completely separate, so that related pages (all belonging to
the same tree) are grouped together linearly in the tab bar. (This might
also work well on webOS, by the way, with its card system.) The advantages
of this model: you no longer always see what you’re done with; you don’t
have to worry about read/unread status; there’s no odd redundancy between
Back/Forward and the tab bar, since the latter fully takes over the role of
the former; and there’s no clutter or confusion on the tab bar like there is
now because the tab bar shows only related tabs. The disadvantages: getting
to old pages is more complicated; you’re still constantly closing tabs,
rather than simply scrolling down; the display of your history is not as
visual nor as simple. What do you think?

*The system I just described should be much easier to implement as an
extension. Anyway want to try it?*

And maybe including a way to close a page, removing it from a timeline when

Timelines should be saved wholly, so you can easily go back to them in the
future. I often cannot remember enough about a certain page, but I remember
a bit about how I got there or what I was doing at the time. Firefox’s
history currently doesn’t do a great job facilitating such use cases. If it
saved entire timelines, I could find the part of the timeline I do remember
and follow it to the page I’m trying to find. Having Firefox remember
context in this informative way would simply be great. Thus, as I pointed
out above, the interface should probably discourage deleting pages from the
history unnecessarily, so closed tabs can be stored as records of an entire
tab, not just the last pages in that history.

Anyway, curious to hear your thoughts on this, and nice work!

Thanks! You’ve pointed out some crucial issues. What do you think about some
of the above ideas for alleviating some of those problems? Do you have any
other ideas? Possibly alternate systems for solving the tab problem?

David

In response to Paul's comments, something as simple as adding
the functionality to plant markers arbitrarily in the pageflow
would alleviate the issue of scrolling back and forth as he describes.
If I'm not done with a section yet, but need to refer to another,
I could simply right-click the page and select "Drop Marker",
or similar, from the context menu.  The scroller would then show
markers by highlighting the pages that have them, perhaps with
a colored dot or outline.  That way, when I scroll through my
history, I can easily find the things I meant to get back to despite
those things being mixed in among all the "read" pages.

Kith, that’s very clever. That would be a more obvious, visual, and
content-based way of indicating where you are. This marker could have the
appearance of one of those sticky bookmarks that stick out the side of
books. This could also be merged with the *keep unread* functionality I
suggested earlier, where running that command would insert this place marker
wherever you are (perhaps at the part of the page near the top of the
content area). Adding a line on the Scroller for that particular point in
each page with a marker might be too much visually, though, as they would
always be visible. Clicking on an page item should take you back to wherever
you were on that page the last time it was active, with or without a
position marker. Perhaps, instead, the background colour of the item on the
Scroller could have the same colour of this position marker in the content
area. Just the colour could work as a visual reminder.

On Jun 14, 6:10 am, David Regev <david.re...@gmail.com> wrote:

Thank you, David, for you kind comments.  I've given this issue some
more
thought and have two more suggestions to add.
First, you have suggested that the Scroller show more information when
we mouse-over.
That concept could be extended to this sort of bookmarking as well.
The flag could show its
own metadata when we point at it (time and date, maybe a URL, perhaps
an
editable comment field).  Moreover, the flag should be freely re-
positionable and,
for accessibility, numbered chronologically.  These numbers should not
change
if a flag is removed.  That way, users could add several markers to
each page if they should
feel the need.
Second, I wonder how you would feel about allowing users to filter
what they see
on the Scroller.  For example, showing only unread pages or flagged
pages
or even full text search results.  Then we could kind of zoom in and
out on certain levels
of specificity in a context-driven way.
It sounds like a move toward the modal, but could provide for the need
to see certain
groups of information together without distraction.  And I'm sure it
could be implemented
in a way that makes it visually obvious what is going on.

Yes, I was thinking that these flags would be draggable up and down the side
of the page. There’s a downside in that they would take up some horizontal
space for pages with them, so some design is needed to alleviate that.
There’s also the question of whether you want the flags to be part of the
browser’s standard automatic behaviour of keep track of unread pages and
your last position within a page, or whether they should be an additional
layer on top of that for those who wanted it (perhaps for especially long
pages). I would prefer well-functioning automatic solutions usually and
manual solutions only when strictly necessary. I suppose we’ll see how well
the former would work. But it would make sense to add some simple version of
the fag concept as a visual indicator.

Absolutely. We can do a lot of cool stuff here with search. Having your
entire history visible in the canvas opens up some interesting
possibilities. In Part 1, I briefly mentioned the idea that Find could work
across the entire tab history: it would first look for the terms on the
current page, then the previous page, then the one before that (or something
like that).

It sounds like a move toward the modal, but could provide for the need to

Filtering could somehow be integrated into the Find interface, so it
wouldn’t be a totally separate thing. I imagine it working similar to how
Safari highlights your search terms and darkens everything else, calling
attention to what you want. Once you’ve navigated to the desired result,
everything would go back to normal. So, avoiding modality here should be
possible.

Flags! That’s exactly what they’re called. I couldn’t remember. Here’s what
they look like, for anyone reading:

[image:
http://fc06.deviantart.net/fs20/i/2007/281/f/3/Book_With_Post_it_Flag...]

There’s a downside in that they would take up some horizontal space for
pages with them, so some design is needed to alleviate that.

I noticed that too, but the flags only need to be obtrusive when we're
trying to navigate. In the content area, we could simply place a colored
line at the top of the nearest paragraph or something to show there is a
flag here and allow some basic interactions like drag-and-drop and delete.
Then, if we make them a little more obvious in the mouse-over behavior of
the Scroller, we can put more advanced functionality there (if it should
need to be), and it might feel more like the "keep it unread" functionality
you mentioned earlier.  I do like the idea of things sticking off to the
side, and much of the horizontal space is often wasted in page design, but I
also agree that it would be easy to see as just more clutter on the screen.

Wherever any indicator is placed, it should extend outside the frame for the
page. Otherwise, it would be both harder to spot and confusing as to whether
it’s part of the page or part of the browser. That gives me another idea: we
could use the page border (something sites would not be able to modify) as
an indicator. Unread pages would have a different colour, corresponding to
the indication in the Scroller. And perhaps the border could be thickened a
bit in the area that was last visible for any page. That would give you a
clearer idea of exactly where you left off.

I didn't mean to argue semantics here... I think this is where a prototype
comes in.  Once the pageflow is fully established, a solution may be
obvious.  Thanks for listening!

I couldn't help myself.  Here's a quick mockup from our conversation above.
The top image is what the user might see while browsing a page that has been
flagged (shared browsing possibility?).  The bottom image contains the UI
exposed when the user summons it by, for example, clicking the down arrow on
the left side of the flag.
I've omitted the Scroller for the time being and left the page background a
neutral color for contrast with my crude blocks.

<https://lh4.googleusercontent.com/-qYfuu20_-R0/TflAr4Xnh8I/AAAAAAAAAV...>

bookmarking interface. In general, I would love to be able to mark up
bookmarked pages with notes like this and see those notes the next time I
open the page, along with the original version of the page. It would be a
great alternative to saving pages to disk or elsewhere. It’s still the scope
of the limited extensions I proposed, however.

Perhaps someone would want to implement this as an extension (on top of the
current interface).

That's an excellent observation.  Flags should absolutely be persistent on
bookmarked pages, and maybe optionally retrieved from history on loading a
non-bookmarked page.  I'm sure I have many older bookmarks that are now a
mystery to me.  That whole situation could be remedied with a few short
notes Flagged to the pages.
Come to that, there's been little discussion on how to handle bookmarks in
this project.  Have you posted your ideas on that elsewhere?  I'd love to
read them.

Hi David,  Thanks for your response.  It's a lot of good thinking on this,
and I'm afraid I don't have much to add, or any elegant solutions.  Good
point about Hick's law and the problems of too many choices.  The ability to
collapse a page into its header (like gmail, google reader, or google
groups) might help distinguish pages you're done with and those you are
not.  Perhaps the default could be that they would collapse when you
finished with them (scrolled past them?) but you could quickly click the
header to keep them open if you weren't done with them.

I like your alternative idea (below).  It focuses on a clear, easy, and big
payoff -- a way to automatically group tabs according to which page(s) they
were opened from, like with Tree-Style Tabs and in your other proposal.  
Besides just the active/open tabs, this could also apply to history, as your
approach emphasizes -- a need for a "Tree-Style History" as well.  

Improving History and Bookmarks might be another way to help with the
too-many-open-tabs problem.  (I think about things like Read It Later, or
your discussion with Kith on flags below.)  

(I find I don't use Panorama that often because I don't think beforehand to
start a new tab group (or a new window) and then I've opened a string of
tabs, and  there's no way to select all of them in one go and make a group
out of them, and it's too much trouble to drag them one by one...)

Paul

Let me describe an alternative behaviour I recently thought of. No mock-ups,

I don’t have any grand vision for bookmarks. Using bookmarks as a
replacement for Save As is the biggest idea that I have. Replacing folders
with tags more fully would be nice too, as would somehow integrating
bookmarks into Panorama. I don’t have any concrete idea on how to do that
properly. Maybe some of Firefox’s developers have more specific thoughts.
I’d also welcome any bookmark-management ideas specific to my design.

Collapsing pages is definitely something I would like to experiment with if
and when we start building prototypes. Perhaps it can even work as a
replacement for the History Scroller. We might be able to use that idea for
solving some of the problems we’ve discussed: collapse a page to “close” it,
leave it expanded to leave it open (and, importantly, running). It’s kind of
a hybrid between my proposal and the alternate tab-based model I quickly
outlined earlier in the thread. If we collapsed pages only if you’ve
scrolled past the end of the page or you’ve manually collapsed the page, it
might solve even more of the problems with getting back to unfinished pages.
What do you think?

I like your alternative idea (below).  It focuses on a clear, easy, and big

Yes, it’s a lot like Tree-Style Tabs. I didn’t even notice that.

Improving History and Bookmarks might be another way to help with the

Things like Read It Later feel to me like yet another layer of complication
that could be solved more elegantly if browsers had better
page/tab-management. With my proposal (and some of the alternatives I’ve
outlined), together with Panorama and Sync, it seems to me that we would
have that more elegant solution.

(I find I don't use Panorama that often because I don't think beforehand to

I know what you mean. Although it would change how people are used to
browsing, moving the New Tab button to Panorama could, theoretically,
greatly improve tab management. It would also be similar to Aza’s original
concept <http://www.azarask.in/blog/post/firefox-mobile-concept-video/>.
(Note how he also has a Bookmarks area in the zoomable canvas.)

Paul

Agreed on collapsing pages, they'd be a good way to deal with open/closed
pages and making it easier to go back to pages you're not through with.  
Something to experiment with at the least, as a way to make merging history
and open tabs work.

I do like the Read It Later option, since it offers a place to put things
between keeping it open in a tab and bookmarking it.  I have a lot of tabs
open now that are things I want to get back to, so I don't want to lose them
into my history or bookmarks, but there's no real reason to keep them open,
except as a reminder to go back to them later.  Read It Later fits that need
perfectly.

It would be interesting to see how it would work if opening a new tab always
opened a new tab group, and tabs opened from a page were then opened inside
that tab group.

I tend to put those tabs in a separate group. That’s usually fine but, as
you point out, you don’t want extra pages open and running all the time. And
that really touches upon a fundamental problem with making the user worry
about “opening” and “closing” pages. One of the advantages of my original
proposal was that you didn’t have to worry about that. That stuff would be
reduced to a technical aspect of the implementation, taken care of by proper
memory management. There’s no reason the browser couldn’t do some of that in
the current interface—much like BarTab did. If these things we all done
right, Read It Later and similar tools would be unnecessary (for their
current main purpose, at least).

It would be interesting to see how it would work if opening a new tab always

Me too. Panorama’s visibility would have to be improved, though.

With the discussion about the issues brought up earlier quiet now, I’d like
to bring up another issue: *web apps*. This is related to the issue of
unfinished pages, but more acute. Suppose you’re in a web app, such as
Gmail, and you spawn a few pages from it. In the context of Inline Tab
History, where should these pages open? If they queue up within the current
tab, like you might expect, then you have to leave your web app in order to
read them. This issue is exacerbated if the original page is deactivated
when you leave it, because you often want the web app to continue running.
So, *what should be done with web apps?*

Some ideas to consider: we could special-case app tabs, but then web apps
that haven’t been pinned would still be an issue, and we don’t want to force
users to create app tabs to fix problems in the design. Could web apps be
detected automatically (at least with a high degree of reliability)? One
possible solution would be to place all links set to open in a new window
(something many web apps do) in one adjacent tab. The same could be done for
all app tabs. That could solve the problem, but it would overcomplicate the
interface, and we’re trying to simplify. Another possible idea is to expose
very clearly a way to pin a page, something like a ‘Keep running’ command,
so that pages aren’t automatically closed when unfocused (this should also
be indicated in the History Scroller in some way, perhaps by desaturating
all inactive pages). With Paul’s idea of keeping pages running until they
are manually collapsed, *à la* Gmail, this is less of an issue. But I’d like
to see if anyone has other ideas.

Thoughts?

David

My first thought on the problem of detection was: "we could whitelist web
apps from a central location, and the browser could subscribe to that
list".  This would make the detection of web apps automatic and invisible to
the casual user.  One problem with that approach is that the list needs to
be maintained and will never be complete no matter how carefully we try to
keep it up.  We could crowd-source the list by offering a control in the
browser to submit a site that wasn't already on the list, perhaps
automatically when a user selects to "pin" the tab as an app.  But that
leaves a lot of setup, and it doesn't work right away.  Users won't use a
feature they don't know about, and this approach is meant to expose itself
by its operation alone.  But to start, there is either no list or only a
limited list, so there is little exposure.  Furthermore, we are still making
the users do the work, which is one thing we're trying to avoid, and new
sites would have to be discovered and submitted by users (by whatever
mechanism), so the list is always behind the web.

Instead, what if we propose a standard for web apps to identify themselves
to the browser?  Web apps are different enough from other web pages that
their maintainers might back such an initiative.
The browser could use the identifier to determine what behavior to use when
displaying a page.  That kind of standard is also future-proof; should
another breed of webpage require different treatment from the browser, it
could be added with ease.

As for display, I agree with a horizontal move from the app itself... what
about a layered approach?  An app tab could allow one additional layer of
tabs within itself.  A sub-tab could be spawned within the app-tab each time
a link requests a new window or the user requests it.  With inline history
there shouldn't bee to many of these, and this way they are all logically,
visually, and programatically connected to the parent app-tab.  Sub-tabs
could be dragged to the primary tab bar should the user desire it, and
app-tabs would automatically make this transition so that there are never
more than two levels.

Cons: Added complexity and loss of screen space to the second row of tabs.

I was thinking this too. Considering the current trend towards web apps
everywhere, this sounds like something that might be possible in the near
future.

In the meantime, I was wondering if it’s possible to detect if a page is
maintaining any sort of network connection or has something running in the
background. Ideally, this should be the thing that’s maintained by the
system and is completely transparent to human beings. The tasks of “closing”
documents and managing memory should have moved to the background a long
time ago. If a page is static and I’m no longer viewing it, the browser
should remove it from memory. If I was chatting in Gmail, or if Twitter is
updating in realtime, Firefox should somehow realize that those pages should
continue running for a while (for how long is another question). The
question is: can this stuff be determined automatically? If an algorithm is
good enough, it might be used until web apps start using this theoretical
future standard and tell the browser to keep them alive. Considering that
Mac OS X is moving in this direction of hiding opened/closed status for
applications, I suspect that this may be possible, at least in a way that is
good enough for now.

As for display, I agree with a horizontal move from the app itself... what

And we might be able to compress this added hierarchy into the current
design. You start off with an app tab that looks like this:
/✉\ +
Suppose that page spawns three pages. We can open them all up in order
within one tab that’s visually attached to the parent app tab:
/✉\ ✆✇✈\ +
The idea is that it all still looks like it’s one tab, but the original app
can remain “open”. Meanwhile, the History Scroller would look something like
this:

✉
⊼
✆
✇
✈
∨
The idea there is to separate the web app, which is an entity onto its own
with its own way of dealing with history and which is persistent, from the
standard tab history that it spawns. It should all look like one tab, but it
would technically be two.

And here’s a possible cool feature that could be added to this: if your
screen is wide enough, we could display the app tab on the left of the
screen and its adjacent tab of spawned pages (along with that tab’s
Scroller) at the right of the page. The app tab would always remain visible.
It would make a neat browsing experience.

This is what I originally had in mind, but there are problems. For one, it
would work only for app tabs. If you’re viewing a web app in the middle of a
tab history, trying to implement this there would be overly complicated. A
more generalized way of keeping pages alive would be better: (1) do it
automagically, (2) require pages to be closed manually, or (3) require pages
to be kept alive manually (or by the server). We could also retain the above
“mockup” for app tabs in conjunction with one of those ways of keeping other
pages alive (but giving those pages the standard tab history interface).

Another problem with this proposal is the added visual complexity. I would
still prefer a cleaner simpler solution. If I can get some prototypes or
extensions built, we can iterate and possible learn enough that we can
simplify all this. Some of the alternatives that we came up with in this
thread should be easier to implement than the others. For this to be
possible, I still need developers.

I’ve also been thinking about the history-less alternative I briefly
described earlier. Basically, instead of tab history, pages are
*always*opened in new tabs. The tab bar would be the visual indicator
of history
there. New Tab would always open a new tab group, so related tabs are never
mixed with unrelated ones—all without the need to move tabs around manually.
In this model, you still have to close pages yourself (so it’s not my ideal
slution), but the web app situation would not be a big issue. Some way to
view closed tabs quickly would also be needed. It would probably be simpler
than my original proposal, and easier to implement. I was thinking that we
could then visualize the tab bar using something like webOS’s card
stacks<http://www.precentral.net/working-card-view-stacks-update-webos-2-0>within
Panorama.

Thoughts?

Hmm... in the specific case of an e-mail app, I think I would expect (as a
user) that each [external] link clicked should produce a new tab since they
are likely unrelated, especially links from different e-mails.  Same goes
for social sites like Twitter and Facebook as well as "home page" apps such
as iGoogle and My Yahoo; even links that are near one another are not
[necessarily] likely to be related.  On a "regular" website, however, I
would expect more of a "this is an article, here are some related items"
format, where each link somehow expands on what was being presented around
it and relates to the page as a whole.  That kind of makes me wonder if we
should push a little harder to separate the web apps from regular browsing.  
Perhaps it would be worth exploring the possibility of treating web apps
more like full-on applications?  
Just to brainstorm...

A normal browsing session probably starts with one or more tabs opening as
the homepage.  The browser would have its own Browser Button followed by
these tabs across the top from left to right.  When the user opens a web
app, the in-tab history makes a note of this (perhaps a modified version of
the page header, but sans content) and maybe even provides a "Switch To"
button.  At the same time, the tab bar shows a zoomed out view where the
tabs vanish (shrink into the Browser Button, maybe) and a new browser button
appears for the web app (visually different from the Browser Button,
probably the favicon or similar).  This flashes a couple of times and then
the browser automatically switches to the app.  The Browser Button shrinks a
little and sits off to the side of the App Button.
The web app is now treated as a full-fledged application that just happens
to use the same framework as the browser.  It can have its own tabs,
starting with a pinned "home" tab in which the web app itself runs and which
is not permitted to browse away from the domain of the App without spawning
a new tab.  These *replace* the Browser's tabs.  Each of the other App
Buttons (including the Browser Button) shows a badge with the number of open
tabs, and mouse-over any of these icons will produce a quasi-modal change
over to that App [dimmed, perhaps?].  Selecting a tab or clicking the Button
would commit to the switch, and moving the mouse out of the tabspace would
revert to whatever was showing last.
[On second thought, clicking any App Button should open the App Menu like it
would when the App has "focus", but with a special "Switch to" item at the
top.]

It sounds complex, but it is similar to both "tabs" and "task bar"
behavior.  I think it might be good to blur the line between Browser and App
in this way to make relationships more clear.  You can't see the whole
session at once, but that's kind of the point;  we only see what is most
relevant to what we are doing now, but in an information-rich way.  An
adaptation of Panorama could provide the zoomed-out full-session view,
should the user desire it, and this way the browser manages the larger
structures for us.

Like split-screening two windows... That sounds pretty awesome (I'd sure use
it!). But it does, as you noted, suggest a wide-screen format. Perhaps the
browser could make the decision based on the width of the content on both
sides and the size of the screen, then change the display accordingly.

I’ve also been thinking about the history-less alternative I briefly

I like the look of the card stacks; they clearly show the complex
relationships of a hierarchical structure. Are you thinking of something
similar to what I described above, with each App (including the browser)
being a card?  Perhaps each App as a stack with tab history displayed in
cards?  That would be a good zoomed-out view of the full browsing session, I
think.

A stray thought:
What happens to old tabs?  You've expressed that the user shouldn't have to
manually close things, and I agree.  It wastes time and makes past
information inaccessible.  Maybe we should discuss re-envisioning the tab
bar as a Timeline bar with discrete starting points for each "session"?  
There are some very info-rich opportunities there...

Your point gets to the heart of a problem I’m surprised we haven’t discussed
*: how do you know what’s related to what?* It’s pretty subjective. If I’m
on a forum and I open up many threads, those new pages are probably more
related than if I open a few links from my e-mail. Following links from one
Wikipedia articles yields a tree of pages that are even more related. Links
from a feed reader, on the other hand, are sometimes related and sometime
completely unrelated, depending on what grouping of feeds you’re viewing.
This would be nearly impossible to detect. But I don’t think knowing this
information is necessary. This isn’t really the type of relatedness I’ve
optimized the design for; instead of grouping pages related *by content*, we
can group pages that are related *temporally*.

Outside web apps, most pages are transient: they get opened manually or
spawned, you might open some new pages from there, and the older pages then
get closed. There’s a natural linear reading order. And that’s what grouping
“related” pages (whether in the tab bar or inline) helps you do: you move
from one page to the next in the order in which you normally would.
Personally, if I open up a few tabs from my e-mail, I will usually read them
in that order, usually in one shot, mentally separated from any other tabs I
may have open. They’re related in my mind, even if they’re not really
related, because they’re grouped in my mind and in my browser as a reading
queue that I must get through.

In short, I don’t think it’s necessary to worry about when a spawned page
should be added to the queue or when it should create a new tab. People can
always move a page to a new tab, and we could, in time, observe how often
this is done. I’d be open, however, to changing the behaviour specifically
for links set by the page to open in a new window (this is the default for
links in both Gmail and Google Reader, for example) and seeing how that
works.

A normal browsing session probably starts with one or more tabs opening as

It sounds complex if you just count the words in the description; I don’t
think it’s actually that complex, once you’ve read it. I must admit, I want
to play with this right now.

There are a few issues with this, though. From what I understand (please
correct me if I misunderstood), web apps would behave, in terms of launching
pages, in much the same way they would now: by creating new tabs. This would
create some apparent inconsistency with normal pages, which would open new
pages next to them inline in one tab. I can see the argument for why this
might be necessary, but I fear the consequence of proliferating different
mental models in people’s minds, rather than simplifying the interface and
aligning it with current mental models.

A related issue is that we should be careful introducing more forced
hierarchy into the browser. We already have two layers of task management in
most systems: that of the operating system, and that of the browser. It
often feels artificial and confusing, on top of forcing us to deal with
unnecessary complexity. The trend towards making the browser replace the
operating system is a good thing in this respect, as it will unify the
different task management systems. (This is why I had no window controls in
my mockups, because they depict an ideal environment where Firefox is the
operating system.) So, when dealing with web apps, we should be careful not
to reintroduce a separate layer that works too differently from normal web
browsing. I’m not saying that it’s not a good idea; it’s just tricky to do
right.

*Aside: *Personally, I would love to see Ubiquity become truly ubiquitous
and cross-platform. (Funny how we’ve come full circle.) Ubiquity’s promise
is to get us out of application silos and let us use their commands
anywhere, not confined to any one specific web app. Imagine if this goal
were achieved in future. Web apps would then be reduced to content viewers,
while the tools they provide to deal with that content would work outside
the app. This is the promise of a content-centric future, rather than an
application-centric one. (As Aza Raskin said, away with
applications<http://www.youtube.com/watch?v=3UwZkKsWgc0>!)
So, making web apps even more prominent and moving them into their own modal
worlds would clash with that future. That’s my own pet peeve with web apps.
I cannot do much about it now, but this is the direction I would prefer.

Like split-screening two windows... That sounds pretty awesome (I'd sure use

That’s exactly what I had in mind. If the screen isn’t wide enough, the two
tabs would remain one behind the other.

I like the look of the card stacks; they clearly show the complex

I was thinking that this could be done if we kept the need to close pages,
rather than trying to be clever and take care of that automatically (that
can be revisited in the future). In that situation, the issues with web apps
and revisiting unfinished pages don’t really exist in any serious form. If a
page/tab/card is still around, you’re not done with it, be it an unfinished
article or a web app. There would be no Back/Forward in this system, as all
links are opened in a new card within the same stack, so the stack is a
(partial) visual indicator of your history. Any web app, in this situation,
would usually remain the left-most card in the stack. Opening up a new page
from scratch would always be a new stack. Basically, it’s like I described
earlier, with tab groups replaced by these stacks. I was also imagining
using gestures similar to the swipes in Firefox for mobile, where you swipe
to either side to reveal the next “tab” in the sequence, and where you could
also zoom out to see all of Panorama. Going “back” and “forward” would be
very simple there, since it would be something like a long swipe or two
swipes. I also imagined that, when you got to the bottom of a page, if you
kept dragging the page up, it would just go away (similar to the way you
close a page in webOS, by throwing a card upwards while zoomed out), and the
next page would take focus. So it would partially keep my original idea of
using scrolling to move forward in the queue, since you could always keep
scrolling to the bottom of the page ...

read more »

I watched this and also "Don't make me click"<http://www.youtube.com/watch?v=EuELwq2ThJE&feature=relmfu>today when I got home from work.  I can honestly say now that I am even more
excited than I was before about the technologies we are discussing and
(hopefully) pioneering here, and about where they could go.
I have also read your proposal for a ZUI browser (couldn't find the link
just now), and after playing with Social Helix <http://socialhelix.com/> and
Enso <http://www.humanized.com/enso/launcher/>, I can see clearly what
inspired you.

Aza Raskin also said, "You cannot be better without being different".  It is
my hope that the developer community remembers that and takes on some of the
challenges you've put before them!