{#} Replies are directed back to [EMAIL PROTECTED]
{#} To reply to the author, write to Colter Reed <[EMAIL PROTECTED]>
Okay, I've slept on it. A couple thoughts.
On 2/5/02 22:00, "Ben Rister" <[EMAIL PROTECTED]> wrote:
> * How often do you need to reorganize your buddy lists? The tabs at the top
> are taking up space all the time. (This is true of most clients, not just
> Fire)
I should probably recuse myself from this part of the discussion, since my
usage pattern of Fire affects this more than most. What with testing adding
buddies, blocking buddies, importing contact lists, etc., I'm in the setup
quite frequently.
> * What's the "Online" bar for in the window, from the user's point of view?
> (I know why it's there programmatically =))
Guess it doesn't bother me that much. I only just now noticed that. (I
think it can be gotten rid of rather easily.)
> * (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.
> * (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?
> * Anybody else find Cmd-Shft-I somewhat excessive?
Nope. I had to look in the menus to find what it did.
> * 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.
> * 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.
(BTW, *very* good sales-pitch tone. :) )
> * 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.
> 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.
> * 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.
> * All common actions take 1 click
They do now, with a modifier key.
> * 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.
> * 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.
> * 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... ;)
> * 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.
On 2/5/02 22:00, "Jonathan Baumgartner" <[EMAIL PROTECTED]> wrote:
> I can't quite tell in your mock-up, because the image is shrunk, but it
> looks like even with only a few buddies, the bar extends across the entire
> width of the screen. I would prefer it be more like the Control Strip from
> OS 9, where it extends only to the width it needs. And maybe a minimize
> widget that would shrink it to either completely hidden except for a
> maximize widget, or a "use the smallest amount of real estate while still
> displaying minimal information" state, with maybe icons indicating the
> number of online buddies per service (like Mail's icon.)
I was thinking this myself as I was pondering the BuddyBar.
> What if you made an option where it could function like the Dock, with the
> tooltip concept? That way you could have a very thin BuddyBar only
> displaying icons going down the left or right hand side, and a mouse-over
> would show the buddy's name. That would conserve space too, even if you've
> got it on the bottom.
I don't think this is a good idea. Without buddy names, you're not getting
nearly enough information for the real estate you're taking up. Just stick
the buddy window off the edge of the screen.
> 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.
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.
> It's a good idea, though, Ben, but the only major problem I see with it is the
> fact that the dock would need to be on the left or right. I don't think that's
> an acceptable solution. Why not make a little black icon that would appear in
> the right side of the menubar next to the time? Right now, I have icons for
> PPPoE, Displays, Sound volume, Batter level and percentage and a little analog
> clock. There's more than enough space for another one for Fire with and a
> drop-down menu with your active buddies, preferences, buddy management, online
> stats, etc.
Well, if you do that menu the official way, it requires a separate app,
Fire.menu, that loads and runs independent of Fire.app. Not a bad idea, but
it would be a little difficult for them to communicate with each other right
now.
JabberFox and Proteus place their menu items by hacking a private API.
Private APIs change and break easily -- Apple has zero hesitation to rework
something since it's 100% "behind the scenes" and they're the only people
using that API, right? Eric's already had to rework some code in Fire to
maintain compatibility with the next point-release of OS X, and I, for
another, don't want to have to spend time with each system upgrade figuring
out how the new private APIs work.
Besides, what's the advantage of adding a menu item when you've already got
the Dock menu to work with? (Aside from the fact that a menu item might be
easier to use because it doesn't move around on you like your dock probably
does, what with the resizing and the hiding and all.)
> 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.
> PS: I didn't get an answer on my Yahoo question.
42
> :)
I checked, and I'm not getting that error. Are you using TOT? (Why does
everyone assume that if we don't answer, we're not paying attention?)
--
Colter Reed
AIM/MSN/Yahoo: Sanguerent ICQ: 113022030
{#} ----------------------------------------------------+[ fire ]+---
