[Libreoffice-ux-advise] [Bug 91874] A Search by function or keyword over main menu-- similar to SpotLight, Tell Me, or Ubuntu's HUD but native for LO GUI

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=91874

--- Comment #11 from Mike Kaganski <mikekaganski at hotmail.com> ---
As advised by Heiko, here are relevant bits from bug 101110:

...
I imagine that something like in AutoCAD, where there is a rich menu with an
input box, where one can enter either help request, or (some characters of) a
command name, and in the list beside the input box, there appear both similarly
named commands and help topics, so clicking to any of those, one gets either
the command executed or help topic open. See
https://www.youtube.com/watch?v=peDXW7lu6tk

The "menu" could be e.g. in a sidebar.

I suppose that this would make it easier to use some commands that one cannot
fins in menu/toolbar. And macros should be available there, too, as ordinary
commands.
...
There are several main problems that this proposal could solve.
1. When I want to use some rarely-used command. :) For a power user, that knows
of some less-used functionality but useful in some situations, this is surely
often encountered situation. One single rare command may be required once a
year, but there's another one, and another, too much of them.
2. When I want to maximize usable screen space, like using new single toolbar.
So, the toolbar space is not too huge.
3. When I don't know (remember) where the command is (menu/toolbar) and what
its icon is, but searching by (part of) command's name will show me its icon
and (hopefully) will show me its position on menu. Further, I may not remember
its correct name, I may enter a word "capitals", and each command having a good
description and growing dictionary of aliases, I'll be presented with
"Format->Text->UPPERCASE" and "Format->Text->Capitalize Every Word" commands,
and also "Format->Character" with help section describing its Font Effects, and
Character Styles in that context. This way, anyone will find it easier to find
commands for requested functionality, easier to learn and enhance proficiency.
...
This kind of UI is very common currently. You may see it in Unity Dash, Windows
Start, Blender etc. Also, I see a wish for this rather frequently in forums
(e.g. here:
http://blender.stackexchange.com/questions/40163/find-commands-by-name , here
in Russian:
https://www.linux.org.ru/forum/talks/12695695/page1?lastmod=1467486174771#comment-12705845)
...
(In responce for suggestion that it's better addressed with a plugin fetching
Uno commands list):
I'm afraid it's impossible without "native development", because otherwise it
won't be able to use additional information. I mean, that it must respond to
"contextual" meaning (bring commands that don't have typed words in names, but
that may do what user wants, e.g. by having a dictionary of "tags" attached to
each command), etc. Supporting external DB of such information is unfeasible,
because it would require from maintainer to do it multilingually, track each
new/modified command, etc.

Not every LO feature has its uno command: e.g., many entries inside Format
Character dialog. I'm afraid, that if users will search for "Blinking", they
won't find requested commands using your suggested approach, while in best case
they would be presented the option to open that Format Character dialog.

Many uno commands would likely come unlocalized; that would be a showstopper
for this feature.

The feature should also provide relevant help entries (online/offline,
depending on whether help is installed locally).

I suppose that the feature is only possible by gradual development. First,
create infrastructure for it, e.g. means for feature developers to define the
"tags" for their commands. Implement the feature to be user-visible, and then
gradually fill required data to existing commands, hopefully with a bunch of
easy hacks. Include this into localization process, etc.
...
And btw, with notebookbar coming (that is often criticized for wasting vertical
space, and is targeted to users that tend not to use menu), and already
implemented single toolbar (that clearly seeks to maximize screen real estate),
the need to hide menu bar will be greater. It would be possible to continue
being productive without menu bar in LO, if such a feature is implemented.
...
See also: bug 90195

-- 
You are receiving this mail because:
You are on the CC list for the bug.