UX Improvement Project

The UX Improvement Project

Early in 2007 the Sakai Foundation began work on the UX Lead Initiative. This initiative was put on hold pending the hiring of a new Executive Director (me: Michael Korcuska). The goals of the UX Lead Initiative project remain critically important to Sakai and Michael's recommendation, which has been approved by the Sakai Foundation Board, is to re-frame this as a project that would last approximately six months. At that point, we would determine whether to continue with a second phase of the project or, perhaps, return to the original idea of a full-time position at the Foundation.

I first want to thank those institutions that pledged support for the UX Lead Initiative:

• The rSmart Group
• University of Cambridge
• Yale University
• Johns Hopkins University
• Indiana University
• Charles Sturt University

We are hoping, of course, that these institutions will keep their pledges in place and provide support for this project. In addition, we are hopeful that others in the community can make financial contributions to the effort. Regardless of these contributions, the UX Improvement Project will being going forward (assuming we can get development resources form the community--See "The Process" below). Additional funding will be used to increase and/or accelerate the work. If you would like to contribute to this project please contact Michael or Mary.

The initial thoughts about the goals of the project and the initial scope of work are described below, but we are eager for community input. Please add your comments to this page or send email to Michael.

Project Goals

The goals for the project are as follows:

1. Can be completed in approximately 6 months
2. Will improve the user experience in Sakai, especially for novice/first-time users
3. Provides an opportunity for us to evaluate quality of the UX lead as a potential full-time staff member
4. Interacts with the Fluid project in a meaningful way
5. Creates usable standards for other teams/projects
6. Has UX working closely with software developers

The deliverables would be:

• Re-designed UI and re-developed code, checked into trunk and ready for the "next" release (ideally 2.6, but being flexible about this).
• Optionally, and budget permitting, behavioral models and wire frames for a second phase.
• Documentation and recommendation for UI standards to be applied to other areas of Sakai. This wouldn't be "official" at this point but would go to the UX working group for comments and hopefully build momentum as standard recommendations for tools.

Project Ideas

In my discussions with community members and board members about a project like this, two potential projects surfaced:

1. Site setup and editing. I think everyone agrees that many aspects of this are confusing or, at the very least, could be improved substantially.
2. The initial landing page or "home page" when you first log into Sakai. Many people feel that it is difficult for some users to make sense of what they are looking at.

After starting with item 1, I now prefer item 2 because (a) it really is the "first impression" and (b) the technical feasibility is much greater, especially given the time frame and likely available resources. A set of email exchanges I had with the board are summarized below--they outline the reasons for my shift in thinking. They also end with a comment that would favor item 2.

But please suggest other ideas. We ultimately want to meet the goals--the specific project is not that critical.

The Process

The Sakai Foundation Board has authorized up to $50,000 to support this project. The Sakai Foundation will only be supporting part of the project--the remainder of the staff and other resources will be provided by contributing organizations. Ideally, two contributing organizations will come together to provide development resources to work with the UX lead. This will encourage joint ownership of the resulting code. Without the contribution of additional resources dedicated to implementing the UX changes, this project cannot go forward. The funding is not sufficient to complete all of the work. More importantly, it is critical for this effort to be re-enforcing the community source model and that means significant contribution from community members.

The initial thinking is that the bulk of the funds would be used to hire an external UX expert to lead the redesign effort, although if a contributing institution had a suitable UX expert on staff it could be used, instead, to fund software development. Travel and other expenses would also be covered.

If your organization is interested in working on this project or if you know a suitable candidate for the UX lead position, please contact Michael as soon as possible. We would like to identify the UX lead by the end of October and kick off this project in November.

Summarized Email Exchange

Michael's initial email (Sept. 1)

I've been thinking a lot about the UX position. I think the
position description and the goals are excellent. I'm hesitant,
though, to create a full-time, permanent position at a time when I'm
still working on the budget and we have many other priorities as well
(e.g. QA needs more resources, scalability/reliability is becoming
increasingly critical, localization could be improved...). If we had twice
as much money it would be an easy decision. But we don't. I'm
currently thinking that this should be a consulting project, with a
duration of 6 months and a possible extension and/or permanent
position resulting from the success of the effort.

One idea I have floated in my conversations, which has gotten
positive reaction, is a project to redesign Site Setup/Site Info.
This would include a ground-up UX redesign and code rewrite (or
refactoring). The current code is not easy to work with (12,000 lines
in a single file with dozens of case statements) and developers are
simply afraid to touch it. The added benefit, from my perspective, is
that it addresses the perception of ease of use as well as the
reality. The first thing user/instructor will do once Sakai is up and
running is to try to set up a new site for their course. If that's
difficult/confusing they may never go further.

The deliverables would be not just code but a set of UX standards and
templates that would hopefully be picked up by the community. The SF
would not necessarily fund all of this but would provide the funding
for the UX lead and look to the community to provide developers and
other assistance. The second phase would be for the UX person to take
these around to various project teams and help them implement and
extend the standards.

I would like to get your input on this (the specific idea and the UX
position generally) ASAP so I can formulate a recommendation in time
for the board meeting on September 12th. I'd like to begin taking
action on this in September and perhaps invite top candidates to be
interviewed at EDUCAUSE.

Clay's Response (Chris also added his support to this reframing of the idea):

As far as the Site Info idea as a UX project, I'd have strong doubts
about doing the site-manage refactoring work within the 6-month period
you've indicated. In the first place because this isn't work that a
UX consultant would do - so who would? And in the second place
because it would be such a big project. SiteAction.java alone is such
a beast, and it touches on so much (everything from the construction
of the Home page to the CM API), that I would guess it would be a
major undertaking. Don't get me wrong - valuable work indeed, and
long overdue - but perhaps not something that should supplement a
short-term UX initiative. Some assessment of the LOE from a couple of
our technical leads might inform the proposal.

To the extent that we're targeting people's first reactions, I think
it might be better to start backwards a step even from site creation.
We've been dealing with a lot of training in recent months, of course,
and it's been clear that people have a hard time understanding what
they're looking at upon first logging in. They don't realize that the
"tabs" along the top refer to distinct spaces, each with its own set
of "tools" in a lefthand menu. Along similar lines, it takes some
time before they appreciate the distinction between their My Workspace
and all the other sites (even after they grasp the idea of distinct
sites), and how it's both kind of a site like all the others, and at
the same time rather different. Then there are other questions about
how some tasks are carried out in the My Workspace when they should
really be globally available (e.g. preferences).

A redesign in this area would fall more completely within the domain
of a UX expert, the technical work would be focused on the portal
rather than an intersecting tangle of business logic, it might be a
better fit for a 6-month timeframe, and it would attack people's first
reactions even more immediately.

Added to which, the Fluid project is already doing some work in this
area (the "more" dropdown), which could encourage immediate working
relationships with leaders in our UX community, and perhaps cast into
greater relief this candidate's ability (to the extent that they are a
candidate for a permanent position) to coordinate with the work of
other UX people rather than merely produce something on their own
steam.

~Clay

John Norman's addition:

This (making the 'site' concept intuitive) is one of our top 5 concerns. It is not apparent enough to users what they are engaging with when they get to Sakai. I have been exploring with our developers the question "why do we need a portal at all?" Users need to find their sites - this could be through a 'Contents' page. For those with many sites, an index or even search would be useful. In order to be able to tell you which sites you belong to (and perhaps how you came to belong to them), we would need the user to identify themselves (login). What else is the portal doing? If we refocus attention on site membership at the landing page, it may become more apparent that Sakai is a collection of websites each with different purposes.

I might be tempted to expand Clay's project beyond this redesign of portal (I don't think Fluid is thinking at a fundamental enough level yet) to include possible site setup and maintenance behavioural models and wireframes, but I would start with a home page that makes my workspace and course/project sites much clearer. I would contribute effort to refactoring the backend code if I was confident that it would support a more intuitive presentation of the homepage.

My thinking here is very half baked, but I think our current models reveal too much of the underlying technology and are not intuitive enough. Resetting our developer-driven thinking in this area would be an immensely valuable contribution.

John

Michael's reply:

Smaller is better, in my view. Although I was hoping to both fix a
troublesome piece of code and get some UX work done at the same time,
I don't want to boil the ocean. My understanding of the Sakai code
base is not sufficient to estimate the site setup/management project.

The project Clay describes meets my goals for this proposal, which
I'll articulate a bit more clearly now:

1. Can be completed in 6 months
2. Will improve the user experience in Sakai, especially for novice/first-time users
3. Allows us to evaluate quality of the UX candidate
4. Interacts with the Fluid project in a meaningful way
5. Creates usable standards for other teams/projects

It sounds like original proposal doesn't meet at least goal #1 (although it also sounds like somebody should tackle SiteAction.java someday soon).

Thanks,

Michael

Chris' email:

One thing I'd like to see in the list of criteria you articulated Michael is interaction with a development project team. It might be baked into your #5 below, but I'd call it out. We've been able to make some superficial improvements without a lot of developer/designer interaction but the majority of the stuff we need to do will require a lot of good designer/developer interaction. So, in addition to repeatable standards, we should want to see a repeatable and scalable methodology employed in the work.

Chris

Mara's comments:

All – Just some further thoughts on the UX/home page conversation.

I went and talked to our Training and Support lead, Karen Miles, about the pain that John and Clay have expressed regarding the home page or site concept. After two + years of working closely with our faculty on using Sakai she finds that this isn't much of an issue. The biggest issue for them is separating the concepts of user management from site management. This is something that Marc Brierly and Daphne Ogle did a preliminary design for but Stanford and Berkeley didn't have a) adequate time to implement, and b) the job re-architecting site set-up was too critical to not have more central oversight.

Karen's comments:

For us, the more fundamental concern is around site creation and maintenance. People seem to get through the steps of creating a site without much difficulty, but we've done quite a bit of local customization to make that easier. The big headache now seems to manifest in the concept that maintaining my site and all of the tools in it is different than maintaining my users. I just keep going back to the work that Daphne and Marc did to mockup breaking those workflows apart and how that would alleviate some of the pain our users are feeling.

This makes me question the concept of attacking the UX problem as a "quick win." Speaking for myself and my own teams output, it seems that sometimes quick wins, while absolutely necessary at times to get a production system out the door, don't always help us get closer to solving some of the critical underlying problems. For example, group mgmt. vs. Section and group Mgmt. tools.

I am not sure I fully understand the home page problem (or I have heard John refer to it as the Portal paradigm), but what I imagine could be just a new view of existing content OR it could be an entirely new paradigm for the application (how much of Sakai is built on the portal model?). Very different projects in scope. One probably more controversial than the other.

It seems to me that we can't assume that what jumps out to us at our schools will be the thing to work on. I would like to allow the UX lead and Michael to determine the best place to put these efforts via talking with more schools, reviewing the results from the Fluid UX walkthroughs, and talking with more user facing staff combined with the constraints of people, time, $ to guide this effort. Personally, at this point I would rather get a make-over in 8-10 months than get a facial in 6 months. We are changing things on our users so quickly now that radical change every six months makes for massive hand-holding and deep breathing exercises...

Mara