Three Mobile-Software Rules | Hacker News Reader

Three Mobile-Software Rules

tbray.org

39 pointswglb14 comments

> I started wondering why all software, without exception, isn’t written this way by default.

This is a very interesting question. I'm pretty sure it's pure "technical debt"; we're still so conditioned by extremely slow storage devices (the floppy is still the canonical "save" icon, remember?) that nobody questioned this sad state of affairs.

It became suddenly obvious that all and every application should continuously save its state, so that you would need to name your files only to better find them. A whole new paradigm waiting to be implemented, fully orthogonal persistence ( http://en.wikipedia.org/wiki/Persistence_%28computer_science... ).

OS X Lion will probably push this first as they apply what they learned on iPad to OS X.

Snow Leopard made the very first step toward it: when your app is in a consistent, everything-persisted-that-needs-to-be state, it can set a bit that tells the OS that it can just kill -9 it at will.

Edit: here's an article on it. It's called "sudden termination". http://www.tuaw.com/2009/09/03/mac-10-6-comes-with-license-t...

I feel like I remember Jef Raskin talking about this in his Hamane Interface book, the idea that there should be no saving and that everything should always have infinite undo (all as a goal). I might be wrong about that.

The concept of "no save/infinite undo" is definitely in "The Essentials of User Interface Design".

> It became suddenly obvious that all and every application should continuously save its state

I'm not so sure. Continuous saving is one of those ideas that sounds great until you actually do it, but then you realise that saving isn't just about persistence, it's also somewhat about marking a meaningful checkpoint in your work.

Take a look at Google Docs, for example. Open a spreadsheet, edit a few things, hey, great, I can go back to every previous edit in the history of the document. Two months and thousands of edits later, all those early edits are completely and utterly useless, but it puts a horrible drain on the UI because you don't have (for example) separate copies that you saved from when you distributed draft 1 of the sheet and when you distributed draft 2, which are the only milestones you really care about by now.

The idea isn't even that great in the short term, because any usefulness in being able to jump back to work from a couple of days ago is swamped by the awkwardness of having to navigate through every single edit you've made since then to get there. Give me a real document control system and my Ctrl+S reflex any day.

Orthogonal persistence doesn't enforce unlimited undo, nor does it forbid a "save a copy as" option. Both may make sense (or not) depending upon the task or application.

Take "Crash-Only" one step further and you get apps that back themselves up automatically. Re-install the app on your new device and it restores all of your data.

The fact that on the mobile screen there’s just not room for that stuff makes me increasingly wonder how much we really need it.

So true. It's so bad on the (normal) web these days that I often visit the mobile version even from my computer's browser.

Also:

Gosh, this notion of tying everything together loosely with addresses, data types, and a few simple verbs seems to have legs.

Sarcasm is necessary here as it's so obvious where all of this is going. We've already seen it on PCs; the web wins for 99% of all needs.

"Crash-Only" is a great approach. So, why do Android phones take a long time to power down?

No idea, but it isn't instant on my single-tasking iPhone 3G either.

I wonder why is that? I've got a 3GS and most times it takes seconds to power down and other times it can take up yo 20 seconds or so.

Power up and power down are anachronisms too. Ideally a device powers up and powers down only once it its lifetime.

I've got a Samsung Galaxy S, only takes a couple of seconds after I hit the power off item to power down.

Reply on news.ycombinator.com