Improving KDE Applications Help menu “Actions Lookup”

Today I have been working on a small Proof of Concept which intents to demostrate that improve the Help menu by adding an “Actions Lookup” is possible. 

At the moment this is not a planned feature, so is not going to be in KDE Platform 4.6 or even not in 4.7. If the overall feedback I get during the next days is positive I will start a brainstorming (in kde-usability I guess?) to design the feature and try to implement it for 4.7.
Some ideas I have in my mind:
  • Be able to use it as we use KRunner (shortcut + write text + enter)
  • Something to show where the action is (so the user can learn the app)
  • Search within the Handbook
  • Online search?
What do you think? would be useful have something like that in our platform?
Cyap!

=-=-=-=-=
Powered by Blogilo

44 thoughts on “Improving KDE Applications Help menu “Actions Lookup”

  1. I like how well it appeared to work (yay for people using KActions), I think this could work well as a krunner like interface.

    Good stuff.

  2. I think this is very nice. It will be especially helpful for those new to KDE applications.

    Showing where the action is would be quite tricky. The only way I can think of now is by hovering and showing something like “File > Save” or something. Or maybe on right click have an option to navigate to the action.

    Overall I find this an quite an innovative feature and you should definately keep up the work for it.

  3. I think it would serve as an even better “help” if it afterwards showed the user where to find the action in the menu/toolbar so that they don’t think that they always have to type it in the help menu. Maybe somehow highlight the correct item in the toolbar/menu?

  4. Also gets +1 from me. Stefan has a point that showed after where to the action in the menu/toolbar. All in all a brilliant idea that progressing nicely.

  5. I really like it, put I have two small suggestions. I know it’s just a proof of concept, but I’d rather make it perfect from day one on so here I go:

    1. Add a grayed out description text in the search field indicating that this is a search field and what can be searched for. The text should disappear automatically once the user focuses the search widget. Avoid the word action in the user interface, because I doubt the average user understands the implementation details of actions. Maybe something like: “Search for menu entries”, this leaves out the fact that it also searches for tool bar entries, but brevity and understandability beats correctness in this case, I believe.

    2. Do not show the results in the help menu itself. This makes the menu grow dynamically and all actions below the search field move around, which is always a bad thing to have. It also makes it harder to distinguish between search results and regular menu entries, like the “about” buttons. Instead add all search entries in a submenu and add the usual small arrow to the right of the search field indicating, that a submenu exists. Make it open the submenu automatically once a search term is entered and close it again when the field is empty.

    Apart from those smaller things: Keep up the good work!

    • Ich bin seit KDE4.1 dabei und bin von 4.2 sehr angetan:der Desktop ist jetzt viel stailber, die Taskleiste ist flexibler (autohide, symbole aus dem Tray ausblenden etc.) und auch die Composing-Effekte machen nun richtig was her.Da ich Ubuntu nutze gibt es ein paar grafische Ruckler beim Start, weswegen ich ernsthaft fcber einen Umstieg nachdenke wahrscheinlich zu Arch-Linux.Ab jetzt empfehle ich kde4 weiter !

  6. Awesome idea! It should take some getting used to, but it would also be a killer feature for some applications where you can’t find the damn button you’re looking for!

  7. Online search might be a bit of a stretch for the menu and not really intuitive unless you can define very narrow search terms in userbase for example. The proposals of Florian get +1. What is especially nice about it, is that adding proper Tooltips now has an overall improval of the application itself, as it becomes searchable metadata. This should motivate people to actually fill in sensible tooltips.
    Have you done the metadata search in nepomuk?

  8. Here’s an idea:

    Instead of this being a part of the traditional menubar, offer it as a replacement.
    User can choose between a traditional (as demo’d) or minimal menubar.
    The traditional menubar is the default and is exactly as you demo’d the feature
    The minimal menubar can just be one word: “Menu”. It may be hidden by default (Ctrl+M to show/drop)
    Selecting it drops down the search box and the top level menu items (File, Edit, …)
    Query entered will lead to relevant results. The results replace the top level menu items.
    Clearing the search box restores the top level menu items.

  9. I very like the idea. It is simple, clear, yet very handful. Very nice piece of programming ! :) I would very like to see it in 4.7 or even in 4.6 if it were possible. That is what KDE needs now – small things that make people say: “wow, it is so simple but helps a lot!” Arron calls it elegance :)

  10. Nice idea!

    Here just my 2cents :)

    1. Don’t place it under “help”, make it possible to add it in the tool bar. Then everyone can drop it, where he likes it to be. This way experienced user will be able to find this really nice feature very easy. Also people like me will be able to hide the menu bar completely :)
    2. Make it possible to search and set setting-options too. This way the tool gets a lot more attention and people will be able to set their settings very quickly.
    3. Offline usage has to be possible (for phones and people without internet-access)
    4. Allow actions to be tagged, so users are able to find their wanted feature with different key-words.

    You got a huge +1 for this needed feature. Especially in huge applications like office, pim or development applications, this feature will improve the usability a lot!

    Regards
    Tony

  11. I was thinking to something similar from a pair of weeks now, there are a lot of great implications in using a search based command interface.

    I’m not really a c++ coder but I’m _very_ interested in the code and willing to learn the language if it’s of help for this feature arrive in kde as soon as possible.

    feel free to contact me for whatever you want, even small (what I can) money donations.

  12. This is awesome. I have been meaning to look at implementing this for ages (with the first and possibly second bullet-points), but I’m pretty useless. You are clearly not. Monster massive mad props to you sir.

    The good thing about putting it under “help” is that it is a standard menu which is (almost?) always there. The bad point is “help” is where you go to look things up you don’t know, I would see this more as a major (if not the main) way to interact with applications.

    Personally I would like to use this, as you say “like KRunner” as my default way of accessing actions in all KDE applications.

  13. @twolfy

    4. Allow actions to be tagged, so users are able to find their wanted feature with different key-words.
    +1 – that could be cool, though it is the sort of thing that is tricky to work out how to make the UI for it elegant (unlike the basic concept of this which is very simple and elegant)

    Search the web
    – 1 > I’m not a fan of this trend to add web-searches to all search interfaces. I can’t think of a time when I’d want to search my application menu for actions and also search the web for the same thing. If I want a shortcut-and-type way of searching the web there are several solutions, including KRunner, I don’t need it built into every application

  14. @Darwin

    Wow, that Mac OS X implementation shows the way.
    * it highlights the menu item
    * the actions matching what you type replace the rest of the help menu (don’t push the other items down and don’t make it a submenu as @Florian suggests)
    * it can also find preference settings as @twolfy wants
    Mac lacks only the gray suggestion text that @Florian suggests.

    It would be great if the menu of matching actions could show the tooltip text, instead of making you dance around with “What’s This?” (2:05 onwards) which wouldn’t be available if matching actions replace the rest of the help menu. Maybe similar to the way the Application Launcher menu has the name and the additional text.

  15. Pingback: openSUSE et open source » Blog Archive » openSUSE 11.4 M5 et KDE 4.6 RC1

  16. Pingback: Lo mejor de la semana 51/2010 | Los ojos de Tux

  17. Pingback: Mejorando el menu ayuda de las aplicaciones KDE con un buscador : KDE Blog

  18. Pingback: Video: Mejorar el menú “Ayuda” de las aplicaciones de KDE con “acciones de busqueda” » Espacio KDE

  19. I don’t like this. This is exactly like the help assistants that were removed from Office XP, because they were confusing. A much better idea for 4.7 is a) do once and for all context-sensitive help, because I don’t want to browse and search a handbook when I want help about a specific feature, and b) review the ? titlebar function, expand it, and once and for all, again, KILL WITH FIRE THE RECTANGULAR YELLOW BUBBLES WITH WINDOWS 95 SHADOWS (that even get shadowed again by the KWin Shadow plugin… it’s that horrible). They look completely out of place in Oxygen, and they even looked out of place in Plastik. If you want shadow, you’ll surely want a pretty one, like the Oxygen tooltip shadows.

  20. like it looks like. just dont forget to put “Search:” label or something. otherwise no one knows why theres an edit box in the help menu or what it’s there for :P

  21. Pingback: AppMenu Runner, meet the KDE HUD | Afiestas Blog

  22. Pingback: AppMenu Runner, el menú inteligente de KDE al estilo HUD | El Blog de Rigo

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>