{#} Replies are directed back to [EMAIL PROTECTED]
{#} To reply to the author, write to Ben Rister <[EMAIL PROTECTED]>
Good bunch of comments...
>> * (Window width) Each name is of different length, which means that you
>> either cut off the long names or waste space to the side of the shorter
>> names. (Also not just Fire)
>
> Standard, accepted limitation of the list view. Finder does the same thing.
Windows is also a standard, accepted limitation of computing. Need I say
more? =)
>> * (Window height) The number of people online at any given time varies, so
>> unless you resize your window every time somebody logs in or out, you're
>> probably wasting space (or can't see all your buddies). The more buddies
>> you have altogether, the more widely it varies. (Not just Fire.)
>
> What if the Buddy List window would resize itself according to its needs?
I can't think of a concrete reason why besides taking control away from the
user, but it seems like an intuitively bad thing to have a window sitting
there resizing itself without user interaction. (Not to mention the
question of which direction to grow.) Perhaps somebody with more HCI
knowledge can provide an analysis one way or the other?
>> * Anybody else find Cmd-Shft-I somewhat excessive?
>
> Nope. I had to look in the menus to find what it did.
I think this may even support my point. =)
>> * Most people have a relatively small "working set" of people to whom they
>> actually want to talk. One can help manage this and pare it down through
>> groups and collapsing unused ones, but surely there is a more elegant
>> solution... (Not just Fire.)
>
> This is an accepted metaphor. A tad inelegant, perhaps. But people are
> used to it.
Again, Windows is the norm, too. And it's a tad inelegant, but people are
used to it. But some people choose to do something a bit different because
it suits their purposes better.
>> * What's the most frequent action performed on buddies, by far? Sending a
>> message. Why do we have to double-click to do that?
>
> Because it plays on the metaphor people are used to with their computer. If
> you want to use something, you double-click to open it. I recently tried
> using KDX, and I hate the way single-clicking causes an action.
> Single-clicking should make a selection (unless you're clicking on a
> button), double-clicking causes the action.
But you're *not* opening something. If you want to talk about that, look at
the dock itself. Single click launches the application/activates the
window. It's the accepted behavior on "bars." I agree that you shouldn't
have single-click-actions on the list view, but you can make it easier, with
single click, putting it in a context where that is the "correct" behavior.
> (BTW, *very* good sales-pitch tone. :) )
<shudder> =)
>> * Second most frequent? Getting information. As mentioned above, this
>> could be much easier.
>
> I don't remember this being part of your survey. I'm not sure this is the
> second most common buddy action.
It wasn't, that was based upon some research I did with another group. It
may not be true of Fire users, though, as I think about it, since other
people's away messages don't work...
>> The BuddyBar sits at the bottom of your screen, and is about as tall as the
>> menubar, if not a bit shorter. It can be floating on top of all
>> applications if you prefer, act as a normal window, or even sit behind
>> everything.
>
> I feel that Windows' multiple taskbars is one of the most inelegant UI
> solutions Redmond has come up with.
Multiple taskbars? Maybe it's a new XP feature or something, but I've not
seen that. But I'd agree that that's a bad idea.
But in any case, this isn't another dock.
>> * Screen real estate of buddy list reduced to essentially zero in normal
>> case, without loss of features commonly used
>
> I don't think it's quite zero. *Overhead* might be approaching zero.
Of course not actually zero, I think that anybody who can express any
information without any screen space at all deserves some kind of medal.
However, because it has effectively no impact on your work, it *is*
essentially zero.
>> * All common actions take 1 click
>
> They do now, with a modifier key.
A click, drag-target, and release is not a click.
>> * Service status information more visible (on a cleaner background than the
>> dock icon), control easier
>
> The dock icon may be getting cluttered (I'm waiting for someone to
> contribute a "Show Dancing Jesus in Dock" patch) but account status is
> easily glanced at and determined. If you show ghosted accounts, it's even
> spatial.
Dammit, you beat me to my next idea! =)
I'm not sure what the differences are between our systems, but the service
status is not that clear to me in my dock. <shrugs>
>> * Less duplicates between the same buddy on different services--just put the
>> "preferred" one in the bar.
>
> What if you created an UberBuddy -- a group of buddies that would act as
> one. Define a preferred order among the buddies in the group, and only the
> highest-priority buddy in the group is shown. Actions would be performed on
> the preferred buddy.
Yep, I think that's a great idea, and somebody should do it. I'm not sure
how you're going to express that to the user in an elegant way (and there
are some questions that arise), but I'll look forward to it. =)
>> * Requires dock on left or right, won't work with dock on bottom. This is
>> the biggest problem, as it appears that most people have left the dock on
>> the bottom. One could put it at the top under the menu bar, but that is a
>> significantly poorer solution from a mouse-targeting perspective, not to
>> mention possible interference with the menu bar. However, it would retain
>> the other benefits. Any comments or suggestions on this are highly
>> requested.
>
> Yeah, the bottom of the screen's a pretty useful location isn't it? Maybe
> that's why Apple put the Dock there... ;)
I think that when all is said and done, Apple put the dock on the bottom
because it made a nice parallel with the menu bar. Aesthetics. The NeXT
bar from whence it came was properly positioned on the side, where it makes
the best interface sense. Because the items in the dock are (square) icons,
not text, there's no orientation preference, but as I mentioned in a
previous email, English text unquestionably works best horizontally.
>> * Issue with apps placing windows with resize controls behind the bar? Only
>> applies to when floating, but maybe we can tell the system to not autosize
>> windows there, like the dock does (for the apps which listen). Can always
>> hide Fire momentarily if it is an issue for a second.
>
> Can't do it. The system call is Dock-aware and that's it.
Yeah, was afraid of that.
> On 2/5/02 22:00, "Jonathan Baumgartner" <[EMAIL PROTECTED]> wrote:
Replied to most of this stuff to the actual email...
>> Another nice option would be auto-hide. That would take care of this
>> problem.
>
> *shudder* And introduce others. Auto-hiding decreases the functionality of
> the dock by an order of magnitude. You have to hit the edge of the screen,
> wait for it to appear, then acquire a new target and move for it. (My
> roommate has his dock set to auto-hide with small icons and maximum
> modification -- it's almost unusable.) And every time an experienced -- I'm
> not even talking newbies here -- user sits down at a Mac with the dock
> hidden, the first question they ask -- usually mid-drag -- is "Where's your
> dock?" But I digress.
I agree wholeheartedly.
> On 2/6/02 06:25, "Joel Richard" <[EMAIL PROTECTED]> wrote:
>
>> Also, I'm the kind of person who has windows on top of windows on top of
>> windows. So once the buddy list is covered up completely, I don't notice it
>> anymore anyway. Even on a TiBook my windows overlap. (then again, I'm the
>> kind
>> of person who'll have a half-dozen terminal windows open to different
>> servers)
>
> Me, too. My screen is full of windows. If I'm not using it, it's not in
> front. End-of-story. Its size quickly becomes irrelelvant.
And that's the point--there are people, myself included, who work and IM in
parallel, and who want to have the information at their fingertips at all
times. The fact that the buddy window *does* get covered up is part of what
made me think about this in the first place, because it shouldn't be a
choice between working or having my IM information. It's an interruption to
my work to have to keep bringing Fire back to the front just to have the
information. And floating the buddy window would just take up too much
space. Hence...
>> I guess the point I'm trying to make is why not use a convention that has
>> already been established rather than trying to create a new one that requires
>> a user to dramatically change the way he uses his computer?
>
> Exactly. Fire should work better, not different.
And how can something be both better and the same? I mean, really now... =)
br
{#} ----------------------------------------------------+[ fire ]+---
