{#} Replies are directed back to [EMAIL PROTECTED]
{#} To reply to the author, write to Brad Watson <[EMAIL PROTECTED]>
well, feedback can be a foul temptress sometimes. Wielding the hand of
judgment for good and bad, like judge judy after polishing off an entire
box of ring-dings. I personally don't like the idea. Mostly for my own
reasons, some others that have been discussed here & even more reasons
that I haven't put my finger on yet. In all honesty, it feels like a
windows deivice. I know a lot of mac programs have their own dock-like
menu bar as well, but I think the same of those too and try to stay away
from them whenever I can. Sometimes lately it seems that modern mac apps
have all come from the windows platform & have simply been "made to
work" on the mac. I think that one of the biggest attractors that draws
me to programs like Fire, Omniweb, Watson... etc are that these are
created with only the mac in mind & don't share philosophies found in
other less intuitive operating systems.... However, if it's any
consolation I've got a buddy who only recently switched from a windows
background to OSX who I showed the mockup & he loved it. It stirred a
debate of UI design that lasted us way into the wee hours of the morning.
Brad
On Tuesday, February 5, 2002, at 06:38 PM, 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 ]+---
