Community
Participate
Working Groups
From my experience, no this is not intuitive to our users. Quick Access is not something the user sees in other applications. In the year I train new and experienced Eclipse plug-in and RCP developers, my impression is that only a small part of them, knew about the purpose of this field. This was also try to long time Eclipse users. Find / Search icons are usually used to describe such a field. See for example IntelliJ screenshot on their main page: https://www.jetbrains.com/idea/ As search is already used for other purpose in Eclipse, I suggest "Find". Best solution IMHO would be a search or find icon without text.
I didn't and it took me quite a few releases to actually try and discover that feature. Maybe "Quick command" would be more inviting/clearer?
(In reply to Lars Vogel from comment #1) > As search is already used for other purpose in Eclipse, I suggest "Find". I think that is just a synonym and using it would actually be confusing. > > Best solution IMHO would be a search or find icon without text. I disagree that an icon would be better (icons are even more likely to be overlooked, and how should the icon look like so it does not get confused with "search"?)
(In reply to Lars Vogel from comment #1) > Find / Search icons are usually used to describe such a field. See for > example IntelliJ screenshot on their main page: > https://www.jetbrains.com/idea/ IntelliJ's "magnifier"-icon in the toolbar open their "unified" search, which searches content AND commands.
(In reply to Till Brychcy from comment #4) > (In reply to Lars Vogel from comment #1) > > Find / Search icons are usually used to describe such a field. See for > > example IntelliJ screenshot on their main page: > > https://www.jetbrains.com/idea/ > > IntelliJ's "magnifier"-icon in the toolbar open their "unified" search, > which searches content AND commands. IntelliJ's "magnifier"-icon does not search content at least not then I used it. I used to make fun about IntelliJ that "search everywhere" does not do a text search and demonstrated that by having an editor open with "Some Text" in it, and demonstrating that "Search everywhere" shows no results if I search for "Some Text".
(In reply to Lars Vogel from comment #5) > IntelliJ's "magnifier"-icon does not search content at least not then I used > it. I used to make fun about IntelliJ that "search everywhere" does not do a > text search and demonstrated that by having an editor open with "Some Text" > in it, and demonstrating that "Search everywhere" shows no results if I > search for "Some Text". You're right, it just search in commands, classes, filenames and symbols, but because of "symbols" (last one being the reason i confused it, I rarely use it). Still I'm right, too - it does way more than a search only commands.
(In reply to Till Brychcy from comment #6) > it does way more than a search only commands. Quick Access does also more than a search only for commands, it also allows to switch to already open editors. And Mickael is in process to allowing to extend it via arbitrary extensions.
(In reply to Lars Vogel from comment #7) > Quick Access does also more than a search only for commands, it also allows > to switch to already open editors. And Mickael is in process to allowing to > extend it via arbitrary extension I'd call that a "command" from the user's POV.
The QuickAccessProviders have a name that tells what they're able to search; we could reuse the name of the main ones. Something like "🔍 Commands, Preferences...".
I come to like the term action for the Quick Access content: a user hits it to *do* something (find a command to execute, a piece of code or a view to jump to...), so I'd suggest something like "Find actions...". What do you think?
(In reply to Mickael Istria from comment #10) > I come to like the term action for the Quick Access content: a user hits it > to *do* something (find a command to execute, a piece of code or a view to > jump to...), so I'd suggest something like "Find actions...". > What do you think? +1
New Gerrit change created: https://git.eclipse.org/r/149483
Gerrit change https://git.eclipse.org/r/149483 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=6e2d0be6201eb582cb0658d1aa98cd24710f1a27
So it's currently "Find Actions..." Anyone feel free to reopen with some better proposals, we can still easily change it for 4.14.
New Gerrit change created: https://git.eclipse.org/r/149501
Gerrit change https://git.eclipse.org/r/149501 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=84b2a293678617e8523b21ff342f77732cc9d815
(In reply to Mickael Istria from comment #14) > So it's currently "Find Actions..." > Anyone feel free to reopen with some better proposals, we can still easily > change it for 4.14. I don't like the text "Find Actions" text in the text box. What's wrong with "Quick Access". I have the feeling that "Quick Access" together with the proposed Icon would be a good solution - it would help new users to understand what the field is for and experienced eclipse user still will still recognise it.
(In reply to Matthias Becker from comment #17) > (In reply to Mickael Istria from comment #14) > > So it's currently "Find Actions..." > > Anyone feel free to reopen with some better proposals, we can still easily > > change it for 4.14. > > I don't like the text "Find Actions" text in the text box. What's wrong with > "Quick Access". I have the feeling that "Quick Access" together with the > proposed Icon would be a good solution - it would help new users to > understand what the field is for and experienced eclipse user still will > still recognise it. Yes, I brought this up on cross projects as well. https://www.eclipse.org/lists/cross-project-issues-dev/msg17091.html I just don't like "Find Actions" any better than "Quick Access" because the former suggests that I can search/look for "Action"s, but what are "Actions"? Why would I need to Find one? "Commands" might be a better fit with existing terminology in the IDE, but not all these things are really Commands, though one can always sort of think of them all Command-like shortcuts. If we're going to replace something truly descriptive of the functionality, i.e., "Quick Access", might "Shortcuts" be better? It's shorter... Also, I think the icon doesn't look nice. It reminds me too much of a creation icon with a magic wizard wand. But I'm not graphic designer so I can't make something nicer. We just want something that screams "click me!".
See comment #10 about why "Find Actions" seemed acceptable and easy enough to understand. It actually is the same idea a your > but not all these things are really > Commands, though one can always sort of think of them all Command-like > shortcuts. so: > "Commands" might be a better fit with existing terminology in the IDE What is a command in the *user* terminology? If it appears the term isn't too strongly used, we can try it. (In reply to Ed Merks from comment #18) > I just don't like "Find Actions" any better than "Quick Access" because the > former suggests that I can search/look for "Action"s, but what are > "Actions"? actions is used with just the meaning of "doing something" here. > If we're going to replace something truly descriptive of the functionality, > i.e., "Quick Access", might "Shortcuts" be better? It's shorter... I usually understand "keybinding" when I head "shortcut". Is it just me? > Why would I need to Find one? Maybe we can just get rid of "Find" and use "Commands..." or "Actions..." ? > Also, I think the icon doesn't look nice. It reminds me too much of a > creation icon with a magic wizard wand. Magic wand can do much more than creating things: they can more or less teleport, move things, transform, create, delete... in one or a single work. That's the reason why I found it appropriate here. I'd actually challenge more the usage of the magic wand for just "creating" things. A cracked/opening egg would fit better for "creation" IMO. But still, although I think the magic want captures the idea of the feature, we can still discuss other proposals. I just find the magic wand really a good match here and don't feel able to make better proposals (as opposed to the label for which I'm less enthusiast).
As I was thinking of gold old M-x (yep, prior to Eclipse my IDE was emacs :)) -- read: meta-x -- why not say "Meta Search"?
Ed, the magic wand will be replaced, we already have a Gerrit somewhere for it. I can search next week for it, if you don't find it.
The term Command is used in General -> Keys, it is one of the things one actually finds in the dialog, and it is the first thing mentioned in the unchanged hover text. Not only that, the whole dialog does actually behave a bit like a not-so-short key binding sequence, i.e., type Ctrl-3+<plus some more keys>+Enter as kind of a key binding short-cut for hunting down the same thing as is available elsewhere in the UI. So indeed the dialog behaves a lot like a key binding "shortcut" where a familiar sequence of key strokes acts as a quick way to invoke a command or as a shortcut to do something for which there is no command, but for which there could be one, in principle. All this is to say that personally I think of this dialog as a shortcut for a longer sequence of interactions for achieving the same result. That's how I personally tend to use it, i.e., type the name of a view in order to open it. I like your idea of removing Find and I believe that given it brings up a dialog that technically it should end with... In the end, I think both Find/Search will lead people to believe the button is related to finding/searching for *content*, hence I see the point of Stephan's comment about "meta". I'm not sure I like Meta Search" but it certainly captures the essence... I'm glad to hear about an image improvement. I think the + symbol is too closely associated with "New" already and I cannot properly perceive the tiny light at the end of the "wand", specially given it's so close to the other yellow things.
I found "Quick Access" just perfect and at my various customers I always noticed that they're well aware of it. Just the Ctrl+3 binding wasn't generally known.
(In reply to Eike Stepper from comment #23) > I found "Quick Access" just perfect and at my various customers I always > noticed that they're well aware of it. Just the Ctrl+3 binding wasn't > generally known. Feedback we get on Twitter whenever we mentuon it with the @EclipseJavaIDE account is that there are always a significant amount of people who never tried it nor know the shortcut.
I proposed to find a better name than "Quick Access", but the new one, "Find Actions" is definitely worse!
I'm getting exceptions with the new code. org.eclipse.swt.SWTException: Widget is disposed at org.eclipse.swt.SWT.error(SWT.java:4711) at org.eclipse.swt.SWT.error(SWT.java:4626) at org.eclipse.swt.SWT.error(SWT.java:4597) at org.eclipse.swt.widgets.Widget.error(Widget.java:452) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:351) at org.eclipse.swt.widgets.Control.removeKeyListener(Control.java:2713) at org.eclipse.ui.internal.quickaccess.QuickAccessDialog.close(QuickAccessDialog.java:298) at org.eclipse.jface.dialogs.PopupDialog.lambda$4(PopupDialog.java:650) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:185) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3963) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3590) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1160) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1049) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155) at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:660) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:559) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:150) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:137) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:107) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:660) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:597) at org.eclipse.equinox.launcher.Main.run(Main.java:1468) at org.eclipse.equinox.launcher.Main.main(Main.java:1441) That's because close is called twice. The first time explicitly by the mouseUp handler: QuickAccessDialog.close() line: 298 QuickAccessDialog$1.doClose() line: 160 QuickAccessDialog$1(QuickAccessContents).handleSelection() line: 593 QuickAccessContents.access$4(QuickAccessContents) line: 585 QuickAccessContents$7.mouseUp(MouseEvent) line: 786 The second time but the stack trace leading to the widget disposed error.
New Gerrit change created: https://git.eclipse.org/r/150366
(In reply to Dani Megert from comment #25) > I proposed to find a better name than "Quick Access", but the new one, "Find > Actions" is definitely worse! Again, that is really subjective. The issue with "Quick Access" is that, as an uneducated end-user: * "Access" what? * "Quick" doesn't bring any payload So the name doesn't carry much of the value proposal of the feature. "Find actions" tells a bit more: why should I click it? To find an action. To me, the current name have more payload and increase usability over the former one that wasn't as explicit. However, it's indeed not perfect, and I'm more and more moving, late after several other commenters, to the idea that "commands" is a better term than "actions". So it could be "Find commands", and as discussed, the "Find" may be unnecessary as people can infer this from the icon or some ... suffix. So to me, at the moment, the best proposal could be to just use "[Icon] Commands...".
(In reply to Ed Merks from comment #26) > I'm getting exceptions with the new code. Please try to keep discussions focused for easier resolution and use dedicated bug for independent "branches". There is already bug 551192 about this.
(In reply to Mickael Istria from comment #28) > (In reply to Dani Megert from comment #25) > > I proposed to find a better name than "Quick Access", but the new one, "Find > > Actions" is definitely worse! > > Again, that is really subjective. The issue with "Quick Access" is that, as > an uneducated end-user: > * "Access" what? > * "Quick" doesn't bring any payload > So the name doesn't carry much of the value proposal of the feature. > > "Find actions" tells a bit more: why should I click it? To find an action. > To me, the current name have more payload and increase usability over the > former one that wasn't as explicit. > > However, it's indeed not perfect, and I'm more and more moving, late after > several other commenters, to the idea that "commands" is a better term than > "actions". > So it could be "Find commands", and as discussed, the "Find" may be > unnecessary as people can infer this from the icon or some ... suffix. > So to me, at the moment, the best proposal could be to just use "[Icon] > Commands...". I still prefer "Actions" over Commands, seems like this is also the term VScode uses. https://code.visualstudio.com/docs/getstarted/tips-and-tricks And as a user I don't think the term "Commands" rings a bell.
(In reply to Mickael Istria from comment #29) > Please try to keep discussions focused for easier resolution and use > dedicated bug for independent "branches". > There is already bug 551192 about this. Sorry, the revision history just pointed back at the commit for this Buzilla, which was still open... Thanks for pointing at the satellite bug.
(In reply to Lars Vogel from comment #30) > I still prefer "Actions" over Commands, seems like this is also the term > VScode uses. https://code.visualstudio.com/docs/getstarted/tips-and-tricks According to that page, vscode calls it actually "Command Palette"... https://code.visualstudio.com/docs/getstarted/tips-and-tricks#_command-palette (BTW: I think in Emacs it corresponds best to M-x, which is C-h c describes as: "M-x runs the command execute-extended-command")
(In reply to Mickael Istria from comment #28) > (In reply to Dani Megert from comment #25) > > I proposed to find a better name than "Quick Access", but the new one, "Find > > Actions" is definitely worse! > > Again, that is really subjective. The issue with "Quick Access" is that, as > an uneducated end-user: > * "Access" what? > * "Quick" doesn't bring any payload > So the name doesn't carry much of the value proposal of the feature. You don't have to tell me that. I opened this bug ;-). "Commands" is a bit better but also not intuitive enough in my opinion. Maybe "Find Features"?
(In reply to Dani Megert from comment #33) > Maybe "Find Features"? -1 for that suggestion For completeness here is my feeling +0 for commands, +1 for keeping "Find Actions", +1,5 for using only "Find"
(In reply to Lars Vogel from comment #34) > (In reply to Dani Megert from comment #33) > > Maybe "Find Features"? > > -1 for that suggestion > > For completeness here is my feeling +0 for commands, +1 for keeping "Find > Actions", +1,5 for using only "Find" Lars, "Find" was just what I was about to suggest :-). So +2.
(In reply to Dani Megert from comment #35) > (In reply to Lars Vogel from comment #34) > > (In reply to Dani Megert from comment #33) > > > Maybe "Find Features"? > > > > -1 for that suggestion > > > > For completeness here is my feeling +0 for commands, +1 for keeping "Find > > Actions", +1,5 for using only "Find" > Lars, "Find" was just what I was about to suggest :-). So +2. And maybe use a magnifier as icon.
(In reply to Lars Vogel from comment #34) > (In reply to Dani Megert from comment #33) > > Maybe "Find Features"? > > -1 for that suggestion > > For completeness here is my feeling +0 for commands, +1 for keeping "Find > Actions", +1,5 for using only "Find" Do we get to add them up? :-P -3 Find Features - confusing when my workspace is full of features -2 Find - makes people think it's Ctrl-F and finds content -1 Find Actions - different from what's familiar but not better -0 Quick Access - familiar and describes what it does, but apparently not "inviting" +1 Find Commands... - conceptually it is "extended" key binding behavior +2 Shortcuts... - because my ideas are the best ones. :-P +2 Commands... - it's shorter and still to the point
(In reply to Ed Merks from comment #37) > -2 Find - makes people think it's Ctrl-F and finds content Very soon, it will also find contents by making the Quick Text Search results directly available there.
(In reply to Dani Megert from comment #36) > And maybe use a magnifier as icon. See Bug 551325 for the new icon discussion. The plan is to use a icon similar to the Mac finder icon.
(In reply to Mickael Istria from comment #38) > (In reply to Ed Merks from comment #37) > > -2 Find - makes people think it's Ctrl-F and finds content > > Very soon, it will also find contents by making the Quick Text Search > results directly available there. It's hard to name a moving target. So the idea as that during this release cycle, somehow you'll embed the current Quick Search dialog results in this one "unified" dialog?
(In reply to Ed Merks from comment #40) > It's hard to name a moving target. So the idea as that during this release > cycle, somehow you'll embed the current Quick Search dialog results in this > one "unified" dialog? Yes, that's one of my goals (and the current state makes me optimistic about the chance of this happening this week).
My personal theory of why some people don't use this feature: They simply don't expect such a thing to exist. They think in boxes: if I need a view I go to Window > Views > ... > ... >....., if I need X I search in box X. We should try to encourage people to think bigger & across boxes. So if we stick to technical terms, "Find" sounds like down playing rather than "think big". At least "Find Anything" could give a hint. Or - repeating my proposal from above - "Meta Search". But maybe even that is still too small. What names will signal to people that they can ask any question, raise any request? google, siri, alexa ... since we shouldn't copy one of these names, here comes my almost random set of proposals: Ask Dave Ask Erich Ask Dani Ask Ed ... ;p Q: "What's a fast way to do X in Eclipse?" A: "Have you asked Erich?"
Most important IMHO is to use a good icon, people seem to have no problem with the "Finder" icon on Mac.
(In reply to Ed Merks from comment #37) > +2 Shortcuts... - because my ideas are the best ones. :-P Conceptually great, but tied to keyboard shortcuts already (is this the place where I configure shortcuts?), but we could call it Fast Lane who doesn't want to go there?
(In reply to Lars Vogel from comment #39) > (In reply to Dani Megert from comment #36) > > And maybe use a magnifier as icon. > > See Bug 551325 for the new icon discussion. The plan is to use a icon > similar to the Mac finder icon. Hey guys. What do you think about the "magnifier" icon as propose in Bug 551325?
(In reply to Matthias Becker from comment #45) > Hey guys. What do you think about the "magnifier" icon as propose in Bug > 551325? No objection from me, I actually used the magnifier emoji at the beginning (until I found the magic wand cooler for this feature).
(In reply to Matthias Becker from comment #45) > (In reply to Lars Vogel from comment #39) > > (In reply to Dani Megert from comment #36) > > > And maybe use a magnifier as icon. > > > > See Bug 551325 for the new icon discussion. The plan is to use a icon > > similar to the Mac finder icon. > > Hey guys. What do you think about the "magnifier" icon as propose in Bug > 551325? It's quite simplistic graphically, but I think that does capture the underlying concept.
(In reply to Ed Merks from comment #47) > It's quite simplistic graphically, but I think that does capture the > underlying concept. That was by intension. ;-)
After the icon discussion has concluded, may I remind you that this is the "Retitle" bug?
Removed milestone as no one reacted to https://www.eclipse.org/lists/eclipse-dev/msg11217.html.
What if we stick to "Quick search" first and only change it in one or two releases. If it was changed I'm afraid users might think "where is the quick search gone?". Too many things changes: 1. Text field is a button now. 2. It has an icon. 3. it is renamed from Quick Search to something else (maybe find actions). So my suggestion would be, to change only 1. and 2. and stick to "Quick Search" until further notice. In one or two releases it might be changed to something else. I've heard that text search might be added to the quick search as well. Today quick search cannot only execute commands but also opens pref pages. So at one point in time it might search the whole eclipse (similar to what spotlight on mac does or the omnibar in chrome). So what about "Search Eclipse" or something similar as a text?
(In reply to Matthias Becker from comment #17) > I don't like the text "Find Actions" text in the text box. What's wrong with > "Quick Access". I have the feeling that "Quick Access" together with the > proposed Icon would be a good solution - it would help new users to > understand what the field is for and experienced eclipse user still will > still recognise it. Just to rephrase this again: I have the feeling we are changing too much at one time. We do: - Change from an input field to a button - Change the text - Add an icon - Change look and position of the popup up that comes up We agree that a lot of user's don't know what "Quick Access" can do. But we also don't know if the new version is better. But what I am quite sure is the following: Existing user of Eclipse that *know* Quick Access will miss it and won't see that "Find Actions" is the replacement for it because everything (4 aspects) are different. They don't have the possibility to recognize that new one as replacement for the old. I would propose a phased approach: - First change to the input field and also change to the new dialog look and feel. - Add a new icon (I propose a simplistic magnifier icon) *but keep* the text "Quick Access". Via this users that know "Quick access" have the possibility to lear that this is now a button with an icon. - Some releases later we remove (or change) the text of that. Again the user have the possibility to recognize this again because the icons is the same. So we reach the same target but we give user's time to adapt. What do you thing about this proposal?
(In reply to Marcus Höpfner from comment #51) > So my suggestion would be, to change only 1. and 2. and stick to "Quick > Search" until further notice. I don't see that value in keeping a label that seemed inefficient for many users. As we're changing a few things, we can also change the label and users who got used to former Quick Access will still identify it because of the position on the toolbar. > So what about "Search Eclipse" or something similar as a text? I like it.
(In reply to Mickael Istria from comment #53) > (In reply to Marcus Höpfner from comment #51) > > So my suggestion would be, to change only 1. and 2. and stick to "Quick > > Search" until further notice. > As we're changing a few things, we can also change the label and users who > got used to former Quick Access will still identify it because of the > position on the toolbar. I doubt that.
(In reply to Matthias Becker from comment #52) > - Some releases later we remove (or change) the text of that. Again the user > have the possibility to recognize this again because the icons is the same. +1. That sounds very reasonable!
IMHO the discussion should be about a term and icon that make clear what the feature is about. As long as it is precise, we don't have to care much about the fact that it gets changed. Ed ranked a couple of proposals in comment #37 > -3 Find Features - confusing when my workspace is full of features > -2 Find - makes people think it's Ctrl-F and finds content > -1 Find Actions - different from what's familiar but not better I share his assessment for the first three > -0 Quick Access - familiar and describes what it does, but apparently not "inviting" It describes what it does, but you can't derive its function from the label. > +1 Find Commands... - conceptually it is "extended" key binding behavior > +2 Shortcuts... - because my ideas are the best ones. :-P > +2 Commands... - it's shorter and still to the point All of the last three don't nail exactly down, what the feature really is about. Trigger something/a command, open a view, jump to a preference. I like "Search Eclipse" proposed by Marcus Hoepfner in comment #51. It searches Eclipse (commands, preferences, views, ...) and in the result list you can chose from a couple of options to interact with it. Unfortunately it will become imprecise, as soon as the Quick Text Search results become part of the search result (announced by Mickael Istria in comment #38).
(In reply to Felix Otto from comment #56) > Unfortunately it will become imprecise, as soon as the Quick Text Search > results become part of the search result (announced by Mickael Istria in > comment #38). Because the Quick Access is now extensible, we don't really control what's going to get in. So we need an imprecise enough term ;) I find "Search %productName" is good and imprecise enough to fit. However, it would then be "Search Eclipse SDK" or "Search Eclipse IDE" or "Search My RCP application". It's not a bad think IMO.
(In reply to Mickael Istria from comment #57) > (In reply to Felix Otto from comment #56) > > Unfortunately it will become imprecise, as soon as the Quick Text Search > > results become part of the search result (announced by Mickael Istria in > > comment #38). > > Because the Quick Access is now extensible, we don't really control what's > going to get in. So we need an imprecise enough term ;) > I find "Search %productName" is good and imprecise enough to fit. However, > it would then be "Search Eclipse SDK" or "Search Eclipse IDE" or "Search My > RCP application". It's not a bad think IMO. No, please, please don't "brand" the button! What's searched doesn't depend strictly on the brand... An "Omni search that's generally extensible so could/might/will search all kinds of things no person might ever expect and might also maybe include content search as well as arbitrary other meta things in addition to views, command, and so on" just isn't going to be well reflected by a brand name. Then just call it search because after all, the base package is just a starting point that apparently can be extended by the various contributions installed later that will/might/could contribute to the dialogs's results. I get a bad feeling about the arbitrariness of all this. As others have mentioned, I hope the users who already use this will recognize the new replacement and won't end up shaking their heads wondering "what are these people thinking"?
(In reply to Ed Merks from comment #58) > An "Omni search that's generally extensible so could/might/will search all > kinds of things no person might ever expect and might also maybe include > content search as well as arbitrary other meta things in addition to views, > command, and so on" just isn't going to be well reflected by a brand name. > Then just call it search because after all, the base package is just a > starting point that apparently can be extended by the various contributions > installed later that will/might/could contribute to the dialogs's results. That a good point. Adding the brand adds no payload. > As others have mentioned, I hope the users who already use this will > recognize the new replacement and won't end up shaking their heads wondering > "what are these people thinking"? There will always be someone to complain about any change, we cannot fully avoid that. We need to find a trade-off that doesn't break existing workflow and encourage new users. If the cost of 30% growth in usage of Quick Access is a few people shaking their heads but still using it, it's still a significant win. To get back to the name, then in the end, Quick Access allows to Find *anything*, so as suggested by Stephan in comment #42, "Find anything" can be bith complete and imprecise enough.
In my favorite browser (Firefox), the field (a text field) is labeled Search. It has an icon that's a "copy of the proposed icon". If we're going to change everything (with no statically sound basis from which to judge, and with no statistical basis from which to judge in the future that it's an actual improvement), perhaps "Search..." is the most general, least specific, and tersest choice. But I would hope that along with this change that the functionality actually in the dialog (hence the ...) includes content search.
(In reply to Ed Merks from comment #60) > perhaps "Search..." is the most > general, least specific, and tersest choice. Yes, it is, but it's also already used for the Ctrl+H Search Action (ie search for specific objects in a reduced scope), so there is a risk that people who see this Search... do not expect it to do more than Ctrl+H.
(In reply to Ed Merks from comment #60) > If we're going to change everything (with no statically sound basis from > which to judge, and with no statistical basis from which to judge in the > future that it's an actual improvement), perhaps "Search..." is the most > general, least specific, and tersest choice. So we see that we are really not sure what is better then "Quick Access". Why don't we start small like it's proposed in comment 51 and 52 and first only add the icon and keep "Quick Access". Via this approach existing users have the time to adapt to the change and we have more time to think about a better text. And maybe we come to the conclusion that we may be even don't need a text. On macOS the Spotlight Menu Entry also only has a magnifier glass and no text.
(In reply to Mickael Istria from comment #61) > (In reply to Ed Merks from comment #60) > > perhaps "Search..." is the most > > general, least specific, and tersest choice. > > Yes, it is, but it's also already used for the Ctrl+H Search Action (ie > search for specific objects in a reduced scope), so there is a risk that > people who see this Search... do not expect it to do more than Ctrl+H. Can we use "Search Actions"?
(In reply to Lars Vogel from comment #63) > Can we use "Search Actions"? In latest build, it also search for text in files: https://www.eclipse.org/eclipse/news/4.14/platform.php#quick-text-search-in-Find-Actions
I think "Quick Access" is definitely worse than Find Actions or Search Actions. Let's assume that the entry would not be called Quick Access in the past. Would anyone propose Quick Access as the new label? IMHO the only reason someone thinks this is a good label is that we are used to it, IMHO it has no meaning for new users.
(In reply to Mickael Istria from comment #64) > (In reply to Lars Vogel from comment #63) > > Can we use "Search Actions"? > > In latest build, it also search for text in files: > https://www.eclipse.org/eclipse/news/4.14/platform.php#quick-text-search-in- > Find-Actions Cool. So Search seems fitting again. We can relabel the other entry to Search Text or something similar.
(In reply to Lars Vogel from comment #65) > I think "Quick Access" is definitely worse than Find Actions or Search > Actions. > > Let's assume that the entry would not be called Quick Access in the past. > Would anyone propose Quick Access as the new label? IMHO the only reason > someone thinks this is a good label is that we are used to it, IMHO it has > no meaning for new users. I don't propose to keep Quick Access forever. I just want to go ahead in phases and not to change too much at once. Co-workers of me how even know that the quick access war changes did not realize that the new thing is the replacement. I fear we don't progress in the usage of quick acess much and will loose existing users if we change too many things at once.
I don't agree that Quick Access is meaningless. It's definitely used to quickly access things that are otherwise much harder to find. And to belabor the point, it's familiar after so many years... Also, if you put a word after "Search/Find" then it sounds like we're searching/finding those types of things, i.e., actions. What are actions? And when the dialog does actual content search, as it now does, is that result an action? I don't think so. Did anyone previously suggest "Omni Search"? If one puts a word before search it says something about the type of search rather than what is being searched. Was "Quick Search" rejected? It's least is 50% familiar. :-P And the dialog apparently includes quick content search results too...
we mix up two things here: - the final name - to rename now or later Can we agree and an approach for the second one? Does body have problems with first keeping quick access and only adding the new search icon?
(In reply to Matthias Becker from comment #69) > Does body have problems > with first keeping quick access and only adding the new search icon? I'd rather see everything changed at once and this topic closed. See reasoning on comment #59 why I think slowing down the change is not the most interesting problem/value we can work on. I think brainstorming on the new name is more important. If we find something good enough that satisfies all of us, then we should just adopt it instead of delaying the delivery of associated value. If by the end of M3 we're still hesitating, then reverting to "Quick Access" until we find something better may be the safest choice.
(In reply to Matthias Becker from comment #69) > we mix up two things here: > - the final name > - to rename now or later +1 for two phases: keep name for now, revisit later. Why? - let's not unnecessarily annoy people who are used to the status quo. Any percentage of users who perceive that the feature has gone missing means that we have failed. - we don't have an agreement yet for a name that has all desired properties: it should be short, self-explaining, and motivate people to actually try and use it etc...
(In reply to Mickael Istria from comment #70) > (In reply to Matthias Becker from comment #69) > instead of delaying the delivery of associated value. If by the end of M3 > we're still hesitating, then reverting to "Quick Access" until we find > something better may be the safest choice. Let's see it the other way around. Why did we even change it in the first place even though we don't have an agreement?
(In reply to Matthias Becker from comment #72) > Let's see it the other way around. Why did we even change it in the first > place even though we don't have an agreement? There was enough agreement back then from voiced opinions. And changing things brings the discussion one step further: people now share their opinions and proposals instead of remaining silent. Disrupting is a collaboration tool ;)
(In reply to Stephan Herrmann from comment #71) > (In reply to Matthias Becker from comment #69) > > we mix up two things here: > > - the final name > > - to rename now or later > > +1 for two phases: keep name for now, revisit later. > > Why? > > - let's not unnecessarily annoy people who are used to the status quo. Any > percentage of users who perceive that the feature has gone missing means > that we have failed. > > - we don't have an agreement yet for a name that has all desired properties: > it should be short, self-explaining, and motivate people to actually try and > use it etc... +1 also for two phases. The above statements summarize it perfectly.
FYI - Dani suggested that we hide the text by default, so the naming is IMHO not so critical anymore. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=551324#c4
(In reply to Lars Vogel from comment #75) > FYI - Dani suggested that we hide the text by default, so the naming is IMHO > not so critical anymore. See > https://bugs.eclipse.org/bugs/show_bug.cgi?id=551324#c4 I would even propose to remove the text completely (as the final solution). But still I would propose to use a grace-period where we keep the old text next to the new icon so that existing users can lear the new thing.
And now I also know where this "Find..." comes from. It comes form Eclipse Theia. They have a "Find commands" menu entry to open their command palette. But that is something different. There you really look for "commands". The Quick Access is much broader. "Quick Access" is much more comparable with the "Spotlight Search" on macOS. And there the pattern of the text is "<something> Search" (where <something> == Sportlight) and not "Search <something>". So "Quick Access" uses the same pattern.
Hey, guys, what an annoying waste of time here. "Quick Access" was perfect because it provides access to a variety of things, and "Find actions" is not only wrong but also messed up the title case in the dialog title. Please revert that stupid change.
(In reply to Stefan Mücke from comment #78) > what an annoying waste of time here. Totally agree with this. Attention to detail is important but this entire thing here is ridiculous. I also liked Quick Access or the proposed Search Eclipse (maybe inspired by Search Google).
(In reply to Stefan Mücke from comment #78) > messed up the title case in the dialog title. I uploaded a Gerrit to fix that.
New Gerrit change created: https://git.eclipse.org/r/152213
(In reply to Stefan Mücke from comment #78) > Hey, guys, what an annoying waste of time here. No one is entitled to decide to judge how unrelated people should spend their time and what's a waste of their them or not. > "Quick Access" was perfect because it provides access to a variety of things Sure, the name was good, but many of us have experienced that new users typically wouldn't try this feature, and have thought the label could be a cause. So although the name was fine, it wasn't appealing enough to many users. Also, as it has become a button, it's usually better that the label starts with a Verb (we already linked to some related UX recommendations from multiple sources about it) > Please revert that stupid change. Your comment would have been taken more seriously if you didn't ruin it with such negative parts.
Gerrit change https://git.eclipse.org/r/152213 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=aac63d10ac3fab0ea5097501e0850ede86487ff8
(In reply to Mickael Istria from comment #82) > (In reply to Stefan Mücke from comment #78) > > Hey, guys, what an annoying waste of time here. > > No one is entitled to decide to judge how unrelated people should spend > their time and what's a waste of their them or not. > Indeed not, but everyone tends to have an opinion they tend to express it. It could be done with more sensitivity. I had much the same feeling, but saying "hey, aren't there 1000s of bugs open and 100s of existing feature requests that your time could be better spent on those" won't go over well and in the end it is indeed none of my business how others spend their own valuable time. I know you and others work hard to make things better and I definitely appreciate that a lot. > > "Quick Access" was perfect because it provides access to a variety of things > > Sure, the name was good, but many of us have experienced that new users > typically wouldn't try this feature, and have thought the label could be a > cause. I did suggest that many users will not be happy with changes to familiar things. I get annoyed every time I update my iphone and I can't find familiar things because it's now done in some new improved way. > So although the name was fine, it wasn't appealing enough to many users. This is of course quantifiable... > Also, as it has become a button, it's usually better that the label starts > with a Verb (we already linked to some related UX recommendations from > multiple sources about it) > Even introducing the first and only toolbar button with text has been questioned... > > Please revert that stupid change. > > Your comment would have been taken more seriously if you didn't ruin it with > such negative parts. Yes, this strikes me as a little rude. Certainly there are good reasons why you changed it from an entry field to a button You've explained those in detail and we look forward to further cool features within the popup, e.g., quick content search results. Keep up the good work for the good cause and know that others appreciate it in principle (even if I strongly dislike "Find Actions"). :-P
(In reply to Mickael Istria from comment #82) > Your comment would have been taken more seriously if you didn't ruin it with > such negative parts. Mickael, you are too easily offended. You should listen to your users, and I am one of them, even since the days of Eclipse 2.0. I listen to my users, no matter what language they use and how they behave. If they have something to say, I care, even if they are upset. And when they are upset, this is an important indicator that there might be many more users who are annoyed but don't speak up. Also, you should listen to your own developers. Dani and Ed, who are both high-profile committers, already said that "Find Actions" is worse, but you don't seem to care and push ahead. If you don't listen to me, listen to them. (Lars, as a good project lead, which I always thought you are, you too should listen.) When I want to quickly open a perspective, I am looking for a 'perspective', not an 'action'. And I don't want my brain having to construct an 'Open a perspective action' around that. Proper terminology is hugely important. Your brain uses words to think, and 'action' definitely gets in the way. This is not a matter of liking and not liking. I support your argument that verbs are better than nouns, and I am not against lengthy discussions and attention to detail. But unless a better solution is found, stick with the old one. And don't be upset when users have strong opinions. Thank you for caring about making Eclipse better! And thank you for your work on making Quick Access extensible. This is definitely a noteworthy improvement.
Stefan, I frequently work with new Eclipse IDR users and they usually don't understand what Quick Fix should mean. It is IMHO a phrase experienced Eclipse users grow to know. And please avoid saying "stupid" and "waste of time" or the like if you state your opinionif you do not intend to insult people. And last but not least the text will be anyway soon be hidden by default on request of Dani.
If we're going to totally change it anyway... +1 for no toolbar button with text That avoids the discussion about the label, saves real-estate, and a tooltip can be more descriptive than a label. But I'm a little concerned that the icon looks "way too disabled" to me. It's almost invisible on a gray background, and if there is no text, it will be far less noticeable than what it's replacing. I know there's a "one icon for all themes problem", but somehow we need to make this more noticeable than the current "close to invisible" state that it's in...
(In reply to Lars Vogel from comment #86) > Stefan, I frequently work with new Eclipse IDR users and they usually don't > understand what Quick Fix should mean. It is IMHO a phrase experienced > Eclipse users grow to know. some error recovery: s/IDR/IDE/ s/Fix/Access/
Mickael, please fix this for M3 either by removing the text or reverting to 4.13.
(In reply to Dani Megert from comment #89) > Mickael, please fix this for M3 either by removing the text or reverting to > 4.13. As I disagree on this one, I'll let someone who really wants it to happen change it. I won't veto nor block nor slow down anything on the topic of how to label this feature; I'll just remain silent and inactive and will revive the discussion after 4.14 is released if I still have motivation for it.
(In reply to Mickael Istria from comment #90) > (In reply to Dani Megert from comment #89) > > Mickael, please fix this for M3 either by removing the text or reverting to > > 4.13. > > As I disagree on this one, I'll let someone who really wants it to happen > change it. I won't veto nor block nor slow down anything on the topic of how > to label this feature; I'll just remain silent and inactive and will revive > the discussion after 4.14 is released if I still have motivation for it. My patch to hide it by default will be ready for m3
(In reply to Lars Vogel from comment #91) > (In reply to Mickael Istria from comment #90) > > (In reply to Dani Megert from comment #89) > > > Mickael, please fix this for M3 either by removing the text or reverting to > > > 4.13. > > > > As I disagree on this one, I'll let someone who really wants it to happen > > change it. I won't veto nor block nor slow down anything on the topic of how > > to label this feature; I'll just remain silent and inactive and will revive > > the discussion after 4.14 is released if I still have motivation for it. > > My patch to hide it by default will be ready for m3 Thanks!
(In reply to Dani Megert from comment #92) > Thanks! Will be done via Bug 551324.
Thank you for the changes in 4.14 M3. Well done!
I don't think we will find a conclusion for 4.14.
As the title is hidden by default in the perspective bar, I don't think it matters that much anymore. Please reopen if you disagree.
