Improving the CLE v1.0

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:

• Main Screen Templates (more or less)
• Manage Site Settings
• Personalize the Portal
• Join & Edit Sites

• 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).

People

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) ~84

• Design: ~31 hours
• Technical: ~178 hours ~58 hours
• 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

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

• Design: ~3 hours
• Technical: ~32 hours
• Data Feed: ~14 hours

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

• Design: ~38 hours
• Technical: ~71 hours
• Data Feed: 0 hours

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

• Design: ~32 hours
• Technical: ~56 hours ~32 hours
• Data Feed: ~8 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

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

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.

10	9	8
7	6	5
4	3	2
1

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.

Enjoy!

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"!

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

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:

Change Layout wo/ Sidebar	Change Layout w/ Sidebar	Widget Added
Add Widget to Page	Add Widget - Alt View	Predefined Templates
My Templates (conceptual)	My Templates	Copy Site (modified)

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.

Enjoy!

Dashboard (Start Here)	Create a Site - Course Confirmation	Create a Site - Course Form
Create a Site - Non-Course Form	Create a Site - Sneak Peak at Templates	Create a Site - Select an Option
Site Settings - Copy Sites 3 (Error Message)	Site Settings - Copy Sites 2	Site Settings - General
Site Settings - My Profile	Joe's New Site - Site Assistant update	Joe's New Site - Using the Site Assistant
Joe's New Site	Site Settings - Copy Sites 1	Site Settings - Import/Export
Site Settings - Success Message	Site Settings - Add a Member	Site Settings - Members Tab

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

Object Model	Layout Schema	Layout Rules
Componants Overview	Widget Schema

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.

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:

Dashboard	Site Home Page

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.