The Ed Techie

Stringle 2.0

Having shown you Stringle, I thought it'd be interesting to think what else it would need to be a usable tool.

Here's my thoughts:

Tools –

A good range of tools that users can select from. Tony's working on this, so you should have a range to select from and can simply drag them into your toolset and give them a label (thus avoiding all that del.icio.us and URL stuff).

Easy way of adding new tool - if you come across a tool then you want to be able to add it simply by clicking a button. If we were providing students with a university social bookmarking tool, then this could be done easily.

Toolset related to resource - I think this would be quite powerful. If you select a particular tool then it has some metadata associated with it which automatically loads in the appropriate tool(s). Thus if you're doing a timeline activity the only tool available is a timeline, if you're doing a collaborative activity then maybe a discussion board and IM tool are displayed.

Content

Easy add - as with tools, you don't really want people to mess around with OPML managers, so you need a neat way of adding content in.

Icons - next to the links in the grazr widget it would be good if you can identify different types of resources, e.g. activities had an icon or were styled a particular way.

Enterprise -

Authentication - you're going to need some way of allocating roles and resources to individuals, which means all the tedious but mission critical stuff around linking with student record systems, assigning roles, security, etc.

Tracking - this is essentially dumb integration. If you really want to do tracking you need to know what people are doing in each of the tools. This might be insoluble if you want to allow an open system.

Usability - it's no oil painting at the moment and definitely could benefit from some good interface design.

Of course, you may be asking yourself 'why bother? Why not just use Pageflakes?' (or something similar). There may be something in this, but what impresses me is the way a system can be configured quite easily. More on this in the next post.

Stringle - almost a web 2.0 PLE?

Tony Hirst visited me yesterday in Cardiff and we spent the day going through his String n Glue VLE (Stringle). I'll split up my posts on this, so in this one I'll do a quick users guide, then I'll look at what else it needs in another post, and finally some thoughts.

Before we get stuck in I ought to just say that there is a bit of clunkiness about this, and the immediate reaction might be 'most students are not going to do this.' Which is true, but a lot of this clunkiness could be removed with a bit of resource and programming (e.g. creating a button that automatically adds a resource). I'll come back to this in the next post, but for now, assume it could all be made easy.

You will need a del.icio.us account and an OPML manager (e.g. from http://www.opmlmanager.com/) in place before you start.

Go to Stringle at http://ouseful.open.ac.uk/stringle2.php

You'll see a list of tools across the top like Docs, whiteboard, etc. Clicking one of these will load the tool in to the Tools tab in the central frame.

One the left there is a list of content. Clicking on one of these will open the content in the Web tab in the centre (or you can add in a URL in the box at the top and it will display it).

And that is essentially it - you have your tools at the top and your content down the side. Both are configurable, so let's start with the tools.

Say I want to add in a scheduler tool, like Remember The Milk. You need to bookmark the site using del.icio.us (any social bookmarking tool could be used but for demo Tony has opted for the best known one). You need to tell Stringle it is a tool, and to do this you use the tag stringle:tool You can create clusters or categories of tools, which you can load in to Stringle at different times. So for example you might have a collection of collaborative tools. Lets say I group my Todo tool in with admin tools. I would then add in the del.icio.us tag by leaving a space and adding 'admin'. Now I want to tell it what text to put along the top in Stringle, so I add another tag, say 'stringle:Milk'.

Now I want to load my admin tools in to Stringle. To do this I add in some text after the URL - ?t=del.icio.us name/category name. So in my case I would add in ?t=mjweller/admin to give the url http://ouseful.open.ac.uk/stringle2.php?t=mjweller/admin

Okay I said it got a bit clunky, but this could all be automated. Now let's add some content in to the left hand panel, which comes courtesy of Grazr. To do this you'll need to go to your OPML manager. If you are in OPMLManager, then right click on the main folder and create a sub-folder. Let's say I'm creating a course on Evolution, so I'll add in a folder with this name. As I discover different resources I can add them in here using the add link function. These can be sites, rss feeds, podcasts, etc.

Once you've built up your collection of resources, you want to import it in to Stringle. This requires URL jiggery-pokery again. This time add ?oURL for OPML feed so in my case it would be ?o=http://www.opmlmanager.com/opml/mweller.opml giving the URL http://ouseful.open.ac.uk/stringle2.php?o=http://www.opmlmanager.com/opml/mweller

Now we can of course combine the two to give my toolset and my content -

http://ouseful.open.ac.uk/stringle2.php?o=http://www.opmlmanager.com/opml/mweller.opml&t=mjweller/admin

It may be a bit buggy still (especially in IE Tony tells me), but you get the idea. That's the boring stuff, I'll look at what else could be done to it in another post.

Outsourcing learning technologies

This article in the Economist Consumer technologies are invading corporate computing (via George Siemens) outlines how some universities are effectively outsourcing a lot of technical development, using the Google Apps for your domain bundle. The guy says that "Compared with the staid corporate-software industry, using these services is like “receiving technology from an advanced civilisation”, says Mr Sannier."

A couple of things on this - firstly there is often a delay between the rhetoric and the reality when new ideas come along. The whole service oriented approach was one of these. I found myself wisely telling everyone to think of everything as a service, without really being sure what this meant. Google have continued to demonstrate what this really means, and this is a good example. It's not about buying a big bit of kit for your IT guys to install, you simply say 'all our students get the Google services.' Secondly, it really does mark something of a watershed that universities are now formally recognising these consumer, real world apps and not insisting that somehow education is special and needs to develop its own tools. Thirdly, what sort of impact does this have on institutional practice? As a small example, at the OU we have struggled with a calendar project for a while (partly it isn't a calendar project but a multiple database problem), but at what point would it be effective to say 'hey, go with Google'. What the institution needs to concentrate on then is making data available in the right format. It's kind of analagous to educators needing to shift their focus from creating content to supporting understanding.

Stephen Downes' visit

Stephen Downes came to the OU today and gave a talk on PLEs. We had a chance to chat beforehand, and his talk was, as ever interesting and thought provoking. I felt that his vision of a PLE, although it steered clear of the client based talk I have seen in other ones, was very much based around an individual and their collection of resources. I didn't see much room for collaboration in it. I queried him on this and he responded that the resources should include community and peer resources and tools such as Skype would be included. I can see how this would be neat (and as I have blogged before, I like the netvibes personal portal approach to collecting tools) - however it still makes collaboration difficult if we all have different tools. If you have Skype and I have Trillian, how do we conduct a collaborative activity?

VLEs are often criticised because they provide a blanket provision, but the benefit of this is that you can get on with doing the task in hand, safe in the knowledge that everyone is using the same system. This is part of my problem with PLEs - the problem they report to solve is not so great as to require the massive technological and cultural change it would require. For instance in order for a PLE to be most effective we need interoperability between all tools, and for universities to become a thing of the past, or at least how we think of education to alter radically. I'm not sure either of these is likely to happen in the near future. What I do like about PLEs is that they force us to think about learners as being in the technology world, and not technological tabula rasa. I don't think higher education has even begun to grasp what it means to have the net generation entering their ranks. But I still have my doubts about PLEs - I think I may just be lacking that visionary thing.

Institution vs individual environments

Have just completed writing for a course on eportfolios. I remain a bit sceptical on these, at times they seem little more than a set of prepared fields for web publishing. In terms of academic practice they can be seen as part of a general shift from the institution to the individual. Along with blogs, social bookmarks, individual portals, etc the emphasis is less on providing students with all their ICT requirements and rather on incorporating their existing tool set into the institution. This viewpoint sees its apotheosis with the Personal Learning Environment (CETIS PLE Project). Now if I had doubts about eportfolios, they are nothing compared to the ones I have regarding PLEs.

The not inconsiderable problems a PLE would need to address are:

1. Support. The support issues for an institution and educators would be extremely complex if each user had a different set of tools, and so would most likely be passed on to the individual. One of the reasons why current VLEs have been successful is that they allow universities to centralize support and thus ensure a certain level of competence and quality of experience.
2. Quality assurance. Increasingly universities need to ensure a certain quality of provision. This would be difficult to maintain and predict if everyone is using different tools.
3. Suitability. While the learner-centric notion has much about it which is admirable, we should also be aware that sometimes the student is not the best judge of what is the best approach. In this context this could mean they continue to use a tool when a different one is better suited to the purpose, or they are not exposed to new technologies.
4. Negotiation of activity. Although the choice and flexibility in this approach is a strength, it could also create a significant overhead in negotiation. For example group activities would be difficult to achieve if everyone used their own tools. While there may be some standardization and compatibility between systems (e.g. different IM clients may be able to communicate), this is difficult to envisage between different categories of systems e.g. IM and asynchronous tools. Therefore there would need to be negotiation between students as to which tools to use.
5. Technological complexity. Although the service oriented approaches and standardization will help, it would still be an enormously complex task to enable the range of different tools to integrate with those systems required by an institution, and even more problematic if one has to assume a novice user

What the PLE work reveals and acknowledges is the growing use of technologies by learners. VLEs are often operating on an assumption of zero experience and competence (which is the safest thing to do, and for some students, valid). Higher education has not really begun to address the implications of Prensky's ‘digital natives’ coming in to the higher education context with familiarity and loyalty to a number of different technologies.

The tension here is between institutional and individual technologies. VLEs are an institutional response to the opportunities of the internet. Most of the newer tools are based around the individual. The eportfolio is a good example of this tension. Many universities are beginning to develop or buy institutional eportfolio systems, so that they provide all students with this tool and use it in specific courses and for institutional aims, e.g. as a means of assessment. However, the eportfolio is an individual tool and one of the main drivers behind them is their ability to collate information and learning across institutions. So, should an eportfolio be a tool that a user brings to an institution or one that an institution provides for everyone? Of course, interoperability goes some way to solving the dilemma, since it means data can be ported between applications, but it is unlikely to be the complete solution, and many of the problems with the PLE outlined above, such as support and guaranteed level of provision will remain.

Some of the implicit and explicit criticism of current VLEs that is found in the PLE work is valid, but this does not necessarily mean that the PLE is the solution. Some of the complaints, for example the ‘one size does not fit all’ claim could be addressed by making VLEs better, either in terms of pedagogy or customization. One could envisage a rich set of tools being offered to students via VLEs, with customizable and personalized feeds, interfaces and tool selection, which would go some way to achieving the aims set out for PLEs.

Clients are the new flares

I spent some time in a session on Personal Learning Environments recently. The issue of PLEs aside, what intrigued me was that most of the talk focused on the development of rich, desktop clients.

In fashion they say if you stay still long enough, trends will come back around to where you are. This is true with educational trends also I guess, so for some it seems that clients, like flares, have come around again. Some of you will remember the early e-learning days where you had a plethora of different clients for each functions - email, discussion forums, online simulations, etc. Then the web came along and the web browser became the ubiquitous interface. This was a significant step forward and was partly responsible for the phenomenal growth of internet usage in the nineties. Now you could use any browser to access most of the functions you wanted to perform online. This is very useful if you log in from different locations, as you don’t need to rely on multiple versions of different software clients being available. It also means you can integrate different tools as they are operating within the same browser framework. However, there is often a loss of richness and speed in using a web version of a system compared to the dedicated software client.

With PLEs the fashion seems to have come full circle again, and the talk is now of rich, desktop clients once again. Two reasons are put forward as the main advantages of this approach, one of which I feel is valid, and the other less so. The first, more powerful argument is the ability for the user to create a rich environment with complex functionality, which would be difficult to achieve through a web browser. The software is housed on the user’s machine, and not located remotely on a server, which means that the transactions are quicker and the level of control greater.

The second argument put forward is that a client allows the user to work offline, since the connection with the server is not required. While this is important for users sometimes, it is something of a red herring. Most users can easily arrange tasks for periods when they know they will be offline, for example downloading documents for reading. It runs counter to the trend in society for almost ubiquitous connectivity. There may be times when you want to take your mobile device to the top of a mountain to study, but these are not so frequent as to necessitate the massive development and cultural effort that a PLE-oriented system requires.

If I had to back a winner here I'd go for ubiquitous connectivity and browser interface (maybe with some thin clients), over the rich desktop client.