Child pages
  • Capabilities and Tools
Skip to end of metadata
Go to start of metadata

In progress...

Mapping Tools and Capabilities Between Sakai 2 and Sakai 3

This area is meant to capture some of the thinking around the shift from a tool-centric Sakai 2 to a capability-centric Sakai 3 view of the world.

  • How do Sakai 2 tool functionality map to needs for migration to or re-implementation for Sakai 3 capabilities? What about areas where there is overlap or a strong degree of similarity in existing Sakai 2 tools/services?
  • How easy will it be technically to port the Sakai functionality, including both what we think of as the underlying services and as the user-facing tools? Are there cases where starting from scratch would be a more useful approach for one, the other, or both?
  • What "tool-view" organizations of capabilities are still useful in a design-led re-imagining of the user experience for Sakai 3?
  • etc.
For Reference

> ----Original Message----
> From: [mailto:sakai-
>] On Behalf Of Ian Boston
> Sent: Thursday, February 05, 2009 1:53 AM
> To:
> Subject: sakai-kernel Re: K1 compatibility layer
> I can give you some data points on the spectrum.
> The FileManager, which is Resources Tool re-implementation works in
> Sakai3/K2 with some very minor changes to the urls. It will probably
> need some visual changes as well, but dont forget that that was just a
> first iteration in the space, that may not be compatible with Sakai3
> from a UX point of view.
> Low hanging fruit:
> Profile part of the UX and working now
> Messaging (chat, threaded discussion, comments on documents,
> personal), are either in the UX and supported or are trivial to
> implement.
> Site management, part of the UX and working now.
> Drop Box, trivial.
> Harder:
> Calendar, but I expect of be able to support CalDAV ontop of WebDAV
> Scary:
> Gradebook
> Samigo
> Local custom tools that don't fit anywhere else.
> However I am expecting Gradebook2 which is GWT based and makes heavy
> use of REST to be compatible with the Sakai3/K2
> The one think that I took away from last year is the effort required
> to re-implement with a Widget + REST approach is significantly less
> (1-2 orders of magnitude less) than server side development, which is
> why we have been able to invest more on UX work.
> and
> Mid January we had no services and no UI, and now we have an almost
> functional UI for Sakai3/K2, its missing the social networking parts
> and I suspect some tool integration.
> Ian

> ----Original Message----
> From: [mailto:sakai-
>] On Behalf Of Ian Boston
> Sent: Thursday, February 05, 2009 9:48 AM
> To:
> Subject: sakai-kernel Re: K1 compatibility layer
> Hmm, here is a guess just from the K2 point of view. The % are how
> much of the supporting functionality to create a UI implementation
> already exists in K2
> Blog - 80%, almost entirely content based, probably missing messaging
> which is in progress.
> Assignments - 80%, there are some permission management issues
> Email, 50%, needs messaging.
> News, I think there is a RSS tool there already.
> LinkTool needs porting.
> WebContent, I think it might be there already
> Search, 95% /rest/search?q=
> This does not include the UI/UX effort but I think I would categorize
> all of these at the easy end of the scale.
> Ian


Sakai 2:

  • Announcements
  • Email Archive
  • Mailtool (Mailsender)
  • Messages
  • Blogger
  • Chat Room
  • Discussion
  • Forums
  • Rwiki
  • Assignments
  • Gradebook
  • Post'em
  • Tests & Quizzes/Samigo (and Mneme)
  • Portfolio?
  • Polls?
  • News
  • Podcasts
  • Resources
  • Schedule
  • Roster
  • Section Info
  • Site Info / Worksite Setup
  • Search
  • Syllabus
  • Web Content
  • Linktool
  • Kernel 1

Sakai 3:

  • Enforced integration standards and minimum requirements across all areas (i.e., Scorecard).
  • Kernel 2
  • Assessment
  • Grading
  • Portfolios?
  • Reporting?
  • Communication
  • Collaboration
  • Content Authoring (Templates)
  • Social-Networking
  • Administration and Reporting
  • No labels