31 January 2016 On opening up my apps.

It's been rather humbling creating the all-new website that launched today, though maybe "tumbled out" might be a better word than "launched". At 07:50 my old site was zapped and by 08:00 the new site was working wonderfully till, at 08:05 I found that it had a catastrophic problem. At 08:10 I nervously applied a fix that I hoped would solve the problem and by 08:15 I was happy that the site was basically OK. What could possibly go wrong? Well, from 12:00 to 13:05 (which is when my wife came home expecting Sunday roast to be served) I was cooking and debugging as best I could, with the amazing Sean sorting out some problems that arose from an "improvement" to the site infrastructure. In the early evening it was the same story about an "improvement" causing things to go backwards. But by 20:05 the site was stable and I could leave it to settle down and start to write this blog.

Although I am the first to admit that I don't have much sense of design and was happy for Sean and James at Three&me to create a new layout, I'd assumed that my knowledge of web design wasn't too bad. After all, I was on my 3rd or 4th Prof Steven Abbott website, I was using Responsive Design and had all sorts of Javascript tricks behind the scenes.

But when confronted with people who really knew what they were doing, and who had no problem telling me the many ways in which my old design was, well, a bad design, I had to admit that my web skills were way behind the times.

So after some intensive weeks of re-writing, where they would tell me what to do, give me some working examples so I could do the grunt work, one outcome was that I was much fitter. Their office is a short bike ride from my home/office, but it's up hill all the way back. And although we work extensively via email and GitHub, there's no substitute for face-to-face activity to sort out really tricky issues.

The decision to use GitHub was inevitable but painful. For some reason, my brain just doesn't "get" how GitHub works. It's a marvellous system whereby multiple people can work on the same code in parallel, often making changes to code that is being changed in other ways by co-workers. Then via a series of pushes, merges and pulls, the different elements can be recombined to a new, clean version from which we can all start to make further changes. There are millions of people using it and maybe I'm the only one too stupid to be comfortable with it. Though, in my defence, any system that uses a command line in the 21st century has to have something seriously wrong with it. Thank goodness for SourceTree that makes it vaguely possible for someone like me to see what's going on.

But GitHub is the future. All my apps have been extracted from the web pages and are basically stand-alone. This isn't obvious to anyone looking at the website who cares to view the page source. But the magic of PHP means that stand-alone apps are sucked in to the page where they are needed, just as if they had been written (as in my previous versions) as part of the page. Why is it important for the apps to be essentially stand-alone?

Open apps in GitHub

Here's the plan. Once the new site has truly settled down, I'll put all the standalone apps onto open GitHub so that people can

  • Use them for their own purposes
  • Spot bugs, make improvements
  • Create wholly better ways to achieve the over-riding aim which is to expand users' understanding and to help users to solve problems
  • Help find ways for non-experts to appify their technical knowledge.

It is the last two elements that interest me most.

Better interactions with the technical knowledge

I have had a clear idea of apps being inputs, calculations and (usually) graphs plus some output values. The scheme works well compared to the usal alternative which is to have no interactive input/output, just a set of words, formulae and graphs that most of us don't really understand.

But just as I was fairly pleased with my web "design" skills till shown how out-dated they were, I'm sure there are bright young scientists/programmers who could show myself (and others) a much better way to do what I am doing.

For example, lots of smart people use d3.js to make much more powerful representations of data. However hard I try, I can't make d3.js do anything other than produce slightly nicer graphs. I just don't "get" how to make my inputs and outputs more lively. Similarly, I look at people like Bret Victor who can do awesome coding with inputs and outputs and try to imagine (without much success) how my apps could be much more alive.

Appification of knowledge

I find it astonishing that everyone isn't appifying their knowledge. How could one not want others to be able to interact with their expert knowledge in something like an app? However behind the times I am with web sites and app skills, I find that I am ahead of the majority of the scientists I happen to know who have almost zero knowledge of Javascript or HTML5 (even when they are wizards at high-powered technical computing). So if I want this approach to expand, I've got to make it easier for someone with the will, but without the skills, to make it happen. This means semi-automating app production and, maybe, having a coding resource to hold the scientists' hands to get a properly functioning app ready for the outside world. This isn't so hard. But it's not being tried seriously, and not, yet, by myself.

The first steps

So, how will I go about opening the apps and finding bright new minds who will want to help me do things better? I don't know. But I do know that re-creating the website, doing it via GitHub and having the apps GitHub ready is the first step of the journey. The second step is to say in public that I intend to use this GitHub route to change the game when it comes to appification of technical knowledge. The third step? I have little idea, but for the moment I'll take it one step at a time and having already taken two steps, I'm already on my way.