To Sakai or Not to Sakai on the WebSite

We are switching the web site to use Sakai – Nate Angel asked the following question:
Second: on the decision to move the Sakai website into Sakai. Can we discuss a bit before we make this move? I spend a bit of time on websites in my day job and I don’t really find Sakai to be the right tool for a public-facing website at this stage. While I love my own dogfood, I’m also a fan of the right tool for the right job.


Nate – I have moved this discussion to the web group on collab – join if you like.
We can discuss it – but at some point we need to make a decision. Using Sakai of course has many disadvantages as we can well imagine. And we could delay this forever with discussion – but now is a good time to make the switch with the webmaster transition.
Here are the pros:
(a) One less server to maintain
(b) Since it is Sakai we can involve the community in the editing and maintenance of the content. Since we will share server space and account space with collab.sakaiproject.org it will be very easy to permit community members to edit content on the site. We have never gotten community involvement in the web site in Mambo.
(c) We do not have to maintain/train a separate IT staff to maintain/upgrade/patch the web site software – Sakai is a small IT shop – the more we can reuse skills, talent, and people the better – the less we need to keep separate pools of talent that we need to replace on turnover – the better off we will be.
(d) The way we did the Sakai site previously was *very* expensive because we had so much replication.
(e) Using Sakai allows us to trivially expose things like the dev list or a document library of the QA group under s tab. Folks do not have to put things two places.
(f) Eating your own dogfood is good – even in our initial tests – we are finding and fixing little rough edges in Sakai – this will be a benefit for *any* organization that wants to make their gateway page richer. We can fix stuff very quickly because we own the code base.
Frankly, we have not been using much of the Mambo features at all – for example – I asked for a document library about a year ago and there is just not the right software in place – Sakai solves this trivially.
Also, our current site is overly complex – if you look at sites of peer organizations you will see a relatively simple graphic layout and navigation -on our current site, folks can never find what they are looking for. Sakai is quite capable of replicating a decently designed navigational structure in a top-quality look and feel. Our current navigation structure has evolved organically over time with repeated PHP hacks. I think applying a little discipline to navigation and information architecture to our website is a good thing. I also think that at times less is more. Look at peer organizational sites and see how simple they keep things for new users in particular.
We will maintain the site using the wiki to edit most of the content and iframes to display the content – you have not yet played with the anonymous workgroup portal in Sakai – but it can create a wide range of navigation structures. You can even add sub-sites and breadcrumbs. I expect that the site will ultimately look as nice as any other site on the net.
For me – unless someone steps forward with a willingness to commit do the work for the long term – I am not likely to reconsider the decision.
Frankly – I would far prefer to have intense discussion about the information architecture of the site – that is what matters the most – what software underpins the site is a trivial detail IMHO. Under “WG: Sakai Foundation Website” in the wiki – there is already some brainstorming notes about the information architecture of the site – lets try to work out what the right structure for the site should be.