But displaying lists in applications can be much more than trivial, certainly for applications on Mac OS X, especially when you have to deal with large quantities of data, and have to solve problems such as variable row heights or changes to this information.

Ever since using Tweetie, a Twitter client for Mac OS X, from a development point of view I was always curious as to how the list view for the Twitter timeline was implemented; hundreds of rows of tweets can be displayed in this control, and the performance hit appears to be minimal; scrolling is smooth, there doesn’t appear to be a huge memory footprint. So how is it done?

Lists in Tweetie

If you class-dump Tweetie, you can see three classes at work:

• ABScrollView: A subclass of NSScrollView. It’s not clear as to why there is this subclass but an ABColor object is used for the background (as opposed to an NSColor).
• ABTableView: A subclass of ABScrollView which is used as the list control.
• ABTableViewCell: The cell class used to display each row in ABTableView.

The interesting part of the class hierarchy is contained in ABTableView and ABTableViewCell. ABTableView is a subclass of ABScrollView (not NSTableView) and is a control which can display a list of ABTableViewCells. However the real misnomer here is the cell part, because ABTableViewCell is a subclass of NSView, and not NSCell.

So essentially what we have here is an implementation of something similar to NSCollectionView, which has a set of subviews which each represent a row and have their own place in the view hierarchy. But how, then, is the Tweetie list view so performant?

@interface ABTableView : ABScrollView
{
    ...
    NSMutableDictionary *reusableTableCells;
    ...
}

...
- (id)reusableCellsArrayForIdentifier:(id)arg1;
- (id)dequeueReusableCellWithIdentifier:(id)arg1;
...
@end

Reusing Cells

The answer seems to lie in a method declared on ABTableView, which is -dequeueReusableCellWithIdentifier:. For those of you who are iPhone developers, you will be familiar with a method on UITableView with exactly the same method signature.

For those who aren’t, I shall explain: certainly compared to simple NSCell instances, NSView instances are pretty expensive. In fact, NSCell is actually designed as a “mechanism for displaying text or images in an NSView without the overhead of a full NSView subclass”¹. In light of this, if we have 100, 1,000 – or even more – rows in a list, we don’t want the overhead of 1,000 instances of NSView, each used to represent a row. What’s more is that most of these cached views are wasted, since 1,000 rows cannot be displayed in the viewport at the same time. The iPhone takes advantage of this, and ensures that there are only enough view (in this case UIView) instances to cover the height of the table view; if the associated rows are scrolled off screen, then the views are removed from the view hierarchy.

Scrolling works much like laying down track for a train by picking up track from behind it; when a row is scrolled so that it is no longer visible, it is removed from the table view and “enqueued” (ie stored in an array); when a row that is not visible is scrolled so that it becomes visible, the data source should first check to see if there are any enqueued views, and if so it is then added to the view hierarchy and displayed.

What this means is that hundreds of rows can be displayed in one control without a large performance hit, and is one of the optimizations that makes the iPhone UI so responsive.

Lists in Echofon

After class-dumping, you can see that Echofon implements their list views in pretty much the same way as Tweetie, using two main classes:

• FastTableView: A subclass of NSScrollView which is the list control.
• FastTableCell: A subclass of NSView which represents a cell used for the table view.

Although not as explicit as the enquing/dequeuing in Tweetie’s list control, it would seem that FastTableView does a similar job as it has declared on it -popCellForRow:fromArray: and -popSpareCell.

Also to note is the use of NSControl and not NSView as the superclass of the table “cell” object, unlike with Tweetie. I would guess that this is for some of the additions that NSControl provides, perhaps the target/action mechanism.

Final word

When displaying large amounts of data in a list, as many applications do, often NSTableView is not enough. It is a pretty performant class, but when you start doing things with variable row heights, it isn’t really cut for the job. Nor is a class such as NSCollectionView; again it doesn’t implement variable row heights and lots of items can slow it down.

It seems that using view objects for each row, which have an established presence in the view hierarchy is the way to go, if you have the optimizations on top of this. For one you get the added convenience of using instances of NSView, and not simply working with NSCell.

As a final note, a quote I recall from Marcus Zarra’s book on Core Data says:

The lesson I took away from that story is to expect my users to put thousands of times as much data into my application as I would ever consider reasonable

When working with large quantities of data, it is these kinds of optimizations that make your app more responsive and provide a better experience to the user.

But now you need people to buy it. You release a demo version of your software which allows your potential customers to get a feel for the app and decide whether it’s right for them, or not. And in doing so, you screw up the entire thing.

Where demos suck

It amazes me how many software companies get demo versions of their applications wrong. Demos aren’t a trial period for you of your users, but rather a trial period for your users of you and your software. And if you want to sell your app, you’d better make a good impression.

But time and time again, demo versions of applications aren’t done properly, and rather provide more friction for making sales than acting as a way of convincing your users that your software is worth them buying. Common areas where application demos fall down are:

1. You have to register an account to download the demo.
2. The emphasis is placed on purchasing the app rather than downloading it.
3. The demo places a crippling restriction on the software that doesn’t let you get a proper feel for it. For example, restricting major features.
4. There is a time limit on the demo which pressures users into purchasing the full version.
5. An annoying window prompting you to buy the app is displayed at frequent intervals.

All of these elements create a negative experience of you and your software, right from the very start. But what is it about some of these irritations that make such demos a bad experience for your users, and what are the alternatives?

1. Account registration

Everyone hates account registration. I – like most other people – already have too many online accounts, and to be quite honest, I don’t want any more.

But where this is even more of a problem for people who want to try out your apps before they buy is that you’re already putting rope around their neck. They may just want to try out your app but you are already asking them to make a partial commitment by signing up to try out the demo.

An example of this is with the FileMaker Pro trial download. Before you get a copy of the software to try out, you have to fill in a form, providing your name, address, operating system, and other market research questions such as how you heard about the product. This will be a huge turnoff for any potential customers because they will be less inclined to go through this entire process, just to see whether the application is something they’re interested in or not.

The solution to this problem is simple: don’t do it. On the main page for your app, place a prominent “Download” link which allows people to download your demo in one-click, no strings attached. This way they can see whether your software is relevant to them, without them feeling as if they’re being tied to anything.

2. Emphasis on buy, not try

Another problem with demo software is that the emphasis of the product is immediately placed on buying the software, not offering users to try it first. This ties in with making the users register to download the demo version first, or nagging for them to hand over their credit card details and is again, annoying because it ties them down and makes them feel that they are making a commitment rather than just trying out the software in their own time.

A good example of this being done well is on the Agile Web Solutions downloads page; it is clear that the focus of the section is downloading a demo version of the software to try out first, and not immediately placed on buying it, as shown by the prominence and alternate colour of the “Download Now” button compared to the “Buy It” button.

3. Crippling restrictions

Of course, some form of restriction needs to be placed on your demo applications so that people who have a genuine need or interest for your app can’t use it forever for free.

However, these crippling kinds of restrictions include things like restricting major features from the demo version, which is often counter-productive, because it doesn’t actually let your users see whether your software is right for them, since they don’t have access to certain features, which might be the main reason that they would be interested in using the full version.

Instead of imposing restrictions such as this on your demos, where possible it is better to provide some other restriction that allows your users to get a feel for the application, but perhaps provides an upper bound on their use of it. A good example of this is with LittleSnapper, which limits the number of images in your library in the demo version to 30, but so long as you have 30 or less images in your library you get access to all the other features available in the full version of the app.

From a business perspective, you want to make sure that the restriction you place means that people who are genuinely interested in using your software can’t do so forever without paying, but which doesn’t provide a barrier for those who aren’t yet sure to see whether the app is right for them.

4. Time restrictions

This is probably one of my main annoyances with demo applications – where time limits are imposed  on the use of the demo. The reason I find this such a turnoff is that it it similar to being sold something by a salesman on commission: there is constant pressure on you to purchase the full version rather than doing it in your own time.

Again, this seems attractive from the business side of software, and sometimes this may be appropriate, as there is no other justifiable alternative as a restriction on the demo, but this should only be used as a last resort.

And as Matt Gemmell suggested on one of the World According to Gemmell segments on the MDN show, if you are going to impose a time limit as a restriction, make sure that the time limit only applies to the days that the software is actually used. For example, if you impose a 30-day time limit and the user first uses the demo on the 1^st of the month, but doesn’t use it on the 2^nd, 3^rd or 4^th and comes back and uses it on the 5^th, only count that as 2 days of use, not 5.

5. Prompts to buy

This is probably my biggest annoyance of application demos: where they constantly nag you to purchase the full copy; be that on launch, on exit, or even just during use of the application, it’s a definite no and will not get me – and most other people, I imagine – on your good side.

As I mentioned earlier, application demos are a way for your users to decide whether your software is right for them, and whether it is worth their time (and money). But this is another really annoying feature of demos because it is again pressuring users to purchase your software, rather than letting them decide first whether it is right for them or not.

In this process, it provides your users with a negative experience, and pushes them in the opposite direction to buying your software.

Final word

Application demos are a way for the user to decide whether your software is right for them. It’s your one shot to impress them and convince them that your software is worth investing their time – in learning how to use the software – and money.

Although it might seem like a convenient excuse to offload a whole load of marketing onto your potential customers and pressuring them to make a purchase, this reflects badly on you, and if you offer multiple products they are unlikely to try out others if you create a bad first impression.

The key is to provide a user-friendly experience which portrays you and your software in a positive light; if the software is presented in this enticing manner and people have a genuine need or interest in your software then you are going to make some sales.

As developers, it is hard for us to detach ourselves from what we do and cater to the user. We live on the other side of the fence and are often restrained from making the right decisions because of the way we think, and usually need an objective opinion. We have the curse of knowledge by being so deeply focused in on our software, and what seems intuitive and easy for us is unlikely going to be the same for the people who use our creations.

Thinking from the user’s perspective

The amazing thing about a lot of usability and application design is that most decisions come down to simple thought of how your software is going to be used, and to anticipate and accommodate the user’s various needs. It’s about thinking “I shouldn’t put that text field there because the relation to that other form is confusing” or “I should relabel that button because the current label is misleading”.

As software developers, our main subjects are not computers (even though we do instruct them on what to do) but rather people. We have to be psychologists to some degree and accommodate their needs – our software of which is an end to a means.

The reality

As Matt stated on an earlier MDN show podcast, users want to spend as little time in an application as possible, so that they can get on with their lives. But because we have an affinity with the software we produce it is often hard to detach ourselves from the way we go about our business and think in this way.

Of course this doesn’t mean that we shouldn’t design and architect our applications in a maintainable way, and doesn’t mean that we should write crap code that looks like something the dog threw up. However bear in mind that the user doesn’t actually see any of this. To paraphrase Gemmell again, all the user sees of our applications is the interface.

At the end of the day, users couldn’t care less whether you have a PHP backend or the UI implemented using Rails; they have such a different perspective of what we create. What they care about is how your software solves their problem and how it makes their life easier by doing so.

A flawed design

It’s a pretty common design in applications even today, although flawed. The problem is that it is often linked with a permanent, destructive action, and doesn’t take two important behaviours into account:

1. People don’t read
2. Humans being humans, we all make mistakes

It also offloads the responsibility of managing data – which often is important – to the user, and forces them to make a choice about what they want to do, a choice which often cannot be undone. But hang on, why should an action that I want to perform be completely, irreversibly destructive anyway? We have the Recycle Bin to provide a safety net for accidental deletion in the filesystem, so why shouldn’t closing a Word document without saving or unsubscribing from an RSS feed be reversible too?

Alongside this, the dialog is irritating in most situations:

1. “Why are you asking me this?! I clicked on the button because I wanted to perform the action… duh” – when we’re in a hurry and just want to delete something, we have to then go through another modal dialog to accomplish the action.
2. “Shiii- I needed that and I just clicked on Delete” – due to the fundamental flaw in nature of the design, it’s easy to accidentally go ahead with the action anyway.

A better design

I like the design that Gmail have implemented when you want to delete a message: the message is soft-deleted and a bar is displayed prominently notifying the user that a potentially destructive action has just taken place, but that it isn’t permanent and can be quickly undone by clicking the Undo button.

This is a great design because it caters for most use cases: if you want to quickly go through and delete messages, you can do without being inhibited by modal dialogs. However if you accidentally delete something that you don’t want to, the action can be easily reversed.

But people don’t like repetitive, boring tasks. And one of the areas where this is done especially poorly is when performing batch operations on large sets of data, where the user has to go through several stages to accomplish a task – each time for every item they want to perform the operation(s) on.

Dealing with multiple items

It really does amaze me how badly this is done with lots of services that are on offer, most of which play with large quantities of data – manipulating all of this can be something of a nightmare.

A great example of this is on Facebook. In the settings, there are a list of applications that you have granted privileges to – 85 in my case. What I want to do now is remove a load of these from this list. The procedure to do this is:

1. Click on the X in the right-hand corner.
2. Click on “Remove” in the are you sure..? dialog box (as a side note, the “Remove” button shouldn’t be the default option since it is a destructive action)
   
3. Click on OK in the confirmation dialog
   

For those who are mathematically inclined, you probably have guessed that to remove all 85 applications from the list takes 255 clicks (perhaps more taking into account accidental/mis-clicking). And guess what? There is no way of removing privileges from multiple applications at once.

This is when people don’t like clicking – when they have to perform batch operations by clicking the same things over and over again to do the same job on lots of items.

Solving the Problem

I feel that iTunes solves this problem very well when editing multiple items at once in the “Get Info” panel. The panel is generic and works with different kinds of media, and allows batch editing of all properties that are shared by items in the current selection, something which is very useful especially when dealing with large media libraries. This means that the user can change a load of common properties of items in their media library in one fell swoop, then go through and change the unique properties, such as song name afterwards.

Final word

When designing an interface that deals with lots of data, make sure you have a way of changing or removing multiple items at once, rather than the user having to repeat several actions for each item – something which becomes tedious very quickly, and means they have to waste more time dealing with fairly minor actions, rather than the main focus of your application.

It’s a fair enough dialog, I have been using free software which someone put their own time into and I’m appreciative, and might think of donating to the developer(s) who wrote it.

However, two fatal mistakes have been made here:

1. The “don’t show again” checkbox is unchecked by default:
   
2. The donate button is the default option:
   

From a business or financial perspective, that sounds brilliant. Prompt the user to give you money every time they close your app, because they’re probably going to forget to check the “don’t show again” box, and fortunately for you, if they happen to accidentally hit enter then they’re going to be taken straight to the donate page.

But in terms of establishing goodwill with your customers, it’s a horrible decision – the dialog is annoying, and this is only going to be a lingering annoyance if you repeatedly forget to check the “don’t show again” option – something fairly likely since it’s on application terminate when you generally want or need to get out of the application quickly.

You should always make sure that options such as this are safe and off by default – that is, that without any user intervention if they are prompted once for something that is an extra and something annoying, the option to turn it off is set to yes by default. By default, no stupid emails when registering for an online account, no annoying popup boxes or dialogs.

Be subtle

Of course it’s reasonable to have some form of link to donate to a product, or buy a full version or something similar. But if you’re going to have one be subtle about it. Put it in the about box or discreetly as a menu item, so that if users want to find out more they can do, but it’s not always glaring and in-your-face. I quite like how Viewfinder by Connected Flow does this on their demo version:

Granted it’s always there, but it’s a discreet message and in a small font, which isn’t particularly distracting and at the least doesn’t get in the user’s way.

Overall a winner

At the end of the day, if your app isn’t annoying and persistent about money, the good experience you give your customers will make them more likely to donate to your project. And if your product is commercial then you’ll give your users a better experience and mean that others are likely to purchase it based on the good things that people say about it.

I have talked about piracy before, but I was inspired by Matt Gemmell’s take on it in Episode #9 of the MDN Show:

Piracy is pretty much an unsolvable problem. That’s a controversial thing to say, but I don’t mean it’s absolutely technically unsolvable, but it’s one of these situations where you have diminishing returns. The better your protection, the better your solution to the problem of cracking and piracy and so forth, typically the more it ends up hurting your users.

I completely agree with that point, with something I like to call the 90/10 rule. That is, that a large percentage – hopefully the larger percentage – of your users are legitimate, but that there are always going to be a small percentage of users who will pirate your software, and no matter what you do, they won’t pay for it. And as Gemmell said, the more you try to prevent piracy, the more it hurts the 90% of your users who are legitimate.

The people who are going to pirate your software are split into two main categories:

1. The hardcore pirates. These people aren’t going to pay for your software. Period. No matter how good your anti-piracy implementation, they’ll try and get around it. And if they don’t crack it, they’re not going to pay, because they just don’t want to pay you.
2. The casual pirates. These people often don’t actively seek to harm you, but they may need to use your software immediately but can’t pay for it straight away. Perhaps they work for a company and need to go through some admin to pay for it, but they need to use your software right now.

For the casual pirates, this is where your basic anti-piracy enforcements come into play, such as serial numbers, for example. They aren’t actively seeking to harm your business, but they may do so to get the software immediately. But they are unlikely to persue the case to the end of the Earth to pirate your software if the methods to do so aren’t immediately available. If your anti-piracy methods are just good enough, they’re probably going to become legitimate users because it’s not worth their effort to pirate your software and will expend that effort paying for it.

However, the hardcore pirates are likely to go to the end of the Earth and beyond to pirate your software. These are the 10% and they don’t want to pay. Perhaps this is a moral decision, perhaps they just don’t like you. Perhaps they just don’t like companies. But the bottom line is that they are not going to pay you. If they can’t get past your anti-piracy methods, they’re not going to pay you, and if they successfully pirate your software they’re not going to pay you. Either way it’s a lost cause.

Hopefully less than 10% of your users are actively pirating your software to cause you harm. But instead of focusing on the 10% of your users who just aren’t going to pay, you should look to the other 90% of the people who are paying for your software, and think about them.

After downloading the new Chrome beta for Mac OS X the first thing that struck me was how well it blended into the native Mac UI. The window takes on the standard OS X window appearance whilst working into it with the tabs which are built into the title bar. This wasn’t simply a port of the Windows version, it’s evident that time and effort has gone into making the app as Mac OS-native as possible, with the Preferences window and the keyboard shortcuts and so forth.

But the truth is that many software developers think they can invent a better UI than already exists.

One of the worst applications for OS X in terms of UI that I’ve come across recently has been the Paragon Talking Concise Oxford English Dictionary and Thesaurus. Reviewed by Mac Format, the actual functionality of the app seemed to be fairly average. But worse still, as concluded in the final rating was the “often awkward interface”. I don’t know about awkward, but I’d also add in damn-right ugly:

What I don’t understand is why the developers did this – what was so bad about the native OS X UI? It’s the classic example of reinventing the wheel when it didn’t need it, but which in this case was damaging since the reinvented UI looks pretty grim.

Especially if you’re porting your application, don’t make your application look identical on multiple platforms. Take the time to port it to the platform so that it fits in with that platform’s appearance and behaviour.

Creating your own UI or using that of another platform can distract users away from the actual functionality of the app because it looks alien compared to other applications on the platform; if it is behaviourally different then this also makes the app harder to use because then they have to deal with behaviours that they’re not used to.

If you want some custom control, then build into the existing UI and make it fit in.

Otherwise, the learning curve of using the new UI – which comes as cliff-like – is the main learning focus rather than learning to use the actual functionality of the app, the functionality being the reason why people buy the app in the first place, right?

Which can be changed to:

(Dependent on your level of stalkiness).

Being a moody teenager myself, I am, naturally in contact with.. A lot of moody teenagers. And there has been almost outrage over the new changes; groups with such titles as “i HATE THE NEW FACEBOOK!” rallying troops with motivational speeches including “i HATE HOW FACEBOOK HAS BECOME MORE CONFUSiNG, THEY ARE ADDiNG TOO MANY FEATUrES, PEOPLe CAN SEE YOUR EVERYMOVE…NOT A GOOD LOOK!!!!” have sprung up thick and fast (you’d perhaps be misguided that International Caps Lock Day is infact the twenty-third of October).

Although I find this very amusing, I can sympathise.

Of course changes have to be made to Facebook, otherwise it would remain like a stagnant pool for 10 years. And I’m sure they’re responding to user feedback and I’m sure in the long run it will improve the whole Facebook experience (although this particular update seems like a bit of candy to satisfy the kids).

But the way they’ve gone about it is terrible.

What is this? What can it do for me? Why the hell would I even want this?

were several questions that came through my mind, and where were the answers? Where was the explanation of how or why to use this? Nowhere. Users have basically been thrown into the deep end – accustomed to the “old” Facebook layout, this change has been sprung upon the site, and they don’t know what to do with it, how it works (initially) or why they would want to use this.

And this is not new. This has occurred several times with Facebook.

Joel Spolsky summarised this quite well on Episode #51 of the Stack Overflow podcast:

Spolsky: They’re gonna start, I mean, every time I changed a font, I could change a font on “Joel on Software” and get, you know, 30 angry emails, and then change it back and get another 30 angry emails, 25 of them from the same people that were upset the first time I changed them “ I just finally got used to that font that you changed”. And have to change it all over again.

And it’s because people don’t like to be somewhere they’re uncomfortable. They want to be familiar with their surroundings and know what to do and how to do it.

Not just cainophobia

By now you’ve probably come to the conclusion that users simply don’t like change. But this is an important thing to note. This is why designing UIs which are familiar to users is so important – UIs which reflect their mental model, which are consistent with other applications on the platform, which have workflows which are common and canonical are so important. Because if they aren’t, then you’re throwing your users into the deep end, and their experience will be so much worse.

And if it isn’t, make sure that an explanation is near – all you need is a small question mark icon, or a line of text which explains what something is, or perhaps a tooltip, such as those on Stack Overflow:

which will give your users confidence in what they’re doing and help them to do what they want to do.

As Jeff Atwood noted on Episode #37 of the Stack Overflow podcast:

Naming is super hard; whether you’re naming code, you’re naming human beings, naming is just really difficult.

And he’s right. Finding the “right” name or a name that works for software is really hard. When I started to think about naming (which I had deferred for as long as possible) I looked for a few tips on what makes a good name – of course I have some ideas of my own, but I wanted to see what others had to say on the topic. Although quick Googling yields a fair few results I wasn’t too happy with the results I saw, most of which seem to resemble something similar to SEO patter.

So I started thinking: what makes a good name for software, and how do you go about finding it? My first thought was to go for a bit of brainstorming – ideally, I would have scribbled my thoughts on a wall covered in IdeaPaint but at $200 per 50 sq. ft. I decided to go for the old-skool whiteboard. I think that brainstorming is perhaps one of the greatest ways to come up with an idea – even if most of the diagram amounts to no immediate result, it’s a great way to get your ideas down. Then you decide to take a break and come back later, your ideas will still be there, and you’d be able to add any fresh ones.

But what do you brainstorm? I started to think about different perspectives that would affect the name – namely:

1. Who are your users? Since the name is a way of your software sounding attractive to your users, who are they? What background are they likely to have? What are they likely to be familiar with?
2. What is the context? Where is your software going to be used? This often affects the name – since I am working on some software targeted at the Mac, there are certain “conventions” (in a loose sense) or “trends” which affect what a good name for that audience is. I had a look around at similar pieces of software and started thinking about what was common about them; were there certain aspects or a “style” of the name that were part of this context?
3. What does your software do? Often great names can arise from a fundamental word or set of words that explain what the software does. For example, one of the Apple Design Award 2009 winners is an app called Things which is task management software. Part of the effectiveness of this title goes down to the fact that it explains (or at least gives an idea of) what it does in one word. Don’t be afraid to get out your thesaurus for this bit – I found it pretty useful in expanding my ideas by finding synonyms of these fundamental words or ideas.

After I’d got my ideas down I found that I could think about them, and see which bits fitted well together – was it certain words, or ideas that stood out and formed a great name? However I also had periods where I’d have no idea where to go next, and left it at that and went and did something else. Then, when I came back to it I had several new ideas which I could use to expand upon, and since I’d written my ideas down I could continue from where I’d left off.

But what makes a great name? I started to think about this too, and there are perhaps two key points that I decided:

1. Keep it short. Although having a name which explains (to some degree) what it does, don’t be verbose about it (not naming any names, but several Microsoft product names don’t exactly fit this criteria).
2. Make it easy to remember. This often comes with keeping it short, but make sure that it is something that is easy to remember and spell. Often something easy to remember is something original and different, but make sure that it isn’t too obscure.
3. Make sure it isn’t taken. Do a quick search for the name and make sure that your name hasn’t already been taken. If it has is there some way you can modify the name to make it something you like but different from this name?
4. Make sure it isn’t offensive. Particularly if your software is targeted at other languages apart from your native one, make sure that what you choose isn’t something offensive or a turnoff in those languages.

Another point that I started exploring was metaphors; is there something in real life that is a metaphor for the core functionality of the software? If this can be drawn into the name it makes it more effective and easier for your users to remember and associate with.

An important point is that when coming up with the ideas, don’t be afraid to try things out. Write it down, see how it looks on paper; say it out loud, or ask colleagues what they think of the name. Having a list of names that you’ve come up with – perhaps added to the brainstorm, perhaps separate – even if they don’t work, can help to provide inspiration for other names. And great names don’t come quickly – I spent about a week or so thinking about it and coming up with ideas before I found a name that I thought worked pretty well. Don’t rush the process – and when you think you’re sure about a name, think about it some more; make sure it’s something you definitely like and you want to go ahead with.

Although these were my experiences with this, I’ve provided a bit of a generalisation – some projects require more of certain parts and less of others, but these are some things to think about. And naming isn’t the only thing to consider about your software – it’s pretty much a marketing feature. Create a great software product and make sure the name is something that at least works, and things should start to fall into place.