If you’ve been using the subversion repository, please switch over to github as soon as you can. I believe this will be much better for everyone, and ensure MGTwitterEngine has a long useful life ahead of it.

If you’ve already made a fork of MGTwitterEngine, please contact me – I’d love to add you as a repository collaborator and get your changes into the main codebase! You can contact me via github, or find my contact details here.

I hope MGTwitterEngine continues to be useful to you. I plan to move some of my other projects over to github according to demand and as time allows.

Before we start, let me assure you: all of my Cocoa source code which has been free and open source up until now will continue to be free and open source. This is a discussion regarding future code only, and indeed only a subset thereof. It’s an additional avenue, not a change of policy. I also very strongly hope that response to this post won’t turn into a debate about whether “all code should be free”, and such – I’m a very prominent contributor to the open source community for the Mac and iPhone, and I think my position in that regard speaks for itself; this isn’t intended to be a philosophical debate about software freedom-as-in-anything.

As a self-employed software engineer, I understand the value of my time. I not only have an hourly rate, but I also grasp the value of getting ahead of a schedule, or being able to meet an aggressive schedule without having to compromise functionality or vision. The idea of paying others for quality source code is something I find very easy to accept and understand.

If I can pay $150 and get something that really does fit my needs, and it would save me more than a couple of hours of my own time, then it’s clearly a win in terms of time and money. I’d be crazy not to pay for it. That’s as true for compiled software as it is for source code, and it’s also just as true (for the right return on investment) if the code costs $5,000.

You might have to be more selective with source code (because unlike with apps, there’s often a clear dividing line between what fits the bill and what’s useless to you) but the general value proposition is similar.

For whatever reason, there are only a handful of people selling code components on the Apple platforms. I suspect that’s less about the market and much more about perceived worthiness; we do all tend to collectively reinforce the perception that only the very best stuff will do, and it’s incredibly difficult to convince yourself your code is even worthy of being open source, much less paid for in its raw form. I’ve had to twist the arms of so many Mac developers to convince them that they have a component worth sharing with others.

I have a component (as usual, it’s a GUI-focused piece of code; something visual) in the works right now for iPad, and I’m planning to make the code available for licensing to use in your apps for a fee. I think it’s important to test the market and see if there’s interest, and if it can be a viable part of my overall business. I’ll be giving more details in due course, including showing demos, sharing API documentation and so forth.

I’ve been thinking about how to approach the licensing/payment, and have had a few discussions on the matter with friends and colleagues. It all boils down to two main issues: pricing, and what you get for your money. I have a few thoughts on this.

Source must be included

I would very rarely buy a precompiled component. Sure, if it’s a situation where the specific algorithm or integration is what you’re paying for and you’d conceivably rarely (if ever) want to tweak it (barcode scanning, talking to a piece of specialist hardware), then maybe.

Generally, though, what you’re paying for is an API where the implementation and behaviour is important, and needs to be up for inspection and modification – at least as a last resort. I would always feel far more secure if I had the code. I’d thus almost certainly want to sell the code, rather than just a library or framework.

Price perception is important

The pricing of source components is all over the place; it varies incredibly wildly. Entry-level is in the tens of dollars, and you can also readily pay many thousands. There isn’t a direct relationship between type of component and price, and there’s no clear model. My personal impression is that pricing based on the actual number of hours you’d need to spend creating it yourself (times some average hourly rate) is largely fantasy; for anything non-trivial you’re immediately in the thousands of dollars range.

I think there’s a major psychological barrier towards paying that amount unless you can pass the cost directly to a client or your company. I also feel that the majority of the market for iPad/iPhone and Mac are small shops, and often individuals. They’re not going to pay for multi-thousand-dollar components. For well-designed (visually, and every bit as importantly but considerably more rarely, architecturally) GUI components with a reasonably general use scenario, I think the ideal entry-level price point is probably somewhere around the $150-200 range.

I’m not certain about that, but I do know that going much lower very quickly puts you into pointless territory. At some point, you have to target those who understand the value of their own time, and are willing to spend money to make more money.

Tiered licenses

I think that pricing at a single flat rate is unrealistic, even though it’s unarguably a bonus for the buyer. We don’t price software at a flat rate (you buy a license to use it on a fixed number of machines, often one), and we don’t price our consulting services at a flat rate in that sense (if multiple clients want the same piece of work done, they each pay for that work; albeit perhaps at a reduced rate if you have a pre-made component of your own and choose to offer such a discount).

The question is how to tier. Historically, components have been priced per “developer seat”, whatever that really means in practice. Bigger companies pay more by virtue of the fact they’re bigger companies. I don’t think that model works on these platforms; there are just very few big companies, but a huge number of very small companies each selling multiple applications. I think that the right model thus becomes per-app.

My gut says that a three-tier system would fit the bill:

1. The base tier which almost everyone will go for, perhaps allowing use in just a single application.
2. A middle tier allowing use in up to a certain small number of apps, which covers the bulk of the market (most people release only a handful of apps). This would be priced as a very small multiple of the base tier.
3. A top, premium tier which constitutes an unlimited license. Rarely if ever purchased, but fair in those situations.

And naturally, you offer upgrades at any time by simply paying the difference.

These are all difficult issues, but I think this is an area that we shy away from, and it’s needlessly hindering a legitimate and healthy part of the software industry on our favourite platforms. We’re all already clients of each other’s professional services, and customers for software, so there doesn’t seem to be any reason that selling code components wouldn’t at least be viable.

I’d love to hear your thoughts on any of this, either via the comments here, on Twitter (I’m mattgemmell), or in an email (my contact details are here).

The actual topic of discussion isn’t particularly germane to my point, but suffice to say that it concerned a situation where Xcode (the development environment for Mac and iPhone/iPad programming) wasn’t doing anything to assist in a very common situation where you’d want to choose one of two possible courses of action, due to an underlying feature of the programming language used.

In probably more than 80% of cases, one particular choice would be made. My point, of course, is that Xcode ought to default to the most common choice, but transparently allow overriding that choice if the other option was needed.

Many people readily agreed, but there were two other types of response which stood out. They were:

• Xcode can’t know for certain which choice you want.
• It’s not Xcode’s fault anyway, because it’s due to an underlying feature of the programming language.

Both these responses illustrate what I call engineer thinking, and it’s something that’s both understandable but also incredibly damaging to the user experience of software. (A brief note is appropriate here to say that I’m a software engineer myself; I’m not just pointing fingers.)

Engineering in the real world has taught us (usually the hard way) about tolerances and precision. The axle must be of uniform strength, the furnace must run at a controlled temperature, the structural properties of supporting columns must be carefully designed. Reality tells us that being exacting, and producing the same outcome each time, is the key to not only reliability but even to feasibility itself. That’s all well and good, and has given us our civilisation.

But a problem arises when you allow precision-based design principles to hinder user experience. All too often, when faced with a decision about how to implement certain functionality, engineers take the extreme position that:

1. A feature must be exactly what 100% of users want.
2. If the above isn’t true (and it almost never is), the feature must be configurable.

This binary approach is gravely wrong, and unjustly offloads decision-making onto the user of the software. We’ve all seen where this approach ends up: multi-row sets of tabs, scrolling panes of checkboxes, nested radio-buttons and a general overload of configuration.

It has become increasingly difficult to avoid choices in our daily lives, to an extent which many of us find intrusive and counterproductive. Buying coffee in a shop you’re not familiar with leads to momentary paralysis as you work out how to convey the fact that you just want a regular, black filter coffee. This isn’t the way forward.

From the user’s perspective, there is always a default. The engineer will then argue, correctly, that different users will have different opinions as to what that default should be, but here the Universe steps in and reminds us that there’s always a “usual way”. There is always one particular behaviour or configuration or setup which suits more people than any of the others (surprisingly often, there’s one which suits more people than all the rest put together). That is your default behaviour.

The existence of uncertainty is not an excuse for exposing it to the user.

It is software’s responsibility to mask uncertainty and to make the effort to provide a sensible default behaviour. Many users will care more about the fact that there is a default than what the default is. Choice means decisions, and decisions mean effort and second-guessing, and loss of focus and time. The best choice in software is a choice which has already been made for you, invisibly.

There are of course situations where choice is needed, as indeed in the case which spawned this discussion. The key realisation is that there are different ways to present choice. Too often, we’re given choice as a first resort; instead, present choice as a last resort. If the user must be able to choose, then let them do so by overriding a sensibly-chosen default behaviour – and ensure that such situations are as rare as you can make them.

Software cannot just wash its hands of issues of technical complexity or uncertainty; it’s not remotely OK to simply offload that work to the user. Software intended to help with a given task has an implicit expertise; we assume that our photo-editing software knows more about photo-editing than we do. Expertise carries a duty of care whereby the expert is expected to provide the benefits of expertise without the full cost of knowledge. That’s why experts are useful! The same holds for software.

The primary expression of expertise is in knowing effortlessly what the right course of action is in a given situation, and carrying it out without micro-management or endless justification. Make your software such an expert, and a guide and assistant to the user. Don’t force the user to make your software’s decisions for it, or to repeatedly bow down before its keen grasp of the vagaries of choice and uncertainty.

It all comes down to a question of art. Our art (that of software engineering) is not in making it work. If you see it as a significant success that you managed to name some methods, or write code that compiles and runs (or implemented a heap sort, or found the bounding box for a set of points, or parsed some XML), then your career goals are low indeed. Anyone in this industry can do that stuff, including any reasonably proficient final-year undergraduate in Computing Science. That’s core-skillset, vocational learning. You’re not aiming high enough.

Our art is in making the abilities of our software accessible to those who do not know how it works.

Your chance to demonstrate skill and professionalism and genius is by effectively hiding all the circuitry and wiring and batteries and screws behind one big shiny “Get the Job Done” button, whose apparent function is almost magical.

If you’ve exposed underling complexity or unnecessary choice in your software because you see those things as inevitable, it’s because your job isn’t finished. If you’re going to write GUI software for other people to use, do it properly, and treat those people like human beings instead of software engineers. If you want to expose complexity to the user and wash your hands of it, write command-line tools – or utilities that are used exclusively by other machine processes.

You can’t have it both ways. Writing GUI software is for people who strive for excellence not only in the “software” part but in the “GUI” part too.

Please note: this is about the user interface conventions and considerations which apply to creating software for the iPad platform (and touch-screen tablet devices in general). It is not a technical discussion of iPad-related APIs (which remain under NDA at time of writing in early March 2010).

As I watched the iPad introduction keynote, there was one thing above all which struck me:

That’s iWork (Keynote, Pages and Numbers) for iPad. It’s also a message.

It’s not just a big iPhone

The iPad may be a larger version of the iPhone in terms of the hardware and operating system, but treating it as the same device would be foolish. It turns out that increasing the display size of touch-screen hardware can transform it into an entirely new class of device. The iPad is a productivity platform in a way that the iPhone rightly never tried to be. (And it’s officially OK to charge $9.99 per app.)

When Steve Jobs introduced the iPad, he did so in a very specific way:

The iPad is in the middle, between the iPhone and the Mac. This isn’t just an acknowledgement of relative display size or processing power, it’s also a strong indication of the market position of the device and its software.

The iPad is a target for apps from the desktop, not just from smartphones. There are some very interesting opportunities here.

The Missing Link

We already have iPhone apps on the iPad (they can run at their native size in the middle of the screen, or be scaled up to fit). That’s useful, but it’s not particularly interesting. Far more relevantly, we can bring desktop-class applications to iPad – but we need to rethink our user interface and design in general. What works on iPhone won’t automatically work on iPad.

The essence of the new opportunities on iPad is that this class of device is a natural home not just for the viewers and small utilities we’ve seen on our phones, but also for creators and editors as we see on desktop platforms. Productivity applications, and sophisticated workflows. There are entire genres of applications which haven’t been truly feasible on an iPhone OS device until now; this is an opportunity to literally pioneer a high-profile touch-screen version of those applications.

In order to work out how to do that effectively, we need to talk about what exactly is different about the iPad compared to the touch-screen smartphone platforms. It all comes down to input and output.

• The display is much larger; 1024×768 pixels. Apps with more demanding presentation requirements will be at home here.
• The virtual keyboard is larger, and external physical keyboards are supported via Bluetooth or the dock. Apps which focus on typing are now much more feasible.
• The iPhone supports multi-touch, but only the iPad can credibly claim to support two hands. We’ll talk more about this later.

These facts lead to a shift in how we can think about what applications and interfaces can exist on the iPad. We just need a set of guidelines to follow.

The iPad introduces and lends itself to some new UI conventions. I’ve compiled a list of thoughts that I’m going to discuss below. Some of these are simply from looking at the built-in apps on the iPad, and some are subjective impressions.

Master-Detail

This isn’t new, but it’s new to the iPhone OS platform. Master-Detail is an interface concept whereby you can see both a list of things, and also additional information about the currently-selected thing in the list. On iPhone, either the Master or the Detail was visible, but not both – there wasn’t room. On iPad, we can again have Master-Detail, as exemplified by Mail:

This gives us an easy set of conventions:

• Master-Detail is feasible and acceptable on iPad.
• In landscape, both Master and Detail are visible.
• In portrait, the Master is shown in a transient pop-over.

Two-pane and three-pane interfaces are once again worthy of consideration on this class of device.

Look like a Viewer

The primary warning about designing for the iPad is: more screen space doesn’t mean more UI. You’ll be tempted to violate that principle, and you need to resist the temptation. It’s OK to have UI available to cover your app’s functionality, but a bigger screen doesn’t mean it should all be visible at once.

• Hide configuration UI until needed.
• Look like a viewer, and behave like an editor.

Pages looks like a beautiful reading app:

until you interact with something to display relevant editing UI:

This leads us naturally to the next point.

Edit in place

On the Mac and other desktop platforms, there’s a convention where we have globally-positioned editing UI. Common examples include floating inspector palettes, toolbars, menus, and status-bars. That won’t fly on the iPad, because it introduces a level of indirection between the editing action and the object being edited. It’s a touch-screen device; we should interact and edit directly.

• Edit object properties in place.
• Attach the editing UI to the object. Show/hide/move as necessary.

For example, when you edit transition/build animations in Keynote, you do so on the actual object to be animated:

Upon adding an animation, the list of available types is similarly attached to the relevant object:

The same goes for slides as a whole:

It’s a good principle to follow; it’s direct and immediate, and it’s intuitive for a device where it feels like you’re interacting with the actual objects using your fingers.

Inspectors should be Contextual

There can, however, sometimes be value in keeping standard editing interfaces in standard positions; the key consideration is how much UI to show. On the desktop, this is something we often get wrong. Here are two familiar examples:

These inspectors (for Keynote and Microsoft Word on the Mac) are difficult to use because they show all possible editing controls at once, disabling those which don’t apply to whatever is selected. It’s not easy to find which options apply to what you’re editing at the time, and the density of controls requires the pixel-precision of a mouse pointer and considerable screen space to display.

On the iPad, any globally-positioned inspectors should nonetheless be contextual in terms of what editing UI they show. Don’t overload the user with irrelevant options; hide anything that doesn’t apply. If you’re editing text, show only text editing controls:

If you’re editing a chart, show only options relevant to charts:

The guideline is simple, and it’s good advice even for the desktop:

• Inspectors should present context-relevant UI.
• Hide controls which don’t apply to the selection or focus.

The concept of context is key to iPad software design. In human-computer interaction, we often discuss this under the title of modes.

Use Modes to simplify UI

Modes, or modal interfaces, are where the user deals just with one particular area of a piece of software at a time. They see only the relevant controls and information for one particular task or type of work; an example would be iPhoto’s photo-editing interface, or the Ribbon in the recent versions of the Microsoft Office applications.

There’s been a history of modes getting some bad press on the desktop. The issue is that they trade stability (things always being in exactly the same place in the UI, and not changing) for simplicity (not having too many controls to look through at once). On the iPad, it’s clear where the winning side of the balance is: simplicity. Modes are completely appropriate on this device.

The challenge is in keeping our UI clear and uncluttered. Not only that, but our UI has to be actually usable with a finger – an incredibly imprecise, enormous, screen-hiding input device – rather than a pixel-perfect mouse pointer. Modes can help us keep plenty of space around. Move UI elements into modes, and/or position them contextually and temporarily – but just don’t go overboard with the number of modes.

• Modes are preferable to clutter.
• But removing a feature might be preferable to adding a mode for it.

The modal organisation of features is better than an all-at-once approach, but don’t let it become an excuse for feature creep. One of the primary rules of iPad app design must surely be that less is more.

Fewer Features

Feature-creep or bloat is the bane of desktop software. Any application with a non-trivial feature set isn’t fully used by most of its users; that’s pretty obvious to anyone who has ever used Microsoft Office or Adobe Photoshop or even the iWork apps on the Mac. There are plenty of features there which you’ll never touch, and would probably never miss if they were gone.

Most users need only a small set of features, and software is better when it’s focused. A nice side-effect of focused software is that the UI is easier to design and comprehend (because there’s less of it, and it’s more obvious why each thing is there). The trick is to figure out which small set of features are actually important, and implement only those.

• Offer only the most-used/needed features. If in any doubt, remove a feature.
• Discard optional/niche or highly configurable functionality.

This is another rule which is equally true for the desktop. The difference is that people have been trained to accept fuzzy-edged applications on their computers, whereas they probably won’t do so on the iPad. Be focused, targeted and comprehensible. You can add things later when it becomes clear what’s important, but you’ll never recover from a confusing first impression.

Two Hands

Many people are excited about the fact the iPad is large enough to support two whole hands providing input simultaneously. The hardware support is no different from the iPhone, but the available space certainly is. Suddenly we have visions of really usable card games and air hockey and so forth; it’s hard to underestimate the importance of this factor.

The worrying thing is that I’ve heard people talking about providing twice the UI, with strips of buttons and controls down both sides of the screen, just because there’s enough room for that kind of thing now. Resist that temptation at all costs. The way to support dual-handed input on the iPad is in a discoverable and optional way. There are a couple of interesting examples in Keynote:

During the iPad introduction keynote, Phil Schiller was using Keynote on the device, and demonstrated some subtle dual-hand input features. Whilst resizing a photo, you can tap another photo with your other hand and the one you’re resizing will match that other photo’s size. Similarly, whilst dragging a slide you can tap other slides with your other hand to add them to the group being dragged, thus moving them all at once.

The important point is that there are other, more obvious ways to accomplish these things; the two-handed input features are conveniences and power-user features. They’re useful and time-saving and possibly discoverable, but they’re not the only way to accomplish those tasks. We’re only just beginning to come to terms with the possibilities of dual-handed input; essential functionality shouldn’t require it yet.

• Dual-handed input is acceptable.
• Be usable with one hand. Don’t require two hands for essential features.
• But don’t be afraid to offer time-saving, discoverable dual-handed functionality.

The fact that users can use their hands to interact is something to capitalise on; it’s a very important aspect of the attraction to this type of device. Understandably, it’s rooted in human psychology.

Use the Psychology of Touch

This is where it gets touchy-feely, and thus where we engineers are least comfortable. It’s also where we find the explanation as to why your grandmother wants an iPad but wouldn’t touch a Mac or PC. The twin key factors are touch, and the device’s unique form-factor.

Touch is emotionally important to humans; it conveys the identity and “realness” of an object. Direct touch bypasses abstraction and creates a strong connection with the touched object. This is particularly true when the object itself triggers associations in our minds. Due to its very size and weight and display area, the iPad triggers powerful associations with:

• Printed documents
• Notepads of paper
• File-folders from the filing cabinet
• Clipboards
• Books

There is something intrinsically “right” about seeing the iPad as a technological successor to, or version of, these physical objects. We’re immediately ready to accept the one as a substitute or enhancement for the other. This is a powerful, and novel, position for the iPad software developer.

It wasn’t true with the iPhone or iPod Touch; the devices are too physically small. The “Notes” app on the iPhone will forever be a simulation of a legal pad; the similar app on the iPad is a legal pad (to your user). It’s an incredibly important distinction in terms of how it influences our design.

There’s a predilection towards “realness” on the iPad which overrides mere fashion and aesthetics as seen on the iPhone; it’s a core component of the attraction of the hardware. The standard apps on the iPad build directly on this by using virtual materials. The form-filling view in Numbers is a good example:

We’ve all clipped those card dividers into our binders, and seen them become dog-eared. We know how the slightly waxy laser-printer paper feels, and we’ve bent and reshaped that paperclip a thousand times. These are real things, presented virtually.

We’ve all been in the room with these varnished bookshelves, lit by afternoon sunlight. We’ve all bought a new novel, opened it and guiltily buried our nose in the pages just to enjoy the smell of books.

We’ve all used this legal pad to sketch ideas. Perhaps we’ve even seen it on the telephone table in the study or hallway, slid into its leather slip-case with an index sheet (all those things are visible in the interface above if you look for them).

We’ve all seen this quality day-planner and wished we had the discipline to use it, because it’s a beautiful analogue thing in an increasingly digital world. We’ve paid ridiculous prices for Moleskines and diaries and fountain pens.

We’ve all seen this address book sitting on a desk, hard-bound and meticulously re-indexed, with a red fabric bookmark sitting loosely over the cover.

Did you feel an emotional connection to any of these images and statements? Your users will feel those connections too, even if they can’t articulate them. You can, and should, directly capitalise on these feelings and connotations.

Even if you can’t find a way to make your interface be a real thing, you can often make it into a surface for real things. It’s one additional level of abstraction, but it’ll still work.

This is the table you empty the photos drawer onto when you want to find a particular image from childhood; the stacks are all that’s left of the long-discarded paper wallets the photos originally arrived in. The full-screen display is a photographer’s light-box. The device becomes physical surfaces we know in the real world.

Even resolutely abstract concepts like playlists of music can be represented as surfaces of CD albums. There’s often a way to pull your software interface a little closer to a familiar object from the real world, and increase engagement with the user.

• Make your application a real object if at all possible.
• Alternatively, make it a surface for real objects.

Our graphic design budget must surely increase, but I think you’ll find the pay-off is more than worth it.

Key Questions

In summary, when approaching iPad app design, do so in a way that acknowledges the strengths and unique advantages of the device and platform. Ask yourself these questions:

• What are the core features? How can I remove some of them?
• How can I make this work on a touchscreen device?
• How do I create an emotional connection?
• How can I make my app uniquely suited to iPad?

Don’t ship before testing on an actual device, and remember that first impressions last – take the time to get it right. Don’t assume that what works on iPhone will be equally suited to iPad, and certainly don’t generalise from desktop software.

There’s a unique and exciting opportunity here, and just possibly the beginning of the next major stage in software design and user experience. You’re getting in on the ground floor, and there’s every reason to be optimistic. Good luck.

If you’ve attended one of my sessions and want to share your thoughts with me (and/or offer a testimonial for publication), please do get in touch either in the comments on this post or directly via email (gmail; matt.gemmell).

If you attended my workshop and/or saw my session during the Mac conference, I’d be very interested to hear your feedback – good and bad. Get in touch via email (“matt” at this domain, or my gmail: matt.gemmell), and please be as candid and specific as you like.

I hope everyone had even half as much fun as I did, and I hope to see you all again soon!

Amateur fiction is a wonderful thing, and the internet is a great publishing medium, but you naturally run into the issue of quality control – there’s a lot of bad fiction out there. Perhaps not quite as much as you’d think, but still a lot. If you’re writing such stuff and your problems are those of triteness, illogical plot points, indecipherable or tired dialogue or any of dozens of other problems, I can’t really help you.

But there’s a far bigger group of writers out there whose problems are those of style, and I can give some advice on that. Here are a few stylistic guidelines to follow for readable, smoothly flowing online fiction.

Emphasis only

You only need one kind of emphasis, and it should be this kind. Call it italics or whatever else, but stick with just that style. Don’t use boldface or underline or anything else, as a general rule. You can, of course, very sparingly use all-capitalised words for suitable effect.

Use the same emphasis for thoughts

If someone is thinking, use the same old emphasis – and don’t use quotation marks around the thought either. Do it like this:

I would rather out-think them than out-fight them, he thought. Violence must be our last resort.

If you need to emphasise something within a thought, then you remove the style, like this:

I will never forgive him for this.

Use blank lines between paragraphs

Separate your paragraphs with a blank line. Don’t indent them; that’s antiquated, harder to read and more suitable for print.

Avoid sound effects

Any attempt to render a sound in text will come across as corny and bizarre; don’t even try. Instead, either describe the sound in passing or simply make reference to the fact that a sound was heard.

This is bad:

Picard didn’t even glance up from his computer terminal as the familiar BEE-DEE-BEE-DEE sound announced that someone was requesting entry to his Ready Room.

This is better:

Picard didn’t even glance up from his computer terminal as the familiar sound of the door chime announced that someone was requesting entry to his Ready Room.

Don’t let characters babble

Writing dialogue is very difficult, for two different reasons. First, you have to decide what the characters actually say – and that part is up to you. Second, you have to figure out how to make them say it in a believable and tolerable way.

So many amateur writers spew dialogue onto the page and end up giving the reader the impression that the characters were having a verbal tennis match. I see stuff like this a lot:

“Is there something wrong, T’Pol?” asked Archer.

“I am uncertain what you are referring to, Captain,” she replied.

“You’ve seemed even more withdrawn than usual over the past few days.”

“Have I not been performing my duties adequately?”

“I didn’t say that. I’m just concerned, that’s all. I wanted to see if there was anything troubling you.”

“I appreciate your concern, but there is nothing the matter. I have simply not had sufficient time for my regular meditation during our ongoing negotiations with the Andorians.”

“Well, if you say so.”

It’s not awful, but it’s a bit disconnected and confrontational. It gives the impression of quite a rapid and unanchored exchange, whereas the actual dialogue itself tends to suggest a more nuanced and cautious conversation. There were probably pauses and contemplative silences, and meaningful looks flying around, but we missed them all – and that’s a real shame.

I even sometimes see prose written like a screenplay, simply because many people don’t know how to write and pace dialogue. It does take some work, but it’s not difficult. Feel free to space out the dialogue; really visualise the people who are speaking. They don’t stand facing each other and robotically deliver rapid-fire retorts like two computers playing chess against each other. Slow it down, and describe what’s happening as well as what’s being said.

Taking the same conversation between Archer and T’Pol, we can make it much more interesting to read and less jarring by doing something like this:

She took the indicated chair only reluctantly, and if anything she looked even less comfortable seated than she had when standing.

Sitting ramrod straight and perched on the very edge, Archer thought. You’d think there was no Vulcan word for “relax”.

He sighed, noticing one delicate eyebrow rising momentarily at the sound, and began.

“Is there something wrong, T’Pol?” he asked, almost immediately regretting his choice of words. She visibly tensed up even further, though he wouldn’t have thought it possible.

“I am uncertain what you are referring to, Captain,” she replied, her voice measured and calm. Her facial expression was a picture of control, but her large eyes betrayed a hint of uneasiness.

“You’ve seemed even more withdrawn than usual over the past few days,” he replied, trying to keep his tone relatively light but knowing he wasn’t entirely succeeding. He was worried, and a part of him wanted her to know it.

“Have I not been performing my duties adequately?” she dissembled, fully aware that it was a stalling tactic at best. Jonathan Archer was remarkably perceptive for a human, and he was usually quite proficient at seeing past her cool, logical exterior.

“I didn’t say that,” he replied, his tone slightly strained; “I’m just concerned, that’s all. I wanted to see if there was anything troubling you.”

He gave her a small smile, and saw her glance away for a moment before once again meeting his gaze.

“I appreciate your concern, but there is nothing the matter,” she said, and this time it was his turn to raise an eyebrow. “I have simply not had sufficient time for my regular meditation during our ongoing negotiations with the Andorians.”

He looked at her in silence for a long moment, scanning her face for the slightest weakening of the barrier she always kept in place. As usual, there was none to be found. He sighed once more.

“Well, if you say so,” he said, again offering a weak smile for a moment before turning and crossing to the window.

She knew this was her cue to leave, so she stood up and went to the door, pressing the small panel to make it slide open. She was about to step out into the corridor when he spoke again.

“If you ever want to talk, you know where to find me,” he said.

She looked round and saw he was once again facing her, but his expression was hidden in the glare of the stars behind. She simply nodded, and after a pause which was perhaps a moment longer than necessary, she stepped through the doorway.

Now yes, that’s quite a bit longer, but it’s also a lot more interesting and less like some kind of verbal duel. It’s better paced, and it doesn’t cause as much confusion or shortness of breath.

Pace your dialogue; focus on the entire interaction, not just the spoken words. People think and gesticulate and pause and sigh and fidget and frown and a million other things; they don’t just chatter at each other. Slow it down.

Use an authentic voice

Don’t make characters say things they wouldn’t. This is particularly important when writing fan fiction; you’ve got keep the characters in character. This, for example, is bad:

“That sounds pretty freaking dumb, Geordi,” said Picard.

This is considerably more believable:

“I believe that may prove unwise, Commander,” said Picard.

Make your story as crazy as you like, but make your characters believable.

Use breaks

Chapters are your largest organisational units; use them appropriately, but don’t overuse them (like Dan Brown). There’s a natural type of break which can occur within a chapter, to indicate that the time and/or location has changed: it’s called a scene break. If you’re writing fiction online, it’s conventional to just insert some kind of horizontal separator – you should feel free to do so with abandon, and always to mark time/place changes.

You can use an HTML horizontal rule, or a few centered “+” symbols, or whatever you like – just be consistent. You do not need any other kind of break besides scene and chapter. When you reach the end of a chapter, take an entirely new page (if you’re publishing online, literally link to another page on the web where the next chapter can be found).

Avoid inappropriate cultural references

This one is a very common problem, and it’s a sure-fire way to make your writing sound cheesy. No matter how ideally a pop song expresses the sentiment you want your protagonist to have, do not make him or her listen to it, mention its aptness, or (god forbid) sing it to another character.

Those things will seem like a really wonderful idea if you’re thirteen years old, but for the vast majority of your readers they’ll be agonising. Instead, describe the character’s actual feelings – by all means use analogy to do so – and don’t cheapen the moment by reducing it to a quotation of lyrics.

Relatedly, if you’re shamelessly copying a plot point from a TV show in your own fictional world, resist the temptation to have one of your characters remark on how similar the events are to what happened in that TV show. It sounds self-conscious and adolescent, and it’s considerably less amusing than you think it is. Avoid.

Get a proof-reader

This is blindingly obvious, but it’s also universally ignored: get someone who isn’t you to read your work. Not your mother, unless she’s likely to give constructive, honest feedback. Others will see problems that are invisible to you, particularly with regard to pacing and logic. Take their suggestions and criticisms on board, and revise accordingly.

I’ve barely scratched the surface of this topic here; feel free to suggest more tips (not just pet peeves, please; offer the solution to the problem too) in the comments below.

You can ask to remain entirely anonymous if you wish, and you can similarly contribute a question or issue that you’ve already solved – there might be scope for other views or some useful additions. In you have a possible topic in mind and aren’t sure about it, send it anyway!

You can send your thoughts to me via email to my gmail account (matt.gemmell) or to matt at this domain. Get those suggestions in.

I’ve already answered almost 40 questions on all kinds of things (mostly Mac/iPad/iPhone UI/interaction questions), and I’ve love to hear yours – though please note that I’m more interested in giving my opinions on things than answering specific technical questions. You can ask me a question here.

Dear Potential iPad Competitors,

We’ve all seen the media furore about the iPad, and we know that this day has been coming for a long time. There’s something natural and seductive about the idea of a tablet computer. Something to do with the form factor, portability, implied intuitiveness and non-computery quality of the thing. It’s straight out of Star Trek, and a lot of people want one in their lives.

I’m a little worried about you, though. Your usual tactic is to simply copy the industrial design of the most successful product, reduce the price, then adopt a pump and dump strategy until your next quarterly financials. That’s fine in itself; that’s how business works. I just think you’re misinterpreting both why people are excited about the iPad (even if they don’t realise it), and what exactly you need to copy. I think you might be on a dead-end track without even realising it.

I’m here to help you. I mean that genuinely. As you read the previous paragraphs, you were probably assuming I was speaking in a sarcastic, mean-spirited Apple fanboy tone – I assure you that’s not the case. Yes, I’m a Mac/iPhone/iPad developer and contractor, and I’m excited about the iPad, but I’m more excited by the general class of devices which iPad represents.

I don’t want Apple to be the only company who understands the potential and attraction of devices like these. I use an iPhone, but I’m glad that there are now many other touch-screen smartphones with polished interfaces, multi-touch capability, desktop-class web browsers and functionality-enhancing sensor hardware. A good idea is a good idea, and I’d like everyone to have access to it.

Competition is good, but only as long as it’s good competition. A flood of second-rate imitations doesn’t help anyone; not the customer, and not even your bottom line. The better you compete, the more marketshare you’ll have and the more choice the consumer will have. I’m trying to take a long-term view of this burgeoning market, because it’s the responsible thing to do given that I care about empowering people in general, rather than enriching one specific company (whichever company that might be).

So, let me tell you about a few areas in which I think you might have got the wrong end of the stick about iPad, and what you need to do to compete with it most effectively.

Tablets aren’t computers

Several of you have announced you’re going to create products that you call tablet computers. I think we’re immediately heading off down the wrong path here, at least if your intention is to compete with iPad and grab a decent chunk of the market. A big part of the reason for all the excitement about the iPad is that, similar to the Nintendo Wii in the videogames industry, it appeals to segments of the market which have not traditionally been targeted. Segments which are nevertheless ready and willing, as with Wii, to buy devices in their hundreds of thousands.

It’s difficult to get our heads around the fact that these non-technologically-savvy users can suddenly constitute a core market for a device, yet that’s the case here. Nintendo saw it, and Apple sees it too. It’s an uncomfortable realisation since these people are so unfamiliar to people like you, as hardware manufacturers, and me as a software engineer. This discomfort leads to a kind of understandable blindness, and more importantly can make us leave money on the table. The relative sales and demand figures for Wii vs PlayStation 3 and Xbox 360 over the last several Christmases are indicative of that.

When competing with iPad, you have to realise that, to your new core market, tablets are not computers. There’s no such thing (to your customer) as a “tablet computer”; the very name reduces the likelihood they’ll buy it. The potential of the tablet is that it’s not even seen as a computing device. This is an incredible opportunity to expand into a new market, if you’ll only commit to that mindset.

If you’re thinking of a “tablet computer”, you’re only coming halfway, and you’re asking your customers to come further than they want to. My advice to you is: commit to the vision of a tablet, not a tablet computer, and you’ll have taken the first step towards claiming your share of the money which your new customers are ready and waiting to spend.

The tablet market isn’t the netbook market

During his iPad introduction keynote, Steve Jobs essentially said that netbooks compromise on everything. What he meant was that netbooks are essentially a laptop with a series of cost-cutting measures applied in order to hit a particular price-point, in the hope that high unit sales will result. The premise of netbooks has proven to be financially valid, and they’re selling well – I’m even typing this post on one.

From your customers’ perspective, it’s almost the opposite situation: netbooks compromise on nothing but price. To the potential tablet market, and most of the netbook market, computers are hard. They’re idiosyncratic, needlessly complex things that impose a daily cost in exchange for offering up their functionality. That’s true of all computers, regardless of OS or hardware. To much of the netbook market (and pretty much all of the tablet market), the only gesture of diplomacy towards the user that netbooks make is that they’re cheap. That’s not a strong basis for a customer relationship or a buying decision.

For this reason, the tablet market isn’t the netbook market. It’s true that tablets may cannibalise netbook sales, at least to some extent. But there’s a fundamental benefit: the actual value proposition of a tablet to the vast untapped true-consumer market is vastly higher than that of a netbook. To your customer, a tablet is a “compromise machine” in the best possible way. A tablet is something that people intuitively understand better than the alien and abstract form of a laptop or some arbitrary desktop computer. It’s critically important to capitalise on this, which leads me to my next point.

Tablets aren’t hardware

Many of you have shown in your tablet pre-announcements that you believe tablets like the iPad are hardware devices, but you’re wrong. A tablet device is, in itself, simply a touch-controlled display containing a computer. It’s the top part of a laptop but with touch sensitivity on the screen. That’s not a tablet, by any definition your customers will implicitly use.

A tablet is a synthesis of hardware and software.

If you’re planning to supply the one without the other (probably the hardware without the software), you will fail commercially. You’re not even in the same market. I’d like you to be in the same market because there’s always room for a wonderful new offering and no single company should own any space. But you have to sweep away this dangerously incorrect assumption.

If you’re going to put a desktop operating system onto a tablet device, you’re going to immediately alienate the vast majority of your potential customers. Note the word “potential”. Paradoxically, you may temporarily placate most of your existing customers, but you’re not innovating and you’re certainly leaving a lot of money on the table.

Even if you’re planning to run a desktop operating system with a tablet/touch-suitable veneer, I think it’s a poor decision. The breadth of value of your device will then be the extent of that veneer and the functionality it makes available, and nothing more. What you may think of as the powerful bonus of a full desktop environment will prove to be a limiting factor, and a frustration to your user. You have to commit to the device if you’re going to be relevant in this potentially very lucrative segment.

The greatest success will go to those who fully commit to the software. Your hardware must be good enough, but your software must be nothing short of excellent. Using an OS designed for a screen and a mouse and a keyboard, with or without a launcher or overlay as a token nod towards touch-based interaction, doesn’t count as remotely excellent. Customers want the tablet experience because they can focus on doing the things they want to do, and be free from the tyranny of computers which force an unfamiliar and abstract input mechanism on them, and software which assumes everyone is an idiosyncratic expert in the task they want to accomplish. Tablets are about people and goals, not machines and tasks.

It’s not possible to meet that expectation without designing it into the software from the ground up. Don’t sabotage your own efforts right from the outset.

Limitations aren’t portable

There’s been a lot of press about the limitations of the iPad, and you’re probably both frightened and overjoyed by it. Frightened because you don’t want those complaints to be levelled at your product, and overjoyed because you feel that if you overcome those limitations then you’ll have a strong comparative marketing campaign and a shot at the market.

Be very careful. For the most part, those oft-mentioned “limitations” are limitations for a computer. Yes, a computer without multitasking and Flash support and expandable storage and a built-in camera would indeed be relatively undesirable, and vulnerable to competition. But you have to remember that limitations aren’t portable between product categories.

As I mentioned, a tablet isn’t actually a computer. What constitutes a limitation on a tablet may not be a limitation on a computer, and vice versa. The key to understanding which is which lies in user perception, and not at all in technical details. Let’s look at some things which are listed as limitations of the iPad, from the point of view of customer perception of a tablet device.

No multitasking, in the sense of running multiple UI-presenting apps simultaneously. The user doesn’t care about this. The small existing market of technically-savvy people do, but the majority of users switch between tasks without any regard to applications. They’re entirely happy to jump between their email client and web browser and ebook reader software without caring whether they’re launching and quitting them. Indeed, to most people, switching between apps is launching and quitting them.

There are indeed cases where there’s a real advantage to keeping things running in the background, say to obtain notifications of new instant messages or twitter updates; the iPad can do those things via other means like push-notification systems. The OS itself is fully multitasking-capable, and indeed many system process are running simultaneously at all times, so it’s possible we’ll see third-party background applications in future. The complaint about ‘lack’ of multitasking is a false limitation which is meaningless to the majority of your potential market. Conversely, the benefits of improved stability and extended battery life are very real.

No expandable storage. Users don’t care. There’s a 64Gb model, and data can be selectively synchronised to the device. Our lives are increasingly stored in the cloud and accessed remotely, and local storage is dying a slow death. By all means throw in whatever storage you can, but it’s a fallacy to assume that the power and weight costs of a hard drive are in any way a wise trade-off against solid state media in a tablet device, no matter how much storage hard drives can provide. Your user doesn’t really care, and the question is fast becoming irrelevant.

Closed system. This is the very opposite of what your customers care about. The percentage of your customer base who make a buying decision based on the openness of a system (in terms of system-level customisation options, use of open source software or otherwise) is vanishingly tiny. They’re very vocal, certainly, but commercially they’re irrelevant. Pandering to this segment will most certainly damage your penetration into the market. Be extremely wary about sacrificing large-scale appeal for the sake of a tiny but noisy technical minority. The tablet space is in no way designed for or aimed at such users.

The App Store walled garden. Your customers care about ease of discovering, browsing, buying and installing new apps; they don’t care in the least about whether it’s an open system or not. They don’t care about freedoms of developers, and developers themselves care more about visibility and marketing and sales than they do about pure principles of software democracy. The constraints of the App Store provide a unique, easily discoverable channel which is right in front of every user, and it also establishes at least a basic level of quality control. Your customers want everything that the App Store provides, and practically none of what it doesn’t. It’s a bonus, not a limitation.

Equally, there are some iPad limitations which might well be genuine shortcomings. There are two obvious examples which have been widely commented upon.

No support for Flash. No-one except Adobe actually cares about Flash, but a huge number of people care about the stuff that just happens to be made with Flash. Apple’s decision not to support Flash is not purely a technological one (Flash’s graphics performance, CPU utilisation and corresponding power consumption aren’t that awful, though they can indeed be sub-standard), and for the average person there will indeed be places on the web with blue “missing plugin” icons where they instead expect a familiar game or widget.

This constitutes a genuine opportunity for a comparative benefit in your product, albeit a very small one. Remember: people care about content and experiences, and do not care in the least about Flash itself per se. The relevance of Flash is likely to decrease in future, and it’s by no means a killer feature. Flash support on a tablet device amounts to a bullet point, but probably a valid one when competing with iPad.

No camera. From the average user’s perspective, I do think this is a valid limitation. It’s clear to every reasonable person in the world that Apple will at some point introduce an iPad model with a camera, but for now it’s a potential gap. Fill it, and compete – but don’t assume that you can substitute a camera for a core part of the tablet experience.

Don’t miss the point

The core message here is that there’s an enormous market out there who want to buy something they’ve only just learned about: the tablet experience. It’s not hardware alone, but the inseparable union of hardware and tablet-specific software which creates a device other than what they regrettably know as a “computer”. Don’t miss the point by creating something that’s only a missing link between computers and tablets, no matter how strong the temptation. That’s a path to mediocrity at best, and failure at worst.

I offer these thoughts honestly and genuinely, because I care about this class of device and its enormous potential to empower and connect people. I don’t mind which logo is etched or printed on my tablet, but I will choose it according to the best principles of a meritocracy. I just want to make sure you don’t take a wrong turn before many of you have even started down the road.

Please compete, but don’t compete blindly. Don’t make the mistake of retrofitting conventional computer thinking to what is a fundamentally new class of device. Every moment of jarring re-orientation of how we view bringing computing devices to market will pay dividends if you’re willing to commit to the potential your customers see in a tablet. I truly believe that you’ll thank me later if you’re only brave and visionary enough to see this opportunity for what it is.

I hope you’ll take some of this advice to heart; I truly do. I look forward to seeing what you bring to market.