/
Co-design meeting notes 12/10/14

Co-design meeting notes 12/10/14

Dec 10, 2014

New meeting times:

  • Starting this week, we will be meeting every week

  • Wednesdays 4pm ETS (every other week)

  • Fridays 1pm EST (every other week)

Using wiki vs. Google doc

  • Consensus seems to be that it's easier to make comments in Google docs.

  • Shanee can not access the document via Google, but she said that is ok

  • Send a note to whole group, letting everyone know that we are using google, 

    • Please use another color if you are editing the body of the text. 

Dana's sketches

  • Incorporating sketches and some use cases from earlier work

  • Moving through the digital literacy aspect of first discovery

    • If there seems to a problem, ex. if person clicks a key that is inappropriate

    • You can do it incrementally - if use encounters issue, we teach them what thy need to now right now

    • At minimum: Choose language

    • Want to make it possible for user use it independently

    • tutorial of how to navigate the screen

    • Are we assuming the user can point?

    • Can we use demonstration first, to avoid any digital literacy at all. 

    • Start with establishing a way of communicating which doesn't rely on any digital 

      • Asking questions might be a barrier - it might be that asking a question 

      • Through the mutability of the tools, through the intuition 

      • Are we saying that design won't solve this, but asking question will? 

      • Some people will not be familiar with these systems, and they will bounce off of them. 

      • The questions that we are asking of them (frequently commands) are intended to establish 

    • We need to daw boundaries and scope this. 

      • If a use doesn't understand that they can select a language by touching 

      • Don't know if language 

  • Whitney - one thing we have learned working with people who are low literacy and low digital lit

    • How can we try this out?

    • Moving forward with testing protocols together

    • Before we create the testing protocol we want to make sure that 

    • We have to see what works and what doesn't

  • The way to test this, is to implement different approaches, if there are different approaches, and test them. 

  • Every persona that we use had used a computer before

  • Is the primary target is those people who would not be able to use explore tools?

  • Make sure we don't miss the same population who always gets left behind.

  • Kathy - maybe the place where we might see digital literacy issues in the elder care, might be in the elder care setting. 

    • Gregg These aren't people who can't learn these things, they just haven't

    • If users don't have digital literacy and have access needs - they get left out

  • Jess- the form of a questions, don't believe that a person who has never used a computer before won't understand how to use the interface

    • If we design something simile enough 

  • Kathy - maybe one of the issues that we want to make sure of, is that in this population that we are talking about

    • The group that we would test with includes people with digital literacy issues 

    • The only way to find out is to 

  • Whitney - All three of the personas are people who cam into the library

    • There is value in having 

    • Marney's example is interesting becuase very few people will 

  • Gregg - in addition to everything else ask them, what are you interested in?

  • John - where is the common dimension between 

    • The means and the mode are secondary to the task

    • Takes us back to the gamification ideas

  • Gregg perhaps we start with this interface here, if they run into trouble, then they

  • Dana - first page may be a pre-tool, a person may have someone helping setting this up 

    • Putting a language on the first page as a pre-tool is correct becuase then we know how we can communication

  • Rich - When they get stuck like that, can we provide a question? Stated, written, in sign language?

    • If they are not interaction, then the system goes back to asking the simplest question, with the simplest response

    • We found that the space bar was the easiest to find and use

    • Whintey, if they still aren't able to respond after sometime - that's the fail gracefully kind of moment]

  • Make sure that you have means of communication before you ask them what to do

  • But I like this as a fall back, becuase then the people who don't need this, won't need to see this

On second screen we are asking several questions, could we have one question at a time?

Rich - this might be too complicated for some users

  • If we eliminated the side bar with the different icons

  • There is a progress bar on the buttom as well. 

  • The visual presence, the size of the icons on the side looks just as important

  • Will there be an issues that this is in portrait layout?

  • Next and back button would bookend the progress bar?

  • A narrow focus - two columns in ballence don't work. 

  • Won't have two things that look like the same thing

  • There will only be four screen

  • The basic functionality needs to be established here, then we will lead them to another interface where granular preferences can be established

  • Bootstrap levels: 

    • Can we communicate with you at all? 

    • Can we find your required settings? 

    • Can we adjust the screen so that you can adjust settings further?

  • We need to know what minimum font size that they need to have

    • If they can't see anything that is smaller than this, then you can't use any font smaller than this. 

    • Jess - based on where we want to start.

    • Gregg - we may need to start larger than 4x

  • Whitney - The task of setting the screen size is a task that a use is willing to engage in. 

  • Balance between getting the user through, 

  • If we make everything larger, we could almost take away the instructions