Project Profile (CLE 1)
Overview
This project is based on previous discussions that can be found here: UX Improvement Project
Goals
MAIN DESIGN GOALS
To summarize, the overall plan is to re-design a few key areas of the CLE that will help end-users accomplish the following:
Immediately distinguish between the gateway (pre-login) and the main CLE (post-login).
Once logged in, quickly get oriented to the CLE by understanding the layout, controls, and overall UI metaphor.
Easily understand where to go to setup a site of their own.
Intuitively setup a site of their own without limiting any existing functionality.
Once a site is setup, easily understand how to make changes to it (edit it).
*Once user A sets up a site, user B should generally have no problems getting oriented to the environment even if it's his/her first time logging into the CLE.
Package the designs into an "implementation ready" kit.
*We'll have to see how this one goes. But in general, it shouldn't be out of reach.
SECONDARY DESIGN GOALS
Gain more insight into our end-user's needs and expectations.
Explore layouts and design concepts that push Sakai into a more modern application from both a technology and UX perspective (think Web 2.0)
Take an inventory of various systemic usability issues that go beyond the scope of this project and explore solutions that can be implemented into this project as a proof-of-concept for solving them in other areas.
Deliverables
DESIGN DELIVERABLES
Screen Designs - Includes virtually every *screen template needed for implementation.
Optional Materials - Any prototype, wire-frames, or other blueprints that document the user interactions through the design.
*Screens will be in PNG format and will represent the coalescence of all the UX design work and thought that goes into this project.
WEB DEVELOPMENT DELIVERABLES
Web Templates - Consist of HTML,CSS, and JavaScript. These web templates should correspond to each of the screen designs.
JAVA & DB DELIVERABLES
???
Comments
Hey Lance, when I tell people about my layout ideas without site tabs, I always refer to Indiana as the place that needs them. Brad told me that in the change from old OnCourse to Sakai, the ability to flip to and fro between sites was one of the valued features of Sakai. I haven't abandoned getting rid of site tabs, but I hold this thought as saying if we do get rid of them we will need something else to support flipping between sites. It was suggested at the time that relying on browser tabs would not be good enough...
I agree; we do not want to lose the capability. What I would like to see: a) reclaiming the screen real estate currently consumed by tabs, b) allowing individual tools to now implement their own tabs within their real estate, and c) a new site navigation mechanism that maintains the ability to flip between sites quickly. Best, L
Hey Lance,
Site navigation, along with tool navigation, it something I'll certainly be looking at.
I'm curious about your last point:
"c) a new site navigation mechanism that maintains the ability to flip between sites quickly."
Can you help define "quickly"? How important is it for instructors or students, to have the ability to quickly jump from one site to another?
My assumption is: While in a site, performing interrelated tasks efficiently is key. But once the user jumps into a new site, he/she departs from the task-flows being worked on in site A and is now working on task-flows related to site B.
Do you think my assumption is correct, or is your opinion that a user's tasks bleed from one site to another often enough to warrant a navigation method for rapidly jumping from site to site while working?
Nathan,
I think your assumptions are probably good for students, but instructors are often dealing with multiple sites where they must "flip around". The current DHTML site navigation is quick enough (I think). If I were to suggest an improvement, it should have an area of the five most recently visited sites. It is not uncommon for our users to have 30+ sites listed.
Hey John,
Can you shed some light on your last point?
"It was suggested at the time that relying on browser tabs would not be good enough..."
How is Indiana using the site tabs?
I might suggest that we rethink the tab metaphor for site navigation. We recently ran into a case with Assignments 2 where we wanted to use tabs for navigation within the tool, but were worried they would compete with the site tabs. Generally speaking, I would like to not only streamline site access, but also reduce the amount of screen real estate consumed by the portal bits. Thanks! L