Re: [Gaim-devel] Account Group Mock-Up

[Jason G. E. <jge...@ho...>]

> 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 benefit.

You could still have Account Groups in a menu structure.  But, a menu 
structure is an excessively limited way to do things.  Why not do away with 
the Preferences window and make that a menu tree?  I don't think you'd find 
any UI "guru" who would advocate the sort of change you're proposing.

>> 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.

No one will figure out that there are two windows; one with the account that 
they just created, has a close button, and is labelled "Accounts"; and 
another that looks similar to every other buddy list ever created?  They can 
see the effect of their actions as they happen.  What better way to create a 
mental bond?


>> 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.

In what way is it 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.

How have I made 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.

My mock-up does not contradict with Tim/Sean's UI.

> add in the save item
> that ethan suggested and I think we have every case possible, without
> groups of accounts.

Except that the major difference between the OSX print screen and dealing 
with people's accounts is that the print screen is a fixed scope, there are 
and will only every be 12(?) items on that screen.  That isn't not the case 
with the fluid nature of account creation/deletion.  I like the idea of 
'saved item' but it is going to be a massively complex beast when/if it's 
implemented.  Account Groups gives a similar result without the 
complication.

>> >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
> gaim.sf.net/plaintextpasswords.php

But it doesn't make it appear to work.  You access buddy logs from the buddy 
list, not from the Account list.  Buddies aren't grouped by account or 
Account Group.  There is no extra connection there.  All the issues that 
people have now they would have with my mock-up and they would have with the 
drop-down menu mock-up.

> next time give us details, much like sean did when he put up
> http://gaim.sourceforge.net/sean/status.php
> and as many of the other proposals have in the archives.  :-)

Sean's concept was less of a drastic change from what people are used to. 
My mock-up was to get people used to the idea.  Details haven't been 
required until now and they aren't being used in a manner that promotes the 
understanding of the mock-up, so I feel very justified in not having spent 
time on the "could be done 50 ways" details.

>> 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.

And you've just stated the case for having "account" being the sane default 
on that menu so that users that don't read will constantly make new account 
under the default one group.  No added confusion.

>> 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 :-)

Agreed.  I'm having this discussion with the two most difficult people 
possible.  One thinks that users only have one account and the other wants 
nothing more than to get rid of the Accounts window.  If you don't hear from 
me for a while it's because you've succeeded in frustrating me to the point 
of giving up.  :-)


>> 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
> give.
> <snip>
> 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.

Where's the complication?  You don't see anything different unless you've 
specifically asked to have more than one group.  With Tim's proposal you're 
already in the situation of having multiple line items if one of the 
accounts is out of sync.  There's less complication because you can change 
the status of mentally grouped accounts all at once.


>> 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?
> <massive snip because I really don't care>

I was referring to Adium devs getting feedback, not Gaim devs.  It's 
generally accepted that the order of UI grace is Linux, Windows, OSX.  Yahoo 
and AIM are both windows applications.  Winamp, Mozilla, WMP, etc have 
non-standard GUI.  I agree that users will blame the application (Gaim) 
before the support layer (GTK), and that should be expected since the 
application is obvious and the support layer isn't.

> the end goal isn't to get everyone using gaim

Never said it was.  I'm looking forward to the day when libgaim is done, but 
that doesn't mean that Gaim shouldn't support users because of imaginary 
complication.

Jason