Linked by Thom Holwerda on Sat 16th Aug 2008 16:50 UTC
Graphics, User Interfaces This is the eighth article in a series on common usability and graphical user interface related terms [part I | part II | part III | part IV | part V | part VI | part VII]. On the internet, and especially in forum discussions like we all have here on OSNews, it is almost certain that in any given discussion, someone will most likely bring up usability and GUI related terms - things like spatial memory, widgets, consistency, Fitts' Law, and more. The aim of this series is to explain these terms, learn something about their origins, and finally rate their importance in the field of usability and (graphical) user interface design. In part VIII, we focus on the tab.
Order by: Score:
Opera
by StephenBeDoper on Sat 16th Aug 2008 18:19 UTC
StephenBeDoper
Member since:
2005-07-06

Opera is a bit difficult to classify in this timeline, since Opera had a multiple document interface long before it had tabs - however, MDI is not the same as having tabs.


The implementation in Opera was functionally-identical to tabbed-browsing, though. I generally think of tabbed interfaces as an evolution/refinement of MDI, especially since many of the holdout MDI apps provide a row of buttons to select the active document (as did Opera - tabs by any other name).

Reply Score: 3

RE: Opera
by OSGuy on Sun 17th Aug 2008 01:15 UTC in reply to "Opera"
OSGuy Member since:
2006-01-01

That is correct but not all tabbed interfaces are MDI. Tabs can be used to represent multiple user elements. These elements can either be forms or just plain controls stacked on top of each other and just BringToFront() the control. If they are child forms in an MDI, when a tab is clicked you just activate/show that form and if they are multiple controls in an SDI form, you just bring the control referenced by the tab index to the front. As far as the user is concerned, he can't see any difference except that he won't be able to have multiple views when going with the SDI version because there won't be any child forms to unmaximize. Having an SDI tabbed interface is much more efficient than with MDI. It faster and slicker. FF is a perfect example of a tabbed interface implemented using SDI. It requires less memory too when compared with an MDI version of it but coding it is a bit trickier so you have to know what you are doing. This is especially important when handling events.

Edited 2008-08-17 01:24 UTC

Reply Score: 2

RE[2]: Opera
by OSGuy on Sun 17th Aug 2008 02:09 UTC in reply to "RE: Opera"
OSGuy Member since:
2006-01-01

Now that I think there is a third way too. You can use a real control with page/sheets with tabs and put the controls in there and half of the work will be done for you so no need to worry about activating/showing controls ;) When you think of it, there are many ways.

Reply Score: 2

Taskbars
by StephenBeDoper on Sat 16th Aug 2008 19:04 UTC
StephenBeDoper
Member since:
2005-07-06

This all comes at a price, however. While tabbed interfaces seemingly reduce clutter, they also add another layer of complexity. Most graphical user environments have a single place to switch between windows/applications (the taskbar), and while tabbed interfaces do reduce the number of entries in the taskbar, it does not in fact eliminate them - it only moves them to another location.


IMO that point illustrates that neither UI convention is going to be ideal for every situation (rather than indicating a deficiency of tabbed interfaces).

Taskbars, in my experience, have a "threshold of usefulness" - it doesn't take long (for me, at least) reach the point where it takes a prohibitively long time to find & select a particular window or application using a global taskbar. E.g., I have over 50 tabs open in Firefox at the moment - it would be nightmarish to try manage those as separate windows via the taskbar (or something like Expose).

So, instead of having one place where the user can go to to switch between documents and applications, he now has multiple locations. Switching from document Abc in a word processor to webpage Xyz in a browser may now require more clicks and attention focus switches than in a non-tabbed interface.


(Emphasis: mine)

That can be a benefit in many instances - it makes sense if you think of it within the context of operating globally vs operating locally. For my own usage patterns at least, I find it fairly helpful to have a global app-switching mechanism that lets you select individual apps, then a local/app-specific mechanism that lets you select documents within those apps.

It should also be kept in mind that tabbed interfaces are usually optional. E.g., I know people who have been using Firefox for 2 or 3 years but have never used tabbed-browsing (if they even know it's available). IMO, tabbed interfaces are one of those rare features that can provide real benefit to more advanced users (and/or those of us seriously afflicted with Nerd Attention Deficit Disorder), without burdening more casual users with extra complexity.

A common sentiment, especially among the Apple and GNOME camps, is that reducing complexity in the graphical user interface is by definition always better than increasing complexity. While this might be true in a lot of cases, the resounding success of the tabbed document interface clearly shows that as with everything in computing, there is no golden rule. The tabbed interface increases complexity, yet it makes working with computers a lot easier for many people.

Sometimes, logic simply doesn't prevail.


There is a fairly simple, logical explanation: people are willing to put up with a bit of extra complexity if there's a significant added benefit.

Edited 2008-08-16 19:12 UTC

Reply Score: 2

RE: Taskbars
by Doc Pain on Sat 16th Aug 2008 23:23 UTC in reply to "Taskbars"
Doc Pain Member since:
2006-10-08

For my own usage patterns at least, I find it fairly helpful to have a global app-switching mechanism that lets you select individual apps, then a local/app-specific mechanism that lets you select documents within those apps.


An additional fact worth mentioning is that different applications tend to handle tabbing control differently (different locations, different behaviour to mouse clicks and different key bindings). While you are usually familiar with how your favourite window manager changes content globally, you mostly need to have a look at which application is running at the moment and how to change its content through tabbing.

There is a fairly simple, logical explanation: people are willing to put up with a bit of extra complexity if there's a significant added benefit.


Oh yes? :-)

Reply Score: 2

RE[2]: Taskbars
by StephenBeDoper on Sun 17th Aug 2008 00:23 UTC in reply to "RE: Taskbars"
StephenBeDoper Member since:
2005-07-06

"For my own usage patterns at least, I find it fairly helpful to have a global app-switching mechanism that lets you select individual apps, then a local/app-specific mechanism that lets you select documents within those apps.


An additional fact worth mentioning is that different applications tend to handle tabbing control differently (different locations, different behaviour to mouse clicks and different key bindings). While you are usually familiar with how your favourite window manager changes content globally, you mostly need to have a look at which application is running at the moment and how to change its content through tabbing.
"

By and large I've found that the keyboard shortcuts are usually consistent, at least. On my Windows box, I currently have 4 apps open that use either a tabbed UI or MDI with an internal taskbar (Firefox, MySQL-Front, EditPlus, and "Microsoft SQL Management Studio Express"). In all of them, Ctrl-Tab (or Ctrl-Shift-Tab) works for switching between document windows.

Ideally, I would prefer SDI in combination with floating palette that lists the child windows & lets you switch between them. But I've never seen that outside of some old NeXT apps and an old BeOS tool called "Active App".

"There is a fairly simple, logical explanation: people are willing to put up with a bit of extra complexity if there's a significant added benefit.


Oh yes? :-)
"

Ya rly. Srsly.

Reply Score: 2

RE[3]: Taskbars
by Doc Pain on Sun 17th Aug 2008 00:59 UTC in reply to "RE[2]: Taskbars"
Doc Pain Member since:
2006-10-08

By and large I've found that the keyboard shortcuts are usually consistent, at least. On my Windows box, I currently have 4 apps open that use either a tabbed UI or MDI with an internal taskbar (Firefox, MySQL-Front, EditPlus, and "Microsoft SQL Management Studio Express"). In all of them, Ctrl-Tab (or Ctrl-Shift-Tab) works for switching between document windows.


Because I'm not using any "Windows", I can't confirm this. Regarding different applications that use tabbing on UNIX, Ctrl+Tab (performing the same kind of operation locally that Alt+Tab does globally) behaved differently in Opera (brings up tab selector) and Firefox (switches tabs) and GNotepad+ (does nothing).

It's not that I am a consistency guy - in fact, it doesn't matter to me at all because I'm using applications through all imaginable toolkits -, but that's something I just noticed. Of course, keyboard behaviour isn't important when you're only using the mouse.

Furthermore, the corresponding menu items are often missing. While windowing applications had something like a menu "windows" containing "next" and "previous", associated with shortcut key combinations (I remember Ctrl+PF6 / Ctrl+Shift+PF6 being such shortcuts), today's tabbed applications don't seem to have such "next tab" and "previous tab" menu items inside a "view" or "tabs" menu or submenu.

Ideally, I would prefer SDI in combination with floating palette that lists the child windows & lets you switch between them. But I've never seen that outside of some old NeXT apps and an old BeOS tool called "Active App".


I do see this in Windowmaker all the time. :-)

Reply Score: 2

RE[4]: Taskbars
by StephenBeDoper on Mon 18th Aug 2008 18:03 UTC in reply to "RE[3]: Taskbars"
StephenBeDoper Member since:
2005-07-06

Because I'm not using any "Windows", I can't confirm this. Regarding different applications that use tabbing on UNIX, Ctrl+Tab (performing the same kind of operation locally that Alt+Tab does globally) behaved differently in Opera (brings up tab selector) and Firefox (switches tabs) and GNotepad+ (does nothing).

[...]

Furthermore, the corresponding menu items are often missing. While windowing applications had something like a menu "windows" containing "next" and "previous", associated with shortcut key combinations (I remember Ctrl+PF6 / Ctrl+Shift+PF6 being such shortcuts), today's tabbed applications don't seem to have such "next tab" and "previous tab" menu items inside a "view" or "tabs" menu or submenu.


There certainly are poor implementations of tabbed interfaces - but that's true for any UI functionality / mechanism that I could name.


Ideally, I would prefer SDI in combination with floating palette that lists the child windows & lets you switch between them. But I've never seen that outside of some old NeXT apps and an old BeOS tool called "Active App".


I do see this in Windowmaker all the time. :-) [/q]

That would make sense, given that Windowmaker is virtually a clone of the NeXT UI.

Is there a system/GUI-wide tool in WindowMaker for listing an app's child windows? It's been a few years since I used it, but from what I remember most of the "document selector" applets were app-specific (in contrast, one of the things I like about ActiveApp is that it changes to reflect the currently-active app - hence the name).

Reply Score: 2

..tabs in fluxbox..
by mtzmtulivu on Sat 16th Aug 2008 20:59 UTC
mtzmtulivu
Member since:
2006-11-14

its also possible in windows managers like fluxbox to group different windows in a tab simply by middle clicking a window bar and drop it on another open window bar

for example, open office doesnt support tabs so if i want to have 2 opened documents, i will have to have 2 instances of open office and 2 entries in the taskbar ..to join them together in fluxbox, all that is required is just dragging one window ontop of another and they will be joined as tabs and they will have different colors to show which one has focus ..

it would have been nice to have this feature in "main stream" window manages

ps:
last time i checked, open office has an old and unmaintained plugin that adds the ability to open multiple documents in tabs

Reply Score: 4

RE: ..tabs in fluxbox..
by Doc Pain on Sat 16th Aug 2008 23:19 UTC in reply to "..tabs in fluxbox.."
Doc Pain Member since:
2006-10-08

for example, open office doesnt support tabs [...]
ps:
last time i checked, open office has an old and unmaintained plugin that adds the ability to open multiple documents in tabs


If I remember correctly, the "old" StarOffice I did use in versions 3, 4 and 5 had implemented a kind of tabbed document handling, much as the "task bar" from fvwm95. OpenOffice abandoned this concept in favour of multiple windows. I think this is due to the fact that StarOffice included an own kind of window manager...

Reply Score: 2

tabs are a step to tiling window managers
by asgard on Sun 17th Aug 2008 04:24 UTC
asgard
Member since:
2008-06-07

I believe that tabs are easier to work with because they present a progression to tiling window managers, which are generally easier to work with than the windowed window managers.

If you look at for example editor in Eclipse, it's easy to manage tabs here, easy to put up two or three different tabs at once, to split them in different groups and so on. Similar things can be done with options in Blender (these two programs are my favorite examples why tiling window managers are superior to windowed ones).

Reply Score: 2

CDE but barely a note of NeXTSTEP?
by tyrione on Sun 17th Aug 2008 06:55 UTC
tyrione
Member since:
2005-11-21

Give me a break. The entire NeXT UI Paradigm broke ground across the entire playing field.

What's the point of doing a series if you don't even cover an indepth look at NeXT UI, BeOS and OS/2?

Reply Score: 1

Thom_Holwerda Member since:
2005-06-29

Ah, a "you-haven't-covered-my-pet-project-and-now-I'm-gonna-cry" post.

What's the point of doing a series if you don't even cover an indepth look at NeXT UI, BeOS and OS/2?


I'd love to cover NeXT, so if you can supply with me with a NeXT machine to do so, I'd be happy to see what I can do for you. In fact, I already covered a bit of NEXTSTEP in the article on the dock.

Reply Score: 0

helf Member since:
2005-07-06

Thom, I can supply you with NEXTSTEP 3.3 or OPENSTEP 4.2 and they run in vmware and parallels on Macs quite well ;)

I'd supply you with a desktop running OPENSTEP, But I doubt you'd want to pay shipping charges ;)

/me is the resident NeXT nut

Edited 2008-08-18 15:40 UTC

Reply Score: 2

tyrione Member since:
2005-11-21

Ah, a "you-haven't-covered-my-pet-project-and-now-I'm-gonna-cry" post.

"What's the point of doing a series if you don't even cover an indepth look at NeXT UI, BeOS and OS/2?


I'd love to cover NeXT, so if you can supply with me with a NeXT machine to do so, I'd be happy to see what I can do for you. In fact, I already covered a bit of NEXTSTEP in the article on the dock.
"

http://www.nextcomputers.org/forums/

I can always supply the ISOs or you can reference them off of the forum linked and run them in VMWare.

Reply Score: 2

Tab overload
by 3rdalbum on Sun 17th Aug 2008 07:51 UTC
3rdalbum
Member since:
2008-05-26

Tabs have become so popular that they are even used in programs where they are not really very useful.

Take the X terminal applications. Gnome-terminal and Konsole have tabs for different instances of your shell. But when I have multiple instances of my shell on the same desktop, I'm using them in conjunction with eachother - for instance, browing a man page for a command in one, and typing the command in another one. In this case, I have to keep switching tabs all the time.

Or I might be testing a GUI program in one, and reading its' log file in the other.

It's worse with Gedit, as multiple text documents open in new tabs rather than new windows. If I'm editing a frontend and a backend simultaneously, I have to switch between them in order to see what I've got written in the other one. It's annoying because I have to break concentration in order to perform that task.

This whole series has been okay, but one man's usability is another's annoyance. I don't see modal dialogs as an inherant evil, I see them as important when a user has entered a mode that can influence the rest of a program or the rest of the operating system. By forcing the user to make their decisions before continuing on with the program, you avoid the possibility of the user expecting their changes to have been applied.

Reply Score: 1

RE: Tab overload
by Doc Pain on Sun 17th Aug 2008 13:39 UTC in reply to "Tab overload"
Doc Pain Member since:
2006-10-08

This is a valid point: Where Documents controlled by tabs are used "side by side" and there's no means to "transform" the tabs into sub-windows (such as Opera does), a "tabs-only mode" may be a worse solution thatn having multiple windows. Your examples of the shell application and the text editor are impressive; I can imagine other kinds of applications where "tabs-only" may make your workflow get slower due to an increased amount of forced tab switching. In such cases, running multiple instances of the same application - the shell application or the text editor - may definitely be the better choice.

I've seen "tab abuse" in a german program that manages the work of psychologists. This application is one of the worst designed ones I've ever seen, and of course, it's very expensive. Must be the expensive tabs inside. :-) Instead of a useful menu, it uses tabs to group buttons that control the different actions, but the content that is brought up then is presented in sub-windows that do not allow windowing control, just as double-fixed dialog windows. This application really is a usability nightmare and would be a good means to torture Thom as the author of the "Common Usability Terms" series. :-)

Reply Score: 2

RE[2]: Tab overload
by Thom_Holwerda on Sun 17th Aug 2008 16:51 UTC in reply to "RE: Tab overload"
Thom_Holwerda Member since:
2005-06-29

This application really is a usability nightmare and would be a good means to torture Thom as the author of the "Common Usability Terms" series. :-)


Do you happen to have access to screenshots of this application? If so, be sure to edit out the personal information (probably a redundant warning, but better safe than sorry).

Reply Score: 1

RE: Tab overload
by phoenix on Sun 17th Aug 2008 20:30 UTC in reply to "Tab overload"
phoenix Member since:
2005-07-11

Take the X terminal applications. Gnome-terminal and Konsole have tabs for different instances of your shell. But when I have multiple instances of my shell on the same desktop, I'm using them in conjunction with eachother - for instance, browing a man page for a command in one, and typing the command in another one. In this case, I have to keep switching tabs all the time.


And ... opening another instance of the terminal app is hard to do? Just because an application supports tabs doesn't mean you are forced to use them. Start the app multiple times, with a single tab in each one.

With Konsole 4.1, you can now split the view horizontally or vertically, so you can have any number of shells open and viewable at once.

Edited 2008-08-17 20:32 UTC

Reply Score: 2

RE[2]: Tab overload
by Thom_Holwerda on Sun 17th Aug 2008 20:52 UTC in reply to "RE: Tab overload"
Thom_Holwerda Member since:
2005-06-29

With Konsole 4.1, you can now split the view horizontally or vertically, so you can have any number of shells open and viewable at once.


Which effectively means Konsole now has an MDI interface.

Reply Score: 1

Simplicity != Usability
by HappyGod on Sun 17th Aug 2008 11:15 UTC
HappyGod
Member since:
2005-10-19

The problem that I have with the Gnome philosophy is that they confuse simplicity with usability. That is, they assume that if they make a given task a simple as possible that it will automatically become more usable.

This (as demonstrated by the article) is not always the case. Other examples include Gnomes "control" panels (i.e. Networking, XGL) which provide no options for advanced users, presumably because adding these options might confuse novice users.

This way of thinking makes for frustrating software, as you are reduced to finding non-intuitive ways of performing otherwise simple tasks.

BTW. Big fan of these articles. Keep them coming.

Reply Score: 3

Tabs good, tabbed dialogs bad
by Chicken Blood on Sun 17th Aug 2008 18:19 UTC
Chicken Blood
Member since:
2005-12-21

This discussion has made some good points about when tabs can aid usability and when they can hinder it.

when used within top level windows

What isn't really discussed though is tabbed dialogs. This old article pretty much explains why they are almost always bad and why there is usually a much better alternative: http://homepage.mac.com/bradster/iarchitect/tabs.htm

Reply Score: 2

RE: Tabs good, tabbed dialogs bad
by wakeupneo on Tue 19th Aug 2008 04:56 UTC in reply to "Tabs good, tabbed dialogs bad"
wakeupneo Member since:
2005-07-06



That was an interesting article...particularly the similarity I noticed between the 'innovative' MS Office Ribbon and this piece of old software:

http://homepage.mac.com/bradster/iarchitect/images/tabtool.gif

GACGAS ;)

Reply Score: 2

deeper problem
by RandomGuy on Sun 17th Aug 2008 21:00 UTC
RandomGuy
Member since:
2006-07-30

There is a deeper problem behind this whole tab issue:
Whenever a new technique is used to better handle complexity there's less pressure on developers to reduce complexity.

One example are tabbed interfaces, as opposed to just showing all available options without any kind of nesting. Tabs/nesting are exponentially more powerful than just showing the options - think one digit vs 9 tally marks, two digits vs 99 tally marks, ...

The downside is, of course, that people have to grasp how to write a number (say to base 10) instead of just scratching lines.

After a certain number of tasks (depending on the person) the additional effort becomes worth it.
You can already see a primitive version of this in the taskbar itself:
The system tray. It only delays the problem, it doesn't solve it. At some point you need tabs or virtual desktops or both. Until recently (a couple of weeks ago, just check Thom's blog) I thought that tabs and multiple desktops were the best things since sliced bread. I looked at Gimp and thought "God damn you guys! Who the hell do you think you are littering my desktop with windows?!?".
Then it dawned on me:

Tabs popping up in just about any app indicate that the OS/DE does not provide sufficient means to group tasks/windows, switch between them, and view them side by side.

Every OS/DE I've used so far (Win 98/XP, KDE 3.5, Gnome 2.something) totally sucked ass at this. Vista and KDE 4 haven't fixed this yet as far as I know. I don't really care for eye candy either.

If 60 windows are swirling around me that's still about 55 too many - no matter how fancy the animation.

So app developers work around the issue and start adding tabs. Or people use virtual desktops. And you don't notice the problem anymore.
I know I didn't until recently.

But the point is, these methods don't work together very well and they don't scale. Thom already touched upon the friction between tabs and windows (a decent, possibly system wide undo could fix some of it) so let me just explain what I mean by "scaling":

The problem is that they are basically that taskbar, system tray, virtual desktops, tabs and whatnot are patchwork. There is no obvious way to express cross-cutting concerns like:
"Give me all the windows/tabs that are work related, and are either from (insert pdf reader) or (insert latex editor)."

There is also no elegant way to extend this like:
"Hide all the windows that haven't been active in 30 minutes."
or "Hide all of the windows tagged 'work, project A'"

As you can tell by the last sentence, I believe that some sort of tagging might solve these issues in a more elegant way. Extending it is both obvious and easy if the DE provides enough attributes.

The main problem is to make this easy to use for Joe Average who doesn't want to think about tagging and queries.

Reply Score: 2

RE: deeper problem
by netpython on Mon 18th Aug 2008 06:58 UTC in reply to "deeper problem"
netpython Member since:
2005-07-06

I don't think Joe Average has 55+ windows open on average.

Thus all this makes me think again whose agenda is being called?

Reply Score: 2

RE[2]: deeper problem
by RandomGuy on Mon 18th Aug 2008 14:05 UTC in reply to "RE: deeper problem"
RandomGuy Member since:
2006-07-30

I don't think Joe Average has 55+ windows open on average.

Have you ever wondered why?

This is like watching a dog with three legs and claiming "He's fine. He doesn't jump that much anyway."

If there's one thing humans are good at it's coping with (artificial) limitations and working around them. Like app developers using tabs to work around the suckiness in the underlying DE/OS.

The point is that _because_ the taskbar blows chunks at >5 windows (give or take) people are basically emulating a more powerful environment by opening and closing apps repeatedly.

When I only had the taskbar, I'd find myself running about 5 windows at a time. Pushing some apps in the system tray I got to about 10. Using tabbed apps and counting each tab as a window gives me a chance to have about 20 open at a time and still feel comfortable. With virtual desktops this number increases to something between 30 and 60, depending on the situation.

Just about any person I've talked to who has used multiple desktops finds going back to a single one painful to say the least. Even OSX Leopard and Gnome, products with a strong focus on simplicity, have virtual desktops.

I find it very hard to believe that about 50 windows ought to be enough for everybody (tm), some constant of nature like the speed of light or pi...
Likewise I find it naive to assume that Joe Average who started out with single tasking and now runs several programs at a time will never want to run more - not even if advancements in DEs allow him to.

Edited 2008-08-18 14:06 UTC

Reply Score: 2

RE[3]: deeper problem
by netpython on Mon 18th Aug 2008 14:53 UTC in reply to "RE[2]: deeper problem"
netpython Member since:
2005-07-06

If you want to have 55+ windows open be my guest. I never said there should be a hard limit. Though i doubted wether we are seriously addressing the needs and greeds of the average computer user or we are academics f*cking ants for our own purposes.

Reply Score: 2

RE[4]: deeper problem
by RandomGuy on Mon 18th Aug 2008 15:34 UTC in reply to "RE[3]: deeper problem"
RandomGuy Member since:
2006-07-30

My point was that the number of windows the average computer user has open will increase as well, he's just a little behind the curve...

Besides, simple everyday situations can mean a lot of open windows.
Like chatting with a couple of friends, watching a video on youtube, using Google, checking your email, listening to music, editing pictures, ...
Of course you can work around this by opening and closing apps repeatedly but it's just that: a workaround.

I don't buy the assumption lots of windows == rocket science.
Well, maybe we'll just have to agree to disagree...

Reply Score: 2

RE[2]: deeper problem
by helf on Mon 18th Aug 2008 15:45 UTC in reply to "RE: deeper problem"
helf Member since:
2005-07-06

don't be too sure about that. I have to work with "average joes" that can barely use computers. they seem to think minimizing a window means it is closed. I've seen people with brand new machines crawling with all 2gb of ram used up and several gigs of swap because they had, literally, 2-300 windows open for explorer, IE, and various programs.

I get called to come get "rid of the viruses" and all i do is reboot the machine ;)

Edited 2008-08-18 15:46 UTC

Reply Score: 2

RE[3]: deeper problem
by thebackwash on Mon 18th Aug 2008 18:55 UTC in reply to "RE[2]: deeper problem"
thebackwash Member since:
2005-07-06

don't be too sure about that. I have to work with "average joes" that can barely use computers. they seem to think minimizing a window means it is closed. I've seen people with brand new machines crawling with all 2gb of ram used up and several gigs of swap because they had, literally, 2-300 windows open for explorer, IE, and various programs.

I get called to come get "rid of the viruses" and all i do is reboot the machine ;)


And charge them $60 for having "the knowledge" necessary to solve the problem? ;)

Reply Score: 2

RE[4]: deeper problem
by helf on Mon 18th Aug 2008 23:09 UTC in reply to "RE[3]: deeper problem"
helf Member since:
2005-07-06

you know it ;)

Reply Score: 2

RE: deeper problem
by google_ninja on Mon 18th Aug 2008 21:10 UTC in reply to "deeper problem"
google_ninja Member since:
2006-02-05

Every OS/DE I've used so far (Win 98/XP, KDE 3.5, Gnome 2.something) totally sucked ass at this. Vista and KDE 4 haven't fixed this yet as far as I know. I don't really care for eye candy either.


I don't know if it is completely handled in OSX, but its a damn sight better then any other environment I have used. Spaces + Expose is better then any of the clones I have seen anywhere else.

Reply Score: 2

Browser timeline
by unapersson on Mon 18th Aug 2008 11:50 UTC
unapersson
Member since:
2005-07-19

There were two other Mozilla based browsers that both did tabbed browsing before Mozilla itself: Skipstone (v0.7 1999) and Galeon. Both were GTK-based and helped inspire Mozilla's implementation.

Reply Score: 1

Opera Tabs Before 7
by jrronimo on Mon 18th Aug 2008 19:53 UTC
jrronimo
Member since:
2006-02-28

I could swear that Opera 6 had a 'proper' Tab implementation -- with the graphic and all. I can't find the screenshot now, but I was trying to show my friends how awesome tabs were since I loved Opera so much at the time. If you're disagreeing with me, what about Opera 6's tab implementation makes it improper?

Since that time, I've actually grown to hate tabs for a lot of the reasons you've mentioned -- alt+tab doesn't work among other things. Luckily, the Opera Devs have kept "SDI" implementations available through preferences. My Opera opens windows rather than tabs and I have removed the tab bar as it is just a waste of space that could have more OS News content. ;) It gives me Alt+Tab back, which is nice.

On top of that, I've changed the way I look at my UI in general -- the Windows Taskbar is essentially a tab bar but for all applications, to me. I can easily identify the content of a webpage by looking at its place in the Taskbar. If I get too many open, Windows Groups them together, making it easier for me to read the title attribute of a window. Of course, that's one more click and one more attention focus than as if everything were just in the taskbar, but it's become very usable to me. (I would even argue that it's not necessarily one more attention shift since I just look for the icon representing the applicaiton I want before narrowing it down to a specific instance of that application. Image recognition is simpler than reading the words.)

Edit:// I also meant to mention about "bad" tab implementations. I'm looking at you, IE7. Having the tab bar BELOW the address bar flies in the face of all things sensical and right! Changing a tab should change the content below it, with the tab being the 'major' grouping. I just don't see why it makes sense to have a tab bar in the middle of the things it's changing.

Edited 2008-08-18 19:55 UTC

Reply Score: 1

Tabs in Opera and Tabs in Visual Studio
by Glynser on Tue 19th Aug 2008 15:28 UTC
Glynser
Member since:
2007-11-29

Using Opera, I have my tabs vertically on the right side. This is very cool, as you have suddenly much more space for your tabs (and since I always recover the last session and avoid using bookmarks, I often have about 100 opened tabs).

Recent development shows that many other programs use an approach like that, like having a list on the left or right side acting as a replacement for the former tabby stuff.

As you mentioned in your post, if there are too many tabs, most programs will turn that to some confusing multi-column tabs then, but the cool thing in Opera is that they aren't "ordinary" tabs, in fact they do resemble ordinary buttons (with the active one being highlighted), so there's no need to shift them all to another column (like in some confusing Windows dialogs).


The worst thing I've ever seen related to tabs was in Visual Studio 6.0, there was a very tiny window (VERY tiny!) that had the following tabs:

Allgemein (= General)
Formate (= Formats)
Erweiterte Formate (= Extended Formats)
Weitere Formate (= More Formats)
Weitere Erweiterte Formate (= More Extended Formats)

That showed me how you can really mess up with using tabs. And in that case, they'd just have to make the window a bit bigger ;)

Hehe, just found a screenshot:
http://www.wachtler.de/unsinn/weitere_erweiterte_formate.png

Edited 2008-08-19 15:29 UTC

Reply Score: 1