Designing a mobile app

1. Designing a mobile app Chris Greenhalgh G54UBI / 2011-03-02 Chris Greenhalgh (cmg@cs.nott.ac.uk)

2. First… • Work out what the application is meant to do, e.g. • Identify possible users and situations of use • Identify use cases, i.e. main activities • Write one or more user stories Chris Greenhalgh (cmg@cs.nott.ac.uk)

3. Example: tree walk • Existing paper walking guide to trees and gardens on the University Park campus • (as used for GLF) Chris Greenhalgh (cmg@cs.nott.ac.uk)

4. Example: user story • Ali is visiting University Park and installs the tree walk app on her Android phone • She starts the app and the main view shows the walking map • As she explores the area the app chimes and pops up more detail of nearby points of interest • She reads these with interest before continuing her walk Chris Greenhalgh (cmg@cs.nott.ac.uk)

5. D1. Identify application “screens” • Work out how the application will be divided into screens, e.g. • Splash screen • Map overview • Location detail view • Help • … Chris Greenhalgh (cmg@cs.nott.ac.uk)

6. D1: Example • Welcome screen • Main map screen • Point of interest screens • 4: Acer saccharinum; 5: Ulmus ‘Sapporo Autumn Gold’; 7: Metasequoiaglyptostroboides • Where am I? screen (native app) • Help screen Chris Greenhalgh (cmg@cs.nott.ac.uk)

7. Non-GUI apps • “Screens” are most relevant for GUI-based apps, but still a necessary starting point for other apps, e.g. audio • For non-GUI apps there may be other application “modes” which effectively sub-divide/specialise each screen • E.g. “seeking”, “detail”, … • These should be identified and charted in the same way as screens Chris Greenhalgh (cmg@cs.nott.ac.uk)

8. D2. Define screen “flow” • Work out how the application moves from one screen to another, e.g. • On direct user input (e.g. a button) • On “back” • On timer • On sensor input condition Chris Greenhalgh (cmg@cs.nott.ac.uk)

9. D2: Example Welcome “Start” button GPS trigger Detail (1) Detail (1) Detail (1) Main(map) Back Back Back “Help” button “Where?” button Where? Help Chris Greenhalgh (cmg@cs.nott.ac.uk)

10. D3. “wireframe” each screen • For each screen, work out what GUI elements will make it up and roughly how they will be laid out, e.g. • Images, Text, Buttons, Gauges, … • Specify what each GUI element will do • Highlight any elements that change • These may be domain model objects or properties! (see 6) Chris Greenhalgh (cmg@cs.nott.ac.uk)

11. D3: Example Welcome Main Welcome to the University Parktree walk GPS: Start Help Where am I? Chris Greenhalgh (cmg@cs.nott.ac.uk)

12. D3: Example Help Map (native app) Tree Walk Help Blah blahblahblah Blah blahblahblah Blah blahblahblah Blah blahblahblah Blah blahblahblah Blah blahblahblah OK Chris Greenhalgh (cmg@cs.nott.ac.uk)

13. D3: Example Detail 4 … 4: Silver Maple On the right hand side of the drive is a group of young Acer saccharinum, the Silver maple, introduced from Eastern North America in 1725. It is a fast growing tree. OK Chris Greenhalgh (cmg@cs.nott.ac.uk)

14. D4. Specify sensor input and effects • Identify • Which sensors are monitored • When, e.g. on which screens • How sensor input is processed • E.g. identify region entry • Which screen elements are affected and how • E.g. signal strength, user position • What other actions result • E.g. screen transitions Chris Greenhalgh (cmg@cs.nott.ac.uk)

15. D4: Example • Sensor is GPS • Only required on main screen • Accuracy is shown on main screen GPS gauge • Position is checked against interest regions • Entering interest region switches to detail screen Chris Greenhalgh (cmg@cs.nott.ac.uk)

16. D5. Specify any “invisible” activities • E.g. • Network operations • Audio / sound effects • Background processing Chris Greenhalgh (cmg@cs.nott.ac.uk)

17. D5: Example • Transition to detail view accompanied by “chime” sound-effect Chris Greenhalgh (cmg@cs.nott.ac.uk)

18. Optional: D6. Define/Refine the domain model • Identify the classes of “things” that your application “knows” about, e.g. • Trees, shops, exhibits, places, … • Identify what your application “knows” about each “thing”, i.e. • the properties and relationships that are shown to the user (see 3) • The properties and relationships that are used internally when deciding what to do (see 2, 4, 5) This activity can be done and re-done at any stage through the designand refinement process Chris Greenhalgh (cmg@cs.nott.ac.uk)

19. Why D6? • Aim to separate • Code = behaviour • Screen and element “templates” = appearance • Domain data = data values = specific content • Because • Code is harder to change • Specific content can be represented more concisely as data values • Specific content can be changed more easily • Potentially dynamically, e.g. from a server Chris Greenhalgh (cmg@cs.nott.ac.uk)

20. D6: Example • “Things” are “points of interest” • Or perhaps more specifically “trees” • A point of interest has: • A spatial trigger region • A map key (e.g. “4”) • “Detail” information • A title • Some descriptive text Chris Greenhalgh (cmg@cs.nott.ac.uk)

21. Iterate… • Review and refine taking account of • Walkthroughs • Details emerging from later stages • Other use cases • Paper prototyping • Implementation constraints • User tests Chris Greenhalgh (cmg@cs.nott.ac.uk)

22. Summary • D1. Identify application “screens” • D2. Define screen “flow” • D3. “wireframe” each screen • D4. Specify sensor input and effects • D5. Specify any “invisible” activities • D6. Define/Refine the domain model (optional) Chris Greenhalgh (cmg@cs.nott.ac.uk)