Rather than keeping up an individual blog for myself, I'm now posting my thoughts on teaching and technology within the blogs for the projects I'm currently working on. These are:

Arcadia Fellows blog, Cambridge University Library
http://arcadiaproject.blogspot.com/

CourseTools project blog, CARET, University of Cambridge:
http://coursetools.caret.cam.ac.uk/project-blog

It always seems to me that one of the great disadvantages to working in a University is all the clever people. No matter how obscure you make your software, there'll always be someone who manages to figure it out - and then you've got real users that you actually need to support.

OK - I'm being tongue-in-cheek here, but I genuinely do think we have a lot to learn from the wonderful hardware and software designed for the primary classroom. For a start, software for kids has to have interfaces which make sense. (Jakon Nielsen has put to rest the myth of the 4-year olds who can understand software which baffles adults.) But the software out there for schools also seems to be incredibly diverse and creative, in a way that HE software isn't.

Interactive Whiteboards are a particular interest of mine (why are they ubiquitous in schools and almost unheard of in universities?), but, for example, perhaps the long-term development of RWiki could be influenced by this - essentially a visual Wiki (if that's not a contradiction) for kids. Kids can create their web pages visually, dragging and dropping pictures and words around the page - but the best bit is that they can watch what the others in their class are doing on their own computers at the same time. It seems to me that this is both enjoyable (I tried it out - it's great fun!) and, more importantly, offers real potential for collaborative learning. But the real strength of the product, in my opinion, is that the design / development team thought hard about the teaching objectives, and then considered how the users - the 5 or 6 year olds - could achieve those objectives with an interface that helps, rather than hinders them.

Perhaps my new year's resolution should be to imagine that, among those Nobel Prize winning Professors and sky high IQ students, there are a few 5 or 6 year olds eager to learn...?

Spellchecker included in Firefox 2

Now, the readers of this blog probably know all about this already - but for those who don't, the new version of the Firefox browser comes with an in-built spellchecker (on PCs only, unfortunately). In fact, it's checking this posting as I make it, and has so far objected to 'blog', 'Firefox', and (rather ironically) 'spellchecker'.*

This is just what the lecturers and students at Cambridge have been asking for - now lecturers writing lecture notes directly into the Wiki, for instance, see instant spell checking (see screenshot below).


Say goodbye to the misspellings in Worksite Info or Announcements which make lecturers blush with shame - Firefox 2 is bringing us a brighter and better-spelt world for 2007.

So let your Sakai users know about this, and lets close REQ-410!





* But that's okay as I can add them to the dictionary...

RSF, nuanced tools and the implications for support

Faculty members love to personalise their teaching sites: they like to sprinkle them with pictures and, more importantly, use precisely the right terminology ('Professional Tutor' not 'Personal Tutor', 'Colleagues' not 'Roster'). With RSF, (some) Faculty members will have the power to change terminology, buttons, messages, options... to create the page which is just right for them.

However, what are the implications for IT support staff helping students use a system where we can't predict what a button might be called - or even if it is a button rather than a link? What do we do about our Help Manual, or our Help Videos? In fact, we're already starting to see this problem at Cambridge with the inbuilt Sakai Help Manual - where we've changed tool names (often on a course-by-course basis) to fit in with University custom, but haven't (or can't) update the Help files.

It may be that page redesign is kept more strictly under control - or that Faculty members are asked not to re-name or move certain buttons. Or perhaps it will place much more emphasis on creating an intuitive user-interface in the first place - and in placing clear but brief instructions on the page itself, which are updated with a page redesign. Watch this space...

Diving in to RSF - an instructional designer's viewpoint

An online learning environment developed by many Universities, such as Sakai, has huge potential advantages for us - but so far Sakai has achieved cross-University use at the expense of the nuances of learning in different institutions. Often, it seems, tools don't work in quite the way that follows our teaching practice. But of course, it's not just different Universities which take different approaches to teaching, but the Departments and lecturers within each University. The goal of the RSF web-framework (at least from my viewpoint) is to support a genuinely nuanced approach to teaching, where each Department can have its own subtly different front-end to a tool. But will it work in practice? This was what the RSF bootcamp aimed to find out...

The theory of RSF is that a UI designer can create the HTML for a tool and then go away, safe in the knowledge that a tool will come back which looks and works just like their description. The RSF bootcamp took 4 participants (and a few extra who got roped in at various stages) and aimed to go from requirements gathering to fully-fledged tool in a weekend. Would it work?

Participants:

• me, Harriet Truscott - instructional designer at University of Cambridge. Gathered requirements, designed UI.
• bootcamp leader, Steve Githens - programmer (and supervisor) at Northwestern University, in Chicago
• RSF designer, Antranig Basman - programmer at University of Cambridge, and inventer of RSF (www.ponder.org ).
• programmer, Andy Thornton - programmer at University of Cambridge, and writer of the Sakai RWiki tool.

The tool:

We needed to find a tool which could plausibly be re-written in RSF over the weekend, and which would have some distinct benefits from being redesigned. A lot of discussion took place over what this should be, but finally Drop Box was picked as being fairly small, offering a starting point into looking at Resources, and having room for improvement. In fact, I already had some requests for improvements to Drop Box specifically for Cambridge users. (And with the magic of RSF, anyone at another University can redesign the interface to fit their needs better, so we don't need to worry about what other Universities might want, so long as we cover the functionality.) Our new version of Drop Box was re-named Pigeonhole, as that's what we call the tutors; mail boxes in Cambridge.

Friday afternoon:

The tool to work on was agreed, and we then set to work rethinking the functionality. We already had a few requests for this and descriptions of problems. Steve had used Drop Box in his teaching, as had Dan from CARET, who gave us his ideas from his experience. We also looked at the functionality in Blackboard. DropBox wasn't in our previous system. We would have liked to have seen the Boddington and Moodle UI and functionality, but didn't have access to a system at the short notice. We used an Interactive Whiteboard (Smartboard) for a first rough design, which worked excellently - we were able to annotate and save screenshots fast and efficiently.

Friday evening:
I did the first set of UI mockups using Fireworks, and Steve and I went through a short paper-prototyping session which brought up a couple of bits of missing functionality. By the end of Friday, I had UI mockups v. 2 to turn to HTML. These mockups seemed to meet the needs from Steve (working with classes of 600 students), Dan (classes of 3 students), and the Faculty of Education (groups of 60 students).

Friday night:
Some sort of coding went on. I was asleep.

Saturday morning:
I grabbed the opportunity to go through the UI with Richard Kirby of Credit360.com (specialising in software for large companies to track and monitor data). He had a lot of useful feedback and suggestions for improved functionality - some of it rather out of scope for a weekend, but all useful thoughts. Thanks, Rich!

Saturday afternoon:
Met up with the programming team and did the HTML version of our UI screens, which was quick and easy. There were a few UI refinements to make (mainly because classes of 600 need something different to classes of 5 or 20 which we're more used to!) but so long as all the fucntionality was in, the templates could be followed, and I got to go home.

Sunday morning:
By now, the first functionality had appeared. Steve had to leave to get his plane, but I had a quick tour of where we were up to. The RSF templates were very similar to my original HTML - or rather, they were identical except for having extra RSF tags in the HTML. We still have some tweaks to make to the UI, but of course we can do this with no problem (or at least I hope so).

We had an interesting debate about the merits of XML/XSLT versus RSF for restyling- I think Pigeonhole could be a real test-case for this, so we'll see how it devel0ps.