{#} Replies are directed back to [EMAIL PROTECTED]
{#} To reply to the author, write to Joel Richard <[EMAIL PROTECTED]>
Hi folks,
I found a very simple, easy-to-code solution to the buddy list taking up too
much space. I minimize the window when I'm not using it. Amazing, eh? :)
Sarcasm aside, I started doing that because AIM's window has those godawful
blinking ads which are a complete distraction to my work, so I kept the window
minimized when I didn't need it. Fire solves all that because it has no ads.
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)
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.
I guess the point I'm trying to make is why not use a convention that has
already been established rahter than trying to create a new one that requires a
user to dramatically change the way he uses his computer?
Just my three cents. (this was more than two cents of typing. ;)
--Joel
PS: I didn't get an answer on my Yahoo question. Does no one use yahoo here? :)
Ben Rister wrote:
>
> {#} Replies are directed back to [EMAIL PROTECTED]
> {#} To reply to the author, write to Ben Rister <[EMAIL PROTECTED]>
>
> >From try 3: (OK, this is getting ridiculous. I'm assuming that the fire
> list server is trashing my stuff because there's an attachment, so here it
> is without the attachment.)
>
> >From try 2: (At the risk of defying fate when the first one met an ill end,
> here's a resend of what I sent yesterday. Let's hope it's not an omen. =))
>
> And try 1:
>
> Good evening, everybody.
>
> The Fire interface has undergone a lot of changes recently in the chat
> windows, most notably in the migration to the toolbar approach. However, my
> proposal is a somewhat more radical change to the interface, in particular
> as a substitute for the buddy list. As it stands now, the buddy list is a
> great waste of screen space, and there's some interface problems with it as
> well:
>
> * 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)
> * What's the "Online" bar for in the window, from the user's point of view?
> (I know why it's there programmatically =))
> * (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)
> * (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.)
> * Anybody else find Cmd-Shft-I somewhat excessive?
>
> Additionally, there are things about IM that are not being exploited well:
>
> * 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.)
> * What's the most frequent action performed on buddies, by far? Sending a
> message. Why do we have to double-click to do that?
> * Second most frequent? Getting information. As mentioned above, this
> could be much easier.
>
> Ladies and gentlemen, I present to you the Fire BuddyBar(tm).
>
> 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.
>
> On the left side, you have the buddy area. This contains the list of
> buddies in your working set (as specified in their user information) that
> are online. Clicking on the buddy opens an IM to them (or shows the window
> already open). Each buddy has a little icon next to them that shows their
> service and status (along with name dimming as usual, etc.). Clicking on
> the service/status icon brings up their info window (profile, etc.).
> Contextual menus provide the usual functions one would expect. The final
> item in the buddy area is a small indicator showing how many other buddies
> are online, and clicking on it brings up the normal buddy list for times
> when you need somebody outside of your working set.
>
> The buddy area of the bar grows as large as the other items permit, and all
> other items would be able to be added and removed by the user. Directly to
> the right of the buddy area, indicators similar to the current dock icon
> ones would (optionally) be present, indicating the status of each service.
> Clicking on them allows you to connect/disconnect/etc. from the service. To
> the right of that, your current status would (optionally) be displayed
> (Available/etc.) and could likewise be changed.
>
> Pros:
> * Screen real estate of buddy list reduced to essentially zero in normal
> case, without loss of features commonly used
> * All common actions take 1 click
> * Service status information more visible (on a cleaner background than the
> dock icon), control easier
> * Less duplicates between the same buddy on different services--just put the
> "preferred" one in the bar.
>
> Cons (with brief discussion):
> * 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.
> * Pointless if there are too many buddies in your working set online at the
> same time. However, the survey justified my intuition that this would not
> be a problem for most people if running at 1024x768 or higher. Roughly 15
> or so buddies with normal-sized names can fit on 1024 with both optional
> areas turned on. As this is about as many as most people have as their
> *total* working set, the number online should easily fit.
> * 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.
> * I have to implement it!
>
> The BuddyBar wouldn't replace the buddy list, but simply serve as an
> additional feature working in conjunction with it. The BuddyBar follows the
> eternal CS maxim of optimizing the common case--for most people in most
> cases, it would function much better than the current way of doing things,
> and there would be a graceful fallback to the buddy list for the cases it
> can't handle.
>
> So. That's my harebrained idea. You can see a mockup (of dubious quality)
> of what it might look like when implemented attached to this email
> (revision: it's now at http://homepage.mac.com/decimus/mockup.jpg). I just
> realized I forgot to put the indicator for "everybody else" in the mockup,
> but hey. You get the idea.
>
> If this sounds like something that many people would like, then I'll start
> working on it, and a while down the line we'll have a great new feature that
> puts Fire above everything else in another way. If not, well, then we can
> all just keep using the buddy list all the time. I have a TiBook, I guess I
> can spare a couple inches on the side. =)
>
> I heartily encourage comments and suggestions, either back to the list or to
> me personally, and if it is going to become a reality it'll be good to make
> sure we know all the issues and questions up-front. So drop me a line, and
> we'll see what we can do.
>
> Best regards,
> br
>
> --
> Ben Rister
> [EMAIL PROTECTED]
>
> The last good thing written in C was Franz Schubert's Ninth Symphony.
> -- Christa Ptatschek
>
> {#} ----------------------------------------------------+[ fire ]+---
{#} ----------------------------------------------------+[ fire ]+---
