/
Lumen Learning Analysis of Utility Simulation

Lumen Learning Analysis of Utility Simulation

Apr 12, 2017

Introduction

The Floe Project assisted Lumen Learning by performing an analysis of some of the interactive assessments and learning tools within their platform. Floe provided Lumen short-term and long-term recommendations to help improve accessibility and inclusion. From this partnership, Floe created the "(Inclusive) Web Games and Simulations" entry in the Inclusive Learning Design Handbook as a resource to help other organizations.

 

The following is an analysis of the 'Utility Simulation'. The findings below are not exhaustive - rather it provides examples of the kinds of issues to be aware of. Where appropriate, recommendations, resources, and possible solutions are given.

Also see Inclusivity and Accessibility of Interactive Web Games and Simulations for additional resources and guidance on creating accessible and inclusive interactive content.

 

Table of Contents

 

Significant Issues

Issue

Reccomendation

For students who are more willing to explore and experiment, this simulation works well for them. If a student is more cautious or likes to understand things before acting, this simulation is unforgiving. Many times the learner is:

  • forced into advancing even though they may not be ready

  • unable to go back and choose different options

  • not given opportunity to review concepts

  • Give more options for users to retry and review.

  • Change wording of choices as to not make the student feel they have failed to understand.

Screen readers offer higher degree of control of navigation than just conventional keyboard interaction. This unfortunately allows a screen reader user to get into states which break the experience of the simulation:

  • items which are supposed to be non-interactative and hidden are focusable by the screen reader and are read out loud

  • inconsistent focus order

  • Elements which are supposed to be completely hidden to users, including screen readers, should follow established techniques.

  • Improving document structure through use of HTML semantic elements, and WAI-ARIA should help improve screen reader navigation and focus order.

  • Focus order should go from top to bottom and left to right in most cases.

  • Test with users of screen readers and keyboard users to further identify issues.

Important visuals (like graphs and tables) are background images which are inaccessible to screen readers. These images also lack any text descriptions.

  • Use W3C recommended technique for describing complex graphics.

  • Background images are for cosmetic purposes only. Graphs should have appropriate use of <figure> and <img> elements.

  • Graphs should have data tables (possible implementation described later in this document)

  • Tables should be HTML <table> and not images.

Choices

Issue

  • Some screens only have 1 option and forces the player forward.

  • Sometimes offer more choices or opportunities to seek out further explanation.

  • Example: in the definition of margin, the choices are either “Got it” or “Grumble”. In both cases it assumes the learner understood what margin meant which may not be the case.

  • Example: on the node that says “Let’s take our little animal example and apply a few economist tools to it”, the user is forced to advance. Perhaps give choices for users to review topics like margin and utility.

Recommendation

  • Change the wording to be more accommodating.

  • Also see "Interface Vocabulary" below.

  • Provide opportunities for users to review, revisit, or retry before proceeding.

Issue

  • Sometimes it is unclear what some choices mean.

  • “Say that in English”

    • implies that there is "something wrong" for not understanding it

    • What is the outcome? The words are already in English.

    • Users need to be familiar with this colloquial language.

  • “Say that as an economist might say it”

    • Unclear what this means and what the outcome is.

Recommendation

  • Change the wording to make it clear what the outcome would be.

  • See "Interface Vocabulary" below for recommendation on changes.

Issue:

  • There is a lack of closure on after going through the Marginal Utility per Hour sim (choosing between Apples and Berries). It just ends rather abruptly.

  • Feedback (i.e. "Great" / "Excellent") wasn't enough to offset the feeling that you could have made better choices.

Recommendation:

  • Add a reflection / summary at the end to recap what you should have learned.

  • Feels like there are multiple paths through the MU sim, but there's no way to go and explore those options. Give users the opportunity to retry parts of the sim to learn something new.

 

Interface Vocabulary

While the overall tone of the simulation is humorous, there are instances where the vocabulary used may be at odds with the state of the player. This creates a disconnect between the player and the game - especially for users who may be having a hard time understanding the concepts.

For example, a number of times the interface only gives the player the option to advance by selecting "Got it", "I agree" etc. when in fact the player may not "get it" or even understand enough to "agree".

In these cases it may be more appropriate to assume a more accommodating tone.

 

Current Phrase

Example Revision

Got it.

Okay. Let's continue.

Say it in English.

Can you say that more simply?

Say that as an economist might say it.

How would you say that in more technical terms?

Go back one.

Go back to previous screen.

The "utility" - the value - of water...

The "utility" (value) of water ...

Hold on there, cowboy What do you mean...

Hold on there. What do you mean ...

I agree. Let's move on.

Okay. Let's move on.

If we must.

Okay, if we must.

I'm getting bored. What else?

That's a pretty graph. What's next?

Makes sense.

Alright, what's next?

Grumble. This is why people don't like Econ classes.

Grumble. This is why people don't take Economics classes.

Apples. (4 hours)

Apples. (Takes 4 hours)