Forum .LRN Q&A: Re: My vision and priorities for .LRN.

Posted by Lars Pind on

After having spoken with a number of users and user advocates/trainers, including Carl Blesius, Bruce Spear, Hannah Wermuth (Copenhagen University), and others, over the past few weeks, I very much agree.

Bruce told me about how something as simple as the login screen confuses people. And about how he had to turn off almost all features, and help people learn how to use each feature one at a time, with much hand-holding.

That certainly suggests spending much more effort on making the features that we do have extremely easy to use, with good auomated hand-holding and help, rather than just piling on new features, when the current ones aren't good enough yet.

What should those few core areas be, though?

The ones that come to mind are the most central ones are:

- Constituents: Who are participating in a class/community, in which capacity, what can they do, which info do we have for them (street address, major line of study, IM contact information, etc.), sending email/SMS to them. (SMS is very hot around here.)

- Communications: People need to communicate. Teachers need to tell students what to study or that the schedule changed or whatever. Students need to ask and answer questions.

- Documents: Teachers need to put teaching materials online. Students need a place to share project work files with other students, as well as turn in their reports.

- Scheduling: Students need to be able to see when they have classes. Ideally, they can coordinate meetings with other students, integrating with their own calendars (Palm, Outlook, Apple iCal, Yahoo! Calendar).

We can easily add survey, curriculum, faq, news, and many others to the list, but if we want to do a superb user experience, we need to be prioritize very hard.

In addition, there are some equally important larger, structural issues:

- Navigation: People "get lost in the levels". We all know this. We need to fix it. Part of this is OpenACS, part of this is the way .LRN attaches to OpenACS, particularly the portals.

- Help system: We need to build some more hand-holding into the system. "Where can you go from here". "Things you can do that you haven't done yet". "Tips". "What can this feature do for you and how does it work".

- Consistent design: Consistent navigation and help both in the framework and inside each of the packages.

How much of this can we accomplish by when? I'm not sure. It's going to take time to do right. It's going to take involving real users a whole lot, and it's going to involve thinking outside the box.