CDI1: Assignment 2

Overall goal: mock up a navigation or guidance system, focusing on at least one non-typical user group.  Evaluate your conceptual project using the Wizard-of-Oz technique.  Depending on how fully describable or demonstrable your idea is, the use of a usability survey is optional. Produce a presentation and report.

This is a teamwork exercise. Groups are listed on the Group Membership page.


The background case study is again SpaceBook.  However, any definition of a navigation or guidance system can be much broader than this.  The exact purpose, domain and nature of the system are entirely up to the group to decide upon.  For example, it could be indoor, outdoor, pedestrian, cyclist, driver, pilot, bus passenger, metro/underground user, etc.  Each of these have very different requirements, problems and technical limitations.  Problems and weakness do not always have to be solved (not all can be) but being aware of them is important.  Users can be warned of these limitations and it may be possible to avoid situations and circumstances that lead to trouble.  Even a basic “do not get this device wet” or “splashproof not waterproof” statement can be very useful!  A surprise problem or failure is always worse.  So try to pre-empt possible problems by considering a range of conditions that might be encountered in different real world scenarios.  Communication is almost always noisy, both in the traditional acoustic sense and due to ambiguity or misunderstanding.  And as communication is two-way (or more), these problems can occur at either or both ends.  The noise of a passing bus can prevent a clear signal for ASR or a human user.  Similarly, is a conversational user interface (CUI) the best option? [http://www.computerworld.com/article/3129098/artificial-intelligence/why-google-a-i-is-the-last-user-interface.html]

To help you formulate your ideas, I’ll suggest four broad themes to think about.  It is possible to consider one in particular or to blend these approaches:

  1. SOLO or SOCIAL (single or multi-user). 
  2. BASIC.  This focuses on the basic needs of the user more, e.g. simple A to B navigation.  So concentrate on getting from point A to point B efficiently and reliably.  A low-cost, no-frills option.  Perhaps more clinical or business-like.  Errors are expensive.
  3. FUNCTIONAL.  Focus on the purpose more, e.g. provide tourist information or other (most likely geo-location) information.   Perhaps more leisurely and relaxed.
  4. FUN.  Something more game-like.  Treasure hunts, scavenger hunts, geo-caching, hide-and-seek, laser-tagging using camera phones, Pokemon Go, Augmented Reality Zombie Run, Dragon Matrix [http://dragonmatrix.org.uk/] etc.

There is no reason to restrict these to standard phone apps either.  You could involve robots, drones, custom wearables, custom-built devices, signs/screens/sensors in the environment and so on.  Hybrid physical and digital systems are allowed.  Something different might be along the lines of self-queuing, self-moving chairs [http://en.rocketnews24.com/2016/09/29/never-stand-in-line-again-nissan-releases-propilot-self-queuing-self-moving-chairs-%E3%80%90videos%E3%80%91/]

Issues to consider include (not an exhaustive list):

Ensuring you have designed a robust architecture.  Think about your weakest link in the chain of events.  What happens if there is a failure in one module of the system?  Can you guarantee a reliable mobile data or wifi signal?  Remote areas often have poor internet access.  What happens if the signal drops, as can happen when using underground travel?  GPS rarely works inside or underground, or when satellite signals are blocked by buildings in dense urban areas.  Perhaps a system designed to operate off-line is a better approach, e.g. Google Trips [https://get.google.com/trips/].

Most maps and digital devices are “flat” while the real world is not.  Are there any 3D aspects that might prove problematic?  Lorries and double-decker buses still occasionally hit low bridges.  There are strict safety regulations on “stacking” of aircraft around airport.  Are stairs or the use of underpasses a problem?  An example scenario might involve getting from Evo House to Informatics (some routes may involve encountering areas of construction work).  Or some way of guiding people around Evo House or the Informatics Forum (remember to consider which doors are locked, require keycard access or are only open at certain times of the day).

You may choose to concentrate on a specific location or smart space.  Following on from the Collider on 14 October, you may want to design something to aid the user experience in a museum or gallery.

Your system should be generally accessible and usable, but consider developing a system that is particularly friendly for at least one non-typical user group, such as:

Evaluate your system.

When you have developed your project sufficiently, use the Wizard-of-Oz paradigm to demo the system.  A single good case example is sufficient, or multiple if you have time, but there should be at least one analysis and commentary as part of your documented write-up (this could involve video, transcription, feedback, user comments, etc.).  This should show how your system could adapt to difficulties.  For example you could simulate background noise during testing by playing a recording of traffic noise, surrounding conversation (busy restaurant), dogs barking, someone talking to the user at the same time (tracking multiple conversations in parallel), a baby crying, children running around and needing shouted at.  Team members can act these roles out.


Your task for Assignment 2:

  1. Consider an appropriate system, user group and scenario as discussed above.
  2. Consider the design guidelines and previous work/examples covered in the lectures so far.
  3. Write a proposal describing your system and how you would develop a prototype.
  4. Evaluate the proposal (a mock prototype is sufficient – you should be good at acting and using your imagination by now) by testing a scenario Wizard-of-Oz style.
  5. You should try to restrict the proposal and evaluation write-up to 4000 words.  There is no limit to the number of images/illustrations/videos you may include.  References to relevant literature should be included where appropriate.
  6. You should prepare a 10 minute group presentation of your system and results.


Home : Teaching : Courses : Cdi1 

Informatics Forum, 10 Crichton Street, Edinburgh, EH8 9AB, Scotland, UK
Tel: +44 131 651 5661, Fax: +44 131 651 1426, E-mail: school-office@inf.ed.ac.uk
Please contact our webadmin with any comments or corrections. Logging and Cookies
Unless explicitly stated otherwise, all material is copyright © The University of Edinburgh