Select a mobile application you are familiar with, and assess it using the architecture considerations (economy, visibility, spacing, symmetry, emergence) fro

264

C H A P T E R

13

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 user­interface 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 Ethnographi

Collepals.com Plagiarism Free Papers

Are you looking for custom essay writing service or even dissertation writing services? Just request for our write my paper service, and we'll match you with the best essay writer in your subject! With an exceptional team of professional academic experts in a wide range of subjects, we can guarantee you an unrivaled quality of custom-written papers.

Get ZERO PLAGIARISM, HUMAN WRITTEN ESSAYS

Why Hire Collepals.com writers to do your paper?

Quality- We are experienced and have access to ample research materials.

We write plagiarism Free Content

Confidential- We never share or sell your personal information to third parties.

Support-Chat with us today! We are always waiting to answer all your questions.