[Millennium]

Originally posted by Guy Incognito:
Ok...I'm sorry, Millenium. Tabs in the tabbed-browsing sense are the best UI design ever. I don't know why I've ever doubted you.

Funny.

Yes, I do think that tabs in the tabbed-browsing sense are the best implementation of the concept to date. That doesn't mean it cannot be done better. But the thing is, tabs are already a good implementation of the idea, so one can't just come up with an alternative in a couple of days and have it automatically be better; you could do that if tabs totally sucked, but they don't. Beating the tab concept is going to take a lot of thought, and a lot of testing. Testing is crucial: what looks good on paper, even if it completely conforms to UI guidelines, does not always work well in reality.

You know something? That would actually make for an interesting contest. Have people come up with The Worst Browser UI Ever, with the constraint that whatever you come up with must comply 100% with the UI guidelines for the platform you're mocking up (obviously, mockups would have to be restricted to platforms with actual UI guidelines). Then, come up with The Best Browser UI ever, with the constraint that you must break every single UI guideline on your platform which applies in any way to your product.

Obviously, there would have to be a few other constraints; the browser would, for example, have to actually be capable of displaying Web pages. But this could actually be a pretty cool concept.

[Steve]

Damn... seems Apple has "used tabs" for a long time, and they will use them in Safari.

[Guy Incognito]

Originally posted by Steve:


Damn... seems Apple has "used tabs" for a long time, and they will use them in Safari.

Those tabs are static in nature. Of course Apple has used tabs for a long time. They're everywhere in preference windows.

Apple will *not*, however, use them for a dynamic purpose in Safari.

[mrtew]

Originally posted by Guy Incognito:
I see we're getting nowhere. I'll let the tab-lovers use their shoddy implementation just like I've grown to let Windows-lovers use their shoddy OS.

God I wish that were true.

Why oh why can't you let the tab-lovers use their tabs in peace! We've already told you that when you come up with a better idea, we will drop tabs in a minute. Now leave us alone until you do. I think you are just against the concept of multi-document-in-one-window, you're not against tabs and their implementation.

[nobodybutme]

What did the old Notepad use to cycle through documents? (I think it was called Notepad) I never really used it, but I seem to recall that it basically allowed multiple, persistent "documents" to be viewed through one window. I'm just curious due to my lack of familiarity with the older OS.

[Developer]

Originally posted by Millennium:
Yes, I do think that tabs in the tabbed-browsing sense are the best implementation of the concept to date.

Not true. Preview's multi-document interface is already much better than tabs.

[Steve]

Originally posted by Guy Incognito:
Those tabs are static in nature. Of course Apple has used tabs for a long time. They're everywhere in preference windows.

Apple will *not*, however, use them for a dynamic purpose in Safari.

They will. And I will bet on that.

How would tabs on a browser be anymore static than the ones on Apple's site? (or for that matter, in Project Builder?).

[kzmk]

Originally posted by Steve:
They will. And I will bet on that.

How would tabs on a browser be anymore static than the ones on Apple's site? (or for that matter, in Project Builder?).

have you EVER been able to hit command-w to close a tab? ever? let's say... in the internet-prefpane?

[Millennium]

Originally posted by Developer:
Not true. Preview's multi-document interface is already much better than tabs.

For crying out loud, for the last time, Web pages are not documents! Web pages are applications. They have different needs, and different capabilities.

For that matter, Preview's multi-document interface is for something completely different. PDF's are static documents; the number of pages does not change. Likewise, when a user opens multiple documents, this number is unlikely to change, and when it does change it tends to only decrease the number of documents, so things stay relatively stable in terms of where everything is. This is very different from a multi-page browsing environment, where the number and position of pages changes frequently.

Preview's drawer works very well for static stuff (though at least on this TiBook/400 it's painfully slow). But it falls completely flat in a dynamic environment. What's good for the goose isn't necessarily good for the gander.

[kzmk]

Originally posted by Millennium:
The fact is, he has not presented a better widget, therefore he is essentially just railing against the idea.

that so?
so i'm railing against the idea, too?
funny, 'coz i'm not.

Indeed it wouldn't be. Tabs make more sense than buttons do. That's why Opera's MDI-based switching never caught on, but tabs did; the metaphor makes more sense.

tabs make more sense than buttons?
why's that?
why do we have buttons in preferences' toolbars, if tabs made more sense? why do we have buttons in the finder's toolbar? why not have tabs in the finder?

and tell me: what is - from a user's perspective - the difference between a link and a tab in chimera? it is from the program's persepective (if this can be), since one page is in memory/loaded, the other is not. and that's it.

it all comes down to what you're used to. and you've gotten used to tabs as a means of switching between open documents. if it would've been buttons in the first place, and someone came up with the concept of tabs, you would argue that buttons made more sense.

Actually, he's not "damn right". I'm trying to point out why, in fact, this is exactly the sort of thing tabs were designed for: switching between different areas of functionality inside an app. Guy's assertion that this isn't what's taking place arises from his sorely mistaken impression that Web pages are documents.

when was the last time you "saved" an app?
if web pages aren't documents, then i don't know what i've been designing for the last couple of years. hm... so golive is an app-builder. nice to know.

btw: i was the one who argued that tabs were designed for switching between "documents". but they were not designed to be closed or created upon user-interaction.

Putting a little button inside a big button, essentially. That's even worse UI than plain tabs are. I've seen mockups of this idea before (there's a bug on Bugzilla with a lot of argument about this). Buttons inside buttons, particularly tiny ones like this would have to be, are bad UI. Of course, one could say (quite rightly) that having no easy way of closing tabs is also bad UI. But hacking bad UI on top of bad UI does not make good UI.

this was just an example of how bad tabs suck.
look, some people want buttons inside the tabs. not me. others. and that shows that there's a lack of functionality provided by tabs.

Subclassing a tab is not "hacking" by any stretch of the imagination. It's taking a behavior that people don't normally even use with tabs (namely control-clicking) and making it do something. It in no way interferes with normal tab operation, merely adds a new behavior which improves functionality. Tell me again why this is bad?

it is not bad.
all i'm trying to say is, that tabs are suboptimal, and that there NEEDS to be a better solution. and this solution has to come from apple. they MUST provide a widget (btw, the notepad used a flip-page-metaphor).

people need to understand that tabs are a hack (who cares about "sub-classing", anyway). they are by no means the right widget. they work - for now - but there has to be a better way.
and this is not to say that the concept of multiple documents per window is bad.

...or that Apple's implementation is inadequate, and can be done better.

apple's implementation is not "inadequate".
it would be inadequate if tabs had been designed to be opened and closed. but they were not, so the implementation is perfect.
a window's titlebar wasn't designed to be scrolled. if somebody came up with that idea (scrollable titlebars) - would you say that apple's implementaion was inadequate?

Are tabs the perfect widget? No; nothing is perfect. But they're the best solution that anyone has presented so far.

really?
i think there have been a lot of good ideas which were put down because they were mockups. you couldn't use them, you could only look at them, compare them to a working method (tabs) and decide that this method was better.
not fair...

Curmi's screenshot of a drawer doesn't work. Reasons:[list][*]It is in a drawer. Drawers are not constantly onscreen, and therefore there is no constant, consistent reminder of the pages in use.

so what? i don't think drawers are the way to go.

[list][*]When the drawer is onscreen, it wastes far more screen real-estate than a tab bar does: a good 64x120 pixels or so per page.[*]Not all of the pages are onscreen at once; scrolling is required.[*]This will inconsistently require one click (if the page is onscreen), two clicks (if the drawer is offscreen and the page happens to be brought onscreen when the drawer is activated), or even more clicks (if scrolling is required). Terrible UI, and very inconvenient as well.

right. so what?

[list][*]You want to get into "what UI widgets were designed for"? Very well; I'm game. Drawers were designed for supplemental information, not actual controls. Apple breaks this with Mail, but Apple breaks so many of their own UI guidelines anymore that it's not even funny. OmniWeb also breaks this with their bookmarks Drawer. The point is, here you're hacking a Drawer to do something it wasn't designed for, and yet you rail against tabs for doing the same thing. At least keep your arguments consistent. Granted, I don't see this as a valid claim for Tabs or Drawers, but it's a hole in your own logic. If it's OK to hack Drawers, then it's OK to hack Tabs.

i'm NOT railing against tabs, damnit!
or hacking tabs.
all i'm saying is, that we, as users and developers, should not settle with the (system-level) tabs as the widget to do what we want this particular widget to do: switching between *documents*. closing tabs, opening tabs - how silly is this? chimera is redifinig a widget's funcionality. this IS bad ui-design. i'm NOT saying it is bad ui, because it works, and does so quite well. but folks need to start differentiating and need to accept and agree that the system-level tabs - as a widget for this purpose - are not right.

look at macromedias's apps and compare them to adobe's apps (look at the palettes). adobe WISELY chose to use their own implementation of tabs. because their tabs behave in a way the system-level tabs were not designed to behave. they have menus in their tabs, you can drag the tabs and create a new window (palette), you can double-click on their tabs and have the window shrink.

maybe all we need is a different set of tabs, which is clearly set apart from the current version.
just as there are different sets of buttons (some even allow for menus, see).

and you're not right with your take on drawers and the way they are used by apple/omni. drawers are different, because their concept is based on *content*, not on behaviour. you're not "hacking a drawer" if you fill stuff in it which apple didn't describe in their guidlines. you'd be hacking a drawer if you'd hack the way it behaves. make it detachable, for example...

even okito wasn't hacking a drawer when they put palettes in it and made these palettes draggable. they were putting content in the tabs, that's all. and THAT'S what drawers were designed for: content of some sort. this content can then be controls (see "create", or - it's a stretch, i know - mail.app) or real content (notes for example) which refers to the document window the drawer is attached to.

having said that, a drawer would be far more compliant to the HIG than tabs. that is not to say that a drawer would be the perfect solution ui-wise (i think it wouldn't, you've already made the points).

• At least from the screenshot, I see no easy way of getting rid of pages, so you still haven't solved the no-close problem you find with Tabs.

Like I said: show me something better than Tabs, and I'll go with it. But this isn't better.

see above. just because there's no mockup of a context-menu, you're complaining. just because there's no animation shown of pages being dragged out of the drawer, you're complaining.
the way I see the screenshot, it could very easily be minimized windows. say... an app-specific mini-dock, for example.

[kzmk]

Originally posted by nobodybutme:
What did the old Notepad use to cycle through documents? (I think it was called Notepad) I never really used it, but I seem to recall that it basically allowed multiple, persistent "documents" to be viewed through one window. I'm just curious due to my lack of familiarity with the older OS.

it had a little widget which looked like a pagecurl. you could "flip through" your notes. just a forward/backward-button with a different look.

[Cipher13]

Still no response, guy?

I guess you don't have the goods, huh.

[undotwa]

My idea?

Simply a slide out dock under the window (opens automatically when command click is done, moves the window up to fit the dock, and closes when the last dock icon is dragged to the trash) with a list of minimized windows (64x64), big docks which grow larger than the window get the little arrow from toolbars to reveal the other window names). Scrub on the icons to reveal the name. Command click to add a window to the dock. Drag icon to trash to close the window.

Happy? I'm a genius.

[Guy Incognito]

Originally posted by mrtew:
I think I'm an idiot.

You think? I know!

[Guy Incognito]

Originally posted by Cipher13:
Still no response, guy?

I guess you don't have the goods, huh.

Response to what? You haven't said anything since the last page.

[Silky Voice of The Gorn]

I think people are overthinking the solution to the problem.

Safari already has a place for "tabs"- the bookmark bar. It just needs to be modified slightly. Instead of a big nasty blue tab widget, a new web document window would appear as just another bookmark bar name. It could be differentiated from a standard bookmark by being underlined, or perhaps a different color.

Because they're in the bookmark bar, you can easily shuffle the order, and right-click context menus. Everything follows current UI guildines.

Thoughts?

[Guy Incognito]

What Millenium doesn't understand is that webpages are mostly 'read-only' documents. Just like PDFs are when using Preview. You can't modify them.

The 'read-only' trend is changing but, these pages are still documents. They'll just be more 'read-write' than what they are now. There will be a better degree of manipulation eventually.

But gawd, Millenium, stfu about webpages being apps.

While Mill will claim that MacNN Forums is actually an app for many users to use to edit a very large document...it's more of a document with the tools necessary to edit the 'read-only'ness of HTML.

Millenium, realize that the pages are all documents. Some that are plain text + a couple of images maybe. And others that circumvent the lack of flexibility of HTML.

[Simon]

Originally posted by Guy Incognito:
But gawd, Millenium, stfu about webpages being apps.
...
Millenium, realize that the pages are all documents. Some that are plain text + a couple of images maybe. And others that circumvent the lack of flexibility of HTML.

Ummm, actually no.

He's right. Maybe not in the literal sense of "apps" but conceptually he is right.

There's no need to be rude here buddy. You can like tabs or not and you can wish for them or not. Getting loud here won't change Safari one bit.

[asxless]

Originally posted by Silky Voice of The Gorn:
Safari already has a place for "tabs"- the bookmark bar. It just needs to be modified slightly.

Exactly! Safari already has 95+% of the functionality of Tabs implemented via the Bookmark Bar.

I put my main "tab groups" from Mozilla into Safari's Bookmark Bar. The 'browsing' functionality is even better than Mozillas 'tabs' because I can rearrange them, etc. BUT...
* I can't quickly create a new empty bookmark in the bookmark bar from a menu or keystroke,
* adding a link to the bookmark bar requires two steps, and
* I can't add a folder of bookmarks to the Bookmark Bar from the Bookmark menu.

All Safari needs is a few more menu items to allow me to...
* File/New/Empty bookmark in the bookmark bar" (or for those who still have an open mind "File/New/tab")
* "Open link as a new bookmark in the bookmark bar" without having to reply to the sheet (or for those who still have an open mind "open link as a tab") but frankly this isn't a big deal,
* Right click a bookmark (or book mark folder) in the Bookmark menu to add it to the Bookmark Bar (or for those who still have an open mind "select a tab group from the bookmark menu").

Of course, Safari also would need a "Kiddie Menu" preference for those too twisted to deal with tabs

asxless in iLand

[Guy Incognito]

Originally posted by Simon:
Ummm, actually no.

He's right. Maybe not in the literal sense of "apps" but conceptually he is right.

In a very abstract sense, he's right. In a very literal sense, I'm right.

What makes an app and app and a document a document?

If a text document of some sort allowed me to embed a Java applet that allows me to draw things in a constraint space of my document, does the document automatically become an app?

Does embedding an interactive QuickTime or Flash file into my document that allows me to play a little game make my document become an app?

I was afraid Millenium might corrupt some people into believing his bullshit. Are you proud of yourself Millenium? Now kids all over the world will go tell everyone that webpages are apps.

Getting loud here won't change Safari one bit.

Exactly...so why are people getting loud over tabs?

[khufuu]

Originally posted by Guy Incognito:
In a very abstract sense, he's right. In a very literal sense, I'm right.

What makes an app and app and a document a document?

If a text document of some sort allowed me to embed a Java applet that allows me to draw things in a constraint space of my document, does the document automatically become an app?

Does embedding an interactive QuickTime or Flash file into my document that allows me to play a little game make my document become an app?

I was afraid Millenium might corrupt some people into believing his bullshit. Are you proud of yourself Millenium? Now kids all over the world will go tell everyone that webpages are apps.



Exactly...so why are people getting loud over tabs?

Embed is the key word Guy. A document can have an embedded application (QT) which plays another document (the QT file or data stream.) This doesn't make the document an application just because it can 'run' another application.

A document is loaded into an app so that the app can do something with the document.

Web pages are documents that the browser application can display and modify. Yes...modify.

Tabs are a hyper-links to cached web pages. Control clicking on a link creates a new hyper-link (tab). Adding this hyper-link to the browsers display is an act of modifing the currently display document within the browser. Nothing more.

It has nothing to do with the windowing sub-system on the OS.

[Guy Incognito]

Originally posted by khufuu:
Embed is the key word Guy. A document can have an embedded application (QT) which plays another document (the QT file or data stream.) This doesn't make the document an application just because it can 'run' another application.

A document is loaded into an app so that the app can do something with the document.

And that's exactly my point. Why can't Millenium understand this?

[Guy Incognito]

Originally posted by khufuu:

Tabs are a hyper-links to cached web pages. Control clicking on a link creates a new hyper-link (tab). Adding this hyper-link to the browsers display is an act of modifing the currently display document within the browser. Nothing more.

I don't disagree with that. I'm not sure what your point is.

What I'm saying is that there's a better way to display or organize these 'hyper-links'.

They could be done at the system level, instead of the app level since webpages are 'documents'.

All apps that handle documents would have this consistent document switching ability. That way we won't have to struggle with several different methods (Chimera's tabs, Preview's thumbnails in a drawer, and Acquisition and Proteus' drawer items.

[Silky Voice of The Gorn]

Quickie mockup of my idea..italic or colored bookmark would actually be a "tab".

[nobodybutme]

Originally posted by Silky Voice of The Gorn:
Quickie mockup of my idea..italic or colored bookmark would actually be a "tab".

Interesting. I think you would need a vertical seperator between the two types.

[nobodybutme]

Originally posted by Guy Incognito:
I don't disagree with that. I'm not sure what your point is.

What I'm saying is that there's a better way to display or organize these 'hyper-links'.

They could be done at the system level, instead of the app level since webpages are 'documents'.

All apps that handle documents would have this consistent document switching ability. That way we won't have to struggle with several different methods (Chimera's tabs, Preview's thumbnails in a drawer, and Acquisition and Proteus' drawer items.

It's been mentioned many times. Different controls are used for different reasons. Let's look at Project Builder, Preview and Mozilla, hell even iPhoto. They all offer some concept of document switching. Each method of viewing is different, and it's different for a reason.

Preview previews the pages in a PDF. Apparently, some people find it helpful to preview page thumbnails rather than just page numbers. Project Builder lists what basically correlates to a directory tree. It's fast for viewing the file names and their association with other files. iPhoto is even more visual in a sense that it is just one big list of photos. Seeing the picture is more important than the name. To have one control to take the place of all these is ludicrous . Each one uses a different mechanism for viewing. The goal is to offer more convenient organization of the files in relation to the file types . Some files are more visual, and some are more distinguishable by file attributes.

Then there are Mozilla tabs. So far, it is the best control for the job because it does all those things mentioned in your poll. If tabs where replaced by either of the other controls, then the benefit of tabs would be lost, just as if you replaced Project Builder's file listing with Preview's thumbnails.

You are trying to create a swiss army knife widget that will be a jack of all trades and master of none. Regardless of what you believe, that isn't good UI design. Oh, and UI stands for User Interface. You seem to consistently forget the "User" part of it considering how often you disregard so many opinions.

Now, if you come up with a cool MegaSuperGuyWidget2003 for system-wide multiple-doc switching, I think a lot of people would appreciate it and a give you the praise that you often give yourself. Better widgets are always good.

[Millennium]

Originally posted by Guy Incognito:
What Millenium doesn't understand is that webpages are mostly 'read-only' documents. Just like PDFs are when using Preview. You can't modify them.

They are not stored on your disk, or on any disk you can access in the "traditional" fashion. You can interact with (many, though not all) Web pages. You can save a Web page to your hard drive, yes, but in the process of doing that you are also fundamentally changing the way you use it; that's where it crosses the line from application to document again.

Hold on; I think I just realized something about your viewpoint. You're a Web designer, aren't you? And I'll bet you don't touch HTML code yourself either; you only use WYSIWYG tools, at least under ordinary circumstances. This is not meant as an insult; while I don't agree with that style of creating pages, it's a valid way of doing it. But if this is true, then no wonder you don't see pages as apps; you've never been taught the process of creating an app, or even what an app really is, and so you don't recognize your own work as a program. Of course, the fact that more traditional programmers tend to look down on Web designers doesn't help either; I sympathize with whatever pain my colleagues may have caused you. They say you're not "really" programming, but the fact is, in a way, you are.

A Web page is a document when it is being edited. It's a document when you save it and start mucking around with it. But in between, when it's on the Web, it's an application. Or, to be more precise, it's the interface to an application. But from the user's perspective, that amounts to the same thing.

Or, to put it another way: is Apple System Profiler a document? It's read-only. You can't really interact with it, except for some flippy-triangles. You can save a report, but you don't use a report the same way you'd use an app.

This is the problem with most Web designers; they forget what they're doing, and what they're making. The Web is not a hard drive. A page is not a piece of paper. You're taking archaic metaphors too literally.

But gawd, Millenium, stfu about webpages being apps.

See above. I hope I've clarified a few things. "Application" versus "document" is little more than a state of interaction. And when people go through a browser, they're interacting with the page as an app, not as a document.

While Mill will claim that MacNN Forums is actually an app for many users to use to edit a very large document...it's more of a document with the tools necessary to edit the 'read-only'ness of HTML.

Guy, do you know anything about how the Web works?

Yes, I say that the MacNN Forums are an application. You use it to collaboratively view and edit documents (which we call "posts"). These documents are stored in a database on our servers. But this page you are reading is not a post. It is an application used to display the post, in a grouping which we call a "thread". The post itself actually looks rather bland and ugly; there are no images, and it's all plaintext. It's filtered through this application -the page- to make it look nice. That is what HTML is for.

I'll give another, non-Web example, which may make this easier for you to understand: a shell script. For those of you who don't know what shell scripts are, they're collections of Terminal commands, stored in a text file. You can run that file on the Terminal and it will execute the commands.

Is this a document? It depends. When you open a shell script up in TextEdit or BBEdit or pico or whatever you prefer, it sure feels like a document, and when you interact with it in that way, it is a document. But when you run it from the command line and it actually does what it's written to do, it's an application. Usually a small one, but an application nonetheless. And note that it does nnot act on its own; it requires an environment (the shell) to do its work. The same goes for Perl scripts or Python scripts or even AppleScript.

Web pages are the same way. You can open one in a text editor or DreamWeaver or something similar, and it's a document. You design, you code, you tell the page what it is supposed to do. But then, you open it in a browser, and it does what it's supposed to do. That is how you interact with the page, as an application. You can save it to your hard drive and edit it as a document, yes, but then you have stopped interacting with it as an app and started interacting with it as a document again; you have hopped back over the line that was originally crossed when you put it on the server.

You are not a traditional programmer. Perhaps this is why you don't realize this yet. For programmers, their work crosses the line between application and document, back and forth, all the time. This is particularly true for scripters, who use the same file both as a document and an app (rather than those working in compiled languages, who must put their code through a compiler, creating a separate file, and then run that). But your page has two faces, You see only the "back face", as it were, where you edit the page, because that is what you do. But you need to recognize the "front face", where people interact with it as a program rather than a document.

Millenium, realize that the pages are all documents. Some that are plain text + a couple of images maybe. And others that circumvent the lack of flexibility of HTML.

HTML is a language for specifying the structure of an interface. Sometimes, that interface only displays "plain text + a couple of images maybe", which isn't entirely unlike system-monitoring applications, and in a cast like this, you need no other code. This is a problem only that Web designers forget that they're making small applications, because this doesn't often feel like programming. But then, neither does writing in Smalltalk for most people, and yet no one would claim that Smalltalk apps are documents.

Other times, the pages present an interface to let the user edit data stored on a server, and some ActiveX controls will even edit documents on your own hard drive (though these tend to be malicious in nature). These are more along the lines of "traditional" applications. But some -perhaps many- designers are still stuck in the old paradigm of pages as documents, which holds back the potential of the Web by a rather astounding degree.

[Guy Incognito]

Originally posted by Millennium:
They are not stored on your disk, or on any disk you can access in the "traditional" fashion. You can interact with (many, though not all) Web pages. You can save a Web page to your hard drive, yes, but in the process of doing that you are also fundamentally changing the way you use it; that's where it crosses the line from application to document again.

Here you are saying that these webpages are apps while on the web...but once downloaded they are documents because I've fundamentally changed the way I use it?

Hold on; I think I just realized something about your viewpoint. You're a Web designer, aren't you? And I'll bet you don't touch HTML code yourself either; you only use WYSIWYG tools, at least under ordinary circumstances. This is not meant as an insult; while I don't agree with that style of creating pages, it's a valid way of doing it. But if this is true, then no wonder you don't see pages as apps; you've never been taught the process of creating an app, or even what an app really is, and so you don't recognize your own work as a program. Of course, the fact that more traditional programmers tend to look down on Web designers doesn't help either; I sympathize with whatever pain my colleagues may have caused you. They say you're not "really" programming, but the fact is, in a way, you are.

HTML is no different than whatever 'language' or 'code' that is beneath a Word document. Word will interpret this invisible code to display the document with specific formatting.

So you're basically insulting me because I don't write my Word documents in the language interpreted by Word? Or my webpages in the HTML language?

A Web page is a document when it is being edited. It's a document when you save it and start mucking around with it. But in between, when it's on the Web, it's an application. Or, to be more precise, it's the interface to an application. But from the user's perspective, that amounts to the same thing.

So I guess my PDF file is a document when I edit it...when I save it and start mucking around with it...but as soon as it's on the web or in the hands of someone else, it's an application or an interface to an application?

Or, to put it another way: is Apple System Profiler a document? It's read-only. You can't really interact with it, except for some flippy-triangles. You can save a report, but you don't use a report the same way you'd use an app.

You're confusing yourself.

This is the problem with most Web designers; they forget what they're doing, and what they're making. The Web is not a hard drive. A page is not a piece of paper. You're taking archaic metaphors too literally.

Really...

The web is a massive storage area composed of many hard drives.

A page is definitely a piece of paper or a 'document'. It just has new aspects that physical paper doesn't.

See above. I hope I've clarified a few things. "Application" versus "document" is little more than a state of interaction. And when people go through a browser, they're interacting with the page as an app, not as a document.

You're very confused.

Guy, do you know anything about how the Web works?

More than you do it seems.

Yes, I say that the MacNN Forums are an application. You use it to collaboratively view and edit documents (which we call "posts"). These documents are stored in a database on our servers. But this page you are reading is not a post. It is an application used to display the post, in a grouping which we call a "thread". The post itself actually looks rather bland and ugly; there are no images, and it's all plaintext. It's filtered through this application -the page- to make it look nice. That is what HTML is for.

Raw Word documents are also bland and ugly when you see the language behind the formatting.

Embedding a mini-application inside a document (like MacNN Forums) does not make a document an application.

I'll give another, non-Web example, which may make this easier for you to understand: a shell script. For those of you who don't know what shell scripts are, they're collections of Terminal commands, stored in a text file. You can run that file on the Terminal and it will execute the commands.

Is this a document? It depends. When you open a shell script up in TextEdit or BBEdit or pico or whatever you prefer, it sure feels like a document, and when you interact with it in that way, it is a document. But when you run it from the command line and it actually does what it's written to do, it's an application. Usually a small one, but an application nonetheless. And note that it does nnot act on its own; it requires an environment (the shell) to do its work. The same goes for Perl scripts or Python scripts or even AppleScript.

Word files, Excel files, Rich Text Files...they all must be applications too right?

Millennium, Millennium, Millenium. Just because there's a degree of low level language behind a document, it doesn't necessarly make it an app.

Word, Text Edit, iTunes...they all interpret a lower level format that isn't seen by most users.

Just because people started off using HTML in its raw form doesn't mean HTML is a language to build apps.

Imagine how ridiculous if the first word processors forced you to use similar methods to building and HTML page. That's how stupid the idea behind HTML is.

Web pages are the same way. You can open one in a text editor or DreamWeaver or something similar, and it's a document. You design, you code, you tell the page what it is supposed to do. But then, you open it in a browser, and it does what it's supposed to do. That is how you interact with the page, as an application. You can save it to your hard drive and edit it as a document, yes, but then you have stopped interacting with it as an app and started interacting with it as a document again; you have hopped back over the line that was originally crossed when you put it on the server.

It's clear you're very confused.

You are not a traditional programmer. Perhaps this is why you don't realize this yet. For programmers, their work crosses the line between application and document, back and forth, all the time. This is particularly true for scripters, who use the same file both as a document and an app (rather than those working in compiled languages, who must put their code through a compiler, creating a separate file, and then run that). But your page has two faces, You see only the "back face", as it were, where you edit the page, because that is what you do. But you need to recognize the "front face", where people interact with it as a program rather than a document.

Using this description, all documents are in fact apps.

HTML is a language for specifying the structure of an interface. Sometimes, that interface only displays "plain text + a couple of images maybe", which isn't entirely unlike system-monitoring applications, and in a cast like this, you need no other code. This is a problem only that Web designers forget that they're making small applications, because this doesn't often feel like programming. But then, neither does writing in Smalltalk for most people, and yet no one would claim that Smalltalk apps are documents.

HTML is not a programming language.

Other times, the pages present an interface to let the user edit data stored on a server, and some ActiveX controls will even edit documents on your own hard drive (though these tend to be malicious in nature). These are more along the lines of "traditional" applications. But some -perhaps many- designers are still stuck in the old paradigm of pages as documents, which holds back the potential of the Web by a rather astounding degree.

Yes...ActiveX controls *are* mini apps...Java applets *are* mini apps...and they are embedded into a document known as an HTML page. Does this make an HTML page magically become an app? If so, then I'd better start running.

edit: removed unnecessary ad homs.

[dfiler]

This is like arguing about whether an El Camino is a car or a pick-up truck.

Web pages are either: neither and both at the same time... or not. Think about that one for a while!


Web pages, from the user's perspective are most definitely documents. Web pages are how users mentally group related data in both concept and physical storage. However, the description of a web page as just 'document' fails to capture all of what's going on. If something contains any user-generated data that is edited and viewed primarily through one window, then it is a document. Preferences are user generated data specific to the configuration of a tool.

However, the terms application and document are neither mutually exclusive nor all-inclusive. Web pages aren't merely documents, or even pure documents.

This often trips users up. It is more difficult on the web to realize what data is stored where and what is necessary to preserve and manipulate that data. Pure documents are much easier for users to work with, everything they see in the window is stored in a file named the same as the window title. Web pages are often generated dynamically from multiple files and databases. Thus, from a developer�s perspective, the term document is rather worthless for describing a 'web page'. Web pages can contain computational code, 'applications', which generate varying output, 'documents', for users to view.

Isn't it obvious to both of you that web pages contain attributes of both applications AND documents?

From the user's perspective this complicates matters greatly. It is impossible to deal with web pages as either pure applications or documents. Initially, the industry was heading more toward the application portrayal, providing users with a billion files whenever a web page was saved. Then along came a different approach, more tightly linking web pages to the document metaphor. We can now save web pages as a single document. This greatly simplifies things for most users by conforming to a well understood and thought out interaction metaphor, the document based application. However, it also confused things because sticking to standard document-based-application interaction techniques routinely results in lost data. The data being viewed as a document is not represented as a document on the server.

We've yet to find an interaction metaphor and GUI that allow for powerful web sites (apps and databases) but with easy, document based front ends. Much more research is needed on this.

Final note:

Tabbed documents, in a single window, blur the distinction between documents and applications. Tabbed documents ruin the direct manipulation metaphor because it un-marries data from its embodying object, the window. This quickly leads to the deterioration of widget/action association for window level controls. Having more than one outcome for the window close widget is bad.

[Silky Voice of The Gorn]

Originally posted by nobodybutme:
Interesting. I think you would need a vertical seperator between the two types.

Yes..good idea. Here's an update:


Ok...much like the Dock, the bookmark bar has two regions...the Bookmark Region, and the Active Page (AP)* Region. Drag an AP to the Bookmark region, and it *becomes* a regular Bookmark. Of course you can shuffle the order within each region as Safari currently does.

There would be a pref to disable the Active Page Region completely, for those who want a simpler browser (which would be as Safari is now).

* "Tabs" - I'm not using the term because it's inaccurate and misleading.

[Guy Incognito]

Originally posted by Silky Voice of The Gorn:


Ok...much like the Dock, the bookmark bar has two regions...the Bookmark Region, and the Active Page (AP)* Region. Drag an AP to the Bookmark region, and it *becomes* a regular Bookmark. Of course you can shuffle the order within each region as Safari currently does.

I had suggested that idea a while ago (in conjunction with someone else) and got nothing but negative comments. This was pretty sad considering the idea was wonderful and worked like the Dock (an UI element everyone using OS X is used to by now.)

People were judging my mockup instead of the dock concept I had proposed.

I had the non-active (bookmarks) and active (cached-pages) in one bar. But alas...tab-lovers everywhere united and stepped all over my concept.

The non-active act like bookmarks in the web browsing sense or Dock favorites in the Dock sense. The actives acted like tabbed-pages in the web browsing sense or launched apps in the Dock sense.

The ones that weren't bookmarks but merely 'cached' would disappear upon quitting the browser...just like apps that aren't Dock favorites disappear when quit.

Dragging them off would make them go poof like the Dock and like bookmarks and Safari.

They could be context-clicked.

They could be moved around and renamed like Safari, OmniWeb and Chimera bookmarks.

I thought it was the most wonderful solution. But no...apparently it was crap. I have contributed lots of very interesting ideas before this mockup and tons other afterwards...but someone, somewhere always comes along and tells me I've contributed nothing and that I'm a tabbed-browsing hater.

This concept here:



...seen in this thread:

http://forums.macnn.com/showthread.p...k&pagenumber=2

I'm glad to see that you've come up with the very same idea. And your mockup is really cool. I'd use that (if these elements would wrap to another line when the line is full...of course, the wrapping would be an option, since we all know how people like options.)

[Silky Voice of The Gorn]

Originally posted by Guy Incognito:

I'm glad to see that you've come up with the very same idea. And your mockup is really cool. I'd use that (if these elements would wrap to another line when the line is full...of course, the wrapping would be an option, since we all know how people like options.)

Looks good! One aspect of your idea that gives me pause is the wrapping...I'm not a big fan of static control regions being overly dynamic-wrapping would "push" the page down, forcing a user to shift their focus needlessly. If the exercize here is to think like Apple, I believe the overflow button that exists now would continue to be appropriate; it's behavior is the same as the Finder, so users are accustomed to it, and it keeps the visible control area clean. Anyway, I believe that having more boomarks bar shortcuts than are visible defeats their purpose to begin with- thats what the bookmarks menu/folders are for!

[dfiler]

Originally posted by Silky Voice of The Gorn:
Yes..good idea. Here's an update:


Ok...much like the Dock, the bookmark bar has two regions...the Bookmark Region, and the Active Page (AP)* Region. Drag an AP to the Bookmark region, and it *becomes* a regular Bookmark. Of course you can shuffle the order within each region as Safari currently does.

There would be a pref to disable the Active Page Region completely, for those who want a simpler browser (which would be as Safari is now).

* "Tabs" - I'm not using the term because it's inaccurate and misleading.

I hate to be harsh... but this is a horrible idea! Although... it would definately be convenient for some users.

The problem is that it uses the same widget for two things which must be dealt with differently by the user. Many or perhaps most users would never be able to remember what the difference is, let alone construct a model of appropriate interactions. If the user forgets, they stand the chance of loosing data. This is the same problem caused by tabbed documents in a single window. Its not the widget that has problems; its the broken direct-manipulation metahpor.

Oh yeah, and in case you haven't noticed, everyone is well aware that tabs could be implemented as an optional feature, off by default. Gee, we never thought of that before

Most of us, arguing against tabs, are doing so because we view it as similar to bundling real miniature knives with action figures. Sure, they're in a protective case by default, but at some point the kid might take them out to play with.

We have yet to invent a form of multiple-documents-in-one-window that doesn't cause occaisional data loss. When one is adequately developed, it should be implemented in the window server, not individual applications.

If safari ships with tabs, people will be loosing form data left and right. Window widgets should have only one associated action.

[Guy Incognito]

Originally posted by dfiler:

If safari ships with tabs, people will be loosing form data left and right.

Very true...this is probably the number one reason why tabs should stay away from Safari (marketed to the mass and thus normal users).

People will click the red close widget and...uh oh...say bye to that e-mail you were writing...say bye to that page that took half an hour to find.

[dfiler]

Originally posted by Guy Incognito:
Very true...this is probably the number one reason why tabs should stay away from Safari (marketed to the mass and thus normal users).

People will click the red close widget and...uh oh...say bye to that e-mail you were writing...say bye to that page that took half an hour to find.

While this point is true for all multiple-docs-in-one-window applications, it is especially pertinent to web browsing. People routinely view and edit hundreds of documents in one web browsing session. This constant switching between documents makes it even more likely that a user will close the window when trying to get back to another tab.

Users would have to remember that they are in Safari and that when they want to return to another document, they can't just close the window to uncover another. Yes, this is a mind boggling simple concept. However, when you're switching between web pages dozens or hundreds of times a day, it is likely to be forgotten on occaision.

Picture your average user e-filing their taxes for the first time. "What the heck is this J-24 deduction" ... clicks on link that explains the deduction, reads the explanation, and then closes the window ... "****! Where'd my tax form go? I'd spent 40 minutes figuring out the correct numbers. "

(Oh yeah: Guy, thanks for not quoting my last sentence... I've now corrected the double negative which ruined my point)

[Silky Voice of The Gorn]

dfiler -
I appreciate your thoughts. I'm actually a reformed "tabist"; I'm not a fan either! I'm just postulating some other ideas for similar functionality.

]The problem is that it uses the same widget for two things which must be dealt with differently by the user. Many or perhaps most users would never be able to remember what the difference is, let alone construct a model of appropriate interactions.

I see it as being no different than the Dock - at glance the Dock appears to be one long bar of icons, but through learned usage it's use and functions become clear. My mockup has a vertical divider, like the dock, and goes one better by having the names italic to further visually separate the regions (italic is not necc. the best solution; underlines, or different color is a possibility-could be a pref...).

If the user forgets, they stand the chance of loosing data. ]

In my model, a user would not be able to drag an Active Page off the bar like a bookmark (much like an active app in the Dock can't be removed); they can only be reshuffled or made into bookmarks. So it would be impossible to lose data, except from explicit menu or keyboard action.

To address your general point, I think users are smart enough to "get it"...the Dock, loved or hated, is a single widget with different functions, and I would surmise that most all users have no problem using it. This is no different, really.

[Millennium]

Originally posted by Guy Incognito:
I had suggested that idea a while ago (in conjunction with someone else) and got nothing but negative comments. This was pretty sad considering the idea was wonderful and worked like the Dock (an UI element everyone using OS X is used to by now.)

People were judging my mockup instead of the dock concept I had proposed.

Yes, and the Dock is still bad UI in a large number of ways, among them the lack of organization. So suddenly, now that it suits you, you support things that you yourself have called bad UI in the past? I think we're starting to see your true colors.

I had the non-active (bookmarks) and active (cached-pages) in one bar. But alas...tab-lovers everywhere united and stepped all over my concept.

For good reasons, it would seem.

The non-active act like bookmarks in the web browsing sense or Dock favorites in the Dock sense. The actives acted like tabbed-pages in the web browsing sense or launched apps in the Dock sense.

So in other words, a single toolbar with two types of elements that act completely differently from each other, labeled only by relative position to one another? Even the Dock isn't that inconsistent.

I thought it was the most wonderful solution. But no...apparently it was crap. I have contributed lots of very interesting ideas before this mockup and tons other afterwards...but someone, somewhere always comes along and tells me I've contributed nothing and that I'm a tabbed-browsing hater.

It's not that you haven't put in any effort. You've obviously had a lot of interesting ideas. But you have yet to come up with one that works as well as tabs.

Let me put it this way: the Dock breaks just about every UI rule in the book. Even you spoke out against it in the past. But with a little time, you found -as I did- that UI rules or no, it actually worked and worked well.

The same is true of tabs. They break every UI rule out there. They shouldn't work, but they do. That's what you're up against, when you try to propose an alternative; you have to beat something which isn't perfect, but is so good that it works when it shouldn't. You have to come with something at least as good as that before "Tab-lovers" will give it a second look. And so far, you haven't managed that.

This concept here:

...doesn't appear to work, unfortunately. Fortunecity seems to be denying image links from outside.

[Guy Incognito]

Originally posted by Millennium:
Yes, and the Dock is still bad UI in a large number of ways, among them the lack of organization. So suddenly, now that it suits you, you support things that you yourself have called bad UI in the past? I think we're starting to see your true colors.

Your stupidity amazes me. I've almost given up arguing with you.

Thanks for telling me there's no organization Mr. I-Like-Tabs-That-Have-Obsolutely-No-Organization.

For good reasons, it would seem.

So in other words, a single toolbar with two types of elements that act completely differently from each other, labeled only by relative position to one another? Even the Dock isn't that inconsistent.

It's exactly like the dock, you stupid fu�k. The elements act exactly the same and there's no distinction between them except that one is permanent (and reverts to it's original state...a bookmark) and the other is not (and disappears...a tab). Just like the Dock.

OMG, W3B P4GE5 ARE APPLICATI0NS!!!!111 THIS DOCK CONCEPT IS PERFECT!!!!!

Start making sense Millenni-dumb! Are web pages apps or not? If they are then shouldn't this be the best approach? Please don't answer...you'll just embarass yourself ONCE AGAIN!

It's not that you haven't put in any effort. You've obviously had a lot of interesting ideas. But you have yet to come up with one that works as well as tabs.

Yeah...in your sick, twisted little world where there's one UI to rule them all and, in the darkness, binds tab-fu�ktards. LORD OF THE TABS! Your preciousssss.

Dumb ass.

Let me put it this way: the Dock breaks just about every UI rule in the book. Even you spoke out against it in the past. But with a little time, you found -as I did- that UI rules or no, it actually worked and worked well.

Yes...there are many flaws with the Dock. There's no organization like you mentionned. The Dock shrinks to become ridiculously useless when windows are minimized or when there are many apps in it.

Come to think of it...it's probably not a very good solution for web browsers. But it's already better than tabs which suffer *gasp* no organization...and becomes ridiculously useless when too many pages are tabbed.

At least my idea wraps to another line.

Don't like wrapping? How about a vertical column instead of a horizontal bar. It holds way more items and could be resized so that names actually make sense. The obvious answer from you will be "what about the wasted screen space"...as if that makes any difference since people that adopt the tabs philosophy already have their browser open as large as the frickin' monitor they're using.

I'm sure that's no good for you either though. TABS!!!!!! YOU LOVE TEH TABS!!!!!!111

The same is true of tabs. They break every UI rule out there. They shouldn't work, but they do. That's what you're up against, when you try to propose an alternative; you have to beat something which isn't perfect, but is so good that it works when it shouldn't. You have to come with something at least as good as that before "Tab-lovers" will give it a second look. And so far, you haven't managed that.

It doesn't work for me...how can it be good if it doesn't work?

...doesn't appear to work, unfortunately. Fortunecity seems to be denying image links from outside.

Can anyone else confirm this? It works for me.

[Guy Incognito]

BTW, in answer to the other thread where you still rant about how web pages are apps.

Adding a few buttons to a document and thus adding interactivity doesn't make a document an app.

HTML is not a programming language. You can do some forms but ultimately you need some VBScript or JavaScript to really make it do anything special.

I can embed some pretty crazy sh!t in a Word document. Does the document become an app? No!

I just dropped a QuickTime movie inside a Text Edit Rich Text document. The movie has little widgets to control the movie. OMG, OMG...it's an APP!

[Millennium]

Originally posted by Guy Incognito:
Your stupidity amazes me. I've almost given up arguing with you.

Making ad hominem attacks is not very nice. I apologize on the occasions where I make them. Perhaps people would like you more if you did the same.

Thanks for telling me there's no organization Mr. I-Like-Tabs-That-Have-Obsolutely-No-Organization.

Tabs are not -and should not be- an organization scheme. They are part of an organization scheme, not the scheme in itself. If you have enough tabs in a single window that you need to organize them, then something is very wrong.

OMG, W3B P4GE5 ARE APPLICATI0NS!!!!111 THIS DOCK CONCEPT IS PERFECT!!!!!

Funny; why are you so angry at me? I've tried to keep from getting mad; I did slip once, but I apologized for that. This is a debate, for crying out loud. Not some deathmatch.

Start making sense Millenni-dumb!

Millenni-dumb? Come on now; there is no need to resort to name-calling. Though I will give you points for originality; I've never heard that one before. I probably shouldn't ever let you get a hold of my real name.

Are web pages apps or not? If they are then shouldn't this be the best approach? Please don't answer...you'll just embarass yourself ONCE AGAIN!

Yes, Web pages are apps. No, this is not the best approach. How can this be? Because even though a Web page is as much an application as, say, Photoshop, they run in fundamentally different environments. And while the Dock is well-suited to the OSX Desktop, it's not well-suited to a browser.

Yeah...in your sick, twisted little world where there's one UI to rule them all and, in the darkness, binds tab-fuktards. LORD OF THE TABS! Your preciousssss.

Dumb ass.

Excuse me? It seems like you're the one being more restrictive here, stating how every UI element's behavior, once set by Apple, must remain set in stone for all eternity. Are tabs never to evolve, now that The Holy UI Experts at Apple have set to writing something without ever having imagined this particular possibility for their use? That seems rather shortsighted to me. You would keep the UI locked in stone, and in the darkness bind it.

Watch your pop-culture references in the future; I can play that game as well as you.

At least my idea wraps to another line.

...which has already been shown to be bad UI by countless experts, long before this dicsussion even began. If you're going to have a dynamically-changing number of widgets, then at least limit them to one dimension of expansion. Yes, space runs out eventually. That will happen no matter how you design a widget, simply because screen space is limited. The question then becomes how to deal with it. I think OSX toolbars and Safari's Bookmarks Bar have the best solution yet found: the chevrons going into an everflow menu. It's not great, but what would you propose instead? Scrolling would be even worse.

Don't like wrapping? How about a vertical column instead of a horizontal bar. It holds way more items and could be resized so that names actually make sense.

The obvious answer from you will be "what about the wasted screen space"...as if that makes any difference since people that adopt the tabs philosophy already have their browser open as large as the frickin' monitor they're using.

Actually, no. Not always. I don't; most don't. And plenty of single-window users have their browsers that large. You seem to act as though tab bars are the only reason people maximize their browser windows, and that simply isn't true. There are many other practical reasons for doing it. I don't, but that's me.

I'm sure that's no good for you either though. TABS!!!!!! YOU LOVE TEH TABS!!!!!!111

Calm the hell down.

It doesn't work for me...how can it be good if it doesn't work?

You are only one person. You are not all users. You are not most users. You are not many users. Hell; you're not even two users. You are one user. There may be a other users like you, or there may not (there happen to be a few). But as pretty much every look at this issue to date has shown, you're in a tiny minority. Tabs work for just about everyone.

And given this, one must ask, why don't tabs work for you? Is the fault in the tab paradigm, or in the way you're using the tabs? From what you've told us about your habits, it seems pretty clear that the fundamental paradigm is sound, and your problems result from nothing more than your own misuse of it. This does, of course, only apply to you personally; it may be different for other users. But for you, the source of the problem seems clear. This is not an ad hominem attack, though it may sound like one at first glance. I am merely analyzing the way you yourself have said you use tabs, and have noted that this may be the source of the problem. That's hardly an attack, only an observation.

[Guy Incognito]

Tiny minority? Do you have a link? Can we have numbers or statistics?

How do you know tab-lovers are the majority? Because of a poll conducted on MacNN? LOL!

I'd be more willing to believe that people with tab-fetishes constituted about 1% of the browsing population *at the most* considering Internet Explorer holds 95% and a few other popular browsers Hyatt hasn't touched don't either. What's that? "They all love it but they just don't know it yet?" Yes, yes...and everyone loves Macs, they just don't know it yet either.

Misuse of tabs? How's that? Because I want to have more tabs than you do in one window?

This is the last time I'm replying to your ill-thought-out responses.

[Millennium]

You know, Guy, I just realized something. You talk awfully big, you know that? That's not an accusation, just an observation. In that lovely Private Message you sent me, you told me to "stop acting like I know anything about a good UI". This would seem to imply that you have a reason to believe you do know something about a good UI.

So, I'd like to hear what this reason is. What are your credentials? What UI research have you done? What applications have you designed? Do you have a Web site I can look at, or even just some articles? Are you Guy Kawasaki, hiding in plain sight with a name so blindingly obvious that no one would ever suspect it was you? Your writing style doesn't match Tog at all, and your philosophies don't match Raskin, so I very much doubt you're either of them. So just how did you get to become such an expert at UI issues?

[Millennium]

Originally posted by Guy Incognito:
Tiny minority? Do you have a link? Can we have numbers or statistics?

How do you know tab-lovers are the majority? Because of a poll conducted on MacNN? LOL!

Not just here. Every single place I have looked, I find tab-lovers to be in the vast majority, among those who have used tabs.

I'd be more willing to believe that people with tab-fetishes constituted about 1% of the browsing population *at the most* considering Internet Explorer holds 95% and a few other popular browsers Hyatt hasn't touched don't either. What's that? "They all love it but they just don't know it yet?" Yes, yes...and everyone loves Macs, they just don't know it yet either.

I do not count people using non-tabbed browsers as being on my side. But neither can you, Guy. People who have never used tabs can only fairly be counted as neutral, because they have yet to form an opinion one way or the other. You cannot claim them for your side any more than I can claim them for mine.

Misuse of tabs? How's that? Because I want to have more tabs than you do in one window?

Because you want everything in one window, eschewing the whole idea of organization and then complaining that there isn't any.

This is the last time I'm replying to your ill-thought-out responses.

A real shame, that. I was hoping that at some point we could get this back to being an actual debate, rather than me arguing my points and you flaming me in response.

I have already admitted that it may be possible to do a better UI for this than tabs. You have yet to admit that tabs just might -not necessarily are, but might- be the best thing to date. Until we are both open to what the other side has to say, further discussion is pointless. I can honestly say with a straight face that I have looked over and considered every alternative you've presented that I'm aware of. And so far, it hasn't been difficult to shoot them down. But I can also say that, at least from where I'm sitting, you don't appear to have given me that same courtesy.

This is not the first time you've shown open contempt for me, either. As I have said in other threads, I will repeat here: why do you hate me so much?

[Silky Voice of The Gorn]

Scandal: Millennium and Guy are the same person!

Kidding aside, is it me, or is all this tab nonsense the geek version of the abortion debate? Makes me long for a year or so ago, before they existed and we all surfed away in multiple document bliss...

[AKcrab]

Until someone writes a program where I can *use* an alternative window management method, I will love tabs. How in the world can I base a judgement on a screenshot, 'mockup', or a brilliant description of a 'best case scenario' alternative?

Tabs are better than every option i've ever been able to actually use.

If we start asking for "better multiple window management" instead of "tabs" will that make you happy, Guy? /rhetorical

[Developer]

Are there any disadvantages of the Windows Task Bar?

[AKcrab]

Originally posted by Developer:
Are there any disadvantages of the Windows Task Bar?

The first off the top of my head is truncation. It can get very severe, since every window gets listed. On W2K you can't change the order of the items listed in the task bar, either.

[mrtew]

Originally posted by Silky Voice of The Gorn:
Yes..good idea. Here's an update:

To me that looks like it would make the trunkation problem worse. My bookmarks line is totally full and my tabs line gets full too. I don't see any advantage at all to combinging the two into one line, just confusion. What's the advantage besides that it doesn't 'misuse' a gui element?

[mrtew]

Originally posted by mrtew:
I think I'm an idiot.

Originally posted by Guy Incognito:
You think? I know!

Where did you even get that quote? Did I sarcastically say that to you a month ago. It's not in this thread.
You'd be more convincing if you didn't throw a tantrum every 4th post (around 5 times per page) and call people stupid fu**s etc. because you can't accept that they don't agree with you. You really aren't as smart as you think you are as you might realize by re-reading your own posts.

Stop trying to take people's tabs away until you think of something better.

[Silky Voice of The Gorn]

Originally posted by mrtew:
To me that looks like it would make the trunkation problem worse. My bookmarks line is totally full and my tabs line gets full too. I don't see any advantage at all to combinging the two into one line, just confusion. What's the advantage besides that it doesn't 'misuse' a gui element?

Very good points; I never claimed my mockup was perfect! .

Personally, I wouldn't have truncation at all. As bookmarks/Active Pages get added, they move over to the existing "overflow" widget as used in Safari and the Finder.

My attempt in this exercise was to keep it to one line, because I don't like wasting vertical space (of which Chimera tabs take a LOT). Even when I used Chimera, I never had more than 2-3 tabs open at once, so the horizontal space consideration was never an issue (that is, all my bookmarks + tabs would fit in one line easily)...my internet connection is pretty fast, so whether using bookmarks or tabs, its just as fast to switch between sites for me.