Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    70
  • comments
    185
  • views
    53365

Click-happy, Click-sparse

Sign in to follow this  
Oluseyi

387 views

First off, I am aware that there is a UI mode for Windows that selects on hover. Now that we've got that out of the way...

It's amazing how click-happy user interfaces are! Click this, click that, click that, click this, ask me stupid questions and require me to click "Next" each time... The mouse is a pointer; is it possible to infer intent from its location and "context"? If I'm staring at my blank desktop and then point at the Start Menu, you might as well open it up. It's not like I'm doing something else at the moment, so it's unlikely to irritate me. Don't do it if the pointer is engaged or captured - dragging a widget or icon, for instance.

Essentially, a click should initiate an action, and menu navigation is not an action. By reducing the number of clicks, I think we can reduce hand fatigue and the rate of RSIs. Of course, there's the possibility of false positives in a system like this - accidentally pointing at the Start Menu bringing it up, necessitating a click to cancel, which is worse. That's easily remedied by having the pointer lying outside the boundaries of a menu hierarchy cancel the menu. This raises its own problem, namely the probability of losing menus due to awkward placement. Fortunately, that's a problem that's been solved: every new child (popup) menu should open with its mid-point anchored to the parent item, such that the maximum distance of travel in either direction is no more than half the height of the menu.

In addition, a "boundary transition area" can be in effect around windows, menus, etc that causes the mouse to exhibit a little "resistance" to crossing into the next region, reducing the ease with which false positives occur.


In a system such as the above, though, keyboard focus has to be divorced from mouse focus. One of my dissatisfactions with the Windows GUI model is that keyboard focus is tied to both mouse focus and window order. Being able to point at a window without changing its order yet scroll its contents while maintaining original keyboard focus isn't irrational to me.


Next up: More GUI philosophy: Windowing, palette menus and why MDI is a bad idea.
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!