People do much better reading text paragraphs that are narrow than a line of text that spans the whole width of, say, a monitor.
Do you have problems reading paragraphs that contain dialog from multiple people (such as newspaper articles)? If not, then why must your chats separate each post onto a new line in order for you to follow a conversation?
Not to say that I'm not the freak here, but I still don't understand your vehement objection.
Adium had something similar to this and it was brilliant.
Top left would be the recent and active conversations. Below that is the normal contact list. And the right side is the familiar chat window.
Adam...bring this back. You don't understand what I mean by chat are being horizontally skinny. You're thinking the whole window has to be skinny...not so. Just the text area.
Still...I don't think Apple should touch tabs. I was surprised they did with Safari and I'd be even more surprised if they did with iChat. The casual browser or chatter doesn't need tabs.
To this day, I know no one personally that uses the tabs in Safari. The only time I hear of people using it is on web forums.
The actual proof of concept is here:
Nobody on the team is against single window mode, but nobody wants to spend the time to make it currently either. And that's the rub here, only a small amount of people want this feature, and at the same time, nobody is around to implement it currently. Overmind was the one who originally did this one, but he's moved on to other things.
As to this tabs vs drawer debate, it's really silly. If you like tabs, you use those, and if you like drawers, you use those. There is a client that has both. If someone wanted to implement a drawer in adium it would probably be accepted, so if anyone here who wants drawers is code savvy they could implement it as well.
If you mix up tabs.. then perhaps you should look at how you use tabs and maybe read the tabs before you type something to that person, as it should have their name in it. *shrug*
Other than that, there are people who like both, and don't care which. I personally like adium tabs more because they are more customizable for my preferences, and also I can hit cmd+# to switch tabs, rather than scroll through a bunch. On that same idea though, colloquy has implemented adium tabs as well, but doesn't support cmd+#, which I think is a bummer and kills some usability. *sigh*
Personally, I find Expose to be more efficient in general. It works across all applications, it lets each window be optimized for its own space and contents, it uses no extra screen space, and it allows for fast visual selection of windows. Perfect.
As an avid tab user, Expose doesn't even come close for me.
Tabs offer greater flexibility for keyboard navigation. Cmd left/right to cycle through tabs, or cmd-# to jump directly to one. The tabs are always visible so it's easy to see how many cycles are necessary to reach a message with unviewed content.
It is difficult to discern expose'd IM windows. IM windows contain text and small images, and with several open it is difficult to distinguish between then when using expose. With expose I have to hover my mouse from one window to the next until I find the one with the conversation I want to read.
Expose does not consistently place windows. which makes the hunting and hovering even worse once I press the expose key. With tabs I can order my tabs in a specific way and then switch between them while they remain in this order.
Expose does not provide an overview of IM state like tabs. Tabs will show which contacts are typing and which have messages waiting for you, right on the message window in a central place. You cannot duplicate this functionality with expose.
Expose is far from perfect for IM, and I find statements that Expose is better than tabs for IM to be laughable at best.
Quote:
Originally posted by Kickaha
Tabs are (oh god, do we *have* to go through this again?) a kludge to compensate for the PISS POOR window management on most systems. They are, at *best* a nice extra under MacOS X.
Could one not make the same statement about Expose? Expose is a PISS POOR solution for managing multiple inner-application windows, especially multiple windows of text.
The expose argument may fly with web browsing where pages look different, but when you're dealing with multiple similar looking windows it falls short and doesn't even begin to handle display of state, which tabs do very well.
You state that expose uses no additional screen space. But having multiple windows open DOES use additional screen space, much more so than a 20 pixel tall row of tabs.
Right now tabs (and drawer, depending on personal taste) are the best we have. If you have any suggestions for improving them we're all ears (and we have tried many suggestions in the past, even wild stuff like that single window mode mockup Tick posted a few up).
As an avid tab user, Expose doesn't even come close for me.
Tabs offer greater flexibility for keyboard navigation. Cmd left/right to cycle through tabs, or cmd-# to jump directly to one. The tabs are always visible so it's easy to see how many cycles are necessary to reach a message with unviewed content.
Expose is direct access, no 'cycling' needed.
Quote:
It is difficult to discern expose'd IM windows. IM windows contain text and small images, and with several open it is difficult to distinguish between then when using expose. With expose I have to hover my mouse from one window to the next until I find the one with the conversation I want to read.
Hurm, never had a problem with this one.
Quote:
Expose does not consistently place windows. which makes the hunting and hovering even worse once I press the expose key. With tabs I can order my tabs in a specific way and then switch between them while they remain in this order.
True. But I thought we were talking about window/task *switching*, not *ordering*? Heck, just tile the suckers in that case. :P
Actually, as long as you don't move the windows, Expose *does* put them right back where they were the last time you invoked it.
Quote:
Expose does not provide an overview of IM state like tabs. Tabs will show which contacts are typing and which have messages waiting for you, right on the message window in a central place. You cannot duplicate this functionality with expose.
Errrr... you're talking about a specific hypothetical implementation of tabs, yes?
And the windows in Expose are actually live... Can't get much more 'state' than that.
Quote:
Expose is far from perfect for IM, and I find statements that Expose is better than tabs for IM to be laughable at best.
And I find the idea that tabs are just better in general to be laughable.
Quote:
Could one not make the same statement about Expose? Expose is a PISS POOR solution for managing multiple inner-application windows, especially multiple windows of text.
'Multiple inner-application windows'? Ahhhh, you mean MDI. That Windows concept that everyone, including Windows, is moving away from ASAFP?
And you misread what I said. I didn't say tabs were piss poor, I said they were a hack to get AROUND a piss poor windows management system.
Tabs are a throwback in general UI use. They were designed specifically to get around the nasty NASTY window cycling in Windows (and that Linux GUIs adopted, the idjits.). MacOS X does it right. Cmd-` for window cycling within an app by keystrokes, Expose for graphical random access selection with the mouse. I really don't see the utility of tabs anymore.
Quote:
The expose argument may fly with web browsing where pages look different, but when you're dealing with multiple similar looking windows it falls short and doesn't even begin to handle display of state, which tabs do very well.
See above.
Quote:
You state that expose uses no additional screen space. But having multiple windows open DOES use additional screen space, much more so than a 20 pixel tall row of tabs.
But you're only using one window at a time. So... the Windows 'menu-bar-in-every-window' is *not* a waste of space then?
Quote:
Right now tabs (and drawer, depending on personal taste) are the best we have. If you have any suggestions for improving them we're all ears (and we have tried many suggestions in the past, even wild stuff like that single window mode mockup Tick posted a few up).
I don't see any real way to improve tabs - they're a UI evolutionary dead-end in my opinion.
The only reason they exist is due to lousy window management on other systems... a problem that MacOS X simply doesn't have in the first place.
Perhaps the solution to people not being able to discern windows in Expose mode is for Apple to add a bit more to it. Think of icons. They scale to different sizes based on a few key sizes. At some point when scaling, a decision is made to switch to the next key size. I think the same should be done to windows. A window should be able to request to be notified if it is being scaled by more than X%. Then, the window could opt to redraw itself differently in this case.
In the case of a small instant message window, once it is scaled to half size or less, the window could just display the username of who you are chatting with along with the status (typing, away, available, etc) and number of unread messages. Basically, just give the user the information needed to know what this window is and choose it. All of the data displayed when the window is not scaled is irrelevant as this text is too small for some/most people to read anyway.
Of course, if the window isn't requesting this notification, it would just scale as it currently does. Maybe this could be the big feature of Expose 2.0?
Adam, you're exaggerating. I know you're proud of your tab implementation...it's certainly the best out of everything I've seen but as Kickaha points out, it's a solution in search of a problem.
Exposé is not nearly as bad as you say it is.
How many conversations do you normally have simultaneously? 7? 8? 12?
Exposé has no problem displaying 12 Adium chat windows at 1028x768. With buddy picture and decent size buddy name somewhere in the window, anyone can easily identify any window. Much more so that 12 tabs inside a window. And the windows are much larger targets to hit.
You could say that tabs are meant for 10.2 users. I'd accept that. But tabs over Exposé?
No. Expose is not direct access, it requires (for a primarily text window) hovering the windows to see their titles and figure out which one you want, as I said.
Without tabs, cycling is needed (cmd-~) to switch between conversations. There is no sense of placement when cycling with cmd-~. This is what I meant.
Quote:
Originally posted by Kickaha
Errrr... you're talking about a specific hypothetical implementation of tabs, yes?
I am talking about the tabs in Adium.
No offense, but your replies to my points are pretty weak and a lot of them do not follow from what I've said. I'm a little surprised to see such a post from one of the moderators here.
Perhaps the solution to people not being able to discern windows in Expose mode is for Apple to add a bit more to it. Think of icons. They scale to different sizes based on a few key sizes. At some point when scaling, a decision is made to switch to the next key size. I think the same should be done to windows. A window should be able to request to be notified if it is being scaled by more than X%. Then, the window could opt to redraw itself differently in this case.
In the case of a small instant message window, once it is scaled to half size or less, the window could just display the username of who you are chatting with along with the status (typing, away, available, etc) and number of unread messages. Basically, just give the user the information needed to know what this window is and choose it. All of the data displayed when the window is not scaled is irrelevant as this text is too small for some/most people to read anyway.
Of course, if the window isn't requesting this notification, it would just scale as it currently does. Maybe this could be the big feature of Expose 2.0?
That would be interesting but it can be done right now. Any theme that has a large enough buddy picture will scale decently. Proteus allows you to put buddy picts in the toolbar...sure, the picture is small but you'd need over 8 windows to really start having difficulties distinguishing between picts.
People aren't stupid. It's actually quite easy to differentiate using just a few visual cues...the way the text is laid out, the buddy pict...you don't need much more than that.
No. Expose is not direct access, it requires (for a primarily text window) hovering the windows to see their titles and figure out which one you want, as I said.
You're exaggerating. I don't know anyone who has had major problems distinguishing between even similar looking plain text TextEdit files let alone chat windows with the buddy pict plastered all over it.
If there something people have trouble distinguishing is truncated names...especially French hyphenated names. Jean-Francois, Jean-Paul, Marc-Andre, Marc-Antoine.
What do you do when you're confronted with 3 tabs that look like this: Jean-...?
You're exaggerating. I don't know anyone who has had major problems distinguishing between even similar looking plain text TextEdit files let alone chat windows with the buddy pict plastered all over it.
No. Expose is not direct access, it requires (for a primarily text window) hovering the windows to see their titles and figure out which one you want, as I said.
Actually, I can't say I've ever really had that problem. I do primarily coding (text), and haven't had the issue you're claiming.
In iChat, I've never had a need to hover, the user pics clue me in immediately. *shrug* (As do the titlebars, but maybe my eyes are just better at picking out tiny text.)
So, for me, Expose is quite direct access. "I want *that* chat window *click*"
Quote:
Without tabs, cycling is needed (cmd-~) to switch between conversations. There is no sense of placement when cycling with cmd-~. This is what I meant.
Why is placement important in cycling? They're orthogonal issues. "I want that window" is a different idea than "I want *this* window *there*" One does not preclude the other.
Quote:
I am talking about the tabs in Adium.
No offense, but your replies to my points are pretty weak and a lot of them do not follow from what I've said. I'm a little surprised to see such a post from one of the moderators here.
Then refute them. Rebuttal time. You have 90 seconds.
Look, I know a lot people like tabs. They're funky, they're cool, and they're the hip UI widget du jour.
But they were made to solve a problem that the Mac simply doesn't have.
For inter-application windows in an IM client, yes. Tabs provide much better window cycling and state visibility than separate windows with expose.
Sure, expose helps manage a cluttered screen and find lost windows (and does a very good job of it!). But with tabs, we prevent both these trouble situations from happening, rather than simply providing a means to deal with them.
This is why tabs (or some form of window management, such as a source list in a drawer) are better than expose for this particular application.
For inter-application windows in an IM client, yes. Tabs provide much better window cycling and state visibility than separate windows with expose.
Sure, expose helps manage a cluttered screen and find lost windows (and does a very good job of it!). But with tabs, we prevent both these trouble situations from happening, rather than simply providing a means to deal with them.
This is why tabs (or some form of window management, such as a source list in a drawer) are better than expose for this particular application.
Okay, let's do a gedanken experiment. Take the tabs idea to the logical conclusion: all windows, from all apps, tabbed.
If tabs prevent clutter, than that seems like a natural direction to go.
Silly? Yup. You bet. Which means that the initial idea is probably a less then elegant solution.
Now, think about Cmd-`/Cmd-tab cycling alone. It gets you the ability to cycle within *just the windows of one app* at a time. Now, why tabs? To reduce the number of windows open? Why? Well, because it causes clutter and you might lose a window... which is what Expose solves. For all apps. All the time. For as many windows as you may have. Cmd-`/Cmd-tab scales. Expose scales. They both work for any app, any window size, any content. (Yes, you point out that pure text *can* be problematic - in my experience, it is not.) This is a set of scalable and orthogonal solutions that work exceedingly well.
Other UIs don't allow you to cycle just within the current app's windows, so tabs were invented to get around that problem - a way of quickly selecting the pseudo-window you want in just that one app, without having to cycle through other apps' windows.
We don't have that problem.
Tabs don't scale well. They don't work for all applications, and they really don't work for situations where windows need to be various sizes. They are, simply put, inelegant and a workaround.
Now, that being said, there are some nice implementations of tabs. Adium looks to have one. Kudos. But it is still a UI widget that is in search of a problem on the Mac. *shrug*
Then refute them. Rebuttal time. You have 90 seconds.
If you really want me to... (Keep in mind I am referring to tabs in an IM client - one of the topics in this thread - not the proliferation of tabs into apps where they do not solve a particular need, which I am against).
Quote:
Originally posted by Kickaha
And the windows in Expose are actually live... Can't get much more 'state' than that.
Actually you can, using a bar of tabs with simple icons on them.
Quote:
Originally posted by Kickaha
'Multiple inner-application windows'? Ahhhh, you mean MDI. That Windows concept that everyone, including Windows, is moving away from ASAFP?
No, I do not. I mean the simplification of application interfaces by moving away from multiple windows. The source list in iTunes, the account drawer in mail, the tabs in safari, the source list in iPhoto. Interfaces simplified into a single window (for great benefit!) by using some sort of tab or source list control.
Quote:
Originally posted by Kickaha
And you misread what I said. I didn't say tabs were piss poor, I said they were a hack to get AROUND a piss poor windows management system.
Tabs are not a hack, and tabs in an IM client work in addition to the window management system, they are not meant to replace it.
Quote:
Originally posted by Kickaha
Tabs are a throwback in general UI use. They were designed specifically to get around the nasty NASTY window cycling in Windows (and that Linux GUIs adopted, the idjits.).
Tabs (or a source list in a drawer) are used in an IM client to simplify the interface by keeping related information together in an organized fashion in a common place. Tabs are not a "throwback".
Quote:
Originally posted by Kickaha
MacOS X does it right. Cmd-` for window cycling within an app by keystrokes, Expose for graphical random access selection with the mouse. I really don't see the utility of tabs anymore.
Tabs offer many advantages over Cmd-`, I've already stated them in my previous reply.
Quote:
Originally posted by Kickaha
But you're only using one window at a time. So... the Windows 'menu-bar-in-every-window' is *not* a waste of space then?
Without tabs, there are many conversation windows on my screen (clutter). With tabs, there is a common conversation window on my screen that holds all my conversations (organization). Did I explain it more clearly that time?
No problems distinguishing 9 conversations with Exposé.
Maybe others wouldn't but I could probably even read conversation text and see who's replied and who didn't. 9 conversations!!! I rarely have more than 5 simultaneous conversations.
1024x768...one step above the lowest sane res on OS X. I think this either an average resolution or maybe even low compared to today's standard monitor/LCD flat screen resolution.
If you're still using 640x480, you probably shouldn't be using OS X.
Adam, let me know when your tabs allow drag and drop of text clippings or images.
Let me know when I can follow to conversations at the same time. A private and a group chat. You'll probably answer "easy, separate them", to which I will reply, "why tabs". Tabs simply kill the multitasking aspect of Mac OS.
It's fine on Windows where things such as full-screen windows and MDI exist which go against multitasking but on Mac OS X? Unnecessary.
[Tabs] don't work for all applications, and they really don't work for situations where windows need to be various sizes.
I agree!!
I'm only speaking about tabs (or a source list in a drawer) as a means to unify content within a common interface in the specific example of an IM client. If you keep the discussion focused on the use of tabs in an IM client, it should be easy to see the benefits they provide.
Much like expose, tabs are not the best solution for every application. But a lot of us feel that they are one of the best solutions for an IM client at this time, not to say something better won't come up in the future
Comments
Originally posted by kim kap sol
People do much better reading text paragraphs that are narrow than a line of text that spans the whole width of, say, a monitor.
Do you have problems reading paragraphs that contain dialog from multiple people (such as newspaper articles)? If not, then why must your chats separate each post onto a new line in order for you to follow a conversation?
Not to say that I'm not the freak here, but I still don't understand your vehement objection.
Originally posted by kim kap sol
Adium had something similar to this and it was brilliant.
Top left would be the recent and active conversations. Below that is the normal contact list. And the right side is the familiar chat window.
Adam...bring this back. You don't understand what I mean by chat are being horizontally skinny. You're thinking the whole window has to be skinny...not so. Just the text area.
Still...I don't think Apple should touch tabs. I was surprised they did with Safari and I'd be even more surprised if they did with iChat. The casual browser or chatter doesn't need tabs.
To this day, I know no one personally that uses the tabs in Safari. The only time I hear of people using it is on web forums.
The actual proof of concept is here:
Nobody on the team is against single window mode, but nobody wants to spend the time to make it currently either. And that's the rub here, only a small amount of people want this feature, and at the same time, nobody is around to implement it currently. Overmind was the one who originally did this one, but he's moved on to other things.
As to this tabs vs drawer debate, it's really silly. If you like tabs, you use those, and if you like drawers, you use those. There is a client that has both. If someone wanted to implement a drawer in adium it would probably be accepted, so if anyone here who wants drawers is code savvy they could implement it as well.
If you mix up tabs.. then perhaps you should look at how you use tabs and maybe read the tabs before you type something to that person, as it should have their name in it. *shrug*
Other than that, there are people who like both, and don't care which. I personally like adium tabs more because they are more customizable for my preferences, and also I can hit cmd+# to switch tabs, rather than scroll through a bunch. On that same idea though, colloquy has implemented adium tabs as well, but doesn't support cmd+#, which I think is a bummer and kills some usability. *sigh*
Either way, this argument is silly
Originally posted by Kickaha
Personally, I find Expose to be more efficient in general. It works across all applications, it lets each window be optimized for its own space and contents, it uses no extra screen space, and it allows for fast visual selection of windows. Perfect.
As an avid tab user, Expose doesn't even come close for me.
Tabs offer greater flexibility for keyboard navigation. Cmd left/right to cycle through tabs, or cmd-# to jump directly to one. The tabs are always visible so it's easy to see how many cycles are necessary to reach a message with unviewed content.
It is difficult to discern expose'd IM windows. IM windows contain text and small images, and with several open it is difficult to distinguish between then when using expose. With expose I have to hover my mouse from one window to the next until I find the one with the conversation I want to read.
Expose does not consistently place windows. which makes the hunting and hovering even worse once I press the expose key. With tabs I can order my tabs in a specific way and then switch between them while they remain in this order.
Expose does not provide an overview of IM state like tabs. Tabs will show which contacts are typing and which have messages waiting for you, right on the message window in a central place. You cannot duplicate this functionality with expose.
Expose is far from perfect for IM, and I find statements that Expose is better than tabs for IM to be laughable at best.
Originally posted by Kickaha
Tabs are (oh god, do we *have* to go through this again?) a kludge to compensate for the PISS POOR window management on most systems. They are, at *best* a nice extra under MacOS X.
Could one not make the same statement about Expose? Expose is a PISS POOR solution for managing multiple inner-application windows, especially multiple windows of text.
The expose argument may fly with web browsing where pages look different, but when you're dealing with multiple similar looking windows it falls short and doesn't even begin to handle display of state, which tabs do very well.
You state that expose uses no additional screen space. But having multiple windows open DOES use additional screen space, much more so than a 20 pixel tall row of tabs.
Right now tabs (and drawer, depending on personal taste) are the best we have. If you have any suggestions for improving them we're all ears (and we have tried many suggestions in the past, even wild stuff like that single window mode mockup Tick posted a few up).
Originally posted by resimada
As an avid tab user, Expose doesn't even come close for me.
Tabs offer greater flexibility for keyboard navigation. Cmd left/right to cycle through tabs, or cmd-# to jump directly to one. The tabs are always visible so it's easy to see how many cycles are necessary to reach a message with unviewed content.
Expose is direct access, no 'cycling' needed.
It is difficult to discern expose'd IM windows. IM windows contain text and small images, and with several open it is difficult to distinguish between then when using expose. With expose I have to hover my mouse from one window to the next until I find the one with the conversation I want to read.
Hurm, never had a problem with this one.
Expose does not consistently place windows. which makes the hunting and hovering even worse once I press the expose key. With tabs I can order my tabs in a specific way and then switch between them while they remain in this order.
True. But I thought we were talking about window/task *switching*, not *ordering*? Heck, just tile the suckers in that case. :P
Actually, as long as you don't move the windows, Expose *does* put them right back where they were the last time you invoked it.
Expose does not provide an overview of IM state like tabs. Tabs will show which contacts are typing and which have messages waiting for you, right on the message window in a central place. You cannot duplicate this functionality with expose.
Errrr... you're talking about a specific hypothetical implementation of tabs, yes?
And the windows in Expose are actually live...
Expose is far from perfect for IM, and I find statements that Expose is better than tabs for IM to be laughable at best.
And I find the idea that tabs are just better in general to be laughable.
Could one not make the same statement about Expose? Expose is a PISS POOR solution for managing multiple inner-application windows, especially multiple windows of text.
'Multiple inner-application windows'? Ahhhh, you mean MDI. That Windows concept that everyone, including Windows, is moving away from ASAFP?
And you misread what I said. I didn't say tabs were piss poor, I said they were a hack to get AROUND a piss poor windows management system.
Tabs are a throwback in general UI use. They were designed specifically to get around the nasty NASTY window cycling in Windows (and that Linux GUIs adopted, the idjits.). MacOS X does it right. Cmd-` for window cycling within an app by keystrokes, Expose for graphical random access selection with the mouse. I really don't see the utility of tabs anymore.
The expose argument may fly with web browsing where pages look different, but when you're dealing with multiple similar looking windows it falls short and doesn't even begin to handle display of state, which tabs do very well.
See above.
You state that expose uses no additional screen space. But having multiple windows open DOES use additional screen space, much more so than a 20 pixel tall row of tabs.
But you're only using one window at a time. So... the Windows 'menu-bar-in-every-window' is *not* a waste of space then?
Right now tabs (and drawer, depending on personal taste) are the best we have. If you have any suggestions for improving them we're all ears (and we have tried many suggestions in the past, even wild stuff like that single window mode mockup Tick posted a few up).
I don't see any real way to improve tabs - they're a UI evolutionary dead-end in my opinion.
The only reason they exist is due to lousy window management on other systems... a problem that MacOS X simply doesn't have in the first place.
Originally posted by Kickaha
Errrr... you're talking about a specific hypothetical implementation of tabs, yes?
No.
In the case of a small instant message window, once it is scaled to half size or less, the window could just display the username of who you are chatting with along with the status (typing, away, available, etc) and number of unread messages. Basically, just give the user the information needed to know what this window is and choose it. All of the data displayed when the window is not scaled is irrelevant as this text is too small for some/most people to read anyway.
Of course, if the window isn't requesting this notification, it would just scale as it currently does. Maybe this could be the big feature of Expose 2.0?
Exposé is not nearly as bad as you say it is.
How many conversations do you normally have simultaneously? 7? 8? 12?
Exposé has no problem displaying 12 Adium chat windows at 1028x768. With buddy picture and decent size buddy name somewhere in the window, anyone can easily identify any window. Much more so that 12 tabs inside a window. And the windows are much larger targets to hit.
You could say that tabs are meant for 10.2 users. I'd accept that. But tabs over Exposé?
Originally posted by Kickaha
Expose is direct access, no 'cycling' needed.
No. Expose is not direct access, it requires (for a primarily text window) hovering the windows to see their titles and figure out which one you want, as I said.
Without tabs, cycling is needed (cmd-~) to switch between conversations. There is no sense of placement when cycling with cmd-~. This is what I meant.
Originally posted by Kickaha
Errrr... you're talking about a specific hypothetical implementation of tabs, yes?
I am talking about the tabs in Adium.
No offense, but your replies to my points are pretty weak and a lot of them do not follow from what I've said. I'm a little surprised to see such a post from one of the moderators here.
Originally posted by rrabu
Perhaps the solution to people not being able to discern windows in Expose mode is for Apple to add a bit more to it. Think of icons. They scale to different sizes based on a few key sizes. At some point when scaling, a decision is made to switch to the next key size. I think the same should be done to windows. A window should be able to request to be notified if it is being scaled by more than X%. Then, the window could opt to redraw itself differently in this case.
In the case of a small instant message window, once it is scaled to half size or less, the window could just display the username of who you are chatting with along with the status (typing, away, available, etc) and number of unread messages. Basically, just give the user the information needed to know what this window is and choose it. All of the data displayed when the window is not scaled is irrelevant as this text is too small for some/most people to read anyway.
Of course, if the window isn't requesting this notification, it would just scale as it currently does. Maybe this could be the big feature of Expose 2.0?
That would be interesting but it can be done right now. Any theme that has a large enough buddy picture will scale decently. Proteus allows you to put buddy picts in the toolbar...sure, the picture is small but you'd need over 8 windows to really start having difficulties distinguishing between picts.
People aren't stupid. It's actually quite easy to differentiate using just a few visual cues...the way the text is laid out, the buddy pict...you don't need much more than that.
Originally posted by resimada
*sigh*
No. Expose is not direct access, it requires (for a primarily text window) hovering the windows to see their titles and figure out which one you want, as I said.
You're exaggerating. I don't know anyone who has had major problems distinguishing between even similar looking plain text TextEdit files let alone chat windows with the buddy pict plastered all over it.
If there something people have trouble distinguishing is truncated names...especially French hyphenated names. Jean-Francois, Jean-Paul, Marc-Andre, Marc-Antoine.
What do you do when you're confronted with 3 tabs that look like this: Jean-...?
Originally posted by kim kap sol
You're exaggerating. I don't know anyone who has had major problems distinguishing between even similar looking plain text TextEdit files let alone chat windows with the buddy pict plastered all over it.
/me raises hands
I have a slight vision problem..
Originally posted by The_Tick
/me raises hands
I have a slight vision problem..
Then you'd probably have trouble seeing those small tabs.
I have a slight motor-control problem and I can't properly hit the small tabs.
Originally posted by resimada
No. Expose is not direct access, it requires (for a primarily text window) hovering the windows to see their titles and figure out which one you want, as I said.
Actually, I can't say I've ever really had that problem. I do primarily coding (text), and haven't had the issue you're claiming.
In iChat, I've never had a need to hover, the user pics clue me in immediately. *shrug* (As do the titlebars, but maybe my eyes are just better at picking out tiny text.)
So, for me, Expose is quite direct access. "I want *that* chat window *click*"
Without tabs, cycling is needed (cmd-~) to switch between conversations. There is no sense of placement when cycling with cmd-~. This is what I meant.
Why is placement important in cycling? They're orthogonal issues. "I want that window" is a different idea than "I want *this* window *there*" One does not preclude the other.
I am talking about the tabs in Adium.
No offense, but your replies to my points are pretty weak and a lot of them do not follow from what I've said. I'm a little surprised to see such a post from one of the moderators here.
Then refute them. Rebuttal time. You have 90 seconds.
Look, I know a lot people like tabs. They're funky, they're cool, and they're the hip UI widget du jour.
But they were made to solve a problem that the Mac simply doesn't have.
Originally posted by kim kap sol
Then you'd probably have trouble seeing those small tabs.
I have a slight motor-control problem and I can't properly hit the small tabs.
I can see the tabs perfectly fine. I have problems differentiating multiple documents in expose. Same with separated out adium windows.
As to your motor control problem, that's different than what people have been arguing here.
Originally posted by kim kap sol
But tabs over Exposé?
For inter-application windows in an IM client, yes. Tabs provide much better window cycling and state visibility than separate windows with expose.
Sure, expose helps manage a cluttered screen and find lost windows (and does a very good job of it!). But with tabs, we prevent both these trouble situations from happening, rather than simply providing a means to deal with them.
This is why tabs (or some form of window management, such as a source list in a drawer) are better than expose for this particular application.
Originally posted by resimada
For inter-application windows in an IM client, yes. Tabs provide much better window cycling and state visibility than separate windows with expose.
Sure, expose helps manage a cluttered screen and find lost windows (and does a very good job of it!). But with tabs, we prevent both these trouble situations from happening, rather than simply providing a means to deal with them.
This is why tabs (or some form of window management, such as a source list in a drawer) are better than expose for this particular application.
Okay, let's do a gedanken experiment. Take the tabs idea to the logical conclusion: all windows, from all apps, tabbed.
If tabs prevent clutter, than that seems like a natural direction to go.
Silly? Yup. You bet. Which means that the initial idea is probably a less then elegant solution.
Now, think about Cmd-`/Cmd-tab cycling alone. It gets you the ability to cycle within *just the windows of one app* at a time. Now, why tabs? To reduce the number of windows open? Why? Well, because it causes clutter and you might lose a window... which is what Expose solves. For all apps. All the time. For as many windows as you may have. Cmd-`/Cmd-tab scales. Expose scales. They both work for any app, any window size, any content. (Yes, you point out that pure text *can* be problematic - in my experience, it is not.) This is a set of scalable and orthogonal solutions that work exceedingly well.
Other UIs don't allow you to cycle just within the current app's windows, so tabs were invented to get around that problem - a way of quickly selecting the pseudo-window you want in just that one app, without having to cycle through other apps' windows.
We don't have that problem.
Tabs don't scale well. They don't work for all applications, and they really don't work for situations where windows need to be various sizes. They are, simply put, inelegant and a workaround.
Now, that being said, there are some nice implementations of tabs. Adium looks to have one. Kudos. But it is still a UI widget that is in search of a problem on the Mac. *shrug*
Originally posted by Kickaha
Then refute them. Rebuttal time. You have 90 seconds.
If you really want me to... (Keep in mind I am referring to tabs in an IM client - one of the topics in this thread - not the proliferation of tabs into apps where they do not solve a particular need, which I am against).
Originally posted by Kickaha
And the windows in Expose are actually live...
Actually you can, using a bar of tabs with simple icons on them.
Originally posted by Kickaha
'Multiple inner-application windows'? Ahhhh, you mean MDI. That Windows concept that everyone, including Windows, is moving away from ASAFP?
No, I do not. I mean the simplification of application interfaces by moving away from multiple windows. The source list in iTunes, the account drawer in mail, the tabs in safari, the source list in iPhoto. Interfaces simplified into a single window (for great benefit!) by using some sort of tab or source list control.
Originally posted by Kickaha
And you misread what I said. I didn't say tabs were piss poor, I said they were a hack to get AROUND a piss poor windows management system.
Tabs are not a hack, and tabs in an IM client work in addition to the window management system, they are not meant to replace it.
Originally posted by Kickaha
Tabs are a throwback in general UI use. They were designed specifically to get around the nasty NASTY window cycling in Windows (and that Linux GUIs adopted, the idjits.).
Tabs (or a source list in a drawer) are used in an IM client to simplify the interface by keeping related information together in an organized fashion in a common place. Tabs are not a "throwback".
Originally posted by Kickaha
MacOS X does it right. Cmd-` for window cycling within an app by keystrokes, Expose for graphical random access selection with the mouse. I really don't see the utility of tabs anymore.
Tabs offer many advantages over Cmd-`, I've already stated them in my previous reply.
Originally posted by Kickaha
But you're only using one window at a time. So... the Windows 'menu-bar-in-every-window' is *not* a waste of space then?
Without tabs, there are many conversation windows on my screen (clutter). With tabs, there is a common conversation window on my screen that holds all my conversations (organization). Did I explain it more clearly that time?
No problems distinguishing 9 conversations with Exposé.
Maybe others wouldn't but I could probably even read conversation text and see who's replied and who didn't. 9 conversations!!! I rarely have more than 5 simultaneous conversations.
1024x768...one step above the lowest sane res on OS X. I think this either an average resolution or maybe even low compared to today's standard monitor/LCD flat screen resolution.
If you're still using 640x480, you probably shouldn't be using OS X.
Let me know when I can follow to conversations at the same time. A private and a group chat. You'll probably answer "easy, separate them", to which I will reply, "why tabs". Tabs simply kill the multitasking aspect of Mac OS.
It's fine on Windows where things such as full-screen windows and MDI exist which go against multitasking but on Mac OS X? Unnecessary.
Originally posted by Kickaha
[Tabs] don't work for all applications, and they really don't work for situations where windows need to be various sizes.
I agree!!
I'm only speaking about tabs (or a source list in a drawer) as a means to unify content within a common interface in the specific example of an IM client. If you keep the discussion focused on the use of tabs in an IM client, it should be easy to see the benefits they provide.
Much like expose, tabs are not the best solution for every application. But a lot of us feel that they are one of the best solutions for an IM client at this time, not to say something better won't come up in the future