You Say Tomato, I Say Tomato, Let’s Not Call the Whole Thing Off: The Challenge of User Experience Design in Distributed Learning Environments

This is a guest post by Jutta Treviranus for the On the Horizon series on distributed learning environments. Jutta established and directs the Adaptive Technology Resource Centre (ATRC) at the University of Toronto, a centre of expertise on the inclusive design of emerging information and communication technology. Jutta has led a large number of national and international multi-partner research networks (including The Inclusive Learning Exchange (TILE), the Canadian Network for Inclusive Cultural Exchange, the Network for Inclusive Distance Education, CulturAll, Stretch, Fluid and the Barrierfree project), that have led to a range of broadly implemented technical innovations that support inclusion. She has helped to develop pivotal accessibility legislation, standards and specifications internationally (including W3C Web Accessibility Initiative Authoring Tool Accessibility Guidelines, IMS Global Learning Consortium AccessForAll and ISO 24751). She is also a member of a number of key advisory panels and task forces (e.g., Accessibility for Ontarians with Disabilities Act, Pan-Canadian E-learning Strategy, JTC1 Special Working Group on Accessibility). She is the principal investigator on the Fluid Project and on the Board of Directors of Sakai. Jutta holds faculty appointments in the Faculty of Information Studies, the Faculty of Medicine, and the Knowledge Media Design Institute, at the University of Toronto.

Poor or inconsistent design and development of the UI is widely recognized as a systemic problem within academic community or open source projects and the major impediment to more widespread adoption. This problem is also a barrier to innovation – to improving pedagogy, research and administration activities within academic software. There is widespread agreement that the greatest need for innovation in this field is in the area of human interaction and support for more effective academic workflow. Cumbersome, problematic UI development processes and UI frameworks within community source software projects make it very difficult to contribute innovations.

For a number of reasons UI development in these projects is commonly left to programmers, with little input from skilled designers. It is frequently tackled at the end of the development process. Components of the UI are often developed redundantly, inconsistent across applications and inadequately tested and refined. Architectural frameworks for the UI are also inconsistent, redundant and poorly thought out.

Another challenge faced by community and open source software projects in academia is that they must address the needs and preferences of a very diverse group of users and constituents. These differences arise from institutional preferences (including branding); conventions of an academic discipline (e.g., math vs. English); cultural or linguistic differences; differences related to age, role or perspective; different teaching and learning approaches; and differences related to disability and environmental constraints. Although it is acknowledged that a consistent UI across tools and functions would greatly improve the user experience (especially when using an ever-increasing set of tools), it is very difficult if not impossible to agree upon a single UI design.

The Fluid Project attempts to address these challenges by providing a UI architecture that supports UI transformation at runtime for individual needs and preferences or during configuration for institutional preferences. This transformation is made possible by a rich, living library of reusable UI components that have been tested for usability and accessibility. The architecture and UI components work across platforms and applications. Thus each user can have a consistent, personally-optimized user experience across tools. In addition Fluid provides a toolkit of user experience design resources. Fluid is an international project funded by The Andrew W. Mellon Foundation in its second year (

One of the unexpected outcomes of Fluid thus far is that we have found ourselves at odds with common or traditional notions integral to pedagogy, software design, user interaction design, usability and accessibility.

One of the unexpected outcomes of Fluid thus far is that we have found ourselves at odds with common or traditional notions integral to pedagogy, software design, user interaction design, usability and accessibility.

The Fluid approach makes it possible to personalize the application and desktop to your individual needs and preferences. Unlike an office, desk or studio, for some reason, users do not view applications or the desktop as their personal terrain or workspace to customize to their own needs. Rather the computer desktop has become contested real estate that is controlled by:

  • advertisers and commercial interests,
  • developers who view UI design as “lipstick,”
  • designers who view the UI as a mass market generic environment that should accommodate the ‘typical’ user, and
  • institutions that want to make their mark.

The desktop is anything but a personal environment that we make ourselves at home in. Fluid must encourage users to treat the UI as their own space.

The Fluid approach to user experience design and usability testing is also at odds with standard or commercial UI design methods. These methods assume that the user really doesn’t know what is best or what they want. Users are not self-aware, what they report doing is not actually what they do and asking users what they might want does not lead to innovation because they extrapolate from what they know and are most likely to ask for a faster horse carriage than a car. Consequently the assumption is that any proposed design requires extensive user testing with objective observation and data gathering from a large number of representative users. There are several problems with this assumption and approach in community and open source academic software projects and with the Fluid approach:

  • users are too diverse to get a representative set for testing,
  • in Fluid there is no one configuration of the interface as each interface is configured to the individual needs of each user,
  • users within community and open source are much more self-aware and articulate in the methods of UI design and are not content to be studied but want to be active participants in the design.

Lastly, one of the most critical goals of the Fluid project is to address accessibility for students, instructors and administrators with disabilities. This is achieved through the transformation and aggregation of UI components to match individual accessibility needs. This approach is at odds with the legislated approach to accessibility that promotes a rule-based, one-size-fits-all solution. As where Fluid provides accessibility through a flexible system that adjusts to the individual needs of each user, the traditional approach is to adhere to a set of fixed accessibility rules for every resource or resource configuration.

In my article I hope to chronicle the new approaches we are pioneering, the pros and cons of these approaches and the valuable lessons we have learned about the user experience, how we work and learn and the collaborative process.

Share Button

Google+ Comments

This entry was posted in Ed Tech and tagged , , . Bookmark the permalink.

9 Responses to You Say Tomato, I Say Tomato, Let’s Not Call the Whole Thing Off: The Challenge of User Experience Design in Distributed Learning Environments

  1. Pingback: support communication

  2. Pingback: horizon software international

  3. Pingback: horizon software international Trendy Here!

  4. The fluid project seems to be posting some nice controls, but I’m not sure why existing projects like YUI aren’t being used. Generic GPL javascript frameworks are fantastic, and have saved me much time and effort.

  5. Pingback: special education and technology

  6. Ben Wilkoff says:

    If the UI is such a problem. Why don’t we innovate and simply create a better one. Why don’t we rely on the pedagogy of authentic learning and not on the IT background of the people who are building the back end. Anyway, thanks for your extensive post here.

  7. Nathan Garrett says:

    Ben, the post above *is* about innovating a better front-end. Could you explain what you mean by authentic learning pedagogy? I don’t understand how applies at all the post above about better UI design.

  8. Pingback: Dave’s Whiteboard » Blog Archive » Career choice, or, wherever you go, there you are

  9. Colin Clark says:


    Thanks for your comments. I’m the technical lead for the Fluid Project. We do indeed use existing JavaScript tools, jQuery in particular. It’s a fantastic tool and has saved us a lot of time and effort. We’re also sharing our work back with the jQuery community by helping to make the jQuery UI widget set more accessible.

    That said, our code plays nice with other toolkits. If you’re using YUI or one of the other great libraries out there, you shouldn’t have any trouble using them alongside Fluid components.

    Fluid components are designed to fill the gaps in existing widget sets: interactions that are flexible, accessible, and carefully designed. We’re not out to build yet another foundational JavaScript toolkit; we want to adapt and enhance wherever possible.


    I agree with you that there’s a real opportunity to create innovative new user interfaces. Our users–teachers, students, instructional designers, and so on–should definitely be an integral part of the design process. Jutta’s post touches on some of the ways we’re engaging users through research, interviews, workshops, and participatory design in Fluid.

Comments are closed.