Thanks, Clay. Your answers are very helpful.
Harry On Oct 8, 2013, at 10:21 AM, 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
