Reading: Drop Nice-to-have Features

This week’s reading exhorts us to be very careful with adding features. It suggests that, once a list of potential features is made, it’s a good idea to cut that list in half, and cut what remains in half again. Decide what is truly essential to the operation of the application, and leave everything else out. Unessential features get in the user’s way when they’re trying to accomplish their goals.

One way of thinking about the problem is a variant on the 80-20 rule. 20% of the application’s development time covers 80% of the essential functionality. Or, 80% of the development time is used developing features that only are used 20% of the time. The author suggests just spending the 20% of the time, and using the other 80% to take vacations, get more sleep, or develop other software. “Aim Low.”

As an exercise, go through old work that you’ve done, and do some “interface surgery” on it. See what you can remove from the interface with an eye to make it more streamlined and easier to use.

Lastly, the author suggests that frequently, the features you had in your nice-to-have list, will not be what your users are complaining is missing. It will be a number of other problems instead. Focus on what’s not working for your users, and forget about your own list of nice-to-haves.

Reading: Drop Nice-to-have Features

Brainstorming and Screen Size

Task: Alarms

Solutions from Brainstorming

For this task, I sat down with a partner and we took turns saying ideas for how the alarm setting system might work and look. For this brainstorm, we focused on what kind of data needs to be entered.


Alarms can be set by location, so the device needs a way to add a location.

Ideas included:

  1. Street map
  2. Map of Galaxy
  3. Shortcut for current location
  4. Parsecs (whatever those are)
  5. Street address
  6. Star System
  7. XYZ coordinates
  8. Planet Latitude/Longitude
  9. Point in orbit
  10. Vague, fuzzy description
  11. Altitude
  12. Presets for commonly visited places

On evaluation, it seemed that some universal way of defining a location would be needed, but having local options would be potentially useful to quickly set a location based on current context. For example, Earth-based street addresses might be useless on the Doctor’s home planet – I’m not sure if his planet even has streets – they are certainly useful when he’s on Earth. Saved locations would be especially useful if they’ll be used more than once.


Since the Doctor travels through time, the settings for alarm times will need to be more detailed.

Ideas for time inputs:

  1. Phase of moon
  2. Galactic epoch
  3. Astronomical time
  4. Orbit timing
  5. Year, month, day, etc
  6. Number of seconds since Big Bang
  7. Number of seconds from now
  8. Time until some event
  9. Harmonic convergence
  10. Time of a planet location
  11. When two or more planetary bodies converge
  12. During retrograde events
  13. Moon is in the 7th house
  14. Half-life of some radioisotope like carbon-14
  15. Speed of light
  16. Time light takes to reach home planet from star
  17. Home planet time (days, years, etc)
  18. Stardate

On evaluation, it seems like beings as advanced as the Doctor would have their own universal time units. The decaying radioisotope approach seems especially reasonable and accurate. Once again, when traveling, some way of entering a locally used time would be useful to avoid having to mentally convert between universal time and local time.

How Does the Alarm ‘Go Off’?

Finally, an advanced alarm like this one seems to need more features than a simple beep. Sometimes, any sort of sound at all might be dangerous. Here are the ideas we generated:

  1. Attach note to alarm
  2. Verbal message
  3. Keep quiet when in danger
  4. Snooze
  5. Send straight to brain
  6. Visual alarm
  7. Scrolling message
  8. Can be dismissed
  9. Password to dismiss
  10. Alarm that won’t go away until a condition is met
  11. Notifies somebody else if you don’t respond
  12. Starts pulling you toward something
  13. Engage homing device
  14. Put in a Panera order when you’re 10 minutes away
  15. Starts kettle of tea
  16. Activates another device
  17. Monitor heart rate to decide whether or not the Doctor is in danger

In discussion following this part of the brainstorming, we decided that the most important thing is that the alarm not put the Doctor in danger. The watch should intelligently handle this by itself, because it’s too easy to forget to put the watch in silent mode. (See pretty much every social situation in the early 21st century.) Next in importance, given all the different times and places for alarms, is the ability to tell the Doctor what they’re for. Some sort of short note explaining the alarm’s purpose would be useful. The alarm should be snoozable in case it can’t be dealt with at the time.

Task: Homing

Solutions from Trigger-Based Brainstorming

A partner and I sat down and used the Trigger method. We each wrote down ideas for how the watch could indicate the direction of the TARDIS. Then, we swapped papers and expanded on each others’ best ideas.

Here are the ideas that seemed best:

  1. Project on the ground
    1. Route to follow
    2. Arrow pointing at TARDIS
    3. “pond rings” radiating from TARDIS
  2. 3D enhanced reality
    1. Show route emanating from user
    2. Show turns off in the distance
    3. Show a TARDIS icon on the horizon
  3. 3D flyover map
    1. Holographic Google Earth except the whole galaxy
    2. Like a planetarium
    3. Route and location of TARDIS in holograph

Human Interface Ideas

Given the complexity of data inputs and outputs, the display may need to be fairly complex. Entering data and displaying data will need to be carefully designed.

Display and interface ideas we found:

  1. Manipulate watch bezel to change settings
  2. Miniature planetarium display
  3. Project on wall
  4. Project directly onto retina
  5. Send sound directly to inner ear (inaudible to others)
  6. Project on ground, especially for homing
  7. Just the watch face
  8. Any nearby piece of glass like a car windshield
  9. Magnetism (gently pulls user in a direction)
  10. Hot and cold
  11. Compass
  12. Voice directions
  13. Brainwave interface
  14. 3D holograph
  15. Watch hands move to point out directions

On evaluation, small features like watch faces won’t really be large enough for complex displays. Since the Doctor is a social creature, having the ability to share the display seems to rule out direct to eye/ear/brain methods, especially when dealing with less advanced species. Projected or 3D displays seemed to us to be the most shareable.


For the alarms interface, the idea of a 3D spherical display projected above the watch seemed to make sense, especially in light of needing to set a location for an alarm in a 3D universe. Mapping a single sphere in two dimensions is a whole science unto itself. Finding a spherical planet among many using a two-dimensional representation seems like it would be very difficult. Planets would potentially be on top of each other. Also, with a display in thin air over the watch, I find myself gesturing at it with my right hand as if spinning a globe. Zooming could be either a spreading/pinching gesture, or a scooping/pushing/pulling gesture.

Going with the 3D approach, I tried to imagine how setting time and alarm notes would be done, since those are solved problems in 2D rectangular displays. Since the display is spherical, I’m imagining a ring-based interface wherein sets of related options, such as terrestrial year occupy one ring. The circular shape would fill up the sphere in two dimensions nicely. To move between option sets, the ring sets’ circle could be ‘flipped’ to show a new screen.

Brainstorming and Screen Size

Inspiration: Prototyping with Arduino

When making physical devices, it’s often useful to make prototypes of the object first. For high-fidelity, but perhaps not feature-complete prototypes, the Arduino platform is a rich resource.

Arduino refers to a microcontroller ecosystem that includes a set of standardized, open source hardware boards, and an IDE for developing simple software to drive the hardware. The hardware is built out of extremely cheap and commonly found integrated circuits and electronic components attached to printed circuit boards designed to be easily attached to external components via a breadboard.

Once the prototype is working, the engineer can then create a circuit board design using the exact same components. This design can be sent to a custom PCB manufacturer that can manufacture small or large runs of circuit boards.

I’m currently working with Arduino boards for an HCC independent study. The assignment is to build a working prototype of a data glove combined with inertial measurement units to recognize hand gestures. The parts are easy to snap together on a breadboard, and each component has example code that can be adapted to the project. So far, I’ve had to write very little code to get usable data either a USB serial connection or Bluetooth serial connection. For the shoulder and elbow-mounted IMUs, I’ve only had to change a half dozen lines of code just to get the desired output formatting.

IMU attached to an Arduino Micro with integrated BLE


Inspiration: Prototyping with Arduino

Reading: Task Analysis

The main purpose of task analysis is to identify the actions – observable behavior – that are required to complete the task. This is a separate analysis from something like GOMS, in which the purpose is to get a sense of what is going on inside the user’s head.

Hierarchical Task Analysis

A Hierarchical Task Analysis is a breakdown of major tasks, and their subtasks, as well as a set of plans that describe the order and conditions subtasks are performed. Subtasks will not always be performed – they can be conditional as described in the plans.

The granularity of the subtasks depends upon the purpose of the task analysis, and on stopping rules. One stopping rule is the P x C rule where if the probability multiplied by the cost is below a threshold, stop creating subtasks. Another stopping rule is where the task is broken down to the point where many small mouse or keyboard interactions would have to be described. A third stopping rule is where a user must make a decision. Breaking down mental processes is likely beyond the scope of the system being created.

Once a first attempt at making a HTA is completed, it is a good idea to examine it for omissions or mistakes. Subtasks can be refined to reflect repetitious patterns, discretionary events, and wait times.

Knowledge-Based Analysis

Knowledge-based analysis attempts to group things into taxonomies. Eg. steering systems and light systems in a car. Determining the grouping can be quite difficult. Experts can be asked about the systems, or non-experts can be asked to do a card sort. In subsequent iterations of the analysis, groups can be created, merged, or changed.

One type of knowledge-based analysis the author uses is the task-analysis for knowledge description. This uses Task Descriptive Hierarchy, which is a way of uniquely describing each object.

Overall, KBA is designed to give a general sense of a system, rather than the ‘how to do it’ of HTA.

Entity-Relationship Analysis

Entity-Relationship task analysis, like Knowledge-Based Analysis, tries to capture objects and actions, but emphasizes the relationships between them, rather than their taxonomy.

Relationships will be between objects, such as human actors, and things being acted upon (patients). Objects will also have relationships with actions, such as subsystem x does y. Events are things that ‘just happen’, ie. there is no specific actor doing the event. For example, temperature dropping below a threshold. Objects can have relationships with events, too. For example, if temperature drops below 65 degrees F, the furnace turns on and heats the room.

Complex relationships can be broken down into messages. Person 1 tells person 2 to do something, and they do it. Person 2 is both patient and actor.

Data Sources

Data about tasks can be found in several places.

Frequently, there is existing documentation, that though not written for task analysis, can be perused for information about tasks. The main caveat is that these describe how something is supposed to be done, not how it actually is done. Further probing will be needed.

Tasks can be observed as they are being done. Observation can be passive, where the task is simply observed as its being done, or active, where questions are being asked about the process as it’s happening. This has the advantage of showing the actual task as it’s being done, but this is very time consuming.

Lastly, information can be gathered from the human actors via interviews. Direct questioning can quickly get to desired information. This is especially helpful after spending time observing the task so that the right questions about unclear elements of the task can be asked.

Comparison of Techniques

Each technique works best for certain types of problems. Hierarchical Task Analysis is best for explaining simpler tasks, especially when producing instruction manuals. For more complex tasks, Knowledge-Based Analysis is capable of supporting more complex structures and concepts.

Further, taxonomies developed through analysis can be the basis of user interface menus.

Reading: Task Analysis

Inspiration: Codrops

Codrops is a blog by two authors and several regular contributors that’s dedicated to web design. It’s a mix of technology and design.

On weekly feature I like is the Collective which features an innovative website for design inspiration, several JavaScript or CSS tutorials, a featured typeface, and some ruminations on design in general.

For inspiration, its Playground features interesting, usually interactive designs. The methods used to build the demo are usually explained.

Inspiration: Codrops

Reading: Prototyping

The reading for this week focused on defining what prototyping is, and its advantages and limitations.


Typically, prototypes are either high-fidelity or low-fidelity. The reading mentioned medium-fidelity prototypes, but suggested that the limited benefits of this type do not outweigh the cost of producing this type of prototype.

Low-Fidelity Prototypes

These are prototypes that roughly represent the layout of an application or physical device, but only describe, not implement, its functionality. The advantage of low-fidelity prototypes is that they are quite cheap to produce, and allow the designers to create many iterations of the prototype. Low-fidelity prototypes can take several forms, most of which are on paper:

Storyboard: These are used to prototype the usage of what’s being built, by telling the story if its usage.

Sketches: Often, paper-based prototypes are drawn by hand. They don’t have to be works of art, and prototype makers can use symbols or icons in place of items that require detailed drawing. This helps get around the inhibition of bad drawing skills.

Wizard of Oz: The prototype is tested by someone who acts as if the paper or 3D prototype is real, while an operator manipulates the prototype as if it was responding to the user’s inputs. For example, a drop-down menu on a website could be created in paper form, and shown when a user “clicks” on it.

High-Fidelity Prototypes

High-fidelity prototypes have at least partial functionality implemented. Often, they involve writing code, which may or may not be incorporated into the final product. The advantage of these is that it’s easier to communicate how the product will work. One disadvantage is that the cost to make these prototypes is rather high. There needs to be a  good reason to invest the effort into making a high-fidelity prototype.

Another problem, one I’ve encountered in my own work, is that, because of the cost to produce a high-fidelity prototype, it is tempting to keep the prototype as the finished product. One team I worked on had us making “prototypes” of the web-base user interface we were building, but all of them ended up being used in the final product. This can be OK when done deliberately, but in this case, the code wasn’t written in such a way to be maintainable as new features are added.

Reading: Prototyping

Reading: Brainstorm, Chainstorm, Cheatstorm, Tweetstorm

The purpose of the research in this reading was to experiment with methods of developing novel ideas and approaches to problems without spending a lot of time doing traditional brainstorming.

In traditional brainstorming, a group of up to a dozen or so people are gathered together, and under a certain set of rules, encouraged to rapidly share ideas to address a problem. The emphasis is to not judge the utility, feasibility, or craziness of an idea, but to just get the ideas recorded. After the idea generation session is over, the group may vote on which ideas are the most useful.

While brainstorming is a well-understood, and often useful method of generating ideas, it suffers from a few problems. It can be inefficient, in part, because several people need to have schedules arranged, and are often taking time from other duties, and in part because the time spent as a group generating ideas could possibly be spent with each individual generating ideas by themselves. For example, six people brainstorming for an hour doesn’t necessarily produce six hours worth of individual work.

The researchers attempted to get around this problem with a few different methods.

Chainstorming skips the idea generation phase by attempting to match up pregenerated ideas from other brainstorming sessions. The results of that were pretty striking. The pregenerated ideas seemingly had nothing to do with the presented prompts, but matched surprisingly well.

Reading: Brainstorm, Chainstorm, Cheatstorm, Tweetstorm