Closed Bug 159510 Opened 22 years ago Closed 20 years ago

Remove tabs, replace with something more Aqua-like

Categories

(Camino Graveyard :: Tabbed Browsing, enhancement)

Product:
Camino Graveyard
Component:
Tabbed Browsing
Platform:
PowerPC
macOS
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID
Milestone:
Future

People

(Reporter: st, Assigned: mikepinkerton)

Details

(Keywords: helpwanted)

Attachments

(4 files, 2 obsolete files)

One possible solution - replace the tab bar with a "Page Cache" drawer.
3.76 KB, text/html
Details
SizeComp.png
21.51 KB, image/png
Details
newtabs5.png
36.94 KB, image/png
Details
newtabs5_doc.txt
10.61 KB, text/plain
Details 
Tabs are intended for dialog boxes, a situation where there is a static, low
number of tabs (say, two to five). Conversely, Chimera is using the Tab control
in a situation where there is not only a dynamic number of tabs, but the user
can create as many as they like.

mpt writes eloquently on some of the problems with using a tab bar:

    http://mpt.phrasewise.com/discuss/msgReader$294

On the other hand, the incredible popularity of tabbed browsing reveals that
people are likely to put up with a lot of bother to have a less messy interface
for managing large numbers of web-pages.

To summarise, tabs are Bad but tabbed browsing is Good. The obvious solution is
to use a different widget instead of the tab control.
My suggested solution to this problem is in this attachment (complete with
**** mpt-style ASCII art! :) 

It does everything tabs currently do, but also provides:

* an obvious way to add new pages
* an obvious way to remove pages
* an obvious place for pages to go when there's too many to fit on the screen.
I rather suspect Chimera's committed to tabs for 1.0, but perhaps this could be
something for the future.
Summary: Remove tabs, replace with something more Aqua-like → [RFE] Remove tabs, replace with something more Aqua-like
we talked about doing a drawer instead, but it is a little less obvious UI-wise
unless we do soemthing custom. Plus then you have the conflict with the
bookmarks or you start getting drawer happy, which isn't good from a screen real
estate perspective.
Obvious to whom? In what circumstances? It's not mentioned in the spec, but I'd
assume that the drawer would automatically open under the same circumstances
that the tab-bar currently appears.

I suppose it isn't as immediately comprehensible as a tabbed interface, but I
don't think it would take more than five seconds to figure out, and it makes
more complicated usage (the whole drag and drop interaction) more obvious.
There's drag and drop lists all over OS X, but very few drag and drop tab-bars.

I agree about getting drawer-happy, though. In a world where everything
conformed to my wishes, there would be a page-cache drawer and a seperate window
for bookmarks so screen real-estate would be conserved. Unfortunately, this is
not such a world. :)
FWIW, I thought IE's Scrapbook feature looked great, and expected to use it
frequently. I also thought Mozilla's tabs were questionable from a UI perspective.

Guess which one I use all the time and which one I don't? (I don't use the IE
Scrapbook, and I do use tabs. Go figure.)
I've been thinking to another solution to replace the tabs area by a popup menu.
That's the way to show tabs that's inefficient. It uses a lot of space.

For example, in a tabbed window the title of the page in the title bar is
replaced by a popup menu with a rectangular frame and a small down arrow on the
right.

Title like now = 1 window without tab.
Title inside/with a drop down menu = 1 'tabbed' window.

Of course the name "tab" should be changed to "Page".

The advantage of the title popup menu is :
- uses less space
- can contains more items even when they have a huge title/url
- does show/hide the tab bar when there is only 1 tab/page.

The close problem can be solved like this:
Close Window (and all its pages)= Cmd-W
Close Page = Cmd-Shift-W

That means that if there is a window with only "1 tab/page", Close Page is
equivalent to Close Window.

An alert should be issued if a Close Window is issued when the Window contains
more than one page.
Whatever's decided, it can and should be created in Mozilla experimentally first
so people get a chance to try it before it shows up in Chimera.
Having a drawer replace tabs will completely suck. In an abstract sense, it's a
cleaner solution but functionally it requires *much* more screen space to do the
same thing with little benefit for most people.

While tabs are conventionally used in dialogs, they're still view containers and
users recognize that switching to another tab switches the content.

I think you're in danger of ruining one of Chimera / Mozilla's best features to
solve a problem that nobody cares about. Don't do it. This is a power user
feature, trying to make it "mom-safe" just isn't relevant to who is going to use it.

Tabs are not a power-user feature. They are reasonably mom-safe already:
basically quirk-free and cleaner to use than multiple windows. The tab metaphor
in itself is very mom-friendly, since it's based in the real world (unlike
pop-ups or child windows, such as drawers). I'm hoping for WONTFIX, since the
alternatives either take too much space or are too unwieldy.
The main reason I'm worried about the tab-bar is that I'm afraid it's going to
get all unwieldly and bloated with context menus, close tab buttons, new tab
buttons and so forth, like Mozilla's tab bar. You can't claim that tabbed
browsing is a simple and familiar metaphor when you're using such non-standard tabs.

At the least, what we need is some kind of UI spec that we can point to when
stupid requests come in. "Look, I'd love to add a 'Bookmark this range of tabs'
item to the tab context menu, but it's not in the UI spec, so...". 

Given that people *will* want context menus, drag-and-drop in every corner of
the app, new tab and close tab buttons, the idea of the page-cache is to have a
user-interface where adding such things doesn't look stupid or over-detailed.
I think the solution for these issues (based on other bugs), will be to have a
new tab button that you can add to the toolbar, not in the tab itself, and the
ability to close tabs via context menu, but not to put a close tab widget on them.

Adding context menus and drag-and-drop is not bloat, but quite to the contrary,
it enhances ease of use. You should be able to get a context menu for anything
in the app and drag-and-drop should work with everything in the app (and there
are already bugs coving these). What would be great to help with drag-and-drop
with tabs would be to make them spring-loaded, but I don't think we even need to
think about things like that until 0.9 ;)

Also, tabs are definitely not used only in dialogs and preference panes; look at
Project Builder. You can probably have around 10 tabs open in the main window,
and some on different sides, if you're going for a one-window workspace. The
only thing that's unique about Chimera is that you can contol how many tabs are
open at once, but if we're aware that this is a unique situation with our
application and follow the guidelines for extending the UI, this is not a problem.
I'm a programmer, but Project Builder scares me. Project Builder's use of tabs
is wild, crazy and no doubt evil - also, PB doesn't have to deal with tab
creation and deletion, all the tabs are fixed in number. The closest thing to a
tabbed interface that PB has is the little "choose a recent or open file" popup
list.

Anyway, I just wanted to mention that apart from AIM client (whose name I
forget) that gave me the idea for a Page Cache drawer, Aquisition has also
implemented something astonishingly similar:

http://www.xlife.org/aquisition_screenshots.php

In Aquisition, the things on the left are "searches" - you make a new search by
typing in the search toolbar widget, and you delete a search by clicking on it
and hitting the delete button. You can flick between them by clicking on
whichever search you want.

I've played with it for about five minutes now, and I think it's really nifty.  
I like the drawers, but can't reconcile that with the fact that my monitor is
4:3, not 3:4.  16:9 screen users will have even more to complain about. 
Additionally, since the drawers are always shorter than the windows they're
attached to, use of a standard drawer is going to result in lots of scrolling
for the user.

Maybe if the drawer could wrap to be 2x, with some thumbnails (sort of like the
new Preview) and a title caption, looking something like the iPhoto organizer...
Component: General → Tabbed Browsing
QA Contact: winnie → sairuh
I vote for a popup menu with all of the open 'views' and two buttons next to it labeled '-' and '+'. It could even assign the first nine views to cmd-(1-9). The popup menu could go in the toolbar or, better yet, on the right side of the status bar at the bottom of the window. Also, the list of tabs/views should be in the menu like the Window Menu does. (IMHO, there should be a Tab/View Menu separate from the Window Menu for this kind of stuff.)
Summary: [RFE] Remove tabs, replace with something more Aqua-like → Remove tabs, replace with something more Aqua-like
In the spirit of something more "Aqualike".. how about employing a totally new
kind of interface element more like a "sliding rule"?  Has anyone here seen the
Drive 10 utility?  The way that it has like a sliding display with a focus
window in the middle.  I've looked at that many times and thought, that's cool,
couldn't it be used for other things?  The tabs are messy in part because the
open tab is always located in a different place in the row and it moves around
everytime a new tab is opened..  Why not put use ~ the same amount of space as
is used now, but make the tabs less staticly positioned.. put them on like a
conveyer-belt or slide-rule kind of arrangement which wraps around and provides
a "window" in the middle where the currently viewed tab is always located, and
its name is more "in focus" to make that obvious?

I'm up for a radical departure from tabs, but not tabbed browsing.  

The other idea I had was to make it so you could have a vertical version for
users with scroll wheels.. where they simply hold down alt and scroll the wheel,
and a vertically arranged list of tabs "pops up" in a floating window over the
current screen.  In the middle is the highlighted current tab.  As the wheel is
scrooled, the list moves up and down, and when it rests on a page name, and the
user lets go of alt, the popup window collapses into nothingness and that page
comes to the forground. 

>"Whatever's decided, it can and should be created in Mozilla experimentally
first so people get a chance to try it before it shows up in Chimera."

I really have to take issue with this comment.. I would agree that if we were
designing the interface for Mozilla's future, we should leave it up to doing it
in Mozilla first, but why should we leave it up to the Mozilla project
exclusively to engineer the interface elements for Chimera?  That will leave
Chimera with something very unaqualike which can't take advantage of any of the
capabilites of Aqua or other advantages and features exclusive to Mac OS.  If we
don't take the lead in engineering interface advances for Chimera to advantage
of what additional capabilities OS X has to offer, then essentially we're
letting Window$ users decide the best UI for Chimera, and in that case, we might
as well fold this project right now and stick to Mozilla... because, then what
would the point of having a Chimera project outside of Mozilla be?
I think the drawer instead of the tabs is a good idea. I think splitting the history panel in 
half and assigning the new half of the drawer to the ?tab/window-list? would be a good 
use of generally wasted space. 

Conceptually both history and currently open windows have some relation that we could 
work with.

As far as appearance of this drawer, I would look to the layers palette in photoshop or the 
drawer in Preview (default pdf viewer in OSX10.2), i.e. a snapshot of the window with title 
beside it.

Now regarding the suggestion of a pop-up item is that not already there? It is called the 
window menu. It would be cool for that menu item to have a list of the current open tabs 
as well as all chimera windows.

Something like this would be in the window menu:

Window
--------------------------------------------------------
Minimize Window
Zoom Window

Previous Tab
Next Tab

Bring All to Front

Untitled (would be the same as the current foreground tab)
   Slashdot.org
   Mozilla.org
   Bugzilla
   Untitled

Untitled 2
   Untitled 2
   Google Search: Bug 159510
   Bug 159510 - Remove tabs, repla....   
-----------------------------------------------------

Something has to be done...tabs are not supposed to be used this way. IMNSHO. :-)
In self reply to #14, A popup menu/button would work quite well. It would only
add one more click to the UI vs. tabs and it would look similar to Project
Builder, without having the unique PB page environment itself. Having simple +
and - buttons next to it will also help.
This should probably be resolved WONTFIX. Mozilla has demonstrated that tabs are
a viable feature that users are, in fact, using. It is only natural for Chimera
to provide this feature as well. And, indeed, tabs are seen elsewhere in Aqua
apps, and so are hardly un-Aqua-like.

That said, there is room for additional features like those suggested in this
bug. However, since Chimera provides the tab feature, and is supposed to be kept
simple, it's unlikely these other features will be implemented.

My suggestion would be for those interested in such features to start a
derivative browser project based on Chimera's code.
WFM..  I see no reason to get rid of tabs from Chimera right now when there are
too many other more pressing things that need improvement and fixing.  I agree,
it's such a major interface rework, it should be it's own project derived from
Chimera source.. or it should be reconsidered after a version 1.0 is reached..?
 Maybe put it off for future reconsideration?
Futured then.
Target Milestone: --- → Future
Tabbed browsing is an Insanely Great Idea(TM). It only takes 1 click to switch
pages and doesn't use up much screen real estate. That's why it's Mozilla's
killer app (along with pop-up blocking). Stephane's idea sounds interesting, but
the idea of clicking and dragging to switch pages makes my wrists hurt. And I
certainly wouldn't want to open a drawer every time I feel like switching to a
different page (and leaving the drawer open would use up far too much of my
ibook's screen). If it ain't broke, don't fix it. Recommend WontFix. Sorry for
the spam. Too bad there's not an easy way to vote against a bug :(
The problem remains that there are many, many oddities that derive from the
tabbed interface as it stands now. Futuring the bug works for me.
The popup menu is the best solution, even if it's not implemented now.

In build 1205, even if you open a Local file from your HD the title is not
showing the path, like in Finder. I think it would be useless because you can
find the "Recent Items" menu in the Apple menu.
That's Apple who must implement the CMD-Click in the "Recent Items" menu, like
for the Dock to show the corresponding item in the Finder.

Having a popup menu like in Finder solves all the Tabs problems.
It has proxy icons, can handle an 'unlimited' number of items (tabs/pages) and
not just 16.

Adding + and - icons (around/close to) it is useless, we have already 2
shortcuts "Previous/Next Tab" and the following shortcuts: next paragraphs.

If that Menu is acting like a normal menu, drag or click then drag, meaning it
remains opened, the user can hit a key to reach an item just like in a Form
Popup with arrows, or extended to other keys.

Shortcuts can be added automatically e.g.: CMD-CTRL-[0...9 then a-z] that makes
already 36 immediately reachable.

For those with wrist problems, a Shortcut can display that menu, just as if you
had made a click release then drag, like in the menubar.

The Window menu in the menubar can be hierarchical, with a Right Triangle to
show the submenu with all its 'tabs'.
For the main title in the Window menu, the current 'tab' name is used, just add
a submenu to its right with a checkmark in front of the current 'tab', itself.

Instead of showing a rectangle to inform it's a popup menu add an icon in front
of the title : Single Page or Multiple Pages like in the Bookmarks menu.

This will allow you to drag on page or one tabset into the Bookmarks Sidebar or
the Bookmarks Toolbar or the Finder (=Save As HTML Complete).
If you don't like that additional S/M Page icon, when a proxy icon is dragged to
a Bar or Finder, a dialog should appear asking Add that Page or Add the Tab Set.
To avoid that dialog holding down the Option key can be used to say immediately
that is the Tab Set.

A neater solution would be to use (1 icon + Title). A single page shows the
Favicon and a Multiple Page shows a Multiple Page icon, no favicon (visible in
Location field). It will be more consistant with what we have now in the
Bookmarks sidebar or menu.

That solution respects all AAHIG.
I hate to spam, but please leave tabbed browsing alone. It's the one thing about
Mozilla (and Chimera) that most people universally love. It'd be like replacing
the steering wheel of a car with a joystick.

A popup menu might adhere to the AAHIG better, but it isn't nearly as intuitive,
and real-world scenarios where they're deployed (OS X print dialogs) suck.

Apple isn't always right. This is one of those times. If you have any doubt,
check out the awful print dialogs that use a popup menu to navigate the
different 'panes'.

Now to go spam 169838 (moving status bar to the top of the window), or maybe
file a bug against bugzilla requesting the ability to cast negative votes.
Attached image newtabs3.png (obsolete) — 
AAHIG says it's not good to change the behavior of a know control.
The new design is intentionaly flat trying to show a sheet-of-paper, to make
them totally different than Apple's tabs.
Just an idea to nicely fit all the features required.
I'm thinking that one solution might involve something more like the dock.
In favor of the newtabs2.png... It's definitely "more aqualike" than what we 
have now...
Attached image newtabs4.png (obsolete) — 
Clearer, showing single and multiple pages.

To avoid any confusion with Apple tabs, "Tabs" are renamed "Pages" (Page
Controls), which is what they really are.

A Window can display a Single Page or Multiple Pages.
A Window contains one document with one page or several pages.
A Window saved on the Finder will be represented as one document (htmld), no
matter if it contains one or several pages.

A Page can be dragged and dropped over another Page, to replace its contents,
by dragging it with its Proxy icon only, not by dragging it with the Drag
Control.
The cursor is changed to a pointing-finger-hand when it's over the proxy icon.

A Page Control can be moved inside the Page Bar by clicking on its Page Drag
Control (just below its Close Button) and dragging from left to right.
The cursor is changed to a double horizontal arrow <-> while it's over that
area.
Attachment #108793 - Attachment is obsolete: true
Re to comment #28, I think that's a wonderful UI concept. Not only does it make
Chimera's non-standard tabs look different from Apple's standard Aqua tabs, it
also accommodates the close widget quite nicely. As Stephane pointed out, the
HIG warns against making standard-looking controls act in a non-standard way.
Apple says that if a custom control is required (as in Chimera's case), it must
also look like a custom control. Stephane's concept follows this major guideline
and also manages to fit into the Aqua interface very nicely.
I like it! Of course, you should be able to drag and drop tabs by dragging the
"title bar" under the close button.
Vote for newtabs4...  
Newtabs4.png looks good with only 3 tabs, but I'm a little worried about all
that visual clutter limiting th enumber of tabs you can effectively have open at
once.
The current 16 tab limit is bad enough, I wouldn't want to be even more restricted.
>Newtabs4.png looks good with only 3 tabs, but I'm a little worried about 
all that visual clutter limiting th enumber of tabs you can effectively have 
open at once.
>The current 16 tab limit is bad enough, I wouldn't want to be even more 
restricted.

I don't think this is a problem at all.. If there are too many tabs, it can either 
shrink the font size, and/or hovering the mouse over the tab can display 
the full name of the smaller sized tabs..  

Call it a stupid question, but why would anyone want that many pages 
open anyways?  Are we just trying to create an exercise in programmer 
misery here or is there a real practical reason why anyone needs to have 
more than 16 pages open?  Typically I have only 3-5 open.. a webmail, 
some news sites, versiontracker and something else I'm actively 
reading... At some point you need to just close stuff you aren't really 
reading or bookmark it for later.  If anything, this change offers an 
improvement for anyone who actually needs that many pages open.  In 
the case of say 32 pages, each page "tab" could theoretically shrink down 
to the size of the page titlebar width only.. and hovering the mouse over 
each one can display the full title.



attachment 108864 [details] looks lovely! now, the usual question would be, "how difficult
would it be to implement" ;)

to respond to comment 33 about wanting more than 16 tabs open: not a dumb
question at all. i agree that having that many is both unwieldy and maybe even
uncommon. but one feature that runs up against this limitation is the ability to
convert the contents of a bookmarks folder into a tab group --and i can
certainly see a bookmarks folder containing more than 16 items (see bug 181402).
nevertheless, i do hope that a new tabbed browser implementation would be able
to workaround the 16-item limitation.
I'm willing to put it some time implementing a custom control like the PNG
shows. Of course, I haven't done it before, and it'll be in my spare time over
winter break (hurrah for University students!), but I can probably pull in
another person or two.
Concerns: I might click on the close button when I'm trying to drag the tab. I
might click on the button even when I'm just trying to click on the tab. I think
this is a basic problem with the whole tab concept.

Also, I don't think it needs a special "drag" area, the whole thing should be
draggable.

Just as an alternative idea, how about placing a control to close the tab at the
very top of the vertical scroll bar (where the PDF viewer plug in from Schubert
IT places a little drop arrow for a menu). I imagine a small control there
(perhaps a gray circle with an X in it, like in ProjectBuilder when you have
multiple panes). Or of course it could be a little red bubble.

That would be separate from the tabs so it wouldn't interfere with the "tab"
widget of aqua.
I didn't think I would like any of the alternatives, but those PNGs fix my big
annoyance -- the how to close a tab thing. Just make sure whoever ends up
implementing such a solution doesn't get too carried away with the drag'n'drop
or Adobe might sue like they did Navigator... How many pieces of a patent have
to be covered for it to be an issue?

Definitely don't go to adobefacts.com. I think Adobe must have let it lapse and,
don't go. Here's the patent if anybody cares:
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=5546528.WKU.&OS=PN/5546528&RS=PN/5546528

Should this now be a new/different RFE? It seems like things have turned toward
a restructured tab system, rather than replacing the tab system in general... I
vote this goes into the hands of those in charge of Chimera's UI/usability.
You can find my full explanation on
http://www.eternaltedium.com/cgi-bin/chimeraboard/ikonboard.cgi?s=3df6ef581903ffff;act=ST;f=8;t=244;st=15
It's a bit long for here, just the end after the newtabs4.png, because the
beginning contains some obsolete ideas for other things (palette, etc).

- If you make an Option-click on close = "Close the Others -Tabs-"
- A spinning cursor covers the icon of each page which is still downloading. For
a single page, it's over the icon in the title bar.
This will allow to get rid of that huge barber pool in the status bar.

Some answers:
++ Comment 36
-close by mistake
Clicking on close by mistake, it's exactly the same for a window.
And that close button is so small!
Normally we'll have "File-Open Recent>..submenu.." (or perhaps via Undo).

-all draggable
You'll loose the possibility to constraint the rearrangement inside the Page
bar. So when you'll drag horizontaly you'll have insertion/rearrange and replace
events together.
You don't drag a window by its contents, only its title bar, a Page Control also
, legend 6.

-close on top of Scroll bar
AAHIG says don't add to much thing there.
Will be strange, can only close the current one.
No space is lost, see below.

++ Comment 32 size-clutter
They have the same width as those from Apple, you don't loose anything.
An Apple tab is made like this (_ === _)  only the (_ and _) are differents and
contains other sub-controls. The _ in Apple are always empty, 10 pixels I think.

The page-corner (top right) can be removed but I kept it because the empty space
below can later be used to resize a single Page Control (tab) or if you hold
down option key all are resized together, like for a window.

I'll soon add the mockup for that 'extended version' with resize control below
the top right corner.
Stephane's new tab design seems to satisfy most complaints and the flatter style
looks better than Apple's tabs anyway. Aside from the extra work to implement
and debug, it seems like a winner.

I'm not sure about renaming the tabs to 'pages' though, since that would
needlessly isolate Chimera users from what seems increasingly like a pretty
common browser UI term. I suppose you could solve that by trying to change it
across the different Mozilla related projects, but they'll probably just laugh
at how uptight Mac people are about not using actual tabs. The distinction to
the average user between what a 'page' is and a 'window' is also seems like it'd
be a bit confusing. I don't have a suggestion off-hand for anything more
appropriate though.

re: more than 16 tabs:  I hit it frequently.  Here's how:

I have a slow modem connection at home (ah, the joys of mountainside living). 
To read news, I have a bookmark group of the news summary sites I read.  So, I
open those tabs, then go left->right through them.  I cmd-click the links I want
to read (set to open in the background, of course) on the news site, then close
that tab.  On to the next summary site, etc.  By time I'm done selecting the
articles, the article in the left-most tab is now fully loaded.  I read that one
while the others are loading.  By moving left to right, I experience very little
load latency with this method.  

I currently have 5 summary sites, so all I need to do is see 4 articles on each
and I've hit the limit.  Yes, the tabs get too small to be informative, but
since I'm just reading left->right anyhow, they only need to be big enough to
click on.

re: newtabs4.png - very pretty
re: comment #36 - 
>Just as an alternative idea, how about placing a control to close
>the tab at the very top of the vertical scroll bar

This is what Mozilla does.  I think it works quite well.  They've basically
factored out the close button, like you'd do in a math equation.
i.e.  
  2a + 2b + 2c + 2d + 2e = x 
becomes
   2(a + b + c + d + e) = x

So, with tabs, where c = close, i = icon, T = title
 ciT ciT ciT ciT ciT ciT
becomes
 c(iT iT iT iT iT iT iT)
or 
 (iT iT iT iT iT iT iT)c
because c is redundant, i and T are unique.

re: comment 38:
>Clicking on close by mistake, it's exactly the same for a window.

No, a window title bar is a much bigger target, so for a given time the user is
much less likely to close the window by mistake.  See Fitt's Law.  This is a
good argument for not including the close button on the tab - Fitt's Law says it
will necessarily make tab selection slower, because you're decreased the size of
the target, and greatly increased the cost of a miss-click.  When users are
slowed down by their UI they tend to get frustrated.  Factoring out the tab will
greatly increase UI speed because the chance of hitting the close button is
greatly reduced, and the cost of missing is just selecting the wrong tab, which
is a much lower cost mistake than accidentally closing a tab (i.e. recovery time
is very fast, vs. very slow or impossible).

re: comment #13 - one of mine - I was completely wrong when I wrote this.  A
Vertical 'Page Cache' drawer can definately hold more 'tabs' than a tab bar,
because we don't have a choice but to write English text horizontally. As an
example, my Apple Mail folder drawer is open now, on my secondary 1024x768
screen. There are 45 folders visible, without scrolling (each with a mini-icon).
Making an allowance for a control wiget at the top, there could easily be 38
'tabs' on this screen, far more than can be handled effectively by the
compressed horizontal tab-bar.   
Simple exercise: take the titles of 20 web pages, put them in a text editor. By
resizing the text editor window and moving the text, minimize the screen space
they take up while maximizing the amount of information presented.  I'll bet a
donut that you're always going to have a vertically-stacked list with the window
bounds clipping the right-end of the longer page titles.
Potential downside: Our webpages are horizontally oriented, we look at them that
way because we write our text that way.  UI's are primarily horizontally
oriented (menubars, etc, are vertical secondarily).  Clicking on an item from a
list in a drawer causes a cognitive context switch hit by requiring a
primarily-vertical target acquisition mode (minimally horizontal).  Some users
might find this disconcerting.  This is probably a moot point, since that
decision has already been made vis-a-vis bookmarks in the drawer.
Attached image SizeComp.png — 
Re: Re: 38 Close by mistake - Fit's Law
The comparison with an average Window and an average Page Control is quite
similar.Window 1/29 and Page 1/26, so not a big difference.
The Close Window is activated around it, hence the border around it.
The Close Page is only activated when you are just over it, no border at all.
Attached image newtabs5.png — 
CHANGES IN newtabs5.png:

(6) Drag-control area with thin gray line as it's a 'title bar'.
(9) Page Grow Control only visible on the Selected Page.
    To modify the width of the Selected Page.
    With Option key down, modify the width of All Pages in that Page Bar.

+ Illustration details when a Single Page is loading.
  Page 2 has a spinning wheel, not the Window.
  The Multiple Pages Window has a fixed Window Proxy icon.


Answers to various comments:
We should not see the Page Controls like icons but like pages/floating
documents, a floating window with its own bar (6).

If we remove the drag-control (Page Control Bar) to do a Command-Drag, like in
the Finder toolbar, to rearrange the Pages inside the bar, we will loose the
shortcuts Cmd-Click to open a link in a new window/tabs like any other link
should do.

A Page Title is a Link, like a link in a web page.

If we keep the drag control, we can do a command-drag with the Page Drag
Control like for any other window. The Page is rearranged but not bring to the
front.
Attachment #108864 - Attachment is obsolete: true
Attached file newtabs5_doc.txt — 
FYI. All the details, explanations, menus, etc about the newtabs5.
> A Page Title is a Link, like a link in a web page.

I'm not sure that makes sense. I understand the command-click argument, but how
does a page/tab title correspond to a link when single-clicked? It switches to
another view; a link typically retains the view but points it to a new location.
I like the new proposal, but the close button/draggable area won't work very
well until bug 159478 is fixed (persistent I-bar or "pointing hand" cursor). 
With an I-bar cursor, it would be pretty hard (possible very frustrating) to
click the close button or draggable area accurately.
newtabs5.png contains a little GUI error, the current tab must be white
(clearer) and the other tabs must be gray (darker than current tab).
I'll perhaps make a new png.

The main critics about this new control seems to be the Close button that might
close a Tab by mistake. I don't find it relevant, all the GUI is like that, eg
Finder.
Solution: Undo or Confirmation dialog (that can be disabled in the Prefs) or
File-Open Recents.
One idea I recently had for my own designs maybe helpful, is to allow the tab to
be selected and then press Delete key to close it. Just a thought.
I'm still willing to implement the tabs as shown, but I'd like to know if people are still truly interested in them. I also wouldn't mind a word from anyone who's successfully subclassed an NSTabView to draw different tabs (not different content cells), though I have a sinking feeling I'll have to reimplement the whole shebang anyhow.
I would vote against any attempts to use the delete key to close a window.. Too much opportunity for error with forms and stuff in pages to accidently close a window that way, but I am very much interested in seeing a build with the newtabs5 example implemented to test out!-Matt
Instead of creating our own custom UI, why not have this?In the window, you would have a horizontal split view (one subview above another). The top subview would contain a table view of the current "schmoos" (tabs) and the bottom subview would contain the rendered page. You could select each schmoo by clicking on them, and remove them by selecting one and pressing the delete key. Another thing is that each window would have the same schmoos in them, so if you closed the window and opened a new one you would be just where you left off. This is similar to the QuickMarks proposal, but is much more Mail-like. (And when I say Mail-like I mean the split view, not the drawer.)One of th biggest things holding us back is the schmoo metaphor. This is where you have current page and can go back and forward. Quite frankly, I don't know why we still have this anymore. It's benifit was that you could start at one page and click links to get somewhere else. However, this day in age we rarely simply 'surf' the net in a linear fasion anymore.
.
Assignee: saari → pinkerton
I think that the Mozilla system works quite well (having a universal tab close
button above the scroll bar), because it allows the user to close several tabs
without having to keep moving the mouse -- a disadvantage for Safari.  Having
tiny close buttons on individual tabs make it rather hard to hit the target for
closing the tab, while increasing the probability of closing a tab
inadvertently. As far as using a drawer, this takes a lot of screen real estate,
although it is the direction OmniWeb is headed in. One way Camino could improve
would be to more closely implement Mozilla's system for tabs, even left aligning
them so the user can remember spatially where a particular tab is -- a difficult
thing to do with center-aligned tabs.

Closing this bug as a decision has been made on the future of tabs in Camino. We
now have our own tab view providing all the flexibility we need for a long time.

Please open a new bug for comments, sugestions or enhancements reflecting our
current and future tabs state.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: