Hi Harry, > 3. The "path" of a content is missing - for example, if I create a group > first and then create a discuss for the group, the discussion is shown as > https://oae.oae-qa0.oaeproject.org/discussion/oae/xJ6xhkqlX, which does not > indicate path in something like: Home-->Group1-->Discussion1, this makes the > navigation among contents counter intuitive in my opinion.
This was actually one of the major findings from a set of usability studies that was done a while back. As you say, this was particular problematic when people went from one context (e.g. group library) to another (e.g content item). A number of design solutions have subsequently been tested and providing a way for people to trace their steps back from the context they're at (based on the navigation they've been doing) came out as the strongest solution. This solution hasn't been implemented yet, but I anticipate that we'll see it show up in the next couple of months, especially now that some extra usability testing is kicking off. Hope that helps, Nicolaas On 8 Oct 2013, at 15:21, Clay Fenlason <[email protected]> wrote: > Hi Harry: > > To be clear, I am not using the OAE to support a traditional course. I am > using it to support collaboration for small team projects, for which students > happen to be getting course credit. To your more specific questions: > > > 1. SAKAI OAE used to have pages, where I can organize contents by lectures - > Canvas system has similar thing called Modules. Does current OAE support that? > > 2. without 1, we can use folders in library to try to achieve the same goal > but it seems that current OAE library does not support collections. > > One of the apparent shifts in the past year of (mostly) refactoring of the > OAE is that the 'Sakai Doc' (as we used to call the 'create a modular page' > capability) has disappeared, and a kind of collaborative note-taking doc (an > etherpad integration) has appeared in its place. It would be understandable > to interpret this as a shift in product direction, but I don't think that's > quite right. In my view we're in a transitional state where the collaborative > doc is there because it was easy for the team to do quickly and well, and we > haven't yet re-introduced the 'create a modular page' capability for the new > architecture, because that's going to need more thought. The old 'Sakai doc' > was less than a complete success, being problematic for both technical and > design reasons, and the team didn't want to just reimplement it without > working out the issues. > > So no, OAE in its current state doesn't offer much in the way of support for > organizing content, either in a page or in libraries. This broad issue is > recognized as a significant usability concern, and addressing that broad > concern with more design work and user testing is going to be part of the > project's focus for the next few months. > > As a temporary, manual workaround, the teachers in our Georgia Tech pilot are > pasting URLs to content items into etherpad pages. Which is sort of wiki-like > in concept, however clumsy. > > > 3. The "path" of a content is missing - for example, if I create a group > first and then create a discuss for the group, the discussion is shown as > https://oae.oae-qa0.oaeproject.org/discussion/oae/xJ6xhkqlX, which does not > indicate path in something like: Home-->Group1-->Discussion1, this makes the > navigation among contents counter intuitive in my opinion. > > I might be misunderstanding, but you appear to be conflating a few issues. To > help me think about them, let me try to break them out. > > a) Navigation between content items is a usability issue, some of which may > be addressed by design conventions such as breadcrumbs (which is I think one > way of interpreting your picture of 'path'). > > b) The OAE intends, at a fairly deep level, for content to not be restricted > to particular contexts, but rather to give users a variety of different > angles of approach, filtered views, opportunities for sharing in new > contexts, etc. This can lead to usability issues that stem from a loss of > context, but a design solution which anchors content to a particular context > (in the URL or a hierarchy of storage locations) may inhibit some of the > former goals. This is going to need careful thought and testing. > > c) Assumptions about user needs wrt content navigation and discovery. I'm > seeing some interesting use of the activity feeds, for example, that seem to > alleviate a certain fraction of browsing, navigation and context-setting > needs. I've also seen preliminary designs that make use of the black binding > at the upper left [1] to establish context, though I haven't seen these > designs implemented yet (maybe they were dropped for good reason). At any > rate, suffice it to say it's less than clear to me where the design focus > should be. It's tempting to jump into a narrower focus on, say, navigating > from one discussion thread to another, but then I'm not certain that users > really want or need to follow that sort of path very often. > > But I think it's right to flag this as another broad usability concern that's > going to need additional testing and probably design refinements. I'm a > little more cautious about recommending particular solutions (like your > 'path'), but expect that the team will find an evidence-based way of pinning > down the problems and working out a response in future releases. > > ~Clay > > [1] http://screencast.com/t/0OWdh6a1u > _______________________________________________ > oae-dev mailing list > [email protected] > http://collab.sakaiproject.org/mailman/listinfo/oae-dev
_______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
