From: Jason G. E. <jge...@ho...> - 2005-03-09 02:24:41
|
Hey Guys, I thought I would join in on the whole mock-up thing and submit some changes I think would be good for Gaim. These changes affect grouping of accounts, global statuses and non-buddy list status changing. http://geocities.com/jgepublic/mock-up/ I threw this together yesterday and did some quick spell check today, it's rough but should get the point across. I look forward to the discussion. Jason |
From: Sean E. <sea...@bi...> - 2005-03-09 17:19:47
|
On Wed, 2005-03-09 at 15:24 +1300, Jason G. Ellison wrote: > I threw this together yesterday and did some quick spell check today, it's > rough but should get the point across. I look forward to the discussion. Hey, Jason! The current design about status and accounts and stuff aims for simple elegance in both UI and functionality. You're aware of this. I'm a huge fan of the concept that "these are all the accounts I use, but there's only one of me. I'm I'm actually away, or idle, or on the phone, then all my accounts should show that" and so I'm not a huge fan of this account group idea. As you state, the same thing can be accomplished with multiple instances of Gaim (with the appropriate -c flags set), and I think that would actually provide a more comfortable experience all around: not only is it easier to understand that a Gaim instance represents a single person rather than an amalgamation of sets of aggregated accounts (amalgamate and aggregate are fun words), but the UI for using it would also be simpler. Your UI, which is obviously just a mockup to present your ideas, nothing you intended to be set in stone, also seems more complicated than it is currently. It has some good ideas in it (I like showing the buddy icon in the account list, for instance, but overall it feels very Windowsy and I'm not sure why. I think it's because the dialogs look like they use explicit positioning a la Windows resource files. Anyway, I'm not convinced that the confusion added by the notion of account grouping isn't outweighed by its benefits, especially when the same effect can be accomplished (better, I think) by multiple instances of Gaim. I am concerned that my idea may be too limiting for a lot of people, however, and I'm glad to see so many people coming up with ideas. I'm sure that with the feedback these designs generate, we'll be able to find the best compromise between "power" and simplicity. Does anyone else have any opinions about Jason's mockups? -s. |
From: Luke S. <lsc...@us...> - 2005-03-09 18:16:04
|
On Wed, Mar 09, 2005 at 12:20:29PM -0500, Sean Egan wrote: > On Wed, 2005-03-09 at 15:24 +1300, Jason G. Ellison wrote: > > Anyway, I'm not convinced that the confusion added by the notion of > account grouping isn't outweighed by its benefits, especially when the > same effect can be accomplished (better, I think) by multiple instances > of Gaim. I am concerned that my idea may be too limiting for a lot of > people, however, and I'm glad to see so many people coming up with > ideas. I'm sure that with the feedback these designs generate, we'll be > able to find the best compromise between "power" and simplicity. > > Does anyone else have any opinions about Jason's mockups? > > -s. I think that about sums it up for me. It is a ton of added confusion, for very little gain. Plus, his idea that "these are accounts I don't use very often" can be grouped together is rather flawed. under his model, if I have 5 accounts I use for testing, I would have to set up 5 groups each of one account, or else only use all 5 at once. (or worse, manipulate groups on the fly just to test something). For users who actually do let friends use their gaim without -c, your group structuring would again require that each account be in its own group, or that numbers of accounts go online that you did not intend to. I can just imagine explaining to a friend "oh yeah, you can sign on, but first you have to move your account out of that group over there into a new one." this might be of some benifit to users with "work" and "home" profiles, but I think that most of these users will in fact be using gaim from different locations, and thus have an implied -c in place. They can set one when they leave for work, unset the other when they get there. and vice versa on the way home. people with "work" and "home" screennames that they use at one location should be a much smaller number of people, and can either use -c, or can set up complex states with the current ui. note that here, pushing -c or complex states, we make the *odd* case complex, not the *average* case. on average, I think sean will turn out to be mostly right, that whatever accounts are "enabled" in a single instance of gaim really do most commonly represent a single person. It isn't only gaim's status that implies this view, but also its buddy list, its logging system, and its global preferences. all of this would have to be split to account for "groups of accounts," and some things, particularly the logs, would have trouble migrating between "groups of accounts." if for instance you wanted to move some account as per above (ie to sign on just one account). luke |
From: Jason G. E. <jge...@ho...> - 2005-03-10 00:45:29
|
Sean, Luke, thanks for replying to my message. I'll cover both your messages in this reply. Short version: In its rawest form Account Groups is a way of setting status, nick and icon for more than one account at a time; and nothing more*. The groups don't represent a single person, they represent a "role"ish-type-thing of a single person. Gaim Instance = Person Account Group = a Role *until more settings can work cross protocol Verbose: Multiple Instances (-c flag): With the -c flag you have completely separate Gaim configurations. As I mentioned in the mock-up under the account privacy tab, contacts can have buddies that are in different accounts across different account groups. If you're using -c then you don't have that combined list of buddies and you'll have to duplicate the overlap across instances. In addition if you want to see if a contact is available you'll have to check every instance that they might be in. And how do you know which tray icon represents which instance? If, for example, there's someone that you don't mind talking to in and out of business hours then you're life is going to be hell. Buddy grouping and account grouping are completely separate things. Buddies are grouped into contacts which are grouped into "groups." Buddy grouping is shown on the Buddy list. Accounts are grouped into account groups (in this mock-up and in users heads), which is shown in the Accounts list. I explain this here because I don't want Account Groups to be confused with the Buddy List Grouping mock-up from a short while ago. (online and offline groups) I don't think Account Groups should affect the list of contacts at all. Sean, you say that having multiple windows of overlapping contacts would provide a more comfortable experience overall, I hope the above explains why I think otherwise. An aside about contact buddy stack ordering... As well as showing buddies that are most available (available, then idle, then away) first the order should also be determined by the availability of the account the buddy is on. If two buddies in one contact are both available, but one of your accounts is away, then the available buddy on the available account should be at the top. I'm not sure if Gaim is currently doing this. The UI feels Windowsy... Yep, it probably does. I use windows (as do 80% of the people that download Gaim from Sourceforge) and made the mock-up in that environment. The mock-up was made using PaintShopPro, not using a gui creation tool, hence everything looks slightly off. I didn't want to spend heaps of time making everything look perfect, since it's a rough mock-up and not a design guide. A lot of stuff was just quick cut and paste. So, as you state, use this to get an idea for what I'm trying to express, but in no way consider it the final form or even what I would like for the final form. "these are accounts I don't use very often" can be grouped together is rather flawed.... Indeed it is, and in no way my intention. I meant for the last group to represent a single role that wasn't used daily. I should have done that differently. You (Luke) are correct in stating that each rarely used single role account would have its own group. So there is no need to explain about moving accounts around groups, etc. But I guess a power user could create 2 groups, the bottom one with all rarely used single role accounts and just move those into the empty group above when they wanted to use it, thereby lowering the total number of groups. The only problem with that is nick and buddy icon, tho. People with different roles will use Gaim from different locations... The first thing that comes to mind is laptops. The next thing is that a lot of work has and is being put into making Gaim work from USB memory sticks, portable drives, etc and across the win/lin boundary. Location is no longer a barrier from sharing config files. Hopefully this statement isn't too much of a concern anyway with the explanations that I've given above. > on average, I think sean will turn out to be mostly right, that > whatever accounts are "enabled" in a single instance of gaim really do > most commonly represent a single person. It isn't only gaim's status > that implies this view, but also its buddy list, its logging system, > and its global preferences. all of this would have to be split to > account for "groups of accounts," and some things, particularly the > logs, would have trouble migrating between "groups of accounts." if > for instance you wanted to move some account as per above (ie to sign > on just one account). I hope this is clarified by the above, but just in case... No changes would need to be done to buddy list, the logging system or the global preferences. This doesn't change buddies in any way, it allows people to act on accounts based on how they view their accounts. Both of you stated that all-accounts-are-representative-of-one-role is how you do business. (Sean by saying so, and Luke by saying it's the common case) Then Account Groups makes your life easier, because instead of setting things multiple times, once for each account, you only need to do it once. Your buddy-list-embedded-status-changer will not be filled with hordes of accounts, instead you'll have a clean single group. Is not 1 item more easily managed than 10? So Luke, in both cases (odd and average cases) using Gaim becomes simpler. As an aside, serious question, how do we know which is the odd and which is the average case? Hopefully this wasn't too verbose, it's just that I have put a lot of thought into this and want to make sure I'm not leaving stuff out. And yes, I can be even more verbose, so please question anything and everything. Luke, Sean, thanks again for responding. Jason |
From: Sean E. <sea...@bi...> - 2005-03-10 05:16:36
|
On Thu, 2005-03-10 at 13:45 +1300, Jason G. Ellison wrote: > In its rawest form Account Groups is a way of setting status, nick and icon > for more than one account at a time; and nothing more*. The groups don't > represent a single person, they represent a "role"ish-type-thing of a > single person. > > Gaim Instance = Person > Account Group = a Role You're strongly emphasizing that second usage case you outlined: people who have entirely different sets of accounts for different contexts. Personally, I think that is certainly the rarest of your three use cases by far. I think the most common use case is still just a single account. For that case, your idea is far too complicated as multiple groups of multiple accounts makes little sense for someone with a single account. Even if I'm mistaken and tons of people have one set of "work" accounts and another set of "family" accounts and a third set of "friends" accounts, they're still all owned by the same person. And a real-life person is still only "here" or "not here." The only real legitimate reason to keep them as separate as you want is to lie or deceive: to keep your boss from knowing that you're doing recreational drugs while inviting your friends to join you. > Sean, you say that having multiple windows of overlapping contacts would > provide a more comfortable experience overall, I hope the above explains why > I think otherwise. Yeah, you have some good points. I suppose what I meant was that assuming that the Gaim UI represents a single person with a single state regardless of role or context allows us to do certain Good Things (such as global status on the buddy list) which are not permissible if we don't allow that assumption. > The UI feels Windowsy... > > Yep, it probably does. I use windows (as do 80% of the people that download > Gaim from Sourceforge) and made the mock-up in that environment. That was more of just a comment than a critique. I didn't assume you expected the UI to come out looking exactly like that. After further thought I think it's because all your UI elements are centered whereas Gaim is left-aligned. Not to mention you use stuff like frames which Gaim no longer uses. Again, it's nothing that couldn't be HIGified. Just a comment. Also, please note that we do not currently provide packages for most of the popular Linux distributions (Fedora, Debian, Gentoo, Ubuntu) or any other UNIX-like operating system. Sourceforge downloads are not an accurate representation of Gaim's usage. |
From: Jason G. E. <jge...@ho...> - 2005-03-10 06:33:48
|
Sean, >> In its rawest form Account Groups is a way of setting status, nick and >> icon >> for more than one account at a time; and nothing more*. The groups don't >> represent a single person, they represent a "role"ish-type-thing of a >> single person. >> >> Gaim Instance = Person >> Account Group = a Role > > You're strongly emphasizing that second usage case you outlined: people > who have entirely different sets of accounts for different contexts. I don't believe this to be the case. I believe I'm focusing on everything except "a girlfriends (or other friends) account." I hadn't expected those 6 words to get such heavy focus.* > I think the most common use case is still just a single account. > For that case, your idea is far too complicated as multiple groups of > multiple accounts makes little sense for someone with a single account. For someone who wants all their accounts unified it's the simplest of cases. http://www.geocities.com/jgepublic/mock-up/accounts-singlepurpose.png I can't see how that can be considered more complicated then the currently in-use account window. > The only real legitimate > reason to keep them as separate as you want is to lie or deceive: to > keep your boss from knowing that you're doing recreational drugs while > inviting your friends to join you. Just because you are physically located at your computer doesn't mean that you want to chat to everyone in the world. There may be a subset of the world that you are happy to chat with, but can't be bothered with the rest of the population. I can't be the only one who thinks this way. The fact that there has been discussion of complicated multi-status global-status settings and enabling the ability to set yourself invisible to only certain buddies suggests that I'm not alone. Is everyone who supports these features drug taking devil-worshipping liars? Grouping accounts just allows you to eliminate people in much less tedious manner. > Again, it's nothing that couldn't be HIGified. Just a comment. That's how I took it, but the verbose response on my part was probably overkill. > Also, please note that we do not currently provide packages for most of > the popular Linux distributions (Fedora, Debian, Gentoo, Ubuntu) or any > other UNIX-like operating system. Sourceforge downloads are not an > accurate representation of Gaim's usage. Agreed. But I don't know of any way of getting an accurate representation of actual Gaim usage. The point wasn't to say that Windows is bigger than Linux (tho who knows), but rather to remind people that 80% of 250,000 isn't a small number. * The reason I put those 6 words in the document is because I believe it would be common practice to simply add another account to the account list when a friend just quickly wants to send a message or see if someone is online. The thinking being "my friend wants to add his account, so I'll add an account." Instead of "my friend wants to add an account, so I'll run another instance of gaim with the -c flag (which I've never seen before) and then add the account to that." I don't think the common practice is the best practice. Grouping accounts allows you to deal with that usage case easily. Jason |
From: Sean E. <sea...@bi...> - 2005-03-10 07:38:05
|
On Thu, 2005-03-10 at 19:33 +1300, Jason G. Ellison wrote: > I don't believe this to be the case. I believe I'm focusing on everything > except "a girlfriends (or other friends) account." I hadn't expected those > 6 words to get such heavy focus.* Considering that your recommended changes are entirely unnecessary for all but that second case, I stand by my claim that you're over-emphasizing it. > > I think the most common use case is still just a single account. > > For that case, your idea is far too complicated as multiple groups of > > multiple accounts makes little sense for someone with a single account. > > For someone who wants all their accounts unified it's the simplest of cases. Unless that person has only one account (which I suspect is still the most commnon use case, but I'm likely wrong), in which case "unifying all their accounts," is merely "just let me sign-on AIM and don't ask me about 'account groups.' I'm already worried about the backlash we'll see from people moving away from the "Login" window (very single-account specific). > http://www.geocities.com/jgepublic/mock-up/accounts-singlepurpose.png > > I can't see how that can be considered more complicated then the currently > in-use account window. Both are unnecessarily complicated, but for different reasons. What makes your proposed idea *more* complicated is that it adds another layer between me and what I want to do. I'd like to say "these are my accounts. Make things work." You want to say "These are the accounts I use for work," "these are the accounts I use for school," "these are the accounts I use for drug-taking, devil worshipping, and lying." There's nothing fundamentally flawed about that idea, I just happen to think it's less common than the "I only use one IM service and have a single screenname" or "I chat mostly on AIM, but I have a Canadian friend on MSN, so I have to use that too" notions. I won't sacrifice ease of use for the most common case for ease of use for the less common case, especially when I fall under "most common case." > Just because you are physically located at your computer doesn't mean that > you want to chat to everyone in the world. There may be a subset of the > world that you are happy to chat with, but can't be bothered with the rest > of the population. I'd say this is more the function of privacy than account management. I don't think having multiple accounts is the best way to segment your friends into groups much less a common way. > I can't be the only one who thinks this way. The fact that there has been > discussion of complicated multi-status global-status settings and enabling > the ability to set yourself invisible to only certain buddies suggests that > I'm not alone. The latter actually *is* a function of privacy. I think the former comes mostly from people who don't want to be limited by a global status's need to abstract a large array of protocol-specific status settings into a few global concepts that can be understood by all protocols. These are people who want to go invisible, but would be otherwise limited by IRC's inability to do so, for instance. Perhaps they want to make a phone call, but AIM doesn't have a specific "On the phone" status like MSN does. I'm sure a few people do actually want to avoid certain people sometimes by pretending not to be there; this is another uncommon case that can't be given higher precedence than more common cases. > Is everyone who supports these features drug taking > devil-worshipping liars? Yes, most likely. I'm not positive about that, though. I won't go so far as to claim that I know what every Gaim user wants, or even that I know what most Gaim users want. I *think* I know what most Gaim users want, but my perception is skewered. So is all of ours; that we're subscribed to the developers list of a multi-protocol IM client indicates that we have slightly different expectations from an IM client than most. My perceptions are probably skewed ther furthest. I'm IMed by dozens of people each day who can't figure out how to use Gaim as it is. This keeps me from thinking that people really want a greater number of unfamiliar concepts separating them from their friends. I hardly ever use the buddy list, privacy, statuses, file transfer, or pretty much anything. I pretty much use Gaim solely to receive messages. I'm far from an "average" user. However, I happen to be the person ultimately responsible for direction, and until someone else manages to convince me I'm wrong (which will admittedly be hard, especially from someone who isn't a core developer whose opinions I already have huge respect for, although I'm receptive to ideas from anyone) I intend to continue the current route. -s. |
From: Jason G. E. <jge...@ho...> - 2005-03-12 02:55:35
|
>> In its rawest form Account Groups is a way of setting status, nick and >> icon for more than one account at a time, >> .... >> I don't believe this to be the case. I believe I'm focusing on >> everything >> except "a girlfriends (or other friends) account." I hadn't expected >> those >> 6 words to get such heavy focus.* > > Considering that your recommended changes are entirely unnecessary for > all but that second case, I stand by my claim that you're > over-emphasizing it. I claim that you are over-emphasizing status changes in my Account Group mock-up. :-) If most people only have one role that still means that they get the benefit of only having to change their nick and icon in one place. >> For someone who wants all their accounts unified it's the simplest of >> cases. > > Unless that person has only one account (which I suspect is still the > most commnon use case, but I'm likely wrong), in which case "unifying > all their accounts," is merely "just let me sign-on AIM and don't ask me > about 'account groups.' I'm already worried about the backlash we'll see > from people moving away from the "Login" window (very single-account > specific). I've been following Gaim development for about 6 months, and you have a nack for getting people to go on rants or give up. (And that's possibly why you are the lead.) I'm going to avoid the rant about Gaim being super-bloatware if it's intended audience is someone with a single account, and I'm going to avoid the rant about not adding new features that could benefit users while not inconveniencing the rest, and I am going to try and not give up, yet... The above quote relates to Luke's #3, am I'm going to respond to that a bit more in-depth. >> http://www.geocities.com/jgepublic/mock-up/accounts-singlepurpose.png >> >> I can't see how that can be considered more complicated then the >> currently >> in-use account window. > > Both are unnecessarily complicated, but for different reasons. What > makes your proposed idea *more* complicated is that it adds another > layer between me and what I want to do. I would assume that what most IM Client users wish to do is to chat to people and managing accounts isn't a part of that activity. Dealing with the actual accounts is something that should really only be done once. Account Groups separates protocol accounts from profiles. Since you've admitted that you don't even use the buddy list, then you're probably not personally aware of the huge portion of the MSN userbase that change their 'Friendly Name' more often than I change undies. It's a huge part of the culture on the MSN network and profile access is super important to these people. I don't know of any culture on any protocol where you get cool points for changing your server port. This mock-up separates the two into the frequently and infrequently used components. And since this mock-up represents 2 menu trees, one menu item and the current Accounts window and puts them into a visually connected pair in a single window it could be said that it removes unrequired abstraction and greatly increases affordance. > I'd like to say "these are my accounts. Make things work." You want to > say "These are the accounts I use for work," "these are the accounts I > use for school," "these are the accounts I use for drug-taking, devil > worshipping, and lying." And some people will put their buddies into similar groups and some don't group at all. >> Just because you are physically located at your computer doesn't mean >> that >> you want to chat to everyone in the world. There may be a subset of the >> world that you are happy to chat with, but can't be bothered with the >> rest >> of the population. > > I'd say this is more the function of privacy than account management. Setting status, permit/deny buddy list addition, blocking and even giving out your username are all a form of privacy, why can't grouping of accounts be? > These are people who want to go invisible, but would be otherwise > limited by IRC's inability to do so, for instance. Perhaps they want to > make a phone call, but AIM doesn't have a specific "On the phone" status > like MSN does. I'm sure a few people do actually want to avoid certain > people sometimes by pretending not to be there; this is another uncommon > case that can't be given higher precedence than more common cases. Completely off topic... This can be hardcoded by the devs. There's been mention of being able to set different accounts to completely different statuses through personalisation with "one click" technology. These are the unconfirmed drugged out, devil-worshipping, llama beating liars I was referring to... Jason |
From: Luke S. <lsc...@us...> - 2005-03-10 15:02:28
|
On Thu, Mar 10, 2005 at 12:17:04AM -0500, Sean Egan wrote: > On Thu, 2005-03-10 at 13:45 +1300, Jason G. Ellison wrote: > Even if I'm mistaken and tons of people have one set of "work" accounts > and another set of "family" accounts and a third set of "friends" > accounts, they're still all owned by the same person. And a real-life > person is still only "here" or "not here." The only real legitimate > reason to keep them as separate as you want is to lie or deceive: to > keep your boss from knowing that you're doing recreational drugs while > inviting your friends to join you. I mostly disagree here. 1)I think at this point many people are still using one set of accounts at home and at work. I think this is why aim introduced the ability to sign on multiple places at once. I think its why jabber has always had it. 2)I think that many people ARE in fact using multiple accounts. I think that is why aim introduced linked screennames. Talking of people I know who do NOT use gaim, some of my female friends change screenname every time they break up (not often, but still adds up over the course of time). Sometimes they'll go back to an older one when they are looking for someone who doesn't appear online. My brothers have looked at changing screennames as they have graduated highschool and entered college. The name that made sense to a freshman or sophmore in highschool isn't always the same that you want to go by in college, and aim's linked screennames lets you make that transition in a way that wasn't possible before. our interface should allow the same. I think we do right now, you can auto sign on both, but we all know that status needs to be better. 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 think that anyone installing gaim is going to be *relatively* more clueful, thus they will find themselves being the one who has to adjust to friends on multiple protocols, getting someone to change protocols isn't easy, and I'm not sure I buy sean's theory of regionalized protocols. Sure the *dominent* protocol changes by region, but I think many more than just the dominent one is still used in any give area. 4)I, unlike sean, am concerned with privacy. I do use my buddy list quite a bit, gaim for me is two way, I start some conversations, many are started with me. The buddy list is crucial. But so is control over who we talk to. Again looking at my brothers, a real conversation: Mom: I don't want you talking to that person. Brother: I'm not, see it popus up this little do you want to talk with x dialog and I close it. Mom: why don't you just block the person? Brother: that would be rude. this sort of senario, which I have heard from other places as well, says we need to do more to control what windows pop up on the users' screens. letting them get at invisible and block more easily will help. but blocking isn't sufficient, and so our current model breaks down, we should support the extended options of protocols where they exist, we currently don't do even a decent job of this. 5)people who do use multiple sets of accounts, which is something I do, with one set for my own friends, one set that used to be my main accounts, but became nearly entirely gaim after some unpleasentness, and a 3rd set for work. But I am *never* online at the same computer with the work accounts as with the others (except silc where I haven't set up a second account). Why would you be on your "home" accounts from work? do you think that many gaim users work at home? 6)your girlfriend or friend logs on. it was utterly dismissed that this sort of thing requires changes to more than accounts. I'll refute that. I get consistent complaints that "My girlfriend logged in and now I have all her groups. And I can't remove them becuase there are buddies in an account not signed on. (hers)" that means the buddy list has to change to support this well. now consider logging. you enable global logging, it useful to many of us. now your girfriend signs on. and her conversations with random people are logged *on your computer* and *in the same place as your logs*. do you think this is good? ideal? I don't. I think we can solve these problems better than account groups. I don't think ANYONE will understand intuitively what an account group is, or how they create one, or why they should. It'll have to be explained to them, just like the contact support has to be explained to many users. this is especially true if accounts are added to a group by default, if accounts are added to the only existing group by default. and if we do NOT do that, then we'll have the same issues with "How do I sign on two accounts at once" that we have now. > > Sean, you say that having multiple windows of overlapping contacts would > > provide a more comfortable experience overall, I hope the above explains why > > I think otherwise. I don't think it is ideal. I think it is better than leaving half the confusion (the buddy list) and 2/3rds of the mixing (buddy list and logs both) in place, which is what you do. > > Yeah, you have some good points. I suppose what I meant was that > assuming that the Gaim UI represents a single person with a single state > regardless of role or context allows us to do certain Good Things (such > as global status on the buddy list) which are not permissible if we > don't allow that assumption. again looking at friends who use linked accounts, I the most common case is a single away message, but *at times* any given friend will set different away messages on each account. accounts that they are certainly using together. Our ui should allow this, normal users who never even think twice about other clients use this ability, ours will also. since they always use the accounts together, and most of the time with a single state, the ui should make that the easy default case. but it shouldn't require going to tools, selecting accounts, opening an account group (which may or may not be expanded by default, feel free to disreguard this step), dragging an account from one group to another. and then and only then setting its state. that's far too many steps for such a simple operation. Sean's proposal says "use the more advanced part of this otherwise simple ui to make an exception to your global state for one enabled account". that's half the number of steps, open the advanced, select an account, set its state. > > Also, please note that we do not currently provide packages for most of > the popular Linux distributions (Fedora, Debian, Gentoo, Ubuntu) or any > other UNIX-like operating system. Sourceforge downloads are not an > accurate representation of Gaim's usage. > there is no mathematically accurate way to count gaim's users. you can get a rough idea of debian users by looking at the results the popularity contest returns. http://popcon.debian.org/source/by_inst shows gaim with the following: #rank name inst vote old recent no-files 556 gaim 2523 1069 563 883 8 consider that xfree86 has 2 xfree86 244374 93651 61385 41488 47850 try to do some math, extrapolating across the debian population. remembering that many (perhaps most) never find the popularity contest, and that these being simpler users, they are more likely to have gaim. remember that MANY consider it a secuirty risk, and refuse to install it at all. propbly disproportionately few of these install gaim. those are just guesses. redhat/fedora install gaim by default if you install their "graphical internet" meta package. most users would do that. how many end up using gaim? who knows. but you can figure that these installs dwarf the number of unix installs via sf alone. gentoo users also aren't hitting sf. they are getting it by emerge from the gentoo mirrors. these downloads would certainly be sufficient to change the download statistics if they had to go to sf to get gaim, even though I doubt they are as significant as rh/fc. 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. but as their are developers willing to help them AND put up with opinions like mine, and opinions voiced more strongly than mine, it seems to be here to stay. luke |
From: Jason G. E. <jge...@ho...> - 2005-03-12 03:02:04
|
> 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. 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. If you want people to find and use the account manager then make it easy. 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 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. You can't expect people to be comfortable with something that they haven't seen before. > 5)people who do use multiple sets of accounts, which is something I > do, with one set for my own friends, one set that used to be my main > accounts, but became nearly entirely gaim after some unpleasentness, > and a 3rd set for work. But I am *never* online at the same computer > with the work accounts as with the others (except silc where I haven't > set up a second account). Why would you be on your "home" accounts > from work? do you think that many gaim users work at home? 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. Plus, if you're carrying around Gaim on your iPod, you'll have all of those accounts settings available all the time and you'll want some way to manage them. Now Sean is correct, this isn't super common, but as IM becomes more a part of peoples lives then people are going to want greater control. Some of those people exist today and more will come. > 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 > don't think ANYONE will understand intuitively what an account group > is, or how they create one, or why they should. It'll have to be > explained to them, just like the contact support has to be explained > to many users. You've presented the problem and the possible solution in the above sentences. 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. 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. > again looking at friends who use linked accounts, I the most common > case is a single away message, but *at times* any given friend will > set different away messages on each account. accounts that they are > certainly using together. Our ui should allow this, normal users who > never even think twice about other clients use this ability, ours will > also. since they always use the accounts together, and most of the > time with a single state, the ui should make that the easy default > case. > <snip long process of setting distinct status> > Sean's proposal says "use the > more advanced part of this otherwise simple ui to make an exception to > your global state for one enabled account". that's half the number of > steps, open the advanced, select an account, set its state. All along I've said that my status stuff was in addition to the status selector on the buddy list. And in the mock-up I state that a possible variation of the accounts window could make it so that you can set the status of individual account. In fact, my original hand-drawn mock-up included a seperate column for the server connection settings, and the Status column showed the status of each account with "use group" being the 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. 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. 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. > 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 download.com? 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? Yes, that's a loaded question. :-) As I said before, I don't care who has more users. You acknowledge that Gaim is used by Windows users and is probably going to stick around and that's good enough for me. Jason |
From: Luke S. <lsc...@us...> - 2005-03-12 03:36:24
|
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 on. > > 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 gaim.sf.net/plaintextpasswords.php 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 http://gaim.sourceforge.net/sean/status.php 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 different problem. > > 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 give. > > 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 > download.com? 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 protocols independently. > > Jason luke |
From: Jason G. E. <jge...@ho...> - 2005-03-12 04:57:27
|
> 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 |
From: Kevin S. <ke...@si...> - 2005-03-12 10:17:37
|
Jason G. Ellison wrote: > 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. > I don't feel comfortable letting you say Windows is second in UI grace, given the number of applications (and most eerily notably Microsoft's own applications) that choose to ignore the UI design elements provided by the OS in favor of a separate toolkit. Think about how many Microsoft Programs don't even use standard UI widgets, and then go on to think about Mozilla, Gaim, Trillian, Winamp, and many others which also avoid the same. That definitely makes a point contrary to Windows having a graceful UI. And of course all the disagreement with different applications and UIs takes away from the grace on its own as well. And don't get me wrong, I am a Windows user. I spend my time in Linux with a CLI, and rarely a GUI. Windows is my GUI, but I'm not willing to claim it's any good. :) Kevin |
From: Kevin S. <ke...@si...> - 2005-03-12 10:19:06
|
Jason G. Ellison wrote: > 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. > I don't feel comfortable letting you say Windows is second in UI grace, given the number of applications (and most eerily notably Microsoft's own applications) that choose to ignore the UI design elements provided by the OS in favor of a separate toolkit. Think about how many Microsoft Programs don't even use standard UI widgets, and then go on to think about Mozilla, Gaim, Trillian, Winamp, and many others which also avoid the same. That definitely makes a point contrary to Windows having a graceful UI. And of course all the disagreement with different applications and UIs takes away from the grace on its own as well. And don't get me wrong, I am a Windows user. I spend my time in Linux with a CLI, and rarely a GUI. Windows is my GUI, but I'm not willing to claim it's any good. :) Kevin |
From: Ka-Hing C. <ja...@ja...> - 2005-03-10 02:51:15
|
On Wed, Mar 09, 2005 at 03:24:35PM +1300, Jason G. Ellison wrote: > Hey Guys, > > I thought I would join in on the whole mock-up thing and submit some > changes I think would be good for Gaim. > > These changes affect grouping of accounts, global statuses and non-buddy > list status changing. > Is it actually possible for a typical user to group their accounts base on roles? Everyone who I know of who don't code an IM client has 1 account per role. http://geocities.com/jgepublic/mock-up/AccountGeneral.png however, is a pretty good idea. That way whenever there's a connection error we have a place to look at instead of "open debug window and try again". -khc |