Rethinking the right-click
The capability to use the mouse right-click to bring up a context menu has been a staple of the Windows interface since Windows 95. I recall seeing this capability in application even before then. It's an elegant way to add additional functionality to an application without cluttering up the user interface or requiring the user to constantly mouse to the main menu. I'm a fan of the right-click because of these reasons.
But the right-click has a downside -- its not obvious to less experienced users to even use the right-click. With the left-click, a user is deliberately acting on something; clicking a button to perform an action, clicking a hot-link to open a page, or click and dragging a scroll bar. The left-click is all visual. We don't expect a left-click to do anything if we happen to click on some some empty part of a window. The user sees something that looks like it should be left-clickable, and the user clicks on it. It's part of the learning process. The right-click is not so visual. It's not apparent what parts of a user interface are right-clickable and which ones aren't.
The non-necessity of the right-click is fairly apparent with popularity of the most basic user interface in widespread use today: the web browser. Web pages are so obviously simple to use, that the masses have little problem learning how to navigate the web. Even as websites have become more complex, I have yet to come across a website that actually made use of the right-click as part of its user interface experience. Web browsers provide certain functionality using the right-click (not the least of which is copy/paste), but not the websites themselves.
This has caused me to rethink certain aspects of the SSP user interface. There is significant functionality found in certain places of the control window that are accessible through right-clicks. Typically, these pop-up menus mirror what is also available in the main menu. But I've come to the conclusion after watching users use SSP and other programs, that right-clicking is not something that is often tried when attempting to find a feature -- even scanning the main menu is often overlooked. Perhaps that's why Microsoft got rid of the main menu altogether in Office 2007.
The October 2007 Edition of SSP has the first steps in re-working access to certain features, particularly as it relates to the right-click. Over time, the right-click will be used more for features that are about the user interface environment ("Customize...", "Preferences...", etc.), and less about function ("Transition", "Verse Order', etc.). Other features that have been available through the right-click pop-up menus, will be made more prevalent as left-clickable controls.
Once example of this is the new "Properties" button that appears in the Program panel. This button provides access to features that have always been accessible through a right-click on the Program panel. The difference now is that users actually see that there is something call "Properties" that may actually be useful to them. They'll left-click on it, and wallah, see a menu of options letting them set properties for that particular program item. The main intent here is to improve usability for existing users, but perhaps more importantly, improve the learning curve for new users.
As evidence that this works, I've already received a complaint on the Beta Test Support* forum about this new feature. The complaint is that the users at this person's church have noticed this button and are now clicking it and making changes -- unwanted changes that is. I've been asked to remove this feature, or provide a way for him to turn it off. It makes me wonder how many SSP users, for instance, up to now don't realize that they can change the background to a song after they've added to a program. This request actually proves to me that adding the Properties button was a good idea -- it helps make users aware of important features they were not aware of before.
The right-click isn't going away in SSP, but you'll find less need of it as the product evolves.
*A current subscription and linked account is necessary to view posts on the Beta Test Support forum.
(BE126)
Comments:
I agree. I've been using right click since OS/2 2.0 and have loved it. I would hate to see that functionality go away.
But that's not the case.
But they didn't change rapidly enough, and got left in the dust.
PLEASE keep the right-click functions.
Mike
While on the subject of the drop down item menus, I feel a little reorganization would be helpful -- yes, I know they have been changed recently. I find it inconvenient to have the editing toward the bottom of the menu. I would prefer options of that type to be first, followed by display properties, etc. I suggest for songs that the item "song" be at the top and when opened have edit, copy, print, add to short list, remove, and comments. Similarly, for slide shows, and timers. Oh, yes; what is "add to short list?"
There are some options in the preferences to alter double click configuration, but I haven't played with them.
through the program similar to the +/- keys. What seems natural
to me (but maybe not to others) is to double-click a song or slide-show,
in their respective panels, to bring them up for editing. I keep doing
it out of habit and somehow think that it will magically work!
To the last line in the BLOG, "The right-click isn't going away in SSP, but you'll find less need of it as the product evolves.", I say thanks. I am an extensive user of the right-click option.
I also agree that to remove any functionallity because an undisciplined person might abuse it is a bad idea. Operators that are not creators or designers should know, and pay, the consequences of changing something without permission.
As a side note... Does anyone know of a MS OS function that acts like a right-click, but is envoked with a left click? I will answer this in few days if no one else knows it. It might also be fun to learn some others that I am not aware or.
My two bits,
Simon