Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 272089

Summary: [theme] improve the usability of focusing
Product: z_Archived Reporter: Mik Kersten <mik.kersten>
Component: MylynAssignee: Project Inbox <mylyn-triaged>
Status: CLOSED MOVED QA Contact:
Severity: enhancement    
Priority: P1 CC: eclipse, robert.elves, shawn.minto, steffen.pingel, tom.seidel
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Bug Depends on: 172580, 175655, 178891, 196327, 197028, 200832, 203951, 208702, 210709, 213097, 213532, 246441, 249400, 302015, 341631, 354279, 371008    
Bug Blocks:    

Description Mik Kersten CLA 2009-04-13 18:18:25 EDT
We have not iterated on the UI for a couple of releases and should address the following problems:
* Hard to turn off auto-focusing
* Alt+click navigation is awkward and problematic on KDE
* Expand all can break user's expectations
Comment 1 Endre Stølsvik CLA 2009-07-27 03:36:33 EDT
The bug 238220 just got closed, with a comment that further discussion should take place here.

I wrote that bug a while ago, while I still was very new to Mylyn.

Reading over it now, having used mylyn a while, I still wholeheartedly agree to the "executive summary", and actually to everything in the bug.

I really still never use the "focused view" of the package explorer, because I _need_ the overview that the, well, overview gives me. Read the mentioned bug. 

Also, when I occasionally fall into the focused view (since mylyn apparently dumps me there w/o questions when I change task), I feel that way too few files are "focused": Sometimes even not the ones that are open in the editor are shown at all. When I close a file, this should, IMHO, not force the file "out of view", but maybe rather go from bold to normal, or something like that. Italics? Gray? Only after so and so many _use hours_ (not wall-hours, of obvious reasons) without further use should it disappear. This should, contrary to the "it should just work"-logic, be configurable.

Also, the "magic" where the focusness should follow the task doesn't seem to work much at all. (Again - does the "deprecation time" follow use-time (for the current task), or wall-time? If the latter, then just fix it.)

Still, though - I love mylyn. Only sadly a major part of the intent of it (the focused views) doesn't work with me, pretty much at all. (The bugzilla-integration, and "cvs" integration, rocks).
Comment 2 maarten meijer CLA 2009-07-27 08:14:32 EDT
Just reading this bug fresh, I agree with Endre, I too dislike the focus in the package explorer. I just like to add some suggestions:
I do always have my history in the File menu set to 10 or 15 filenames, because I like help in what files I recently saved or edited, so maybe that is part of solution.

So maybe current focus tries to do different things and compromises, maybe focus in package explorer should be a smart filter or even multiple smart filters.
The focus button should offer a popup with different variabkle scopes and focus on the one selected: recent opened, recent saved, recent edited, all in current context, in context history, etc. 

Maybe the focus button should not be a permanent state but a temporary one, timing out again after a set time, or mouse-leave view, or something smarter..

Another option maybe to have some sort of context aware breadcrumbs in the package explorer, as breadcrumbs is a more familiar interface than alt-click.
Comment 3 Mik Kersten CLA 2009-07-28 19:23:48 EDT
Thanks for the comments!

Endre: If working with the Package Explorer unfocused, try Navigate -> Context Quick View (Ctr+Alt+Shift+Right Arrow is the shortcut).

Maarten: If the task is active, Mylyn manages the open editors list to match the context, so we also consider Ctrl+E to be a good way to access the context, although the bold decoration for hidden editor tabs that comes from Platform is unfortunately not very intuitive.
Comment 4 Endre Stølsvik CLA 2009-07-28 19:41:14 EDT
Mik: That quick-view is utterly empty. What's wrong?
Comment 5 Mik Kersten CLA 2009-07-31 14:21:05 EDT
Should only be empty if there is no task active or if there are no elements in the task context.  If there are, and it is still empty, please file a bug wit hsteps to reproduce.
Comment 6 Endre Stølsvik CLA 2009-08-02 13:17:41 EDT
Sorry; No task was active. That was somewhat strange - how does that happen, typically? - I'm rather certain that I've never explicitly deactivated the active task.

Now that I've got it filled with context, I have more questions:

* This thing was rather verbose, with all "paths" exposed - not like what I have in the Package Explorer, where the nodes all start from root, having full package name, liks "com.example.test", instead of "com"+->"example"+->"test". Is it possible to have it like I have in the PE?

* I used the "arrow down" in the top right corner to move it, then resize it, then "remember size and position". However, the tree-browser with its scroll-pane still only uses the size of the original pop up, even though there are way more space now. This persisted through a re-invocation of the view, then also through a reboot of Eclipse.
Comment 7 Mik Kersten CLA 2009-08-05 17:03:36 EDT
(In reply to comment #6)
> * This thing was rather verbose, with all "paths" exposed - not like what I have
> in the Package Explorer, where the nodes all start from root, having full
> package name, liks "com.example.test", instead of "com"+->"example"+->"test". Is
> it possible to have it like I have in the PE?

Yes, please create a new bug for that.  As it turns out, this is a bit tricky.
 
> * I used the "arrow down" in the top right corner to move it, then resize it,
> then "remember size and position". However, the tree-browser with its
> scroll-pane still only uses the size of the original pop up, even though there
> are way more space now. This persisted through a re-invocation of the view, then
> also through a reboot of Eclipse.

Please create a new bug and attach a screenshot if possible.
Comment 8 Mik Kersten CLA 2009-10-14 11:48:52 EDT
We occasionally still bump into the problem of auto focusing being disruptive to new users, since it initially clears a a view they've always seen content in, and they can be unsure of the next step. The problem is that if we avoid focusing the view, we introduce a usability problem for all but the very new user, since novice users benefit from the auto-focusing facility.  In response to the new user case, we now automatically overly an icon and "Empty task context, unfocus or Alt+click" message on the focused view.  We also added a "Auto focus navigator views on task activation" preference to Preferences->Tasks->Context.  However, I'm concerned that's still not sufficient.

Here?s a documentation centric approach that we could take:
* On first task activation, we show a dialog that explains how focus works, and that facilities such as Open Type and Open Resource can be used.  Bridges would have to contribute sections to this dialog (eg, if you're working with Java code, use Open Type).
* In that same dialog, we allow the user to turn off the ?Auto focus?? preference, but recommend that they don?t.

Here's a more direct approach:
* When the view is empty, overlay hyperlinks to help populate it (eg, Open Resource, Alt+click equivalent hyperlink).  These hyperlinks will need to be specific to the view's content (eg, if it can show Java we add open type, if it can show resources we add Open Resource).
* Add a drop-down to the focus button to toggle ?Auto focus? for the view.
Comment 9 Tom Seidel CLA 2009-10-14 12:41:07 EDT
Wouldn't it make more sense not to turn on Auto-Focus in general if the context of the activated task is empty? - From my experience working with a focussed view makes only sense if the context has a specific "size", When starting with an empty context I always have to turn off the auto-focus and "Open Type" can't be used in every case, e.g while browsing through a task-affected package.

Maybe a preference would help in Tasks-->Context: "Do not auto focus navigation on empty task context". This would resolve IMHO the "new user problem" with the empty package explorer. Making the "size" of a context configurable would be also great, if a specific context size is reached the auto-focus will be activated automatically (with a small non-model notification).
Comment 10 Mik Kersten CLA 2009-10-15 13:30:22 EDT
Tom: That's a very interesting suggestion, thanks.  I wonder if it would be weird that when the user comes back to the task the view gets focused, whereas it wasn't before, and we haven't taken that disruptive first focus as an opportunity to teach them what's happening.  But this is a good third option that we should consider in the improving the design.
Comment 11 Endre Stølsvik CLA 2009-10-15 15:27:53 EDT
I personally still think you should consider MY suggestions (in this bug and the one referenced by that comment)! :-)

But seriously - I NEVER use the focused view, due to the reasons outlined - and now I am not that novice Mylyn user anymore, I feel. I don't find it helpful as it stands. I'd want a separate focused view, as I describe thoroughly in the mentioned comments. The only real usefulness for me with Mylyn is the Bugzilla integration, and that makes me kinda sad, given the huge potential I feel i see in the project. Why not just give me that extra view, then people could choose?!
Comment 12 Eclipse Webmaster CLA 2022-11-15 11:45:08 EST
Mylyn has been restructured, and our issue tracking has moved to GitHub [1].

We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub.

[1] https://github.com/orgs/eclipse-mylyn