GNOME Bugzilla – Bug 360614
Proposal: removal of send & receive dialog
Last modified: 2013-03-18 09:51:40 UTC
There are quite a few bugs about the send & receive dialog, it's look an usability. I think the dialog in itself is wrong and opening a dialog window is not needed here, as it disrupts the workflow, even if the interface stays in a responsive way... you have to move the window away etc. So I think it would be better to integrate this into the main interface, following the idea of the Banshee¹ music player (which is - I think - based on usability studies from Betterdesktop/Novell). [1] http://www.banshee-project.org/images/1/11/0_11_0_ipod-sync.png
Created attachment 74273 [details] Mockup This is a mockup how send/receive could be integrated in the Evolution sidebar in the way Banshee's downlaod progress bars work. It's clean and offers the same functionality. Those bars are meant to be displayed on demand, so after they reach 100% they can be removed for the sidebar again. Any interest in integrating this into Evolution?
michael, that mockup looks pretty great to me (with a seperate scroll bar if a user has 12 accounts), but in 2.8's calendar view, we have the mini calendar at that place. :-/ also see bug 247373.
What is the point of having the send/receive button on the other components' interfaces anyway? I don't know if this has any use for anybody. So my proposal perhaps only applies to mailer anyway. My information is that during 2.9.x it is planned to separate evo's componnets in a way that makes it possible to only start mailer or contacts? If this is true, I think chances are good that the send/receive will be removed from all components but mailer anyway, because else you would still need to start mailer in the background for - for example - tasks. About the seperate scroll bar if a user has 12 accounts... I Does it even make sense to query all those accounts in parallel? I would limit the count of parallel operations to, say, tree. Put the rest in a queue and always display the ones currently in progress (perhaps another bar on the bottom reading "xx operations in queue" or something). For 3-4 operation bars this concept works very well. And it is really my impression that I cannot check 3 counts in parallel and send a mail at the same time and my net connection is not too bad. Reading bug 247373, I noticed that this can also be extended to handle connection errors. The operation bar should then be turned into a simple "error connecting to blah" bar, with an error symbol in front of it. At the same time, there should be a notification bubble for this, pressing either would open a dialog showing the exact error message.
Created attachment 74331 [details] Mockup including error handling This mockup has a bar added that appears when errors occur while fetching/sending mail (also showing a notification bubble)
I like that! (updating fields)
I have four accounts, and I have no trouble checking all of them in parallel, even on a fairly bad connection. It's certainly faster to do that unless you actually are getting dropped packets because of bandwidth overload. I have certainly been annoyed by the pop-up box as well, though it's fairly easily pushed below non-Evolution windows on the desktop stack. I do find it useful to actually see all of the accounts in parallel. Sometimes one of them will hang, and I'll cancel it manually. I certainly wouldn't want any others to hang as a result because they were being checked serially rather than in parallel. It is a bit inconsistent that the every-10-minutes auto-check merely activates a "Fetching mail" line in the status bar at the bottom of the Evolution mail window, whereas a manual check pops up a dialog box. The proposal here is a bit of a compromise between the one-liner and the full dialog box. Most of the time, my accounts clear within a few seconds. Perhaps it would be possible to say something like "Checking mail in 4 accounts... 35% complete" for up to say 5 seconds, but if it takes any longer than that for mail to arrive, show more detail for each account that is still pending. That allows you to cancel an individual account if it is hung, or see that there is a big message or a large number of messages coming through on a particular account, while minimizing intrusion. Whatever is displayed, integrating it into the main Evolution mail window might be an improvement, as long as it's still possible to browse through already-downloaded mail while it's running.
I don't think we should add more noise to the evolution UI. Do the user really need to know the complete status, especially when everything goes fine ? I would propose something simpler: a clickable throbber, with a meaningfull animation (I let you find the good metaphors that would represent what's going on...). A click on the throbber would open a transfer status window, which would display the current running transfer status and a log of completed/aborted operations. I'm not sure we need the cancel buttons. Each operation should abort by themselves if something wrong happen (broken connection, timeout), leaving a meaningfull log message. These log messages would also be useful to store the content of all these annoying popup dialogs that appear randomly (IMAP connection failures, RSS feed retrieval failures...), and finally get rid of them. Pan newsreader has something similar to what I describe... Regarding the throbber icon when nothing happens, it may have a different look if something went wrong, but should reset itself to then normal appearance when what went wrong return to a normal status (for example, a IMAP connection that fails, then comes back, or a mail retrieval on one account that fails, but succeed on a second attempt). It should probably goes back to the normal appearance if the user click on it and open the status/log dialog.
> These log messages would also be useful to store the content of all > these annoying popup dialogs that appear randomly (IMAP connection > failures, RSS feed retrieval failures...), and finally get rid of them. That would solve #478594 .
(In reply to comment #7) > Regarding the throbber icon when nothing happens, it may have a different look > if something went wrong, but should reset itself to then normal appearance when > what went wrong return to a normal status (for example, a IMAP connection that > fails, then comes back, or a mail retrieval on one account that fails, but > succeed on a second attempt). It should probably goes back to the normal > appearance if the user click on it and open the status/log dialog. > Excellent. I just signed up to tell you this. :) If there really are users who want to be pop-up notified there could be a way in the configuration dialog or in the right-click context menu of the throbber to enable the old behavior. That should serve everyone happy and solve #247373.
More screenshots or mockups would be welcome. We may soon be in a position to actually address this.
Seems like a new notification/running tasks system¹ may make it into GNOME 3.0 and I wonder if the send/receive dialog would be a candidate to integrated into this UI. Nothing set in stone here but worth following IMHO. [1] http://live.gnome.org/AlternativeNotificationsUI
Oh, nice!
Unless the timeout is fairly short - like around 15 seconds? - there should definitely be a "cancel" button. Otherwise, the connection attempt will hang for what seems like 60-120+ seconds? Which is annoying if you've corrected the problem (downed network connection, downed server, loose cable, etc.) causing the problem. I do like the idea of keeping the dialog box hidden until a throbber is clicked. Or the current practice of having "pending" tasks appear near the bottom is fine. I guess it's really the same as the current system, except that when you manually request send/receive, you don't get the dialog box, you get the "pending task" in the taskbar at the bottom of the main Evolution window, on which you can click to get the dialog box. We still have the problem that the dialog box is not a very nice size if you have lots of accounts.
Looking through the AlternativeNotificationsUI mockups, it's an interesting idea, but isn't it intuitive that you should be able to see Evolution's current status by looking at Evolution itself? If you have to look in some other place, you might not realize that other place exists, and you might not realize that something is happening there while you are in the middle of fiddling with Evolution. (And we don't want automatic "fetching new mail" processes to trigger a desktop-wide notification; it's just not that important. It's OK if you can see them happening if you happen to open the notification list, but they shouldn't grab your attention by popping up or pulsing anything.)
(In reply to comment #3) > What is the point of having the send/receive button on the other components' > interfaces anyway? I don't know if this has any use for anybody. So my > proposal perhaps only applies to mailer anyway. Slightly OT: Labelling the button "Refresh" would make it less email-centric and more applicable to, say, web calendars or remote address books.
Dup of bug 592187?
*** Bug 592187 has been marked as a duplicate of this bug. ***
Progress of Receiving email is shown in Evolution's status bar. The Send/Receive window is shown only after user invoked it, not during automatic (on timeout) updates. The window can be closed anytime, with no lost, it serves only as a notification what is done (progressing) and what not. Renaming Send/Receive to Refresh sounds wrong to me, because Refresh is definitely not the thing the code behind this does (it does more).
I don't get how the fact the send/receive is invoked by the user justifies evolution should pop a dialog. As for the automatic update, showing the progess in the status bar is enough. The only difference between the dialog and the status bar is there is no progress bar in the status bar items, but I guess it could be added.
(In reply to comment #19) > I don't get how the fact the send/receive is invoked by the user justifies > evolution should pop a dialog. As for the automatic update, showing the progess > in the status bar is enough. Automatic update is not the same thing as update (Send and Receive) invoked by an explicit action by a user.