Yesterday along with about 20 others I attended a Design Event organised by the Widg@t project, which is being funded through the current round of JISC Learning Teaching Innovation Grants (LTIG).
The aim of the day was to help the team “define the design specification for the WIDGaT toolkit, in particular the Design Decision Maker and Authoring Tool interface.” The team are planning to build a tool specifically aimed at non-techies – ” The WiDGaT toolkit (Design Decision Maker, Authoring Toolkit) aims to enable staff or students without technical expertise to easily design, develop and share widgets that support personalised learning. It enables the creation of widgets that address particularly (but not exclusively) the needs and preferences of disabled students.”
Splitting into small groups, the morning session was designed to get us thinking not about the authoring tool, but rather on designing widgets. Using the paper based design process the team had used during their previous WIDE project (see my previous post on this), each group had to create a design specification for a widget. The picture gives an idea of how the group I was in used the Design templates and flip chart to record our ideas.
widgat design template
The afternoon was then spent thinking about what kind of tool would allow people without any development experience build our, or indeed any other, widget. So we were thinking around a set of questions including:
*What would be the best way to replicate the f2f, paper supported, decision making process we had gone through?
*What kinds of interface, components and services would need to be available?
*Would templates be viable/useful?
*How would you save/share/publish outputs?
The group I was in spent quite a bit of time discussing the need to include some of the information made explicit in the Design template sheets e.g. detailed “personna” and “scenario” (basically the who, why and how of widget use). Although fully appreciating the need for them, we did wonder if they are better done offline, and if too much pre-authoring form filling might be off putting and actually slightly counter productive? We were also concerned with scope creep and very aware that the team are working to a tight timescale for development. So again we spent quite a bit of time discussing how to create an environment that gave enough options to be useful/useable, extensible to allow new functionality to be easily integrated and also, most importantly, was feasible to build.
During the feedback session it was clear that everyone in the room was broadly thinking in a similar way – particularly around the pragmatics of building a working system within the project timescale. The use of templates was also popular, as that provides a way to show users what is possible and also define an initial set of components/services.
I found the day to be very stimulating and very well structured, so thanks to all the team for their efforts in planning. As with any well designed design process, our input doesn’t stop after one day. The team are now pulling together all the ideas, reflecting on the themes emerging from the day and are going to produce a draft specification which we will be asked to feedback on before producing their final specification. I’m really looking forward to seeing how the toolkit develops and enjoying being part of a collaborative, user centred design process.