What we do

The simple and rather broad explanation of what we do is that: Tin Cap Apps makes educational apps.

But, as you might have guessed, there’s a more complicated and focused explanation too.

Petal diagram with petals for: Learning content; App; Learning design; Usable and Tin Can API.
Ingredients of a Tin Can App

Tin Can Apps seeks to make things that occupy the niche indicated by the intersection of all these disciplines and technologies.

Learning content

Our apps apply to the domain of education in general, which means we don’t distinguish between any sort of education be it training or academic.

Our raw material tends to be existing learning material created by academics or authors. We then look closely at this content in order to identify key or amenable points where it may be improved by the application of technology.

But it’s the case that we create completely new apps with no existing content that support traditional learning material or just gives an interesting context for it to take place.


Apps yes. But not just apps as in the things that are in an app store. We like to think of apps as just small, discrete bits of software. Things that can be (re)used, combined in many contexts. So just components really like learning objects. Small things. As said, they can indeed be apps, but web apps too and (hopefully) IoT apps also. Plugins maybe.  watchOS. Any platform / technology really, as long as we can wrestle it into good educational use.

We certainly don’t seek to make VLEs or entire courses or even just whole training modules. Pages or big software isn’t our thing. They are being done brilliantly by many many brilliant people / companies. Even if we wanted to we couldn’t compete there. We seek to make small interactive activities that embellish the main learning and sit well inside of it or by it’s side. It’s here where we’ve got an edge.


Usability is a key concept. And for us it means that the thing is usable by a user straight out of the box. There can be no learning curve to use over and above, let’s just say, a few seconds of trial and error on the part of and averagely intelligent, inquisitive, motivated user. No instruction manual here. In fact often, as a way of enforcing a good usable design, we’d ban all instructional text entirely. The only way this can be done is by keeping things simple and here simple tends to mean a massively reduced feature set. We’d rather make five small apps that do one thing well and simply than one that does it all but takes some working out. Think Unix tools.

The reason we think this kind of usability is key is that it really doesn’t seem appropriate, in the context of trying to help someone learn something, that we first make them learn to use our software. Cognitive load is a serious thing and it’s to be avoided were possible.

Accessibility is part of usability for us. If your using a screen reader we’ve got make it usable by a both a screen reader and you.

Learning design

Here’s where we start to get a bit more academic ourselves. Learning is a subject itself like maybe architecture. And like any other such subject there are existing theories on how best it can be done. So to some extent learning is a science and there are many known rules, models, or formulas that can be applied. These are approaches that have been tried and tested in both the laboratory and real life. We should use this knowledge where ever we can in the design of our apps. It will mean our apps are designed in a way that supports learning. They are themselves a thing or have features that have been proven to make learning easier, deeper and more long lasting.  But of course there’s room for some art too! and we should always being trying to disprove theories and / or make better ones?

Tin Can API

Our apps should, wherever possible, fully record actions a user takes when using them. What go done. Who did it. Where it got done. When it got done. Even why it got done. What group they are part of when doing it. Who or what states or validates what got done. How well, or not, it got done. How complete it is? An endless set of possible actions and tasks an app could record. And the way and manner an app records this data should be both compatible and interchangeable with other learning systems.

In doing this our apps can standalone outside of traditional VLEs / CMSs and yet still be used by these bigger applications for purposes of recording and grading their users learning activities. And a user can also take their personal records with them through different companies and academic institutions.

It also greatly opens up the potential for quantifying the value of learning activities as, if other systems implement Tin Can API, it becomes easier, through good learning analytics, to connect learning interventions to improved performance.

It’s the way forward and it’s done via the rather good idea of the Tin Can API. We just need to implement it in everything we do.