On Sat, Mar 12, 2005 at 04:01:09PM +1300, Jason G. Ellison wrote:
> >3)I think people do find themselves using multiple protocols. Most of
> >our users most likely do NOT have accounts on every protocol the way
> >we tend to. But I get LOTS of questions about "is there a way to sign
> >on a second account from the same instance of gaim" - people aren't
> >finding and understanding the account manager AS IT STANDS. and this
> >proposal complicates it. to me, you need to justify not only the
> >complication, but the continued existance of something that is
> >currently not being found.
> I don't think this proposal, as it stands, has any affect on the ability of
> people to find the account manager. As for people being able to understand
> it, that depends on how it's presented to first time users.
correct. it doesn't. and so I still want to entirely get rid of the
account editor. what does it do that the menu structure that was
proposed a few days ago can't do? except these account groups which I
think are overly complex for too little benifit.
> The current presentation of Gaim is a mess. Everyone acknowledges how
> AIM/mono account centric most of it is. In a lot of ways it's still
> pretending to be the type of client that you'd find in a Net Cafe, not a
> one user client.
right. so lets get rid of that first dialog entirely. lets start to a
blank buddy list and a new account dialog. if you have existing
accounts, then at least one will be enabled, and that one will sign
> If you want people to find and use the account manager then make it easy.
I'd rather remove it.
> As a suggestion,. the very first time that gaim is run 3 windows should
> open, the blank buddy list, on top of that is the accounts window, on top
here we are on the same page more or less, just the details of which
ui to go with differ.
> of that is the new/edit account window with the general tab in focus. That
> tab has the same basic options that every other client has when a user
> starts the client.
> After the new user has entered in that info the user goes to the accounts
> window, at the same time the buddy list is populated. The user is then
> visually presented with the location they need to go to for dealing with
> their account and their profile. Every single user will have been
> presented with and have used the account manager. With the rest of the the
> proposed changes, if anyone ever wants to do something with their account
> they go to the accounts window.
far too complicated. no one will figure it out.
> You can't expect people to be comfortable with something that they haven't
> seen before.
comfortable? perhaps not. But I *can* expect it to be intuitive. read
joelonsoftware's "User Interface Design for Programmers", its online
in the archives section.
your proposal is not intuitive.
> People working from home, people on their lunch break, people contract and
> move between roles as they please, people that are going to play b-ball
> after work and what to organise it with their friends. But groups can be
> used for more than that. People with more than one social groups. If I
> use an account or two for chatting with Bon Jovi fans, but I'm not in the
> mood to chat about JBJ then I don't want to have those accounts active, or
> at least in the same state as my other accounts.
as perl says, make the common case easy and the uncommon case
possible. you make both possible and both hard. A combination of the
account menu and Tim's improvements to sean's basic UI idea will make
the common case trivial and the hard case doable. add in the save item
that ethan suggested and I think we have every case possible, without
groups of accounts.
> >6)your girlfriend or friend logs on. it was utterly dismissed that
> >this sort of thing requires changes to more than accounts.
> Not sure if you read my other email, but I said that Account Groups are
> mean't to deal with this is any way. Using the same instance for this
> practice isn't the best practice, but it's the common practice and groups
> would help with that. I don't think any changes should be made in Gaim to
> deal with this. If all the things that you mention bother the user then
> they should be using seperate instances.
I did. and a solution that makes it *appear* that it should work,
while utterly failing to fix the biggest problems (ie the buddy list
is far bigger than just how do I do this), is worse than making it
look impossible. I argue a similar point at
right now its sorta in an inbetween state. with Sean/Tim's UI, it
*looks* like it will cause problems, and in fact still does (again, my
focus is on the buddy list). so the result matches the expectation.
> I expect to be blasted by you and the other Windows haters for this, but
> I'm going to present it anyway. I left a lot of the small stuff off of the
> mock-up and expected the discussion to tend towards those. On the accounts
> window I left it so there there was only one "add" button, as opposed to
> one for groups and one for accounts.
next time give us details, much like sean did when he put up
and as many of the other proposals have in the archives. :-)
> When the user clicks on the add button they could be presented with a
> window that has 2 options and an ok button. Those options being:
> o Group: Groups are use used for grouping accounts where you want them to
> share the same profile information and status.
> o Account: your actual protocol account that connects you to your buddies.
> And there you go, you've just informed your users.
as Joel says, and experience supporting gaim tells me, people don't
read. if you are lucky, they skim. if you aren't lucky, they guess.
our users mostly guess. that's why we are fairly safe hiding advanced
contact functionality in an unlabeled "expand" option in the right
click menu. Most people never find it and so are never confused by
it. those who ask about the functionality are easily pointed at it,
and easily understand it from there. plus it doesn't get confused
with "sub groups" which is good since it is meant to solve an ENTIRELY
> common. I decided not to go with that mock-up because it is more complex
> and would have received much criticism from the minimalists on this list.
of which sean is the foremost :-)
> I'm really happy that Tim wrote his "Status UI" email, that way I don't
> have to describe it all again, the only think I see as being different with
> groups is that there's isn't just a single "global" option, but one for
> each group. That leaves us with three states for the in buddy list status
> changer; 1 account, 1 group and multiple groups.
yeah, more complication for no benifit that Tim's doesn't already
> Now before you (the collective) complain that you don't want multiple
> selectors because it takes up too much room, remeber that if you only have
> 1 group, or 1 group enabled then you only have the one selector.
right. but because I'm concerned about just the opposite case, I'm
going to complain that you make exceptions more complex than Tim does.
> >my *guess* is that somewhere between 1/4th and 1/2 of gaim users are
> >on windows. they are certainly the higher maintence segment, and I'd
> >rather drop them than not.
> Does that include the 133k windows downloads from betanews.com and
no, it didn't. that most likely puts gaim fairly solidly around,
maybe a little short of, 1/2, as if I recall correctly, that more than
doubles the downloads.
> And maybe Windows users are the higher maintenance group because they have
> greater expectations of a user interface. How much of Adium's
> feedback/questions are from OSX users?
most of adium's users are filtered out by the adium guys before they
ever reach me. in fact I doubt I've ever heard from an adium user,
only adium developers.
> Yes, that's a loaded question. :-)
was it? I think it was a silly question. Adium uses libgaim well,
their users most likely don't know or care that gaim powers part of
their functionality. nor should they. if I DID hear from adium users,
I'd say they had done something wrong.
windows users expect more in an interface? perhaps that's why
microsoft has such sillyness as that wizard asking if you want a big
help database or a fast one. or perhaps its why you can't change the
margins in Word without looking at the paper size. or perhaps its why
you can't change the color of just some text in MSN. or perhaps its
why MSN messanger can't do as much as yahoo or aim. or maybe its why
they had to invent wizards in the first place to work around the fact
that no one could figure out how to use the GUI without them. There
are tons of other examples, but I think I can rest my case.
personally, I think they require more support because 1)having a
non-windows widget set is totally foriegn to them and 2)gtk on win32
isn't particularly stable. even those few that noticed that
mozilla doesn't look like the rest of their applications are
surprised that a bug they hit might not be a bug in gaim.
mmm. which sounds more reasonable to say? that they expect more, or
that gaim is totally different from anything they have ever seen
before? I think my explanation makes more sense.
now mac users? yes, they complain about ease of install and general
prettyness of the interface. and I HAPPILY point them at adium. and
most of them are pleased.
the end goal isn't to get everyone using gaim, if that were the case
we wouldn't be spending so much time implementing a split core and ui
and working towards a libgaim. rather, the end goal is to have people
using a client that DOES meet their needs. and that won't be the gaim
we distribute for everyone. some people will use a command line
client. some people will use one highly integrated wiht gnome but
still using gtk. some will use ours. some will use a qt ui. some
will use a native windows ui. some will use adium. there will probly
be others. diversity, to an extent, is a good thing. esp. if we can
provide a nice, solid backend for them all to use, so that each isn't
duplicating the hard and time consuming work of figuring out the