Mix and match Sakai 2 and Sakai 3 tools

I am very pleased to be able to share an important update with the Sakai community regarding the ongoing efforts to create a flexible migration path from Sakai 2 to Sakai 3. I have been blogging recently [1] [2] about the development of a new Basic LTI widget for Sakai 3. This effort builds on the existing capabilities [3] of Sakai 3 which allows you to expose entire Sakai 2 sites within the Sakai 3 portal (i.e. with the addition of Sakai 3’s social networking features). The next step in this hybrid evolution was to add the capability to expose individual Sakai 2 tools within Sakai 3 sites. Furthermore, since we were developing this new capability as a Sakai 3 widget, this means that an end user could place multiple Sakai 2 tools onto a single Sakai 3 page (i.e. something not currently possible in Sakai 2). This may sound like a subtle distinction, but as you will see in the embedded video it is an important distinction as it helps to break Sakai 2 tools out of their silos. Instructors can now author pages with custom workflows that may include both Sakai 2 tools and Sakai 3 widgets!

Skip to 12:30 into the video if you want to skip the summary and background…

So now we are beginning to see a migration path for existing Sakai 2 implementations that looks like:

1. Sakai 2 for course sites and Sakai 3 for project sites.
   1. Reduced risk deployment as there is no hard dependency on Sakai 3 being available. For example, if Sakai 3 were to go down, users could easily be directed back to the Sakai 2 portal.
   2. Sakai 3 portal may or may not be the default portal (i.e. implementers choice).
2. Placement of Sakai 2 tools alongside Sakai 3 pages within a Sakai 3 site.
   1. Maintains more of a Sakai 2 user experience while allowing access to Sakai 3 capabilities within a single site.
   2. Provides a nice transition between #1 and #3 for those that find it valuable.
   3. Increases risk as now users are dependent on Sakai 3 remaining available.
3. Mixing and matching Sakai 2 and Sakai 3 tools all on the same Sakai 3 page within a Sakai 3 site.
   1. Provides the greatest flexibility for course and project site design.
   2. Provides the most “native” Sakai 3 user experience while maintaining access to Sakai 2 functionality.
   3. Custom workflows may be created with both Sakai 2 tools and Sakai 3 widgets (i.e. even if you are just exposing Sakai 2 tools, this capability does not exist in Sakai 2).
   4. Maintains same risk profile as #2.
4. Implementer’s selection…
   1. You do not need to think of the previous three deployment strategies as mutually exclusive or synchronous.
   2. You can make any or all of these solutions available to select user populations as you see fit at any time – all based on your local goals and comfort levels.

For example, one possible migration path may look like:

1. Build confidence in Sakai 3 and keep risk at a minimal levels.
   1. Deploy Sakai 3 alongside Sakai 2 with hybrid mode enabled.
   2. Continue to use Sakai 2 for course sites.
   3. Begin to experiment with Sakai 3 portal and project sites.
   4. Make Sakai 3 portal available to select user populations to validate access to Sakai 3 social networking capabilities as well as access to Sakai 2 sites.
   5. Make Sakai 3 project sites available to select user populations.
2. Make Sakai 3 portal the default portal for all users.
   1. Continue to use Sakai 2 for course sites.
   2. Expand use of Sakai 3 project sites.
   3. Develop fallback plan to mitigate dependency on Sakai 3 portal availability (i.e. you still have a fully functional Sakai 2 portal sitting there).
3. Early adopters begin relying on Sakai 3 for course work.
4. Full adoption of Sakai 3 for both course related and collaborative work.

There is a lot to consider here and to complicate matters further I predict not one migration will be identical to another. However, we hope that we have provided enough capabilities and flexibility to tailor each migration to fit the institution’s needs. Furthermore, there is a lot experience in our community in this area as almost all of us have made a similar migration in the past. This time things are a little different… This time we have direct control over both systems and can make the migration smoother.

Let’s continue the discussion in person at the annual conference. Christian Vuerings and I will be presenting on this topic in sessions titled “Integrating Sakai 2 and Sakai 3”. There will be two regular conference sessions and a technical demonstration. See you there! L

[1] http://bit.ly/9Brbdl
[2] http://bit.ly/bXVPVI
[3] http://bit.ly/bQKjlm

First experiences with ScreenFlow – very positive!

I have to admit, I am smitten with good screen-casts and when I saw the release of a new screen-casting application, ScreenFlow, I had to try it.  In the past, I have used SnapzProX and that tool has served me well.  However, there were a couple of serious limitations that have always left me wanting more:

1.  WYSIWYG – You must select your capture options, start the recording, and then do not make any mistakes!  Because you will export to a resolution lower than that of your desktop (e.g. 1440×900), you will likely choose options that limit the capture area to something more reasonable (e.g. 640×480).  Because you have to make these decisions before recording your chances of getting it wrong increase substantially.  This is a very unkind WYSIWYG – no undo – you must start your recording over if you make any mistakes.  
2. Export/Transcoding – You can only make your export selections once and hope you got them right!  You want to get the smallest file size with the highest quality encoding.  Almost certainly you will not get it right the first time.  So now what?  Record again and export again!  Not acceptable.  

I was intrigued when I read TUAW’s blog posting about ScreenFlow.  The approach ScreenFlow takes fundamentally changes the workflow I have come to know.  ScreenFlow captures the entire screen — no more trying to remember if I am in-frame or out-of-frame — just capture the desktop in its entirety and worry about zooming and panning later!  According to their web site: “ScreenFlow can handle everything from capturing DVD video & audio to fast moving Keynote presentations”.  This fundamentally changes the screen capture game and the way I think about it.

 

Okay, so the capture is great (with low CPU overhead), but the real magic happens when you start adding what are known as “actions” to your project.  Actions allow you to manipulate video and audio in post.  Callout actions allow you to draw attention to the mouse or foreground windows.  I cannot do the editing process justice; go watch the company’s screencasts to be wowed.  🙂  IMHO, this application is really top notch and represents what differentiates great Mac software from good: it is fun, easy to use, and it gives me great results.  

 

So how does ScreenFlow directly address my issues with SnapzProX?

1. WYSIWYG – friendly – because it captures the entire screen during recording, I can worry about panning and zooming in post.  If I do not like the results, undo, and try again; very forgiving.
2. Export – Since the entire capture and post processing is saved as a project, I can run multiple exports/transcodes until I get it right.  Again, very forgiving.

While I do not claim to be a pro, I submit my first screencast made with ScreenFlow for your review.  I spent about an hour on this total with three takes.  The learning curve for post processing was very low.  ScreenFlow includes screencasts that document the workflow and are very helpful.

 

XMeeting Configuration Screencast