Blog

Blog

3akai wireframes








More UX Screens
3akai UX Design Review

Status Review

1. Main Sakai gateway page

  • Are we going to use the UXI version, or do we need to come up with a more engaging & open version?

2. People

  • Need a search + search result
  • Will require a user profile screen (see #22).
  • I assume we're dropping ad-hoc groups for now?

3. Course & Sites

  • Need a search + search result
  • How will metadata and tags be used?
  • Is this just one screen? Are we going to use the slide-down utility window?
  • Still need the create a site workflow
  • What about site templates?

4. Search

  • Is this needed here?
  • What is the expectation for this?

5. Me

6. My Sakai

  • Will probably re-use UXI screens for this. Will re-style them with visual design.

7. Message system

  • Need inbox
  • Need outbox (or sent box)
  • Need compose UI (in multiple contexts)
  • Need trash
  • Just the barebones stuff!
  • Need to think through email notifications that notify of new messages (plus, preferences to manage alerts)

8. My connections

  • Need a screen to display users
  • Need a delete or disconnect screen
  • Need to view "connection requests" + approval/denial flow (including email notifications)

9. My Profile

  • How robust is this? Will people be able to comment on "my profile" page?

10. Preferences

  • Same as UXI or will we be doing more?

11. Site Search

  • Will we have an autocomplete feature? Will icons be included?
  • Need a search results page w/ all the trimmings

12. Edit Page

  • Mostly done... but still need to discuss WYSIWYG bar + vignette/widget browser (assuming we have one for this release)

13. Share

  • Does this replace permissions (i.e. allow user to hide page from others) or is this something else?

14. Print page

  • Just the body of the page?

15. Revision history

  • How many screens... 1... 2...??

16. About

  • Lets keep this light for now. We can show the page's URL, some metadata about who/when the page was created. And maybe list outbound & inbound links + all links to non-page content.

17. Copyrights

  • Need edit and view screens.

18. Move

  • Need drag and drop UI – probably a lightbox.

19. Copy

  • Might be the same lightbox as move, but maybe not.

20. Delete

  • Need delete confirmation.
  • What happens to people who are sharing the page? Do they get notified? Can the delete be undone? What happens to content that was added to the system only for this page – does it remain in the system or does the user get prompted to delete that too?

21. View page changes

  • Related to the page revision history.
  • Implies a general vs. detailed view in page revision area.

22. User profile page

  • (see #9)
  • How robust is this?

23. Blank page

  • Pretty much complete

24. Page templates

  • Are there any we absolutely can't live without for this release?

25. Dashboard page

  • Will re-use UXI screen, but will adopt slightly new visual treatment.

26. Site Tool

  • Will clean up the UXI tool selector screen.

27. Site Navigation widget

  • Need to tighten the bolts down on this, but it's mostly complete.

28. Sitemap

  • Will need a screen for this. Will probably look similar to the "move" screen. Perhaps will even incorporate some of that functionality for admins.

29. Recent Activity widget

  • Seems fairly straight forward.
  • Will it include page changes only, or changes to any content?

30. Edit Sidebar

  • Will probably be related to #34.
  • Need screens to select different sidebar widgets
  • Need main screen to allow drag and drop re-positioning of sidebar widgets
  • It is possible to integrate these type of controls directly inline in the main site view.

31. Site settings

  • Have we resolved the site owner/maintainer issue?
  • What about publishing... have we agreed on the model?

32. Members

  • Would be nice to go with the new screens.
  • Peter suggested an import CSV/Excel list. Might be a nice enhancement.

33. Groups

  • Probably going to omit this?

34. Appearance

  • Change logo
  • Switch location of sidebar
  • Change colors? This might be a bit much... the process of selecting a range of options and color harmonizing them maybe not be worth it for now. I'll talk with our visual designer.
3akai UX Project Overview

Useful Information

This is a working document, so expect more detail to be added as needed. Please DO NOT ask me to make changes to it – just make the change yourself. If necessary, I'll revert to a previous version.

Start Here

If you haven't looked at the 3akai demo site, please review it now. The URL is:

http://3akai.sakaiproject.org/

You can create an account and login on your own.

Project Summary

In early 2008 I embarked on a project aimed at improving the user's experience with the 2.x Sakai platform. While the project was well received, a new product vision that dwarfs the limited 2.x LMS model has taken center stage in our community. This new vision not only promises LMS capabilities, but seeks to enhance the product experience with rich and intuitive web page creation features, thoughtfully designed work-flows across different modalities and tasks within the system, easy and rewarding connectivity with other Sakai users, and better control and production of documents, materials, and other academic content.

No doubt this is a tall order! But the embryonic groundwork for these enhancements has already been laid!

What's needed now is a quick, solid, tactical UX strike. We'll have very little time for execution, and even less time for planning (although there will be planning). This project is ideal for people who can self-motivate, roll-up their sleeves, push their ideas, work collaboratively as a team and not get bogged down by lack of formal process.

This project will have two basic teams:

1. UX designers who will produce wire-frames, visual design treatments, and supporting documentation.
2. Developers who will implement the designs, offer suggestions, point out constraints, and clean up functional as well as aesthetic bugs.

While much of the design work remains to be done, we already have a good starting point with the current demo site. We'll evaluate the demo site, along with any relevant new ideas, and work together as a team to arrive at final design solution that is timely, easy to use, modern, and meets the needs of the project details below.

Project Details

Note: These are not in any particular order. In fact, the bottom of the list is probably more critical than the top.

1. Portal Level

1.1. Review/design "My Profile" area & related parts
Nico has added some social networking functionality at the footer of the demo site. We should review this functionality and consider re-designing it.

1.2. Review/clean-up headers, meta-heater, and general portal interactions
Depending on some of the changes that happen in the UX at the Site and Page levels, we may want to reconfigure the layout and general patterns of how users find, join, and generally navigate sites and other areas of Sakai.

1.3. Redefine the gateway page to reflect a more "open community" metaphor
The site model may change to be more open and inviting by default, without a requirement to "join" a site before having some access to it. If we achieve that enhancement at the site level, it would help if we also modify the portal gateway to communicate this openness.

2. Site Level

2.1. Clean up site and page management UI controls
In addition to the standard "Site Settings" options, Nico has introduced various page editing/management controls at the site level (i.e. Create Page, Edit Page, etc.). The UI for how these controls are presented needs refinement.

2.2. Design screens and work-flows for site and page based operations
The above mentioned UI controls call up various screens, each with a different purpose and a varying degree of depth/complexity. We will need to review what's there and clean it up if necessary, as well complete any missing pieces.

2.3. Adopt a different sidebar model
A more flexible sidebar design is needed. I have worked on a few ideas that we can use as a starting point. Ultimately, the sidebar will need to support navigation of Pages within Sites, but will also have a management (add/edit/delete) aspect to it – so expect more behind-the-scenes screens to support the sidebar functionality.

3. Page Level

3.1. Redesign TinyMCE editor to look visually more appealing
When all the controls in TinyMCE are turned on it's frankly overkill. We'll want to decide what controls to present by default. We'll also want to skin TinyMCE to look more consistent with any visual design changes that take place in Sakai.

3.2. Incorporate controls into page edit mode for adding gadgets/media/etc.
We'll need to add controls somewhere on or near TinyMCE for adding various functional bits into the page. This is really the starting point of the most crucial part of this project.

3.3. Design screens and work-flows for adding/editing/deleting gadgets/media/etc.
In addition to the controls mentioned above, we'll need screens for adding – and in some cases, inline editing – of the various functional bits that a user might add to a page.

To facilitate this work, we'll need to identify two or three entities that we'll want to get into this release. These will give the design team a contextual starting point from which to work form.

3.4. Design screens and work-flows for globally modifying permissions with gadgets/media/etc.
Once a functional bit is added to the page, it will need to be managed in someway. In many cases, the object itself will have inline editable features, but in some case there will need to be an aggregate view of all such functional bits so the user can manage them in one central location rather than hunting them down from page-to-page.

4. Other Odds & Ends

4.1. Review original UX Improvement screens and decide if any need enhancement, change, or abandonment.

Project Tasks & Timeline

TBD. However, the project timeline will work backwards from the assumption of a early to mid April code-freeze!

3akai Sketches

My Dashboard

Thumbnails (Click to enlarge)

Description

This is how a user's personal dashboard will look.

1. These menu options have a functional purpose and a communication purpose. They allow users to quickly orient themselves and locate major areas of interest in Sakai. They also send a strong message about the type of product Sakai is.

I have included "Groups" in this set for now, but frankly, I'm not sure I see how groups will be used at this level. We can create a unique site type for ad hoc groups which allows for a presentation that emphasizes only a few basic ideas, ex: discussions, members, files. But beyond this idea, I'm not really sure how groups are different from sites.

2. Persistent utility links. The mail icon implies a messaging system within Sakai.

3. This search bar will appear in virtually every main screen in Sakai. A search will return a search result screen which yields context sensitive matches. In other words, if the user searches for something while in their dashboard, the system will return a result that weights relevant findings within the user's files, personal messages, or other data that belongs to him or her.

Beyond that, the system will display results for sites, people, groups, etc., across the entire Sakai network. If on the other hand, the search is used while in a site, the results will be weighted to the content on that site.

The search results screen will be an important screen and will require a fair amount of time to design. The screen will have various filtering and sorting features that will allow users to quickly find the content they're looking for. This implies a content architecture with heavy statistics and meta data.

4. This is the user's dashboard links and profile summary.

The Edit Profile link will present the user with a UI where he or she can change their photo, add personal information, etc. There will be other ways to access the same UI.

The Messages link presents that same UI as the mail link in the persistent utility links. There may be other ways to access this UI - for example, we may have a dashboard widget that shows a list of N most recent messages.

Preferences will allow the user to control email notifications, time zone, etc.

5. This is a widget. I'm sure we can dream up all sorts of widgets that an academic user would find helpful. For example: Important dates, my grades, my to-do's, etc.

6. These buttons will allow the user to add new widgets to the page. The Options button will allow the user to change the layout, maybe change colors, and possibly other settings. This may be replaced by a "Change Layout" button, allowing the other options to fall under the Preferences link in the user's dashboard links. Or it's possible to go the other way and fold the Preferences link under this Options button.

Site Page - View

Thumbnails (Click to enlarge)

Description

This is how a typical site will look.

See Page View 1:

1. This is the page title. Below it are two important links: "Add a New" and "Publish Site". The former allows users to add a new page, dashboard, or tool to the site (see 1a). The latter walks the user through a wizard to package the content in the site and publish it.

This Publish Site feature is quite different from anything we're doing in Sakai. It's also quite different from any other wikis or site builders. The basic idea is that there are two forms of sites: the first is what is presented here, which is the "working" site. This site has a very collaborative wiki presentation and applies to 85% of Sakai's use-cases. In these cases there may never be a need to publish the site. The second is a "presentation" site, which is the result of publishing the content found in the working site.

During the site publishing process, the user will be presented with a wizard that guides him or her through packaging the content and presenting it in many different formats. For example, the content could be presented as a basic website, a resume or portfolio site, or any other type of site we can dream up.

The site publishing wizard will make use of templates, to expedite the publishing process, as well as fine grained control.

Pages that are published can either be "live" or "static". If live, changes that take place on the working site will be automatically updated to the live site. A static page can only be updated manually.

A site can be published as many times as the user wants - allowing for multiple simultaneous publications, each using different URLs, different design templates (presented in different formats & styles), and different access controls.

Publication settings can always be changed even after the site has been published. A published site can also be duplicated if desired.

2. These are the site links. Any page in the site can be designated as the "Home" page.

The Sitemap will allow for various forms of browsing and search all the pages (and perhaps other content) in the site. I'm currently thinking that the page architecture will be flat, and that hierarchy is implied with navigation inks. However this may change as I think through it more.

Members is self explanatory (details TBD).

The Related Sites link will display sites that have been manually related by users as well as auto-related by way of statistical analysis.

The Published link will display an interface for managing published instances of the working site.

Site Settings is self explanatory (TBD).

3. These buttons will allow users to edit the page and perform various other actions (see 3a).

4. This is the sidebar. It is a deceptively simple feature. The sidebar implies a templating architecture within Sakai. For example, at the bottom of the sidebar, there is a link to edit it. This will present the use with a typical edit page view. In other words, the sidebar is a typical web page (wiki page without the wiki syntax). The only difference is that the "sidebar" template was applied to it. This template not only designates the page to be used as a sidebar, but also filters a set of widgets that are only relevant for the sidebar.

So in this example, the "Browse categories", "Browse tag cloud", and "Related pages" sections are widgets. These could either be the starter set included in all working sites, or perhaps the user chose these when he or she edited the sidebar.

While the widgets may be page aware, the sidebar itself is site oriented. In other words, the widgets selected for the sidebar will be the same across the entire site. But the content within those widgets may change depending on the page. For example, the Related pages widget is displaying a list of incoming and outgoing links based on the page.

5. These sections will allow the display, navigation, and editing their related features.

See Page View 4:

1a. Clicking the "Add a New" link will present a drop down menu with three options: Page, Dashboard, and Tool. Notice that the Dashboard option is gray. This is because there can only be one site dashboard per site. The same with tools - a tool can only be instantiated once per site.

There are still many questions around these options. For example, why does a tool need to be "added" to a site? Can't it just have an omnipresence that can be linked to? Also, can't a dashboard be similar to Google sites dashboard, where it's constructed by the user by editing a standard page?

I have my own answers to these and other questions, but would like to hear your thoughts first.

See Page View 5:

3a. These options are not entirely thought through. This is just a started set to fuel discussion. To quickly summarize:

Page Settings will allow the user to control what features the page will have; for example, should it allow tagging, should it display a sidebar, etc.

View Changes is a link to the revision history. Notify Me of Changes is like a "watch page" option - which emails the user when changes take place.

Sharing & Privacy are access control features.

I hope all the others are fairly self-explanatory

See Page View 2:

4a. We can also dream up other widgets. Here is an example of a photo carousel. This widget lets the user cycle through photo attachments on this page. If there are no photos on this page, the widget heading is not displayed. The same is true for all other widgets that are page aware.

Clicking on a photo will present a page with a photo album UI. The same is true of all other widgets in this sidebar (and in general of most any widgets added to a page). The widget displays summary data and a narrow set of controls. By clicking on it, the user may be taken to a full screen UI that relates to the widget.

See Page View 3:

4b. If desired, any user can minimize the sidebar. The sidebar can be completely removed in the Site Settings area that is available to site managers.

Site Page - Edit

Thumbnails (Click to enlarge)

Description

No detail as of yet.

Site Dashboard

Thumbnails (Click to enlarge)

Description

This is an example of the Site dashboard page. A site dashboard can only be used once per site. It can also be designated as the home page, though that is not required.

Yes, I know, there's a typo on the first slide. Please don't let it distract you to much, err.. "too" much.



Check out this link:

http://confluence.sakaiproject.org/confluence/x/VAAlAQ (Skip ahead to 3:03 on the timeline to see how tweaking might look)



Companion graphics for easier viewing

This is a brainstorming page – please add comments without reservation!

I hope this diagram will help more than hinder the discussion related to site creation and course management. This is the first draft (v1.0) document, so as suggested, expect future iterations based on your feedback. Ultimately, I'd like to arrive at a diagram that captures the situation as accurately as possible.

To get started, click on the thumbnail:

Why do this? Mostly it's the method I use to understand complex ideas. I'm visual in nature (as you might imagine I would be), so the more I can articulate the idea in visual form, the better I understand it. Also, the end product might be helpful as documentation for others.

Much of what's here represents my own current (and limited) understanding, so please go easy. Also, while I encourage feedback from all, please try to keep the technical jargon to a limit.

THE BLUE DOTS

Where does the data come from?

A. SIS

I'm assuming the SIS is where most student data comes from? I'm sure some schools don't pull data from their SIS, so if that's the case, please mention it, but what about the majority of schools?

As I understand it, the SIS contains student records including their transcripts and registrar data? Is the registrar a separate system? Where should it be placed in this illustration?

B. It's my assumption that in the SIS, there is information related to classes?

C. Records in the SIS include "class" based tables/container with the student records? Is this a proper mental picture?

D. I'm assuming instructors and TAs or administration are not in the SIS, but rather some other system? Can someone help describe what systems are used and how data is pulled from them into Sakai? Please be very basic and general with your description – I'm not looking for too much detail.

E. External users from the web can also be included in sites. This implies invitations by email.

How is the data added and managed in Sakai?

F. This bubble represents a Sakai production instance.

G. These are a collection of sites in Sakai.

H. This bubble depicts the members in a particular site.

How do end-users find sites in Sakai?

I. Ultimately, end-users search for sites. They get a search result. How much data is (or can be) displayed in the result? Let's talk about the title, the site contact, the URL and/or any other unique ID. I'd like to understand how and if there might be ways to make the search result easier for end-users to work with.

THE RED DOTS

1. A complete class record (a roster) can be added to a site in Sakai.

2. An individual student user, even from a different class, can be added to the same site in Sakai.

3. Users outside of the SIS can be added to Sakai. But what systems are they added from and how?

4. Users outside of the campus can be added by email invitation?

5. Sites can be found by searching for them.

After wasting a considerable amount of time sketching thumbnails and wire-frames, I've come to realize that any design I come up with for course management just doesn't hold water!

It's clunky, unintuitive, and fails to speak to everyone's needs. I think the problem stems from trying to beautify an existing design that I don't fully understand.

Some of the issues that confuse me are:

  1. Are site types something truly special, or are all sites essentially the same with the exception of different access controls?
  2. Is adding rosters during the course site creation process a required logical step or just a legacy design decision that we've all grown attached to?
  3. What the heck are rosters? I mean, I think I know, but is that word common end-user vernacular?
  4. On a related note, why do we say "course" rather than "class"? When I go to school, I go to my class, not my course - and would expect to find a site for that class. Can someone explain?
  5. And since rosters represent only one of several ways of adding users to a site, do they deserve the special treatment they get in the UI, or should adding site members be a more comprehensive experience with rosters, campus directories, and external users all managed through a related set of screens?

Please help shed light on these and other points I may not have thought of by using the comments feature on this page.

Here's what my research has lead me to thus far

In addition to the questions above, I want to also share my thoughts on discussions I've had with UM folks. If you've taken a look at the designs I've prepared last week, you'll see the site title is grayed out when the course site option is chosen.

UM prefers that course site creators be prevented from adding their own site title in order to reduce confusion when end-users search for sites in Sakai. This makes sense because if sites have duplicate titles, end-users might not know which site is which. But I'm wondering if this is the best solution for the problem - particularly since not all institutions employ this approach.

As I've thought it over, I've come to identify three main methods (I'm sure there are more) for adding members to new sites.

Method 1

Members are added during the site creation process. To simplify the process, members are grouped into rosters. The site creator is able to select and add multiple rosters during the site creation process.

As I understand it, rosters carry with them several types of data. For one, rosters represent groups of user that belong to a class. Secondly, rosters include meta data about the class such as: subject, course, section, etc.

In essence, adding a roster to a site commonly means the site creator wants that site to be used by a particular class. However, more than one roster, hence, more than one class, can be added to a single site.

Advantages of this method

  1. By adding rosters during the site creation process, the class meta data can be used for the site name. Since the site meta data has unique parameters, the site name is in-turn guaranteed to be unique. This reduces confusion when searching for sites.

I believe this is UM's logic.

Disadvantages include

  1. Does not offer site creators the flexibility in building course sites before there is an official roster or record in the school's registrar. This could be fairly limiting in certain circumstances.
  2. Forcing the site creator to sift through rosters during the site creation process is arguably cumbersome.
  3. Its not entirely clear why only rosters are front-loaded in the site creation process and not individual members or external users (perhaps to help reduce the steps and confusion of creating a site?).
  4. Having two processes for adding members: during site creation (rosters only) and after site creation (other member types) is arguably cumbersome.
  5. Advantage #1 doesn't hold when user adds multiple rosters to one site. Only the first roster's meta data is used for the site title.
Method 2

First create a site, and then add members.

Advantages

  1. Simplifies the site creation process.
  2. Potentially makes room for a comprehensive UX that lets the site creator add members using rosters, campus directory, and external users all in one fell swoop.

Disadvantages

  1. What will the site title be if not based on a roster? In other words, this approach introduces the problem UM is trying to avoid – duplicate site titles in the system.
Method 3

A combination of method 1 & 2 – which carries with it many of the disadvantages and only some of the advantages. This is how Sakai is currently setup.

Trying to corner this issue once and for all!

To complement these talking points, I've narrowed in on three key issues that will hopefully help me better understand this design challenge.

Please do not respond to the following topics on this page. Instead, follow this link and post your answers there. Thank you!

1. Where does the data come from?

I have to confess, I don't fully understand all of the campus back-office systems. Does an SIS only contain student records? If Sakai is integrated into an SIS, where does instructor or TA data and credentials come from? Please elaborate – with non-technical language (smile)

2. How is the data added and managed in Sakai?

Is everyone integrating into back-office systems, or are some running scripts to dump user data into Sakai? What happens to the data when a student graduates or drops-out? What happens when an instructor leaves? Can someone help describe these interactions?

3. How do end-users find sites in Sakai?

Do users automatically see the sites they are members of? If no, why not? Can more meta-data be added to Sakai sites to help differentiate sites and thereby mitigate UM's concerns of confusing sites with identical site titles?

Round 1 design mock-ups

A few points to keep in mind:

  • The screens are meant to be viewed in sequence (more or less).
  • Screens 4-4b show different states.
  • Screen 6 is the same as screen 3, but used to show the proper sequence. In other words, when a user updated his/her search settings, the system returns to the search result screen.
  • The cross-listing feature was omitted at this time. I have another screen where I include it, but am not thrilled with it so I didn't post it.
  • Going through this exercise has made me realize that the lightbox method for this flow is too restrictive. I think we need to open up the UI without the small window constraint. I'll probably be working on a version like that in the next round, but want to get some feedback on these screens first.

Enjoy!

Site settings changes

Worked on Site Settings: Import/Export Screen.

Warning

These notes are archived, potentially for future use. This project will be scaled down to a more manageable set of short-run objectives.

Overview: This is a working document used to organize the design issues related to course management functionality for the "Improving CLE 1" UX designs. Please feel welcome to edit this document directly.

I. Course Site

A site type that is "officially recognized" by the university as the online counterpart to an actual course in the catalog.

A. To create a course site, the following is needed:

Required

1. Title
2. Matching course record in catalog (may include: academic term, subject, course/number, section/class, etc.)
3. Description
4. Site contact
5. Members (with roster support)
6. Access Controls

Optional

1. Site nickname
2. Starter set of widgets and tools
3. Survey questions during site creation (zqian: Just in case this existing feature won't get lost. What's the alternative place for it? )

B. Course record data set

1. Academic term <-- is this part of the record set?
2. Subject (ex: PSY)
3. Course (ex: 101)
4. Section (ex: class number - 90369)

Note: not all institutions use a section.

C. Summary of course creation scenarios

Note: These are not traditional detailed user scenarios, but rather are high-level summaries of key issues.

Instructor

1. Creating a single course site per class that he teaches, one at a time:

The instructor will be presented with a site creation process to build a site based on an official university record of a class he is teaching. This will involve finding a record of the class he is teaching via some type of navigation process (ex: browsing and/or searching). Likely, he will need to find his class by filtering options which may include academic year, course subject, etc.

Once he locates his class in the system, he can build a course site for it. Assuming he is logged in using his official credentials and has filled out all the required information, the system will create his site.

If the class is not in the system, he can submit a request to create a course site for a class that he thinks should be in the system.

2. Creating a single course site per class that he teaches, several at a time:

Similar to the scenario above, the instructor will need to find his class(es) in the system. But in this case, he teaches more than one class and wants to create a site for each one. Rather than repeating the process of creating a site for each one, he can find and select all the classes he teaches and generate a site for each class in one fell swoop.

3. Creating a single course site for use by multiple classes that he teaches:

This option is not allowed

4. Create multiple course sites for use by a single class that he teaches:

This option is not allowed

5. Creating a single course site per class that he "does not" teach, one at a time:

As the instructor navigates the courses in the system, he might decide to create a course site for a class that doesn't belong to him. This option would set in motion an authorization process. If he is given authorization, the system will create the course site. If not, the system will not create the course site.

6. Creating a single course site per class that he "does not" teach, several at a time:

This scenario is similar to the one above, except that the instructor selects more than one class (all of which do not belong to him) and requests authorization to build single course sites for each. The system will create course sites for those classes he gets approved for. The system will not create course sites for those he doesn't get approval for.

He can repeat any failed attempts as often as he likes – although there should be a way for the admin to prevent spamming and abuse.


Other Authorized User (ex: instructional designer, TA, IT staff, etc.)


Unauthorized User (ex: student)


II. Non-Course Site

Any unofficial site type.


WIP

Worked On Last Week:

Nathan

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

Nico

  • 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:

Nathan

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

Nico

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

Here's the UX Kit.
This concludes UX improvement project called Improving OSP 1.

The initial upload only includes the PNG screens (source graphic files). The HTML is in progress and will be posted as it becomes available.


Download The UX Kit

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.

Week 3

This week's changes reflect the feedback given by the OSP group on last Monday's call.

Summary

  • Too many things to list at the moment. I've added Beth's summary of last week's call instead. Download the summary here
  • The add user (for sharing) feature is quite different. I'm imagining some intermediate use of AJAX. I hope the screens are self-explanatory.

Enjoy!

Zip archive of all screens (Week 3)

Still bothered by a few issues... so I had to make a couple updates. Hope you can see and appreciate the changes.

Zip archive of all screens (Week 2.2)