Prototyping Idea
I've found paper prototypes to be very useful for sketching out early design alternatives. I think it's important to keep the entire page in mind in my design, so I can catch problems like language or UI inconsistencies in what I'm designing. I've created a template to scale based on an 800 x 600 browser window and the Sakai OOTB skin, with the major page elements. You can just print it out and start pencilling in your interface ideas. It's also easy to tack up onto a board to get a sense of the task flows. I hope that others will find it useful as well.
Administration Workspace UI prototype
I thought it was a little cumbersome to scroll all the way down a huge list in the Administration Workspace, find and check the item I want and then scroll all the way back up to select what to do with it (revise or delete). So, I thought why can't we just have the action buttons next to each item to avoid this:
Buttons are inline with each item:
Any thoughts on the validity of this? Button styling isn't concrete, just a quick suggestion
Steve Lux
Portal UI tweak - rework of tab based navigation
As a point of interest, I'll also post where we want to take our User Interface. We're still confirming user responses so it's not 100% concrete. I realize it's a little beyond the scope of this page, but is closely tied to design decisions:
DISCLAIMER: very very alpha level UI design.
I was told by our programmer extraordinaire Zach A. Thomas that this wouldn't require any core code mods. That was a relief because while UI and GUI ideas are great, they ALWAYS have a reality of programming.
We're proposing to move out class name and description into the page. This moves the name out of the tab based schema and brings in a site description for each page. Also, we're toying with the idea of letting someone have the ability to edit up to 5 main tabs with proprietary names. i.e. instead of "courses" and/or "projects" they could control it themselves and possibly categorize each class.
Another very important discussion we're having about UI is the tool list on the left. On more than one of our sites there are 15+ links. It gets VERY monotonous and we're looking into a way to allow categorization of those links with titles. Our UI group is still in its infancy, but there are some really interesting ideas we've come up with so far to solve sakai UI idiosyncrasies.
Again, HUUUUUUUUGE disclaimer, but thought others in the Sakai UI workgroup might benefit in some way from our UI brainstorming sessions.
Any feedback on how usable (or not) this could be?
Steve Lux
Comments (5)
Oct 21, 2005
Peter A. Knoop says:
Would it be easy for you to add versions for larger screen resolutions, like 102...Would it be easy for you to add versions for larger screen resolutions, like 1024x768, 1240x1024, and 1600x1200?
Oct 31, 2005
Michelle Bejian Lotia says:
I think so. I'll play with it and post other versions here. Do we have a specifi...I think so. I'll play with it and post other versions here. Do we have a specific screen resolution we target?
Oct 31, 2005
Michelle Bejian Lotia says:
I did a version for 1024 x 768 resolution and attached it to this page.I did a version for 1024 x 768 resolution and attached it to this page.
Oct 31, 2005
Stephen Marquard says:
The page layout has changed slightly in 2.1 (CSS changes I think) so the tool if...The page layout has changed slightly in 2.1 (CSS changes I think) so the tool iframes are slightly wider (less whitespace on the right border).
Mar 03, 2007
Diana Lee Perpich says:
Steve mentions that the team is also looking at the tool list on the left, parti...Steve mentions that the team is also looking at the tool list on the left, particularly for sites where there might be many, many tools. My first, brief comment is that we might be able to avoid some of these links if we fronted to users the fact that you can put multiple tools/frames on any given page (a.k.a. "tool"-- I will call them pages for the sake of clarity. It just so happens that most pages, besides home, currently default to a single tool) I've seen sites were instuctors would be just as happy, often more happy, to put two web content tools on a single page. When I use my admin rights to do this for them, they are very well satisfied. But on to my second, more extensive comment.
In another community source, site-building tool I work on, we've addressed the left nav bar this way:
1-- allow site owner to show or hide any given page. In Sakai, that could mean that the site owner turns on Resources, but hides the Resource link from the left navigation. The site owner might use the Wiki as the content portal, with links to resources on the wiki pages, or as attachments to Assignments or Schedule items or Announcements. We already allow do this in Sakai, but we don't always demonstrate it's potential as a best practice.
2-- allow site owners to indicate parent/child page relationships. Child-pages are only revealed when the site visitor selects the parent page. Children can have children of course. At the UM.Sitemaker website, the left-navigation looks like this by default:
and it looks like this when the parent page, "Support and Training" is selected (emphasis mine):
Six new pages show up under "Support and Training," indented slightly. They will be hidden again when the user visits a different first-generation page. You can try it yourself, if you want, by visiting http://sitemaker.umich.edu. Some people aren't crazy about the way the nav list seems to jump around when you hide and reveal pages, but those site owners can opt to reveal all their pages all the time.
Here's what it looks like on the Main Configuration Page for the site-- think Site Info > Edit Tools...
A dropdown number in the first column allows the site owner to re-order the pages, known in UM.Sitemaker as sections. The arrows before and after section names allow the site owner to indicate parentage. Click the go-right arrow to make a section the child of the section above it. This UI isn't great and people still get confused, but it's been quite servicable after 15 months of use in production.
This site has over 40 sections (a.k.a. pages), but only nine are visible to the site owner at first. The other 31 sections are either child sections or hidden sections accessed via inline links throughout the site.