Structure and Interpretation of Computer Programmers

I make it easier and faster for you to write high-quality software.

Tuesday, February 9, 2010

On multitasking

TidBITS unwittingly hits the nail on the head while talking about iPad OS multitasking (emphasis added):

It’s easy to imagine wanting to use an iPad to read text in Mobile Safari, copy some text to a Pages document, and send that document to a colleague via Mail. That specific example may turn out to be possible with the current iPhone OS, but it points toward needing more ways for iPad apps to work together in the future.

Let me break down the user’s workflow here:

  1. User reads text in Mobile Safari.
  2. User copies text to a Pages document.
  3. User e-mails that document to a colleague.

The flow of tasks is linear. The user does not need Mail open while reading the text in Safari, nor Safari open while pasting text in Pages. Whether a platform supports multiple simultaneous applications or not, users typically work with one at a time.

The advantage of multiple open apps is that the user can switch tasks really quickly (the other oft-quoted benefit, of being able to see context in multiple places at the same time, is actually a feature of a windowing UI: a different technology, and one that iPhone OS lacks). The disadvantage is a technical one—the operating system must allocate resources to applications that the user isn’t currently working with. The iPhone (and, I presume, the iPad) provides fast task-switching anyway, through its recommendation that app developers retain app state on termination and recover it on launch. The act of moving between apps via the home screen is supposed to feel like switching tasks, even if it’s implemented by a kind of pause-and-resume.

posted by Graham Lee at 11:36  

Thursday, August 27, 2009

Indie app milestones part one

In the precious and scarce spare time I have around my regular contracting endeavours, I’ve been working on my first indie app. It reached an important stage in development today; the first time where I could show somebody who doesn’t know what I’m up to the UI and they instinctively knew what the app was for. That’s not to say that the app is all shiny and delicious; it’s entirely fabricated from standard controls. Standard controls I (personally) don’t mind so much. However the GUI will need quite a bit more work before the app is at its most intuitive and before I post any teaser screenshots. Still, let’s see how I got here.

The app is very much a “scratching my own itch” endeavour. I tooled around with a few ideas for apps while sat in a coffee shop, but one of them jumped out as something I’d use frequently. If I’ll use it, then hopefully somebody else will!

So I know what this app is, but what does it do? Something I’d bumped into before in software engineering was the concept of a User Story: a testable, brief description of something which will add value to the app. I broke out the index cards and wrote a single sentence on each, describing something the user will be able to do once the user story is added to the app. I’ve got no idea whether I have been complete, exhaustive or accurate in defining these user stories. If I need to change, add or remove any user stories I can easily do that when I decide that it’s necessary. I don’t need to know now a complete roadmap of the application for the next five years.

As an aside, people working on larger teams than my one-man affair may need to estimate how much effort will be needed on their projects and track progress against their estimates. User stories are great for this, because each is small enough to make real progress on in short time, each represents a discrete and (preferably) independent useful addition to the app and so the app is ready to ship any time an integer number of these user stories is complete on a branch. All of this means that it shouldn’t be too hard to get the estimate for a user story roughly correct (unlike big up-front planning, which I don’t think I’ve ever seen succeed), that previous complete user stories can help improve estimates on future stories and that even an error of +/- a few stories means you’ve got something of value to give to the customer.

So, back with me, and I’ve written down an important number of user stories; the number I thought of before I gave up :-). If there are any more they obviously don’t jump out at me as a potential user, so I should find them when other people start looking at the app or as I continue using/testing the thing. I eventually came up with 17 user stories, of which 3 are not directly related to the goal of the app (“the user can purchase the app” being one of them). That’s a lot of user stories!

If anything it’s too many stories. If I developed all of those before I shipped, then I’d spend lots of time on niche features before even finding out how useful the real world finds the basic things. I split the stories into two piles; the ones which are absolutely necessary for a preview release, and the ones which can come later. I don’t yet care how late “later” is; they could be in 1.0, a point release or a paid upgrade. As I haven’t even got to the first beta yet that’s immaterial, I just know that they don’t need to be now. There are four stories that do need to be now.

So, I’ve started implementing these stories. For the first one I went to a small whiteboard and sketched UI mock-ups. In fact, I came up with four. I then set about finding out whether other apps have similar UI and how they’ve presented it, to choose one of these mock-ups. Following advice from the world according to Gemmell I took photos of the whiteboard at each important stage to act as a design log – I’m also keeping screenshots of the app as I go. Then it’s over to Xcode!

So a few iterations of whiteboard/Interface Builder/Xcode later and I have two of my four “must-have” stories completed, and already somebody who has seen the app knows what it’s about. With any luck (and the next time I snatch any spare time) it won’t take long to have the four stories complete, at which point I can start the private beta to find out where to go next. Oh, and what is the app? I’ll tell you soon…

posted by Graham Lee at 00:44  

Friday, July 3, 2009

Just because Brucie says it…

Bruce Schneier claims that shoulder-surfing isn’t much of a problem these days.

Plenty of people discovered “my password” at NSConference, so I disagree :-) (photo courtesy of stuff mc).

posted by Graham Lee at 23:59  

Friday, December 12, 2008

Whither the codesign interface?

One of the higher-signal-level Apple mailing lists with a manageable amount of traffic is apple-cdsa, the place for discussing the world’s most popular Common Data Security Architecture deployment. There’s currently an interesting thread about code signatures, which asks the important question: how do I make use of code signatures?

Well, actually, it’s not so much about how I can use code signatures, but how the subset of Clapham Omnibus riders who own Macs (a very small subset, as the combination of overheating batteries in the old G4 PowerBooks and combustible bendy-busses means they don’t stay around very long) can use code signatures. Unfortunately, the answer seems to currently be “not by much”, with little impression of that changing. The code signing process and capability is actually pretty damned cool, and a nice security feature which I’ll be talking about at MacDev 09. It’s used to good effect in the iPhone, where it and FairPlay DRM are part of that platform’s locked-down execution environment.

The only problem is, there’s not much a user can do with it. It’s pretty hard to find out who signed a particular app, in fact the only thing you can easily do is discover that the same entity signed two versions of the same app. And that’s by lack of interface, not by any form of dialogue or confirmation. That means that when faced with the “Foobar app has changed. Are you sure you still want to allow it to [whatever]” prompt, many users will be unaware of the implications of the question. Those who are and (sensibly) want to find out why the change has occurred will quickly become frustrated. Therefore everyone’s going to click “allow”, which rather reduces the utility of the feature :-(.

Is that a problem yet? Well, I believe it is, even though there are few components yet using the code signature information in the operating system. And it’s precisely that allow-happy training which I think is the issue. By the time the user interfaces and access control capabilities of the OS have developed to the point where code signing is a more useful feature (and believe me, I think it’s quite a useful one right now), users will be in the habit of clicking ‘allow’. You are coming to a sad realisation; allow or deny?

posted by Graham Lee at 00:37  

Tuesday, December 2, 2008

You keep using that word. I do not think it means what you think it means.

In doing a little audience research for my spot at MacDev 2009, I’ve discovered that the word “security” to many developers has a particular meaning. It seems to be consistent with “hacker-proof”, and as it could take most of my hour to set the record straight in a presentation context, here instead is my diatribe in written form. Also in condensed form; another benefit of the blog is that I tend to want to wrap things up quickly as the hour approaches midnight.

Security has a much wider scope than keeping bad people out. A system (any system, assume I’m talking software but I could equally be discussing a business process or a building or something) also needs to ensure that the “good” people can use it, and it might need to respond predictably, or to demonstrate or prove that the data are unchanged aside from the known actions of the users. These are all aspects of security that don’t fit the usual forbiddance definition.

You may have noticed that these aspects can come into conflict, too. Imagine that with a new version of OS X, your iMac no longer merely takes a username and password to log a user in, but instead requires that an Apple-approved security guard – who, BTW, you’re paying for – verifies your identity in an hour-long process before permitting you use of the computer. In the first, “hacker-proof” sense of security, this is a better system, right? We’ve now set a much higher bar for the bad guys to leap before they can use the computer, so it’s More Secure™. Although, actually, it’s likely that for most users this behaviour would just get on one’s wick really quickly as they discover that checking Twitter becomes a slow, boring and expensive process. So in fact by over-investing in one aspect of security (the access control, also sometimes known as identification and authorisation) my solution reduces the availability of the computer, and therefore the security is actually counter-productive. Whether it’s worse than nothing at all is debatable, but it’s certainly a suboptimal solution.

And I haven’t even begun to consider the extra vulnerabilities that are inherent in this new, ludicrous access control mechanism. It certainly looks to be more rigorous on the face of things, but exactly how does that guard identify the users? Can I impersonate the guard? Can I bribe her? If she’s asleep or I attack her, can I use the system anyway? Come to that, if she’s asleep then can the user gain access? Can I subvert the approval process at Apple to get my own agent employed as one of the guards? What looked to be a fairly simple case of a straw-man overzealous security solution actually turns out to be a nightmare of potential vulnerabilities and reduced effectiveness.

Now I’ve clearly shown that having a heavyweight identification and authorisation process with a manned guard post is useless overkill as far as security goes. This would seem like a convincing argument for removing the passport control booths at airports and replacing them with a simple and cheap username-and-password entry system, wouldn’t it? Wouldn’t it?

What I hope that short discussion shows is that there is no such thing as a “most secure” applications; there are applications which are “secure enough” for the context in which they are used, and there are those which are not. But the same solution presented in different environments or for different uses will push the various trade-offs in desirable or undesirable directions, so that a system or process which is considered “secure” in one context could be entirely ineffective or unusable in another.

posted by Graham Lee at 00:45  

Tuesday, November 4, 2008

More on MacDev

Today is the day I start preparing my talk for MacDev 2009. Over the coming weeks I’ll likely write some full posts on the things I decide not to cover in the talk (it’s only an hour, after all), and perhaps some teasers on things I will be covering (though the latter are more likely to be tweeted).

I’m already getting excited about the conference, not only because it’ll be great to talk to so many fellow Mac developers but due to the wealth of other sessions which are going to be given. All of them look really interesting though I’m particularly looking forward to Bill Dudney’s Core Animation talk and Drew McCormack’s session on performance techniques. I’m also going to see if I can get the time to come early to the user interface pre-conference workshop run by Mike Lee; talking to everyone else at that workshop and learning from Mike should both be great ways to catch up on the latest thoughts on UI design.

By the way, if you’re planning on going to the conference (and you may have guessed that I recommend doing so), register early because the tickets are currently a ton cheaper. Can’t argue with that :-).

posted by Graham Lee at 14:39  

Wednesday, September 24, 2008

AppleScript, for once

AppleScript isn’t something I write much about, in fact this is the first post I’ve ever created on the topic. But AppleScript, like the Services menu and Automator, provides that most useful of usability enhancements: the ability to use multiple applications together without fulfilling the marketing requirements of having to look at them all.

As an example, a folder action script might let me combine the Finder with any other application, such as, choosing completely at random, Sophos Anti-Virus:

on adding folder items to this_folder after receiving these_items

  set theScript to "/usr/bin/sweep -nc"

  repeat with i from 1 to number of items in these_items

    set thePath to POSIX path of item i of these_items

    set theScript to theScript & space & thePath

  end repeat

  set theScript to theScript & space & "--quarantine:mode=000"

  do shell script theScript

end adding folder items to

that script then scans any file which appears in a particular folder and locks it if it contains a virus (up to a point). But that’s not really the point, the point is that I haven’t actually had to use any of the target apps in order to get this combined functionality. It’s like I was able to summon the Megazord without having to actually talk to the individual Power Rangers. Erm, or something. And that, really, is how a computer should work; I didn’t buy OmniFocus so that I could look at its icon, or a splash screen, I bought it because it can manage my lists of things to do. And I got iCal in order to manage events in time. If I have things to do at specific times, then I ought to be able to combine the two, and the computer can do the work involved. After all, that is why I bought the computer.

posted by Graham Lee at 21:01  

Monday, May 5, 2008

Social and political requirements gathering

I was originally going to talk about API: Design Matters and Cocoa, but, and I believe the title of this post may give this away, I’m not going to now. That’s made its way into OmniFocus though, so I’ll do it sooner or later. No, today I’m more likely to talk about The Cathedral and the Bazaar, even though that doesn’t seem to fit the context of requirements gathering.

So I’ve been reading a few papers on Requirements Engineering today, most notably Goguen’s The Dry and the Wet. One of the more interesting and subtle conclusions to draw from such a source (or at least, it’s subtle if you’re a physics graduate who drifted into Software Engineering without remembering to stop being a physicist) is the amount of amount of political influence in requirements engineering. Given that it costs a couple of orders of magnitude more to mend a broken requirement in maintenance than in requirements-gathering (Boehm knew this back in 1976), you’d think that analysts would certainly leave their own convictions at the door, and would try to avoid the "write software that management would like to buy" trap too.

There are, roughly speaking, three approaches to requirements elicitation. Firstly, the dry, unitarian approach where you assume that like a sculpture in a block of marble, there is a single "ideal" system waiting to be discovered and documented. Then there’s the postmodern approach, in which any kind of interaction between actors and other actors, or actors and the system, is determined entirely by the instantaneous feelings of the actors and is neither static nor repeatable. The key benefit brought by this postmodern approach is that you get to throw out any idea that the requirements can be baselined, frozen, or in any other way rendered static to please the management.

[That’s where my oblique CatB reference comes in – the Unitary analysis model is similar to ESR’s cathedral, and is pretty much as much of a straw man in that ‘purely’ Unitary requirements are seldom seen in the real world; and the postmodern model is similar to ESR’s bazaar, and is similarly infrequent in its pure form. The only examples I can think of where postmodern requirements engineering would be at all applicable are in social collaboration tools such as Facebook or Git.]

Most real requirements engineering work takes place in the third, intermediate realm; that which acknowledges that there is a plurality among the stakeholders identified in the project (i.e. that the end-user has different goals from his manager, and she has different goals than the CEO), and models the interactions between them in defining the requirements. Now, in this realm software engineering goes all quantum; there aren’t any requirements until you look for them, and the value of the requirements is modified by the act of observation. A requirement is generated by the interaction between the stakeholders and the analyst, it isn’t an intrinsic property of the system under interaction.

And this is where the political stuff comes in. Depending on your interaction model, you’ll get different requirements for the same system. For instance, if you’re of the opinion that the manager-charge interaction takes on a Marxist or divisive role, you’ll get different requirements than if you use an anarchic model. That’s probably why Facebook and Lotus Notes are completely different applications, even though they really solve the same problem.

Well, in fact, Notes and Facebook solve different problems, which brings us back to a point I raised in the second paragraph. Facebook solves the "I want to keep in contact with a bunch of people" problem, while Notes solves the "we want to sell a CSCW solution to IT managers" problem. Which is itself a manifestation of the political problem described over the last few paragraphs, in that it represents a distortion of the interaction between actors in the target environment. Of course, even when that interaction is modelled correctly (or at least with sufficient accuracy and precision), it’s only valid as long as the social structure of the target environment doesn’t change – or some other customer with a similar social structure comes along ;-)

This is where I think that the Indie approach common in Mac application development has a big advantage. Many of the Indie Mac shops are writing software for themselves and perhaps a small band of friends, so the only distortion of the customer model which could occur would be if the developer had a false opinion of their own capabilities. There’s also the possibility to put too many “developer-user” features in, but as long as there’s competition pushing down the complexity of everybody’s apps, that will probably be mitigated.

posted by Graham Lee at 20:36  

Thursday, May 1, 2008

The Dock should be destroyed, or at least changed a lot

I found an article about features Windows should have but doesn’t, which I originally got to from OSNews’ commentary on the feature list. To quote the original article:

The centerpiece of every Mac desktop is a little utility called the Dock. It’s like a launchpad for your most commonly used applications, and you can customize it to hold as many–or as few–programs as you like. Unlike Windows’ Start Menu and Taskbar, the Dock is a sleek, uncluttered space where you can quickly access your applications with a single click.

Which OSNews picked up on:

PCWorld thinks Windows should have a dock, just like Mac OS X. While they have a point in saying that Windows’ start menu and task bar are cumbersome, I wouldn’t call the dock a much better idea, as it has its own set of problems. These two paradigms are both not ideal, and I would love someone to come up with a better, more elegant solution.

The problem I have with the Dock (and had with the LaunchPad in OS/2, the switcher in classic Mac OS, and actually less so with the task bar, though that and the Start Menu do suffer this problem) is that their job basically involves allowing the internal structure of the computer to leak into the user’s experience. Do I really want to switch between NeoOffice Writer, KeyNote and OmniOutliner, or do I want to switch between the document I’m writing, the presentation I’m giving about the paper and the outline of that paper? Actually the answer is the latter, the fact that these are all in different applications is just an implementation detail.

So why does the task bar get that right? Well, up until XP when MS realised how cluttered that interface (which does seem to have been lifted from the NeXT dock) was getting, each window had its own entry in the task bar. Apart from the (IMO, hideously broken) MDI paradigm, this is very close to the “switch between documents” that I actually want to perform. The Dock and the XP task bar have similar behaviour, where you can quickly switch between apps, or with a little work can choose a particular document window in each app. But as I said, I don’t work in applications, I work in documents. This post is a blog post, not a little bit of MarsEdit (in fact it will never be saved in MarsEdit because I intend to finish and publish it in one go), the web pages I referenced were web pages, not OmniWeb documents, and I found them from an RSS feed, not a little bit of NetNewsWire. These are all applications I’ve chosen to view or manipulate the documents, but they are a means, not an end.

The annoying thing is that the Dock so flagrantly breaks something which other parts of Mac OS X get correct. The Finder uses Launch Services to open documents in whatever app I chose, so that I can (for instance) double-click an Objective-C source file and have it open in Xcode instead of TextEdit. Even though both apps can open text files, Finder doesn’t try to launch either of them specifically, it respects the fact that what I intend to do is edit the document, and how I get there is my business. Similarly the Services menu lets me take text from anywhere and do something with it, such as creating an email, opening it as a URL and so on. Granted some app authors break this contract by putting their app name in the Service name, but by and large this is a do something with stuff paradigm, not a use this program to do something one.

Quick Look and Spotlight are perhaps better examples. If I search for something with Spotlight, I get to see that I have a document about frobulating doowhackities, not that I have a Word file called “frobulating_doowhackities.doc”. In fact, I don’t even necessarily have to discover where that document is stored; merely that it exists. Then I hit space and get to read about frobulating doowhackities; I don’t have to know or care that the document is “owned” by Pages, just that it exists and I can read it. Which really is all I do care about.

posted by Graham Lee at 00:13  

Monday, April 21, 2008

Tracking the invisible, moving, unpredictable target

An idea which has been creeping up on me from the side over the last couple of weeks hit me square in the face today. No matter what standards we Cocoa types use to create our user interfaces, the official Aqua HIG, the seemingly-defunct IndieHIG, or whatever, ultimately producing what is considered a usable (or humane, if you like) interface for Mac OS X is not only difficult, but certainly unrepeatable over time.

The “interface” part of a Cocoa user interface is already hard enough to define, being a mash-up of sorts, and to differing degrees, between the Platinum HIG which directs the default behaviour of some of the *Manager controls and the OpenStep HIG which describes the default behaviour of most, if not all, of the AppKit controls. If that isn’t enough, there is an inexact intersection – some controls work differently in (what are loosely called, and I’m not getting into the debate) Cocoa apps than in Carbon apps. There have also been innovative additions on top of the aforementioned guides, such as sheets, unified toolbars and (the already legacy) textured interfaces. There have been subtractions from both – miniwindows still exist but nobody uses ’em, and window shading went west with Rhapsody.

But all of that is related to the user interface, not to user interaction (I’m in the middle of reading Cooper’s The Inmates Are Running the Asylum, I’m going to borrow some terminology but studiously avoid discussing any of the conclusions he presents until I’m done reading it). It’s possible to make HIG-compliant inspectors, or HIG-compliant master-detail views, or HIG-compliant browser views and so on. It’s also possible to make non-compliant but entirely Mac HID views, coverflow views, sidebars and so on. But which is correct? Well, whichever people want to use. But how do you know which people want to use? Well, you could get them to use them, but as that’s typically left until the beta phase you could ask usability gurus instead. Or you could take the reference implementation approach – what would Apple (or Omni, or Red Sweater, or whoever) do?

Well, what Apple would do can, I think, be summed up thus: Apple will continue doing whatever Apple were previously doing, until the Master User takes an interest in the project, then they do whatever the Master User currently thinks is the pinnacle of interaction design. The Master User acts a little like an eXtreme Programming user proxy, only with less frequent synchronisation, and without actually consulting with any of the other 26M users. The Master User is like a reference for userkind, if it all works for the Master User then at least it all works for one user, so everyone else will find it consistent, and if they don’t find it painful they should enjoy that. The official job title of the Master User role is Steve.

All of this means that even inside Apple, the “ideal” usability experience is only sporadically visited, changes every time you ask and doesn’t follow any obvious trend such as would be gained by normalisation over the 26M users. Maybe one day, the Master User likes inspectors. Then another day he likes multi-paned, MDI-esque interaction. On a third day he likes master-detail control, in fact so much so that he doesn’t want to leave the application even when it’s time to do unrelated work. Of course you don’t rewrite every application on each day, so only the ones that he actually sees get the modernisation treatment.

So now we come back to the obvious, and also dangerous, usability tactics which are so prevalent on the Windows platform, and one which I consciously abhor but subconsciously employ all the time: “I’m the developer, so I’ll do it my way”. Luckily there are usability, QA and other rational people around to point out that I’m talking shite most of the time, but the reasoning goes like this. I’m a Mac user, and have been for a long time. In fact, I might know more about how this platform works than anyone within a couple of miles of here, therefore(?) I know what makes a good application. One problem which affects my personal decisions when trying to control the usability is that I’m only tangentially a Mac person, I’m really a very young NeXTStep person who just keeps current with software and hardware updates. That means I have a tendency to inspector my way out of any problem, and to eschew custom views and Core Animation in favour of “HIG is king” standard controls, even when other applications don’t. And the great thing is that due to Moving Target reference implementation, I can find an application which does something “my” way, if that will lend credence to my irrational interface.

The trick is simply to observe that taking pride in your work and expressing humility at your capabilities are not mutually exclusive. If tens of other Mac users are telling me they don’t like the way it works, and I’m saying it’s right, apply Occam’s razor.

And if there isn’t enough fun for you in one usability experience, a bunch of us are presumably going to be providing the iPhone HIG-compliant V on top of our Ms and Cs before long.

posted by Graham Lee at 21:37  
Next Page »

Powered by WordPress