GATEWAY & MY SAKAI
SITE SCREENS (GENERAL)
PAGE AUTHORING (GENERAL)
DISCUSSION FORUM VIGNETTE
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?
- 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?
- Is this needed here?
- What is the expectation for this?
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?
- 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)
- 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...??
- 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.
- Need edit and view screens.
- Need drag and drop UI – probably a lightbox.
- Might be the same lightbox as move, but maybe not.
- 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.
- 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?
- Would be nice to go with the new screens.
- Peter suggested an import CSV/Excel list. Might be a nice enhancement.
- Probably going to omit this?
- 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.
Main template screens
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.
If you haven't looked at the 3akai demo site, please review it now. The URL is:
You can create an account and login on your own.
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.
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!
Thumbnails (Click to enlarge)
This is how a user's personal dashboard will look.
Site Page - View
Thumbnails (Click to enlarge)
This is how a typical site will look.
Site Page - Edit
Thumbnails (Click to enlarge)
No detail as of yet.
Thumbnails (Click to enlarge)
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?
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:
- Are site types something truly special, or are all sites essentially the same with the exception of different access controls?
- 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?
- What the heck are rosters? I mean, I think I know, but is that word common end-user vernacular?
- 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?
- 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.
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
- 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.
- 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.
- Forcing the site creator to sift through rosters during the site creation process is arguably cumbersome.
- 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?).
- Having two processes for adding members: during site creation (rosters only) and after site creation (other member types) is arguably cumbersome.
- 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.
First create a site, and then add members.
- Simplifies the site creation process.
- 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.
- 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.
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
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?
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.
Course Management / Create a Site - Round 1 Mock-Ups
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:
2. Matching course record in catalog (may include: academic term, subject, course/number, section/class, etc.)
4. Site contact
5. Members (with roster support)
6. Access Controls
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.
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.
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.
- 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.
- 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.
This week's changes reflect the feedback given by the OSP group on last Monday's call.
- 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.
Zip archive of all screens (Week 3)
Week 3 Thumbnails
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)
Week 2.2 Thumbnails