Third in a series (#1, #2) of questions occupying my mind at the beginning of 2014. Which may (or may not) inform what I’ll be working on.

3) How can we program on tablets?

I’m now a tablet user. I became a tablet owner at the end of 2012. For six months I played around with it, trying a few Android programming exercises. But I only really became a regular tablet user half-way through the year. Firstly when I put Mind Traffic Control into a responsive design. Secondly when I bought a couple of e-books. And I only really got committed when I did OWLdroid and coupled that with btsync.

So – somewhat late to the party, I admit – I’m now a tablet enthusiast.

And so my question is, how the hell do I program on this thing?

There’s a trivial answer to that question : get an external keyboard, an appropriate editor / IDE and treat it like a normal computer with a small screen. I can do that. I’ve worked a lot on netbooks and small screens don’t freak me out. But that’s not really what I mean.

Because tablets aren’t meant to have keyboards. And a computer without a keyboard challenges one of my deepest held programming beliefs : the superiority of plain text.

Plain-text is so flexible, so expressive, so powerful, so convenient to work with, that I’ve always been highly sceptical of those who want to do away with it. But on a keyboardless computer, it’s a different matter. Plain text isn’t at all convenient without a keyboard.

Especially the text of programming languages which makes rich use of another dozen or so punctuation symbols beyond the alphabet and numerals. And where manipulation relies on cursor-keys, shift and control, deletes (both forward and backspace), page up and down, tab-complete etc.

And yet tablets are becoming ubiquitous. Increasingly they’re the target of our programming, and the tool we have with us. So how are we going to program in this new environment? With multi-touch or stylus but no keyboard?

I have yet to see anything even vaguely plausible as the revolution in programming “language” we’re going to need for this.

I don’t think it’s the “Scratch”-like or “App Inventor”-like “stick the blocks together” languages. The problem of programming on tablets shouldn’t be conflated with the problem of teaching novices to program. (Which is what most visual programming environments seem to be about.)

One issue with that kind of system (and other “flow-charts”) is that blocks need to be big enough to be easily and unambiguously manipulated with fat fingers. But to be decently usable, a programming system should be able to have a reasonable density of information on the screen, otherwise you’ll spend all your time scrolling and forgetting what you’ve seen. How do you resolve that tension?

Perhaps “data-flow” programming of the Max/MSP, PD, Quartz kind. Piping diagrams. Process Modelling packages have something to teach us about orchestrating in the large. But they are shockingly clumsy for certain fine-grained activities that are expressed easily in text. (Eg. how the hell can you talk about tree-shaped data or recursive algorithms using this kind of piping model?)

So I don’t have any information about who is doing interesting work in this area. (Aside : while writing this post, I thought I’d consult the collective wisdom on StackExchange. Needless to say, my question was immediately shot down as too vague.) But I’m now very curious about it.

Giles Bowkett :

This is, in my opinion, the strongest argument for seeing Unix and basic coding skills as fundamental required literacy today. As prostheses for memory and identity, computers are too useful not to use, but if you don’t know how to craft your own code which gives you a UX which matches the way you think, you’re doomed to matching the way you think to the available tools, and even the best available tools basically suck. Interaction design is not only incredibly hard to do well, it’s also incredibly idiosyncratic.

Yes. Atlas is also pretty damned cool.

I’m not, personally, quite so excited by this as I am by Bespin. But it’s nice. Particularly how you program the sizers by clicking on which edges are glued and which not. And the connection of the panels in the screen to controllers on a special bar is good.

I’m expounding my usual “late-bound” tabs model of IDEs again, over on StackOverflow.

… late binding between the buffer in the editor and actual concrete thing you’re working on, gives the editing environment more flexibility and power.

Think this is out of date? One place where the idea is back with a vengeance is in the browser, where you don’t have 1-1 correspondence between tabs and web-pages. Instead, inside each tab you can navigate forwards and backwards between multiple pages. No-one would try to make an MDI type interface to the web, where each page had it’s own inner window. It would be impossibly fiddly to use. It just wouldn’t scale.

Personally, I think IDEs are getting way too complicated these days, and the static binding between documents and buffers is one reason for this. I expect at some point there’ll be a breakthrough as they move to the browser-like tabbed-buffer model where :

a) you’ll be able to hyperlink between multiple files within the same buffer/tab (and there’ll be a back-button etc.)

b) the generic buffers will be able to hold any type of data : source-code, command-line, dynamically generated graphic output, project outline etc.

The biggest problem I’ve noticed people having with Mind Traffic Control is with delegating. They were sometimes delegating without filling in the task description (thinking that the original task description would get copied across – which it wasnt’t) or delegating to names of people which clearly weren’t email addresses (or Goggle logins).

Now I’ve trapped this. When delegating a task, it’s description gets copied (although you can still edit it), and the system also traps non-email addresses as targets to delegate to.

Keep watching …

Today’s Mind Traffic Control update.

The “defer” screen was simple, but not simple enough. Why make the user go through two mouse clicks – select a radio button and then the submit button – when this can be reduced to one? Now choosing how long you want to delay is a single button click.

I was also finding, when defering, that I wanted to remind myself of today’s date. Now I’ve just added a display of today’s date for convenience.

In general, I’m going to follow a philosophy of trying to identify and implement small improvements like this to MTC.

All suggestions welcome.