LinuxLiom

Background

I’m in the process of building out the front end of my Mountain weather Application. In University I did two modules based on UI design, mainly oriented towards biomedical applications.

In these modules, theory such as Shneiderman’s eight golden rules of design and Neilson’s ten usability heuristics were covered. Application design was also part of the course, covering low fidelity design and cognitive walkthroughs. For the design of this app, I intend to use these principles and processes. Before building a low-fidelity design, lets cover the theory and how I will use it to shape the application. By the end of the post I will have some declarative statements. These should give a skeleton outline of what the final app should look like and how it will function.

Shneiderman’s eight golden

Here I will review Shneiderman’s eight golden rules and how they apply to the app I plan on designing:

1. Strive for consistency
   • I think this is relevant for applications with multiple windows. This app will be just one window but consistency will be considered.
2. Seek Universal usability
   • So where possible, make the app as accessible as feasible. Can I design it so a child or a non-English speaker can use it with little to no issue.
     • Where possible, use images to show weather state.
     • For user inputs like date range, Add a drop-down calendar widget, use a drop-down menu for mountain selection.
3. Offer informative feedback
   • When is an item is selected, have the GUI provide a visual and audible signifier to show there request has been registered.
   • If forecast data cannot be retrieved from the Met API, make it apparent to the end user.
4. Design Dialogue to yield closure
   • If forecast data cannot be retrieved from the Met API, make it apparent to the end user.
5. Prevent errors
   • Stop user from selecting passed dates or dates outside the forecast model’s range.
   • Confine the user to the scope of the programmed backed. Avoid random text inputs.
   • Make it clear which mountain’s forecast is currently presented on the main screen.
6. Permit easy reversal of actions
   • Add a panel for recent selections.
   • Possibly add a back arrow
7. Keep user in control
   • Make it impossible to input illegal inputs.
   • Avoid automatic selection where possible, recall inputs such as date ranges where applicable.
8. Reduce short term memory loading
   • With a “recent” panel, previous actions can be recalled.
   • maintain user inputs when changing selected mountains.

Great, after covering these eight rules I’ve pinned down some designs. First, lets cover Neilson’s ten usability heuristics before recapping.

Neilson’s Ten Usability Heuristics

Lets quickly cover these, many tread the same ground as the eight golden rules:

• 1. Visibility of System Status
  • Make sure it is clear which mountain is selected
  • maybe have a thread pining Met API in the back-end to confirm connection
• 2. Match Between the System and the Real World
  • UI mapping, I’m not sure If this can be applied in this application. A mapping design may become more apparent after the first low-fidelity design or cognitive walk-though is completed.
• 3. User Control and Freedom
  • Overlapping with some of the thinks outlined in the previous section, prevent out-of-bounds inputs, make inputs selection as intuitive as possible.
• 4. Consistency and Standards
  • review rule one of the eight golden rules.
• 5. Error Prevention
  • review rule five of the golden rules.
• 6. Recognition Rather than Recall
  • Keep date ranges when switching mountain ranges.
  • Possibly cluster ranges by region and not alphabetically
• 7. Flexibility and Efficiency of Use
  • Add panel for home/ favourite ranges of mountains.
• 8. Aesthetic and Minimalist Design
  • minimise clutter and bloat. If it holds no relevance to the current view, remove it.
• 9. Help Users Recognize, Diagnose, and Recover from Errors
  • Give feedback when an error happens, i.e. cannot retrieve weather data check local internet access.
• 10. Help and Documentation
  • Add help tab where appropriate.

UI Declarations:

Now that we have reviewed some theory, lets make some declarative statements before drawing some low fidelity designs and doing some cognitive walkthroughs.

User Inputs

• The user inputs should be limited to the mountains supported by the back-end, this can be done with a drop-down selection.
• Group mountains by locality, not alphabetical order
• Map date inputs with a calendar to select the dates. Lock out the selection of passed dates and future dates beyond what the forecast supports.
• Possibly add an advanced section, where users can append their own coordinates to their local app.

Graphics

To make the app as accessible as possible, emojis and graphics should be used to map purposes of user inputs. Graphics should be used to show the weather outlook selected to give universal and comprehensive feedback.

Application function

• Should allow favourite locations to be saved and easily recalled
• Should have the user option to either intuitively open the nearest location or the last selected mountain.
• Should have recommendations for locations in with favourable forecasts in a user selected time-frame.

Conclusion

This posting is getting a bit lengthy. Lets do some Low fidelity designs and congnitive walkthroughs in a follow-up post. Until then!