Administrivia and APIs

It was great to spend time talking with students at the #IndieEdTech/API Conversation a couple of weeks ago. Listening to their voices is something I need to make sure is a bigger part of what I do. It was both refreshing and insightful… And slightly concerning.

The concerns raised by students in various groups during the design sprint (judging by the various blog posts out there) seem to have been focussed on administrative tasks.

Finding and accessing information that has value and meaning seems to be a huge issue for university students. Navigating the complexities of our organisational design, corporate structure and responsibilities is tremendously difficult. Institutional Knowledge is simply inaccessible for most students, especially those who need it most – first in family, the under privileged, minorities and the disenfranchised – who often lack the cultural capital to seek, let alone find, information within our organisations.

I’m not sure if those working in Higher Ed realise just how complex our internal structures and systems are to navigate. Those of us who’ve been in here long enough have learnt it’s not what you know (or even where you go) it’s who you know. The fact is that the skills required to navigate the system aren’t embodied by the system, but in the tacit knowledge of those who work in it. This should be of concern to everyone involved in the system.

But it isn’t. We are failing to communicate effectice and do very little to address the administrative overload we place on staff and students – we just keep adding more. We just add another system. We just create a new department. Or rename an existing one. We restructure again. We run a project for 6 months. We create another new website but leave the old one in place. Information is constantly added but nothing is ever removed. This all becomes a burden that hinders students from focussing on their primary aim – learning!

Then there’s the language. In my organisation I think it’s possible to have an entire conversation that would be unintelligible to any outsider just by using our internal nomenclature. The effect that the casual observer may think we’re speaking in Swahili. We have so many unnecessary acronyms and seem to waste an incredible amount of time explaining them, but no desire to simplify the language in order to make it accessible. How does this help students or new staff?

There’s a massive assumption that technology actually offers efficiencies and not more administrative overheads. Every product sells itself as more efficient and more effective than what proceeded it, that everything will be faster and better. But when you measure those claims against the one constant we have – time – do they stand up? Has anything ever actually freed up more time to teach? Improved your life so much you can switch to more fulfilling tasks? Or has the amount of administration simply exanded to the point of suffocation?

I agree with this tweet, to a point – teachers can’t be replaced with technology – but how much of the technology that we’ve rolled out in the last 10 years has created more time for teachers to focus on their learners and build relationships?

The Ed-Tech industry (and the billions of venture capital dollars being fed into it) seem to assume that the problem is not the technology, but the teachers. That if we get rid of them, or automate their function we’ll somehow get a better education system.

I agree with Helen on this one – that the way forward is definitely not more technology, but less. Less faux interaction and more real ones – with actual human beings. What’s needed is to stop the need for people to the part of the technology that makes it all work, the soft malleable stuff that glues things together. Less automation of the human elements and more automation of the data itself.

Context Sensitivity

I’m always so surprised at how unhelpful our technology tends to be. Yes, our phones are connected to the internet so the world of information is at our finger tips, but why is the search prompt the primary interface of my phone? Why is it that so little information seems to actually come to me despite a myriad of data points available.

I read Bret Victor’s Magic Ink paper some time ago and I suggest you have a look as it’s thoroughly engaging discussion on this topic and not particularly technical. The abstract reads:

The ubiquity of frustrating, unhelpful software interfaces has motivated decades of research into “Human-Computer Interaction.” In this paper, I suggest that the long-standing focus on “interaction” may be misguided. For a majority subset of software, called “information software,” I argue that interactivity is actually a curse for users and a crutch for designers, and users’ goals can be better satisfied through other means.

Information software design can be seen as the design of context-sensitive information graphics. I demonstrate the crucial role of information graphic design, and present three approaches to context-sensitivity, of which interactivity is the last resort.

Bret goes on to illustrate and outline his ideas with wonderful demonstrations and cases that model the kinds of behaviour he’d like software to represent. When I reflect on many of the conversations and topics discussed at the #IndieEdTech event, particularly around the concept of the Personal API and the issues outlined above, there is a strong parallel to this paper:

  • When we talked about non-traditional students accessing a knowledge bank – it was to overcome the curse of having to interact with a system that has no understanding of your context, structures with no meaning and language that’s incomprehensible.
  • When we talked about a course handbook that contained ratings and examples of student work – it was because of how barren and decontextualised the information that students had access to when making choices on what to study and why.
  • When we talked about using Slack as a model for interaction between students, the LMS and their class – it’s because so much time was wasted navigating these systems that the purpose – actually learning – was being lost.
  • When we talked about building an API mixer – it was to empower users to take control of their data, but also to automate the drudgery of “interaction” with the glut of information systems within the university.

My experience of APIs with IFTTT has enabled me to actually reduce the administrivia I’m required to perform in my professional and personal life. I’ve programmed an auto-updating timesheet based on geo-location. I get a personal weather update based on my location at the time I’m usually getting dressed so I can make sure I’m clothed appropriately for the climate outside. The simplicity of IFTTT recipes mean that I can utilise a range of APIs to provide the Context Sensitivity to improve my experiences with technology. Technolgy begins to work for me. Imagine what would be possible for learning if we applied the same thing to Ed-Tech? APIs rather than Robots. Simple solutions rather than complex ones.

Simpilicty of Language

Another way forward is to begin to simplify the language used in universities. One of the things that I got from listening to Kin evangelising APIs was the role of language in the design process. By starting a project off with the development APIs you could actually design in a much more thoughtful way. This process of developing an API system represents the simplification of language in order to develop clearly defined functions and purposes within an organisation. It’s a document that everyone should be able to can relate to – from administrators through to designers and developers – it should be Human Readable. This process requires the functions and purposes of the Univeristy to be abstracted from the specificity of systems, and creates a more broadly accepted and accessible language from which we can all operate from. This way of working with technology can dramatically reduce the friction in terms of technical implementation – but adopting the same language would have a real impact on reducing the institutional knowledge gap that staff and students have.

Language really matters and I would love to see institutions take steps to make theirs more accessible. To go through a process of simplification in order to remove it as a barrier for learning, but also for adopting and utilising technology.

Smarten Up Dumb Technology

I’m going to keep going back to this – but for me #IndieEdTech really is about increasing autonomy and agency. Part of that is empowering users to take control over their technological footprint – to utilise the tools they want in ways that suit them.

So rather than seeking to constantly create smarter technologies, what if you simply allowed people more control over how they interacted with them? What if you provided tools that allowed users to move data between systems more easily? What if you got your internal systems to talk to each other in a shared language? What if you made systems more contextually aware? What if instead of investing millions in “better” technology you empowered your users?

I think APIs are a way in which we can do that. They don’t represent the solution, but a way to find it.


Make Your Own Slogan: MYOS and the Networked Future

When I started this post it was only a week since I submitted an abstract for the dLRN15 Conference, but the it’s taken much longer to pull this post together than I originally thought. The title of the talk that I submitted was Empowering the Node & Avoiding Enclosure and in this post I want to begin the process of sketching out some of the core motivations and ideas I’ve been having in regards to the technology for living and working in a networked world.

This is has been a process of attempting to bring together some of the ideas I’ve been dwelling over for the last year and a half about what is happening online, particularly in the ed-tech space, and alternative ways that we could do things. The ideas are very much tied into notion of networks, in particular the concept of distributed systems. I put it down on my “year ahead” post back in January as a topic that I really wanted to explore this year, so when the call for papers, and the list of speakers/organisers came out – I figured this was as good a time as any.

In the meantime Jim Groom has published a couple of posts, one & two, that share similar ideas, particularly around the architectures around how to build alternatives. Yesterday Michael Felstein also put together this great post on the EDUCAUSE NGDLE and an API of One’s Own. Both share commonalities with what I’ve been thinking in particular around APIs and an “operating system” of sorts. It’s kind of why I decided to get this post out even though in some areas it’s still only half-baked.

So what’s the problem?

The big issue that I have with the current raft of technology is centralisation. Some of the big players are working desperately towards concentrating all your data, profiles, media and personal information into their own systems (see Facebook has officially declared it wants to own every single thing you do on the internet). Commercial social media tools have given life to the idea that networks are things that can be created, manipulated, bought and sold. However,

a network isn’t a thing, but an expression of individual nodes, how they interact with each other and the relationships they develop.
The Network & Me

These enterprises do not operate as networks, but as containers. They are an explicit attempt to seize and monetise our digital endeavour by controlling the vectors through which they flow. They are closed, controlled and centralised systems that are attempting to enclose the web, the notion of commons and the ability to connect and share. Yes it will be possible, but on their terms and in their space. As the importance for digital networks grows, the tools we currently rely on are undermining their ability to function. They are becoming a medium where networks do not grow and thrive, but silos in which they become stunted and curtailed by a simple binary choice – accept or decline.

Technologies in which digital networks can thrive don’t look like the tools available to us today, or those planned for tomorrow. Not the learning management system, Facebook, LinkedIn, Twitter or Medium.

So what’s the alternative?

I’ve been a huge fan of Jim Groom & Tim Owens’ work on developing up the literature and architecture for a Domain Of Ones Own. I think that idea – a space owned and controlled by the user – is paramount in this networked age. It forms a solid foundation from which to build networks in a distributed way, rather than the centralised silos that are currently available.

I’ve been eating up information relating to domain of ones own projects and the related technologies and concepts like Known, APIs, Docker & Containers, Federated Wiki, WordPress, JSON, GIT, node.js, Open Badges, xAPI, Blockchain – because to me they all work towards developing an idea of how a domain of ones own can be transformed into an operating system of ones own. An operating system that can drive us forward into the networked age by changing the current technological paradigm to one that seeks to empower the node rather than enclose them. “Nodeware” rather than explicit software or hardware.

This platform would aim to improve the ability for each individual to connect and share with others in truly negotiated and social ways. A platform that allows us to rethink the ways in which we learn and engage with digital networks – distributed, negotiated, social, interactive and sovereign.


The genesis of this was an attempt to rethink the Learning Management System in a distributed rather than a centralised way. I was over bemoaning what the LMS is and was and so took it upon myself to think through the what a viable alternative might actually look like. If we simply reinventing the LMS we’d end up with something like the Learning Management Operating System that Feldstein and co developed. The central idea I was working on however was to provide students, rather than the institution, a way of creating content, recording learning, developing a portfolio and managing their online identity. The challenging component of this was to think beyond the standard institutional IT infrastructure and beyond a better centralised system but one that was truly distributed system. Domain of Ones Own showed that there was a viable alternative, and coupled with concepts embedded in the indie web movement such as POSSE (Publish (on your) Own Site, Syndicate Elsewhere) and the growing momentum behind APIs ideas started to form around a way to manage, mind and make your own learning:


That image was from about a year ago – the kernel of an idea was there but not necessarily the means to take it forward.

Over the new year I participated in the first Federated Wiki Happening and the experience of not only using, but embracing, a federated, socially constructed, non-linear and cooperative environment was fantastic. It opened my eyes to what could be possible if we re-thought not on the applications but the underlying technologies we used too. I loved the open nature of the federated wiki, but what I fell in love with was the concept of being an “empowered node“. The system worked in a way that empowered the individual. It provided tools and methods to create an individual identity while at the same time allowing others to connect social and professionally.

Last year I also worked on our university Badges project, and have been thinking about the potential of xAPI to capture a more nuanced and broader spectrum of learning and so have been broadening my concept of what’s possible technically and culturally.

A fortnight ago we held a workshop on how as an institution we could support Learning Technology Innovation. One of the key areas I wanted to explore with the group was APIs. So in the process of planning and putting together a presentation for the event I’ve been engaged in that space too. Just follow Kin Lane and have a play with IFTTT and you will quickly understand the power and potential that APIs offer. (PS this video offers a neat explanation of what the hell APIs are).

Welcome to MYOS

MYOS is the name I’ve given to the concept of developing a personal and social software system that provides not only the tools and technology to empower the individual in the networked age but some guiding principles about how it should enable, enhance and empower the user.

The name came from a bit of a play around with various combinations of words to describe what it would encapsulate:

  • make your own stuff
  • mind your own stuff
  • manage your own stuff
  • my online self
  • my operating system

MYOS could simply be – Make Your Own Slogan 🙂

MYOS is very much the model the Jon Udell laid out as “hosted life bits” – a number of interconnected services that provide specific functionality, access and affordances across a variety of contexts. Each fits together in a way that allows data to be controlled, managed, connected, shared, published and syndicated. The idea isn’t new, Jon wrote about life bits in 2007, but I think the technology has finally caught up to the idea and it’s now possible to make this a reality in very practical way.

Technology Foundations

There are two key technical components to MYOS – Containers and APIs.

Containers are a relatively new phenomenon and arose as part of Docker. They allow individual applications and services to be packaged in a way that can be deployed on a single server. Apps can be written in any language and utilise a variety of databases because they are contained their own package. At the same time they can talk to each other – share common layers that allow for greater integration. Containers provide a way for a variety of “life bits” to be co-located and packaged in re-deployable ways.

APIs (Application Programming Interfaces) at their most basic level allow applications to to talk and interact with other applications. APIs are the vectors through which information travels between systems. For many years they were primarily used internally with large and complex systems, but they are now emerging into the public space. They provide you the ability to cross-post between twitter, facebook, google and instagram. They allow you to push files to and from Dropbox from a multitude of applications. APIs are increasingly accessible not just to developers but to users too. Services like IFTTT allow almost anyone the ability to harness APIs to create useful “recipes” that link their own data and interactions in ways that increase effectiveness and impact.

Founding Principles

On top of those technical foundations MYOS aims to embed a number of key principles common with the Indie Web movement and help define what the system aims to do – Empower the Node:

  1. You are in control
  2. Data is yours
  3. Connections are negotiated
  4. Enhance and enable diversity

You are in control

The focus of MYOS is to empower the individual rather than re-enforce the network. Empowered nodes provide a stronger and more resilient network that is able to not only cope but thrive on change. An empowered individual is not locked in or enclosed within a single system but is free to move between them.

Data is Yours

You should always be in control of your own data. You should be able to decide who and how that data is accessed, viewed and shared. Data sovereignty is now more important than ever as we see how state surveillance and commercial enterprise has transformed private data into a commodity that is bought, sold and exploited. MYOS should ensure that any data is ultimately controlled and managed by the individual.

Connections are negotiated

In a world that relies on the network we need to ensure that democratic values are not lost. Individual choice has increasingly been eroded by the binary – Accept or Decline. We need to move beyond the autocratic rules that have come to define much of our digital lives. Connections need to be negotiated and a key way of developing that is building in a handshake mechanism that ensures transparency but also encourages users to negotiate terms that suit them. This would include being able to decide what information is shared, how it is shared, what is hidden, what is private, what is relevant, what is preferred as well as negotiating a period of renewal. This handshake could include the development of “data lifetime” clause to ensure that data isn’t kept in perpetuity, but can be removed or forgotten without the deletion or removal of the user or service.

Enhance and enable diversity

Rather than enforce a monoculture, MYOS aims to promote diversity. While there is a need for a stable core, MYOS should promote a diverse eco-system of applications. From a technical level a containerised approach enables different application built with different languages, foundations and data structures.

Making it Work

For MYOS to work it hinges on a number of cultural concepts:

Owners not Consumers

I’ve written before about my notion that society is transitioning from passive consumerism to active ownership. The current model of networks is very much on built on consumerist conventions and why much of the potential inherent in the technology has devolved into manipulative and exploitative marketing. As an alternative Ownership requires a personal investment and active participation in order to receive a reward. An owner understand that there is always risk and a cost involved, but rather than be manipulated into supporting a venture, they wish to be informed. Value needs to be demonstrated and transparent.


In a cultural capacity openness is still a fairly new and one that is continues to challenge and disrupt existing cultural modes, model and practices. Many aspects of Western culture are built on practices that install and maintain rigid hierarchies of power and exploitation that are achieved by ensuring knowledge is limited through secrets, lies and division. openness destroys those notions and instead requires trust to be created, managed and maintained through transparency and a shared experience. Openness seeks alignment rather than consensus, cooperation rather than collaboration – which tends to turn all processes into a “consensus engine”. Openness encourages federation rather than centralisation, a key tenet of MYOS.


For MYOS to ever function it requires a community, but communities don’t just happen. They require encouragement and nurturing as well as a level of active participation and contribution. Rather than being an emergent outcome of a social environment they require the result of careful fostering and cultivation. Community is the outcome of contribution, not participation. MYOS needs to be something that works with people, not for or to, and lies in the process of reclamation and liberation.

Agnostic Appropriation

Creativity is just connecting things. When you ask creative people how they did something, they feel a little guilty because they didn’t really do it, they just saw something. It seemed obvious to them after a while.
– Steve Jobs

MYOS isn’t a new thing. It’s an attempt to draw a line that connects a number of concepts that relate to our digital lives and the way we are increasingly living and working in this connected space. Movements (like the IndieWeb) and software (like Known) already provide aspects of the kinds of functions I see MYOS fulfilling. MYOS is an attempt to create a map of a networked idea.


In developing up a set of features for MYOS I started thinking about the idea of “Nodeware”. A combination of software applications, hardware and device that don’t just provide a service to the user – they empower them. They provide a rich set of tools to create, manage and maintain their online selves. Names are purely illustrative, but below is a quick list of starting features:

Identity Management – profiles and memberships
Cards – identities and personas
Keys – authorised access
Records Management – quantified self
Sash – badge display
Qualifications – certification, diplomas & degree
Shelf – web and print publications
Gallery – photos and graphics collections
Cinema – video collections
Radio – audio collections
Portfolio – assembled artefacts
Notes – ideas, notes and fragments of thought
Scrapbook – collection of the curated and salvaged

Expanded not replaced

The idea I’ve been working from is not an attempt to go and reinvent or recreate existing applications and services but to expand their features and connect them together. Open source projects make a perfect candidate for this expansion – so rather than replace Known or WordPress they can be developed in ways that integrate it into MYOS. One way that this could work is by rethinking something like cPanel and turning it into an OS level application that provides an underlying data structure and tools to connect and deploy various application via their containers.

More to come…

I’ve felt a little rushed to put this post out, but I wanted to join in the conversation not sit outside it. I’ll admit to not having everything fleshed out, or even properly specced, it’s still very much about an alternative way of thinking, designing and working with systems online. There’s a couple of posts I can see already that need to be written,in particular what the LMS and other institutional systems might evolve into when students are using MYOS. Until then I’d love to hear your thoughts and ideas.

Featured Image: flickr photo by rrruuubbb shared under a Creative Commons (BY-NC-SA) license