Introduction to Design

Design 101

Explain what 101 signifies to non-US users, or rename An Introduction to Design? 

We realize many people in the Sakai community work in small teams and wear many hats. We've talked to many developers that don't get to work with designers on a daily basis. If this sounds familiar, this Design 101 section is for you. It's not meant to be inclusive instead we've identified key design tips that we feel are helpful to think about when you're designing a Sakai Tool.

Why care about Design?

• We all want users to want to use our applications
• Save time in the end on refactoring and even bug fixing
• Avoid implementing unneeded or even unwanted functionality
• More likely for the system to match the way users work which means less support calls and questions
• Innovation - understanding users, their goals, needs and workflows helps us be innovative in the way the user interacts through the system.-
  -Drag and drop in images was designed after understanding the dynamics and importance of seeing the context of a group of images while organizing it.
  this is not resonating with me, too long and not sure what the point is here, reword or remove?

Proposed Design Process 

*Insert image here*

Design tips for developers in Sakai development

• What tools do you like to use? Why do you like them?
• They solve a specific problem: bugs are easier to track using JIRA than email, for example.
• They match up with the way you like to work.
• No wasted effort
• Correct, clear terminology used
• They look 'right' - even if 'right' for you means 'completely plain'

Idea generation

• Start out with a high level vision of your new application or enhancement.
  • Examples:  Allow instructors to present images to their students, Allow instructors to post syllabi
    The word faculty is ambiguous since it means something different outside the US; use instructor or other
  •  
• Define some hypothesis about what the system will need to do that you will check with real users.
  • Talk to and observe users doing the activity now (in the digital world or in the analog world) to see how the system can support their work and hopefully help them more efficient without taking away needed details.
  • Don't understand what 'digital' or 'analog world' means in this context?

Create requirements

• 80/20 rule
  • Don't try to fit it all in - hide the stuff that's used less often
  • Less is more (i.e. less clutter is more functional) - good point but is the same as 'don't try to fit it all in' - so that makes it clutter!
  • Example:  Advanced features can be added in different sections, under expanding blocks (i.e. click the little arrow and the block opens up with the extra options), or perhaps under an "advanced" link so a user can cruise through the typical (80% case) workflow without the additional decisions to make.  Even making the decision that I don't need to fill out this field is work for users.
  • No! the little triangle of death! No, seriously, worth reminding them that if they're going to have a 'click the little arrow' scenario, the little arrow needs to be large enough for people to be able to click on it while using a dodgy mouse with the computer balanced on their lap.
• Talk to some real users - We are not users but it's very easy to think we know them well and are doing the right thing for them. Falling into the trap of building for ourselves is very easy. Talk to a few users  and put yourself in their place while thinking about the design
  • What would Judy want?
    • Note: Do NOT only talk to one or two users!
  • Would Judy use this feature?
  • Example:  Although librarians may want to add a ton of metadata about a file they post in resources, our typcial user just wants to make the file available with minimal work. 
  • Potential avenues for connecting with users
    • Most of us live in our users' environment - get out on campus and talk to people. 
    • training and support groups or others that have contact with faculty, students, etc.
    • "Lemonade stand" - offer students a candy bar to spend a few minutes looking at your design
    • Instructors are busy but we've had good luck getting some of their time since they are most interested in Sakai working well for them.  We gave out gift cards to a local coffee shop.
• Figure out what's generally true about your users
  • Learn about enough individual users to separate out the quirks from the common behaviour patterns
  • Many times the people that shout the loudest are the ones with the unusual requirements
    • Example of an app built or changed for an idiosyncratic behaviour that gets in the way of the majority of users?
      Great!
• Build workflow to scenarios
  • Users do activities, not tasks/use cases - I don't get this?
  • May include working across tools in Sakai - but Sakai doesn't support this at all well. What does the developer do in this case?
  • Design for the "happy" scenario and build in the rest. Back to the 80/20 rule. Initially design the application as if all goes well so you know the main flow works well. This is true 80% of the time. Then start thinking about how to handle problems. - don't really get this one either?  does it mean that you write the help messages after?
  • Using real scenarios allows us to build workflows that match the way users work.
    • Example:  Webcast study tool? but how do you make sure your scenarios aren't overly specific to an individual? what's the difference between a scenario and a task?

Design

• Users don't think in tools silos - the activities they need to accomplish in teaching and learning likely cross tools. When you are designing Sakai tools think about how you can minimize the need for users to switch between tools. - I think this is an important point, but is it one that our beginner developers can accomplish ? Can they make helper tools? Also, Sakai is very bad at this! Or maybe I'm not getting the point?
  • Create a helper tool that allows users to complete a task from one tool in the tool they are working in currently. Example - Section Info "Add TAs"
• Software is a means to an end - anytime we make users think about how to make the application do what they need we interrupt their natural creative flow. The application should not get in the way of users reaching their goals. Many of us understand and are interested and intrigued by the way software works. Our typical users are not. I think that for developers, the two instructions here are more helpful than the "explanation". I think I'd drop the explanation.
  • Use meaningful defaults (on page load make sure the focus is in the first place the user is likely to need (form field)
  • Hide implementation details. The implementation model is irrelevant to users. The UI and the back end models will likely be completely different in order to meet the users needs.
• Consistency -  Are there conventions in web applications that users will know about? Users are required to do less "relearning" if we use known interactions.  Are there other tools in Sakai with the same or similar interactions? If so, use the same model. Users learn to do a particular activity and expect it to work the same way across an application. I'd turn this into an explicit insturction. 'Before you design your tool, look at all the other tools in Sakai to see if one of them already does something similar. If so, copy it. If two tools do it differently, why not ask the UI group for suggestions on which to follow?'
  • Web users are used to using bread crumbs to both "see where they are" and navigate back to a place they were previously.
  • Global action links are meant to allow users to navigate to each main page in a tool. Sometimes in Sakai they allow a user to take an action such as adding new item. So which should they do? And if they should only be navigate to each main page, how do you take actions? what's the difference between adding a new item and going to the 'add new item' page?
  • WYSIWYG editor should work the same across Sakai
• Am I using the same terminology that is used elsewhere in Sakai? Users can much easier and quicker recognize terms used elsewhere and know what to expect from them - if I click an 'edit' link I'll be taken to a page where I can make changes within this file. Anytime a different term is used users may have to think about why it's different - I used edit in resources but I only see revise for this announcement. How are they different? Does revise allow me to do less or more than edit does? Again, I think I'd turn this into an instruction. Instructions are just a bit easier to tick off for a hurried, busy developer than points to reflect on.
  • Lots of discussion about this on the dev and UI lists lately. Some work has been done here to agree on conventions and make them consistent across Sakai.
  • Even different styles of buttons can make users wonder the buttons interaction will be different than another one.
• User the end user's language - examine your language, trying it out on users if possible. Is it unnecessarily technical? Remember most users won't understand technical semantics. Is it consistent with usage in other Sakai tools? This makes sense to me.
  • Although tools within Sakai can be thought of as channels, most users would have no idea what that means.
  • Not only technical, users in different areas of expertise have their own "language". During our course management work, we found people in the registrars "back office" refer to related courses as enrollment sets. In talking with faculty and students, they referred to them as classes with sections.
• Test paper or early prototypes on at least a few real users. If this is impossible, test on someone non-technical and unfamiliar with system who will indulge you. We should explain what this means, and how you do it. Is it worth simply pointing people at Joel Spolsky's web page here? (on usability testing for developers) 
  • We all have own understanding and assumptions about the system. Basically those of designing and developing Sakai tools know too much. It's important to check our assumptions against users of the system.
  • For instance in Sakai we have Sections and Groups. Those close to this work know that sections are meant to represent official sections of a course and groups are more informal, ad hoc groupings of people. User testing has shown that our typical users are confused by this language and the fact that management of them are in 2 different places.
• Less is more - every piece of information or interaction on a page competes with every other piece of information and interaction on a page. By default only give users the necessary information to complete a basic interaction. Again, can we turn into an instruction. "Look at your page. Are there some settigns which aren't usually needed? If so, can you hide them behind a heading?" and show a picture.
  • One of the design pattern that will be released with the Sakai design pattern library is "extras on demand". Show section info. In the majority of situations sections only have one set of meeting times. If a user needs to specify more than one it is only one additional click to get the information they need.

Implement and Iterate

• As you implement your design continuously put the system in front of users to see how they use the system.
• We almost never get it all right the first time.
• Would be great to show a short video here.  LOOK ON YouTube.