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.
However, distributed teams introduce several UX challenges. Requirements developed in the silo of a remote team tend to focus on the requirements and business rules as expressed in that environment. For example, UC Berkeley might tend toward defining the business rules for the Gradebook based upon our campus policies rather than doing the extra work required to generalize across a wide range of institutions and global cultures. This behavior makes good local sense since as institutions we are driven by enlightened self-interest and need to ensure that we meet the needs of our local users with our local resources. However, producing a tool that only creates interactions based on the primacy of UC Berkeley's business rules often effectively lowers the ability for other schools to leverage the tools and increases the total cost of adoption.
Another UX challenge is that working in tool silos makes it difficult to create a coherent, “holistic” environment for the end-user. Many user goals are based on work flows that cut across tool sets. This has been an oft-cited usability problem within Sakai. Users don't think within the same categories and silos as the development teams work.
- 860 reads
