Launcher Improvements

[mmstick]

Closes #19 Closes #20 Closes #23 Closes #25

[jacobgkau]

After this, GNOME Control Center settings panels are no longer displaying in search results; those are part of the regression testing checklist. The G-C-C panels have NoDisplay=true set. Not sure what the best way to work around that would be.

[mmstick]

We can ignore NoDisplay if OnlyShowIn was set. That was a condition the former logic was handling.

[jacobgkau]

Regarding the new help copy, this is what it currently looks like:

I identified the following issues/limitations:

• The Web Search entry only shows DuckDuckGo as an example, with no way to discover the other 26 supported websites.
• The Calculator example (which is the only example that includes actual parameters instead of a placeholder) is a little difficult to understand, especially because there's an equals sign in the middle of the equation in addition to the prefix equals sign at the beginning.
  • The (qalc) just before the colon also makes this line look a bit messy, since the rest of the lines use similar-looking curly braces for required parameters.
• I'm not sure why the OR is in all caps in the file navigation example.

I tried playing around with making the usage patterns more consistent with man page format and having separate working examples, and came up with this:

This repurposes the name as a short description since there's not much value to having a non-descriptive short name listed. It doesn't solve the issue of plugins like web search that have too many options to list, and having a newline in the description seems like kind of a hack, but it might be an improvement overall. What do you think? (Wanted to check before I pushed; seems like UX might eventually need to be involved as well if this gets much more in-depth.)

[WatchMkr]

@maria-komarova can you take a look at this when you have a chance?

On the one hand I like that not having as much detail makes it clean and has a good default for using the functionality. On the other hand, I can search youtube but don't know it and adding them while still looking clean is tricky.

[maria-komarova]

General question before I dig deeper with this one - would having "Syntax" be useful? Because as a less technical user I find examples much more helpful. Overall I like shorter descriptions, they are easier to digest and grasp at a glance without spending too much time reading. Getting into details, I like the change from "Find" to "File search". But then longer descriptions on top of Syntax make it a little more difficult for me to quickly grasp the options. I'm also a bit confused on what "with tab autocomplete" means under File navigation.

[jacobgkau]

General question before I dig deeper with this one - would having "Syntax" be useful? Because as a less technical user I find examples much more helpful.

I think the reasons it's useful to include syntax would be:

• It makes more clear which words in the example should be changed (parameters) and which should stay the same (command/prefix).
• The syntax can have "or" operators | (or even just the word "or" like one has in the first image) to compactly show several different possible options that can be used, while doing the same thing with examples would require an entire example for every option.

I'm also a bit confused on what "with tab autocomplete" means under File navigation.

That means when using file navigation, you can press tab to autocomplete directory/file names. Maybe should be changed to "with tab autocompletion" if not reworded further, but it is fairly useful to know about when using that plugin.

[mmstick]

Shall I merge with the proposed changes from @jacobgkau ? We can always revisit the design of pop-shell later.

[jacobgkau]

Shall I merge with the proposed changes from @jacobgkau ? We can always revisit the design of pop-shell later.

I'd need to push the proposed changes if we want to do that, otherwise this is still in the state from my first screenshot. (Everything else did look good besides the help text that I brought up.)

[mmstick]

Push to this branch if you can

[maria-komarova]

I still think shorter descriptions are more user friendly when it comes to less technical users. I do like changing "Find" to "File Search" for the first line. And adjusting "OR" to "or" in the last "File navigation" row. I see the issues @jacobgkau pointed out but I can't see an easy way to improve it yet. More text makes it more difficult to scan through.

[jacobgkau]

I still think shorter descriptions are more user friendly when it comes to less technical users. I do like changing "Find" to "File Search" for the first line. And adjusting "OR" to "or" in the last "File navigation" row.

Okay, sounds like someone should revert that last commit and then make the two changes you're suggesting.

More text makes it more difficult to scan through.

You don't think the labels at the front of the lines help with this? Having the syntax on the short lines at various points horizontally because of the different description lengths makes it more difficult to quickly find where those start, IMO, but you're the expert.

[maria-komarova]

Let's push without the changes, even the ones I'm suggesting. I will make the design/description changes a separate thing. I'm sure there should be a better way of doing it somewhere there.

[jacobgkau]

Okay, I will force-push to revert the two-line commit I just made, then give it a quick re-test to make sure we didn't break anything else while playing with that.

[jacobgkau]

@mmstick You just merged this with my two-line commit included.

[maria-komarova]

It's fine then, let's keep two lines if they are already merged.