Skip to end of metadata
Go to start of metadata

Quick Links & Helpful Information

Current sub-sections of work

Weekly call-in infomation

See the Implement ion Summary Page

Mondays, 9 am pacific, Noon eastern and 17 BST at SAK001

  • IP Address:
  • Telephone: 812-856-7060
  • Conference Code: 348
  • PIN: 72524

News & Updates

Worked On Last Week:


  • Issue 1.2.3 Design is done. HTML is no longer needed. Will send Nico the screens.
  • Issue 1.2.5-7 Deferred until all other tasks complete
  • Issue 1.3.2 - Design is done. Will send IU team the screens.
  • Issue 1.3.3 - Design is done. Will send Nico the screens.
  • Issue 4.2.2 - Design is done. I sent Chen the screens. She may need icons, but will let me know when.


  • Wrote documentation
  • Almost completed the "grid" view feature in the tools widget.
  • Other smalls odds and ends

Chen & Michelle

  • Distracted by local production issues, but are 45-50% complete with issue 4.x.x (aka Edit Preferences)

Worked Planned For This week:


  • Issue 1.3.5-7 Design was started and is about 30% complete. The remainder will be worked on this week.
  • Issue 1.6.4 Will review Nico's updates and offer design changes is needed.
  • Will also work with Ashish from Georgia-Tech to prioritize the next piece of design work.


  • Will try implementing the "Create New Account" screen by himself (without HTML support)

Chen & Michelle

  • Plan to continue work on 4.x.x with expected completion date of end Sept / early Oct.

General To-Do's

  • Still need to resolve how JIRA will be managed for this project. Peter will hopefully lead the effort – but further discussion is necessary. I suggest we start email thread to discuss how best to use JIRA and Confluence to manage both development tasks and design tasks.
  • Connect UofM folks (Gonzalo & Zhen) with Berkley and Nathan to plan design project around course management, groups, roles, etc.

Other Notes

  • No developers from UofM were able to make the call.
  • Several people from Berkley may be joining the UXI design/implementation effort in the next week or so.
  • Overall completion of the project still very difficult to estimate.

Last week we had an open call to discuss implementing the UX screens that came out of the first UX Improvement design project.

This Wednesday a small but eager team came together in a kick-off meeting / working session aimed at implementing the screens.

People on the call (many of whom comprise the working team) include:

  • Michelle Wagner, Chen Wen, and Lance Speelmon from Indiana
  • Gonzalo Silverio and Zhen Qian from U of M
  • Nicolaas Matthijs and John Norman from Cambridge
  • Oliver Heyer from Berkeley
  • And yours truly, Nathan Pearson

The meeting lasted an hour and concluded with the team picking different areas of interest to work on:

  • Michelle and Chen will be looking into the Edit Preferences screens.
  • Gonzalo and Zhen will focus their attention on the Create a Site screens.
  • Nico will do his part by bringing everyone up to speed on development methods, working through various framework issues, and ultimately finishing up the Add Tools screens that were started in the hackathon.
  • Oliver was on the call to evaluate the project and consider lending a hand with PM support.
  • My job is to service these guys in any way I can, whether that's helping with PM or working through design changes as needed.

Things that should currently be underway and/or are next steps:

  • Michelle, Chen, Gonzalo, and Zhen are studying the screens and going over the dev documentation Nico has provided on confluence. Hopefully they're also setting up an environment and doing a bit of tinkering.
  • Nico is working on various framework issues and coordinating with others to align development processes. See below.
  • Oliver and I should probably chat sometime soon to discuss his plans.
  • I will be reaching out individually to each team member to schedule a time for us to review each screen in detail, much the same way Nico and I did earlier, and shape up some time estimates which will feed into a larger project schedule. Also, I'll be using those discussions to prioritize which screens I'll need to get crack'n on.

Nico has posted the following questions to the team:

Team: please use the confluence comments to reply, or send an email to Nico directly, or use the UX list.

  • Has everyone seen MyCamTools yet and the development approach it uses ? (JSON datafeeds on the backend, that are being used by a HTML/CSS/JavaScript front-end
  • How does everyone feel about this development approach?
  • How does everyone prefer to create datafeeds? (sdata, entitybroker, ...? )
  • How does everyone want to get started? (short technical meeting, find out themselves with me for consultancy, look at code first, which documentation is needed...)
  • How would folks like to team up? Who prefers doing front-end and who prefers doing back-end?
  • What is everyone's commitment to this project?

Areas that still need attention include:

  • We could also use volunteers who are interested and able to commit to PM'ng this project.

A few side notes:

  • This status update was sent to both the UX and Dev lists, but all future updates will only be sent to the UX list, so if you're interested, make sure you're on that list.
  • The team working on this project should use the UX list as the main communication channel. If the list gets too busy, we'll get our own list together - so please let us know if we become disruptive.
  • I will make every effort to post a weekly status update (likely toward the end of each week, but that may change).
Implementation Summary


Nicolaas Matthijs
Nathan Pearson

Screen review

*This review is best viewed when accompanied by the Storyboard Document

Results of an initial screen review of Nathan's UX Project screens in order to find out the workload and the scope of what goes into Sakai 2.6 from a UX point of view.

1. Main Screen Templates | TOTAL HOURS = ~209 (5.2 person weeks) 50

  • Design: ~31 hours 26 hours
  • Technical: ~178 hours ~24 hours
    (tick) Data Feed: 0 hours

2. Create a Site | TOTAL HOURS = ~72 (1.8 person weeks) ~65

  • Design: ~21 hours
  • Technical: ~40 hours
  • Data Feed: ~11 hours ~4 hours

3. Manage Site Settings | TOTAL HOURS = ~341 (8.5 person weeks)

  • Design: ~105 hours
  • Technical: ~174 hours
  • Data Feed: ~62 hours

(tick) 4. Edit Preferences | TOTAL HOURS = ~49 (1.2 person weeks) 0 hours

(tick) Design: ~3 hours
(tick) Technical: ~32 hours
(tick) Data Feed: ~14 hours

5. Personalize the Portal | TOTAL HOURS = ~109 (2.7 person weeks) 93 hours

  • Design: ~38 hours
  • Technical: ~71 hours 55 hours
    (tick) Data Feed: 0 hours

6. Add Tools | TOTAL HOURS = ~96 (2.4 person weeks) ~32 hours

  • Design: ~32 hours
    (tick) Technical: ~56 hours ~0 hours
    (tick) Data Feed: ~0 hours

7. Join & Edit Sites | TOTAL HOURS = ~293 (7.3 person weeks)

  • Design: ~89 hours
  • Technical: ~152 hours
  • Data Feed: ~52 hours

Implementation Commitments

CURRENT TOTALS: ~1169 Hours (30 person weeks) - Just about 2.5 months w/ 3 people

  • Design Total: ~319 hours
  • Technical Total: ~703 hours
  • Data Feed Total: ~147 hours
The UX Kit

Here's the UX Kit.
This week concludes the first two-month long project under the UX Improvement Initiative. The project will remain in "Pre-Closed" status for another two months for post-production support.

Topics covered this week include:

  • Created two gateway page templates with related variations showing authenticated vs. unauthenticated view of site gateway (see screens for clarification)
  • Completed the "Add Tools" UI
  • Made lots of small tweaks throughout!
  • Prepared an initial round of storyboard documentation

Download The UX Kit
  • The HTML Files!
    The is the complete set of HTML files that correspond to each of the screens presented in this design project. Download and enjoy!
  • Fireworks PNG Screen Files (Working Design Files)
    This is the complete set of screens in PNG Fireworks format with active layers. They can be viewed using most any image viewer (including browsers), but if you want to edit them, you'll need to use Adobe's Fireworks.
  • Storyboard Document
    This document provides a high-level introduction to the screen interactions. Detailed interactions can be found in the prior weeks video demonstrations. More documentation may be produced later as well.

Worked through the My Account area and cranking out visual design.

Topics covered in this design include:

  • Completed the My Account area (consolidated Account and Preferences)
  • Fleshed out remaining screens for Creating a Site via: Build New, Import, Template, or Copy existing.
  • Applied visual design to many of the screens (about 75-80% finished)
  • Finalized the visual queues and interaction structure around the Dashboard --> Site --> Tool relationship
  • Touched up a few subtle details

See how sites are managed using the Sites widget and tool.

Topics covered in this design include:

  • Searching for sites
  • Joining sites
  • Editing or managing "my sites"
  • Two alternative concepts for sites searching and joining
  • Understanding some fundamental interaction design patterns (hub model)
  • Seeing the relationship between The Site, Widgets, and Tools

To learn more, take a look at this week's flash presentation.

Companion screens below:

Not sure why the gallery function displays the images in a backwards order, but I numbered them in order of how they're presented in the video. Hope this helps.

First round of visual design.

No video this week guys (sorry). But I do have some juicy eye-candy.

From a visual design perspective, my goals were as follows:

1. Create a modern (web 2.0) look and feel.
2. Create a skin that's fairly easy to dissect and modify. In other words, the visual elements should be simple, but not so simple as to lose all personality.
3. Create a concept that takes a step forward in branding Sakai. As of today, Sakai lacks any visual ownership beyond its logo. What I tried to do is expand on the playful elements (strokes of the type and symbol, colors, etc.) while still retaining an enterprise application UI.

The initial stages of the visual design were actually formed during the interaction design work I had presented earlier. I added color, refined various elements, and introduced some conceptual messaging (meet the Sakai Owl).

Important: Please do not focus too much on the content in the widgets. While the content suggests a social network environment, it is only a concept and used purely to foster the visual design exercise.

Also, it's worth mentioning that this visual design is prepared primarily for default Sakai. Your campus will have the option to customize the style to meet your branding requirements.


Take a peak at how Sakai's new roles and permissions system works.

Topics covered in this design include:

  • A completely new and robust way of handling roles and permissions!
  • I added a dynamic hide/reveal option to the sidebar
  • Rearranged where colors, styles, and other customization features are located
  • Added a "styles" option that let's users pick between different pre-defined moods (layout not included)
  • Did some light tweaking throughout

To learn more, take a look at this week's flash presentation.

*Companion screens below:

*Screen revision updates are included in this batch so you'll want to hunt through and find the screens that relate only to the video presentation.

UX Project Feedback - Open Call

Several data points came out of the meeting:

A. The design should incorporate some ideation around a "Sandbox" site type as an option that lets instructors (and possibly other users) take Sakai for a test spin before committing to building a site of their own.

This is a good starting point, but it would be helpful to get specific use-cases around this idea.

B. There was a desire to see the design present more "real world" examples. There was some concern that the direction might not scale well when, for example 50+ sites or tools are added to a user's layout.

In general, there was a desire to see more detail. One request had to do with how tools might be ordered more elegantly so that once added to the layout, they would offer more options than just a first in first out ordering method.

Someone put the request for more details it in terms of seeing a before and after – like an "extreme makeover"! (smile)

My fumbling response to that was (sorry guys, I'm on practically no sleep at the moment due to exams) that the design is all broad strokes at the moment. I'm still dealing with the basic building blocks of this thing, so please be patient about the details. Believe me, I am just as anxious to dive into details and see how they fan out. So as soon as I get beyond a few more larger chunks of the product, I'll make it a point to come up with several mock-ups that show more real world examples and use-cases in action.

In part, that's the reason why we're talking implementation at the moment. We'd like to get a prototype track going where users can begin to interact with real data so we can see where the leaks are and be in a better position to address them.

C. There were comments that touched on what appears to be a recurring concern about the design offering too much!

Folks shared a bit of skepticism that the design is impractical in a real-world deployment where instructors or other users are NOT given access to build and manage sites in such a free-form way. Instead, the more common scenario is that instructors are given a site or two that are designed by someone else (like an instructional designer) and they often have little need (or ability) to dramatically modify it – much less build a site from scratch.

This point is well taken and certainly has not escaped my attention. There are two things I want to say about this issue:

1. We're not yet at a point where we're packing this thing up and driving it into the trunk. This design is just that, a design. More over, it's a design happening in real-time. You're seeing it emerge and in the process are privy to the toiling involved in the the trial and error. It's natural to be concerned that this is what the finished product will be, but let me assure you, it's far from it!

Before this project started, I thought quite extensively about how to approach the process. Either behind a curtain or out in the open. I opted for the latter as I think it better mirrors the spirit of this community. But that approach introduces confusion – so I apologize if I haven't managed the communications better.

I'll continue to emphasize this point as the process moves along.

Also, keep in mind, the reason I wanted to do it in the open was to make sure everyone who wants to have a say into the design will be given the chance to. So try not to feel skeptical, but rather look at it as a work in progress with your feedback playing a significant role!

2. I realize that the design presents MUCH functionality in the UX. There are several reasons I chose this route:

  • Not all institutions lock things down for their users.
  • Sakai does not necessarily (albeit it mostly is today) used only in the academic context. <-- This is not a principle driver, so don't get too hung up on this point.
  • It's easier to scale down than up. If I designed a limited solution, it would be much harder to envision something more robust for those that need it. It's easier to go the other way.

And on that last point, keep in mind that there will certainly be an admin side to all of this that should allow for extensive configurations! So much of what you see will be very much controlled from institution to institution by the system admin. Ideally, I'd like to see an admin control panel that is cleaned up to support ease of use and efficiency for the admin – but that often comes down to a trade-off in priorities (wink)

D. There was a question about Fluid and involving their efforts.

Yes, I agree. This has been one of the main goals from the outset of this project. Once they get some more time, I'm confident we'll be collaborating much more.

E. And finally, a few folks had questions about Paris and any workshops there that could be offered around this project.

Unfortunately, my phone or my ears seem to be going (probably a combination of both) and I missed much of what was said, but John Norman mentioned something about preparing an event either during or after – as well as something during the JASIG conference. But again, I didn't fully catch everything so if someone can add those details here, I'd appreciate it.

Personally, my only plans for Paris are to discuss the UX Improvement Initiative and give a brief showing of progress being done. The format will be a 1 hour presentation. I'd prepare more of a brainstorming and planning workshop, but unfortunately, I just won't have the time this go-around.

Take a look this week at how the basic template idea is shaping up as well as how users can add widgets to their site.

Topics covered in this design include:

  • Changes to the copy site screen
  • Exploring templates a bit further
  • Adding, viewing, and removing widgets
  • Modifying the page layout

To learn more, take a look at this week's flash presentation.

Companion screens below:

Creating a Site & More!

Here's the first rendition of the "Creating a New Site" flow. Also, I cover the Site Settings area and propose a few new ideas!

Topics covered in this design include:

  • Create a site flow
  • Proposed template concept
  • A wizard-esque widget called the Site Assistant that helps new users create their sites
  • General site settings which allows site owners to change colors, add a logo, etc.
  • Exploring how and where the user's profile should fit into a site
  • How a site might present its members in the site settings area – possibly only available to site owners.
  • Briefly discuss my plans for a robust permissions system
  • A feature rich site data import/export feature
  • And last but not least, a way for site owners to copy an existing site while doing a little site management

To learn more, take a look at this week's flash presentation.

Also, don't forget to checkout the companion screens as you watch the video.


Brain dump

General brainstorming... don't read too into it.

As per recommendations made during this project's kick-off meeting, here's a few highlights (comments I heard and paraphrased here) from my interviews with folks in the community:

  • Sakai lacks cohesion as a product. Not only are tools different in their interactions and other design patterns, but the product on the whole lacks a clear metaphor that guides the user's understand of how to best start and use it.
  • Some folks recommended a start-up guide or wizard to get user's going. Also, video walk-throughs were discussed.
  • Many people commented on Sakai being too "tool oriented" and that users need to hunt for obscure functionality across a myriad of tools to complete basic tasks. Very frustrating!
  • While there's talk of a so called "flexible framework" (referring to Sakai being more than just a LMS/CMS – but a CLE, Portfolio, anything really!), in truth it's not. It's very difficult to make any modifications and the out-of-the-box offering is too cumbersome for those that just want to get up and running.
  • Sakai analogy: A camel is horse designed by committee.
  • Sakai is passe in its thinking. It lacks not only the Web 2.0 bells and whistles, but the "spirit" of Web 2.0. It's does a very basic and fairly out-dated thing.. and not that well.
  • Tools that are important include: Resources, Gradebook, Announcements
  • Saving state vs not-saving state?? Contentious issue!
  • Consistency is still a big problem.

My summary: Overall, I heard lots of frustrations relating to nuanced issues within tools as well as issues when user tasks span multiple tools. Inconsistency was high on the list of complaints, but my sense is that if "good design" principles were applied to each tool, consistency would be less of an issue. In other words, consistency is a symptom of a broader problem – poor design. For example, the Wiki tool is designed quite well, and folks generally like it. Yet, it's quite inconsistent from other tools.

As for why the first project revolves around the portal (or CLE as I'm calling it – to which I'm referring to all things that are non-tools)? Simple: Before getting lost in details of any one tool, thinking about Sakai from a high-level will help set the stage for filling in the details later. That's why I agree with the original project goals which centered on the site setup. That's a good place to start since to setup a site, one must fist envision a site. That process touches so much of Sakai that I can't think of a better place to start.

Laying the groundwork

This week was spent laying the groundwork for the CLE. The design work covers:

  • Dashboard views vs. site home page views
  • Re-thinking how users navigate sites
  • Re-thinking how users access tools
  • Putting more thinking and detail into widgets (synoptic tool)
  • Setting the stage for more efficient and robust preferences, permissions, and other configurations
  • Getting jiggy with Web 2.0
  • And a few other goodies...

To learn more, take a look at this week's flash presentation.

Also, you may want to download these screens as they'll be the focus of the presentation:

Note: All designs are for "presentation only"! Any icons, photos, or other copyrighted materials used were done so for purposes of mock-up and will not be used in the final designs. Also, keep in mind that these designs are wire frames (rough sketches) and colors, style, etc. were intentionally omitted.


Kick-off meeting agenda

For those of you who plan to call in, here's the agenda:

DURATION: 1 HOUR (more if necessary)

Say hello to the team.

Project Summary
I'll go over the scope of the project along with the project goals.

Review Schedule & Deliverables
I'll cover the design schedule and design deliverables. If anyone wants to chime in a discuss development or other items, feel free.

Discuss Roles & Expectations
I'm hoping this will be the meatier part of the discussion. I'd like to know where everyone sees themselves fitting in so we can get our expectations aligned.

General Q&A
If necessary, I'll answer any last minute questions you might have.

I'd like everyone who showed an interest in this project to attend as I think it will be a nice way for us to get to know one another. But if you can't make it, please RSVP me to let me know. Thanks!


This project is planned to start on: Monday, March 17, 2008

I've scheduled a kick-off meeting for team members at 9:30 AM MST.

To dial-in, use Sakai001:

IP Address:
Telephone: 812-856-7060
Conference Code: 348
PIN: 72524

Not a team member yet? No problem! Drop me a line and let's talk.

For more information on the types of folks this project needs, take a look at the Thinking about getting involved? section of the UX Initiative Summary.

Also, take a look at the Project Profile to learn more about this project. And if you have any questions, just drop me a note.


This page contains macros or features from a plugin which requires a valid license.

You will need to contact your administrator.

Project Status: Pre-Close (Support)
Design Assets
Project Plan
  • No labels


  1. I love the design, below some questions, some comments about possible gaps, uncertainty about scope/intentions.

    1. Main Screen Templates

    1. Gateway Dashboard Screen
    2-3. Assumes a) notion of internal membership, b) ability to create internal membership?
    4-5. Assumes Sakai internal login (not CAS, etc, or mixed modes).

    2. Dashboard Screen
    5. Widget list - categorization? How will a real list work?
    6. Sites - How will a real list work?

    3. Site Home Page Screen
    4. Site title bar - some sites titles cannot be customized under some circumstances/in some contexts
    5-6-7. Sidebar? is this like a view/perspective?

    4. Tool Screen (Ex: Site Settings)
    What is the purpose of the site id? Is this an editable field?

    6. Widget
    State? What does minimize/close/move mean? For page view? For session? Forever?

    2. Create a Site

    2. Create a Site: Non-Course
    Assumes course/not course site type distinction as only possibility
    Assumes editable site title in all cases?
    Missing some metadata

    3. Create a Site: Course
    Assumes non-provisioned course setup? No terms, etc.
    Assumes editable title, etc.

    3. Manage Site Settings

    1. Site Home Page
    Note: Am on a site now, looks like the dashboard - site and dashboard need to be able to be adequately visually distinguished.
    Sites have multiple owners, design assumes not

    3. Site Settings - Members
    Select All, Select All Visible are not the most common use cases. Other actions, other selection filters have a higher priority.

    4. Site Settings - Members - Add Members
    "For now, we will ask for user email addresses only, as this is most likely" - is this true?

    5. Site Settings - Roles & Permissions - Modify Permissions
    Aggregate idea may be overwhelming. Most people accept the defaults of each tool and leave it at that - at most will modify one tool. Leaving it in the tool makes better sense? I really like the design of the permissions grid.

    6. Site Settings - Import/Export
    New sites can import content from old sites when being created- where is that functionality?
    Functionality missing (tools, page order, groups, duplication, import from sites) or moved someplace else?

    4. Edit Preferences

    2. Account Details
    Assumes editable fields for institutional data, assumes internal login

    4. Edit Look & Feel - Upload Logo
    Assumes that all site types can have own logos, assumes that sites can do without titles

    5. Edit Look & Feel - Styles & Colors
    Assumes that all sites can be changed in this manner (style, color scheme) - whereas it may be only certain types of sites only or none at all depending on the institutional context.

    5. Add Tools
    Some tools need configuration when added - where is that?
    Some institutional contexts will disallow tool list editing, or rearranging?

    1. Hi Gonzalo,

      Great questions. Some things we have answers to, but haven't documented yet. Others are being discovered as we analyze the screens in more detail.

      With the risk of losing documentation around the issues you've brought up (though I hope we don't), I'd like to suggest we get together in a call (possibly with the other UXI resources) to discuss each point in more detail.

      I think that way we can comb through what has an answer and what needs one.