Software Engineering Discussion

SECH13.pdf

Home >Computer Science homework help >Software Engineering Discussion

264

C H A P T E R

What is it? Mobile design encompasses techni cal and nontechnical activities that include: establishing the look and feel of the mobile application (including mobile apps, WebApps, virtual reality, and games), creating the aes thetic layout of the user interface, establish ing the rhythm of user interaction, defining the overall architectural structure, develop ing the content and functionality that re side within the architecture, and planning the navigation that occurs within the mobile product.

Who does it? Software engineers, graphic de signers, content developers, security special ists, and other stakeholders all participate in the creation of a mobile design model.

Why is it important? Design allows you to cre ate a model that can be assessed for quality and improved before content and code are generated, tests are conducted, and end

users become involved in large numbers. Design is the place where mobile app quality is established.

What are the steps? Mobile design encom passes six major steps that are driven by infor mation obtained during requirements modeling and are described in this chapter.

What is the work product? A design model that encompasses content, aesthetics, archi tecture, interface, navigation, and component level design issues is the primary work product that is produced during mobile design.

How do I ensure that I’ve done it right? Each element of the design model is reviewed in an effort to uncover errors, inconsistencies, or omissions. In addition, alternative solutions are considered, and the degree to which the current design model will lead to effective implementation on a variety of software plat forms and devices is also assessed.

Q u i c k L o o k

aesthetic design . . . . . . . . . . . . . . . . . . . . . . . 277 architecture design . . . . . . . . . . . . . . . . . . . . .278 challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . .265 cloud computing . . . . . . . . . . . . . . . . . . . . . . .273 component-level design . . . . . . . . . . . . . . . . .282 content architecture . . . . . . . . . . . . . . . . . . . .279 content design . . . . . . . . . . . . . . . . . . . . . . . . . 277 content objects . . . . . . . . . . . . . . . . . . . . . . . . 277 context-aware apps . . . . . . . . . . . . . . . . . . . .274 design

best practices . . . . . . . . . . . . . . . . . . . . . . .285 mistakes . . . . . . . . . . . . . . . . . . . . . . . . . . .272

pyramid . . . . . . . . . . . . . . . . . . . . . . . . . . .275 quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . .282

graphic design . . . . . . . . . . . . . . . . . . . . . . . . . 277 mobile architectures . . . . . . . . . . . . . . . . . . . .273 mobile development life cycle . . . . . . . . . . . .268 model-view-controller . . . . . . . . . . . . . . . . . . .279 navigation design . . . . . . . . . . . . . . . . . . . . . .280 quality checklist . . . . . . . . . . . . . . . . . . . . . . . .285 technical considerations . . . . . . . . . . . . . . . . .266 user interface design . . . . . . . . . . . . . . . . . . .270 WebApp architecture . . . . . . . . . . . . . . . . . . .279

k e y c o n c e p t s

Design for Mobility

Mobile devices—smartphones, tablets, wearable devices, handheld gaming devices, and other specialized products—have become the new face of comput- ing. According to Pew Research Center [Pew18], in the United States 77 percent of people own a smartphone and 50 percent of people own a tablet computer of some kind. Mobile computing has become a dominant force.

CHAPTER 13 DESIGN FOR MOBILITY 265

In his authoritative book on Web design, Jakob Nielsen [Nie00] states: “There are essentially two basic approaches to design: the artistic ideal of expressing yourself and the engineering ideal of solving a problem for a customer.” During the first decade of mobile development, the artistic idea was the approach that many developers chose. Design occurred in an ad hoc manner and was usually conducted as HTML was generated. Design evolved out of an artistic vision that evolved as Web page construc- tion occurred.

Even today, many developers use mobile apps as poster children for “limited design.” They argue that immediacy and volatility of the mobile market mitigate against formal design; that design evolves as an application is built (coded), and that relatively little time should be spent on creating a detailed design model. This argu- ment has merit, but only for relatively simple apps. When content and function are complex; when the size of the mobile app encompasses hundreds or thousands of content objects, functions, and analysis classes; and when the success of the app will have a direct impact on the success of the business, design cannot and should not be taken lightly. This reality leads us to Nielsen’s second approach—“the engineering ideal of solving a problem for a customer.”

13.1 th e ch a L L e ng e s

Although mobile devices have many features in common with each other, their users often have very different perceptions of what features they expect to be bundled in each. Some users expect the same features that are provided on their personal comput- ers. Others focus on the freedom that portable devices give them and gladly accept the reduced functionality in the mobile version of a familiar software product. Still others expect unique experiences not possible on traditional computing or entertain- ment devices. The user’s perception of “goodness” might be more important than any of the technical quality dimensions of the mobile product itself.

13.1.1 Development Considerations Like all computing devices, mobile platforms are differentiated by the software they deliver—a combination of operating system (e.g., Android or iOS) and a small sub- set of the hundreds of thousands of mobile software products that provide a very wide range of functionality. New tools allow individuals with little formal training to create and sell apps alongside other apps developed by large teams of software developers.

Even though apps can be developed by amateurs, many software engineers think that MobileApps are among the most challenging software systems being built today [Voa12]. Mobile platforms are very complex. Both the Android and iOS operating systems contain over 12 million lines of code. Mobile devices often have mini brows- ers that will not display the full set of content available on a Web page. Different mobile devices use different operating systems and platform-dependent development environments. Mobile devices tend to have smaller screen sizes and more varied screen sizes than personal computers. This may require greater attention to user inter- face design issues, including decisions to limit display of some content. MobileApps

266 PART TWO MODELING

must be designed to take intermittent connectivity outages into account, limitations on battery life, and other device constraints1 [Whi08].

System components in mobile computing environments are likely to change their locations while their apps are running. To maintain connectivity in nomadic net- works,2 coordination mechanisms for discovering devices, exchanging information, maintaining security and communication integrity, and synchronizing actions must be developed. There is always a trade-off between security and other elements of the mobile product design.

In addition, software engineers must identify the proper design trade-offs between the expressive power of the MobileApp and stakeholder security concerns. Developers must seek to discover algorithms (or adapt existing algorithms) that are energy effi- cient to conserve battery power when possible. Middleware may have to be created to allow different types of mobile devices to communicate with each other in the same mobile networks [Gru00].

Software engineers should craft a user experience that takes advantage of device characteristics and context-aware applications. The nonfunctional requirements (e.g., security, performance, usability) are a bit different from those for either WebApps or desktop software applications. There is always a trade-off between security and other elements of the mobile design. Testing mobile software products (Chapter 21) pro- vides additional challenges because users expect that they will work in a large number of physically different environments. Portability is another challenge for software engi- neers as there are several popular device platforms. It is expensive to develop and support applications for multiple device platforms [Was10].

13.1.2 Technical Considerations The low cost of adding Web capabilities to everyday devices such as phones, cameras, and TVs is transforming the way people access information and use network services [Sch11]. Among the many technical considerations that MobileApps should address are the following:

Multiple hardware and software platforms. It is not at all unusual for a mobile product to run on many different platforms (both mobile and station- ary) with a range of differing levels of functionality. The reasons for these differences are in part because the hardware and software available are quite different from device to device. This increases both development cost and time. It also can make configuration management (Chapter 22) more difficult. Many development frameworks and programming languages. Mobile products are currently being written in several distinct programming or script- ing languages (e.g., HTML5, JavaScript, Java, Swift, and C#) for a multitude of popular development frameworks (e.g., Android, iOS, Xamarin, Windows, AngularJS). Very few mobile devices allow direct development on a device itself. Instead, mobile developers typically use emulators running on desktop

1 Available at http://www.devx.com/SpecialReports/Article/37693. 2 Nomadic networks have changing connections to mobile devices or servers.

CHAPTER 13 DESIGN FOR MOBILITY 267

development systems. These emulators may or may not accurately reflect the limitations of the device itself. Thin-client applications are often easier to port to multiple devices than applications designed to run exclusively on the mobile device. Many app stores with different rules and tools. Each mobile platform has its own app store and its own standards for accepting apps (e.g., Apple,3 Google,4 Microsoft,5 and Amazon6 publish their own standards). Development of a mobile product for multiple platforms must proceed separately, and each version of the app needs its own standards expert. Very short development cycles. The marketplace for mobile products is very competitive, and software engineers are likely to make use of agile development processes when building MobileApps in an effort to reduce development time [Was10]. User interface limitations and complexities of interaction with sensors and cameras. Mobile devices have smaller screen sizes than personal computers and a richer set of interaction possibilities (touch, gesture, camera, etc.) and usage scenarios based on context awareness. The style and appearance of the user interface is often dictated by the nature of platform-specific development tools [Rot02]. Allowing smart devices to interact with smart spaces offers the potential to create personalized, networked, high-fidelity application platforms such as those seen by merging smartphones and car infotainment systems.7

Effective use of context. Users expect MobileApps to deliver personalized user experiences based on the physical location of a device in relation to the available network features. User interface design and context-aware applica- tions are discussed in greater detail in Section 13.4. Power management. Battery life is often one of the most limiting constraints on many mobile devices. Backlighting, reading and writing to memory, using wireless connections, making use of specialized hardware, and processor speed all impact power usage and need to be considered by software developers [Mei09]. Security and privacy models and policies. Wireless communication is dif- ficult to protect from eavesdropping. Preventing man-in-the-middle-attacks8 in automotive applications can be critical to the safety of the users [Bos11]. Data stored on a mobile device are subject to theft if a device is lost or a malicious app is downloaded. Software policies that increase the level of con- fidence in the security and privacy of a MobileApp often reduce the usability of the app and the spontaneity of the communication among users [Rot02].

3 https://developer.apple.com/appstore/guidelines.html. 4 http://developer.android.com/distribute/googleplay/publish/preparing.html. 5 http://msdn.microsoft.com/en-us/library/ff941089%28v=vs.92%29.aspx. 6 https://developer.amazon.com/apps-and-games/app-submission/android. 7 When used in an automotive setting, smart devices should be able to restrict access to

services that may distract the driver and allow hands-free operation when a vehicle is moving [Bos11].

8 These attacks involve a third party intercepting communications between two trusted sources and impersonating one or both of the parties.

268 PART TWO MODELING

Computational and storage limitations. There is great interest in using mobile devices to control home environmental and security services. When MobileApps are allowed to interact with devices and services in their environ- ment, it is easy to overwhelm the mobile device (storage, processing speed, power consumed) with the sheer volume of information [Spa11]. Developers may need to look for programming shortcuts and means of reducing the demands made on processor and memory resources. Applications that depend on external services. Building thin mobile clients suggests the need to rely on Web service providers and cloud storage facilities. This increases concerns for both data or service accessibility and security [Rot02]. Testing complexity. Mobile products that run entirely on the device can be tested using traditional software testing methods (Chapters 19 and 20) or using emulators running on personal computers. Thin-client MobileApps are particularly challenging to test. They exhibit many of the same testing chal- lenges found in WebApps, but they have the additional concerns associated with transmission of data through Internet gateways and telephone networks [Was10]. Testing of mobile software products will be discussed in Chapter 21.

13.2 Mo b i L e De v e L o p M e n t Li f e cyc L e

Burns [Bur16] and her Microsoft colleagues describe a recommendation for an iterative mobile SDLC that contains five major stages:

Inception. Goals, features, and functions of the mobile product are identified to determine the scope and the size of the first increment or feasibility prototype. Developers and stakeholders must be conscious of human, social, cultural, and organizational activities that may reveal hidden aspects of the users’ needs and affect the business targets and functionality of the proposed mobile product.

Design. The design includes architectural design, navigation design, interface design, content design. Developers define the app user experience using screen mockups and paper prototypes to help create a proper user interface design that will take different screen sizes and capabilities into account as well as the capabilities of each targeted platform.

Development. Mobile software is coded, functional and nonfunctional. Test cases are created and executed, and usability and accessibility evaluations are con- ducted as the product evolves.

Stabilization. Most mobile products go through a series of prototypes: feasibility prototype, intended as a proof of concept with perhaps only one complete logic path through the application; alpha prototype, which contains the functionality for minimum viable product; beta prototype, which is largely complete and contains most tested functionality; and lastly the release candidate, which contains all required functionality, for which all scheduled tests have been completed, and which is ready for review by the product owner.

CHAPTER 13 DESIGN FOR MOBILITY 269

Deployment. Once stabilized, a mobile product is reviewed by a commercial app store and made available for sale and download. For apps intended for internal com- pany use only, a product owner review may be all that is required before deployment.

Mobile development makes use of an agile, spiral engineering process model. The stages are not completed in order like they would be if mobile development was done using the waterfall model. The stages described above are visited repeatedly as developers and stakeholders gain better understanding of the user needs and product business goals.

Formulating Mobile Device Requirements

The scene: A meeting room. The first meeting to identify

requirements for a mobile version of the SafeHome WebApp.

The players: Jamie Lazar, software team member; Vinod Raman, software team mem ber; Ed Robbins, software team member; Doug Miller, software engineering manager; three members of marketing; a product engineering representative; and a facilitator.

The conversation: Facilitator (pointing at whiteboard): So that’s the current list of objects and services for the home security function present in the WebApp.

Vinod (interrupting): My understanding is that people want SafeHome functionality to be accessible from mobile devices as well . . . including the home security function?

Marketing person: Yes, that’s right . . . we’ll have to add that functionality and try to make it context aware to help personalize the user experience.

Facilitator: Context aware in what sense?

Marketing person: People might want to use a smartphone instead of the control panel and avoid logging on to a website when they are in the driveway at home. Or they might not want all family members to have access to the mas ter control dashboard for the system from their phones.

Facilitator: Do you have specific mobile devices in mind?

Marketing person: Well, all smartphones would be nice. We will have a Web version done, so won’t the MobileApp run on all of them?

Jamie: Not quite. If we took a mobile phone browser approach, we might be able to reuse a lot of our WebApp functionality. But remember, smartphone screen sizes vary, and they may or may not all have the same touch capabilities. So, at the very least we would have to create a mobile website that takes the features of each device into account.

Ed: Perhaps we should build the mobile version of the website first.

Marketing person: OK, but a mobile website solution wasn’t what we had in mind.

Vinod: Each mobile platform seems to have its own unique development environ ment, too.

Production rep: Can we restrict MobileApp development to only one or two types of smartphones?

Marketing person: I think that might work. Unless I’m mistaken, the smartphone market is dominated by two smartphone platforms right now.

Jamie: There’s also security to worry about. We better make sure an outsider can’t hack into the system, disarm it, and rob the place or worse. Also, a phone could get lost or stolen more easily than a laptop.

safehoMe

270 PART TWO MODELING

13.2.1 User Interface Design Mobile device users expect that minimal learning time will be required to master a MobileApp. To achieve this, MobileApp designers use consistent icon representations and placement across multiple platforms. In addition, designers must be sensitive to the user’s expectation of privacy with regard to the display of personal information on the screen of the mobile device. Touch and gesture interfaces, along with sophis- ticated voice input and facial recognition, are maturing rapidly [Shu12] and have already become part of the user interface designer’s toolbox.

Legal and ethical pressure to provide for access by all persons suggests that mobile device interfaces need to account for brand differences, cultural differences, differ- ences in computing experience, elderly users, and users with disabilities (e.g., visual, aural, mobility). The effects of poor usability may mean that users cannot complete their tasks or will not be satisfied with the results. This suggests the importance of user-centered design activities in each of the usability areas (user interface, external accessory interface, and service interface). Accessibility is an important design issue and must be considered when user-centered design is applied.

In trying to meet stakeholder usability expectations, MobileApp developers should attempt to answer these questions to assess the out-of-the-box readiness of the device:

∙ Is the user interface consistent across applications? ∙ Is the device interoperable with different network services? ∙ Is the device acceptable in terms of stakeholder values9 in the target market area?

Eisenstein [Eis01] claims that the use of abstract, platform-neutral models to describe a user interface greatly facilitates the development of consistent, usable multiplatform user interfaces for mobile devices. Three models in particular are useful. A platform model describes the constraints imposed by each platform to be supported. A presen- tation model describes the appearance of the user interface. The task model is a structured representation of the tasks a user needs to perform to meet her task goals. In the best case, model-based design (Chapter 9) involves the creation of databases that contain the

9 Brand, ethical preferences, moral preferences, cognitive beliefs.

Doug: Very true.

Marketing: But we still need the same level of security . . . just also be sure to stop an out sider from getting in with a stolen phone.

Ed: That’s easier said than done and . . .

Facilitator (interrupting): Let’s not worry about those details yet.

(Doug, serving as the recorder for the meeting, makes an appropriate note.)

Facilitator: As a starting point, can we identify which elements of WebApp security function are needed in the MobileApp and which will need to be newly created? Then we can de cide how many mobile platforms we can sup port and when we can move forward on this project.

(The group spends the next 20 minutes refining and expanding the details of the home security function.)

CHAPTER 13 DESIGN FOR MOBILITY 271

models and has tool support for generating user interfaces for multiple devices auto- matically. Utilizing model-based design techniques can also help designers recognize and accommodate the unique contexts and context changes that are present in mobile computing. Without an abstract description of a user interface, the development of mobile user interfaces can be error prone and time consuming.

13.2.2 Lessons Learned de Sá and Carriço [Des08] contend that there are important differences between develop- ing conventional software and developing mobile applications. Software engineers cannot continue to use the same conventional techniques they have used and expect them to be successful. They suggest three approaches for the design of mobile applications:

Usage Scenarios. Described in Chapter 12, usage scenarios must consider context variables (location, user, and device) and transitions between contextual scenarios (e.g., user moves from bedroom to kitchen or switches from stylus to a finger). de Sá and Carriço have identified a set of scenario-variable types that should be considered in developing the user scenarios—locations and settings, movement and posture, devices and usages, workloads and distractions, user preferences.

Mobile User Interface Design Considerations Design choices affect performance and

should be examined early in the user interface de sign process. Ivo Weevers [Wee11] posted several mobile user–interface design practices that have proven to be helpful when designing mobile applications:

∙ Define user interface brand signatures. Differentiate the app from its competitors. Make the core signature elements of the brand the most responsive, because users will use them over and over.

∙ Focus the portfolio of products. Target the platforms that are most important to the success of the app and the company. Not all platforms have the same number of users.

∙ Identify the core user stories. Make use of techniques that require stakeholders to prioritize their needs as a way to reduce a lengthy list of requirements and to consider the constrained resources available on mobile devices.

∙ Optimize user interface flows and elements. Users do not like to wait. Identify potential bottlenecks in user work flow and make sure the user is given an indication of progress when delays occur. Make sure that the time to display screen elements is justified in terms of user benefits.

∙ Define scaling rules. Determine the options that will be used when information to be displayed is too large to fit on the screen. Man aging functionality, aesthetics, usability, and performance is a continual balancing act.

∙ User performance dashboard. The dashboard is used to communicate the product’s current state of completion (e.g., number of use stories implemented), its performance relative to its targets, and perhaps comparisons to its competitors.

∙ Champion-dedicated user interface engineer- ing skills. It is important to understand that the implementation of layout, graphics, and anima tion has performance implications. Techniques to interleave rendering of display items and program execution can be helpful.

info

272 PART TWO MODELING

Ethnographic Observation.10 This is a widely used method for gathering informa- tion about representative users of a software product as it is being designed. It is often difficult to observe users as they change contexts, because the observer must follow users for long periods of time, something that could raise privacy concerns.11 A com- plicating factor is that users seem to complete tasks differently in private settings than in social settings. The same users may need to be observed performing tasks in mul- tiple contexts while monitoring transitions, as well as recording user reactions to the changes.

Low-Fidelity Paper Prototypes (e.g., cards or Post-it notes). This is a cost-effective usability assessment approach in user interface design that can be used before any programming takes place. It is important for these prototypes to be similar in size and weight and for their use to be allowed in a variety of contexts. It is also important that the sketches or text displays be true to size and for the final product to be of high quality. Placement and size of user interface widgets (e.g., buttons or scrollbars) must be designed so that they will not disappear when users extend their screens by zooming. The interaction type (e.g., stylus, joy stick, touch screen) needs to be emu- lated in the low-fidelity prototype (e.g., colored pen or push pin) to check placement and ease of use. Later prototypes may then be created to run on the targeted mobile devices once the layout and placement issues have been resolved.

MobileApp Design Mistakes Joh Koester [Koe12] posts several examples of mobile design practices

that should be avoided: ∙ Kitchen sink. Avoid adding too many features

to the app and too many widgets on the screen. Simple is understandable. Simple is marketable.

∙ Inconsistency. To avoid this, set standards for page navigation, menu use, buttons, tabs, and other userinterface elements. Stick to a uniform look and feel.

∙ Overdesigning. Be ruthless when designing apps. Remove unnecessary elements and wasteful graphics. Do not be tempted to add elements just because you think you should.

∙ Lack of speed. Users do not care about device constraints—they want to view things quickly. Preload what you can. Eliminate what is not needed.

∙ Verbiage. Unnecessarily long, wordy menus and screen displays are indications of a mobile product that has not been tested with users and developers who have not spent enough time understanding the user’s task.

∙ Nonstandard interaction. One reason for targeting a platform is to take advantage of the user’s experience with the way things are done on that platform. Where standards exist use them. This needs to be balanced with the need to have an application appear and be have the same way on multiple devices when possible.

∙ Help-and-FAQ-itis. Adding online help is not the way to repair a poorly designed user inter face. Make sure you have tested your app with your targeted users and repaired the identified defects.

info

10 Ethnographic observation is a means determining the nature of user tasks by watching users in their work environment.

11 Asking users to fill out anonymous questionnaires may have to suffice when direct observa- tion is not possible.

CHAPTER 13 DESIGN FOR MOBILITY 273

13.3 Mo b i L e arc h i t e c t u r e s

Services computing12 and cloud computing13 enable the rapid development of large- scale distributed applications based on innovative architectural designs [Yau11]. These two computing paradigms have made it easier and more economical to create applica- tions on many different mobile devices (e.g., laptop computers, smartphones, and tablets). These two paradigms allow resource outsourcing and transfer of information technology management to service providers while at the same time mitigating the impact of resource limitations on some mobile devices. A service-oriented architecture provides the architectural style (e.g., REST),14 standard protocols (e.g., XML15 and SOAP16), and interfaces (e.g., WSDL)17 needed for mobile development. Cloud com- puting enables convenient, on-demand network access to a shared pool of configurable computing resources (servers, storage, applications, and services).

Service computing allows mobile developers to avoid the need to integrate service source code into the client running on a mobile device. Instead, the service runs out of the provider’s server and is loosely coupled with the applications that make use of it through messaging protocols. A service typically provides an application program- ming interface (API) to allow it to be treated like an abstract black box.

Cloud computing lets the client (either a user or program) request computing capa- bilities as needed, across network boundaries anywhere or any time. The cloud archi- tecture has three layers, each of which can be called as a service (Figure 13.1). The software as service layer consists of software components and applications hosted by third-party service providers. The platform as service layer provides a collaborative development platform to assist with design, implementation, and testing by geograph- ically distributed team members. Infrastructure as a service provides virtual comput- ing resources (storage, processing power, network connectivity) on the cloud.

Mobile devices can access cloud services from any location at any time. The risks of identity theft and service hijacking require providers of mobile services and cloud comput- ing to employ rigorous security engineering techniques (Chapter 18) to protect their users.

Taivalsaari [Tai12] points out that making use of cloud storage can allow any mobile device or software features to be updated easily on millions of devices world- wide. In fact, it is possible to virtualize the entire mobile user experience so that all applications are downloaded from the cloud.

12 Services computing focuses on architectural design and enables application development through service discovery and composition.

13 Cloud computing focuses on the effective delivery of services to users through flexible and scalable resource virtualization and loading balancing.

14 Representation State Transfer describes a networked Web architectural style where the resource representation (e.g., a Web page) places the client in a new state. The client changes or transfers state with each resource representation.

15 Extensible Markup Language (XML) is designed to store and transport data, while HTML is designed to display data.

16 Simple Object Access Protocol is a specification for exchanging structured information in the implementation of Web services in computer networks.

17 Web Services Description Language is an XML-based language for describing Web services and how to access them.

274 PART TWO MODELING

13.4 co n t e x t-awa r e ap p s

Context allows the creation of new applications based on the location of the mobile device and the functionality to be delivered by the device. Context can also help tailor personal computer applications for mobile devices (e.g., downloading patient information to a device carried by a home health care worker as he arrives at the patient’s house).

Using highly adaptive, contextual interfaces is a good way to deal with device limitations (e.g., screen size and memory). To facilitate the development of context- aware user interaction requires the support of corresponding software architectures.

In an early discussion of context-aware applications, Rodden [Rod98] points out that mobile computing merges the real and virtual world by providing functionality that allows a device to be aware of its location, time, and other objects in its sur- roundings. The device could be in a fixed location like an alarm sensor, embedded in an autonomous device, or be carried around by a human. Because the device can be designed to be used by individuals, groups, or the public, it must detect the presence and identity of the user, as well as the attributes of the context that are relevant or permitted for that user (even if the user is another device).

To achieve context awareness, mobile systems must produce reliable information in the presence of uncertain and rapidly changing data from a variety of heterogeneous sources. Extracting relevant context information by combing data from several sensors proves challenging because of problems with noise, miscalibration, wear and tear, and weather. Event-based communication is preferable to the management of continuous streams of high-abstraction-level data in context-aware applications [Kor03].

Figure 13.1 Cloud computing layers

More Control

Less Control

SaaSSoftware as a Service End Users

PaaSPlatform as a Service Application Developers

IaaSInfrastructure as a Service Network Architects

CHAPTER 13 DESIGN FOR MOBILITY 275

In ubiquitous computing environments, multiple users work with a wide range of different devices. The configuration of the devices should be flexible enough to change frequently because of the demands of mobile work practices. It is important for the software infrastructure to support different styles of interaction (e.g., gestures, voice, and pen) and store them in abstractions that can be shared easily.

There are times when one user may desire to work with more than one device simultaneously on the same product (e.g., use a touch-screen device to edit a docu- ment image and a personal keyboard to edit document text). It is challenging to integrate mobile devices that are not always connected to the network and have a variety of device constraints [Tan01]. Networked, multiplayer games have had to deal with these problems by storing the game state on each device and sharing change information among other game players’ devices in real time.

13.5 we b De s i g n py r a M i D

What is design in the context of Web engineering? This simple question is more dif- ficult to answer than one might believe. Pressman and Lowe [Pre08] discuss this when they write:

The creation of an effective design will typically require a diverse set of skills. Some- times, for small projects, a single developer may need to be multi-skilled. For larger projects, it may be advisable and/or feasible to draw on the expertise of specialists: Web engineers, graphic designers, content developers, programmers, database specialists, information architects, network engineers, security experts, and testers. Drawing on these diverse skills allows the creation of a model that can be assessed for quality and improved before content and code are generated, tests are conducted, and end-users become involved in large numbers. If analysis is where WebApp quality is established, then design is where the quality is truly embedded.

The appropriate mix of design skills will vary depending upon the nature of the WebApp. Figure 13.2 depicts a design pyramid for WebApps. Each level of the pyramid represents a design action that is described in the sections that follow.

13.5.1 WebApp Interface Design When a user interacts with a computer-based system, a set of fundamental principles and overriding design guidelines apply. These have been discussed in Chapter 12.18 Although WebApps present a few special user interface design challenges, the basic principles and guidelines are applicable.

One of the challenges of interface design for WebApps is the indeterminate nature of the user’s entry point. That is, the user may enter the WebApp at a “home” location (e.g., the home page) or may be linked into some lower level of the WebApp archi- tecture. In some cases, the WebApp can be designed in a way that reroutes the user to a home location, but if this is undesirable, the WebApp design must provide inter- face navigation features that accompany all content objects and are available regardless of how the user enters the system.

18 Section 12.1 is dedicated to the user interface design portion of user experience design. If you have not already done so, read it at this time.

276 PART TWO MODELING

The objectives of a WebApp interface are to: (1) establish a consistent window into the content and functionality provided by the interface, (2) guide the user through a series of interactions with the WebApp, and (3) organize the navigation options and content available to the user. To achieve a consistent interface, you should first use visual design (Section 12.1) to establish a coherent “look.” This encompasses many characteristics but must emphasize the layout and form of navigation mechanisms. To guide user interaction, you may draw on an appropriate metaphor19 that enables the user to gain an intuitive understanding of the interface. To implement navigation options, you can select navigation menus positioned consistently on Web pages, graphic icons represented in a manner that enable a user to recognize that the icon is a navigation element, and/or graphic images that provide a link to a content object or WebApp functionality. It is important to note that one or more of these navigation mechanisms should be provided at every level of the content hierarchy.

Every Web page has a limited amount of “real estate” that can be used to support nonfunctional aesthetics, navigation features, informational content, and user-directed functionality. The development of this real estate is planned during aesthetic design.

technology

user Figure 13.2

A design pyramid for WebApps

19 In this context, a metaphor is a representation (drawn from the user’s real-world experience) that can be modeled within the context of the interface. A simple example might be a slider switch that is used to control the auditory volume of an .mp4 file.

CHAPTER 13 DESIGN FOR MOBILITY 277

13.5.2 Aesthetic Design Aesthetic design, also called visual design or graphic design, is an artistic endeavor that complements the technical aspects of WebApp design. We discussed visual design in Section 12.1.4. Page layout is one aspect of aesthetic design that can affect the usefulness (and usability) of a WebApp.

There are no absolute rules when a Web page layout is designed. However, a number of general layout guidelines are worth considering:

Don’t be afraid of open space. It is inadvisable to pack every square inch of a Web page with information. The resulting clutter makes it difficult for the user to identify needed information or features and create visual chaos that is not pleasing to the eye. Emphasize content. After all, that’s the reason the user is there. Nielsen [Nie00] suggests that the typical Web page user should be 80 percent content with the remaining real estate dedicated to navigation and other features. Organize layout elements from top left to bottom right. The vast major- ity of users will scan a Web page in much the same way as they scan the page of a book—top left to bottom right.20 If layout elements have specific priorities, high-priority elements should be placed in the upper-left portion of the page real estate. Group navigation, content, and function geographically within the page. Humans look for patterns in virtually all things. If there are no discernible patterns within a Web page, user frustration is likely to increase (owing to unnecessary searching for needed information). Don’t extend your real estate with the scrolling bar. Although scrolling is often necessary, most studies indicate that users would prefer not to scroll. It is often better to reduce page content or to present necessary content on multiple pages. Consider resolution and browser window size when designing layout. Rather than defining fixed sizes within a layout, the design should specify all layout items as a percentage of available space [Nie00]. With the growing use of mobile devices with different screen sizes, this concept becomes increas- ingly important.

13.5.3 Content Design We introduced content design in Section 12.1.1. In WebApp design, a content object is more closely aligned with a data object for traditional software. A content object has attributes that include content-specific information (normally defined during WebApp requirements modeling) and implementation-specific attributes that are spec- ified as part of design.

As an example, consider an analysis class, ProductComponent, developed for the SafeHome e-commerce system. The analysis class attribute, description, is represented

20 There are exceptions that are cultural and language based, but this rule holds for most users.

278 PART TWO MODELING

as a design class named CompDescription composed of five content objects: MarketingDescription, Photograph, TechDescription, Schematic, and Videos shown as the bottom row of shaded objects noted in Figure 13.3. Information contained within the content object is noted as attributes. For example, Photograph (a jpg image) has the attributes horizontal dimension, vertical dimension, and border style.

UML association and an aggregation21 may be used to represent relationships between content objects. For example, the UML association shown in Figure 13.3 indicates that one CompDescription is used for each instance of the ProductCom- ponent class. CompDescription is composed on the five content objects shown. How- ever, the multiplicity notation shown indicates that Schematic and Videos are optional (zero occurrences are possible), one MarketingDescription and one TechDescription are required, and one or more instances of Photograph are used.

13.5.4 Architecture Design Architecture design is tied to the goals established for a WebApp, the content to be presented, the users who will visit, and the navigation philosophy that has been estab- lished. As an architectural designer, you must identify content architecture and

text color font style font size line spacing text usage size background color

MarketingDescription

text color font style font size line spacing text usage size background color

TechDescription

horizontal dimension vertical dimension border style audio volume

Videos

horizontal dimension vertical dimension border style

Schematic

horizontal dimension vertical dimension border style

Photograph

partNumber partName partType description price

createNewItem() displayDescription() displayTechSpec

ProductComponent CompDescription

Sensor Camera

1 Is part of

1 1..* 0..1

0..1

0..1 1

Control Panel SoftFeature

Figure 13.3 Design representation of content objects

21 Both of these representations are discussed in Appendix 1.

CHAPTER 13 DESIGN FOR MOBILITY 279

WebApp architecture. Content architecture22 focuses on the manner in which content objects (or composite objects such as Web pages) are structured for presentation and navigation. WebApp architecture addresses the manner in which the application is structured to manage user interaction, handle internal processing tasks, effect naviga- tion, and present content.

In most cases, architecture design is conducted in parallel with interface design, aesthetic design, and content design. Because the WebApp architecture may have a strong influence on navigation, the decisions made during this design action will influence work conducted during navigation design.

WebApp architecture describes an infrastructure that enables a Web-based system or application to achieve its business objectives. Jacyntho and his colleagues [Jac02b] describe the basic characteristics of this infrastructure in the following manner:

Applications should be built using layers in which different concerns are taken into account; in particular, application data should be separated from the page’s contents (navigation nodes) and these contents, in turn, should be clearly separated from the interface look-and-feel (pages).

The authors suggest a three-layer design architecture that decouples the interface from navigation and from application behavior. They argue that keeping the interface, application, and navigation separate simplifies implementation and enhances reuse.

The Model-View-Controller (MVC) architecture [Kra88]23 is a popular WebApp architectural model that decouples the user interface from the WebApp functionality and information content. The model (sometimes referred to as the “model object”) contains all application-specific content and processing logic, including all content objects, access to external data/information sources, and all processing functionality that is application specific. The view contains all interface-specific functions and enables the presentation of content and processing logic, including all content objects, access to external data and information sources, and all processing functionality required by the end user. The controller manages access to the model and the view and coordinates the flow of data between them. In a WebApp, “the view is updated by the controller with data from the model based on user input” [WMT02]. A sche- matic representation of the MVC architecture is shown in Figure 13.4.

Referring to the figure, user requests or data are handled by the controller. The controller also selects the view object that is applicable based on the user request. Once the type of request is determined, a behavior request is transmitted to the model, which implements the functionality or retrieves the content required to accommodate the request. The model object can access data stored in a corporate database, as part of a local data store, or as a collection of independent files. The data developed by the model must be formatted and organized by the appropriate view object and then transmitted from the application server back to the client-based browser for display on the customer’s machine.

22 The term information architecture is also used to connote structures that lead to better organization, labeling, navigation, and searching of content objects.

23 It should be noted that MVC is actually an architectural design pattern developed for the Smalltalk environment (see www.smalltalk.org) and can be used for any interactive application.

280 PART TWO MODELING

In many cases, WebApp architecture is defined within the context of the develop- ment environment in which the application is to be implemented. If you have further interest, see [Fow03] for a discussion of development environments and their role in the design of Web application architectures.

13.5.5 Navigation Design Once the WebApp architecture has been established and the components (pages, scripts, applets, and other processing functions) of the architecture have been iden- tified, you must define navigation pathways that enable users to access WebApp content and functions. To accomplish this, identify the semantics of navigation for different users of the site, and define the mechanics (syntax) of achieving the navigation.

Like many WebApp design actions, navigation design begins with a consideration of the user hierarchy and related use cases (Chapter 8) developed for each category of user (actor). Each actor may use the WebApp somewhat differently and therefore have different navigation requirements. In addition, the use cases developed for each actor will define a set of classes that encompass one or more content objects or WebApp functions. As each user interacts with the WebApp, she encounters a series of navigation semantic units (NSUs)—“a set of information and related navigation structures that collaborate in the fulfillment of a subset of related user requirements” [Cac02]. An NSU describes the navigation requirements for each use case. In essence, the NSU shows how an actor moves between content objects or WebApp functions.

An NSU is composed of a set of navigation elements called ways of navigating (WoN) [Gna99]. A WoN represents the best navigation pathway to achieve a naviga- tional goal for a specific type of user. Each WoN is organized as a set of navigational nodes (NN) that are connected by navigational links. In some cases, a navigational link may be another NSU. Therefore, the overall navigation structure for a WebApp may be organized as a hierarchy of NSUs.

View

Model Controller

NotifiesWrites

Updates

Fills

Figure 13.4 The MVC architecture

CHAPTER 13 DESIGN FOR MOBILITY 281

To illustrate the development of an NSU, consider the use case Select SafeHome Components:

Use Case: Select SafeHome Components

The WebApp will recommend product components (e.g., control panels, sensors, cameras) and other features (e.g., PC-based functionality implemented in software) for each room and exterior entrance. If I request alternatives, the WebApp will pro- vide them, if they exist. I will be able to get descriptive and pricing information for each product component. The WebApp will create and display a bill-of-materials as I select various components. I’ll be able to give the bill-of-materials a name and save it for future reference (see use case Save Configuration).

The underlined items in the use case description represent classes and content objects that will be incorporated into one or more NSUs that will enable a new customer to perform the scenario described in the Select SafeHome Components use case.

Figure 13.5 depicts a partial semantic analysis of the navigation implied by the Select SafeHome Components use case. Using the terminology introduced earlier, the figure also represents a way of navigating (WoN) for the SafeHomeAssured.com WebApp. Important problem domain classes are shown, along with selected content objects (in this case the package of content objects named CompDescription, an attribute of the ProductComponent class). These items are navigation nodes. Each of the arrows represents a navigation link24 and is labeled with the user-initiated action that causes the link to occur.

24 These are sometimes referred to as navigation semantic links (NSLs) [Cac02].

CompDescription MarketingDescription

techDescription

Schematic Photograph

Video

ProductComponent

BillOfMaterials

Room

select Room

<<navigation link>> view BillOfMaterials

<<navigation link>> recommend component(s)

<<navigation link>> return to Room

<<navigation link>> purchase ProductComponent

<<navigation link>> request alternative

<<navigation link>> purchase ProductComponent

<<navigation link>> show description

Figure 13.5 Creating an NSU

282 PART TWO MODELING

You can create an NSU for each use case associated with each user role. For example, a new customer for SafeHomeAssured.com may have three different use cases, all resulting in access to different information and WebApp functions. An NSU is created for each goal.

During the initial stages of navigation design, the WebApp content architecture is assessed to determine one or more WoN for each use case. As noted earlier, a WoN identifies navigation nodes (e.g., content) and then links that enable navigation between them. The WoN are then organized into NSUs.

As design proceeds, your next task is to define the mechanics of navigation. Most websites make use of one or more of the following navigation options for implement- ing each NSU: individual navigation links, horizontal or vertical navigation bars (lists), tabs, or access to a complete site map. If a site map is defined, it should be accessible from every page. The map itself should be organized so that the structure of WebApp information is readily apparent.

In addition to choosing the mechanics of navigation, you should also establish appropriate navigation conventions and aids. For example, icons and graphical links should look “clickable” by beveling the edges to give the image a three-dimensional look. Audio or visual feedback should be designed to provide the user with an indica- tion that a navigation option has been chosen. For text-based navigation, color should be used to indicate navigation links and to provide an indication of links already traveled. These are but a few of dozens of design conventions that make navigation user-friendly.

13.6 co M p o n e n t-Le v e L De s i g n

Mobile apps deliver increasingly sophisticated processing functions that (1) perform localized processing to generate content and navigation capability in a dynamic fash- ion, (2) provide computation or data processing capability that are appropriate for the app’s business domain, (3) provide sophisticated database query and access, and (4) establish data interfaces with external corporate systems. To achieve these (and many other) capabilities, you must design and construct program components that are identical in form to software components for traditional software.

The design methods discussed in Chapters 11 and 12 apply to mobile components with little, if any, modification. The implementation environment, programming lan- guages, and design patterns, frameworks, and software may vary somewhat, but the overall design approach remains the same. To be cost conscious, you can design mobile components in such a way that they can be used without modification on several different mobile platforms.

13.7 Mo b i L i t y a n D De s i g n Qua L i t y

Every person has an opinion about what makes a “good” mobile app. Individual viewpoints vary widely. Some users enjoy flashy graphics; others want simple text. Some demand copious information; others desire an abbreviated presentation. Some like sophisticated analytical tools or database access; others like to keep it simple.

CHAPTER 13 DESIGN FOR MOBILITY 283

In fact, the user’s perception of “goodness” (and the resultant acceptance or rejection of a mobile app as a consequence) might be more important than any technical dis- cussion of mobile app quality. Mobile design quality attributes are virtually the same as WebApp quality characteristics.

But how is mobile quality perceived? What attributes must be exhibited to achieve goodness in the eyes of end users and at the same time exhibit the technical charac- teristics of quality that will enable you to correct, adapt, enhance, and support the mobile product over the long term?

In reality, all the technical characteristics of design quality discussed in Chapter 12 and the generic quality attributes presented in Chapter 19 apply to mobile apps. How- ever, the most relevant of these generic attributes—usability, functionality, reliability, efficiency, and maintainability—provide a useful basis for assessing the quality of mobile systems as well. Andreou [And05] suggests that end-user satisfaction with a mobile app is dictated by the same important quality factors—functionality, reliability, usability, efficiency, and maintainability—but adds portability to the list.

Olsina and his colleagues [Ols99] have prepared a “quality requirement tree” that identifies a set of technical attributes—usability, functionality, reliability, efficiency, and maintainability—that lead to high-quality mobile products.25 Figure 13.6 sum- marizes their work. The criteria noted in the figure are of particular interest if you design, build, and maintain mobile products over the long term.

Web application

quality

Usability

Functionality

Reliability

Maintainability

Efficiency

Online feedback and help features Interface and aesthetic features

Global site understandability

Special features

Searching and retrieving capability Navigation and browsing features Application domain-related features

Correct link processing Error recovery User input validation and recovery

Response time performance Page generation speed Graphics generation speed

Figure 13.6 Quality requirements tree Source: Olsina, Luis, Lafuente, Guillermo and Rossi, Gustavo, “Specifying Qual- ity Characteristics and Attributes for Web Sites,” Proceedings of the 1st Interna- tional Conference on Software Engi- neering Workshop on Web Engineer- ing, ACM, Los Angeles, May 1999.

25 These quality attributes are quite similar to those presented in Chapters 9 and 15. The implication is that quality characteristics are universal for all software.

284 PART TWO MODELING

Offutt [Off02] extends the five major quality attributes noted in Figure 13.6 by adding the following attributes:

Security. Mobile products have become heavily integrated with critical cor- porate and government databases. E-commerce applications extract and then store sensitive customer information. For these and many other reasons, mobile security is paramount in many situations. The key measure of security is the ability of the mobile app and its server environment to rebuff unauthor- ized access and/or thwart an outright malevolent attack. Security engineering is discussed in Chapter 18. For additional information on WebApp and mobile app security, see [Web13], [Pri10], [Vac06], and [Kiz05]. Availability. Even the best mobile product will not meet users’ needs if it is unavailable. In a technical sense, availability is the measure of the per- centage of time that a Web-based mobile resource is available for use. But Offutt [Off02] suggests that “using features available on only one browser or one platform” makes the mobile product unavailable to those with a different browser or platform configuration. The user will invariably go elsewhere. Scalability. Can the mobile product and its server environment be scaled to handle 100, 1,000, 10,000, or 100,000 users? Will the app and the systems with which it is interfaced handle significant variation in volume, or will responsiveness drop dramatically (or cease altogether)? It is important to design a mobile environment that can accommodate the burden of success (i.e., significantly more end users) and become even more successful. Time to Market. Although time to market is not a true quality attribute in the technical sense, it is a measure of quality from a business point of view. The first mobile product to address a specific market segment often captures a disproportionate number of end users. Content Quality. Billions of Web pages are available for those in search of information. Even well-targeted Web searches result in an avalanche of con- tent. With so many sources of information to choose from, how does the user assess the quality (e.g., veracity, accuracy, completeness, timeliness) of the content that is presented within a mobile product? This is part of what data science tries to address. The basics of data science are introduced in Appendix 2 of this book.

Tillman [Til00] suggests a useful set of criteria for assessing the quality of content: Can the scope and depth of content be easily determined to ensure that it meets the user’s needs? Can the background and authority of the content’s authors be easily identified? Is it possible to determine the currency of the content, the last update, and what was updated? Are the content and its location stable (i.e., will they remain at the referenced URL)? Is content credible? Is content unique? That is, does the mobile product provide some unique benefit to those who use it? Is content valuable to the targeted user community? Is content well organized? Indexed? Easily accessible? These questions represent only a small sampling of the issues that should be addressed as the design of a mobile product evolves.

CHAPTER 13 DESIGN FOR MOBILITY 285

13.8 Mo b i L i t y De s i g n be st pr ac t i c e s

There are several guidelines for developing mobile products26 and for developing apps for specific platforms like Apple’s iOS27 or Google’s Android.28 Schumacher [Sch09] has collected many best practice ideas and has posted several specially adapted to the design of mobile applications and Web pages. Some important considerations when designing mobile touch-screen applications listed by Schumacher include:

∙ Identify your audience. The application must be written with the expecta- tions and backgrounds of its users in mind. Experienced users want to do things quickly. Less experienced users will appreciate a handholding approach when they are first using the app.

∙ Design for context of use. It is important to consider how the user will inter- act with the real world while using the mobile product. Watching a movie on an airplane calls for a different user interface than checking the weather before you leave the office.

∙ There is a fine line between simplicity and laziness. Creating an intuitive user interface on a mobile device is much harder than simply removing features found in the user interface for the application running on a larger device. The user interface should provide all the information that enables a user to make her next decision.

Mobile Product—Quality Checklist The following checklist provides a set of

questions that will help both software engineers and end users assess overall mobile product quality:

∙ Can content, function, and/or navigation op tions be tailored to the user’s preferences?

∙ Can content and/or functionality be customized to the bandwidth at which the user communi cates? Does the app account for weak or lost signals in an acceptable manner?

∙ Can content, function, and/or navigation options be made context aware according to the user’s preferences?

∙ Has adequate consideration been given to the power availability on the target device(s)?

∙ Have graphics, media (audio, video), and other Web or cloud services been used appropriately?

∙ Is the overall page design easy to read and navigate? Does the app take screensize differences into account?

∙ Does the user interface conform to the display and interaction standards adopted for the targeted mobile device(s)?

∙ Does the app conform to the reliability, security, and privacy expectations of its users?

∙ What provisions have been made to ensure an app remains current?

∙ Has the mobile product been tested in all targeted user environments and for all targeted devices?

info

26 See http://www.w3.org/TR/mwabp/. 27 See https://developer.apple.com/design/human-interface-guidelines/. 28 See http://developer.android.com/guide/components/index.html.

286 PART TWO MODELING

∙ Use the platform as an advantage. Touch-screen navigation is not intuitive and must be learned by all new users. This learning task will be easier if the user interface designers adhere to standards that have been set for the platform.

∙ Make scrollbars and selection highlighting more salient. Scrollbars are often hard to locate on touch devices because they are too small. Make sure that menu or icon borders are wide enough for color changes to catch the users’ attention. When color coding is used, make sure there is sufficient contrast between foreground and background colors to allow them to be distinguishable by any color-blind users.

∙ Increase discoverability of advanced functionality. Hot keys and other shortcuts are sometimes included in mobile products to allow experienced users to complete their tasks more quickly. You can increase the discoverabil- ity of features like these by including visual design clues in the user interface.

∙ Use clear and consistent labels. Widget labels should be recognized by all app users, regardless of standards used by specific platforms. Use abbrevia- tions cautiously and avoid them if possible.

∙ Clever icons should never be developed at the expense of user under- standing. Icons often only make sense to their designers. Users must be able to learn their meaning quickly. It is hard to guarantee that icons are meaning- ful across all languages and user groups. A good strategy to enhance recogni- tion is to add a text label beneath a novel icon.

∙ Support user expectations for personalization. Mobile device users expect to be able to personalize everything. At the very least, developers should try to allow users to set their location (or detect it automatically) and select content options that may be available at that location. It is important to indicate to users what features can be personalized and how users can personalize them.

∙ Long scrolling forms trump multiple screens on mobile devices. Experi- enced mobile device users want all information on a single input screen even if this requires scrolling. Novice users often become experienced quickly and will grow tired of multiple input screens.

Developing native applications for multiple device platforms can be costly and time consuming. Development costs can be reduced by using technologies familiar to Web developers (e.g., JavaScript, CSS, and HTML) to create mobile products that will be accessed using a Web browser on a mobile device.

There are no guarantees that a desktop program or a WebApp can be easily adapted for implementation as a mobile product. However, many of the agile software engineer- ing practices (Chapter 3) used to create desktop computer applications can be used to create stand-alone apps or mobile client software, and many of the practices used to create quality WebApps apply to the creation of Web services used by mobile products.

The most important architectural design decision is often whether to build a thin or fat client. The model-view-controller (MVC) architecture (Section 13.3) is com- monly used in mobile products. Because the mobile architecture has a strong influence on navigation, the decisions made during this design action will influence work con- ducted during navigation design. The architectural design must take device resources

CHAPTER 13 DESIGN FOR MOBILITY 287

into account (storage, processor speed, and network connectivity). The design should include provisions for discoverable services and movable devices.

Usability testing and deployment testing take place during each prototype develop- ment cycle. Code reviews that focus on security issues should be included as part of the implementation activities. These code reviews should be based on the appropriate security objectives and threats identified in the system design activities. Security test- ing is a routine part of system testing (Chapter 21).

13.9 su M M a ry

The quality of a mobile product—defined in terms of functionality, reliability, usabil- ity, efficiency, security, maintainability, scalability, and portability—is introduced dur- ing design. A good mobile product should be based on the following design goals: simplicity, ubiquity, personalization, flexibility, and localization.

Interface design describes the structure and organization of the user interface and includes a representation of screen layout, a definition of the modes of interaction, and a description of navigation mechanisms. In addition, the interface for a good mobile product will promote the brand signature and focus on its targeted device platform(s). A set of core user stories is used to trim unnecessary features from the app to manage its resource requirements. Context-aware devices make use of discov- erable services to help personalize the user experience.

Content design is critically important and takes the screen and other limitations of mobile devices into account. Aesthetic design, also called graphic design, describes the “look and feel” of the mobile product and includes color schemes, graphic layout, the use of graphics, and related aesthetic decisions. Aesthetic design must also take device limitations into account.

Architecture design identifies the overall hypermedia structure for the mobile prod- uct and encompasses both content architecture and mobile architecture. It is critical to determine how much of the mobile functionality will reside on the mobile device and how much will be provided by Web or cloud services.

Navigation design represents the navigational flow between content objects and for all mobile functions. Navigation syntax is defined by the widgets available on the targeted mobile device(s), and the semantics are often determined by the mobile plat- form. Content chunking must take intermittent service interruptions and user demands for fast performance into account.

Component design develops the detailed processing logic required to implement the components that are used to build a complete MobileApp function. The design techniques described in Chapter 12 may be applicable for the engineering of mobile components.

pro b L e M s a n D po i n t s to po n D e r

13.1. Explain why deciding to develop a MobileApp for several devices can be a costly design decision. Is there a way to mitigate the risks of supporting the wrong platform?

13.2. In this chapter we listed many quality attributes for mobile products. Select the three that you believe are most important, and make an argument that explains why each should be emphasized in mobile design work.

288 PART TWO MODELING

13.3. You are a MobileApp designer for Project Planning Corporation, a company that builds productivity software. You want to implement the equivalent of a digital three-ring binder that allows tablet users to organize and categorize electronic documents of several types under user- defined tabs. For example, a kitchen remodeling project might require a pdf catalog, a jpg or layout drawing, an MS Word proposal, and an Excel spreadsheet stored under a Cabinetry tab. Once defined, the binder and its tab content can be stored either on the tablet or on some cloud storage. The application needs to provide five key functions: binder and tab definition, digital document acquisition from a Web location or the device, binder management functions, page display functions, and a notes function to allow a Post-it note to be added to any page. Develop an interface design for the three-ring application, and implement it as a paper prototype.

13.4. What is the most aesthetically pleasing MobileApp you have ever used and why?

13.5. Create user stories for the three-ring application described in Problem 13.3.

13.6. What might be considered to make the three-ring application a context-aware MobileApp?

13.7. Reconsidering the ProjectPlanning three-ring application described in Problem 13.3, select a development platform for the first working prototype. Discuss why you made the choice.

13.8. Do a bit of additional research on the MVC architecture and decide whether it would be an appropriate MobileApp architecture for the three-ring discussed in Problem 13.3.

13.9. Describe three context-aware features that would be desirable to add to a SafeHome MobileApp.

13.10. You are a WebApp designer for FutureLearning Corporation, a distance learning com- pany. You intend to implement an Internet-based “learning engine” that will enable you to deliver course content to a student. The learning engine provides the basic infrastructure for delivering learning content on any subject (content designers will prepare appropriate content). Develop a prototype interface design for the learning engine.