Notification Example 3:
Again, OK and Close function as previously stated. Differently, due to the nature of this error, I’ve added a “Settings” button. The Settings button will take the user to the Settings Dialog box (shown in the Settings section of this document).
Note: Remember to be consistent! As you can see, most of the Notifications are the same size and in the same location (when possible). Except for the text, they all look similar and possess common attributes. Likewise, the preferred button choice on each of the Notifications should be highlighted for ease-of-use with the “Navigation” hardware key (aka D-Pad) on the Internet Tablet.
Main Menu
The Main Menu within the Facebook Status Updater application is going to be very simple. There are not many options to change, the only real function that the user has is entering text. But, according to what I’ve stated already, some common factors should be included in the application’s Main Menu. Below is a representation of how this application’s Main Menu should look.
As stated above, the Main Menu for this application contains all of the essentials and nothing more:
*
Edit
o
Cut
o
Copy
o
Paste
o
Select All
*
View
o
Full Screen
*
Tools
o
Settings
o
Help
o
About
*
Close
An application as simple as this doesn’t need much more anyway: the user can use the Edit functions in any of the text entry fields; they can view the application in Full Screen mode; the Settings can be accessed via the Tools menu, as can a Help screen (below) and the About screen (above); the application must have a common, standardized way to be Closed.
Help “Window”
A Help screen can work in several different ways. Choosing Help in the Main Menu can (1) open a web page in the Web Browser, (2) display a Help screen that is similar to the About screen, (3) access a Help file contained on the Internet Tablet (refer to the maemo SDK documentation), or (4) display a screen that says that Help is not available. Remember, even if you decide not to include Help for the application, a Help option should always be included in the Main Menu (see the Help section above). This will allow your users to feel more comfortable within the UI environment that you have created for them.
The Facebook Status Updater doesn’t need much in regards to a Help screen concerning the application itself, but there are a few aspects of Facebook that might require documentation. What I have decided to do is write up some simple instructions as well as appropriate a few items from the Facebook website itself.
Again, this screen is very simple. The only “extra” I have added is a way for people who do not yet have Facebook accounts to sign up. When users tap the green “Sign Up” button, they are taken to Facebook’s registration web page in the Web Browser.
Note: As with the About window, notice that a Return button has been added to this screen. This will return the user to the Main UI.
Closing the Application
I’ve talked a lot about the different Close options and Close buttons are available within maemo applications. That is because there are several ways to close an application (from the Main Menu, by tapping the button in the upper-right of the screen, from the Task Launcher on the side of the screen, by using other buttons a developer might create for a full-screen application, et cetera). No matter how you choose to allow a user to close an application, remember to be consistent. Make every method identical so that the user doesn’t have to wonder whether or not they did something wrong. Provide the user with an easy means to close the application and always let them know what they are doing.
My theory is that, since applications on handheld devices are often easy to close by mistake (whether a user unintentionally chooses the Close option in the Main Menu or the device registers a double-tap instead of a single-tap from an application that is on top of another application, et cetera), applications must allow the user to “undo” what they may have not meant to do. This means including some sort of Dialog box or Notification message to the user so that they can confirm whether or not they really wanted to close the application.
In the case of Facebook Status Updater I have opted for a Confirmation note to appear when a user closes the application. Again, it is simple, but vastly important in providing a standard, intuitive experience for the user.
It’s not the prettiest thing (on purpose), but what we’re really trying to do is make something that is recognizable to users and can be launched from the Hildon desktop.
Common & Consistent UI Elements
Most of what needs to go into the Flickr Uploadr UI has already been discussed above, so I won’t bother mentioning many of those concepts. But, because of the added functionality in this application, a few new UI elements must be added so that users will get the full potential out of the application while still feeling at home in a consistent UI environment.
Settings “Window”
As with Facebook Status Updater, Flickr Uploadr will require the user to edit the Settings in order that the application can communicate with the Flickr API. Because of this, Flickr Uploadr should launch similarly to the aforementioned application: with the Settings screen on top, ready to be edited.
This time, since there is more content on the Application Area (all of the pieces that make up the main UI of the application), I didn’t really try to “fit” the Settings Dialog box into the design of the application like I did before. Here, I just overlaid the Dialog box onto the center of the Application Area.
Note: Remember that after the Settings information has been entered and saved, the next time the user launches the application, it should take them directly to the main UI.
Main UI
The Main UI for Flickr Uploadr is still fairly simple. In fact, this is something to keep in mind for any application that you might develop: keep it clean, don’t try to fit too much on the screen at once, adhere to standards, be consistent.
In the above example, I have populated the text entry fields and drop-down menus in order to demonstrate what each area is intended for. In a working version of this application, these areas would most likely be blank.
There are a few new concepts in the UI above:
*
Image: A path to the image that the user has selected to upload (populated automatically when the user selects an image in the Hildon File Manager).
*
Tags: A text entry field that will allow users to enter Tags to the image that they will upload.
*
Your Tags: A drop-down list of Tags that the user has already used (populated by retrieving them from the user’s Flickr account)
*
Your Photo Sets: A drop-down list of the user’s Photo Sets (populated by retrieving them from the user’s Flickr account)
*
Select: Triggers the Hildon File Manager for the user to find and select an image to upload.
*
Refresh: Refreshes the “Your Tags” & “Your Photo Sets” lists by retrieving the data from the user’s Flickr account.
*
Upload: Uploads the selected image. Notice that this button is currently grayed-out. This is to signify that an image has not yet been selected. It should become active once an image is selected from the device:
Image Field
Most of the concepts presented in this UI are easily understood. One item, though, may be confusing to a user (or, at least make the user unsure of what to do): the Image field. There are two ways that this field can work:
1.
Make it an information-only field that can’t be edited by the user. The field could be darkened a little to look differently than other, editable fields, and only display information after the user selects an image in the Hildon File Manager.
2.
Leave the field editable. This would be my preference, as sometimes users know exactly where their images are and they are comfortable with inputting file paths. While this logic has the potential to “break” things within the application, most issues can be solved with simple error messages and a good Help section. (I was pleasantly surprised the other day when I used the word “attachment” in an email I was writing in Claws-Mail. When I tapped the Send button before remembering to attach a file, Claws-Mail was nice enough to realize my mistake. I was prompted by an error message that asked me if I wanted to go back and attach a file or send the email anyway.)
“Tags” vs. “Your Tags”
Another function that may be confusing is the Tags text entry field and the Your Tags drop-down menu. While both functions can be sufficiently described in the Help section (Flickr has fairly liberal methods in dealing with tagging images), explaining how the two functions work together might be a little more difficult.
In the Tags field, users can enter Tags, whether new or old, to their images. When the user selects a Tag from the Your Tags drop-down menu, though, that tag will be automatically entered into the Tags field. That way, users can scroll through their existing Tags and have them entered for their image. Entering a Tag manually and/or with the Your Tags function should work seamlessly (Flickr can even automagically delete duplicate Tags).
Note: Flickr doesn’t actually need Tag information for a successful image upload, so these functions are optional.
Your Photo Sets
The Your Sets function will allow the user to choose from any of their preexisting Photo Sets. This way, they can easily send their image to the correct Photo Set on Flickr (users can only select one Photo Set per image using this method).
Note: Flickr doesn’t actually need Photo Set information for a successful image upload, so this function is optional.
Uploading Images to Flickr
Uploading images to Flickr is very straight-forward. Once an image is selected, Tags and a Photo Set are chosen (or not), and the user taps Upload, the file should be sent to their Flickr account. Of course, during this process, the Hildon Progress Banner should be used and proper Notification and error messages should be used depending on how the application communicated with the Flickr API.
Main Menu
Much of the Main Menu for any application is similar. But, Flickr Uploadr’s additional functionality requires that a couple of new items be added to the Main Menu:
*
File
o
Select Image from Device
o
Refresh all Tags & Photo Sets
o
Upload Image to Flickr
*
Edit
o
Cut
o
Copy
o
Paste
o
Select All
*
View
o
Full Screen
*
Tools
o
Settings
o
Help
o
About
*
Close
The “File” menu is a generic term that can be used when adding options that are specific to the application and deal with current, working “files” within the application.
An example where this standard was not used is in the “official” Notes application on the Internet Tablet. Instead of using “File” as the menu title in the Main Menu, “Note” was used. While the “Note” menu serves the same purpose as a “File” menu, the different use of terms is somewhat confusing and requires the user to see what’s actually contained in the menu to know what it’s for. A simple change of terms would have made this menu much more intuitive and seamless.
File > Select Image from Device
The Select Image from Device option should trigger the standard Hildon File Manager and allow the user to locate an image file for upload to Flickr. Many times, I have noticed that developers don’t use the Hildon File Manager. I’m sure there is a good reason for this, but the fact is, it is very confusing. When a novice user opens an application, they expect to be able to understand what to do and where to go within the application. If a concept is introduced that is not part of a device’s main UI, it can be unsettling. Lack of consistency alone can be the reason that a user decided to uninstall an otherwise useful application.
Below is an example of what the user should see when they use the “Select Image” menu option:
Here, I have also titled the File Manager Dialog box, “Select Image.” This keeps the user immersed in the terminology of the application and is another minor aspect that can aid in reducing confusion.
File > Refresh all Tags & Photo Sets
Refresh all Tags & Photo Sets will retrieve and populate the Tags & Photo Sets drop-down menus (shown above) from the user’s Flickr account. This function works the same as the Refresh button on the main UI.
File > Upload Image to Flickr
This option will upload the selected file to Flickr. (If a file is not selected, this option should be grayed-out and inactive.)
Closing the Application
Remember to consistently trigger a Confirmation note or Dialog box for every method that a user can close the application. While choosing not to use a Confirmation note upon closing an application is entirely up to the developer, I must stress the consistency aspect of this action. Don’t display a Confirmation note when the user uses the Close button, but not when the user uses the Close menu option, et cetera.
Consistency, consistency, consistency!
Have I mentioned consistency enough throughout this document? If so, I will make no apologies for bringing it up again. Consistency can never be stressed enough. It is one of the most under-utilized concepts in application development — especially in the world of open source software. Yes, it’s exciting to develop and release applications, but just a little extra time and thought concerning the overall usability will add invaluable quality to all applications.
As an example of well-applied consistency, I'd like to point out the commonalities between the main UI of Flickr Uploadr and its Main Menu. Aside from being more descriptive, the three options under the “File” menu, are almost identical to what the user will find on the main UI. Elements like this will help to ease the user into a mindset that needs little to no instruction. Always attempt to give users an experience that, quite possibly, will allow them to use the application without ever referring to the Help section.
Likewise, all of the terms that are used within the Flickr Uploadr UI are terms that were taken from “official” applications that come loaded on the Nokia Internet Tablets. It is not a mistake that I titled the button/menu option as “Close” rather than “Quit” or “Exit”; I didn’t introduce my own term by creating a “Select” button rather than a “Browse” button; I used the term “Refresh” because it is the same term used within the maemo Application Manager for refreshing the Application Catalogs... Each interface element mimics what can be found on an Internet Tablet the first time it is turned on.
Of course, there is some terminology that will be specific to certain applications. In these cases, developers must think of what function they are trying to describe and come up with the proper term for the function. Use a dictionary. Look at other applications. Try, to the best of your abilities, to come up with something that is as universal as possible.
Consistency in graphical form?
Graphics are an area of application development that throw a small wrench into the idea of consistency. While I would like to say that all developers should approach creating and using graphics with the same methods and approach, it will probably never happen. If anything, always rely on the basic tools contained within the maemo SDK. Most of the important graphical UI elements that are needed for any application are already available and do not need to be recreated.
Conversely, some developers prefer simple designs and some enjoy making things “pretty.” The two case-studies that we just reviewed are good examples of the different uses of graphics on buttons. In the Facebook Status Updater application I chose to add small icons to all of the buttons. For Flickr Uploadr I opted to use plain buttons with no graphics.
Graphics can also be added to menu items as well. Here is an example of the menu used in the Evince Document Viewer:
As you can see, the small icons can be helpful, but they are definitely not necessary. What is important is that developers remain consistent with whatever choice they make. Don’t include graphics in some places but not on others.
Either choose to use graphics or don’t. Each method works without breaking the flow of a “most excellent” user-experience, so it is up to the developer as to which route to take. Equally persuading arguments can be made for each one: whether graphics help the user understand functions without needing the ability to read or whether the addition of extra graphics just causes clutter is a debate that I'll leave for another time.
Lastly, be consistent when placing and sizing graphics and other commonly used UI elements. Graphical additions to a UI can either add greatly to design and functionality or completely break it. When designing the look of an application give some concern to how elements work together on-screen. Users will quickly be averted from using an application because of sloppy use of these common UI components.
Conclusion
I understand that the creation of this document is much easier than creating an application in the maemo development platform. But, I think one of the main issues that prevents standards and consistency from being a part of every application is that not every developer is familiar with the maemo SDK features and documentation. Rapid development of quality applications isn’t impeded by using the SDK rather it is helped. Don’t try to reinvent the wheel when many of the items needed fore development already exist. The maemo development platform has made a number of tools and functions available for your disposal. Things like buttons, Dialog boxes, Progress Banners, et cetera — unless you are purposely attempting to create a unique graphical experience (think Canola or maemo Mapper) — can easily be requisitioned from the maemo SDK.
Put some time into planning your application before you begin development. Creating a document similar to this can also be very helpful (there were a few occasions where I had to go back and recreate a graphic example because what I was writing about it didn’t make sense, needed another feature, or just needed refinement). Likewise, documenting your process will allow you to check spelling and punctuation, and get an overall idea of how your application is going to be pieced together (after all, it’s easier to Cut & Paste in a Word doc than in the Scratchbox programming environment). Outline your process, invent test cases, find other people to give you feedback... Most of all, remember that the average Internet Tablet user is not a developer. Put thought into how you can develop an application that is easy, intuitive, and functions the way people expect it to function.
End of the article@!
No comments:
Post a Comment