From: Luke S. <lsc...@us...> - 2004-09-22 01:25:05
|
The status code currently in HEAD is without a UI. the old one is overly aim centric and simply isn't sufficient, which creates the question of what to replace it with. in a previous thread dave west submitted the idea of gaim.sf.net/luke/west1.txt to which i added the following meaningful comments: gaim.sf.net/luke/luke1.txt mark replied that he favored a menu of this, and some discussion ensued which i'm not trying to summerize. basically some people like a menu idea and some don't. after 3 or 4 emails, Brandon D. Valentine proposed the following gaim.sf.net/luke/valentine1.txt which may have had some responces, but they are not preserved in my inbox and i cannot find this thread in the list archives. please excuse the formatting, pasting from screen to non-screen sucks. I'm curious what people think of these suggestions, what improvements they can suggest, or what alternatives they can come up with. i'm even more interested in ideas that represent more than ascii art & text ;-) luke |
From: Ka-Hing C. <ja...@ja...> - 2004-09-22 01:59:14
|
ASCII arts, I think that's close to what Mark said, with some modification of my own: -------------------- |Buddies, etc | |------------------| |[Accounts] [state]| |------------------| |Buddy list | | | | | |__________________| Replace [Accounts] with a a drop down menu with all the accounts, online or not. State is a drop down menu for each status that the account supports. If that status requires a message, then either a window can pop up, or copy the iChat way of in place editing the message. By default, it would show the first online account, and the cooresponding state. Of course when the user click on another account, the cooresponding state will be shown as well. The string should probably be abbreviated so the buddylist is not obscenely wide. Maybe a tooltip should show the full info for the account. If a user chooses the offline state for an account, then switches the 2 menus to show the state of the first online account again. If the user only has one account, then don't show the account menu. -khc |
From: Marc E. <elc...@sb...> - 2004-09-22 04:25:54
|
I think that there should be a few mockups put online, with a description, advantages and disadvantages.. Then maybe some of them can be eliminated and so on, things can be merged, etc. Its hard to picture something in ASCII art. On the subject of handling away messages, I like the way Gossip and Gabber2 do it, but thats my opinion. This one is pretty old, they probably changed the UI, but here it is.. http://usuarios.lycos.es/cgarcia2003/Screenshot-Gabber.png On Tue, 2004-09-21 at 18:59 -0700, Ka-Hing Cheung wrote: > ASCII arts, I think that's close to what Mark said, with some > modification of my own: > > -------------------- > |Buddies, etc | > |------------------| > |[Accounts] [state]| > |------------------| > |Buddy list | > | | > | | > |__________________| > > Replace [Accounts] with a a drop down menu with all the accounts, online > or not. State is a drop down menu for each status that the account > supports. If that status requires a message, then either a window can > pop up, or copy the iChat way of in place editing the message. > > By default, it would show the first online account, and the > cooresponding state. Of course when the user click on another account, > the cooresponding state will be shown as well. > > The string should probably be abbreviated so the buddylist is not > obscenely wide. Maybe a tooltip should show the full info for the > account. > > If a user chooses the offline state for an account, then switches the > 2 menus to show the state of the first online account again. > > If the user only has one account, then don't show the account menu. > > -khc > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel -- |
From: Ka-Hing C. <ja...@ja...> - 2004-09-22 05:09:08
|
On Tue, 2004-09-21 at 21:26, Marc E. wrote: > This one is pretty old, they probably changed the UI, but here it is.. > > http://usuarios.lycos.es/cgarcia2003/Screenshot-Gabber.png This doesn't work at all when you have multiple accounts. -khc |
From: Dave W. <ka...@us...> - 2004-09-22 16:16:53
|
Luke Schierer grabbed the keyboard and banged out: > I'm curious what people think of these suggestions, what improvements they can > suggest, or what alternatives they can come up with. i'm even more interested in > ideas that represent more than ascii art & text ;-) http://unleashed.org/devel/gaim_status_menu.jpg In implementing a very basic way to change and view statuses, this is what I came up with as a menu implementation. I'd also like to see something more akin to my first suggestion as well. I'll provide an example of that later. Basically, in this scenario it looks very much like the old away menu with a couple changes: - The status menu moved to a top level menu - The away button is removed from the bottom of the buddy list - Every account that is added to Gaim is in the status menu and it's status is reflected by the icon next to the name of the account. In this image, the first account is online, the second has an away/busy state set, the third is invisible and the fourth is offline. - Every status that can set has both the name of the status and an icon representing that status. In my mind, this is to train users in association so that if they see the icon in the status menu, they have a description of what it means if it's not immediately obvious. This may not be as important with the stock away items, however when we have custom statuses which might be away or might not be away, it will be important to have icons to indicate which is an away status and which is an available or other status. What's not on this example (yet): - A way of creating/setting/managing custom status messages (whether away/busy or not) - A way of saving/setting a collective status. One great suggestion that Luke had was to add a 'Save status' menu option or button so that one could set the staus of each account the way they like it, then save the state of the collective status into one status that can be recalled quickly. - Probably a bunch of other things, these are just off the top of my head. |
From: Daniel A. <dan...@gm...> - 2004-09-22 17:47:49
|
On Wed, 22 Sep 2004 09:16:39 -0700, Dave West <ka...@us...> wrote: > http://unleashed.org/devel/gaim_status_menu.jpg > > In implementing a very basic way to change and view statuses, this is > what I came up with as a menu implementation. I'd also like to see > something more akin to my first suggestion as well. I'll provide an > example of that later. > > Basically, in this scenario it looks very much like the old away menu > with a couple changes: To be honest, and at the risk of sounding negative, I have to say that i don't think that a nested menu for controlling status is a good way to implement the status UI. Perhaps such a method could exist as an alternative method of changing the status, but i think there should be something more immediately visible and accessible on the buddy list. The current away functionality is far too clunky and this wouldn't really fix anything about the clunkiness. I have mixed feelings about the "Accounts" Buddy List group (from a logical separation standpoint), but think that it is more along the lines that we should be thinking. *** A somewhat different idea that I've had (i can throw together a mock up this evening if anyone thinks it is worthwhile) is to have another "accounts" section at the top (or bottom) of the buddy list that has account information. This section could be vertically resized and/or completely hidden and the contents would be similar to what was proposed for the "accounts" buddy list group. This seems to have the advantages of the "accounts" buddy list group (e.g. immediate visibility and access to functionality), but the additional advantage of not mixing account settings with the buddies (which should be cleaner both functionally and from a coding standpoint). |
From: Luke S. <lsc...@us...> - 2004-09-22 18:43:18
|
On Wed, Sep 22, 2004 at 01:47:42PM -0400, Daniel Atallah wrote:=0D > On Wed, 22 Sep 2004 09:16:39 -0700, Dave West <ka...@us...>= wrote:=0D > > http://unleashed.org/devel/gaim_status_menu.jpg=0D > > =0D > > In implementing a very basic way to change and view statuses, this is=0D > > what I came up with as a menu implementation. I'd also like to see=0D > > something more akin to my first suggestion as well. I'll provide an=0D > > example of that later.=0D > > =0D > > Basically, in this scenario it looks very much like the old away menu=0D > > with a couple changes:=0D > =0D > To be honest, and at the risk of sounding negative, I have to say that=0D > i don't think that a nested menu for controlling status is a good way=0D > to implement the status UI.=0D =0D agreed.=0D =0D > =0D <snip> =0D > ***=0D > A somewhat different idea that I've had (i can throw together a mock=0D > up this evening if anyone thinks it is worthwhile) is to have another=0D > "accounts" section at the top (or bottom) of the buddy list that has=0D > account information. This section could be vertically resized and/or=0D > completely hidden and the contents would be similar to what was=0D > proposed for the "accounts" buddy list group.=0D > =0D > This seems to have the advantages of the "accounts" buddy list group=0D > (e.g. immediate visibility and access to functionality), but the=0D > additional advantage of not mixing account settings with the buddies=0D > (which should be cleaner both functionally and from a coding=0D > standpoint).=0D =0D since i'm seeing someone else suggesting something along these lines, =0D i'm going to re-suggest a ui i have in my mind. I was talking to dave =0D west about this last night and got some possitive feedback as well.=0D =0D you've seen mozilla's dock'ed bar on the side that you can click away =0D with one click? and it collapses into the side? instead of collapsing =0D sideways, have that frame collapse down (i'm biased towards =0D functionality being at the bottom of the window) put an icon & =0D screenname for each account in that. make that the display of current. =0D right clicking one of them can change its status... including signing =0D it off. put some buttons in the bottom (or top) of the frame. "status" =0D (with saved states) & "save" (takes a snapshot of the current state) the =0D status button would be a menu like (and in replace of) our current away =0D button. the other would create a new entry for that menu from the =0D existing config of the accounts it requires more initial set up to set a =0D complex status, but it lets you do things like sign accounts on/off =0D as well as go away (or invisible) or whatever you want from a single =0D click to save and then 2 to 3 clicks to activate. for setting the =0D details of a given account, a dialog along the lines of the one Kevin's =0D ascii art suggests could be used.=0D =0D I realize this is alot of text with no nice pictures to help you =0D understand it, but that's where i'm at in my thinking.=0D =0D the disadvantages as i see it are:=0D * more work to set accounts to some random state. this would be more of =0D an issue for some people than for others, it would allow trivial =0D modifications of some saved state easily (ie changing one or two =0D accounts from something you've done before).=0D =0D * its very multi-account centric. it wouldn't add anything, and would in =0D fact detract from the ui for users who only have one account online at a =0D time. I don't know how important this is.=0D =0D advantages=0D * if, like me, you tend to use the same set of away messages & status =0D settings many times with one week much like the previous one, it would =0D be easy to set up a status for each thing you need and quickly change =0D between them.=0D =0D * it allows different accounts to have different status messages & =0D different away states in any given saved status. it does this without =0D the mess of an away dialog that people complain about.=0D =0D *it allows us to have the away dialog only allow options that apply to =0D that account type, for instance msn need not even offer the ability to =0D set a message.=0D =0D =0D there are probly other advantages and certainly other disadvantages i'm =0D not thinking of right now as well.=0D =0D luke=0D |
From: Tim R. <om...@ho...> - 2004-09-23 04:50:10
|
Note I haven't read any further into this thread than this email yet. Luke Schierer wrote: >since i'm seeing someone else suggesting something along these lines, >i'm going to re-suggest a ui i have in my mind. I was talking to dave >west about this last night and got some possitive feedback as well. > >you've seen mozilla's dock'ed bar on the side that you can click away >with one click? and it collapses into the side? instead of collapsing >sideways, have that frame collapse down (i'm biased towards >functionality being at the bottom of the window) put an icon & >screenname for each account in that. > That sounds a lot like what I was going to suggest, including the collaspable frame, and using mozilla as an example of it, and having it at the bottom. > make that the display of current. >right clicking one of them can change its status... including signing >it off. > Why not left clicking changes status, as if it were a dropdown menu? Then right clicking could let you do other things, like the Account Actions, which are also buried annoying deep in the menus. I'm probably thinking a little of how icq used to work. Except that it just displayed the state (e.g. Away) along with the icon for it, we would also need to display the account name of course. Seems like this would work as well for one account as for many. > put some buttons in the bottom (or top) of the frame. "status" >(with saved states) & "save" (takes a snapshot of the current state) the >status button would be a menu like (and in replace of) our current away >button. the other would create a new entry for that menu from the >existing config of the accounts it requires more initial set up to set a >complex status, but it lets you do things like sign accounts on/off >as well as go away (or invisible) or whatever you want from a single >click to save and then 2 to 3 clicks to activate. for setting the >details of a given account, a dialog along the lines of the one Kevin's >ascii art suggests could be used. > I got lost in there somewhere. I didn't think of that, but in general it sounds like a good idea. One issue I see is if I'm on an account I'm not normally on, and then change to my previously saved away state, when I set up the away state i was probably offline on that account, but wasn't meaning to sign off just then. --Tim |
From: Kevin M S. <ke...@si...> - 2004-09-22 16:52:02
|
Luke Schierer wrote: > I'm curious what people think of these suggestions, what improvements they can > suggest, or what alternatives they can come up with. i'm even more interested in > ideas that represent more than ascii art & text ;-) > I am going to just spit out partial ideas that I presently have: On whatever interface we choose to have that indicates away, have a column along the right side with icons for each account that is connected. If this UI element is a separate "custom status" window, show just the accounts that are set away as icons by prpl with the appropriate status icon for the state they are in, as well as a box containing the "away message" applied overall. Tooltip on hover shows the protocol name, status name, and account name (alias?). If the status display is integrated into the buddy list, keep the bar on the right. On click, pop up a menu allowing the user to select various status supported by each account, including perhaps the ability to sign on and off. I realize this is very trillian-like, but it may not be unreasonable. If the statuses take up more than the height of the blist, a scroll of some kind would be nice, but something in the form of little arrows at the top and bottom of the list would be better than a standard scrollbar. I kind of like the idea of keeping the away dialog in some form: |---------------------| | Away Message | I | | | C | |-----------------| O | | Queued Messages | N | |-----------------| S | | Change | Back | | |---------------------| If the user clicks change, I think it would be very neat if a formatting toolbar could appear, allow the imhtml to become editable, and allow the icons to the right to be used to change the states for each account. The change button could become "Set" Another thought is for the Queue area I allocated, simply make the status icons on the right blink according to which account was sent messages rather than allocate a whole list box. On click we could do some magic to tell the user who has left messages (a popup menu, perhaps) or actually just popup the conversation(s). This is of course probably horrible in some way I'm not seeing, but it's something to get out on the table so people can play with the ideas. Kevin |
From: Rob F. <ga...@ro...> - 2004-09-22 17:51:06
|
I don't have time to read the entire thread right now (huge deadline at work), but what has been thought of along the lines of providing a mechanism for easily identifying the current status of all active accounts? A nice at-a-glance method would be preferable since having to navigate through a menu would seem a rather cumbersome task to accomplish something as trivial as checking status. Kevin M Stange wrote: > Luke Schierer wrote: > >> I'm curious what people think of these suggestions, what improvements >> they can suggest, or what alternatives they can come up with. i'm >> even more interested in ideas that represent more than ascii art & >> text ;-) >> > > I am going to just spit out partial ideas that I presently have: > > On whatever interface we choose to have that indicates away, have a > column along the right side with icons for each account that is > connected. > > If this UI element is a separate "custom status" window, show just the > accounts that are set away as icons by prpl with the appropriate > status icon for the state they are in, as well as a box containing the > "away message" applied overall. > > Tooltip on hover shows the protocol name, status name, and account > name (alias?). > > If the status display is integrated into the buddy list, keep the bar > on the right. On click, pop up a menu allowing the user to select > various status supported by each account, including perhaps the > ability to sign on and off. I realize this is very trillian-like, but > it may not be unreasonable. > > If the statuses take up more than the height of the blist, a scroll of > some kind would be nice, but something in the form of little arrows at > the top and bottom of the list would be better than a standard scrollbar. > > I kind of like the idea of keeping the away dialog in some form: > > |---------------------| > | Away Message | I | > | | C | > |-----------------| O | > | Queued Messages | N | > |-----------------| S | > | Change | Back | | > |---------------------| > > If the user clicks change, I think it would be very neat if a > formatting toolbar could appear, allow the imhtml to become editable, > and allow the icons to the right to be used to change the states for > each account. The change button could become "Set" > > Another thought is for the Queue area I allocated, simply make the > status icons on the right blink according to which account was sent > messages rather than allocate a whole list box. On click we could do > some magic to tell the user who has left messages (a popup menu, > perhaps) or actually just popup the conversation(s). > > This is of course probably horrible in some way I'm not seeing, but > it's something to get out on the table so people can play with the ideas. > > Kevin > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel > > |
From: Diego G. <ga...@in...> - 2004-09-22 22:05:51
|
Rob Flynn wrote: > I don't have time to read the entire thread right now (huge deadline > at work), but what has been thought of along the lines of providing a > mechanism for easily identifying the current status of all active > accounts? A nice at-a-glance method would be preferable since having > to navigate through a menu would seem a rather cumbersome task to > accomplish something as trivial as checking status. I like to have one or more rows of icons on the bottom of the buddy list showing the status of the various account, with different menu to set the status for every icon and tooltips showing the text of the status, the online and idle time and similar info; that is exactly what my account_state plugin does :) Well... it's far from perfect (and not tested for every protocol): it could be more useful with a button to set the global away state and the possibility to show offline accounts, but I really think it's quite user friendly. Diego |
From: Christopher (s. O'B. <si...@pr...> - 2004-09-22 19:10:53
|
Well, I think this idea was proposed a while ago, before the status rewrite became such a prominent part of gaim-devel. It provides current account status in a readily visible manner. Please excuse me if the idea isn't entirely coherent, I just jotted it down as I thought about it. A second blist tree under the first in the buddy list, showing a node for each account, with its status displayed therein. Visually similar to adding all of your account IDs to a "me" group. I do this already :) Ensure that the sizing of the two lists is adjustable with a drag handle, to allow the status list to be shrunken down for those who don't want to see it. Creating a pair of new BlistNode types, perhaps GaimBlistAccountGroup, and GaimBlistAccount Right click context menu on an account node would result in a menu containing: Online/Offline --- Active > Away > Do Not Disturb > Idle > --- Account Options... Where Active, etc are the collection of available status types, and the submenus of each provide the saved custom text messages (if applicable) for example an Oscar account could have a menu of: Online/Offline --- Active Away > "I'm away right now" "I'm at work, stop bothering me" --- Add New... Visible/Invisible --- Account Options... Right click on the account group node results in (somehow) a combined selection of common away/active states (similar to the current Tools > Away > Set All Away menu). I'd presume that it would just be a selection of choices which all prpls provided, such that if every account a user had provided an "Away" state which had a context message, then you could set all to away with a context message. If all accounts have "Active", but only some provide a context message, then you'd still have a context message submenu, but those accounts which couldn't understand a context message would ignore it and simply set "Active". This would require merging something like Oscar's "Invisible" with MSN's "Hidden" status types, so that they could be treated as identical for the purposes of the above mentioned grouping. If not all of your accounts provided a particular status, such as "Do Not Disturb" or "Busy", then that would not be an available choice. I'd be happy to provide clarification if parts of that didn't make any sense... - siege -- Christopher (siege) O'Brien <si...@pr...> http://preoccupied.net/~siege/ |
From: Kevin M S. <ke...@si...> - 2004-09-22 20:41:59
|
Christopher (siege) O'Brien wrote: > A second blist tree under the first in the buddy list, showing a node > for each account, with its status displayed therein. Visually similar to > adding all of your account IDs to a "me" group. I do this already :) > I am pretty strongly opposed to any account data appearing in the blist tree. I think that's needlessly confusing and the whole concept seems fundamentally wrong to me. If the IM client had a good interface for displaying statuses for each account, I wouldn't have myself on my buddy list in the first place. Kevin |
From: Luke S. <lsc...@us...> - 2004-09-22 21:07:31
|
On Wed, Sep 22, 2004 at 04:42:27PM -0400, Kevin M Stange wrote: > Christopher (siege) O'Brien wrote: > >A second blist tree under the first in the buddy list, showing a node > >for each account, with its status displayed therein. Visually similar to > >adding all of your account IDs to a "me" group. I do this already :) > > > > I am pretty strongly opposed to any account data appearing in the blist > tree. I think that's needlessly confusing and the whole concept seems > fundamentally wrong to me. If the IM client had a good interface for > displaying statuses for each account, I wouldn't have myself on my buddy > list in the first place. > > Kevin even in its own frame, and thus visually separated? obviously the idea here is to develop an interface where having yourself on your buddy list would no longer be necessary. luke |
From: Brian B. <boc...@gm...> - 2004-09-22 22:46:38
|
<snip> > > > > I am pretty strongly opposed to any account data appearing in the blist > > tree. I think that's needlessly confusing and the whole concept seems > > fundamentally wrong to me. If the IM client had a good interface for > > displaying statuses for each account, I wouldn't have myself on my buddy > > list in the first place. > > > > Kevin Isn't that why it was suggested that the separate frames be totally resizable? That way, those of us who abhor the idea of having more than the text names of online buddies on our buddy list can make the bar disappear, like the mozilla toolbar - but those of us who don't want to add our own names to our buddy lists can make the account status frame be shown. Perhaps a better comparison would be the attachment toolbar in evolution 2.0, if you've seen that. My $0.02 is that this sounds like a nice, clean implementation. I'd rather have all of my gaim info in one window. Brian |
From: Sean E. <sea...@gm...> - 2004-09-22 23:13:28
|
I've purposely avoided reading this thread too in-depth until I formed my own opinions of what would be a good GUI. Check http://gaim.sf.net/sean/status.php It's simpler than what I sense most people are hinting at here; and that's good. I believe it will handle almost every status-related need. I have ideas for more complex status stuff (setting account statuses individually), but I'll wait for feedback on this first. |
From: Peter L. <spa...@si...> - 2004-09-22 23:25:00
|
Sean Egan wrote: >I've purposely avoided reading this thread too in-depth until I formed >my own opinions of what would be a good GUI. > >Check http://gaim.sf.net/sean/status.php > >It's simpler than what I sense most people are hinting at here; and >that's good. I believe it will handle almost every status-related >need. > >I have ideas for more complex status stuff (setting account statuses >individually), but I'll wait for feedback on this first. > > I've felt pretty much the same, I haven't commented on the UI until some more discussion takes place, but I think this looks very neat, tidy, effective and should be fairly idiot proof Sean. Well done. I look forward to hearing your individual status thoughts. Pete. |
From: Christopher (s. O'B. <si...@pr...> - 2004-09-22 23:43:40
|
This seems to be centered on Active vs Away. How will it work for things like invisible, do not disturb, etc? On Wed, 2004-09-22 at 19:13 -0400, Sean Egan wrote: > I've purposely avoided reading this thread too in-depth until I formed > my own opinions of what would be a good GUI. > > Check http://gaim.sf.net/sean/status.php > > It's simpler than what I sense most people are hinting at here; and > that's good. I believe it will handle almost every status-related > need. > > I have ideas for more complex status stuff (setting account statuses > individually), but I'll wait for feedback on this first. > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel -- Christopher (siege) O'Brien <si...@pr...> http://preoccupied.net/~siege/ |
From: Kevin M S. <ke...@si...> - 2004-09-22 23:49:11
|
Sean Egan wrote: > Check http://gaim.sf.net/sean/status.php > > It's simpler than what I sense most people are hinting at here; and > that's good. I believe it will handle almost every status-related > need. > My main objection in your design, Sean, is the timeout on editing the message. I think it should be a button, because people pause to think sometimes. Not everyone is amazingly quick-witted. :) There should be a button of some kind to click and indicate completion. I tend to think the accessibility would be reduced with a timeout as well (but I don't really know much about that subject). As for the rest of the UI, I really want somewhere for there to be a status-per-account display. Either a way to view a snapshot of this set of states or some kind of always-on display. I don't know how best to do it, but I think it should exist. Other than that, this solution is very nice. Kevin |
From: Luke S. <lsc...@us...> - 2004-09-23 16:56:55
|
working forward off the assumption we go with this as written and thing=20 about other things along the lines of what Ethan has summerized as=20 things move forward, some additional ideas. the autologin optioning we currently have is a flawed concept, we've=20 seen several requests to allow more powerful account grouping, and even=20 more requests to allow better activation of this than the undocumented=20 middle click on sign-on. i'm not suggesting we do that, rather i'm=20 suggesting we remove it entirely.=20 sean has us abstracting everything down to a single gaim-dude. this=20 presents the most unified possible ui to the user, though it will=20 perpetuate the confusion of why msn or jabber don't have auto responces.=20 additionally, he tells me however that a user will still be able to=20 define more complex states, "(11:04:04) SeanEgn: And the user will be=20 able to create custom statuses where he'll be able to say 'This account=20 should be away, this account should be available, this account should be=20 invisible'" given 1) the abstraction and 2)the ability to do complex=20 things, I think it makes sense to, on signon, return to the last state.=20 if "offline" is treated as part of a state, as is invisible, then we can=20 accurately sign on only those accounts that were online, marking them=20 invisible where appropriate, starting to away when appropriate, so on. along with this, we currently have a -w/--away option that is rather=20 single-account centric, though i believe it does function (in old=20 status) with multiple accounts. I'd suggest we either rename that to -s=20 (state) or leave it as is but either way make it so that it functions in=20 parallel with the global menu sean has proposed. luke On Wed, Sep 22, 2004 at 07:13:24PM -0400, Sean Egan wrote: > I've purposely avoided reading this thread too in-depth until I formed > my own opinions of what would be a good GUI. >=20 > Check http://gaim.sf.net/sean/status.php >=20 > It's simpler than what I sense most people are hinting at here; and > that's good. I believe it will handle almost every status-related > need. >=20 > I have ideas for more complex status stuff (setting account statuses > individually), but I'll wait for feedback on this first. >=20 |
From: Nathan W. <fac...@fa...> - 2004-09-23 17:08:06
|
Sean Egan wrote: >I've purposely avoided reading this thread too in-depth until I formed >my own opinions of what would be a good GUI. > >Check http://gaim.sf.net/sean/status.php > >It's simpler than what I sense most people are hinting at here; and >that's good. I believe it will handle almost every status-related >need. > >I have ideas for more complex status stuff (setting account statuses >individually), but I'll wait for feedback on this first > > The only additions I have to that is that we may want to rename "Online" to "Available" since you're really online until you're offline, and that for Available, there needs to be an "Available-with-message" option, since we've got a least 2 protocols that support such things (Jabber and AIM). |
From: Dave W. <ka...@us...> - 2004-09-25 00:23:38
|
Sean Egan grabbed the keyboard and banged out: > I've purposely avoided reading this thread too in-depth until I formed > my own opinions of what would be a good GUI. > > Check http://gaim.sf.net/sean/status.php > > It's simpler than what I sense most people are hinting at here; and > that's good. I believe it will handle almost every status-related > need. > > I have ideas for more complex status stuff (setting account statuses > individually), but I'll wait for feedback on this first. Sean, can you please clarify for me a few things about this design? I know it's still in the conceptual and I'm trying to wrap my head around deeper parts of the implementation (I implemented this design to have a look at possible issues I could think up). - How do setting/unsetting individual account statuses impact what's indicated to the user on this menu? For instance, let's say I play with my statuses individually, setting one away, one offline, etc; at what point does the global status menu change (and in what way does it change)? Another example that is similar yet may have a different answer is what if I have more than one account and I attempt to globally sign them on, how does this menu change (if at all) when one of them is either not able to go online, or is dropped offline? Does the answer change if I have 10 accounts, I set them globally available/online and only 1 actually makes it online? - Similarly, if I am in an "online" state, have at least one account online and at least one account offline, is there a clear way that I can make sure that I globally reconnect? How about for going offline or away messages? Is there a nice and hopefully obvious way of re-syncing accounts that have fallen out of sync, e.g. reconnect when there's no reconnect dialog present? Thanks, --dw |
From: Sean E. <sea...@gm...> - 2004-09-25 01:40:34
|
On Fri, 24 Sep 2004 17:23:23 -0700, Dave West <ka...@us...> wrote: > - How do setting/unsetting individual account statuses impact what's > indicated to the user on this menu? For instance, let's say I play with > my statuses individually, setting one away, one offline, etc; at what > point does the global status menu change (and in what way does it change)? The only way in my design to change individual account statuses is to create a new status. Choosing "Create new status" will create a dialog with the current status filled in. You can just make a change to one account and that's done. You could either give this new status a name, or maybe Gaim will automatically generate one for you "SeanEgn3 is away," perhaps. That name will show on the menu. > Another example that is similar yet may have a different answer is what > if I have more than one account and I attempt to globally sign them on, > how does this menu change (if at all) when one of them is either not > able to go online, or is dropped offline? Does the answer change if I > have 10 accounts, I set them globally available/online and only 1 > actually makes it online? The menu will still show what status you attempted to change to. You will need to rely on a different method to tell you an account didn't login (for now, a dialog box). > - Similarly, if I am in an "online" state, have at least one account > online and at least one account offline, is there a clear way that I can > make sure that I globally reconnect? How about for going offline or away > messages? Is there a nice and hopefully obvious way of re-syncing > accounts that have fallen out of sync, e.g. reconnect when there's no > reconnect dialog present? Not sure I understand the question. Are you just requesting what the Auto-reconnect plugin does? -s. |
From: Dave W. <ka...@us...> - 2004-09-25 01:51:26
|
On Fri, 24 Sep 2004, Sean Egan wrote: > On Fri, 24 Sep 2004 17:23:23 -0700, Dave West <ka...@us...> wrote: >> - Similarly, if I am in an "online" state, have at least one account >> online and at least one account offline, is there a clear way that I can >> make sure that I globally reconnect? How about for going offline or away >> messages? Is there a nice and hopefully obvious way of re-syncing >> accounts that have fallen out of sync, e.g. reconnect when there's no >> reconnect dialog present? > > Not sure I understand the question. Are you just requesting what the > Auto-reconnect plugin does? No, I'm requesting what the behavior will be for manual reconnection. I may have missed it in the thread or in the design page, but it appears to me that the only way to manually reconnect disconnected accounts (that don't have a current reconnection dialog open and don't have auto-reconnect enabled) is to change all of the statuses to another status and then change it back to online to bring the other accounts online. I'm just asking for how that should be solved. If I missed it, please point me to where it's documented :) --dw |
From: Ka-Hing C. <ja...@ja...> - 2004-09-25 19:33:38
|
On Fri, 2004-09-24 at 18:40, Sean Egan wrote: > The only way in my design to change individual account statuses is to > create a new status. Choosing "Create new status" will create a > dialog with the current status filled in. You can just make a change > to one account and that's done. You could either give this new status > a name, or maybe Gaim will automatically generate one for you > "SeanEgn3 is away," perhaps. That name will show on the menu. I am not sure if this is good. If I have more than 2-3 accounts then the number of combinations would be quite huge. Also, say I want to change one of my accounts from available to away, so I would do what you mention above and name it "javabsp is away". Couple days later I have all my accounts set to invisible, and I want to set javabsp to away, so I choose the "javabsp is away" item and boom, all my other accounts become available. -khc |