Forum OpenACS Development: .LRN user interface design
What we're doing is to go one step deeper than just a quick "make it look pretty", and actually attacking the navigation as well as the interaction on the key pages, bringing in Bruce Spear of the UAB to help us understand what users need to get from e.g. the class admin page.
We're only looking at 4 pages right now, and probably won't even get to implementing all of them. So it really is quite limited. But it should show some concrete results and direction.
We'll post the graphics showing the design as soon as we have them, which should be mid next week.
And we'll implement everything as clean CSS, so it's easy for everybody to style it to their own liking.
I'll keep you posted here and on our Developer blog at http://www.collaboraid.biz/developer/.
design is supposed to take place. In my opinion, it
is important to clarify the status and role of some
pages and areas:
- a "community page" that Carl called a key piece of the
- a page area that other systems call "Links for YOU"
(customized to specific target audiences)
- a similar area for "MY links" (personalized by oneself)
Unless these roles a clearly assigned, every navigation
will have major problems.
Also, the navigation to certain public pages needs to
be more transparent:
- personal pages "published" within the inTRAnet,
- public personal pages reachable for the unauthenticated,
- group pages for the inTRAnet,
- group pages for the inTERnet.
What makes navigation also very difficult, is the concept
of subgroups. As long as this does not allow for proper
hierarchy where the link "up to (parent group)" is
similar on all levels, subgroups is, IMO, more confusing
than helpful and should be able to be switched off at
system setup time. A proper hierarchy, however, is
important, see also bugs like
Post feedback here, please.
These look very good. I like the clear difference between the various elements in size and color. It makes it very easy to sacn the page for information.
What would be really interesting would be to get a couple of paragraphs describing how the attributes for each element were decided. That is, a little insight into the actual design process.
What this shows is a clear process and direction is designing user interface is needed as part of an application. It is not just about pretty colors, but making sure that the information that is needed is easy to find.
Presume compliance with such things regional equivalents of such things as Americans with Disabilities Act requirements, etc.
I like Dave's comments, but the info text is redundant by your third visit. What could be nice would be a little [i] logo in the top right of the portlet title bars - these would open a popup (or better, a popup-like hidden div) of the aforementioned info text).
Similarly, a hep icon could be next to the [i] to provide a context help popup. I think help is a major missing factor in our .LRN designs in general.
Also,there are a lot of "My Space" strings! Can we assume that the smaller (and upper) "My Space" String is actually the breadcrumb? If not, where does the breadcrumb go? It's an important part of our navigation, and mitigates some of the concerns raised by Matthias
All I all, considerable improvement and looks really nice. And if you make sure that we can change the colors site wide easily by some parameter (or in a master CSS file), it would be even greater.
You're right, we're missing the rationale between the design elements. Believe me, the rationale is there, we've spent a great deal of time tweaking this. Let me get this written up and posted shortly. Thanks for pointing this out.
A few specifics: Yes, the "My Space" on white background is the breadcumbs.
I agree that there are a few too many "My Space"'s on the page, but we haven't found a good solution.
We've decided to keep the bread crumb and the page title (the one right above the tabs), because these will be important for orientation on the page, so we decided that it was more important that they be present on all pages.
We could choose to re-label the tab "Home" instead of "My Space Home", though.
We have left out help icons on purpose, at this point, because we don't have much useful help to offer. We have discussed ways to present help, though, so it'll be easy to add.
As for the "My Space" at the very top, this was to address a concern about users being able to find their way back to My Space, even though it's linked from the bread crumbs, from "SloanSpace", and from "Al Essa". Plus, Basecamp has a similar link there back to what they call the "Dashboard". It's something we can easily cut, or at least tweak the design somewhat to make it less obtrusive.
As for changing colors, yes, the goal is to implement this as nice, clean CSS, to the extent that the current project allows us to do so. And we'll do everything we can to throw in a really simple color picker, as we already have a couple other color schemes in mind, and there's nothing like colors to invite for bike-shedding 😉
Glad to hear that you generally like the design. Please keep the feedback coming.
You are using a color scheme, where larger letters use less contrast. That's great. You could take the scheme a step further by using contrast to indicate focus. Have contrast increase for the content specific to the page (black and white), with backgrounds in less contrast (such as the greens used on these). This intuitively helps users consistently focus on the page content.
Of the 3 choices, the first one appears to be most consistent in displaying a position grid, indicating where one is in the website. Each vertical line represents a subsite, each horizontal position represents a parallel location subsection or bread crumbs.
For the example, I assume .lrn is the technology and sloanspace is the website. Maybe these should be on the same horizontal line. If not, maybe you can indicate separate zones by say, making the first line at the primary level, such as MIT, then the second line as Sloan School of Management, and the 3rd line "Cohort/Group", and then a forth line "My space"
I've posted them here;
Just as a general point, some users didn't like the 'boxy' look and wanted something 'friendlier'. We decided to go for a 'newspaper' look (something like the New York Times), but this was somewhat frustrated by the number of levels in the headings.
You Are in > My Space
should surely be:
I am in > My Space
You are in > Your Space
'You are in my space' sounds like you are sitting in someones seat.
At the time we were more concerned about a way of merging the two horizontal menu bars at the top of the page. We remain concerned about navigating between classes/communities - it is not as intuitive as we would like.
- Like the hard to miss alerts.
- Like that the language selector and logout are finally in a more standard location (up in the right hand corner).
- Like that we have that space for permanent links (e.g. going to the "site home" or "myspace" -- a problem on dotlrn.org)
- Like that the tabs have finally won back their tab like quality again.
Looking forward to messing around with themes and testing the real thing with lynx (important point made by Cesar). If it works nicely with that browser I bet we would be the first (although I assume we are pretty close already for historical reasons, like the communities hatred of frames).
Can we introduce ACCESSKEY as standard attribute for links and forms (input, textarea, button, label, legend), so people can work them with the keyboard?
The power of tabbing to structure and make less chaotic the space below is illustrated in another site our graphic designer Sille has made for a research outfit, http://www.erhvervsphd.dk/visArtikel.asp?artikelID=510, and where you will see how the headers in the column left reinforce the relationship to the text at right and indicate strongly where you are among a limited number of options. The stylistic advance with her Dotlrn model is greater care in her carving of the tab shape and space so giving the Dotlrn page a fine character, like well-made furniture.
The problem is complexity and the loss of metaphor in the chaos that comes from developing the metaphor only part way. A comparison with her design for the music page of the Danish television second channel might be illustrative: http://www.dr.dk/musik/. The page is down as I write, but it features a cool Bauhaus design layout style whereby the dozens of text/image items are toned down so as not to compete too much with each other and are held together by a light, colorful framework of color bars and white column gutters.
This is not her fault, because we tried to stay close to the earlier model as we had a limited mandate for change. I see a powerful design and stylistic sensibility bound to the confused, data model orientation of the previous Dotlrn designs. This leads to such confusions as the doubling of the words "Classes and Communities" in the portlet header and the sub-heads and the attempt to create a header out of the calendar selection dates to the right. This doubling and faux header is ugly and dumb, and she made the type large, I think, following my friend Louette's Terre Haute Indiana advice, given to me as a sort of blessing as I headed off to language study in France: "If you don't know how to say it, Brucie, say it LOUD!"
This over-size type, or more properly, the to my taste ill-proportioned type scheme, suggests over-sized cutlery spilling off the table.
I think we need to give the designer more freedom, and maybe more money, to move that type around and even hide some of it if necessary. To that we in the community need to give her a license or mandate to make more sense of it.
To do that I think we might, following Cesar's advice, work with a little pain and offer a way out -- using our technology, of course. The pain is that large, faux subhead announcing the starting and ending points of that week. I already know the starting points of the week, as the first entry in the column, and I already know what kind of calendar it is, too, in the "Week Summary" portlet title. Our past has burdened the designer, and we must set her free! And let's do it our way, such as we list options in the course admin pages: how about making an informative, useful, switchable date column heading of "Week/Month/Semester"? Done right, she could design it in a way that carries the tab/furniture theme and so inviting the user to chose the most relevant selection just like he or she is tabbing her way across the desktop.
I would suggest that she strengthen that tabbing even more, and one way to do that would be to condense the seven visual lines above it. If I were the designer, I would move the Sloan Space logo to the right of the tabs, where there is plenty of space for it, send poor Al Essa's picture to his mother, and get rid of that top bar entirely. The idea I might like to explore is Dotlrn as a no-nonsense place of work that nonetheless has a warm vitality to it (and I am thinking of the pleasures of the lush southern German landscape I am presently enjoying in springtime). The tabs, like American-style file folders, suggest an orderly place of work and a limited number of tasks, too: I want to enter into my work space, get a nice little pile of work done, and go to lunch: the tabs say to me: let's run through three or four places, take care of business, and being a good Protestant get that work done and move on: those tabs are wonderfully inviting: I want to push them and watch them open up.
What is keeping the designer from exploring the tab/furniture theme further is the two-column format, and I wonder if the tabs are not powerful enough that we might not empower them further. If we made a tab on the left called "Desktop" that presented the current two-column overview, but reduced it in size like an appendix, might not that allow the designer to explore full-page displays that would allow for more and more complex portlet presentations? Some idea of what that might look like is, again, in her http://www.erhvervsphd.dk/visArtikel.asp?artikelID=510 site, where the simpler space suggests less a packed shipping clerk's collection of details and more a professional researcher's hierarchy of responsibilities.
The one strategic and functional concession I'd make is to Openacs and breadcrumbs: allowing for a thin line of breadcrumbs at the top and off the tabletop, above the rich metaphoric universe of the Dotlrn tabletop, shape, and color field: sans-serif characters on white background, set back a bit, neutral, reminding you that behind the rich metaphor is a simple navigational structure -- like the cool rounded stainless handrails in Disneyland's "Circlevision" giving you something to hold on to and so saving you from vertigo.
Reducing and simplifying the headers and strengthening the tabs/furniture will leave us with two useful lists advancing on the header icon at right: the tabs inviting me to work my way forward, and in the background, the breadcrumbs noting my progress and assuring me I can get back home. And we might reinforce the strong symbolic axis by anchoring the breadcrumbs with "logout" to the very left, point null so to speak, and against that, reinforcing the rich parade of metaphor and tabs on the Dotlrn level, by animating the logo with that nifty slideshow arrangement we find on Nima's Mannheim site and which he generously gave me for my FU sites, including: http://learn.jfk.fu-berlin.de/, where you will see with each page refresh images loosely related to the site theme: students and faculty love the images and how, with each new page, there is a tiny witty commentary, tickling their fancy: a fine counterpoint to the breadcrumbs heading back to the left and the logout.
First, in respect to the order of the day, we spent our first hour looking at a functioning Dotlrn 1.0 site so we might introduce our designers to the basic functionality that the interface would have to address, and we accepted it as a given, as I understand it, because we have a limited budget and mandate to make it pretty and with some attention to improving functionality and code structure but not much. The problem with this is that there are components that made sense before but might not make much sense now, and my call to give the designer some license was to give her some space to help us rethink what we are doing "on the fly", so to speak: she can see things the rest of us likely can not so easily: we are too close to the functionality.
Second, since we have inherited all this baggage, including code and our habitual way of looking at it, and since we are not consulting everyone all the time and don't want to offend anybody, it is much easier for us to add stuff then cut things away and re-organize things. This means we add and add to the point that the whole design, in my view, has became incredibly top-heavy, adding a terrific tax on the user. Hence, my call for simplification to make it easier for the user who, as I have argued, has a limited number of things to do in a given session and has no need for most of it most of the time.
Third, over-riding principle was to "make it pretty", but not "make it simple", and if we had begun with "make it simple" we would likely have ended up with something far different. We did not, for example, begin with user scenarios based on a needs assessment based on empirical research. I think it is fair to say that our task was defined, basically, as stacking the old bricks in new ways. We did not start from a usability study of, say, three different course structures and needs and as these needs changed over the beginning, middle, and end of the course. For example, courses typically start with the problem of presenting a syllabus, organizing meetings, and presenting materials. After a few weeks, students are making presentations and working on projects. At the end, homework is being submitted and evaluated. Each of these involves different proportions of application use: syllabus and file storage to start, then sub-groups and forums, then adding of minutes, reports, and homework as well as feedback. There are other models, to be sure, but I think this illustration suggests how general and function-oriented has been our solution thus far, and that this is a liability.
Fourth, to use a metaphor from Kant's aesthetics: there is a difference between knowing a pyramid by counting the bricks as an arithmetic series and knowing it as a geometric solid. When I work with databases and logic my head is in the former. When I compose my photographs and look at graphic design my head is more in the latter. When I look at the list Lars has offered I agree with every single thing. When I look at the whole, as I described, many of these things sit uncomfortably with each other. Hence, my suggestion that at this stage of the design we give the designer some space (license, mandate) to design a simpler, more comprehensive solution that users might read in a glance and find their way to using more comfortably.
I wish I had more opportunity to explore higher level usability and design issues, and this thred is being a thought provoking read.
I haven't thought this much about usability design and empirical studies since I tutored some University subjects on similar topics a few years ago :)
Please keep posting your thoughts - dotLRN in particular and the community in general are benefiting.
Quick feedback, please. We want to start coding tomorrow ...
Just my two cents.
You're right, it does connotate error more than confirmation, currently.
Just for background, this current redesign is co-funded by MIT and Collaboraid, and the funds are quite limited.
Should be quite easy to have different message categories rendered differently with CSS right? even the image. Not for this round but for the future.
I am really happy to see this change, it's quite badly needed (yes, we always complain that the look is not as important as the underlying architecture but many decision makers are convinced more by the looks, like it or not).
We would need to change the message stuff to track a message type as well (maybe message, warning, error or something like that) to be able to decide what css class to use.
The multiple icons/colors/message types was actually something we had on our wish-list, along with other things like cooking up a few pre-defined color schemes, or going more deeply into the applications.
So we've had to do everything we could to limit scope. Specifically, we've stuck to just 3 pages: My Space, a list-builder page, and a form-builder page (both taken from file-storage, but that's not terribly important). And we've limited ourselves to one version of everything. And no deep IA changes, or application pages.
So brainstorming about what we could also do is helpful for future reference, if anyone should find the funding/time to continue the work at any point in the future.
Right now, the most valuable input would be ways to simplify what we have ...
The message bar is for direct feedback on the action the user just took. There's a causal relationship. You do something, then you see the message which confirms that you did something.
I'm afraid we'll be confusing matters if we use that same location/shape/color for other purposes.
What do other people think?
Is it intentional that the tab reads "My Space Home"? I would like a space home but I am not sure how I would get there with the shuttle grounded.
I think "My Space" or "My Home" or maybe "My SERVICE" (where in this case SERVICE would be SloanSpace) would be better.
- It would be nice if one could change the look and feel from a single file
- the context bar should be available though not necessarily on the My Space view
- table views and not lists for more than 1 item in the announcements, forum lists and faqs portlets are better since they don't need much as much space
I know most of the stuff above has nothing to do directly with the Design, which is due to the fact that I really like it, but hope you implement it technically in a consistent was that allows easy changes for the person installing and using .LRN.
My apologies for responding late.
We did consider left side navigation, but decided against it on this project, for the following reasons:
- We have limited resources, so stick with something closer to what we already know.
- Most current OpenACS application don't work well with left side navigation, because they tend to assume a wide workspace, for example calendar and bug-tracker.
- The stated primary objective fot the current redesign is to make .LRN look pretty for marketing purposes, not improve usability or navigation. Because we at Collaboraid does find usability and navigation important, and the notion of slapping on a pretty shell on an otherwise unchanged product problematic, we chose to add funds of our own for information architecture work. But we don't have much money, so it's very limited.
In order to mitigate this, we did intentionally design the output HTML so it should be easy to apply a different stylesheet to change the tabs to be left side navigation.
Yes, of course you can set colors with a CSS class :) Also you can use the background-image property to add an icon, although that might not be the best choice.
- when the message bar is not present, there's no space either.
- the bar stays, but it won't be there on the next page view. It's only shown on one page view (until the next time you do something that we show a message for).
Having two fixed types (ie. warning/notification) IMHO is a good idea. Either that or we enforce the bar for errors & warnings only, which is impractical.
If we are stuck with one, then I think the colour needs to be less scary - a deep orange or something - so it indicates it wants your attention, but doesn't make you think you just lost oxygen pressurization in your space home.
Going for multiple types has a few implementation and display trickeries. For instance if a page logs both an error and a notification, you now need to display two widgets (with their own styles) rather than just one with two lines.
Regarding the multiple notifications, I'd put error messages first and add a "more messages .." link to it, displaying all messages. If the user continues calling a different page, the top most message of the message stack will be displayed (and deleted after display from the stack) and so on and so forth.
In the last week I answered to three RFC/Ps asking for internal notification and message capabilities. A notification bar would solve their needs.
Either way, as it seems that people would like to keep notification and error bar seperate, I'll do so and add an attribute to enable notification bar (if we are ever going to implement this, the more we thought about it, the better the design gets, but the more work is involved....).
So make sure it is possible for them to have 100% of the horizontal space if their owners want them to have that space.
Also, the top bar where Language Logout and Name is should be given room to grow: e.g. Help, New Mail (10), Buddies (5), University Homepage, Library etc. Keeping that space for local branding is important as well (Sloanspace)
In any case, Help, Language, and Logout should keep their VIP spots on the right top.
On the right top: how often do we switch languages compared to using the help and logging out? Languages is a wonderful design feature, but I'd suspect it is used seldom (ok, another query, how often do we switch languages?) and might better be put in the Control Panel to simplify things a bit, leaving room for something else we use more often or to let in more light and air. Or?
Of course, a generic "Change language" link in the currently selected language isn't going to help you any, so what we need [is something like what Joel (http://aufrecht.org/) has at the bottom of his page. In fact, that's what we did for our CSS'ification:
We'll ask for a formal review once we're complete (should be by Wednesday), but if you have feedback on the HTML or CSS at this point, please do speak up. We've tried to make this as lean and generically skinnable as possible.
(We're still missing some parts, including the 2-column layout for the portal.)
.LRN has a problem with very deep breadcrumb trails. A class generally has a breadcrumb trail like so:
Main Site » dotLRN » Subjects » Business Administration » MBA 101 » MBA 101
"Subjects" is a page that lists all departments.
"Business Adminstration" is a page that lists all subjects in the business administration department.
The first "MBA 101" is a page that lists all classes with the MBA 101 subject (which is typically rather meaningless, given that for most subjects, only one class will be active at any time, namely the one in the current term.
I think we'll need to tidy up this hierarchy quite a bit. Though that is a deep fix, since this is related to how .LRN mounts package instances in the site map. :(
Like the publisher's solution with the two letter codes.
I have also seen little squares with the two letter codes in them, but can not seem to find them now.
Re: Location of Language selector
I have actually watched people try to find the language selector on the present install... no luck (because it is usually off-screen at the bottom of the page and there is there is this funky language that complicates things). Need to have it in an obvious place.
I am presently living in a very diverse linguistic environment (Europahaus), which is university housing with 80% foreigners from ALL OVER THE PLACE so I can test this some more if needed.
Initial tests: top of page is where the mouse usually starts to look when there is gibberish below.
Good to hear this will be implemented in a way that will eventually give Matthias his left (or right) sidebar without removing tabs for those of us who like them (I guessed as much)
One more comment on the placement of breadcrumbs... I tend to find breadcrumbs closer to the content more useful.
Think of it like this: the thing "dropping the breadcrumbs" is the content... so the closer to the content they are the more obvious it is that they actually are breadcrumbs.
This is why I set up dotlrn.org so the breadcrumbs are right above the content and sites I implement in the future using .LRN will likely have the breadcrumbs below the tabs.
Sooo if you could keep that in mind and leave some flexibility for positioning of those little crumbs while coding it would be great.
btw: NICE WORK... and gut luck coding this.
We had to drop the drop-shadows from IE and there's still a small problem with spacing below the tabs on Opera, but we're ready to declare victory for now.
Please take a look at the HTML and CSS, and provide us with your feedback.
You're right. My bad for not keeping the header. I was trying to follow through on Bruce's advice not to make the "Classes & Communities" distinction above, and accidentally ended up with "Communities" instead of "Groups" like it is today.
I don't see "My Groups" anywhere, though. Regardless, I hope the changed version is better. Let me know if there's anything else.
Thanks! I like the new design, and even though all issues aren't resolved (are they ever?) like the My Space/Home redundancy issue, this is an attractive facelift and several steps in the right direction.
Good would be when you confirm that an action has taken place, like a blog entry posted.
Bad would be when something didn't work out, like when you type the wrong password.
The "Bad" message could be combined with the regular form error handling, so we show both the error on the form element, and the alert up to saying "There were errors on the form, please correct below" (or something slightly nicer). If there's only one error, we could name that specifically.
This would have the advantage that we train users to watch for that space, whether good or bad things happened.
On small forms it feels a bit redundant, but on large forms (where the field in error could be off the bottom of the screen) it is invaluable.
A simple generalisation is to say "please address the X error(s) below"
<blockquote> Because we at Collaboraid does find usability and navigation
important, and the notion of slapping on a pretty shell on
an otherwise unchanged product problematic, we chose to add
funds of our own for information architecture work. But we
don't have much money, so it's very limited.
Thank you very much. We want to contribute a little bit and
started work on some suggestions: