Community
Participate
Working Groups
Editors are being used by both the SDK and 3rd parties for non-local contents. Examples are: * Compare editor retrieves contents from CVS * Browser retrieves web page contents * Mylar task editor retrieves and submits contents to/from Bugzilla In each case the editor performs either a load of its contents from a server or a submission to a server. These actions can take seconds to perform, and the user often has to wait for the action to complete. While such an operations is happening the user typically can not interact with the editor, as such, they need to be made aware of the following events: 1) That the editor has gone into a busy state 2) That the editor has returned from its busy state The current mechanism of making the editor title go italic is probably sufficient for (1). Mylar additionally disables all of the widgets in the task editor, making its form contents go gray, and uses the form busy spinner (which unfortunately disappears when the editor scrolls). Together I think this is sufficient for (1). The problem I'm noticing is that when users expect an operation to take more than a couple of seconds, they are reasonably likely to switch to another editor, and will not know when the editor they were working with is ready for interaction again (2). So I'm wondering if we should resurrect the busy spinner, but for editors only because they can be so distracting on views, many of which frequently update their contents in the background (bug 168432). Editors are funamentally different than views because their contents are updated and reloaded as a result of user interaction, so we would be unlikely to have 10 editors all of which had busy spinners due to background updates. Also, if a user activated a Mylar task that opened 10 editors on remote resources, they would want to see all 10 busy spinners because the workbench would not be ready for interaction until at least one of those editors stopped being busy (similar to how Firefox is not ready for interaction until at least one page is loaded when restoring a session with multiple tabs). There is the question of background saves. My guess is that they should not cause the spinner to come up because the editor contents are not changing, and that the busy spinners be limited to when the user explicitly invokes a load or submission of the editor contents.
An enthusiastic +1 here, I would love to see the spinner resurrected for editors!
(In reply to comment #0) > ... > The problem I'm noticing is that when users expect an > operation to take more than a couple of seconds, they are reasonably likely to > switch to another editor, and will not know when the editor they were working > with is ready for interaction again (2). > ... Is the editor name only shown in italics when it's the active editor? If so, I would consider it a bug, but if not, why is this not enough as a visual cue that the editor is no longer busy?
The italics works great for views because it means that looking at a view tab lets you know immediately whether its busy or not. The same is true with editors for the case where you want to check if an editor is busy. I'd like to hear what others think, but I'm pretty sure that the title's change from italic to non-italic is not sufficient to indicate that the editor is no longer busy. Unless your gaze is focused on the editor title, or very close to it, you will not notice the change. We see things with saccades (http://en.wikipedia.org/wiki/Saccade), which automatically jump to things that are in motion. That's why in Firefox we can be looking in the middle of a web page, and notice when another editor tab has stopped loading--our saccade keeps jumping to that animation, and so we notice when it has stopped. (It's also why animations can be so distracting when they're misused, and why I think the current animation should be slowed down some).
Any chance of this making 3.3? I assume that it doesn't require any API changes, but if resurrected it seems like it should go out with M6 or M7 so that there is sufficient time for community feedback. With M4 users would have seen this in action thanks to the compare editor. That spinner was too fast in that version, but was there any feedback from that? Personally I found it worked well with the compare editor and with our editors.
(In reply to comment #3) > I'd like to hear what others think, but I'm pretty sure that the title's change > from italic to non-italic is not sufficient to indicate that the editor is no > longer busy. Why is it important that the user's attention is drawn to the fact that an editor is no longer busy? Can we discuss typical workflows? What I'd like to explore is what users are doing while an editor is busy and when/how they decide to go back and continue working in an editor.
Workflow 1: Mylar's task editor * Add a new comment and click Submit on a bugzilla bug for a repository that's slow or on the other side of the continent/planet * While the submission is happening you want to keep working, so you start reading another bug or hacking on some Java code * 5-10s later the editor stops being busy and you want to see the result, e.g. to add something else. This case is so common both for opening bugs that don't yet have cached data and for submission, that the Mylar task editor has the whacky behavior of automatically activating itself after it is done synching with the network. This must violate some UI design principle because it steals focus from what the user was typing, but without some mechanism like the animation indicating when the synch is done, it's a necessary tradeoff. Workflow 2: Web browser editor * Open a web page, it's slow to load * Go back to a Java editor and keep working, but what you really need to be doing is on that web page, so you need to know when it's done loading. This is the same story as Mozilla/MSIE busy indicators on browser tabs. Note that I use the Tasktop extensions to Mylar, so the Workbench is my default browser and so I frequently end up in this workflow. But others using SDK extensions that require more embedded browsing (e.g. HTML authoring tools) have a similar workflow too. My take on this is that editors are where users spend most of their productive interaction time. I have some numbers verifying this (e.g. http://kerstens.org/mik/publications/mylar-ieee2006.pdf article and we will soon be collecting live usage stats from participating Mylar users: http://wiki.eclipse.org/index.php/Mylar_Monitor_Usage_Statistics ). So when an editor goes into a busy state, the user needs to be made explicitly aware of that fact because there is a good chance that they will be waiting on the editor to stop being in that busy state. If the user has the expectation that the busy state will last more than 5s or so, there is a good chance that they will go to another editor until the one they actually want to use is done being busy. Hence the need to for a clear visual indication of when an editor is done being busy.
Here is my current take on this, but of course I'm interested in others' opinions: For background work, Eclipse shows the busy state in two places - in the view or editor tab if the background work is associated with one, and in the progress area, usually in the trim area at the bottom. Background jobs that matter to the user (i.e. ones that they potentially wait for to finish) should be shown in the progress area. Other jobs should be created as system jobs so that they don't show up in that area, masking the important ones. The tabs use an italic font, a very small visual change that can easily be checked by looking at the tab, but will not catch the user's attention right away. The progress area shows a small progress bar (ideally making it predictable when an operation will be completed), and if the progress area goes blank at completion time, there is a good chance that the user will notice this without having to check. So if the user is doing a main task and then spends some time on the side while waiting for a background operation that is important for the main task, they should be able to see immediately when they can continue with their main task by noticing that the progress area is now empty. If you think the visual indication in the progress area is not enough, could we maybe use another Eclipse mechanism to draw the user's attention to an editor? One that we already have - bold font in tabs? Currently, only view tabs support bold (signifying a content change), but we could easily enable that for editors as well. In the cases you described, the editors that were not visible did indeed undergo a content change as the result of the background work.
Created attachment 61902 [details] patch to enable bold in editor tabs Attaching a patch if you would like to give this a try...
Wrt. bold in the editor titles, I am CC'ing Mike Valenta because I know there used to be support for clearcase repositories that used dynamic views whereby CC would update the files on disk when the server copy changed. A separate process in Eclipse would watch for these and refresh the resource, including I assume updating the editor. Use of bold in the editor title could be interesting in this case.
On the whole, I think it would be helpful to have the editor tab indicate that the contents of an editor have changed since the last time the user looked at it. As an example to consider, if I refactored a method name and some of the contents of the editors changed, wit would be good if all the tabs of open editors that contain changed files became bold. This leads to a couple of questions: - What about if one of the editors was the active editor? Would its tab become bold as well? - What about editors that are not in the tab area? Unfortunately, in the editor drop down, bold is already used for another purpose (to indicate hidden editors). Of course, this doesn't address the original requests, which was to make progress associated with an editor less subtle so that the user is more likely to notice it's absence. Although, I guess one could argue that the user would only care if the completion of the task resulted in a change in the editor content.
(In reply to comment #10) > - What about if one of the editors was the active editor? Would its tab become > bold as well? View tabs with changed content are not shown in bold if they are visible. > - What about editors that are not in the tab area? Unfortunately, in the editor > drop down, bold is already used for another purpose (to indicate hidden > editors). I would be in favor of using a different visual cue in the editor drop down. > Although, I guess one could argue that the user would > only care if the completion of the task resulted in a change in the editor > content. I agree, but would be interested in Mik's opinion on this.
(In reply to comment #11) > (In reply to comment #10) > > - What about if one of the editors was the active editor? Would its tab become > > bold as well? Agree. > View tabs with changed content are not shown in bold if they are visible. > > > - What about editors that are not in the tab area? Unfortunately, in the editor > > drop down, bold is already used for another purpose (to indicate hidden > > editors). > > I would be in favor of using a different visual cue in the editor drop down. Agree. Bold is the wrong visual cue in this case (regardless of what we do with tab treatment).
(In reply to comment #11) > I would be in favor of using a different visual cue in the editor drop down. +1. It took me forever to figure out the meaning of that bolding and everyone I asked afterwards did not know what it meant. Putting in a horizontal separator (e.g. "---------- Invisible ----------") would be much more obvious and not waste the use of bold on this. There is something compelling about using bold as suggested, but I'm concerned that it would be much to easy to confuse with "unread" if we have compelling cases where there is no "unread" content on the editor that stops being. In Mylar, and other applications that use editors for collaboration, editors frequently get into an unread state. Email readers have made users associate bold with unread. Consider these two examples, which distinguish with unread and include the spinner: 1) User opens Compare editor via CVS, busy spinner starts (as with M4), opens Java file because CVS is being slow, then when compare results are done editor tab goes bold (consistent with notion of unread). 2) User working in Java editor, task editor synchs in background (spinner starts), incoming comment comes in on the bug (spinner stops, tab goes bold to demand the users attention) 3) User comments on a bug, hits submit (busy spinner starts), submission completes (spinner stops, no bold because editor is active) 4) User does Java refactoring which updates 10 Java editors in the background, all got spinners when updating to let user know (great) , but it would be horrible for all 10 editors go bold (the whole point of refactoring is that I don't need to see results if I trust the tool, and to inspect would need a diff view anyway). So I think that bold would be helpful for when the editor wants to demand the users attention (similar to how views do this), but not for every case where it stops being busy. With bold users will feel that they must click the tab because they'll want to get rid of the bold (visually it is *very* pronounced). With the spinner stopping the change is still explicit but the choice is up to the user. Also note that I'm coming from a perspective where less bold in the Eclipse UI is better, because bold is so visually pronounced and so good at drawing the user's attention to pick out one or two items from a listing of dozens. That's why Mylar uses bold for the active task in the Task List and to highlight the most interesting elements in views with resource type content. Following up on Workflow 2 on comment#6: the workbench became my OS's default browser over a month ago and I stopped using Firefox and IE, so I see almost all web content in Eclipse editor tabs. I have lost the busy spinners that browsers have, and I wonder if others can imagine Firefox staying as usable as it is without its busy spinners (even though it has a progress bar). I realize that many of us on this bug (including me) shot down using Firefox as a comparison for busy spinners for views. But in my eyes Eclipse is really starting to win at being a rich client, which means that the contents that we typically see in browser tabs is now showing up in Eclipse editor tabs. Whether these are plain Browser editors or better yet rich editors, I think that it is worthwhile to improve the user experience when the contents of those editors are synched with servers.
While this bug is in progress we are experimenting with adding the busy spinners on our own, and noticed that in 3.3M4 these came from the presentation via AnimatedTabItem. While we think it's a bad idea to provide our own custom presentation, we would like to experiment with providing the spinner by repeatedly setting the editor icon. Do you foresee there being too much overhead with setting the icon on an editor every few hundred millis to drive the spinner?
I am not sure but would expect it to not have too much overhead.
FYI: The busy animation design for form-based editors has been updated to have a sexier look, as well as smoother edges with PNG format. The implementation is targeted for M7. See bug 179812.
Mik, would be great if you could share the solution being used in Mylar, I would like to give it a try as well.
For the purpose of experimentation we have been bootstrapped on a local implementation of this for over a week and it is working beautifully, especially with the new animation (bug 179812). What we plan to do now is to add this to the Mylar task editor (bug 182762). That'll be done in a reusable way so that others who have editors for remote resources or other slow-loading things can reuse it. The only thing that I'm a bit leary about is that we're going to stop using the Forms busy indication and rely on our own, which is not quite following the Platform look-and-feel. But I guess that this is OK because it means that we will end up with usage feedback that can help determine whether this mechanism should be used in Platform for 3.4.
This is continuing to be very valuable to Mylyn and I believe that it would be valuable to others. Should we discuss whether it makes sense to have available in Platform UI in the 3.4 cycle? The implementation is straightforward and present in Mylyn, so it seems like more of a question of whether Platform considers this to be helpful UI.
(In reply to comment #19) > Should we discuss whether it makes sense to have available > in Platform UI in the 3.4 cycle? Sorry, but it does not look like we will have the resources to work on this for 3.4.
Remy is now responsible for watching the [EditorMgmt] component area.
Remy: Note that we have full support for this in Mylyn's task editor, also used by the Tasktop web browser editor. Should be easy to generalize.
(In reply to comment #22) > Remy: Note that we have full support for this in Mylyn's task editor, also used > by the Tasktop web browser editor. Should be easy to generalize. I haven't gone through this bug yet but there seems to be a tie in with bug 86221.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
