Palm webOS: Developing Applications in Javascript Using the Palm Mojo Framework – Page 5
There are some foundational principles or values that support the overall webOS user experience; application designers can exploit these same principles to more deeply integrate the application into the overall device experience and enhance the user’s experience. Developers can rely on the framework to provide most of what is required at an implementation level, but the application design should anticipate these needs.
Here are the key principles to keep in mind while designing your application:
- Physical metaphors are reinforced through direct interaction with application objects and features, instant response to actions, followed by smooth display and object transitions with physics-based scrolling and other movement. For example, objects are deleted by flicking off screen and editing is in place without auxiliary dialogs or scenes.
- Maintain a sense of place with repeatable actions, reversible actions, stable object placement and visual transitions taking the user from one place to the next.
- Always display up-to-date data, which requires both pushing and pulling the latest data onto the device so that the user is never looking at stale data when more recent data is available. But this also means managing on-device caches so that when the device is out of coverage or otherwise off-line, the user has access to the last data received.
- Palm webOS is fast and simple to use; all features should be designed for instant response, easy for novices to learn while efficient for experienced users.
- Minimize the steps for all common functions; put frequently executed commands on the screen, the next most frequent under the menus. Avoid preferences and settings where possible and where not, keep them minimal.
- Don’t block the user; don’t use a modal control when the same function can be carried out non-modally.
- Be consistent; help the user learn new tasks and features by leveraging what they have already learned.
Palm applications have always been built around a direct interaction model, where the user touches the screen to select, navigate, and edit. Palm webOS applications have a significantly expanded vocabulary for interaction, but they start at the same place. Your application design should be strongly centered on direct interaction, with clear and distinguishable targets. The platform will provide physical metaphors through display and navigation, but applications need to extend the metaphor with instantaneous response to user actions, to smoothly transitioning display changes, and object transitions.
You can find a lot more on the user interface guidelines and design information in the Palm webOS SDK under the Design Guide. We’ll touch on the principles and reference standard style guidelines in the next few chapters, but will not be covering this topic in depth.
A webOS application is similar to a web application based on standard HTML, CSS, and JavaScript, but the application lifecycle is different. Applications are run within the UI System Manager, an application runtime built on standard browser technology, to render the display, assist with events, and handle JavaScript.
The webOS APIs are delivered as a JavaScript framework, called Mojo, which supports common application-level functions, UI widgets, access to built-in applications and their data, and native services. To build full-featured webOS applications, many developers will also leverage HTML5 features such as video/audio tagging and database functions. Although not formally part of the framework, the Prototype JavaScript framework is bundled with Mojo to assist with registering for events and DOM handling among many other great features.
The framework provides a specific structure for applications to follow based on the Model-View-Controller (MVC) architectural pattern. This allows for better separation of business logic, data, and presentation. Following the conventions reduces complexity; each component of an application has a defined format and location that the framework knows how to handle by default.
You will get a more extensive overview of Mojo in Chapter 2, and details on widgets, services and styles starting in Chapter 3. For now, you should know that the framework includes:
- Application structure, such as controllers, views, models, events, storage, notifications, logging and asserts;
- UI widgets, including simple single-function widgets, complex multi-function widgets and integrated media viewers;
- Services, including access to application data and cross-app launching, storage services, location services, cloud services, and accelerometer data;
Outside of the built-in applications, webOS applications are deployed over the web. They can be found in Palm’s App Catalog, an application distribution service, built into all webOS devices and available to all registered developers. The basic lifecycle stages are illustrated in Figure 1-9.
Downloading an application to the device initiates installation of the app provided that it has been validly signed. After installation the application will appear in the Launcher. If it is a headless application, then a card is not required and instead the application can utilize just a dashboard and communicate to the user through notifications. Headless applications typically include a simple card based preferences scene to initiate the application and configure its settings. Note that headless applications require at least one visible stage at all times (either a card, dashboard or alert) to not be shut down.
Other applications are launched from the launcher into the foreground and may be switched between foreground and background by the user. Each of these state changes (launch, deactivate, activate, close) is indicated by one or more events. Applications are able to post notifications and optionally maintain a dashboard while in the background.
Applications are updated periodically by the system. If running, the application is closed, the new version installed, and then it’s launched. There isn’t an update event so the app needs to reconcile changes after installation, including data migration or other compatibility needs.
The user can opt to remove an application and its data from the device. When the user attempts to delete an application, the system will stop the application if needed and remove its components from the device. This includes removing it from the launcher and any local application data, plus any data added to the Palm application databases such as Contacts or Calendar data.