1 / 22

Designing a mobile app

Designing a mobile app. Chris Greenhalgh G54UBI / 2011-03-02. 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. Example: tree walk.

trish
Download Presentation

Designing a mobile app

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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)

More Related