continued from previous article click here for previous articleAbout “Window”The About Menu can be very simple (text only) or it can be complex (text, graphics, hyperlinks, et cetera). Earlier, I talked about creating a Splash screen to use as your About screen. Below is an example that I created for the Facebook Status Updater application (the blue email/hyperlinks can actually trigger Email and Web Browser!):
Note: Of course, the user must have a way to get back to the main UI, which is why the Return button has been added to the About screen.
Close Options
The Close option is self-explanatory. It will close the current application. It should act the same way as the Close button in the upper-right of the screen in Normal mode. Closing an application can’t be undone so adding a Confirmation note is always helpful. This should be included for the Main Menu Close option as well as the Close button in the upper-right of the screen. It can say something as simple as:
“Are you sure you want to close this application? Yes/No”
Note: When applications are open, the Application Switcher displays a “double-arrow” icon. Tapping this displays a menu containing all of the open applications. Next to each application is another Close [x] button. This should act in a similar manner to the Close functions described above.
Full Screen Mode vs. Normal Mode
When in Full Screen mode, the “normal” Hildon UI options function a differently than in Normal mode. This can be used to the developer’s advantage. Full Screen-only applications operate on different terms than windowed applications and don’t always require every function to be available to the user. In this case, the developer must determine what options are required and how to best convey that information to the user.
First, the Main Menu cannot be triggered by tapping on the Title Area (as the title is hidden in this mode), but it can be triggered by pressing the Menu Key (the hardware button on the left side of the Internet Tablet, pictured). The Menu Key will trigger the same Main Menu that is accessed by tapping the Title Area.
Second, in Full Screen mode, the Close/Minimize buttons are not available on the UI. This requires some thought as to how one might make these functions available within an application. Usually, it is accomplished by placing an Exit button somewhere within the application’s Application Area (whether it be a text or a graphic).
In my experience, it is wise to allow users to switch any application to and from Normal and Full Screen modes. But, this feature can, and should, be left up to the developer’s discretion. If you choose to create a Full Screen-only application, make sure the user has every means of returning to their Home Screen (i.e., the Hildon desktop). If you choose to allow your application to be viewed in Normal mode, remember to include all of the Main Menu functions as described above.
Close & Minimize Buttons
The Close and Minimize buttons may seem self-evident, but there are a number of applications that don’t use them in the correct way. One, for instance is GPE Calendar. In order for GPE Calendar to function properly (i.e., so that event alarms set within GPE Calendar will work), the Close button actually only minimizes GPE Calendar. In order to close the application, one must go to the Main Menu and select Close from the menu. While the reason for this is clear, the functionality is very confusing. In making decisions such as this, developers must consider the standards before they implement functionality that is completely different than users expect. GPE Calendar does have a Minimize button at the upper-right of the screen (as all applications do when in Normal mode), so why not allow the user to utilize the tools that they are familiar with?
Application Area
The Application Area is virtually left up to the developer’s discretion concerning the design of the application. Although, there are a couple of things to keep in mind:
*
Decide whether menu items (whether on-screen menus triggered by a word or graphic or “tap-and-hold,” Context Sensitive menus) might be better suited under the Main Menu.
*
If the application can only run in Full Screen mode, try to design a menu paradigm that’s similar to what one might find in the Main Menu in a Normal mode application.
*
Closing a Full Screen mode application isn’t always easy to decipher. Create a clear method for users to close the application. When users do attempt to close the application, trigger a Confirmation note if at all possible.
*
Whenever there are text entry fields, try to design them so that the virtual keyboard does not cover them when triggered.
*
Try to fit your content into the Application Area (whether in Normal or Full Screen mode) without the need for scroll bars.
Note: There are plenty of other pieces of advice that could be offered here. Mainly, don’t be haphazard: design on a grid, keep it simple, take pride in your application.
Application Development
At this point, I’m going to begin the step-by-step process of developing my first fictitious application, Facebook Status Updater. I will attempt to go through each of the sections that I’ve already described in further detail, outlining why I make certain decisions and some alternate ideas to think about when creating your own applications.
Facebook Status Updater
The Facebook Status Updater application is pretty straight-forward in terms of a UI. Honestly, I don’t know how difficult it would be to program a maemo application that communicates with the Facebook API (although, I assume it wouldn’t be too hard), so I’ll leave that subject for those who are more code-savvy than myself.
The application’s functions are simple:
*
Must prompt user to set their Facebook username (in this case, the user’s email address) and password
*
Must store user’s username and password
*
Must provide a text entry field for typing the current status
*
Must have a way to send the status to Facebook
*
Must confirm that Facebook has received or rejected the new status
But, first things first... We need an icon!
This icon will serve as the means for launching the application from the Hildon desktop. It is their link to a graphical environment that should not be tainted by anything as evasive as xterm or the like.
I have decided that when the user launches the Facebook Status Updater application, it should go straight to the application rather than displaying a Splash screen (which can be reserved for the About screen as discussed earlier). I’ve also deemed it unnecessary to use a Toolbar at the bottom of my UI. So, what does the Facebook Status Updater UI look like?
First, I need to decide where to direct the user when Facebook Status Updater is launched for the first time. At this point, since the user hasn’t entered their Facebook login info, there are a few different routes I could take:
1.
Terrible: Let the user figure it out on their own. There will be a Settings option under the Main Menu after all.
2.
Bad: Display an error Notification when the application starts (“Login failed! No login information.”)
3.
Better: Display an error with a solution (“Login failed! Please enter your login information in the Settings.”)
4. The “right” way: Trigger the Settings window right away!
Note: Be descriptive when creating Dialog boxes. Notice that I have called this box, “Facebook Login.” Always try to let the user know exactly what they are doing.
At this point, the user can enter their information (the populated text above has just been entered for the purpose of this document), tap OK and be on their way. If the user taps Cancel, then the application will stay open, but they won’t be able to do anything other than go to the Settings option and enter their information (or close the application, of course). If they attempt to send and data to Facebook, an error message will be triggered (explained below).
If they cancel the Settings and close the application, then, upon their return, this Dialog box will appear again. But, if the user enters the information and taps OK, this Dialog box should not appear again when the application is relaunched — the user should be delivered directly to the main UI.
Note: This is an appropriate place to bring up some concepts about text entry fields within maemo applications:
*
By default, tapping on a text entry field will trigger the virtual keyboard with Shift activated (i.e., the first letter typed will be capitalized). If you’re creating a text entry field where the usual user entry might be lower case, then code your application to respond that way.
*
If you create a text entry field that can only accept numbers, then code your application to trigger the virtual keyboard in number-entry mode.
*
If the text entry field is for passwords, be sure to use the recommended procedures for obfuscating the password with asterisks.
*
If the virtual keyboard covers any of the text entry fields within an application, code the application to shift the text entry fields up when the virtual keyboard is triggered.
Main UI
Once the user’s information is set and they tap OK, then the Settings Dialog box will disappear and they will be allowed access to the main UI:
Notice that this screen is exactly like the previous screen, except that the Dialog box is not present. It is, in fact, the same screen. All I did prior to this was make the Dialog box appear over the main UI. (It is not always necessary to design your Dialog boxes into the UI (as you will see in the description of the Flickr Uploadr application, but for this example I thought it would work well.)
Now, the user can enter their current status in the text entry field, and tap Update so that the information will be sent and posted to their Facebook profile. This should trigger the Hildon Progress Banner in the upper-right of the screen:
Note: I’d like to interject that any application that requires the user to wait should trigger some sort of progress indicator that lets them know that the application is processing. In my opinion, a standard should be set as to what style of progress indicator is used within all maemo applications. Since the style shown above is what all “official” maemo applications use, I would vote that it be the one that developers should use within their application development (rather than an animated progress bar, et cetera). Also, this style of progress indicator disallows the user from tapping the Application Area, until it goes away, so it serves a functional purpose as well.
For next follow this link
