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: sakai-kernel@googlegroups.com [mailto:sakai-
> kernel@googlegroups.com] On Behalf Of Ian Boston
> Sent: Thursday, February 05, 2009 1:53 AM
> To: sakai-kernel@googlegroups.com
> 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: sakai-kernel@googlegroups.com [mailto:sakai-
> kernel@googlegroups.com] On Behalf Of Ian Boston
> Sent: Thursday, February 05, 2009 9:48 AM
> To: sakai-kernel@googlegroups.com
> 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

Notes

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