News from August, 2008

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) 50

• Design: ~31 hours 26 hours
• Technical: ~178 hours ~24 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) 0 hours

Design: ~3 hours
Technical: ~32 hours
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
  Data Feed: 0 hours

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

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

General

I've played with the demo that Noah set up for me and have taken screenshots w/notes. Some of the notes are for personal use, others are questions to the group.

Please review the notes and make comments on this page.

To refer to a note, please reference the image name and the note number. So for image 2.png, note 3, the format should be: "2.3"

Additional questions

1. What is the reason to allow student to users pick a template?
2. What is the reason to allow student users to select a form within a template?
3. Can forms be edited directly from the view screen?
4. Can forms be switched once content exists?
5. Can a different form be selected from the view screen?

Screenshots w/ notes

The thumbnails are out of order, please refer to the numbers for proper sequence.

3a	4	3
2	1	7
6	5

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

As the 2.6 code freeze approaches, it's a good time to do a gut-check and reflect on where we are and where we're heading from a UX, and in general, a product perspective.

For those of you who don't subscribe to the lists, you might have missed the first UX improvement design project that took place earlier this year. The project's goals were to re-design Sakai to be more web 2.0 friendly with a widget based UI that brings richness, flexibility, and dare I say it... "personality" to the user's experience.

In addition to these lofty changes, the effort was aimed at making it easier (and arguably better) for end users to find and join sites, create a site of their own, and manage their sites.

As is often the case with design, some of these goals were fairly well defined upfront, while others emerged through the creative nature of the process. In the end, our community gained 32 new HTML screens that covered all of the above, and hinted at more.

Alongside this effort was a groundswell of ideation around Sakai 3.0, which promises to make our product the next big thing in academic open-source technology - assuming we can pull it off!

The only thing that stands in our way is us. The challenges we face in working together as an efficient, well coordinated team are not in the least bit trivial. But silver is beginning to line our historic clouds.

Last week, an open meeting took place to discuss how and what we plan to do with the 32 HTML screens produced from the UX improvement project. While the meeting itself had its fair share of confusion, a few brave souls stepped in to commit resources aimed at implementing the screens. Bravo!

Others soon joined in the leap-of-faith, and now, while still understaffed, a small team has come together to tackle this work.

In the meanwhile, progress is being made as the Authoring Summit gets underway, K2 is picking up momentum, and a Sakai roadmap is working hard to get off the ground. At the same time, there's plenty of discussion being had around team building and organizational issues that are key to the herculean effort required for 3.0. All very positive signs!

What's needed now is simply to connect a few UX dots.

So far, the UX screens produced this year have oddly been labeled as 2.6 designs. Given the gravity of the 3.0 vision, as loose as it might be, the knock-on effects (burrowing one of John's lines) of mislabeling the screens has lead some key community contributors, who have an eye on 3.0, to view them as already passé.

This misunderstanding has unfortunately already lead to certain inefficiencies.

To help correct any misunderstandings, I'd like to be clear that these screens were designed with Sakai in mind, not 2.6, 3.0, or any other specific release. The challenges that these designs address are both universal (ex: administration of stuff) and fundamental to Sakai (ex: building, managing, and joining sites).

No matter where we go from here, these issues will remain relatively constant. We'll always need sites and a way to create them. Having a personal dashboard doesn't seem to be going away anytime soon either.

So despite concerns that these screens are passé, imperfect, incomplete, or what have you, the fact remains that they do solve the design issues they intended to solve in a reasonably elegant way. We now have a good solid frame for where the meatier 3.0 stuff can live. In fact, my plan for designing 3.0 is to work within the body of these screens.

Here's a crude but hopefully helpful example to illustrate my point.

So the question is not about whether your institution plans on using 2.6, but rather how efficiently we can produce 3.0? In other words, do we want to be faced with implementing these screens next year, along with all the additional 3.0 screens, or can we stay ahead of the curve by implementing these screens now and avoid worrying about them once the additional 3.0 screens come about?

That's the first dot: These screens lay the UX foundation for 3.0.

The second dot is freeing me up to focus on content authoring and social networking - which requires more resources lending a hand in implementing the UX screens. Currently we need more JS programmers, a committed project manager, and some minor design support.

Assuming that happens, there's still quite a lot of work to be done! From a UX perspective, the heart of 3.0 consists of three large parts:

• A new content authoring paradigm (major mental shift in how we perceive content creation, ownership, and sharing - as well as how existing Sakai functionality is migrated to those contexts).
• A light authoring solution (something needed in the short term - imagine a wysiwyg widget with some ability to pull from tools like Resources.)
• Social networking (a basic framework for ad-hoc user/group interaction that weaves into the content authoring paradigm).

Tangentially, there will likely be a need to re-evaluate the nature of the current Resource tool. Should it continue to be what it is?

The third dot is to understand where OSP fits into 3.0 and Sakai's future in general.

At present, I'm working with the OSP folks to make some 2.6 UX enhancements. While the changes will be relatively minor for this release, they'll hopefully smooth a few sharp corners. More importantly, investing time now will help the OSP folks and me to identify parallels between OSP and the 3.0 vision. From what I can already tell, the parallels are huge!

The last and final dot is all of the other great work being done to change the underpinnings of Sakai to better support the functional parts of the 3.0 vision. Of course I'm referring to K2, but also consider the work that Oxford is doing with hierarchies, the work Cambridge has done with widgets and dashboards, and the various other odds and ends.

So where does this leave us... what's next?

Well for me, the plan is to focus on the following areas over the next few months:

• Keep the ball rolling with implementing the UX screens produced earlier this year. I firmly believe this to be a crucial step in setting the stage for 3.0. Plus, getting beyond this point will results in lots of serendipitous efficiency across the community - I'm confident of that.
• Getting seeped into OSP to help with short-term needs, but more importantly, to plan for bridging long-term 3.0 related goals - which is already a top priority for some of the leaders of that project.
• Working with Jim Eng and other community leaders to foster the content authoring movement which is at the crux of the 3.0 vision. Look for contributions from me on the project planning page as well as the UX planning page (and hopefully, at the Authoring Summit).
• Carving out time to plan for, and do a little sketching around, social networking. I'm playing this one by ear at the moment until some of the other parts I mentioned start seeing some movement.

With a little luck, and your participation, all of this might just come together. No doubt, this is an exciting time for Sakai!

So those are my plans... what are yours?

Hereweek1_screens.zip's a quick an dirty clean-up job to the basic flow for adding (building) a portfolio using templates.

As discussed, for now, I've toggles the "design your own portfolio" option. For now, the user is just presented with templates. However, the other option can easily be added into the UI. But I recommend you guys add a config script to toggle this.

Summary

• Removed items that distracted the user from the task at hand (see 1. Before and 1. After)
• Hid the "design your own portfolio" option
• Simplified/humanized the language. Stopped using words like "template" or "forms"
• Added helpful but concise descriptions
• Recommended a step by step title indicator that does not break
• Re-arranged the order in which some screens appear (see 3. Before and 4. Before)
• Reduced the title, name, display name, presentation name chaos! I highly recommend you guys simplify this. One name is plenty. Let the user pick one name, and force the system to pick up the slack of unique identifiers or key field names. That stuff should all be invisible to the end user.
• Reworked the "add items to your portfolio" screen. Now it is simpler and more scalable. If you look closely at 5a. After, you will that I have also suggested an option to <Add New> content that would deep link to a Wizard or a Matrix – or call up a FCKEditor directly. No need to first create content, then make a portfolio – just link them off and loop them back.
• Implied the ability to add more than one form "item" to each portfolio template (See 5c. After).
• Sharing is still incomplete, but will be drastically easier to understand and manage once done (see 7. After). Once a user selects the "Shared" radio, a DIV will slide open to reveal a simplified sharing UI.

*The screens are just a rough draft to facilitate discussion. There's much work to be done.. so please don't worry that these are the "new designs". They're recommendations for better usability. We can talk more and massage them into the screens you want if you don't like these."

I've numbered the screens in sequence. So just start with 1_before.png, then view 1_after.png, and so on.

Enjoy!

Zip archive of all screens (Week 1) Click Here to Download

Week 1 Thumbnails
1. After	1. Before	2. After	2. Before
3. After	3. Before	4. After	4. Before
5. After	5. Before	5a. After	5b. After
5c. After	6	7. After	7. Before

This week I've updated the screens per the feedback I received from the group. I've made a few relatively dramatic changes since last week, but I believe they're for the better. Plus, they speak to all the issues (at least those I recall) that everyone raised about the last screens.

I'm not going to summarize the scope of the design, other than to describe how to organize the sequence of the screens.

My numerating system works as follows:

1, 2, 3, 4 – Each number represents a "unique" screen template presented in a sequential order based on a user's flow

1, 2, 2a, 2b, 3 – The a, b, c... n denotation implies a change in a screen's state. So 2a and 2b are the same screen, but something changed. The change is most often sequential based on the letter (but not always, so follow the flows below for best results).

4b.1 – Screens with these notations imply an "alternative" screen. In other words, if you compare 4b and 4b.1, they fall in the same sequence, but 4b.1 is an alternate to 4b for some reason or another.

Sequence Guide (follow these steps)

Flow 1 - User Adds Content

1, (1.1 - if some portfolios already exist), 2, 3, 4, 4a, 4b, (4b.1 - if there is no content available for this section), 4c, (4c.1 - shows a multi-select alternative), 4d. If there are questions about what happens on 4d, I will answer them either here or on a call.

Flow 2 - User Edits General Settings

1, 2, 3, 5, 5a

Flow 3 - User Shares Portfolio

1, 2, 3, 6, 6a, 6b, 6c, back to -> 3a

Notes

• Notice that now there is no longer a step by step status indicator. The wizard has been re-arranged into a hub model, which upon further analysis, seems to be the better approach to this data model.
• I still haven't included "commenting" and "expiration" into these screens. Those options will probably appear in screen 6. I'm just not comfortable with how much information is on this screen already. If we can lose the "share by role" feature, it would make life a lot easier

Zip archive of all screens (Week 2) Click Here to Download

Week 2 Thumbnails
1.1	1	2	3
3a	4	4a	4b.1
4b	4c.1	4c	4d
5	5a	6	6a
6b	6c

After thinking over the screens I posted earlier, I realized there were a few things I just wasn't thrilled about. So, I took another swag at it.

Summary

• What you'll find in these screens is that the broad structures have changed, but the detailed interactions (ex: adding content) have not
• The start screen with the 3 boxes has been replaced with more of a dashboard looking screen
• There are tabs now that allow the user to navigate between the dashboard, the build/edit mode, and the preview
• The portfolio list view is a lot cleaner now, IMO
• This approach also brings the design closer to the new Sakai 3.x direction

Enjoy!

Zip archive of all screens (Week 2.1) Click Here to Download

Week 2.1 Thumbnails
1.1	1	2	3
3a	3b	4	5
6