Comments on Sakai 3

I have been chained to a keyboard for most of December so I could finish the first draft of my AppEngine book before the next semester starts. So I left this on the back burner for a while. But now I am catching up.
I really like the Sakai 3 Proposal. The document does a good job of pointing out weaknesses in the current architecture and approach and lays out a good plan for addressing those weaknesses building out on the Kernel 1, Kernel 2, and the UX work to produce Sakai 3.
I also am really impressed as I played with the prototype server. The widget environment was quite nice and the new UX work is very solid – I particularly like the blend of the old and the new. I really liked how the “old tools” were given the entire width of the screen – this is something that I tried to introduce into 2.x but there was no interest. I think the future of LMS UI is to have the LMS take less and less of the screen when the students are doing their learning. We are at a point where folks *know* how to use an LMS so we don’t need to waste 1/3 of the pixels with the LMS UI drawing attention to itself and its features.
Just one funny example of how cool the UI is: I was not happy with the tool menu on the right side of the screen – I figured moving the menu from left to right was look/feel fluff that reduced usability – after using it for a while and grumping to myself – I just decided to see if I could drag it to the right – and of course I could!. I also was a bit concerned because the front page had a social gadget on it – while I like social features – it seemed that using 20% of the main dashboard for the social bits was too much – then I realized that this was just a sample – and poof! The social gadget was gone. Flexibility is *sooo nice*.
Technically – I love the switch to Jackrabbit as Content. I love rethinking Authorization influenced by Bodington. I love the notion that groups are a first class citizen and not part of a site. Sites are cool and need to be retained – but not as the container for everything else. It is better to think of pages and nodes and “nexuses” and let we teachers add site-semantics to those places we conceive as a site. Hierarchy from the get go is a big win.
The Sakai 3 Vision document clearly shows that it is based on a careful analysis of the strengths and weaknesses of Sakai 2. It is not just complaining about the shortcomings of Sakai 2 – it is providing the solutions to those shortcomings.
So overall I love it and am very confident that it will be successful in time. As one of the folks who conceived and executed Sakai 2 – and then had to live with the consequences of early decisions for a long time – I do have a few comments and suggestions to the 3akai team in terms of approach.


Start writing good design documentation. Start writing, updating, and maintaining documentation about how to install, configure, and use the system. We did this in Sakai 2 – the results are in references/docs/architecture and are the base documents that we *still* have to refer to. I generally dislike Wikis as a way to produce real documentation – people make documents in Wikis but never maintain them. The documents I am thinking about need to have all (or nearly all) discussion about the myriad of options and alternatives which were considered removed and only include what the product *is*, how to configure, how to install, and how to develop. Write these documents now while things are fresh in folks minds and while the code is being laid down.
You need to pick a UI technology and make it good. In Sakai 2 we picked JSF and had a vision of lots of reusable widgets – when we never delivered on a sufficient widget set – the whole thing turned into chaos and our current tools bear little resemblance to each other in terms of programming style. The Javascript + JSON is a fine pattern – but it needs a *ton* of documentation – and it needs to be used to build a very large piece of software – and it needs a complete widget set – or the moment that several hundred developers join in – the style will diverge to whatever hacks get each developer down their time line. Once folks go into production and need features – they will not wait several months for the official widget to be produced so they can use it.
A big key here is to keep too many schools from putting the software into production too early. When a school has put a new LMS into production – their patience evaporates. They will no longer wait for the framework to evolve to meet their needs. This means that folks will ignore the UI framework and go their own way and the UI framework will become an orphan.
Please write a complete guide to writing the Javascript + JSON pattern and hand it so someone who does not have physical access to the Cambridge mentors and see what happens. For me it is so elegant and easy while Nico looks over my shoulder – and then when Nico is not there – I get scared. The solution is not “more travel and workshops” by Nico – it is better documentation – look at Twitter and Facebook – they don’t have to come to your office and help. If the new UI development pattern is not explainable without Nico’s presense – then perhaps it needs some more work. Also it might be a good exercise to see the smallest hosting container you can build for a new-style application – and then the exercise could go even further by seeing if that environment could be embedded in some other application – say Kuali or uPortal. You would be amazed at how much functionality which fits nicely static jar files – that makes stuff a lot more reusable. Could the JSON ever be documented well enough that I could implement the same JSON and reuse the HTML/Javascript in Google AppEngine?
Regardless of the risks – you should choose one UI pattern and demand that nothing go into the core – unless it uses the pattern. Let stuff live in contrib forever rather than compromising – just tell folks that they need to improve the framework if it does not fit their needs for their tool destined for the core. Don’t bend on this – or the core will be again a mess of different approaches. If developers complain about contrib – put that energy into making the “adding stuff from contrib” process smoother and easier.
I am a little concerned with the “everything is content” theme in some of the design discussions. We had a similar mantra in 2002 – “everything is XML”. And this was probably the most painful decision that was made in early Sakai days. I fear that Jackrabbit is the new “bright shiny object” – and while Jackrabbit is going to be a superb content hosting and DAV feature for Sakai – Jackrabbit is not the best way to store a calendar which can be sorted and filtered. Jackrabbit has a much faster serialize/deserialize than Sakai1/XML – Jackrabbit has a much tighter distributed cache than Sakai1/XML. But when we wave hands and store everything in a general store and then claim that a clever distributed cache will make it fast – that is really bad. It puts a strict upper bound on the number of users / data objects that an application can handle – and once you hit that limit – there is absolutely no way forward except a complete rewrite. So I fear when announcement, calendar, assignments, testing engine, all get lumped into content. The danger is when the small team of next generation developers are trying to build new tools in a hurry in order to convince folks that it is ready for production, they take short cuts and reuse common storage solution. And things work well on the desktop for developers and be fine for 2000 user pilots on 32GB servers – but once you get to a higher level of users you are dead in the water for 6 months while you rewrite and re-test.
I am surprised that there is no discussion in the document of an approach to relational databases and some decisions about RDB technologies. Some questions come to mind that should be answered. How will we handle database portability? Right now we have a pattern which is workable but probably not ideal. Is Cayenne the answer? If Cayenne is the answer then something really nasty (such as search or Authz) should be written in Cayenne and performance/feature tested. I actually think that Aaron’s GenericDAO has some potential here. My approach to ORM is to do find a layer which will do the nasty repetitive stuff automatically but leave the scary/complex stuff to smart programmers. My ideal ORM is one that helps when it can and gets out of the way which it cannot help.
If 3akai is not going to make it possible to support SQL Server or DB2 – you should announce that right now so those folks who use those databases in 2akai can start making their cases and/or bring in resources as early as possible.
I assume that there will be “no Hibernate allowed” in the new core – if this is the decision – Yay! – it should be documented and enforced.
I am surprised that there is no discussion of database scaling in the documentation – I would like to see words like Sharding and Read-Only replication as a core part of the thinking of 3akai. To get Sakai 3 to the level of 10 million users – we will need to pull out all the stops. And there will not be time to rewrite it again – so you might as well figure this out and support it now as you lay down the lowest levels of the code and test it from the beginning.
I think that something like memcache as a first level service across all of the clusters is an essential feature for scaling – it should be built in from the beginning.
In terms of the Authoring of the pages – I like how it functions and flows. But you need to figure out how the structures I author get serialized for use somewhere else. The 2akai import and export is very weak – just barely sufficient. Please don’t make import and export an afterthought in 3akai authoring – particularly in the area of instructor built content.
Of course I have some suggestions: IMS Common Cartridge, IMS Learning Design, IMS Learning Tool Interoperability, and IMS QTI. Yeah I know it takes some time to read and understand these specs – and some of the specs need some work to make them relevant. So the likely approach will (as usual) be to build our own stove pipe and then bring standards into the process later. I know – this was the Sakai 2 approach – later just never comes – particularly when folks end up in production.
Another source of serialization inspiration is LAMS. LAMS is awesome because serialization is built in as one of the most basic aspects of the Tool Contract. Teachers can E-Mail each other their authored bits – there is a Community site (lamscommunity.org) where folks exchange bits of good learning stuff with each other. This all happens naturally when there is a decent serialization method that is placed in the hands of the teachers.
LAMS also insists that tools serialize themselves into HTML for inclusion into portfolios. This is not hard – and very awesome. If we think of the core of a personal portfolio as a personal content repository to hold my learning artifacts – this notion of serializing my student activity in a tool so I can store it and include it in a presentation later – is very very powerful. But if you don’t make this part of the rules from the beginning – it is never added on later.
It would be really nice to take a solid look at the LAMS run-time tools as to extract use cases for the new generation of tools for Sakai. LAMS run-time tools *are* already widgets – their scope is to be authored and composed together – the LMAS discussion does not have 500 features – it has 10 features – and is designed to have 4-5- threaded discussions placed throughout a learning module.
Don’t get stuck on the LAMS authoring environment and synchronous run-time – most higher education people see this and freak out (Sorry James and Ernie) – the magic bits of LAMS are the tools and tool contract. Think of Sakai’s authoring as a different way to organize and orchestrate tools that are roughly the same size as the LAMS tools. I would even go as far as to say to borrow LAMS source code – but the LAMS tools use Hibernate (Psycho noise effects) – so that is a non-starter :).
There will need to be a “workflow” for 3akai authoring and it will need to be ubiquitous and cleanly integrated throughout the authoring process. Sorry – this is *not* Kuali Workflow(tm) – this is just plain old “workflow” (lower case). This *is* IMS Learning Design – or at least some of IMS Learning Design. Don’t make the mistake of looking at IMS Learning Design and focus on the wrong thing and get all verklempt. You need to look at the lower-level bits of IMS LD – look at the triggers – look at the namespacing of information – look at the expressions for triggers – and look at how to serialize this kind of logic. Make sure that the display of authored content has a moment where it can check to see if something new needs to be shown in case something changed because of the last click.
While I am on serialization – I should put in a plug for IMS Common Cartridge. This is a damn fine spec. It has had lots of developer input and lots of implementations *before* the spec was produced. It is not hard to implement – it has a notion of content (resources) and a notion of organization that really fits how content and authoring compliment each other in the building of course / lesson materials. Common Cartridge covers a lot of good area solidly and is easily extended as needed. And if you align Sakai’s authoring with Common Cartridge – perhaps someday a publisher cartridge can just drop into a Sakai node and then we teachers can add a bit of workflow, change the organization a bit and make it our own. We would even save it and send it to someone else.
Oh yeah and with IMS Learning Tools Interoperability, the publishers won’t even mind if we teachers start sending around cartridges that point to licensed high-value content. Since LTI allows the content to stay on the publisher servers – it keeps cartridges small and legal to send around. It will take some time for this nirvana to happen – but if Sakai (in 2009) ignores these standards at the moment of a complete rewrite – IMHO that would be very short-sighted.
Grading in 2akai is done *very badly* – lets do it right in 3akai. Grading needs to be a service not a tool. There need to be many grading tools and many tools that interact with grading. The grading service needs to be carefully engineered from the ground up to meet the needs of multiple applications and the needs of moving data between the LMS and SIS. Looking at IMS Learner Information Services would be a good idea here. A lot of though has gone into grade transfer – there is more work to do – for me the first step is accepting the fact that grading needs to be a service – not a tool – and laying down that new service.
In terms of the scope of what the 3sakai core distribution consists of – be really picky and keep it really simple. I know that this is sort-of cheating – but just look at the Moodle core and have the Sakai core be roughly equivalent – of course there will be differences because the products are different – but think in terms of how “big” core Sakai is and how much configuration is needed to get core Sakai up and running. Make core Sakai useful out of the box for some nice department or individual level deployment. Moodle’s advantage is that its deploys OOTB at an individual or department level and then stuff gets added to make Moodle work for the Enterprise. Sakai starts as enterprise in its core bundle and pretty much is impossible to get it cut down to a department or individual level.
Speaking of looking at competitive products, there are a few things that I have seen as my LMS horizons have widened a bit. As I said above I like Moodle’s initial scope and install/config approach.
My favorite user interface is Angel – Angel’s UI reserves the screen real estate for the teaching and learning (not the LMS) – 3akai already is going in a similar direction and I actually prefer some UX bits of 3akai over Angel – but Angel still bears a look. My daughter uses Angel where she goes to school – and it looks very effortless for her. I like the fact that Angel has a consistent left and top navigation – for example the top navigation in Angel always has a Modules tab – this is where authoring happens – it is Angel’s Melete. Another thing I *love* about the Angel UI is that it shows both students and instructors a little graph of recent activity in the course – a tiny version of site stats. This makes the class seem alive and real – like Sakai’s presense but with richer detail.
I love BlackBoard’s building blocks – yes they are like 10 years old or some such – but they are really delightful – and with the proxy tool capability – they are even more cool. The key is that Building Blocks work through the use case of adding bits and pieces to the system. You can upload a war file to a running system and do a bunch of really really cool configuration and sand-boxing. As 3Sakai moves toward a really solid core with only the essential bits, how we expand the system will be a very important use case – take a look at BlackBoard for at least one damn fine example of how to do this.
I also mentioned LAMS above – take a look a the tools and tool contract and serialization – don’t get distracted by the authoring interface (Sorry James and Ernie).
Now that we have 3akai launched and going towards production, we need to think about what we will be doing in the 2.x branch. It will take a long time for Sakai 3 to be truly ready to take over for Sakai 2.x – so Sakai 2.x has a long life ahead of it. In particular we will need to do things to Sakai 2.x so that 2.x and 3.x can coexist together for transitions that may last 2-3 years at some sites.
So this is not the time to do any risky “improvements” to Sakai 2.x. I have heard rumors that Sakai 2.7 might get a UI “makeover”. Please do *not* do this – no no no. Sakai 2.x works – the look and feel of Sakai 2.x is not the reason for our lack of growth and with 3akai in the wings – bolting on a whole different navigation scheme just to show we can do it – will just piss off the 1.5 million or so daily users of Sakai 2.x. Put all that creative energy and resources into 3akai.
We do not want to make the Apple OS 9.0 mistake. Max OS 8.0 was awesome – at the top of its game – if you like non-premptive multitasking. Mac OS X was coming with all of its Nexty goodness. Apple OS 9.0 was a transition OS with some stepping stones towards Mac OS/X – but in introducing these stepping stones – they broke a ton of stuff and made it hard to get applications from 8.0 to 9.0 – and the end-user functionality of 9.0 was effectively unchanged as well – so there was no gain with all the pain for developers. And then Apple Mac OS/X was kind of lame until about 10.2. During the time from 9.0 to 10.2 – I switched back to Windows to avoid the bumps in Apple’s roadmap. Lets not have the same crappy transition for the Sakai community.
As a side note, the Sakai 2.5 to 2.6 transition was very nicely done – even with a major refactor of code it was very smooth – because the APIs did not change at the same time. And Sakai 2.6 does lay the groundwork for Sakai 3.0. These kinds of seamless transitions are fine – it is just a bad idea to break what is working in the name of getting ready for what is next.
We should continue to improve Sakai 2.7 – our focus needs to be on performance improvements and functionality improvements. We should go through an exercise that identifies the top 20 small features that faculty want in the existing tools and try to get some done for 2.7. Focus on faculty that *like* Sakai and use it a lot and have a small need that might be low-hanging fruit but bring big benefit. There are plenty of opportunities to improve the UX of Sakai 2.x beyond Sakai 2.6 – but lets focus on improving what we have instead of adding whole new top-level chrome just to show off.
I will close by talking about production roll-out of 3akai. I recently heard people all excited about 3akai and announcing that they will put 3akai into production on a very aggressive schedule – this scares me – particularly coming from schools who don’t currently have at least 1.0 FTE dedicated to Sakai 3. My recommendation is that no school should put 3akai into any kind of production (except non-end-user-pilots) until they have had a staff member 100% dedicated to 3akai for at least 6 months. Clearly Cambridge and Georgia Tech have been involved in the 3akai technologies form their very inception. Having Cambridge go into real production in September and GT in a serious pilot September 2009 is great.
Having two schools who have done most of the development of 3akai running it in production for a semester or two will improve the product greatly. The faculty and students will find edge cases very rapidly and as long as the Cam/GT team has spare energy to address the needs that arise – the product will get better for us all. Believe me – they will not need help from 20 other schools finding what is missing from 3akai.
If a school wants to even Pilot 3akai in the Fall – they should find a staff member *right now* and give them 100% release time and a travel budget to get *deeply* involved in 3akai for the next two years. And this person should be one of your best developers – don’t send someone just to “watch” and/or “comment” – send them to do the work – whatever work is needed. Indiana is already doing this with Lance – This is the right approach. Michigan is trying to free someone up for this assignment – until Michigan jumps in and makes a commitment to help – Michigan needs to sit on the sidelines of 3akai and watch patiently.
The last thing that a “nearly completed” framework needs is 20 schools clamoring for features because their Sakai 3 production is in crisis and the humanities department chair is pissed because there is no “sort-by-date” feature in the new resources tool. Actually the pain to the development team starts when there is even one school in production with the software that is not taking 100% responsibility for any local needs.
A nice, quiet phased approach also allows a few full-scale tools to be developed in the new UI and database pattern to work out the kinks in the framework and developer patterns while the stakes are not life or death.
Also having a slow ramp up of production allows performance of the new system to be worked out. As I said above – I fear that while the new system will likely fix the worst 4-5 performance issues in 2akai, it introduce its own performance issues that will only come to our attention in real production and really only when we get above 20,000 users. Having 10 schools all reaching 20,000 users on the same week with 3akai version 0.63 – will not be pretty.
So in summary, the 3akai effort is awesome – the right people are doing the work and the work plan and timeline laid out in Michael’s document is great (note it says that Sakai 3 will be in full swing in 2011). I think that the biggest risk to Sakai 3 is exactly what messed up Sakai 2 – getting too many schools into production effectively froze the framework research and development before the Sakai 2 work was completed. So we have limped along for the past 5 years with an incomplete framework – we have survived pretty well – but lets have the next five years be better and smoother.
My comments in this blog post are not intended to be “critical” of the effort at all. I just want people outside the development team to realize that there are many complex issues that need to be worked out and the unless the community gives 3akai time to mature *and* the community gives 3akai resources to make progress starting right now – you will end up with a partially completed framework *again*.