Monday, June 26, 2006

Visual representation of M1

Since tomorrow is a 20% day I have decided to post a short movie this evening. The hope is that by the time I return on Wednesday morning there will be some reasonable feedback based on what you see.

I used iShowU to create this Quicktime movie. It cost me $20 and I'm pretty happy with it so far. No, I didn't get iShowU for free and I am not being forced to promote it.

So, without further ado, a tab-scrolling Camino demonstration! (4.6MB)

Bugs that still exist in the code:

  1. Newly created tabs that are selected do not cause the tab bar to scroll along to make it the right-most tab.
  2. The current scroll buttons do no indicate whether or not it is possible to scroll further in that direction.
  3. Resizing the window while scrolled away from the left-most tab causes re-draw problems.
  4. If a tab is currently selected and is to the immediate right/left of the tab bar then there is no divider.
  5. Upon closing a tab that is right-most in the tab bar the tabs are not resized correctly. This is a regression from the first patch submission to the second patch submission.
The only open bug that causes me any concern is the first one. Bruce has suggested that it might take a further patch to fix that problem.

Some open problems that I'd appreciate feedback on:
  1. If a user has 100 tabs open, how can we make it easy for them to scroll to the tab that they want to get to?
  2. How should a user be able to determine how many tabs they have in the active window?
  3. How animated should the scrolling transition in the tab bar be?
I have no idea how many people read this blog daily, so I hope that it is not too much of a bandwidth hit for the host!

23 comments:

Anonymous said...

So, generally this is not too bad; as long as the widget to the tab you're viewing remains in view, life seems OK. It gets disturbing to see the tab bar moving around when the tab you're looking at doesn't change and you can't see its widget, though (note that previously, to cause the tab bar to move, you were using the keystrokes and changing which tab was active/in front of your face).

When determining the minimum size of tabs for a given window width, you also need to take into account the width of the right button so that the tab always ends such that the button is exactly 16px in width (plus the border, etc). Right now in my window I have a button that looks about 20px, but those last 4px are actually blank tab bar, so I can double-click there and create a new tab--some 20 tabs away from this one. It looks odd, and the behavior is even more inconsistent.

Regardless of how we decide to let users determine the minimum width of a tab (aka how many tabs in a given window width), I don't think it should be smaller than a few px + close button + favicon + 4 characters + a few px, for usability purposes. Anything smaller is just a nightmare.

Back to question 1, I still believe that some method of displaying the overflow menu is the best way of handling large numbers of tabs (though that causes problems with imagery, as nougatmachine pointed out). I keep trying to click that right button to get to a tab to the left and find my tab bar moving instead....

At the very least, if nothing else changes wrt this issue in the current implementation, clicking and holding the buttons should continue to scroll, I think. Clicking for every single tab takes forever....

As for the transition, it needs to be more animated/smoother/fluid. Right now it's very "sharp", just like changing tabs....

All in all, still impressive work!

Sam Rae said...

Looks like nice work! To answer the questions from my point of view:

1) I think if someone has 100 tabs open in one window then any tab management system is going to feel the strain. Perhaps you could have this scrolling system combined with a contextual menu that you get by holding down the right arrow button, so that you can choose a tab way down the line.

It might be nice to have arrows to get to the very end and the very start of the list of tabs. I often need to do that.

2) It would be good to have a small icon with the number of tabs open somewhere in the tab bar. Maybe you could even have a number/total system (eg. show 3/20 on each tab). That might take too much room, though.

3) I think with tabs it's essential to be quick and have a snappy feeling, so I think you should go for the minimum animation required to show that the tabs are scrolling. One of the things I like most about Camino is the application's responsiveness. It would be great to keep that going.

Anonymous said...

A couple ideas come to mind. And they are just that... ideas... thinking outloud. Take from them what you will.

1. Being able to right click on the arrow to display a menu of the hidden tabs, then being able directly select which tab you wanted. When you select the tab from the contextual menu, the tab-bar then slides rapidly to the point where that that tab resides in the heirachy.

2. When you click the arrows to view your hidden tabs, your currently selected tab stays in place, but the scrolling tabs appear to slide underneath it. ... or ... Your currently seleted tab slides to the edge of the browser (the opposite of which the direction your scrolling), but stops when it reaches the browsers edge and then the tabs begin to scroll underneath it.

3. Hovering over the tab scroll arrow provides a tooltip indicating how many tabs are hidden.

4. Keyboard shortcuts.

Anonymous said...

Nice to see you're making progress.

With respect to the "100 tab" question, I think it's really beyond the scope of this method to handle such a large number of tabs.

The scrolling arrow method is an enhancement on the current popup menu to navigate the occasional overflow situation the majority of users may encounter.

For the (dare I say) minority of users who open an extreme number of tabs, another method to wrangle such a large number is warranted. Perhaps a menu, or the already discarded tab expose proposal.

I concur with the other comment that each click should scroll an entire "set" of tabs (determined by the window width) instead of a single tab.

The addition of start/end buttons as suggested would also be helpful. This could also tie in with a counter in one of two ways:

[range of tabs on display/total # of tabs]

or

[current "page" or set/total # of sets]

It's a UI concept that I think most people are familiar with, and could also provide at least a bit of assistance to those who open lots of tabs.

Those users could mentally note the approximate "number" of the tab or the "page" they seek, and quickly scroll to that particular group in lieu of whatever solution is adopted for the 100-tab browsers.

I realize it could get really complicated if the window is resized, but it's an idea I thought I'd throw out for the smart guys to consider.

Desmond Elliott said...

Thanks to everybody who responded, I appreciate your thoughts on this matter.

nougatmachine: We are already aware of the need to change the icons at either end of the scroll bar. As far as I know, Jasper is thinking about this.

stridey: We have indeed spoken about this and it is something that I'll work into the patch eventually. The plan is to shift by the number of tabs visible when a user clicks on the scroll button.

smokey ardisson: You are not the first person to say that and I doubt you will be the last. There has already been some conversation about whether or not the active tab should change as you scroll and the overwhelming response was no. Thanks for trying out my rather meager patch!

sam rae: I do indeed have my own reservations about people using 100 tabs at the same time, but people do it so they need to be thought about.

We have thought about having those little arrows, but have some concerns about the amount of extra space they might take up in the bar.

jim barraud: I like your idea about showing the number of tabs left in a certain direction based on tooltips on the click buttons.

sicksadworld: The tab expose proposal has not been dropped, we just haven't thought about it enough yet and when we do work on implementing it we want it to be great!

Anonymous said...

I like it. To add to your 'bugs':
There isn't any visual indication that a new (set of) tab(s) has been opened if they open after the fold. (Like when you open the tech bunch of tabs in the demo)

I think this might be confusing to users.

Anonymous said...

(Coming late to the comment party!)

It interesting what people are asking for in the comments. (Inevitably?) people are asking for contradictory things, which is never easy for the poor guy coding the patch.

My 2p worth:

Making the active tab visible whenever you change the active tab is the core reason for changing from the overflow menu. You can still scroll such that your active tab isn't visible, but any time you change active tab (or load a new page in your active tab?) we should adjust the tab bar so it just becomes visible.

If we're using the "scrolling" model we need to behave like other instances of scrolling that users are used to. In particular:
* Clicking and holding on the scroll button should continue scrolling in that direction
* We should do "smooth scrolling" (which I think is what is what smfr means by 'animation').
* The first two imply that the natural unit of scrolling should be one tab, not the n visible tabs.
* If we readjust the scroll position to highlight something (i.e. the active tab) we should scroll only by the minimum amount necessary to make it visible, rather than trying to always force it to a particular position.
* The graphics used should look more like horizontal scroll bar buttons than toolbar overflow ones.

I quite like the idea of still being able to get an overflow menu, but I'm not sure its worth breaking the "hold down to continue scrolling" habit that everyone has developed from scroll bars.

However we shouldn't hold out until everything is "perfect" before committing something.

Anonymous said...

Scrollwheel support would be a big bonus for the aforementioned '100 tab' crowd. Decisions would need to be made re: direction of scroll -- whether you limit it to horizontal scrollwheels (mighty mouse, many third party mice with 'tilt wheels') or scroll with vertical input too. This also raises the issue of whether the tab bar needs to have focus to accept the input, or whether you'd do it on hover.

With regard to having the 'left' and 'right' scroll buttons, you may want to consider honoring the user's system preference for scroll arrows: one at either end, or together at one end.

Anonymous said...

For scrolling of large/arbitary numbers of items, there is this amazing UI invention called.... a scrollbar.

I don't mean to sound snide or sarcastic - I am serious; I have never seen anything to beat a scrollbar to perform this UI task. It would have to be a very thin (like 3 pixels high) scrollbar intimately connected to the tabs area (grey lines just above the tabs maybe?), but I strongly believe a scrollbar of some form should be seriously considered. I think the buttons-on-the-ends paradym that has come into vogue since Apple's Dashboard Widget chooser came out is seriously flawed.

Anonymous said...

Required reading before implementing this:
http://arstechnica.com/staff/fatbits.ars/2006/3/12/3146

Anonymous said...

The 'poor pickers' thing is valid, but it stems from a simple truth that most people don't like horizontal scrollbars. It took long enough for the web-using public to figure out how to use vertical scrollers and would actually read content below the fold.

@Mark Whybird: sounds interesting, but I think you'd have trouble conveying the 'scrolliness' of such a tiny bar.

Anonymous said...

@ Anonymous - thank you! I totally agree!

@ Chris Clark some pixels like this might work:

 *             *****     *
**  ********-----***  **
 *             *****     *

(fingers crossed that all those nbsp's add up to readable ascii art!)

Anonymous said...

Hrmph.

sorta like

< ----==- >

is all you need, maybe.

Anonymous said...

Could be a nice idea. One Problem: if the tab for the current page is not visible one cannot close it directly with the x button. You have to scroll first to make it visible again...

Anonymous said...

All this is why, despite complaints at its waste of screen real estate, OmniWeb's tab implementation is still far and away the most usable.

@nevyn: The biggest problem with Safari's chevron menu is the inability (outside keyboard shortcuts) to close the active tab when it's buried in the menu. Or even to see the active tab when it's buried in the menu. There are easy enough ways to solve that, though.

Anonymous said...

Hmmmm... why not a menu chevron a-la Safari at both ends???

Then, when you select one, move the manus over to put the selected one within the curently diasplayed set.

(still leaves the 'how many tabs are open right now' question open. I'm almost tempted to consider a (gasp) number very small and faint near the chevrons. Sounds ugly even just typing it.)

Anonymous said...

Sorry, but I think this is "animated UI" for the sake of it.

What UI problem does it really solve that isn't solved by either (1) getting new tabs to open in the foreground or (2) clicking on the "more" chevron on the right? I often have dozens of tabs open; this would be too much churning for the poor CPU/GPU.

Keyboard shortcuts to move between windows (and to close them) are far more efficient than mouse moving, too.

Having a click (or keyboard shortcut) jump a window's worth of tabs would be HORRIBLE. Just think of Microsoft's two-deep preferences, and how clicking on the back one brings that to the front. Awful, awful UI.

Face it, people: this is not broken. It does not need any amount of fixing.

Anonymous said...

@Charles: though I agree that the scroll idea is just animated UI for animated UI's sake, and doesn't particularly solve the problem at hand, I think you're wrong to say that the Safari-style chevron menu isn't broken.

As said earlier, a tab selected from the chevron menu is not actively visible on screen, and mouse users cannot easily close it -- something I hear complained about quite regularly. A close button alongside each item in the chevron menu would solve this problem.

A personal preference for keyboard shortcuts (which I share) doesn't mean mouse users should be second class citizens.

Anonymous said...

Fred: No need to program a special option to switch to Cmd-{ / Cmd-} (aka Cmd-Shift-[ / Cmd-Shift-]); simply use the OS's built-in keyboard shortcut remapping feature in the Keyboard & Mouse pane of the System Prefs to remap the Next Tab and Previous Tab commands ;)

Ian McKellar said...

Epiphany has had this interface to tabs for a long time and they use a Tabs menu that contains a list of all the tabs in the current window. Its works really really well.

Steve McFarland said...

I agree with those who have pointed out the UI inconsistency between the double-scrolling arrows conflicting with that drop-down menu that double arrows bring about most of the time.

However, if you go for the drop-down, I woud love if there were a way to bring the selected tab back into focus. When I have too many tabs open in NetNewsWire, I have no way to close the ones that are off to the right in the drop-down. I have to start closing some of the ones in view just to get to the ones out of view. Needless to say, it drives me insane.

Looks like great work, though!

Anonymous said...

Tabs Field Scroll:

Option-Scrollwheel

This would be a similar behavior to Shift-Scrollwheel for scrolling webpage horizontally.

Anonymous said...

Excellent work. I wish I new how to program as well as you. What I would really love to see implemented in Camino is an Omniweb-like tab implementation. There is an extension for Safari called SafariStand that gives Safari a similar feature (as well as a few others). What I really wish is that someone would port SafariStand over to Camino. Call it CamiStand. I used Camino for a long time--it's so fast--until I found out about SafariStand, and now it's the one thing that keeps me using Safari over Camino or any other browser.