Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 29 Next »

There has been some interest in the community to get this project moving, so stay tuned as we try to schedule a conference call in the upcoming month.

It has now become clear that the Sakai out of the box (OOTB) help files are suffering from a lack of attention. This everlasting issue has been lingering for the longest while, with bursts of interest occurring here and there, as the following links demonstrate (this list is incomplete, please add yours):

It is now time to gather members of the Sakai community and Foundation to tackle this problem once and for all. Bad documentation leads to unnecessary local efforts that do not find their way back to the OOTB help files. Now that so many schools are looking at LMS alternatives, and that the Sakai community wants to promote the use of Sakai, this is a blocker to adoption for many.

Recent threads on the "Sakai User" list has generated interest in this process. It's now time to walk the talk.

Who's Interested?

Name

Email

Institution

Expected contribution

Mathieu Plourde

mathieu@udel.edu

University of Delaware

Ideas, workflows, leadership (Needs Assessment/Ideas, Standards, Editorial Board, Writing, Project Management)

Alan Regan

alan dot regan at pepperdine dot edu

Pepperdine University

Ideas, workflows, content (Needs Assessment/Ideas, Standards, Editorial Board, Writing)

Lorie Stolarchuk

lorie@uwindsor.ca

University of Windsor

Pain points of current situation, integration joys/woes of Brock's MediaWiki, ideas (time permitting )

Robin Hill

hill@uwyo.edu

University of Wyoming

Content, editing... whatever I checked on Alan Regan's form (Standards, Editorial Board, Writing)

Sean Keesler

sean.keesler@threecanoes.com

Three Canoes

Project Management, Writing, Workflows, Editing

Matt Clare

Matt.Clare@BrockU.ca

Brock University

We're more than happy to share our documentation at http://kumu.brocku.ca/sakai A lot of MediaWiki experience. Big advocate of ease-of-edit and radical trust.

Greg Doyle

 

University of Cape Town

Writing

Margaret Wagner

mwagner@umich.edu

University of Michigan

Ideas, Writing

Trisha Gordon

psg3a@virginia.edu

University of Virginia

Content, editing, ideas

Kara Stiles

kstiles@rsmart.com

rSmart

Content, Writing

Rafael Morales

rmorales@udgvirtual.udgd.mx

University of Guadalajara

Localization

Adam Marshall

adam dot marshall at ox.ac.uk

Oxford uni

content (& video scripts)

 

 

 

 

 

 

 

 

Some areas of contribution to consider: Project Management, Needs Assessment/Ideas, Accessibility, Standards, Editorial Board, Writing, Programming/Development, Workflows, Localization (Internationalization/Translation), Screenshots/Videos.

Key Questions

Before we start defining our process, please share your thoughts the following questions:

1. How do we define "end-user documentation" - purpose, audience, and content? And media?

  • Purpose
    • to document the OOTB experience
    • to document configuration options that change the OOTB experience
    • to demonstrate how to accomplish common tasks
  • Audience
    • Faculty should be a primary audience
    • Instructional designers
    • Could we consider faculty as end-users and students as end-end-users?
      • Faculty design choices influence student user experience
  • Content
    • Beginner and Advanced levels would allow a faculty member to get a quick start with the basics and then later explore the more complex features
    • Conceptual Introduction - brief description of the purpose of the tool
    • Task oriented instructions
    • Brief (3 min?) screencast
    • Annotated screenshots

2. What do users need to accomplish their tasks in Sakai?

  • Big picture of what a site is (have a blueprint)
  • Prompts to get started
  • Performance support: job aids, hints, glossary, explanation of expected behavior
  • Access to step by step documentation
  • Templates
  • Examples of what other faculty have done
  • Shared learning contents, activities

3. How do users find support when they hit the wall?

  • Trial and error
  • Call IT for help
  • Look at first page of information that they can find and glance at
  • Search help by keyword
  • Search using Google
  • Consult with colleague in next office, or ask office staff

4. What works in the way our documentation is organized?

  • Clear step by step instructions on how to technically use the tools
  • Follows the same pattern as the system (tool-centric)

5. How should the help documentation be organized?

  • Tools
  • Tasks
  • Warnings/Booby traps/Known Issues
  • Practices/Pedagogical content
  • Use of a taxonomy to allow quick retrieval and navigation

6. What is the current process used to revise and improve the OOTB documentation?

7. What are the difference between help files and other documentation?

  • FAQ: What users are asking after having used the system
  • Tasks: Based on workflows, not on tools (Setting up a course site vs. using Site Info, for instance)
  • Help files tend to be in text, other documentation might be in document, audio, video, picture format.
  •  

8. How can we encourage the Sakai community to contribute their improvement back to the OOTB help files?

  • Provide an easily editable platform for central documentation
  • Provide guidance on what should be contributed back, and how
  • Provide ways to point to localized documentation to supplement the core help files
  • Have a vetting process in place to accept/reject contributed changes
  • Make the help files easily "subscribable", customizable, exportable in multiple formats for quick local updates

9. How should we vet the quality of the OOTB help files?

Collaborative review and verification-- inconveniently tedious and time-consuming, and dependent on careful coordination-- with the same level of respect and attention accorded to QA of code.

10. How should we address the branding and localization issues (different names, logos, style sheets, languages)?

  • What is the difference between localization and branding?
    • Good question
      • I offer the suggestion that "branding" refers to the name and/or logo that an institution may give their instance of Sakai.  Michigan calls their instance "CTOOLS," Indiana "Oncourse," VirginiaTech "Scholar," etc.
      • Localization would refer to providing the same helpful information in multiple languages or regions, e.g. Spanish, English (UK), English (US), French, German, Chinese, Japanese, etc.
  • For "branding," can we provide definable fields.  One definable field might be "brand name" that would default to "Sakai" out of the box (OOTB) but allow an institution to replace with their local instance's name.  The text of the help files would either dynamically (or periodically) lookup and insert the local brand name into the help files.  Similarly, a definable image source could be provided for a brand logo and placed into the help files.  And definable formatting colors could also be available, which would insert the colors into the appropriate CSS and/or HTML source.

11. "Wish list" thoughts?

  • Low-Tech Quick Looks-- static web pages (even simpler than videos) that faculty can look at in a spare 5 or 10 minutes, with boxes and arrows, like Oxford's explanation of the Wiki tool.  Public, with no login required.
  • Pop-up on initial entry to site
    • On first access to a site, person is presented a simple welcome pop-up with three options: video overview, getting started tutorials, or exit.
    • Pop-up is role-based. Students see student materials, instructors, etc.
  • Tool help
    • Tool-based help pages should be easily navigated by the person's role in the site (yet other role materials accessible but not cluttering the current view).  Students report getting lost in the help pages since it's not clear which pages are for them.
  • A document librarian

NOTE: Improvements to the design of the learning environment (many of which are planned in S3) will also go a long way in improving the ease and usability of the service. Providing mouse-hover tool tips and other prompts will offer "just-in-time" support on the page. Of course, this will not eliminate the need for helpful built-in documentation and other support pages.

  • No labels