Home
The Toolkit for Online Communities
17599 Community Members, 1 member online, 3298 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Development : .LRN user interface design

Forum OpenACS Development: .LRN user interface design

Icon of envelope Request notifications

Collapse
Posted by Lars Pind on
Just a heads-up to people that we're currently doing a quick and light-weight .LRN user interface redesign. The goal is to establish the overall design and navigation, and to establish a process which we can apply to the problem of user interface design going forward.

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

/Lars

Collapse
Posted by Matthias Melcher on
I don't know where the discussion about navigation
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
  system http://openacs.org/forums/message-view?message_id=138348
- 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
http://openacs.org/bugtracker/openacs/bug?bug%5fnumber=1755

Collapse
Posted by Lars Pind on
Here are the designs for review.

http://www.collaboraid.biz/developer/blog/one-entry?entry%5fid=33512

Post feedback here, please.

/Lars

Collapse
Posted by Dave Bauer on
Lars,

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.

Collapse
Posted by Cesar Brea on
Very nice, glad to see you've pursued "less is more".  But of course my opinion is subjective without being able to evaluate the result against the design objectives as Dave suggests.

Presume compliance with such things regional equivalents of such things as Americans with Disabilities Act requirements, etc.

Collapse
Posted by Mark Aufflick on
I love it!

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

Collapse
Posted by Malte Sussdorff on
I like this, though I can only second Mark in the number of my space. Is there a need for the larger "My Space" on top of "My space home"? I assume you want to put the name of the community there, but I'm not so sure if this is really necessary (if, by default, we call the first tab "<community_name> home"). If the small "My Space" *below* SloanSpace is the breadcrumb, great. Otherwise I'd suggest to put it there. Not sure what you want to use the "My Space" for in the header, though...

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.

Collapse
Posted by Lars Pind on
Thanks for the feedback!

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

/Lars

Collapse
Posted by Guan Yang on
Imho the color scheme in those screenshots don't allow for enough contrast between background and text color.

Guan

Collapse
Posted by Jarkko Laine on
I second Guan on those "faded" texts. Unselected tabs are still ok, but the same color in the times of the calendar events is already a bit hard to read. But colors are of course easy to change. Otherwise it looks very nice.
Collapse
Posted by Torben Brosten on
I agree with Guan. Users can reduce contrast with their monitors, but maximum contrast is pretty much dictated by the color contrast.

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"

Collapse
Posted by Lars Pind on
Cambridge University kindly let me share their designs with the community.

I've posted them here;

http://www.collaboraid.biz/developer/blog/one-entry?entry%5fid=33621

/Lars

Collapse
Posted by xx xx on
I like the way Cambridge accentuates the portlet headers. It is easier for the eye when visiting the site for the first time. IMO, on Contentpages: content headers should be the first thing that catch the eye. But, this can different for a Homepage and section-Frontpage. Do you differentiate between the those?

I like your tab design though (and would probably use javascript for second-level navigation).

Collapse
Posted by John Norman on
We have not done that as it is difficult to predict how a community admin will configure the community, but I agree it would be desirable.

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.

Collapse
Posted by Steve Manning on
Not wishing to be pedantic but isn't the context bar slightly wrong on the Cambridge pages?

You Are in > My Space

should surely be:

I am in > My Space

or:

You are in > Your Space

'You are in my space' sounds like you are sitting in someones seat.

:-)

    Steve

Collapse
Posted by Mark Aufflick on
LOL :)
Collapse
18: Re: You're in my space (response to 16)
Posted by John Norman on
You're right.

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.

Collapse
Posted by Carl Robert Blesius on

Like it.

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

    Nice work.

Collapse
Posted by xx xx on
The color schemes seem good for the visually handicapped.

Can we introduce ACCESSKEY as standard attribute for links and forms (input, textarea, button, label, legend), so people can work them with the keyboard?

Collapse
Posted by Bruce Spear on
I love the tabs and would highlight them for both functional and aesthetic reasons, cutting down on the headers above them and simplifying or making less busy the type and forms below, and building a rich metaphoric universe around them.

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.

Collapse
Posted by Lars Pind on
I've posted the write-up about the rationale for the current design here:

http://www.collaboraid.biz/developer/blog/one-entry?entry%5fid=34367

/Lars

Collapse
Posted by Bruce Spear on
Thanks for the write-up, Lars!  For me, it raises a couple of compelling issues or problems, and the neat thing about problems (unlike, say, conditions) is that they can more or less be solved.

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.

Collapse
Posted by Mark Aufflick on
Bruce and Lars (and others), thankyou so much for taking the time to write up the thoughts and processes you guys are going through.

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.

Collapse
Posted by Lars Pind on
Revised design without the ID bar up:

http://www.collaboraid.biz/developer/blog/one-entry?entry%5fid=34911

Quick feedback, please. We want to start coding tomorrow ...

/Lars

Collapse
Posted by Bruno Mattarollo on
Just a quick comment regarding the "sample message" that's presented in the mockup. Will there be different color schemes for different message categories? Because in this GIF, the message presented seems more like an error message than an informational message (red background and the exclamation mark sign).

Just my two cents.

/B

Collapse
Posted by Lars Pind on
There's only going to be one color/gif for the message at this point.

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.

/Lars

Collapse
Posted by Bruno Mattarollo on
Fair enough, but since you asked for feedback :)

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

/B

Collapse
Posted by Jeff Davis on
Bruno, currently there is nothing stored for the message other than the message text itself so no way to tell if it was informational versus a warning.

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.

Collapse
Posted by Lars Pind on
Right :)

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

/Lars

Collapse
Posted by Malte Sussdorff on
Björn and myself are planning to enhance the message system to allow sending messages to users from outside the users session (e.g. "you got mail"). We could add a type to the procedure as well, which would display the message with an "id" of "message_$type" (e.g. "message_warning"). But I'm not so sure about the powers of CSS. Would it be possible to choose a different icon and colors based on the "div class id", defined in a .css file ?
Collapse
Posted by Lars Pind on
I think that, for IA purposes, we should consider putting "You got mail" type messages somewhere other than this message bar.

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?

/Lars

Collapse
Posted by Bruce Spear on
VERY nice! (I make the sign of the cross like the pope)
Collapse
Posted by Jeff Davis on
It looks good. I think I would suppress the breadcrumb if it has a single entry and matches the current url.

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.

Collapse
Posted by Nima Mazloumi on
Three thoughts:
- 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

Greetings,
Nima

Collapse
Posted by Jeff Davis on
Nima, it's a small point, but there is no reason a list needs to take up more room than a table and it's list data so presenting it as a list provides the flexibility to display it with or without indents and with or without standard or custom bullets. It's a mistake to make it a table just for presentational issues.
Collapse
Posted by Malte Sussdorff on
It would be good if we had clear CSS names for the colors like  "table_header_background" and so on, which we could change in *one* (as Nima pointed out) CSS file for the whole site (and all packages with it). Subsites and subsite types could overwrite these site wide defaults with their own CSS file. Furthermore, it should be possible to upload the CSS file for the user e.g. from the subsite parameter page (thereby not only saying: use this css file, but also allow the user to upload one for use).

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.

Collapse
Posted by Nima Mazloumi on
jeff: you are right but the list will only need the same height compared to a table if "contributed by" and "date" fields for a news item for instance don't require a new line as they do right now and rather be a column-like of thing next to the news title for instance.
Collapse
Posted by Matthias Melcher on
Although the tabs look really very pretty, they are not compatible with the idea of a "My Space" or "Home" put into one of them. If we are so much in a hurry that we can't discuss navigation nor do the user studies Bruce advocated for, we had better quickly copying what many others currently do: Put navigation/breadcrumbs in a LEFT pane, leaving a narrow (newspaper column like) reading pane in the center, and perhaps a right pane containing "ever-present" controls for concepts that are not yet sufficiently discussed.
Collapse
Posted by Lars Pind on
Dear Matthias,

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.

/Lars

Collapse
Posted by Nima Mazloumi on
Lars: if you need help with the UI redesign let me know. I am more than happy to help out.
Collapse
Posted by Dave Bauer on
Malte,

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.

Collapse
Posted by Bruce Spear on
I like the idea of this bar appearing and then disappearing (I hate popups, nagging, and poodles, don't you?), and I like this space being limited to just that bar: put other widgets elsewhere.  But may I ask you this: as you've designed it thus far: does the space where the message bar appears remain when the bar itself disappears.  I'm hoping that this space appears only when the bar appears, with the portlets moving down, and when the bar disappears, the portlets move up.  Also, how does this bar disappear? Is it timed or can you click it away?  I'm hoping it is timed as adding this click to workload would seem to me to be unnecessary extra work.  Or?
Collapse
Posted by Lars Pind on
Bruce,

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

/Lars

Collapse
Posted by Mark Aufflick on
RE: The notification bar. I think having many multiple types is a bad idea - the simpler the better.

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.

Collapse
Posted by Malte Sussdorff on
Lars, Mark, I see you point. My question now is though, where would we put a notification bar? The idea is to be able to send messages to a user using the webinterface (besides you got mail "new posting in forum x", "user y wants to chat with you, please start jabber here", aso...).

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

Collapse
Posted by Carl Robert Blesius on
breadcrumbs > tend > to > get > really > loooooooooooooonnnngggggg > and > wrap > sometimes > messing > up > the > layout.

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.

Carl

Collapse
Posted by Bruce Spear on
I like the illustration of the breadcrumbs, but I wonder how many levels we might be talking about?  This might best be answered with a query: anybody find themselves more than four levels deep? Might page names appearing in the breadcrumbs be shortened to accommodate this?  Are we talking a manageable 4 levels 99% of the time and 5 levels for sysadmins, who can be expected not to worry about it?

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?

Collapse
Posted by Lars Pind on
Funky note about switching language: The situation that we want to think about is the situation where you're seeing a page in a language which you don't understand at all, you want to have a link to change it.

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:

http://cph02.collaboraid.net:8064/dotlrn/static

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. :(

/Lars

Collapse
Posted by Carl Robert Blesius on
Re: Language Selection:
------------
The Commission
http://europa.eu.int/comm/index_en.htm
drop down

The Parliament
http://www.europarl.eu.int/home/default_en.htm
buttons

The Publisher
http://publications.eu.int/index_en.html
drop down

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.

Re: Tabs
--------
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)

Re: Breadcrumbs
---------
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.
------------------

Collapse
Posted by Lars Pind on
We're now reasonably complete with implementing the MySpace design as static HTML.

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.

http://cph02.collaboraid.net:8064/dotlrn/static.html#

/Lars

Collapse
Posted by Deirdre Kane on
Am i understanding the terminology correctly in that the "Communities" portlet will list classes and communities and that it is the same as what is currently 'My Groups'?  If so, this goes against the terminology we have been using since launching SloanSpace.  For Sloan users, they understand 'groups' as the large umbrella and "class" and "community" as types of groups, so this change will cause confusion.
Collapse
Posted by Lars Pind on
Hi DeeDee,

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.

/Lars

Collapse
Posted by Deirdre Kane on
Lars,

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.

DeeDee

Collapse
Posted by Mark Aufflick on
Regarding the deep breadcrumbs issue Lars, it seems to me that it would be reasonable to regex away some unwanted levels at certain times - like getting rid of the generic "Subjects" link once your breadcrumb is > 3 levels deep etc.
Collapse
Posted by Lars Pind on
Btw, on the message bar, I've looked around a bit and noticed one obvious pattern, which we can implement, which is to have just two types of alerts: Good and Bad.

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.

Thoughts?

/Lars

Collapse
Posted by Bruce Spear on
Lars, thanks for the thoughtful query.  As we have discussed, we developers used to have a fondness for the directness of messages like "SECURITY VIOLATION, THIS INCIDENT HAS BEEN REPORTED", but now we are at the dawn of a new, more cooperative and information age, where think the messages might better be considered in terms of dialogues with intelligent users, including beginners who want to be intermediates and intermediates who want to be advanced.  Even better are messages that offer users helpful ways out of the predicaments we would put them in because we have not designed the thing so well the error would not have been made in the first place.  So, whatever messages you might put there ought to be trustworthy, loyal, helpful, friendly, courteous, kind, obedient, cheerful, thrifty, and possibly even brave, clean and reverent.  As we have discussed, the shortest solution is the best, and so a quick message that gives me options is the best.  If the error is known, then a direct instruction towards remedy.  If not, an opportunity to survey alternatives, such as a reference to context-dependent help files. I'd think we'd also want to promise hope and deliver on that promise, and for that something like Nima's error message dialogue, where the program's diagnostic error message itself is captured on a form that the otherwise hapless user might add to suggest a nice, warm, fuzzy, cooperative relationship even the most hardened programmer would be challenged not to embrace.  In sum, I'd suggest that you think of that message bar as either an opportunity, or poetry, or both.
Collapse
Posted by Carl Robert Blesius on
I ran across some medical info in the Wikipedia that HAD to be fixed as I was looking something up and I noticed Wikipedia uses the same space at the top of the page content for both temporary notifications (e.g. "this is only a preview, and has not yet been saved") and longer term notifications (e.g. "server going down for maintenance in X hours"). A hook for longer term messages with a got-it-now-leave-me-alone button would be nice (just noting for prosperity: I realize implementation is out of scope).
Collapse
Posted by Mark Aufflick on
Lars, that model (of alerting at the top of form errors below) is exactly the model employed in a current client project, and it works very well.

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"

Collapse
Posted by Matthias Melcher on
Lars said on Jun 07 2004 09:30:17:

> 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:
http://www.rzuser.uni-heidelberg.de/~x28/uab/nav.htm
Comments welcome.