I have a view with a few gesture recognisers (ala Clear). Should I add buttons only for voice over users instead?
I thought about using the hint to say something like "3 Finger Swipe Right to Edit. Left to Delete. Up to Create a new one." but it seems like Apple discourages that. Even apple uses "Double Tap to Edit" on textFields and such and I have no idea why they discourage that.
Does not include the name of the action or gesture. A hint does not tell users how to perform the action, it tells users what will happen when that action occurs. Therefore, do not create hints such as “Tap to play the song,” “Tapping purchases the item,” or “Swipe to delete the item.”
This is especially important because VoiceOver users can use VoiceOver-specific gestures to interact with elements in your application. If you name a different gesture in a hint, it would be very confusing.
Yes you should include alternate buttons.
You're misunderstanding the Apple Disclaimer. The disclaimer refers to the fact that VoiceOver is going to take over the touch screen. Once VoiceOver takes over the screen, it decides how to pass gestures to your application. So as it works right now to activate a button, a user would highlight the button, and then double tap. But, VoiceOver doesn't need to stick to this (though it is highly likely that they will for some time). However, it is not a developers job to inform users of this. VoiceOver informs users of this through earcons, traits, and other instructions that are dependant on the AT. If a developer were to include this information in the hint, it could be invalidated by a change in the AT, and then be inconsistent across device versions, or other ATs such as braille boards.
Not only would you be potentially describing gestures that VoiceOver doesn't allow (given that it captures screen gestures. But, even if you were to apply the allows direct interaction trait, you may be describing gestures that people with disabilities can not perform. Either way, including another method of achieving the given interaction is the better solution.
Use custom actions defined on accessible elements instead of using specific buttons for your purpose.
Moreover, I don't think it's a good idea to add VoiceOver gestures dedicated to an application as you suggested with your hints : try and build your app with the VoiceOver standards that users are used to manipulating.
Related
I have this link:
The Best Page
The ajax-populated and -revealed element that exists within the current page is an "enhancement" and has aria-hidden="true". It would be preferable for screen-readers and assistive tech to follow the link's href to the subsequent static page, rather than triggering the click handler (especially since the element that it will acts on is already hidden, as previously mentioned).
Will this behavior already take place or do I need to add something?
When pressing enter on a link, it does the same as a click, and it's a very bad idea to intercept the enter key in order to do something different.
There are keyboard users, perfectly sighted, who aren't using screen reader. These users will experience an unexpected behavior.
Screen readers may choose to send directly a click event, rather than keyboard events, even though enter has been actually pressed. So idem in the opposite direction.
There may be other ways to activate a link, other than click or enter: spacebar, tap on touch screen, assistive techs to click by winking the eyes, etc. How it should behave in these cases ?
By the way, you can't do something different based on whether a screen reader is used or not, simply because you have no 100% reliable way to detect it.
The questions you should ask yourself are:
Why do you want a different behavior between click and enter ? or between screen reader and normal users ?
Are you trying to work around inaccessible content, or do you have two versions of the same content (an accessible and a unaccessible one) ? In that case, it would be much better to have a single content and make it accessible. Rare are the cases where it's really impossible, and experience shows that the two versions are eventually going to be out of sync, more quicker than you think.
Often times convention is one of the most important design consideration for user interface. Usually the advice goes to do it like Microsoft does.
This is for three reasons:
If it ain't broke, don't fix it.
If your users expect to click on a floppy disk icon to save, don't change the icon (even though some of them may have never seen an actual floppy disk).
Users don't want to re-learn the interface (and hot keys, etc.) with each different application they use.
At the same time Emmerson said "*A foolish consistency is the hobgoblin of little minds.*" So when does maintaining a consistent user interface cross the line from a good idea to stagnated innovation?
Microsoft shook up the good old WIMP GUI with the introduction of the tool bar, and then again with the Ribbon control (which is the natural evolution of the tool bar, like it or not.) Now we are seeing ribbons everywhere.
So my question is, what are some user interface paradigms that are accepted and consistent across multiple applications, but have stayed past their prime and are starting to reek? Are there some important changes that would benefit from a grass roots push by developers to innovate and improve the user interface experience for our users?
One thought that came to mind for me is the modal pop-up dialog. You know the ones that say: "Are you sure you want to . . .. - [Yes] [No] [Cancel] [Maybe]" and its evil twin "Successfully completed what you wanted to do! [OK]." We are seeing a movement away from these with the "info panel" in browsers. I think they need to be adopted in windows application development as well.
If possible please list a solution for each stale UI item.
And please don't list clippy. We all know he was a bad idea.
NOTE: This is specifically Windows client user interface paradigms, but I am certainly open to drawing inspiration from the web, the Mac, etc.
You mentioned popup modal dialogs , and I'd argue that non-modal ones are just as bad. Any dialog box remove focus from the program, they could end up behind the program and make it hard to find it, they might not even appear on the same virtual screen.
I'd like to see an end to all dialog boxes. If you need to stop someone from using the UI because of some non-normal circumstance, then remove the relevant parts of the UI from the window, and replace it with what the dialog would contain. Bring back the UI once the problem has been handled.
Clicking things on touch interfaces
It's incredibly difficult to click on things on a touch interface, because you don't know when you have pressed the screen hard enough. And if you add an animation to the button you are clicking, you most likely wont see it, because your finger is in the way. Adding other reactions, like vibrating the phone or painting waves on the screen might work, but there is usually a delay which is too large, much larger than the tactile sense of a button being pressed. So until they invent a screen with buttons that can be pressed, all touch devices should move towards dragging user interfaces (DUIs) instead.
Counter intuitively it is easier to press an object on the screen, drag it, and then release it than it is to just press and release it. It's probably because you can see the object moving when you start dragging, and you can adjust the pressure while dragging it. Dragging also has a lot more options, because you now have a direction, not just a point that you clicked. You can do different things if the user drags the object in different directions. Speed might also be used, as well as the point where the user releases the object. The release point is the real strength of DUIs, because it is very easy to release something, even with pixel precession.
Some designs have started to use DUIs, like (here we go) the iPhone, palm pre and android phones. But only part of their design is DUI, the rest is clicking. One area they all have in common is the keyboard. Instead of clicking on a key the user presses any key, then drags their finger towards the key they really wanted to click. Unlocking these phones also uses dragging.
Other easily implemented DUI features would be things like mouse gestures, where dragging in different directions, or drawing different shapes does different things. There are also alternate keyboards being researched which puts a bigger emphasis on dragging. All buttons can be changed into switches, so have to drag them down a bit to click them. With a well designed graphics, this should be intuitive to the user as well.
The Apple Human Interface Guidelines are a good read on this topic. They discuss this from a very broad point of view and the guidelines apply to any platform, not only Mac.
The file system. I want to save a file.. >OOOPs I need to think of a file name first. Well.... how about ... blah.doc.
6 months later...
Where the %#*(%& * did I save that %()#*()*ing file?
The solution is build a versioning system into the application, or better, the OS. Make files findable by their content, with a search engine, instead of forcing the user to come up with a memorable name, when all they want is for their file to not get lost.
Eliminate the save step. Type something in to the application, and it's just there, and there's no risk of losing it by some misstep, like forgetting to save. If you want an older version, you can just pick a date and see what the document looked like back then.
To build on the search engine idea: It's a pain having to navigate some arbitrary tree structure to find your stuff. Searching is much easier. However, you might still want to have something like a "folder" to group multiple files together. Well, you can build a richer metadata system, and have a "category" or "project" field, and setup the search engine to show items by project, or by category. Or group by those, or whatever new UI discovery we make next.
This question is a bit too open-ended, IMHO.
However, my main approach when designing anything is:
Fits in to wherever it is. If it's a windows app, I copy MS as much as a possible
It's simple.
It provides options
Buttons have a nice description of what the result of clicking will be, as opposed to 'yes or 'no'
Harder to answer the rest of your post without spending hours typing out an arguably useless (and repeated) set of guidelines.
In my mind, the one thing that really stands out is that USERS need more and easier control over the application's user interface appearance and organization.
So many interfaces can not be modified by the user so that the most used/favorite functions can be grouped together. This ability would make your favorite software even easier for you to get things done.
Error messages need a "Just do it!" button.
Seriously, I really don't care about your stupid error message, just DO WHAT I TOLD YOU TO DO!!!
I think the entire Document model of the web needs to change. It's not a user interface, but it leads to many, many bad user interfaces.
The document model was a good idea to connect a bunch of documents, but now the web is also a collection of applications. Today, I think the Page/document model corrupts our thinking. We end up lumping things together that aren't related, modularizing our code wrong, and in the end confusing users with our monolithic control board type websites.
Find dialogs that sit over the widget in which you are doing the search are terrible. Loads of apps do that. The find bar in Firefox works much better.
Many applications have multiple panes within the UI - eg in Outlook there's the preview pane and the inbox pane (amongst others). In these applications typically cursor key presses apply to the currently focussed pane. But there's very poor hinting to show the user which pane has focus and there are seldom keyboard shortcuts to move the focus between panes.
The focussed pane should be highlighted somehow.
Something like alt+cursor keys should move the focus around.
Ctrl-Tab and Ctrl-Shift-Tab cycle left and right through tabs instead of MRU behavior, even though in most cases the same behavior is duplicated with Ctrl-PageUp and Ctrl-PageDown.
There are a lot but here's an idea for a couple of them:
Remove some clicks like in "add another" or "search item" and the like.
This is well done with interfaces like ajax which have autocompletes ( and auto search ) but is slowly being adopted for platform UI's ( and in some cases they were originated in platform UI's. )
This is how StackOverflow does it for some scenarios.
But of course, we all know that already don't we? No need for "Seach tag" or "Add another tag" buttons, they just happen
Dialogs as you described.
Guys at Humanized proposed Transparent messages which actually are used in their product Enso and some other places.
Mac uses them for notifications ( like in Growl ) use them very well, or Ubuntu new notification system.
alt text http://blogs.sun.com/plamere/resource/NowPlayingGrowl.png
Firefox replaces the traditional "Search" dialog box with a search bar at the bottom.
Although not everyone likes the placement for next/previous as in this screenshot
And even SO ( again ) :) replace the notification with the yellow bar.
Finally:
File managers
I really like ( sometimes ) the simplicity of regular file managers, but some times I would like to work faster/better with them.
If you compare IE 4 with IE 8 you can tell the advance ( even better compare IE 4 with Google Chrome )
But if you compare Windows 95 Explorer with Win XP they are almost the same!! ( Win Vista/7 is a step forward )
But I wonder: Why haven't file managers improved as much as webbrowsers?
That's one reason I like stuff like QuickSilver but it is just a step. Much work is needed to create something like a "Perfect program launcher" or (FileManager/DesktopSearcher etc as you wish )
QuickSilver featuring "move to" action
I'm in the process of designing and testing various ideas for an application whose main functionality will be to notify users of occurring events and offer them with a choice of actions for each.
The standard choice would be to create a queue of events showing a popup in the taskbar with the events and actions, but I want this tool to be the less intrusive and disrupting as possible.
What I'm after is a good book or papers on studies of how to maximize user productivity in these intrinsically disruptive scenarios (in other words, how to achieve the perfect degree of annoying-ness, not too much, not too little).
The user is supposedly interested in these events, they subscribe to them and can choose the actions to perform on each.
I prefer books and papers, but the usual StackOverflow wisdom is appreciated as well.
I'm after things like:
Don't use popups, use instead X
Show popups at most 3 seconds
Show them in the left corner
Use color X because it improves readability and disrupts less
That is, cognitive aspects of GUI design that would help users in such a scenario.
For notification, I prefer small notification windows in the bottom right corner. If they have a minimum UI allowing me to take some quick action, it would be ideal.
As model: incoming mail notification from Outlook, Skype notifications for incomming calls, etc.
I have read and recommend:
About Face 3
The Design of Everyday Things
I don't know of any formal articles but the Ubuntu UI design team have considered this issue and you may find something of value in their notification design guidelines or in this discussion by Mark Shuttleworth.
Sorry, no book recommendation here, just one piece of advise: Ultimately, you should let your users decide.
In my experience, what one user considers to be a useful feature is seen as completely broken by the second, while the third doesn't care at all.
Offer them 3-5 options how they will be alerted (including the option to turn alerts off ;-). Of course you should optimise these options as much as possible, hopefully some other answers here can help you with that.
A collection of possibilities:
Change a static tray icon. Useful if the user doesn't have to answer each message immediately, and relatively unobtrusive. Should be an overlay on the original image, making sure that the user recognizes which application it's from, and should be different enough that the user immediately understands that it's not the original icon (for example, a red / yellow exclamation mark on a blue / green background).
Change the tray icon to a dynamic variant. This will be more obtrusive, grabbing the user attention periodically, but is useful when the message is urgent. Could for example be a revolving version of a circular logo, or a pulsating square logo. Depending on the urgency, the animation could repeat endlessly (highly distracting) or once in a while. Use with care :)
Pop-over box in a corner of the screen. This should give some context info, the primary object of which is to enable the user to decide whether or not it's worth checking out immediately. Could afford clicking by using a "More" link or big "+" sign.
Focus the application window immediately. Enormously intrusive, and should not even be used in case of nuclear meltdowns (what if the user already knows the meltdown is occurring, and is looking elsewhere for a solution?). Just don't.
I think an answer depends highly on the specifics of the UI you are working within. However, for general guides
The GNOME desktop environment's human interface guidelines (HIG) is a useful resource if your environment is GNOME, and perhaps informative if it's not. There is a section on using the "desktop notification area": http://library.gnome.org/devel/hig-book/stable/desktop-notification-area.html.en. This covers not overloading the area, etc. (perhaps analogous to the win32 tray).
Apple have their own HIG document. Part of this describes using the Dock for conveying status information: http://developer.apple.com/documentation/userexperience/Conceptual/AppleHIGuidelines/XHIGMOSXEnvironment/XHIGMOSXEnvironment.html#//apple_ref/doc/uid/TP40002721-TPXREF139
Apple also have a separate HIG document for the iPhone. there are several notification techniques described within, e.g. "alerts" http://developer.apple.com/iphone/library/documentation/UserExperience/Conceptual/MobileHIG/ModalViews/ModalViews.html#//apple_ref/doc/uid/TP40006556-CH11-SW1 which are specifically described as to be used for critical information (due to their disruptiveness).
Several apple iphone apps adjust their icon to convey some status info: e.g. mail, SMS, phone all indicate the number of outstanding mails, SMS messages, or missed calls/voicemails as part of their launch icon. I can't, however, find any reference to that in a cursory scan of the apple iphone HIG.
We are designing the UI for a new line of business application. We have no real constraints and are free to design the UI as we see fit. The UI will be done in WPF and targeted for Windows 7, Vista, and XP Pro users.
Many dialog boxes contain OK and Cancel buttons in their lower right corner. Do you feel it is necessary to have this Cancel button or is the red X in the upper right corner sufficient? We are discussing this as we have been noticing more UIs that do not have cancel buttons, only the red X.
Not only you should add it but also make sure ESC is mapped to it.
Present the two designs to the customer - one with the "Cancel" button, the other without. See what their thoughts are.
Better still present them as partially working prototypes and watch them as they use the dialogs. If you ask them to perform a set of tasks and see if they have trouble when asked to cancel an operation.
Having said that, my preference is to include a "Cancel" button for the reasons others have mentioned:
Accessibility (especially as Esc should be mapped to it).
Convention (users will be expecting it).
Include the Cancel button. The red X is VERY hard to tab to. ;)
Include it. This is very common in other user interfaces. Give the user the choice of which to use; making it for them might make them annoyed with your interface.
Users are used to having standard GUI layouts - otherwise they get confused. They also have different ways of using the standard interface. Some people only use the X, some people only use Cancel. People usually ignore the one they're not using, but get confused if their one isn't present. So be safe and keep them both in - it should only be a one-liner function for Cancek anyway.
Include it!
From a user interface perspective, not including a cancel button might leave some users feeling like they have no choice, which is certainly not the case. Imagine the following simple decision scenario:
Warning: All of the files in the selected folder will be deleted. This action cannot be undone. Are you sure you would like to continue?
How silly would an interface be if the only option was Ok? Also, as noted above, on many platforms the Escape key is mapped to Cancel. It's also probably worthwhile setting a default button so that pressing the Enter/Space key doesn't inadvertently perform the action that cannot be undone.
+1 on including it. If you don't include it now and then need some different functionality on Cancel to Close later on, your users will already be used to automatically closing.
Just like we have 'ESC' button on keyboard, we need 'Cancel' in dialogs.
A matter of usability :-)
Include it. And please also make sure that you make sure that hitting the Escape key does the same thing as the Cancel button.
Also, just because you're designing from scratch, please don't throw out all convention. Take a look at MSFT's UX Guidelines for dialog boxes.
The red button is really for 'Close' rather than 'Cancel'. 'Cancel' canceling a running task. Use a 'Close' button instead. And yes include the 'Close' if there is a reason for people to click on it. The red button is quite difficult to click when you really want to close something quickly.
If you have that kind of freedom, consider eliminating dialog boxes from your application entirely, especially ones with the typical "OK | CANCEL" paradigm. Dialog boxes disrupt the flow of action and generally should only be used for things which absolutely require the program to interrupt the user.
You'll notice how disruptive they are in the web environment -- e.g., Stack Overflow only uses them when it needs to be able to OVERRIDE your action, e.g., when you navigate away from an unsubmitted answer.
How would I go about implementing something along the lines of "scrubby sliders", like in Photoshop and quite a few other image-processing applications?
They are slightly hard to describe.. basically you have a regular numeric input-box, but you can click-and-hold the mouse button, and it functions like a slider (until you release). If you click in the box, you can select text, edit/paste/etc as usual.
The Photoshop docs describe it, and I put together a quick example video (an example of the sliders in Shake)
Another similar implementation would be the jog-wheel in Final Cut Pro, which functions similarly, without the numeric readout being underneath.
I can't seem to find any mention of implementing these, although there is probably alternative names for this. It is for a OS X 10.5 Cocoa application.
It is for a colour-grading application, where a user might need to make tiny adjustments (0.001, for example), to huge adjustments (say, -100 +100) on the same control. A regular slider isn't accurate enough over that range of value.
Copy-and-pasting values into the box would be a secondary concern to scrubbing the values, and the Photoshop/Shake setup really well. The unobviousness of the control is also of a low concern, as it's not a "regular desktop application"
I've encountered those. They suck, because they prevent the user from dragging to select the text of the number.
A better idea would be a miniature slider beneath the field that expands to a full-size slider when the user holds down the mouse button on it and collapses back to its miniature size when the user releases the mouse button. This way, the selection behavior is still available, but you also provide the slider—and in a more obvious way.
There's no built-in class in Cocoa for either one. You'll have to implement your own.
I doubt that this exists in Cocoa framework. As far as I remember it is not mentioned in the Apple Human Interface Guidelines.
You can develop one yourself by using a custom view and tracking mouse events (-mouseDown:, mouseUp:, -mouseDragged:).