Presentation is loading. Please wait.

Presentation is loading. Please wait.

Why Design Tips for Sakai? Small teams in higher ed means wearing many hats Not all teams have designers Meant to be a primer for developers doing design.

Similar presentations


Presentation on theme: "Why Design Tips for Sakai? Small teams in higher ed means wearing many hats Not all teams have designers Meant to be a primer for developers doing design."— Presentation transcript:

1

2 Why Design Tips for Sakai? Small teams in higher ed means wearing many hats Not all teams have designers Meant to be a primer for developers doing design 12 Key design tips

3 1. Start with High Level Vision Define hypothesis to check with real users –Example: Allow instructors to present images to their students Talk to and observe users –Understand how they get their work done –Images: digital images badly named if at all, used in many different contexts –Careful! Users leave out details!

4 2. 80/20 rule Less is more Don't try to fit it all in –Leave out edge cases –Hide advanced or less often used functionality

5 2. 80/20 rule

6 3. Talk to & Watch Users We aren’t primary users What would Judy want? Would Judy use this feature? Potential avenues for connecting with users Get out on campus and talk to Instructors and students are interested in improving Sakai Leverage other team member’s relationships

7 4. Find Out What’s Generally True About Your Users Learn about enough users to separate out quirks from common behavior patterns Loudest users likely have unusual requirements Don’t include idiosyncratic requirements

8 5. Scenarios Define Requirements & Workflows Model activities not tasks or use cases –Context and details Design for the typical the scenario –Workflows that match users work –80/20 rule May include working across tools in Sakai Example: Webcast study tool

9 5. Scenario: Using Webcast to Study Lisa has an exam coming up and wants to create a study sheet she can use for the next week while on the elliptical @ the gym. She gets out notepaper, her textbook, and her binder with PPT “ notes ” pages and gets comfy on the couch. She starts reviewing the powerpoints and notes from the lectures after the last exam. As she does this, she ’ s making notes (summarizing important topics) on her notepaper. (This will become her study sheet). As she ’ s making her way through the slides she decides it would be useful to hear the instructor ’ s explanation of DNA replication again. She goes to … a point in the webcast where that ppt slide is, and listens. One sentence he says seems to encapsulate the concept for her, so she tries to get it down word for word. Since her prof talks fast and does not always use lay terms, she relistens several times. After she feels like she understands, she adds some notes in the study sheet. She sees that there were a number of segments that she ’ d highlighted.

10 6. Users Don't Think in Tool Silos Minimize cross-tool workflows Automate cross-tool workflow Examples –Helper tool –Assignments and gradebook recent improvements to workflow –Data/information synchronization across tools

11 Section Info - Add TA’s

12 7. Software -- Means to an End Minimize user’s decisions about mechanics –Hide advanced and administrative tasks –Use meaningful defaults The implementation model is irrelevant to users - don’t reveal it “crazy, email line-breaking, non-human readable URLs which are designed to meet the system needs of uniqueness but not the human need of comprehensibility” Sean DeMonner, U of M

13 Implementation Details?

14 8. Less is More Are there some settings which aren't usually needed? If so, can you hide them? ”Extras on demand” design pattern

15 Less is More

16 9. Consistency Apply known web app conventions –Yahoo Patterns, http://developer.yahoo.com/ypatterns/ –“Designing Interfaces”, Jennifer Tidwell’s book Apply known Sakai conventions –Copy interactions from other Sakai Tools Style guide Sakai design patterns -- released soon! –Conflicting interactions or questionable usability? -- Questions to UI DG, sakai-dg@sakaiproject.org

17 Try it out on users! Users aren’t familiar with technical terms Look at other Sakai tools and copy their language Higher Education has own language –“Faculty” v.s. “Instructor” -- flexibility for local customizations

18 11. Test Early & Often on Users Those of us designing and developing Sakai tools know too much Finding users –Grab students in common areas –Leverage training sessions –Offer food “Something is usable if it behaves exactly as expected.” Joel Spolsky, http://www.joelonsoftware.com/design/1stDraft/03.html

19 12. Ask a Designer If you have access to designer(s): –Get them involved early –Once architecture is in place only minimal changes can be made If you don’t have access to a designer: –Ask the UI DG, sakai-ui-dg@sakaiproject.orgsakai-ui-dg@sakaiproject.org –Recruit a designer from another institution for your working group

20 Sakai Development -- what’s hard, what’ easy Aaron & Hattie’s slides inserted here.

21 Thank You! Questions?


Download ppt "Why Design Tips for Sakai? Small teams in higher ed means wearing many hats Not all teams have designers Meant to be a primer for developers doing design."

Similar presentations


Ads by Google