From: Andy <spi...@in...> - 2007-03-22 14:27:39
|
Hi list, :) I've been testing the 2.0 beta since the beginning. It's been progressing well and relatively bug free. Great job everyone involved! I have a couple of usability issues with the file transfers interface. Currently when a remote contact requests to send a file, Gaim pops up a requester and waits for the user to accept the file and choose its target file location. This means that the requester can go unnoticed if it pops up behind another window (Gnome users can have this problem with the do not steal focus option on, which is default). The transfer times out at the remote end and is missed. At the very least the option to set a sound or other alert would be useful. It would be best if the file transfer requester did not pop up at all. Instead: 1. The file request notification should be written to the chat window. Either inline with the conversation text or as a part of the edit toolbox. 2. A sound event should be able to be set to alert the user to the incoming file request. 3. The tray icon should flash as per the configurable user alert for incoming messages. 4. When the user returns to the conversation window they can click on the request and select the target file location as per usual. I believe this would be a vast improvement on most chat clients out there who often miss these little usability points. I hope that the developers consider it. Thanks for your time. Andy. |
From: Salvatore B. <em...@gm...> - 2007-03-22 15:32:04
|
On 3/22/07, Andy <spi...@in...> wrote: > > At the very least the option to set a sound or other alert would be > useful. It would be best if the file transfer requester did not pop up > at all. Instead: > > 1. The file request notification should be written to the chat window. > Either inline with the conversation text or as a part of the edit > toolbox. I'm not a developer, but I totally agree with this. > Thanks for your time. > Andy. Salvo. ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel > -- Salvatore Benedetto (a.k.a. emitrax) Student of Computer and Telecommunications Engineering University of Messina (Italy) www.messinalug.org skype:emitrax icq:299985329 No to global warming! http://www.climatecrisis.net/ http://www.stopglobalwarming.org/ Siti di vera informazione Italiana www.beppegrillo.it Please do not send me any word, excel or power point file http://www.gnu.org/philosophy/no-word-attachments.html |
From: Stephen E. <spe...@gm...> - 2007-03-22 16:40:44
|
On 3/22/07, Andy <spi...@in...> wrote: > Hi list, :) > > I've been testing the 2.0 beta since the beginning. It's been > progressing well and relatively bug free. Great job everyone involved! > > I have a couple of usability issues with the file transfers interface. > > Currently when a remote contact requests to send a file, Gaim pops up a > requester and waits for the user to accept the file and choose its > target file location. This means that the requester can go unnoticed if > it pops up behind another window (Gnome users can have this problem with > the do not steal focus option on, which is default). The transfer times > out at the remote end and is missed. > > At the very least the option to set a sound or other alert would be > useful. It would be best if the file transfer requester did not pop up > at all. Instead: > > 1. The file request notification should be written to the chat window. > Either inline with the conversation text or as a part of the edit > toolbox. > 2. A sound event should be able to be set to alert the user to the > incoming file request. > 3. The tray icon should flash as per the configurable user alert for > incoming messages. > 4. When the user returns to the conversation window they can click on > the request and select the target file location as per usual. > > I believe this would be a vast improvement on most chat clients out > there who often miss these little usability points. I hope that the > developers consider it. Indeed, that's how the official MSN client works. As does Google Talk, but it goes as far as showing a preview, if the file transfer is a picture. I believe there's some sort of agreement that popups are bad, see the new buddy list notifications. I do think that file transfers belong to the specific conversation window. The file transfer progress dialog is nice, though. Stephen |
From: Richard L. <rl...@wi...> - 2007-03-22 19:12:08
|
On Fri, 2007-03-23 at 00:56 +1030, Andy wrote:=20 > 1. The file request notification should be written to the chat window. > Either inline with the conversation text or as a part of the edit > toolbox. Look at gaim_xfer_request() in ft.c. We're already doing this. If it's not happening in a specific case, that's a bug, IMO. Richard |
From: Andy <spi...@in...> - 2007-03-22 22:22:11
|
Etan S. C. Reisner wrote: > The fact that Gnome/metacity manages windows so poorly as to fail to > notify users of new windows that pop up that Gnome/metacity > *intentionally* prevents them from seeing is not a flaw that gaim should > really be required to work around. Gnome/metacity really needs to be a > *much* more useful window manager for people if it expects people to not > get annoyed at it. Unless they expect everyone to play by their rules > which they probably do and is something I don't much like, since > applications should Just Work (tm). Granted. The decision to go this way was made a few years ago where the general consensus was that requesters stealing focus was a bad idea. Especially those (like windows and KDE) who take [space] to mean the user's accepted something. People were often dismissing important requesters without knowing as they were typing at the time to requesters stole focus. But the not getting focus idea doesn't really work either. I commented on the gnome-usability list back in 2004 that neither solution is particularly good. I suggested a requester notifier in the panel where it wouldn't bother users until they were ready to interface with it. The thing is, gaim is a Gnome app and should be configurable to work well within that environment. > This is more complicated and not nearly as likely to be accepted, > personally I think overloading the tray icon with this sort of stuff is > just asking for confusion. Gaim already can be configured to flash the tray icon and play a sound when a message comes in, all I'm suggesting is for it to notify the user of an incoming file transfer in the same manner, instead of a popup requester. > Even given the changes above the request would still not be 'in' the > conversation window and putting it there would be interesting, I'm not > sure there's a good place for it and having a file transfer request create > a conversation isn't good and neither is having a popup sometimes and an > in-conversation item other times. Again, gaim already can be configured to open a new conversation window on incoming messages. As Stephen Elilert mentioned, this is apparently already a feature of some other IM clients. From your objections, I'm unsure if you understand my proposal. I'm suggesting that popups be abandoned altogether. In their place any file transfer requests be written to the conversation window with a button (or clickable text) for the user to accept the transfer. Along with tray icon and audio notification options. - In exactly the same way an incoming message is handled. So the ability is already in code, it just needs to be moved to the conversation window. Richard Laager wrote: > Look at gaim_xfer_request() in ft.c. We're already doing this. If it's > not happening in a specific case, that's a bug, IMO. Yes it does print to the window text along the lines of "Soandso wants to send you file-x". I meant that the entire notification and somewhere for the user to accept the request should appear there. Not in a popup requester at all. -- As I said, at the very least it would be handy if a sound event could be assigned so there's some kind of notification. |
From: Richard L. <rl...@wi...> - 2007-03-22 22:28:21
|
On Fri, 2007-03-23 at 08:50 +1030, Andy wrote: > The thing is, gaim is a Gnome app No, it's not. > and should be configurable to work > well within that environment.=20 Gaim should Just Work. If the environment is causing this breakage, then the environment is at fault and we should not work around it. (I'm not saying it is or isn't in this case, as I don't know. And for the record, I use GNOME.) Richard |
From: Andy <spi...@in...> - 2007-03-22 22:42:33
|
Richard Laager wrote: > > The thing is, gaim is a Gnome app No, it's not. Ethan Blanton wrote: > Gaim is not, and never has been, a Gnome application. Okay, nitpickig aside. Yes gaim isn't specifically a Gnome app. Yes it's just written with GTK. But to quote the gaim website "Gaim integrates well with GNOME 2 and KDE 3.1's system tray, as well as Windows's own system tray. This allows you to work with Gaim without requiring the buddy list window to be up at all times." This was the thrust of my comment. We should be looking at making gaim the best experience on any desktop. Neither Gnome, KDE or Windows have a useful way to handle popup requesters, at least Gnome has addressed the accidental dismissing of requesters by typing. Look I don't want to be diverted by strawman arguments. My original post was about an usability issue that others have supported. So can we keep on topic? |
From: Ethan B. <ebl...@cs...> - 2007-03-22 22:50:54
|
Andy spake unto us the following wisdom: > Look I don't want to be diverted by strawman arguments. My original post > was about an usability issue that others have supported. So can we keep > on topic? Both of those replies were on topic. So was the other reply I sent to your message. A reply that does not support your point is not off-topic. The fact that Gaim is not a GNOME app, or a KDE app, or a Windows app, or whatever, is in fact important; it means that if we identify a behavior in an environment which we believe is a flaw in the environment itself, we don't necessarily deal with it within Gaim. In this case, there may be a usability issue that we want to deal with, but it needs to be separated from any substandard environment-specific concerns. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Stephen E. <spe...@gm...> - 2007-03-23 00:25:00
|
On 3/22/07, Ethan Blanton <ebl...@cs...> wrote: > Andy spake unto us the following wisdom: > > Look I don't want to be diverted by strawman arguments. My original post > > was about an usability issue that others have supported. So can we keep > > on topic? > > Both of those replies were on topic. So was the other reply I sent to > your message. A reply that does not support your point is not > off-topic. > > The fact that Gaim is not a GNOME app, or a KDE app, or a Windows app, > or whatever, is in fact important; it means that if we identify a > behavior in an environment which we believe is a flaw in the > environment itself, we don't necessarily deal with it within Gaim. In > this case, there may be a usability issue that we want to deal with, > but it needs to be separated from any substandard environment-specific > concerns. > > Ethan I've just had an idea (brace yourselves!). An occasional file transfer popup shouldn't really bother anyone. So, I believe the problem is with clients that let an user drag and drop multiple files to the conversation window, in effect sending multiple file transfer requests at once (MSN, I'm looking at you) . It is already annoying to have to hit a hotkey multiple times, but not nearly as bad as having multiple dialogs spawning. However, Gaim already has the perfect dialog for multiple file transfers: the file transfer dialog itself. So, if any dialogs are to be spawned, it should be that dialog. Perhaps, with an added "Status" column and appropriate "Accept/Decline" buttons. Flashing the file transfer dialog and/or using the notification area icon should be enough to warn the user. If not, then add a file transfer request sound (see: ICQ). I believe this helps with the multiple rogue popups, without the ugly hack of creating a conversation window(if not open already) just to host the file transfer. What do you guys think? Stephen |
From: Andy <spi...@in...> - 2007-03-23 01:09:28
|
On Thu, 2007-03-22 at 21:25 -0300, Stephen Eilert wrote: > On 3/22/07, Ethan Blanton <ebl...@cs...> wrote: > I've just had an idea (brace yourselves!). > > An occasional file transfer popup shouldn't really bother anyone. So, > I believe the problem is with clients that let an user drag and drop > multiple files to the conversation window, in effect sending multiple > file transfer requests at once (MSN, I'm looking at you) . It is > already annoying to have to hit a hotkey multiple times, but not > nearly as bad as having multiple dialogs spawning. > > However, Gaim already has the perfect dialog for multiple file > transfers: the file transfer dialog itself. So, if any dialogs are to > be spawned, it should be that dialog. Perhaps, with an added "Status" > column and appropriate "Accept/Decline" buttons. Flashing the file > transfer dialog and/or using the notification area icon should be > enough to warn the user. If not, then add a file transfer request > sound (see: ICQ). > > I believe this helps with the multiple rogue popups, without the ugly > hack of creating a conversation window(if not open already) just to > host the file transfer. > > What do you guys think? Not completely without merit ;) but if said window pops up behind a window the user is using (another application) we still have the problem of ignored file transfers. Unless this is implemented with both the option to turn on a sound event and a flashing tray icon. But yes, that is a much more elegant position than loads of requesters. In fact a colleague, not 10 minutes ago, sent me 5 files via IM and I had to hunt down 5 requesters and confirm each separately. It would be easier to handle them if they were all in the same window. |
From: Richard L. <rl...@wi...> - 2007-03-23 01:16:25
|
On Fri, 2007-03-23 at 11:37 +1030, Andy wrote: > Not completely without merit ;) but if said window pops up behind a > window the user is using (another application) we still have the problem > of ignored file transfers. Unless this is implemented with both the > option to turn on a sound event and a flashing tray icon. I think both together would work, which seems consistent with other changes we've made. If we get consensus on that, would you be willing to whip up a patch? Richard |
From: Ethan B. <ebl...@cs...> - 2007-03-23 03:19:20
|
Andy spake unto us the following wisdom: > Not completely without merit ;) but if said window pops up behind a > window the user is using (another application) we still have the problem > of ignored file transfers. Unless this is implemented with both the > option to turn on a sound event and a flashing tray icon. Again, the popping up behind a window with no notification from the window manager is an environment problem. We really shouldn't be fixing things like that in Gaim. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: David B. <Dav...@he...> - 2007-03-23 09:18:34
|
My 10 cents : =20 dislike : - new trayicon for an incoming file transfer : don't spam the systray, = it is full of icons as it is; I saw people having over 10 icons there. They would hardly notice an = appearing file transfer icon ;-) - popping up dialogs. That steal focus. - popping up 10 dialogs for the more or less same content (like 10 = incoming files) =20 =20 like: - reuse existing conversation window: - no new icons/dialogs, that could be "lost" etc... - if the conversation window has focus, then the notification problem = does not exist - if the conversation window has no focus, then it should be handled = the same way as a new message on Windows , that means the windows icon on the task bar will flash = and be colored, until the user clicks it, no focus stealing, no jump-in-your-face; I repeat: this is already = implemented - the information can be displayed in the message pane as already = proposed, or - the information can be displayed in a toolbar/line especially for = that(look for GUI design ideas below) =20 Possible file transfer bar look: User1 is offering file "Vacation.jpg*" [Accept][Deny][Details] =20 * - do not hide parts of the filename ! like the last 4 characters ;-)=20 =20 The [Details] button could open the file transfer dialog for more = options. =20 Regards and keep it simple, David |
From: Ethan B. <ebl...@cs...> - 2007-03-22 22:29:56
|
Andy spake unto us the following wisdom: > The thing is, gaim is a Gnome app and should be configurable to work > well within that environment.=20 Gaim is not, and never has been, a Gnome application. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Ethan B. <ebl...@cs...> - 2007-03-22 22:44:17
|
Andy spake unto us the following wisdom: > As Stephen Elilert mentioned, this is apparently already a feature of > some other IM clients. From your objections, I'm unsure if you > understand my proposal. I'm suggesting that popups be abandoned > altogether. In their place any file transfer requests be written to the > conversation window with a button (or clickable text) for the user to > accept the transfer. Along with tray icon and audio notification > options. - In exactly the same way an incoming message is handled. So > the ability is already in code, it just needs to be moved to the > conversation window. We are unconcerned about "some other IM clients". While they may be a source of inspiration, "SomeMessenger does it!" is not a motivation. That said, this does not sound like an unreasonable way to handle file transfer requests. There are, however, some questions: 1) What do you do when you do not have a conversation open with a user? 2) I personally tend to ignore new messages most of the time, until I am ready to deal with them. I don't get file transfers, so I don't have a good feeling about this, but do people tend to expect to be notified of these in a relatively short period of time? (I would suspect yes, since inattention leads to failed transfers.) Does this mean some additional notification would be in order. 3) We currently don't really allow a way to modify existing text; this probably would have to change, if the conversation became more dialog-like. What should this be like? Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Stephen E. <spe...@gm...> - 2007-03-23 00:16:44
|
On 3/22/07, Ethan Blanton <ebl...@cs...> wrote: > Andy spake unto us the following wisdom: > > As Stephen Elilert mentioned, this is apparently already a feature of > > some other IM clients. From your objections, I'm unsure if you > > understand my proposal. I'm suggesting that popups be abandoned > > altogether. In their place any file transfer requests be written to the > > conversation window with a button (or clickable text) for the user to > > accept the transfer. Along with tray icon and audio notification > > options. - In exactly the same way an incoming message is handled. So > > the ability is already in code, it just needs to be moved to the > > conversation window. > > We are unconcerned about "some other IM clients". While they may be a > source of inspiration, "SomeMessenger does it!" is not a motivation. It is not. However, it is useful to have something to compare against, or examples. Taking a look at those other IM programs (sadly, only under win32 afaik) might help others to better understand the proposed feature. Also, you don't need to implement said feature to do an usability test. > > That said, this does not sound like an unreasonable way to handle file > transfer requests. There are, however, some questions: > > 1) What do you do when you do not have a conversation open with a > user? "Prior art": Conversation windows are created, usually. Probably not the optimal way to do it. > 2) I personally tend to ignore new messages most of the time, until I > am ready to deal with them. I don't get file transfers, so I don't > have a good feeling about this, but do people tend to expect to be > notified of these in a relatively short period of time? (I would > suspect yes, since inattention leads to failed transfers.) Does > this mean some additional notification would be in order. I've seen clients (can't remember which) that allow you to auto-accept files. This is already in Gaim, with the auto-accept plugin. It is the workaround I'm going to use right now. > 3) We currently don't really allow a way to modify existing text; this > probably would have to change, if the conversation became more > dialog-like. What should this be like? I believe the idea is something like: "<Buddy> wants to send you <filename>. Accept or Reject?" With the appropriate links/hotkeys/buttons, etc. Stephen |