Workflow Driven Apps Versus App Driven Workflow

Arjen Vrielink and I write a monthly series titled: Parallax. We both agree on a title for the post and on some other arbitrary restrictions to induce our creative process. This month we write about how the constant flux of new apps and platforms influences your workflow. We do this by (re-)viewing our workflow from different perspectives. After a general introduction we write a paragraph of 200 words each from the perspective of 1. apps, 2. platform and 3. workflow itself. You can read Arjen’s post with the same title here.

Instapaper on my iPhone

Instapaper on my iPhone

To me a workflow is about two things mainly: the ability to capture things and the ability to time-shift. Both of these need to be done effectively and efficiently. So let’s take a look at three separate processes and see how they currently work for me: task/todo management, sharing with others and reading news and interesting articles (not books). So how do I work nowadays for each of these three things?

I use Toodledo for my task/todo management. Whenever I “take an action” or think of something that I need to do at some point in the future I fire up Toodledo and jot it down. Each item is put in a folder (private, work, etc.), gets a due date (sometimes with a timed reminder to email if I really cannot forget to do it) and is given a priority (which I usually ignore). At the beginning and end of every day I run through all the tasks and decide in my head what will get done.

For me it important to share what I encounter on the web and my thoughts about that with the rest of the world. I do this in a couple of different ways: explicitly through Twitter, through Twitter by using a sidebar in my Browser, in Yammer if it is purely for work, on this blog, through public bookmarks on Diigo, by sending a direct email or by clicking the share button in Google Reader.

I have subscribed to 300+ RSS feeds and often when I am scanning them and find something interesting and I don’t have the opportunity to read it at that time. I use Instapaper to capture these articles and make them available for easy reading later on. Instapaper doesn’t work with PDF based articles so I send those to a special email address so that I can pick them up with my iPad and save them to GoodReader when it is convenient.

“Platform” can have multiple meanings. The operating system was often called a platform. When you heavily invested into one platform it would become difficult to do any of your workflows with a different platform (at my employer this has been the case for many years with Microsoft and Exchange: hard to use anything else). Rich web applications have now turned the Internet itself into a workflow platform. This makes the choice for an operating system nearly, if not totally, irrelevant. I regularly use Ubuntu (10.04, too lazy to upgrade so far), Windows Vista (at work) and iOS (both on the iPhone and the iPad). All of the products and services mentioned either have specialised applications for the platform or are usable through any modern web browser. The model I prefer right now is one where there is transparent two-way synching between a central server/service and the different local apps, allowing me access to my latest information even if I am not online (Dropbox for example uses this model and is wonderful).

What I have noticed though, is that I have strong preferences for using a particular platform (actually a particular device) for doing certain tasks. The iPad is my preference for any reading of news or of articles: the “paginate” option on Instapaper is beautiful. Sharing is best done with something that has a decent keyboard and Toodledo is probably used the most with my iPhone because that is usually closest at hand.

Sharing is a good example of something where the app drives my behaviour very much: the app where I initially encounter the thing I want to share needs to support the sharing means of choice. This isn’t optimal at all: if I read something interesting in MobileRSS on the iPad that I want to share on Yammer, then I usually email the link from MobileRSS to my work email address, once at work I copy it from my mail client into the Browser version of Yammer and add my comments. This is mainly because Yammer (necessarily) has to be a closed off to the rest of the world with its APIs.

Services that create the least hickups in my workflow are those that have a large separation between the content/data of the service and the interface. Google Reader and Toodledo both provide very complete APIs that allow anybody to create an app that accesses the data and displays it in a smart way. The disadvantage of these services is that I am usually dependent on a single provider for the data. In the long term this is probably not sustainable. Things like Unhosted are already pointing to the future: an even stricter separation between data and app. Maybe in that future, the workflow can start driving the app instead of the other way around.

The Future of Moodle and How Not To Stop It (iMoot 2010)

Yesterday morning I got up at 6:30 to deliver a presentation at the very first virtual Moodlemoot: iMoot 2010. All in all it was a hugely enjoyable experience. I had people attending from among other the United States, Ireland, Zambia, Australia, Japan.

The platform for delivery of the session was Elluminate, which worked flawless. I am still amazed at the fact that we now have easy access to the technology that makes a virtual conference with a worldwide audience possible.

My talk was titled “The Future of Moodle of How Not to Stop It”, an adaptation of the book by Zittrain.

The Future of...

The Future of...

I first recapped the recent discussion about the death of the VLE:

I showed how Moodle was conceived and developed when the web was less mature then it is now (the social web as we know it was basically non-existent) and how a teacher can create a learning experience for his or her students using nothing but loosely coupled free tools. Horses for courses.

I then looked at the two mental models that Moodle could adapt from Drupal:

  1. Drupal’s tagline is “Community Plumbing”. I believe Moodle’s could be “Learning Plumbing”.
  2. Drupal sees itself as a platform. This is exactly what Moodle should reinvent itself as.

In the final part of the presentation I looked at how the new Moodle 2.0 API’s (repository, portfolio, comments and webservices) will be able to help make the shift towards a platform. I finished with asking people to imagine what an appstore for repository plugins and what an appstore for learning activities would look like.

The slides are on Slideshare and embedded below (you can also download a 2MB PDF version). The session has been recorded. Once that recording comes online, I will update this post and try and share that here too.

The one difficult thing about a virtual conference, by the way, is communicating the dates and times. Timezones add a lot of complexity. iMoot, for example, provides users with a custom schedule for their timezone and replays each session twice after the live event. I am starting to believe in the Swatch Internet Time concept again. Wouldn’t a single metric .beat not be great? See you @850!