EDIT: The question is specifically for DESKTOP. No mobile/tablet.

My client wants a design for a web app (chrome webstore). The wireframe is final. But the problem is he wants that the buttons/menu [ in the lower section] should not distract user but at the same time he shouldn't have to click 2 times to use any option (clicking one of many buttons in the lower section).

One solution is to hide all options and show them on a button click like hamburger icon in phones. But it will require 2 clicks to use an option, so not recommended.

Other solution is to show elements on hover. But here also he will have to hover then decide which option to use. It is also a 2 step selection.

If we keep all options visible with low opacity, it will show options when not needed which my client doesn't want.

Is there any other solution to meet the client requirements ?

wireframe for notes web app

  • 2
    Will the web app only be used on desktop browsers or should the solution be mobile friendly? Jul 7, 2014 at 8:16
  • It will be available only on desktop. No mobile version.
    – Jcoder
    Jul 7, 2014 at 12:20
  • IMO, minimizing the number of clicks should not be a requirement. The app should be easy to use and look nice, that's it.
    – kwahn
    Jul 7, 2014 at 16:24

4 Answers 4


I am affraid you won't find a perfect solution here - to provide visibility and affordance (in a visual world) you need to keep some element visible. Showing more on hover is a good idea provided this is a desktop solution (you mentioned Chrome Web Store).

There are pros and cons of both solutions you have mentioned:

Triggering on click will make user click it to discover/rediscover the hidden features (users may avoid clicking it as they forget "what was the icon used for?" and not willing to trigger some unknown action. In other words - this icon will need them to think. It's no good except tools that are used on a very daily basis, where user remembers what is a tool for, or if an icon is very, very self-defineable and understandable.

Triggering on hover is different. Good about it is that user will sometimes trigger the extended options accidentally, which will remind him about what's in there. But at the same time, it needs proper approach because this can become too annoying, resulting finally in user uninstalling the extension. But it cannot interfere with what's on a website user is visiting, limiting user experience of the website.

Thus, you need to properly plan where the initial trigger will be placed, and optionally you can also let user customize this position. One of my favourite examples here is Jing (http://www.techsmith.com/jing.html), where a little on-hover spot is glued to a side of a screen, but its position can be customized (user can drag it around, glueing it to various places around the screen. Except Chrome, which uses the very top of the interface on Windows, the best place for it is top of the screen (it resides just above the main application window content, just over the title bar). But since I use Chrome, the good place is leftmost side of the screen now. It's because most of the pages are not full-width, and as such they are usually centered. Usually. For all the rest, the drag-me-somewhere-else feature does the job perfectly. So as your solution will be used in a context of visiting websites, I would make it the default position, informing user (during onboarding just after the extension installation) that s/he can drag it somewhere else if needed.

enter image description here

Secondly, I would focus on:

  • a great icon, providing correct and fast recognition of what the trigger spot is for, and what treasures it hides. Hamburger menu is a very bad choice here, as if you take a browser as a whole, hamburger menu is contextual, specific for a visited site and allows accessing the main site navigation.
  • making the hover spot big enough, so that user does not need to focus on placing his cursor over it very precisely - one clue is that you can make the hover area bigger than its visual indicator. But don't go too wild here, occupying the full left border of the window, as it may render some websites unusable below, even though you provide the drag around feature.

One more thing is that if your solution is content-contextual, you may go a little bit different way, showing contextual popup menu e.g. after text selection (you may check Diigo extension as a reference).


Your client says that the menu shouldn't be distracting. This doesn't necessary mean that the menu shouldn't be visible.

You can make sure that the content has more visual emphasis than the menu buttons. The eye should immediately be drawn by the content, not the buttons. The user will only notice them when they look around for something that looks like a menu.

How to do this depends on what the content is, and how "attention grabbing" it will be. Many web shops have a top or bottom menu bar in grey / plain text (such as this one). Something like this might serve.


One suggestion would be something like your second solution. Keep the bottom hidden, until the user moves his cursor to the lower part of the screen. You could experiment with the height at which you want to trigger the visibilty, for example when the cursor reaches the lower 30% of the screen, or the lower 20% etc. This way, the menu appears without having to click an hamburger menu, and without hovering on a specific element. Technically, it's still a 2 step process, but depending on the height you choose for the trigger area, it's more of a "1.5 step process". enter image description here

The danger of making this area too big, off course, is that it could irritate (and distract!) the user, so that's why I would experiment with it first.

  • 1
    Good possible solution, but I would like to notice the user might not notice the function when it's completely hidden resulting in frustration or abandonment. My advice is adding a visual cue to this solution. Jul 7, 2014 at 8:18
  • 2 issues that might be a problem for this approach. 1. It isn't good to rely on hover effects / cursor position for touch based devices. 2. Movement is the most distracting thing you can have in a UI. You peripheral vision sees colour and shape badly, but is great at seeing movement. A menu that flickers on and off like this could become very distracting (think how annoying those animated advertising bars are on some websites).
    – Franchesca
    Jul 7, 2014 at 11:11
  • I think a good animation shouldn't be too bad. I agree that for mobile, this solution is pretty much worthless, but I read Chrome Webstore so I suspect it's for PC, where it might work, off course with a visual cue, which I was to lazy to draw :) Off course, just having a button/hamburger menu would be my ideal choice but as the OP wanted something different, I thought of this, with the disadvantages mentioned Jul 7, 2014 at 12:16
  • Thanks, This seems a viable solution for desktop. I can't upvote as I don't have sufficient reputation.
    – Jcoder
    Jul 7, 2014 at 12:31

As your wireframe, it looks like your designing for mobiles. Remember that the hover state is not (at current time) a normal touch functionality.

You may use ghost buttons, it does not distract the user as normal buttons, and you do not need a hover to show them.


enter image description here

  • Sorry if the information wasn't sufficient. I am making only for desktop.
    – Jcoder
    Jul 7, 2014 at 12:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.