Bugzilla – Full Text Bug Listing
| Summary: | Make Quick Access more appealing | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Mickael Istria <mistria> | ||||
| Component: | UI | Assignee: | Mickael Istria <mistria> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | akurtakov, aobuchow, Lars.Vogel, loskutov, ma.becker, nobody, paul-eclipse | ||||
| Version: | 4.12 | ||||||
| Target Milestone: | 4.14 M1 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=547755 https://git.eclipse.org/r/149494 https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=6dcbfad8f63dea2f2502d5c8fc74cd1941b3d6fb https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=f51fc0c51e9782c665dc8fee3128ec6edef4e9ea |
||||||
| Whiteboard: | |||||||
| Bug Depends on: | 500618, 547755, 553209 | ||||||
| Bug Blocks: | 551494 | ||||||
| Attachments: |
|
||||||
|
Description
Mickael Istria
I suggest to drop the text completely and only use an icon. That would be similar to other tools like IntelliJ and consistent with the plan to always use the centered dialog. An icon would IMO be almost like hideen, drown among the plethora of other icons. What about icon+textual link? (In reply to Mickael Istria from comment #2) > An icon would IMO be almost like hideen, drown among the plethora of other > icons. What about icon+textual link? I always ask my customer if they know "Quick Access" and what is does. And most don't know what it does. By using a Search icon it will be must easier to discover than with a strange text. If you can come up with a cool name for the textual link, we can try that but the field should not grow in size due to that. (In reply to Lars Vogel from comment #3) > If you can come up with a cool name for the textual link, we can try that > but the field should not grow in size due to that. What's the issue with that field actually getting bigger? Compare with text browsers for instance, the search takes quite some place, and it's worth it because it's bringing a lot of value. I think it's similar for Quick Access, we cannot really afford our users to not know about it, as it's one of the most productive workflow available. So giving it more space would IMO make the value more discoverable. I suggest a link like `🔍 Find anything... (Ctrl+3)` (In reply to Mickael Istria from comment #4) > (In reply to Lars Vogel from comment #3) > > If you can come up with a cool name for the textual link, we can try that > > but the field should not grow in size due to that. > > What's the issue with that field actually getting bigger? Because developer I have met told me that they hate this waste of screen. This also includes me and IIRC Max Rydahl Anderse, previously with Redhat. He ranted against the existing size several years ago via a bug report. I'm too lazy to search for it bug this rant was the reason why I implemented it that the field can be hidden via a right mouse click. So -2 for an increase of size from me. I suggest `🔍 ` or `🔍 Find ` and adding more info and the shortcut as tooltip. IIRC allow to hide Quick Access was a very popular bug report, before I fixed it. (In reply to Lars Vogel from comment #5) > Because developer I have met told me that they hate this waste of screen. It's indeed taking some space, and maybe we can offer ways to reduce this space, but the value of this feature is high enough to be worth it. And was this user actually using Ctrl+3? It's really something we need all users to use at least a few times a day, otherwise, it means we fail at making the most of value from it. Also, as you mention, there is already a way to hide it, we can keep this functionality to hide it for people who dislike it. > This also includes me and IIRC Max Rydahl Anderse, previously with Redhat. Max is still working for Red Hat ;) And I can also name a lot of other Red Hat people who say Quick Access is under-rated, mostly because no-one thinks it's interesting and knows Ctrl+3 as a shortcut. > He ranted against the existing size several years ago via a bug report. I'm > too lazy to search for it bug this rant was the reason why I implemented it > that the field can be hidden via a right mouse click. There is a lot of reluctance to change. People who know all the shortcuts already (or think they know) find any new usability feature useless. Indeed, it's not targeting them more than other ones, and even if they may take advantage of it, they're usually stuck to their established workflows. But the fact that some advanced people dislike more visible widgets is IMO not an argument to reject such idea. On this kind of topics, I trust newcomers more than long-time users who carry so lot of legacy workflows. > I suggest `🔍 ` or `🔍 Find ` and adding more info and the shortcut as > tooltip. No-one read tooltips ;) Also, just "Find" seems like a text search (Ctrl+F, Ctrl+H). We need to disambiguate that this is a search engine for *anything*. I strongly support raising the prominence of the text box. Maybe we could extend it once it has focus and make it bigger as people type. As for the text and icon I think calling it a 'Command center' or something to that effect might attract people to try what it means. +1 for making the Quick Access box better and easier to discover. -2 for making it bigger in my role as PMC member I'm you will find better ways to promote, for example a one time info popup or via tips of the day. (In reply to Lars Vogel from comment #9) > -2 for making it bigger in my role as PMC member To be, it's an abusive power to say -2 so early. There is still room for discussion, and you're kind of trying to shut down the debate just based on some opinion and without strong arguments. I'll make some research about UX recommendation of how to promote a feature in applications, and we'll see if we can come with something better, or if just giving it more space is the general idea. In worst case, I'll make such link with a preference to control the size, leave it to discrete and not discoverable in Platform, and will put an expanded version in EPP. (In reply to Lars Vogel from comment #9) > or example a one time info popup > or via tips of the day. So on one hand we try to get rid of pop-up, we see that Tip of the Day didn't really meet success, but you recommend using those to promote features (over just making them accessible and discoverable by themselves)? To give some reasons, why it should not become larger: - some developer (including me from time to time) use small resolutions like 1024x768 in which the field is already huge - the field is already huge and only a few people discover it, so making it larger seems like doing the thing which does not work only more of it - you think Quick Access is super special, but what stops the next developer who things another tool item is super special to make is also super big -I'm not aware of any other successful tools which uses this approach - Visual code is very successful. And its users use a initial not even visible command box, if we want to improve our usage we should better copy their approach, their menu frequently map into this box. So as suggested several times, lets start make useful things like adding a meaningful icon, use always the centered dialog, give it a meaningful text and see what happens. If after these improvements we still see a need to increase the size, we can discuss again. I might reconsider -2 once I see the low hanging UX improvements on which you are already working. Currently you seem to have the opinion "Quick Access must be super larger as nothing else will work" to which I say -2. (In reply to Lars Vogel from comment #12) > give it a meaningful text and see what happens. This is what we're discussing: adding and icon and having a meaningful text require to make it wider (by width of icon -at least 16px- + average char width * ($newText.length() - "Quick Access".length()- and you seem to totally reject that. > Currently you seem to have the opinion "Quick > Access must be super larger as nothing else will work" to which I say -2. Read the comments in the right order. In comment #0, I talk about more explicit label, icon and shortcut visible; that can't happen without allowing wider quick access. If you don't want it larger, we can fit and icon in, nor put a more explicit label, nor put the shortcut in. So we basically cannot improve anything you meantion. Here are my suggestions to make Quick Access easier to discover and more useful 1.) Add a search icon (that will already be huge IMHO) 2.) Find a better (and shorter) name than "Quick Access" 3.) Always use the centered dialog (Mickael already working on it) 4.) Add a menu entry to the Search Menu which maps to the field/dialog (Visual Code like behavior) Mickael, please add your additonal ones. I would suggest to work first on the non-controversal ones. (In reply to Lars Vogel from comment #14) > Here are my suggestions to make Quick Access easier to discover and more > useful > > 1.) Add a search icon (that will already be huge IMHO) > 2.) Find a better (and shorter) name than "Quick Access" > 3.) Always use the centered dialog (Mickael already working on it) > 4.) Add a menu entry to the Search Menu which maps to the field/dialog > (Visual Code like behavior) I'll gladly work on 1., but that will result in 16 more pixel wide. About 2., I think better and shorter together is not possible About 3. there is another bug on this topic (which is actually a major refactoring and that would reduce drastically maintenance effort of Quick Access About 4., I'm OK with it. Now, the final question: if we go for a centered dialog, it means it's better to abandon the text area in toolbar. So either we use a Link or a Button. Both are fine to me. (In reply to Mickael Istria from comment #15) > I'll gladly work on 1., but that will result in 16 more pixel wide. I'm fine with that, I'm against adding the shortcut in addition > About 2., I think better and shorter together is not possible "Find" is better IMHO > About 3. there is another bug on this topic (which is actually a major > refactoring and that would reduce drastically maintenance effort of Quick > Access > About 4., I'm OK with it. > Now, the final question: if we go for a centered dialog, it means it's > better to abandon the text area in toolbar. So either we use a Link or a > Button. Both are fine to me. If I can choose I think it should be similar to the perspective icon with text (right click on perspective icon -> show text). (In reply to Lars Vogel from comment #16) > (In reply to Mickael Istria from comment #15) > > > I'll gladly work on 1., but that will result in 16 more pixel wide. > > I'm fine with that, I'm against adding the shortcut in addition > > > About 2., I think better and shorter together is not possible > > "Find" is better IMHO Find is clearly wrong as one can execute any kind of command or even run/debug configurations so Find is misleading. > > > About 3. there is another bug on this topic (which is actually a major > > refactoring and that would reduce drastically maintenance effort of Quick > > Access > > About 4., I'm OK with it. > > > Now, the final question: if we go for a centered dialog, it means it's > > better to abandon the text area in toolbar. So either we use a Link or a > > Button. Both are fine to me. > > If I can choose I think it should be similar to the perspective icon with > text (right click on perspective icon -> show text). (In reply to Lars Vogel from comment #9) > +1 for making the Quick Access box better and easier to discover. > > -2 for making it bigger in my role as PMC member > > I'm you will find better ways to promote, for example a one time info popup > or via tips of the day. This "I'm PMC so I -2 you straight away" was unnecessary Lars. Let's not make it a habit of -2ing each others ideas on sight. I have done my own promoting of it [1][2] but the thing is that I believe we have a discoverability issue with this functionality. Once people see what it does they tend to use it more often. As I said I'm up for making it more prominent and that could mean a lot of things to be discussed - but they will be discussed, -2 or not. [1] https://twitter.com/EclipseJavaIDE/status/827148881511272449 [2] https://twitter.com/eclipsejavaide/status/889435990976323584 (In reply to Sopot Cela from comment #18) > This "I'm PMC so I -2 you straight away" was unnecessary Lars. Let's not > make it a habit of -2ing each others ideas on sight. See again https://bugs.eclipse.org/bugs/show_bug.cgi?id=550932#c12 (In reply to Lars Vogel from comment #12) > To give some reasons, why it should not become larger: > > - some developer (including me from time to time) use small resolutions like > 1024x768 in which the field is already huge > - the field is already huge and only a few people discover it, so making it > larger seems like doing the thing which does not work only more of it I disagree with denoting it as 'huge'. In my screen it takes less than 10% of the width. And to the second point - we're not proposing making it simply bigger but adding icons, changing the text to something that might make it bigger. > - you think Quick Access is super special, but what stops the next developer > who things another tool item is super special to make is also super big Nothing actually, feel free to file a bug to make the "Save all" icon bigger. I'll disagree but also resist others if they -2 you in this "I'm PMC, move aside" fashion. > -I'm not aware of any other successful tools which uses this approach Even if you think we should copy vscode these days (and I'm all for learning from other tools), Eclipse has done new things before it was cool. > - Visual code is very successful. And its users use a initial not even > visible command box, if we want to improve our usage we should better copy > their approach, their menu frequently map into this box. vscode does a lot of other things beside this, does it being successful at present mean we should copy all of them also? Completely disagree with this way of thinking. > > So as suggested several times, lets start make useful things like adding a > meaningful icon, use always the centered dialog, give it a meaningful text > and see what happens. If after these improvements we still see a need to > increase the size, we can discuss again. > > I might reconsider -2 once I see the low hanging UX improvements on which > you are already working. Currently you seem to have the opinion "Quick > Access must be super larger as nothing else will work" to which I say -2. And you currently seem to feel very strongly about making any sort of change to the text box that could cause its increase in size - which is fine. What is not fine is shuffling your "PMC badge" in our faces to shut this down as if we're proposing a sacrilegious change. If you ask me, I'm for getting rid of the toolbar altogether actually, but that's a discussion for another day. (In reply to Sopot Cela from comment #20) > I disagree with denoting it as 'huge'. Lets agree, that we disagree. > copy all of them also? Completely disagree with this way of thinking That is not what I said, but we should learn from it. > And you currently seem to feel very strongly about making any sort of change > to the text box that could cause its increase in size - which is fine. What > is not fine is shuffling your "PMC badge" in our faces to shut this down as > if we're proposing a sacrilegious change. Valid point, sorry for that. I normal -1 or -2 should have been sufficient. To explain: I felt that Mickael felt super strong about making it big so I felt that I have to make a strong statement. Lots of feelings here. :-) I definitely have the position of "Strong opinion, weakly hold" so is I see that the other improvements do not work, I'm open to discuss other options. Maybe both positions could be satisfied if the text box can automatically resize to some extend. Small screen or full toolbar -> small text box. Empty space -> larger text box. But I assume this is not possible at the moment and maybe hard to add. Created attachment 279836 [details]
Example how code promotes important features
See attachment as an example how code promotes important features
Just food for thought.
(In reply to Lars Vogel from comment #23) > See attachment as an example how code promotes important features > Just food for thought. I don't see how this is different or better from the welcome page, which just get closed by users whenever it prompts. Frankly, I know a lot of hype is on VSCode, but I rarely find it more discoverable than Eclipse IDE: it's about impossible to tweak it or use it efficiently without spending some time reading documentation about what are the shortcuts, which files should be edited and how... So this is now a button, with an icon. I'm not so happy about the icon. What do you think about using the magic wand that we usually see in Help > Tips and Tricks ? (In reply to Mickael Istria from comment #25) > So this is now a button, with an icon. > I'm not so happy about the icon. What do you think about using the magic > wand that we usually see in Help > Tips and Tricks ? Matthias, can you help with the icon design? (In reply to Lars Vogel from comment #26) > (In reply to Mickael Istria from comment #25) > > So this is now a button, with an icon. > > I'm not so happy about the icon. What do you think about using the magic > > wand that we usually see in Help > Tips and Tricks ? > > Matthias, can you help with the icon design? I think I'll just update to the magic wand for now, and then we'll use another icon when there is some better proposal. One important concept the icon has to illustrate is that this Quick Access can find *anything*, it's not a text search but more a "workflow" search as typing in it will allow usually to go to someplace else or trigger an action. New Gerrit change created: https://git.eclipse.org/r/149494 Gerrit change https://git.eclipse.org/r/149494 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=6dcbfad8f63dea2f2502d5c8fc74cd1941b3d6fb I'm closing this one since 1. an icon is added 2. a more explicit label is used 3. we moved to a standard button 4. we rely on a standard dialog 5. Hide is available on right-click and feature-wise we're on par with the previous text field, with some extra sugar, and this didn't add any extra required click or keystroke. Further improvements are better tracked in separate ticket (feel free to add me as CC). Thanks Mickael for improving this. As user I already love it. For the new icon feedback see bug 553209. Interestingly, I don't see the gerrit that changed this icon here linked, same for the commit, so adding it manually: https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=f51fc0c51e9782c665dc8fee3128ec6edef4e9ea |