We have left the blog quite quiet for a while, and that is because we have been working with Aaron Brethorst on the Cocoa Controls web site ... but this is not all: we have started another exciting project called VS Nomad (we will make Visual Studio the best environment for cross-platform mobile dev)

So all in all, this means we can’t spend quite enough time to maintain the shop here so we will close it in the next few days. If you are already a mobile[foo] customer, be reassured you can still access our support pages.

We don’t see this as a definitive closure, but we will be away for a few months, and just wanted to let you know!

Permalink | Leave a comment  »

We have left the blog quite quiet for a while, and that is because we have been working with Aaron Brethorst on the Cocoa Controls web site ... but this is not all: we have started another exciting project called VS Nomad (we will make Visual Studio the best environment for cross-platform mobile dev)

So all in all, this means we can’t spend quite enough time to maintain the shop here so we will close it in the next few days. If you are already a mobile[foo] customer, be reassured you can still access our support pages.

We don’t see this as a definitive closure, but we will be away for a few months, and just wanted to let you know!

Permalink | Leave a comment  »

A friend came to find me earlier and asked me if I knew a good designer who could make him some icons. His problem was he had some icons already and wanted to complete his set with a few more, but struggled to find some that would match. 

It struck me that there are a lot of blog posts in the wild on the subject of icons, but none of them organise the sets in a way that they can complete each other.

So I started to compile a list for him recording all the icon sets I know, and organised them by style. If he found this useful, it might be useful you too, hence this post.

Here is my list for the black and white, iOS-like sets. I will post a list of full-color icons next. 

Glyphish

Price: free (with attribution) to $25

The free set contains 200 icons that you can use in your commercial app if you give them attribution and you can add 200 more for 25 bucks. The set is very complete, and contains social media, sport, transport, hobbies, health, pictures, music, videos controls etc.

The set contains PNGs, in 2 different sizes, so they are very easy to integrate in your apps, but don’t contain the AI files, which makes it difficult to modify or add an icon to your set if you need to.

We used them in our slidingNav demo app, and they are very slick.

Cocoa Controls icons for iOS

Price: $15

File type: PNG (including x2 retina size)

This set contains 450 icons, and is very complete too. It covers roughly the same subjects as Glyphish, above, in a very similar style. However, whilst there is a lot of overlap between the two sets, there are also some differences that might be just what you need (for instance, there is an upload/download pair in this kit)

There is no free version of this kit, but you get a lot of icons for your money.

App-bits

Price: free with attribution for commercial use

64 nice looking tab bar icons, free under the creative common licence. Clearly not the most complete set of the lot, but you can get a database image in there that you couldn't find anywhere else.

TokenKit

Price: free for non-commercial use. Commercial: $50 for PNGs and ICO to $75 (including AI files)

The set contains 128 high quality icons available in dark and light colours, ICO and PNGs.

The icons are organised by categories: Adobe, Communications & Internet, Devices, Multimedia, Micelaneous, Office, OS & Folders and Systems & Settings. The navigation by folder is a bit cumbersome, but well worth it to find the gem you are after.

The PNGs files are rather big (128*128 pixels) so you won't have definition issues, but they'll need resizing in your app.

The image above points at the free set, but you should see http://brsev.com/#licensing to get the commercial license.

Working Group's mobile toolbar icons

Price: Free, for commercial and non-commercial with attribution

The set contains 160 icons, and the download contains a PSD file as well as the PNG files. The link above will give you the standard 30*30 size, but they exist for retina display too.

Pixel Press Icons

Price: Free to $69 according to the set.

The free set contains 51 PNG icons available in 30*30 and 60*60 pixels, so they will work for retina displays too. You can use them for free under the Creative Commons Attribution 2.5 Canada license.

For $29, you will have the full White Space "pixel collection" set, containing 352 icons, available in Black or White and in 3 different sizes: 20*20, 30*30 and 60*60 pixels. This could be handy if you don't want to loose definition when you are resizing down.

The AI files are available too in the "vector collection" set that will cost you $69.  

This was the last set of this series I found, but if you know of another set I didn't list, please post it here! 

Permalink | Leave a comment  »

Breaking news: we have icons to give away for mobile developers! 

It's been a while since we've posted here, and we apologize for that. The truth is that we've been busy working with Cocoa Controls... but I am now compiling a nice post about icon sets you can use in your apps. 

... and even better, I have quite a few sets from http://iconk.it/ to give away if you are willing to help us making mobile[foo] a better site by answering our survey. 

It won't take long... so what are you waiting for? 

- Marine

Permalink | Leave a comment  »

Research on a budget

Most lone developers don’t have a separate research division they can turn to get answers to the questions in my previous post. You already know that you’re head of development, head of sales and head of marketing, but guess what: now you’re also head of R&D.

Congratulations on your new role! Here’s a way of collecting the audience data you need as quickly and cheaply as possible.

Phase 1

Download and open this worksheet. (At the moment, you’ll just use the first page.)

Here’s what you need to do: complete as much information in the boxes as you can. If you’re not sure what to write, you might find it useful to look back at the questions above. You’ll also notice a box for a quotation. What you should write there is a description of the user’s key goal written the way the user would express it. For example, don’t write: “User wants to find location of nearest metro station” (for your ‘Metro Finder’ app).  Instead write: “I’m lost and I want step-by-step directions to the nearest tube stop”. This is a good first step for putting you in the shoes of your user.

If you find the form a little difficult to complete, that’s OK. You’re now about to do some research to add some flesh to the skeleton.

Phase 2

Print out a copy of the form you just filled out and also print half-a-dozen blank copies of the second page of the worksheet (the page titled ‘Interview Highlights’).

Now go to a place where your users congregate. This could be a mobile phone shop at a shopping centre, an Apple Store, or a Starbucks. Take a deep breath and stop someone as they leave the store.

“Wait!” I hear you say. “You want me to speak to a stranger? How am I meant to do that?” Here’s some suggestions for interviewing like a pro

First up, you need to look the part. Print put one of those little conference badges with your name on and “Head of User Research” printed underneath. Get yourself a clip board so that you look like a proper researcher.

Then tell your potential participant that you’re doing research into the development of a new mobile phone app and you want to get a better understanding of the people that will use it. Say that you need just 5 minutes of their time. Pique their interest by telling them — in one sentence — the problem your app will solve.

If your potential participant doesn’t want to take part, that’s fine. They probably aren’t your user anyway. If they were, they would have paid attention when you told them about the problem that your app will solve. So now move onto someone else.

Once you have someone on the hook, ask him or her to look over the page you’ve printed out and tell you the specific parts you got right and the bits you got wrong. Does this sound like a good description of the participant? What’s missing?

Immediately you’ve finished your interview, complete one of the ‘Interview Highlights’ forms. Then go back and repeat the exercise until you’ve interviewed around 6 people.

Phase 3

Once you’ve completed your interviews, look over your findings and work to how to change your user description so that it’s more authentic. What do you need to add, delete or revise? If your new user description ends up being very different from the one you started with, you might want to go back and try the exercise again. You should be able to complete one round of 6 interviews in a morning, so you could then use the afternoon to test out your revised description.

Using your research data

At the end of this 1-day exercise, you’ll have a data-driven description of your users that you’ll be able to use to steer design decisions. You’ll find yourself continually thinking back to these interviews whenever you’re thinking about the design of your app. Instead of wondering about what an “average” user would want, you’ll find yourself recalling the specific users you interviewed — and that will make many of your design decisions easy.

You’ll find that the data you’ve collected becomes less important than the change in mindset. Involving users is addictive. Once you take that leap and do it the first time, you’ll find it much easier to do the second time. And before you know it, involving users will become the natural way for you to do design.

But I promise you that you’ll have one extra thing too.

You’ll have a successful app.

Permalink | Leave a comment  »

Here’s a question for you.

What does every successful app have in common?

If you answered, “Works on an iPhone,” “Cross-platform” or “Priced at 99p,” I’m afraid you’re wrong.

If you answered, “Great icons,” “Cool animations” or “Supports multi-touch,” you’re wrong again.

It’s not that these things aren’t important.

They’re just not as important as the common factor behind every successful app.

Knowing your audience

Every successful app has one thing in common.

The people who developed it know their audience.

They know their audience either because they did research to find out what their audience want or because they know what their audience wants intuitively (usually because the developers are the audience). Having a knowledge of your audience clarifies the business problem you are trying to solve. It means you know which functionality is key and what functionality you can leave out.

But when I ask developers, “Who’s your audience?” I find they tend to fall into four groups.

The first group tell me that they don’t know, and they don’t care. It’s rare that these developers create a successful app. And the fact that you’ve read this far means I doubt this applies to you.

The second group tell me that they don’t know, and want some help identifying their users. They want to know who they’re designing for but they’re not sure how to go about it. If this applies to you, read on.

The third group claim they know their users but tend to talk in generalities. They’ll usually say, “Everyone with an Android handset”, or maybe they’ll be a little more specific and say, “People who like playing games”. Because they can only describe their users in general terms, they can’t use the information to make specific design decisions. If all you know about your users is their mobile platform, you’re designing in the dark.

The final group tend to be the developers of successful apps. When I speak to them, I hear something very specific. They say, “One of our typical users is Peter. He’s a blogger who wants to quickly share photos and videos from his Android handset so that the articles he writes are part of today’s news, not yesterday’s.” Their knowledge of users is very specific and can be used to answer design questions. It’s as if someone turned on the lights.

20 questions about your audience

Here’s a quick quiz to assess how well you know your users. If you answer ‘No’ to more than 5 of these questions, look out for my follow up post for some advice on how to flesh out your knowledge.

1. My app is targeted at a small number of customer groups with a specific need.
2. I know the primary user group for my app.
3. I can describe a typical person who uses my app without resorting to generalities.
4. I know the kind of jobs my users do.
5. I know the age range of my users and I know the age group where most people are clustered.
6. I know my users’ level of computer, Internet and mobile know-how.
7. I know how frequently the typical user will use my app (daily, weekly, monthly).
8. I know the apps that they use the most.
9. I know the other apps like mine that users will use alongside my app.
10. I know the other apps like mine that users might choose instead of mine.
11. I know what motivates people to use my app.
12. I know how users would satisfy these goals if my app didn’t exist.
13. I can describe the specific benefits that users say they get from using my app.
14. I can describe the minimum functionality that my app needs to make users think it’s worth downloading.
15. I can describe a successful user journey with my app, from download, to install, to first use.
16. I know how the user would describe ‘success’ with my app.
17. I can describe the specific tasks that users expect to be able to do with my app without reading help.
18. I can describe the typical setting / environment where my app will be used.
19. I know the specific trigger that will cause the user to open my app and start using it.
20. I know the major platform (iOS, Android) and the specific device (iPhone, HTC) that most users have.

In the next post, I will give you a method to quickly (and cheaply) gain the knowledge required to make your app successful, so stay tuned!

Permalink | Leave a comment  »

We're excited to announce the release of our new iPhone app: Out of Office for Outlook.

If you've got an iPhone, and you've ever forgotten to set your Outlook Out of Office, then you need our app!

You can find out more about the app here!

We've also written a couple of blog posts. Read about how the app was designed and what it was like to code.

Permalink | Leave a comment  »

We recently sent a survey round Red Gate HQ to to find out what phones people had (so we could identify potential victims for our Beta programs!).  As you can see, iPhone is the clear winner at 41% followed by Android at 29.5%. WP7 barely registers on the radar at under 5%. 

Permalink | Leave a comment  »

We're currently working on a new iPhone app. Before firing up Photoshop to start on the artwork, we decided to take a peek at the top iPhone apps for inspiration as well as to check out the latest trends.

Using the iTunes store RSS generator we quickly hacked together a grid to display icons for the top 300 paid for and the top 300 free apps.

You can see all the icons here.

Permalink | Leave a comment  »

We've had a couple of requests from customers of the iSQL SDK for a little more flexibility in receiving the callbacks when queries complete. For example, a class might spin off a couple of different SQL queries, and need some way of distinguishing which one has just returned. One way of doing this is to create another class, responsible for accepting the callback, but sometimes that's a bit overengineered. So we've just added a Blocks-based version of the API, and released this today.

If you've not used Blocks before, they're rather neat, and actually not too scary! If you're already an iOS 4 pro, and have been using Blocks since forever, you can skip the next bit. If not, read on...

A Block is just that - a block of code, and the state around it at the time it was instantiated (or copied to the heap; a subtle difference in our case, but sometimes important). Let's take a simple example:

typedef void(^myFirstBlock)(void);

- (void)myMethod {
    myFirstBlock block = ^{
        NSLog(@"Hello world");
    };

    block();
}

In the first line, we declare a block typedef: myFirstBlock is a type of block which takes no arguments, and returns nothing. In myMethod, we create a new block using the ^{ ... } syntax, and assign it to the local variable "block". We can then execute that block a bit later by calling block();.

Importantly, if our Block had used any local variables, they would be packaged up and kept with the Block as well - so extending our example slightly:

- (void)myMethod {
    int answer = 42;
    myFirstBlock block = ^{
        NSLog(@"The answer is %d", answer);
    };
   
    answer = 22;

    block();
}

In this example, we'll see "The answer is 42" printed - not 22. The value of answer was captured at the time the block was instantiated - not when it was executed.

We can pass blocks as arguments to methods, and blocks themselves can take arguments and have return types. In this example, we'll change our block to take a pair of integers:

typedef void(^myFirstBlock)(int,int);

- (void)methodTakingABlock:(myFirstBlock)block {
    block(4, 2);
}
- (void)myMethod {
    [self methodTakingABlock:^(int a, int b) {
        NSLog(@"Doing something with %d and %d", a, b);
    }];
}

You might start to see where this is going... we can pass a block of arbitrary code to another method - perhaps in a 3rd party API - which is then called some time later, supplying some extra data at that point.

That'll do for the moment as an introduction to Blocks - if you'd like to find out more, there's a nice introduction, and some more in-depth tips, both of which I'd recommend having a look through.

So why is this useful for the iSQL SDK? It means that rather than needing to have a fixed callback method for everything (sqlQueryDidFinishExecuting), you can now specify a separate method to be called for each query you fire off. In the past, you needed to rely on passing some metadata around with a query - either a numeric or string ID - and then in the delegate callback, there was inevitably a big switch(...) statement to deal with each of the paths. Now, you can fire each query's results straight to the right logic.

Depending on your style, you might prefer to write that code inline:

- (void)myMethod {
    [self.sqlClient executeQuery:@"SELECT 1;" withCompletionBlock:^(SqlClientQuery *query) {
        NSLog(@"Query completed!");
    }];
}

...or you might prefer to pass the result straight on to another regular method:

- (void)myQueryFinished:(SqlClientQuery *)query {
    NSLog(@"Query finished!");
}

- (void)myMethod {
    [self.sqlClient executeQuery:@"SELECT 1;" withCompletionBlock:^(SqlClientQuery *query) {
        [self myQueryFinished:query];
    }];
}

One of the suggestions we had on the forum was to add a "title" to the query, which you could get at when it finished. With Blocks, you can do exactly that!

- (void)myQueryFinished:(SqlClientQuery *)query withTitle:(NSString *)title {
    NSLog(@"Query '%@' finished!", title);
}

- (void)myMethod {
    NSString *title = @"basic query";
    [self.sqlClient executeQuery:@"SELECT 1;" withCompletionBlock:^(SqlClientQuery *query) {
        [self myQueryFinished:query withTitle:title];
    }];
}

If you're an existing iSQL customer, you can visit the URL in your "thanks for purchasing" email again to grab the new version. If you've not yet bought the component, you can go and grab a new download of the trial version, and start enjoying the Blocks-based API right now...

Permalink | Leave a comment  »

It's about time that Ben and I (Tom) introduced ourselves! We're the latest addition to the mobile[foo] team.

We both joined Red Gate in 2008 and for most our time there worked on SQL Monitor. After a happy 3 years, and the release of Monitor, we both decided to up sticks, move to London, and start new jobs.

A few months past but both of us began to miss Red Gate and the people that work there... so much so that WE'RE BACK!

To start with we're working on an iPhone Out of Office application for mobile[foo] (part of Red Gate's New Business division). We're working remotely and are based in a small serviced office near Covent Garden.

We'll be posting about our experiences designing, coding for, and marketing this app so watch this space.

In the meantime enjoy this gormless picture of us eating our daily Ben's Cookies. 

Permalink | Leave a comment  »

If you've not seen it already, the Motorola Atrix is a really neat piece of technology: at first it looks like a normal smartphone, but the key is in the docks: drop it in one, and it connects to your TV for HD video playback. Another, and it turns into a desktop PC. One more and you have a netbook. Suddenly, I have a single device that works with every form factor I can think of.

Surely this is the way forward - there's been plenty of discussion already about how tablets are (so far) playing out as a medium for content consumption rather than generation; no-one really wants to watch Avatar on a 3.5" screen, and there's nothing quite like playing multi-player games on a big TV in the living room.

I'm not so sure the Atrix is the right answer, though: it's a hardware solution to something that isn't quite the right question. If the question was, "how do I best interact with a single device in many locations", it's a great answer, and an awesome bit of engineering. But I'm not convinced that's actually what's needed. It's more along the lines of "how do I always do the things I want, with the data I need, wherever I am?"

The great thing about the Atrix is that I can be surfing away on my "desktop", run out of the door, so grab my phone and, as if by magic, the web page I was reading transports itself on to my phone screen ready for me to carry on reading on the way to the train. But what's with all the wires? Why do I have to physically plug in a device for me to do this? I love the idea of using my phone to control movies I'm watching on the TV, but really? A dock?

The magic of the cloud means I can have all the data I need available everywhere - I take a photo on my phone, and it appears in DropBox on my PC. If you're lucky enough to have a Sonos music system at home, you can control that with your phone as well - and without having to plug it into a dock!

And there's the difference: we need data everywhere, not device everywhere. The important thing is the data - not the bit of hardware that it runs on.

And I think that's where DropBox, Adobe, Google, and maybe even Apple have got it just a little more right than Motorola in this case.

What do you reckon? Are multi-use devices the way forward, or will we end up with many, more specific, ways of working with our data?

Permalink | Leave a comment  »

A web cam rig made from Meccano (and blu-tak) for recording the screen of a mobile phone

Usability testing is the gold standard for evaluating user interfaces. Although many people are familiar with usability testing desktop systems or web sites, fewer people have experience testing mobile devices. As we’ve discussed before, mobile is different from desktop and this applies to usability testing too. When you’re testing a mobile device, you need to make some important changes to your testing protocol.

The fundamental steps in running any usability test are the same. Here they are:

1. Get buy in
2. Recruit your participants
3. Develop your tasks
4. Finalise your prototype
5. Set up the testing rig
6. Moderate the test
7. Observe the test
8. Analyse the data
9. Improve the design

So how do you carry out these steps when you’re testing a mobile device?

Step 1: Get buy in

When you test any system for usability, mobile or desktop, you need to answer some basic questions to ensure that you end up testing the right product with the right participants. For every test, you need to answer the classic Five W’s (and one H) of journalism.

• Why are you running the test?
• Where will it take place?
• When will it take place?
• Who will be the test participants?
• What system (and what functionality) will you be testing?
• How will you collect and analyse the data?

The answers to these questions are typically captured in a Usability Test Plan. This is a document that gets everyone — managers, developers and other stakeholders — to discuss and agree on the critical decisions that need to be made. It means that when you present back your findings, no-one questions why you tested the wrong functions, or why you asked the wrong users to do the wrong tasks. Even if it is only you involved in the design of your app, you’ll still find the 5Ws very useful to clarify your ideas and structure your test.

Step 2: Recruit your participants

In this step, you’ll go about recruiting your participants. It’s obvious that you want participants to be representative of your end users but it’s just as important that your participants are regular users of the platform that you’re testing. If you’re testing an app for Android, but recruit predominantly iPhone owners, don’t be surprised when your app performs poorly in testing.

About 15 years ago I ran a usability test of a fingerprint identification system for the UK Home Office. My first participant really struggled with the system. It wasn’t because of usability issues with the interface but because the user hadn’t used a computer before and was struggling to use the mouse. At one point, he had the mouse upside down and so ‘up’ movements were being translated to ‘down’ movements of the cursor.

Nowadays, this situation is increasingly rare — the majority of computer users have some experience with Windows. Even if they don’t, once a Windows application has been opened, users can rely on a common set of user interface conventions, such as scroll bars, menus and icons. But user interface conventions for mobile are still in their infancy. For example, Android apps tend to include a specific on screen button to refresh the display, whereas iPhone apps have a hidden control: you pull down the screen to refresh. You don’t want your participants spending their time learning the UI conventions of a new platform, so make sure you recruit users with experience of your device.

Step 3: Develop your tasks

All usability tests are based on the same idea: you ask people to carry out realistic tasks with a system and you observe to see where they struggle. In a test of a desktop system, it’s quite usual to have someone using the system for an hour or more. This is reasonably representative of real-world use because people usually use desktop apps for extensive periods of time to get their work done.
Mobile is different. People may have your mobile app open to occupy two minutes in a queue at the supermarket. Or they may have a very specific question they want an answer to (“Where’s the nearest Chinese restaurant?”) Or they may be using the app in a specific context that is important to emulate.

For example, I was recently looking at several photography books in a bookshop in London. I wanted to check the prices of some of these books on Amazon so I fired up Amazon’s mobile app which allowed me to scan the barcode and check the price. But I was carrying out this activity with a computer bag over one shoulder, a heavy book balanced in one hand, my mobile in my right hand, trying to scan the barcode in the dim light of a bookshop. This is very different from running a usability test in a brightly lit lab where I can put the book on a desk. Context matters with mobile.

Step 4: Finalise your prototype

When testing desktop systems, it’s quite usual for the test administrator to prepare a ‘typical system’ and then ask the participant to work with it. This ‘typical system’ may have a smaller or larger screen than the participant’s own computer and the mouse and keyboard may be slightly different. But it’s not usually much of a stretch to ask the participant to use this system in lieu of the one that they use day-to-day.

Mobile is different. Users customise their mobile device more extensively than they customise their computer and your participant’s configuration may not reflect the standard, out-of-the-box implementation. For example, some apps may not be where you expect them to be on the participant’s phone. Some services (like location services) may be turned off. Asking a participant to use your ‘default’ system could make them feel like they have just rented a car in a country where people drive on the other side of the road: everything’s familiar but it seems to be in the wrong place.

Fortunately, there are several ways to get your prototype onto the participant’s phone so you can test it. The app doesn’t need to be fully coded: for example, you can create an interactive prototype in your favourite desktop presentation application and then export it to the mobile device as a clickable PDF. You’ll find an increasing number of toolkits that contain all the widgets you need to simulate a real app. There are also some apps around (like Interface) that will let you prototype right on the device itself.

Step 5: Set up the testing rig

One of the main problems faced by usability testers of mobile devices is mirroring the participant’s screen.

Sadly, there’s no robust software solution available just yet, which means we’re back to the early days of usability testing where we used cameras to record the screen. There are various solutions open to you: one of the simplest is to mock up a rig out of perspex (or Meccano - see video below) and connect a web camera to it. These are cheap to produce and simple to make, but prepare yourself for screen recordings that are hard to read, especially as the ambient illumination changes.

(thanks to http://belenpena.posterous.com/back-from-euroia)

Step 6: Moderate the test

Test moderation is a lot more challenging with a mobile device. As a moderator, it’s hard — sometimes impossible — to view the participant’s mobile device. Peering over your participant’s shoulder is — let’s be frank — a little bit weird. It also makes participants use the device differently, as they will try to hold it in a way that you can see the screen too. Because of this you’ll find it easier if you have a remote monitor that you can use that’s mirroring the participant’s screen.

Step 7: Observe the test

I find that one of the quickest and most effective approaches to test observation is to ask someone else to do it for you… Seriously.
Get the design team in the observation room and provide each person with a stack of sticky notes. Whenever they spot a usability issue or observe an interesting finding, they should write it down on a sticky note. Sticky notes have the benefit of being small which means people can’t write much — usually just enough to capture the essence of the observation.

Step 8: Analyse the data

Mobile usability testing needs a lightweight approach to analysing and reporting the results from a usability test. One rapid way of doing the analysis is to assemble the sticky notes from the previous step and ask members of the design team to group and organise the sticky notes on a wall (removing any duplicates). Once everyone is happy with the organisation, provide each group of sticky notes with a name that captures the usability issue.

The important point to remember is that your aim here is to describe the problems, you’re not creating solutions. That comes next.

Step 9: Improve the design

Usability testing only makes sense if you change the design to fix the problems that you’ve found. Steve Krug has a wonderfully pragmatic approach to this: for each problem, you ask, “What’s the smallest, simplest change we can make that’s likely to keep people from having the problem we observed?”

You then make the change, check you’ve not broken anything else, and see if you’ve solved the problem. I like this approach because it discourages people from undertaking a major re-design of the interface, which can take a long time to complete and often introduces a new set of usability issues to fix.

In summary

There’s no better way to get feedback on the usability of your app than by running a usability test. Although the process is the same as when testing a desktop app, there are quite a few differences in the details. Adjust your test to take account of these differences and you’ll be better placed to identify the real problems that real users will have with your app when used in an authentic context.

Permalink | Leave a comment  »

We are very pleased to announce that Mobile[foo] is co-organising a Tablet-themed Hackathon in London with the Londoid group.

We finally fixed the date and the venue (hurray!), and we are now working on sorting prizes, t-shirts and sponsors... 

The great coding will start Friday 27th of May 6pm until Saturday 28th 3pm at the crypt and we are certain it will be great fun. 

If you are interested in participating, see the full details and sign-up to the Londroid meet-up.

We will add more detail as we progress with the organisation, so stay tuned. 

Permalink | Leave a comment  »

Summary

You can’t create a mobile version of a desktop system simply by shrinking the screen. You need to re-conceptualise the application and design for red routes, fat fingers and transient use.

Introduction

Is it because children are small versions of adults that they seem to have an obsession with miniaturisation? As a kid, I remember playing with a set of Russian dolls — or matryoshka dolls, to give them their proper name — that belonged to an Aunt. There were 11 dolls of increasingly smaller size, each one fitting inside the previous doll. The smallest doll was tiny, about the size of a fingernail, and I wondered if we would ever be able to make people that size.

Around the same time, I remember watching Fantastic Voyage, a movie in which Donald Pleasance, Raquel Welch and a few other actors are shrunk down to sub-micrometer size and injected into the body of an ailing scientist to repair a blood clot in his brain. It was a fun movie and it got me wondering if scientists would ever design a shrink ray that could reduce people to microscopic size.

Sadly, as I discovered years later, Russian dolls and Fantastic Voyage both exist in a parallel universe with a different set of physical laws. Living things just have to be the size they are. If you magnify a moth to the size of an elephant, its legs will break and it won’t be able to fly. Minify humans to the size of ants and you’ll find their head explodes, being too small to contain the brain cells and neurons that just can’t be made any smaller.

The same goes for mobile design. If you think of your mobile application as a minified version of a desktop application, parts of it will break. With a typical 1280x1024 desktop monitor, you have 1,310,720 pixels to design for. With a typical 480 x 800 mobile screen, you have 384,000 pixels to design for. In other words, you have 70% fewer pixels to play with. This means you need to take a radically different approach to design.  Instead, you need to adapt your mobile design to focus on:

•    Red routes.

•    Fat fingers.

•   Transient use.

Design for red routes

With any application, desktop or mobile, it’s crucial to focus on the key tasks that users want to carry out. All too often we can get carried away with adding new functions and features that obscure the core reason why users bought the application. Marketing insist that we need to add a new feature to encourage existing users to upgrade. If we’re not careful, our application looks appealing on paper but turns out to be frustrating to use.

When we design for mobile, this focus on the key tasks — users’ red routes — becomes all consuming. Nothing is more important.

This is because you just can’t support the same diversity of tasks with your mobile application as you can with your desktop application. If you try, your mobile application quickly becomes unusable with users having to scroll, pinch and zoom their way through it to find the functionality they are after. Prove this to yourself by trying to use a web site like eBay on your mobile phone. Although the red routes — searching for products, browsing categories, and finding last minute deals — are all possible with the web version, they become lost within the design of the page when viewed on a mobile device. So eBay’s user experience team have also developed a mobile application that focuses on just these red routes and this makes the whole shopping experience much simpler.

Figure 1
eBay's web site when viewed on an iPhone and eBay's mobile application. 

Designing for red routes means that you need to remove the less important functions from your application. Red routes are the critical tasks that users need to complete with the application. Most desktop applications sport a dizzying array of functionality but most users only ever use a small subset of that functionality. With each successive release of an application, additional features are added like blades in a Swiss Army knife to encourage people to upgrade. One application where this  is most obvious is in Microsoft Word. Figure 2 shows the growth in menu items in Microsoft Word with each successive release. The key tasks — the red routes — didn’t change as Word evolved. People still bought Microsoft Word for the same reason: to create and print documents. But these extra functions gradually began to obscure Word’s key functions. This eventually made Word so bloated that Microsoft’s design team effectively started from scratch and developed the Office Ribbon.

Figure 2
The growth of menu items in Microsoft Word. Re-drawn from http://blogs.msdn.com/b/jensenh/archive/2008/03/12/the-story-of-the-ribbon.aspx

•    Think back to the functions and features that you offered in version 1.0. The chances are that these are still the main reasons why people buy and use your application.

•    Imagine you’re about to redesign your application from scratch, but it’s only going to allow users to complete a small handful of tasks. Which tasks are you going to support?

•    Imagine you have to strip functionality from your application: which functions would you remove? Continue with this activity until you’re not able to remove any more functions because to do so would be to remove what gives the application its essence. At that point, you’ve identified the red routes.

•    Brainstorm a list of all the possible task that your application supports and then survey users and ask them to pick the most important 5. Combine results across your sample of users and the most important tasks should become obvious.

•   Identify the important tasks, given the uniquely mobile nature of your app. For example, does it make sense to offer geolocation functionality (see Figure 3)?

Figure 3
These two applications make good use of the iPhone's geolocation ability. The 'Find my Car' application supports just two red routes: it allows you to set the location where you parked your car and then helps you navigate back to it. The London Cycle application uses iPhone's geolocation ability to help you find a docking station for your bike, relative to your current location. 

Design for fat fingers

Even if you’re a hunt and peck typist, you use two hands to interact with your desktop computer. You have a full size keyboard that makes typing fast and a mouse that makes it easy to select items on a screen without worrying about clicking on the wrong target.

Mobile devices are different:

•    Fingers are a fat, unwieldy selection device when compared with a mouse. So if people are using a touchscreen device to press buttons and make selections on your screen, make your buttons big.

•   Typing on a mobile phone is difficult and onerous, both with the virtual keyboard on an iPhone and the tiny physical buttons on a Blackberry. So reduce keyboard entry to a minimum.

This means you need to think twice before you ask you users to enter data. Before you request data input, ask yourself if the application really needs the information you’re asking for. For example, do you really need to know someone’s title on a registration form?

If you think the answer is Yes, ask yourself again before you move on. If you can get rid of a field, do so. Review all of your forms and distinguish between fields that absolutely must be completed and others which are optional. If a field is optional, remove it.

Another good design approach is to make sure that you don’t ask users to enter information you can get from somewhere else. For example, rather than ask someone to enter their current location, use the geolocation feature and do the work for them. If people have used the app in the past, see if you can use their previous data to autopopulate fields.

And given the difficulty of entering data with a mobile phone, it’s simply more polite to make sure you give users the correct keypad when you ask them to enter data. For example, Figure 4 shows the same form but in one version, HTML5 form controls have been used to define the field as a telephone number. This makes it quicker and easier for the user to enter a telephone number rather than having to struggle with the smaller, QWERTY keyboard.

Figure 4

Another difference with your desktop computer is that people are familiar with the interaction conventions. With a mouse, you’ll click on objects, scroll and select. We’re still in unfamiliar territory with mobile devices. Will your users know that they can zoom in on your screen? If so, will they know the action to achieve this goal?

Design for transient use

On your desktop computer there are a small number of applications that you use frequently. The chances are that you have these applications open now, while you’re reading this article. These applications are the key ones that you use to do your job: Photoshop if you’re a graphic designer, Excel if you’re an accountant, Dreamweaver if you’re a web designer. You spend hours every day in these applications and you know them well. You know the various keyboard shortcuts to work quickly and you know how to work around features that have been poorly implemented.

You work very differently with mobile applications. You probably have dozens of applications on your phone that you dip into and out of when you are out and about. Think how you use these applications and you’ll soon realise that you use these applications either to kill time while waiting in line somewhere or you use them to do a very specific task. You probably use the applications for few seconds or a few minutes. Unless you’re on a transatlantic flight and dealing with an Angry Birds obsession, it will be rare indeed for you to use an application for an hour at a time.

If your mobile app has a big brother counterpart on the desktop, think carefully about how the two will integrate. Consider the iPod app on an iPhone. The main purpose of this app is to allow you to select and play songs or podcasts on your iPhone. You can’t use this app to digitise your record collection and you can’t even create new playlists: this functionality is built into iTunes — the iPod app’s big brother. Apple realise that the iPod app will be used transiently and by restricting the tasks you can do to the critical ones for mobile, it has the added benefit of making the iPod app less cluttered and much easier to use.

Conclusion

When first designing for mobile, there’s a real temptation to replicate the full functionality of a desktop application into the mobile version. But shrink rays don’t work. Instead, think about the key tasks you need to support. Deliver those tasks for people with fat fingers who want to use your app for a few minutes at a time and you’ll be well on your way to designing an appstore success.

Permalink | Leave a comment  »

Here at mobile[foo], we've been playing with some iOS app development in the last couple of months, and something keeps coming back to us: there's loads of really cool stuff out there, and loads of people who haven't managed to find it yet. Ourselves very much included: I did far more work on Stacks & Heaps that's been done by others, much better than me, many times before.

There's some great examples of Open Source components: enormego's Twitter-style "pull-to-refresh" control, which has itself now made its way into the equally cool Three20 project; Matt Gemmell's awesome MGSplitViewController enhancement on the native iPad component, and even the small but highly-effective Appriater library that prompts your users to leave you a review on the App Store some time before they uninstall it.

However, as someone starting out, or even perhaps more experienced, in mobile app development, finding these libraries can be a problem. There's often a willing answer on StackOverflow or similar, and even a thread listing a few of the more obvious components, but that's not an efficient way of keeping track of such things.

What we're aiming to provide is a way of letting you discover the amazing wealth of content that's out there, quickly, effectively, and easily. It doesn't need to be limited to OSS, though there's some great Open Source content, but if you've got a commercially available component or library, we'd love to hear from you as well.

What now? Tell us we're mad, watch this space, or follow us on Twitter...

Permalink | Leave a comment  »

Let me start by saying this post isn't about teaching you how to draw an icon: there are plenty of tutorials out there that will explain how to do it, and I don't need to write another one. The problem is that they often start by "sketch your idea first on a piece of paper" and this is precisely where you hit a stumbling block. Not useful.

This post assumes you know why a good app icon is important, and is to help you to identify an good icon when someone else is doing it for you.  If you are an app  developer, I bet you already have considered hiring a designer at least once and got discouraged by the task (either because it is hard to find one, or because you cannot afford her).

The good news is that for app icons you can easily outsource your design via sites like 99design. You decide how much you want to pay, and your project is treated as a contest.  In few days, you can have dozens of icons generated to pick from. This is a good alternative providing you know what you need and what constitutes a good icon.

I decided to write this post when a colleague developer told me

"It never ceases to amaze me how you people with an eye for design can take something and tweak it just a little to make it look far far better. Wish I could learn to do that!"

If some people have better design skills than others, I think there are a few fundamental rules that can be learnt very easily: product icons are to an app store what product packaging is to a supermarket. So if you want your product to stand out, think about what you look at when you are in a supermarket, and try to look for the same elements in your app icon.

You will find thar your icon needs to:

1- Be Informative/descriptive.

The same way it is easier to guess there are some pineapple chunks in a tin if the label features a photo of pineapple chunks, the product icon should convey what your product does. In 99% of the cases, try to use an image of a real object. For instance, a palette if your app is about painting, or a notepad if it is about taking notes.

Notebooks picked an easy, recognizable concept. 

Avoid using your logo or a subset of your logo, unless you are a very famous brand, because it will not tell your audience much about what you do.

Huddle is a "productivity suite". Can you tell this from the icon? 

Test if it works: Write what your app does in a few words. Ask someone around you to take a look at the icon and guess what the product does. If the person gives 2 or 3 keyword you wrote down, you are on the right path.

2 - Focus on the app main concept.

The previous point may lead you to use complex imagery. Try to limit the number of objects to the minimum. One or two should suffice, otherwise your icon will be too complicated to decipher and understand. For instance, if your app is designed to monitor your petrol consumption during your holiday, you could use a petrol pump. No need to also add a car and a palm tree.

Test if it works: can you describe your icon in less than 10 words?

This Bento app let you manage everything (notes, contacts, appointments) in one app. The concept works reasonably well at a large size, but is more difficult to understand at a smaller scale 

 3 - Offer high contrast/high visibility.

Strong lines, simple shapes, bright colours.  This will ensure the image is recognisable at a small size, even by colour-blind people.

Papers app icon, representing a library. Does it require the lamp posts too? Are the bricks required to convey the concept of a library? Could it be made simpler to produce more impact?

Test if it works: step away from your computer. Can you still recognise your image?

4 - Ensure it is scalable

Your Icon need to work on different sizes, in the app store but also because you possibly want to use it on your website. Ask for a vector file for it: you will be able to resize and enlarge if required.

Note that this is not necessarily required for toolbar icon, that can get delivered as bitmap it they are optimized for the right size.

5 - Stand out from the crowd.

You can break some conventions to be more visible: if most your competitors use a blue icon, why not try a green one?  

Test if it works: put your icon in the middle of the icon of your competitors, step away and see if which icon stands out most. 

6 - Use a graphic style adapted to your audience.

Funny cartoon-type iconography might not be appropriate for a business application, but a "serious" looking icon might bore teenagers.  This is true for your app UI too, so hopefully your product icon style will match your app content (that's important too)

Test if it works: Most often, you can use your judgment to decide if an icon is appropriate or not, but in case you have doubts, show it to people around you who are similar to your target audience (and avoid your mum, because she will tell you what you want to hear)

Hopefully, with all of that in mind you should be able to avoid all the pitfalls for your next app icon! 

Permalink | Leave a comment  »

I'm just back from Barcelona, where I attended the Mobile World Congress for the first time, with the intention of playing with all the cool tablets planed for 2011 and of finding out what was going on in the App Planet, a recent addition to the traditionally more hardware driven show.

Whilst I couldn't have hoped for more on the gadget front (I was lucky enough to play with the Motorola Xoom, the new Samsung Galaxy tab 10.1, the Blackberry Playbook etc...), the app discussions were not quite what I expected.

I signed up for a session called "making apps profitable": a presentation by Mikael Hed, (Rovio's CEO) followed by a discussion from a panel of "Telcos" (Telecom providers, operators and carriers). I expected to receive insights on how to develop successful apps and distribute them outside the Apple store and Android market place.

Instead, I just realized how little I knew about the mobile ecosystem and the opportunities available for developers in the area.

When you work in a software company in Cambridge like me, it is easy to look at the shiny smart phones and think about the business you can make with them. This is reinforced by the astonishing 2010 growth figures from Apple (+87.2%) and Android (+888.8%). Gartner recently announced that the number of Smart Phones sold to end users has grown by 72% in 2010 compared to 2009 and the Nielsen company predicts that the 50% of the US phones will be "smart" by Christmas 2011.

However, this accounts for just 19% of the total 1.6 billion units sold in 2010, leaving a juicy 81% of the mobile market to be addressed.

And this is what the panel and the audience (mainly of Telcos too) where here to discuss. They are nervous because in the "Feature" world, people currently pay for content itself: they buy a ring tone, or to access the news. This, they know how to provide. However, in the "Smart" word, content is free: "subscribers" (=users) pay for the *medium* to access the content, ie. the app.

The problem is that more and more people with a feature phone now expect to have "apps" too, but operators are not quite sure how to monetise or distribute them. It is a hard problem because they face a variety of problems:

- The market is fragmented. Operators have to deliver apps and services across different handsets, different networks in different countries with different contracts. This generates lots of logistical issues as well as a quality assurance nightmare.

- They need a differentiator. Operators are traditionally chosen for their service, so they are not very keen in distributing the same app as their competitors, precisely the opposite of what their subscribers want.

- They need app providers, but developers don't like them. Operators recognise that they are not developer friendly. For instance the billing process is different for every operator and could change at a minute's notice, creating a nightmare for a developer.

- The 30/70 revenue share model set by Apple isn't appealing. A big portion of the feature phone's owners have prepaid contracts, so most people have a fixed sum to pay per month.  Any share of revenue will have to come from this fixed amount, reducing the operator's margin.

- They are too big to be agile and adapt to the situation. So they need third parties to help them to simplify and reduce their costs.

Fortunately, they are taking some steps to  address the problem:

-  the fact that this discussion is happening at all means that the problem is recognised;

-  the willingness to act on some identified issues: Lee Epting, Vodafone's Content Services Director, said that Vodafone plans to homogenise their billing API in 2011

- the creation of the WAC (Wholesale Applications Community): a joint organisation created to provide a platform for developers to interface better with the carriers, notably by avoiding negotiations with each individual operator.

In conclusion, I came away thinking that:

- the app store is not that bad after all (despite all the pain endured when we released Stacks&Heaps)

- if you are  a smart developer who is not too afraid of a little bureaucracy, there is a potentially juicy opportunity with little competition in the feature phone market. Gemalto has recently brought Facebook to feature phones and there is great demand for more. The question is:  will the Telcos succeed in providing a platform quickly enough and as easy as the app store to attract more developers, and if so, will the feature phones be "cool enough" to develop for?

Any takers? 

Permalink | Leave a comment  »

Following on from the launch of the iSql SDK last week, we have another component for you to use in your iOS apps this week: a grid control!

Extending the concept of a table view into two dimensions, and based on the UIScrollView, this virtual grid allows you to display any table-based data you might need to with minimal effort. Just implement a couple of protocols, one to populate the grid with data, and another on the UIView classes that will form the individual cells of the grid, and you're ready to go.

As before, you're welcome to use this in your apps free of charge, but we'd love to hear any thoughts, suggestions, or bug reports on the forum.

Ready? See it in action, or grab the download!

Permalink | Leave a comment  »

Almost all mobile apps need access to external data to be valuable. With a huge amount of existing business data residing in Microsoft SQL Server databases, and an ever-increasing drive to make more and more available to mobile users, how do you marry the rather separate worlds of Microsoft's SQL Server and Apple's iOS devices?

The classic answer: write a web service layer

Look at any of the questions on this topic asked in Internet discussion forums, and you'll inevitably see the answer, "just write a web service and use that!". But what does this process gain? Desktop applications interact with the SQL Server directly - why should mobile apps be any different?

The better answer: the iSql SDK

Working along the lines of "if you do something more than once, make it shared," we set about coming up with a better solution for the general case. And so the iSql SDK was born: sitting between SQL Server and your iOS apps, it provides the simple API you're used to if you've been developing desktop apps using the Microsoft SQL Native Client.

It turns out a web service remained a sensible idea: HTTP is much more suited to the Big Bad Internet than SQL Server's native TDS protocol, removing the need for complex configuration, firewall configuration, and the like.

However, rather than writing a web service for every app that needs data access, we made the web service generic, serving only as a proxy between the SQL Server and a client library integrated into the iPhone or iPad app. This client library handles all the network communication, and provides a clean API.

OSQL in 25 lines of code

As an example of how to use the API, I put together a very simple app that allowed the user to enter one or more SQL statements, and displayed the results in a rather primitively formatted text field. The total amount of Objective-C code responsible for doing the work? About 25 lines.

You can see this in action in the demo video.

Beta out now - your chance to give us your suggestions!

We've released the iSql SDK as a beta: you're welcome to download a copy, have a play in your own apps, and let us know what we've missed using the Feedback button on the site.

Software development should be fun and rewarding: no-one wants to spend their time writing boiler-plate code over and over again, so stop writing the same web service code, and start doing exciting things in the new world of mobile data!

Permalink | Leave a comment  »