12.1 Open source software and the user experience in higher education  (Page 2/8)

Most of the findings in this entry are from personal reflection from my experience with the above community source projects, talking with colleagues involved in a variety of open source projects, and blogs and writing from across the web.

Delightful software in community&Open source software

When I first heard my fellow Sakai board member, CIO Brad Wheeler from Indiana University, refer to “user delight” as a strategic goal, I was slightly uncomfortable. The term “usability” is so much more utilitarian and sets a nice solid, non-evocative baseline. Don’t get me wrong, I want the BEST user experience possible, but “delight?” So I ask you, why not “user delight?” In fact, shouldn’t usable software simply be the bottom line? If we are going to be in the software development business, shouldn’t we be aiming to, at the very least, satisfy, and even better, create an experience that is welcomed — even sought after! Wouldn’t that be success?! In fact, when I step beyond my prudishness and my fear of failure, I do agree with Brad. Community and open source communities, where higher ed IT shops are striving to create superior software “by academia and for academia” are ideally positioned (at least theoretically) to achieve user delight. However, in order to do this we need to carefully examine the skills and resources and sometimes-unusual alliances that may be required to be successful in achieving this goal.

To begin, let’s be clear, poor usability in software applications is not relegated solely to the domain of open source. Many a commercial product has been slotted for demise – often prior to launch — because of poor usability. Indeed, as evidenced in many a UI listserv, UI design faces challenges in communicating its value across the spectrum of workplaces (spend a day or so on the IXDA list to observe this). Clearly usability problems are not the sole reason for what is reportedly an over 70% failure rate of software projects. But I would hazard to guess that if you are willing to broadly define usability as “a useful and satisfied user experience (UX),” and not just solely issues related to interface design, that a large portion of these failures are likely to indeed be tracked back to usability. While many of the symptoms experienced by commercial and open source development teams are similar, I expect that the solutions applied will often, and necessarily, be different in order to accommodate the cultural and organizational differences between the environments, as reflected in Eric S. Raymond’s “ The Cathedral and the Bazaar .”

I have attempted to outline some of the challenges to the development of a delightful user experience in OSS and Community Source products from the perspective of those projects coming out of higher education for higher education. Many of these issues are interlacing and multi-layered and I don’t expect to create an all encompassing list, but to at least capture a general survey of some of the salient points.

Distributed development teams — the good, the bad, and the inevitable

One of the huge benefits of developing open source products is that development can happen anywhere — and hopefully it does! In order to enable these distributed development teams to deliver in a timely manner, it is often necessary to create frameworks that allow the creation an implementation of loosely coupled tools. From many perspectives, this is a good thing to do: organizationally it allows open source teams to work efficiently (eliminate the coordination costs), and architecturally it provides much greater flexibility.