GameTimer got a nice mention on Episode 171 of “The Spiel” podcast, a show about games and the people who love them. (If you want to listen, here is a direct link to Episode 171, and the discussion of GameTimer starts at about 2h20m.) The hosts Stephen and Dave think it’s a good idea to help speed up the “analysis paralysis” player. Thanks for the review!
My new iOS app GameTimer is getting closer to a release. The app has been submitted to Apple, so I’m now working on generating some interest on review sites. I’ve read the helpful “Pitch Perfect” by Erica Sadun and Steven Sande from TUAW. They make it clear that it’s important to stand out from the tens and hundreds of pitches that are submitted on a regular basis. A short demo video helps in standing out – it shows that you’re willing to put in the work and it makes the reviewers job easier (“quickest way to initially assess your app”). It takes some work and time, but it wasn’t too tricky. In case you’re interested, the final video is embedded on the GameTimer Details page.
This blog post sums up the steps and tools in order to produce the video – so you can do the same for your app. Please let me know if I missed something or didn’t explain things well.
Here are the tools I used to produce my demo video and their associated costs:
- iShowU HD (30$, used to record the app – similar products available, but this was the cheapest “professional” app I found)
- QuickTimePlayer (free, used to record audio)
- iMovie (I used iMovie09 that came with my Mac, the newer iMovie11 is 15$ on the Mac App Store)
- Pixelmator (optional for designing titles, 15$ on the Mac App Store – this is my preferred graphics app so I already had it installed)
Shoot the Video
The first part is to shoot a few segments showing your app. The simplest way is to record the Simulator. A couple of pointers:
- The final video should have a duration of about one minute. You probably don’t need more that 60-90 seconds of “raw” footage.
- Create a few short segments. You probably need a few tries to get each segment right. (I used three demo segments.) Also, you may want to “re-shoot” some segments based on the voice over you want to add (see next section).
- iShowU HD has an option to just record a segment of your screen (so setup to record just the Simulator window). Another feature is to highlight “taps” (they call it “Blob” on Left Click). There are fancier ways of achieving this, but I found this works okay. (There were a lot of mentions of SimFinger by Loren Brichter, but didn’t really see too much of added value.)
Here’s a look at the iShowU HD main window:
You can record your voice using iShowU when recording the video, but you’re more flexible doing video and audio separately:
- As for the video, you should record your audio in small segments.
- In addition to the video segments, also record opening and closing segments.
- You can spend a good chunk of change on good microphones (or even a professional speaker), but a USB headset that I also use for Skype worked fine.
- Rather than ad-lib, you should have some notes or a even fully written narration.
- You’ll probably need a few iterations to have your video and audio come out at about the same length. Edit the copy you are reading or shorten/lengthen the video.
Put it all together
Once you have the basic parts, you can edit the video using iMovie:
- Properly align the video and audio segments. (You can adjust the length a little bit by accelerating or slowing the video so it matches the audio).
- Add a title and closing screen. You can use the built in iMovie Titles, but they seemed quite limited (and not really intuitive to use). Instead, I just put together two PNGs in Pixelmator, also allowing me to use my app background as the background for the screens.
- Add transitions between the video segments. iMovie has some nice animations for this.
- Use the preview to check if things are looking and sounding good.
Here’s a look at iMovie with the title screen, some transitions, and the video and audio segments lined up:
Embed video on your website
Once you have a finished video in iMovie, you can export it to youtube. (You need a youtube account for that.) Once the video is on youtube, add some meta information using the youtube site. You can then use the ‘Share’ tab (‘Teilen’ in German) to get embedding HTML for your website:
All that’s left to do is to add this code to your own website. Done!
When designing an iOS app for different devices in the iOS family, there are a lot of different sizes (and corresponding image files). Rather than having to code all the different cases, UIKit’s UIImage imageNamed can take care of it. This is achieved by using naming conventions, so that UIImage can choose the “right” image file depending on the device the app is running on.
Elements of the “imageNamed” Naming Convention
In order to have a call to
[UIImage imageNamed: <base name>];
return the right image, the full name of the image files (and the corresponding elements in Xcode’s Project Navigator) should be constructed like this:
<base name><iPhone5 element><Retina element><iPad element>.<image type>
Here are the elements used to construct the complete file names:
- iPhone5 images get a “-568h”
- Retina resolution images get a “@2x”
- iPad images get a “~ipad” (case dependent)
- I found that this works for .PNG images, I couldn’t get it to reliably work for JPG images.
- I’ve heard conflicting information whether you can drop the retina element for an iPhone5 image. Some posts are reasoning that it’s not needed as there is no non-retina iPhone with a 568px height. However, I found it only worked consistently with the “@2x” element.
- This convention does not differentiate between landscape and portrait images. If you want to use different images, you have to use different base names, detect the current orientation and choose the right “class” of images.
Complete File Names for different Devices
Putting these elements together, we get the following file names for the base name AppBg (short for App background):
|iPhone (Non-Retina)||<base name>.png||AppBg.png|
|iPhone (Retina)||<base name>@2x.png||AppBg@2x.png|
So when you are using the method call
[UIImage imageNamed: @”AppBg”]
the result will automatically contain the right image for the device your app is running on.
In addition to using the right image in your code (e.g. for the background image), this name convention also applies to the “Default” image that is used as the “splash screen” when an application starts.
One of my favorite tech/developer podcasts, CoreIntuition by Daniel Jalkut and Manton Reece, discussed the “Free Initial Release” strategy on their Episode 75. As fas was I understood them, the episode title “Please Don’t Make The Same Mistake” does not refer to “FIRST” – even though they were quite critical of the idea. As I’m not really productive after staying up till 5am to watch the SuperBowl, I just wanted to give a summary of their discussion. (Main points are from Daniel and Manton, some of the words are mine.)
CoreIntuition’s View of “FIRST”
Daniel thought that FIRST would be “too obviously scheme-y” and could project the wrong image. Initial users (who got the app when it was still free) would look bad if they recommended “this great free app” to their friends, only to find out it wasn’t free any more. At a minimum, you have to make it very clear that the app is only free for a limited time (and even then some will miss that statement).
Manton suggested that it is undervaluing your work – “free app = not worth anything”. Trying to work in the “bargain basement” works for some apps (and he probably meant that you don’t want to be in that market as an Indie Developer).
Basically, they both suggested not to over think things and do the simple thing: Make something that’s worth buying, call it 1.0 and charge for it from day one. (They also mentioned Gus Muellers answer to “Why doesn’t my app sell?”: “Maybe it just sucks.“) Both believe that useful software does finds a way of getting sold.
They also suggested alternatives :
- Release a free “technology preview” or beta, but make sure that you have a way of contacting these users so you can “convert” them to paying users later. (This is probably impossible in the iOS AppStore but may work when developing Mac software.)
- Create a “freemium product”: A basic free product, which serves as a platform of selling a “Pro” version or additional features (possibly through InApp-Sales).
My Take on their Discussion
All they had to base their discussion on was a short tweet about the basic idea of “FIRST”, so they discussed FIRST in a scenario that is a little different than my situation. (That’s totally normal and certainly no criticism on their views.) Overall, I found the discussion very interesting and I am re-thinking my pricing strategy. I especially found the “don’t over think it” sentiment very compelling. Thank you very much, Manton and Daniel!
My next iOS app GameTimer is getting closer to release and I’m thinking how to generate more interest for the app. One idea I’ve been considering is to do a free initial release. This blog post goes into some more details and pros and cons of this strategy. As I love to come up with new terms, maybe I should call it “FIRST”, the Free Initial Release STrategy?
What do I mean by FIRST?
The idea behind “free initial release” is to promote an iOS app by making it available for free on the AppStore. This app is not intended to be free forever – monetization is through sales on the IOS AppStore. However, after releasing the app, it will be free for some time – maybe a few weeks, until switching to a paid app.
Here are a few of the Pros I see:
- Limit the amount of (initial) development work
The sooner you can release your software and get feedback, the less time and effort you waste developing features no one will use.
- Get honest feedback from interested users
For a relatively new iOS developer such as me (i.e. without a track record of good apps or a sizable number of influential followers), it is usually not easy to get feedback from users outside of the immediate friends and family category. A free app is going to be interesting to many more users – and you don’t even have to know them in order to “make” them test the app. One example of feedback is crash logs: You’ll have them, even after testing your app – so you should regularly check the iTunesConnect crash logs or include some crash reporting mechanism such as HockeyApp or Crashlytics. Even better is direct feedback to you as a developer, so make sure to include an easy way for user to leave feedback, such as sending an email or tweet directly from your app.
- Generate (hopefully) positive reviews on the AppStore
Users are a bit more generous with good reviews for a free app, and they are also less annoyed by being asked for a review. If your app has a few positive reviews (rather than the standard three or four 1-star-reviews) or even a good average rating, users will be much more likely to buy your app once you’ve switched to paid. In order to encourage ratings, your app should include some friendly way of “nagging” users for a rating and/or review.
- Easier to create interest for your app
Generally, you will be able to create more interest for a free app: Anyone remotely interested in the app will be able to give it a try. In order to hold these users’ interest, it is important to build a good first use experience. In fact, a good first use experience is probably much more important than having a long list of features that only a few users may need.
As usual, nothing comes for free and there are some disadvantages and risks using FIRST:
- Miss sales to initial buyers
With each new app, there seem to be a few users that buy that app (maybe just because it’s new). If the initial release is free, you miss out on these initial buyers.
- After an embarrassing 1.0 version, nobody cares about a polished V1.5.
I’m not exactly sure where this sentiment comes from (I read about it on the AppCubby blog). But it makes clear that even your version 1.0 has to be compelling enough to captivate the interest of your users. It also means that you can’t just push out an unfinished, crappy version of the app you want to sell – at the least the core of the app has to be “polished”. However, I see this as a bit of a reality check: If there is too much work involved, maybe your app idea is just not feasible.
- Missing the right point to switch to paid
If the idea of FIRST is to generate interest and then make money, there is the danger of missing the right time to switch. You want to do the switch when the interest for your app is sizable, but still increasing – a good point would be right before a link from a John Gruber or being featured on the AppStore. However if you miss that crest, you will again leave money on the table by not properly monetizing on the interest you’ve managed to generate. This means you have to actively monitor how interest is developing, and make sure to be able to change the price on a relatively short notice.
- Interest in a free app is different to something people have to pay for
One of the main points of “Lean Startup” is to build a “MVP” (Minimum Viable Product), but also to validate the concept by asking people to pay money for it. I think it was Jason Cohen who made it clear that people don’t like to say no and will give you all kinds of nice answers if you ask them if they like your idea. Asking for money cuts through that politeness layer. As the discussion around “freemium models” has show, generating interest into a free service does not guarantee financial success for a paid product. (However, I feel that this notion is helpful in “enterprise sales”, but doesn’t fully apply to the iOS AppStore – of course there is a difference between a free app and a 99¢ app, but you are still in “impulse buy” territory.)
It’s not a Beta Test
One thing should be clear: FIRST is not a beta test. First of all, Apple does not look to favorable on buggy apps that are submitted for release and has made it clear that the app has to be fully tested. As noted above, you want your users to have a great experience with your app (after all you want to generate interest in it), so you can’t afford to release a buggy or unpolished release. It is much better to cut features and deliver a “MVP”. When switching to paid, you should make sure to add some features in addition to removing some bugs that have occurred.
Switch to paid
The switch to a paid application can happen in a number of different ways:
- Just change the price (without submitting a new version)
This is the quickest way to switch to a paid app (afaik it does not require approval from Apple). But with the changed guidelines concerning the app description (changes are only allowed with a new version), you shouldn’t refer to the app being free for a limited time in your description if you want to be able to use this option.
- Change the price while submitting a new version
This is a more flexible option: You can refer to “free for a limited time” in your app description and you can also tout the new features when changing the price. (Your existing users probably won’t care.) However, a new version requires approval by Apple and takes at least a few days of review. In order to be able to react quickly, one idea is to submit a new version and hold it for developer release.
- Switch to “free + inApp purchase”
Instead of making all users pay for your app, you can offer a free starter version and an inApp purchase to get to the new features. This option requires new coding to work properly with the inApp purchasing APIs. (I haven’t worked with that API yet, so I’m not sure how much effort that requires.) The other tricky question is what to do with your existing users. If the free version is very close to your existing version, it’s probably okay to keep them on the free tier, but if you are cutting functionality that would waste a lot of the goodwill you’ve generated.
- Switch to a completely new app
This is probably the least desirable option: You have to leave all the “buzz” you’ve been able to generate behind. However, if the reaction to your 1.0 release was so bad that the app doesn’t really have a chance any more, this may be your only option if you still believe in your app idea. But you have to evaluate very honestly if your idea is still feasible – maybe it’s time to cut your losses.
Thoughts for GameTimer
I’ve put a lot of thought into what is the core idea of GameTimer, and I’m confident that I can deliver an MVP that is still engaging users. I’m pretty close to that for the iPhone version of my app, but have decided that having an iPad version would be a great bonus – so I’ll have to have a closer look whether to include that in my 1.0 release. My goal for GameTimer is to go beyond my current level of “one sale per day” – therefore I’m not too worried about missing a few initial sales but hope to generate more interest.
As I’m not working on a project in January, I was able to spend some more time on GameTimer. To recap, GameTimer is a multi-person timer allowing you to measure how much time each player spends during a board game.
I’ve spent a lot of time designing the interface. A good part of it was to make it “look good” (and the associated exploration of Core Graphics), but also to make the interface easy to use and suited to the task of measuring time during a game without undue distraction. For example, the first workable version used portrait orientation, and there wasn’t a good way to make the buttons large enough – so I switched to landscape only.
Here’s a look at the current state of affairs:
Each player has his button (similar to people sitting around a table to play a game), displaying his name and the time he has used so far. The screenshot shows that there is some way of coloring the buttons with the color each players uses in the game. (The screenshot shows no color, wood, white and black, but I’ve also coded red, orange, green and blue and can easily add more colors if needed.)
The game can be started by tapping the ‘Start’ button:
A few things happen:
- Player1’s button gets a green glow to indicate that it’s his turn. Also, his time display starts to advance.
- There is a subtler glow for Player2’s button to indicate that he is the next player. (In the first screenshot this “next player glow” was shown for Player1 to indicate that the game would start with him.)
- The ‘Start’ button turns into a ‘Stop’ button to suspend timing. (Then the active player becomes the next player and when tapping Start again, the game continues with him.)
There are two ways to advance to the next player: You can tap Player1 or the ‘Next’ button. Both actions make Player2 the active player and Player3 the next player. After Player2 finishes her move, you can either tap Player2 or the ‘Next’ button – the ‘Next’ button works for every player. (I’m also thinking about handling random order, but haven’t found the right interaction for it.)
Of course there are quite a few obvious limitations (and some not so obvious):
- No way to reset the clocks (This is next on my list – the workaround “kill the app” is not exactly user friendly ;-). )
- No countdown schemes (For now, the app just measure how much time is used, but I want to use different count down schemes. Also need way to indicate time is up.)
- iPhone only (I want to develop a universal app. Actually, the iPad may be better suited to the use case: The iPad may be placed on the table along the game board, and each player has to press his own button when his move is done)
- Can’t set the players’ names (The buttons should display the name of the associated player. I also need a way to choose a color for the player. There will have to be another view for this.)
- Fixed number of players (Currently, there are four players, but the final product should work for two to four players, maybe up to six players on the iPad.)
Nonetheless, I’d like to get some user feedback as soon as possible. If you are interested, you can play around with the current state of the app (just send me an email and I’ll make it available to you.) The route that I’ll probably take is to release a minimal version of the GameTimer through the AppStore as soon as possible. While the app is not completely polished, I could make it available for free, get the apps into the hands of potential users (more than in a “private” beta test), get some feedback and may also be able to generate a few positive reviews. Have you tried out this strategy or had success with other approaches? Please let me know in the comments!
Recently, I’ve started to work on my next iPhone app. The working title is “GameTimer”. It’s purpose is to keep track of how much time each player in a multi-person board game uses for his/her moves.
Game Timer: Usage Scenario
GameTimer is very much a “scratch-you-own-itch” app: My wife and I love to play board games with friends, especially strategy games that require some thought and do not purely rely on luck. (Some classics in this category are “The Settlers of Catan”, “PowerGrid”, “Carcassone”, or “Ticket to Ride”. In Germany, we also have a series called “Game of the Year” that makes it easy to identify new, exciting games.) One constant issue is that someone takes much more time than the others to make his move. (I’m saying “his” on purpose, as it’s mainly the men that get accused of this behavior.)
Inspiration: Chess Clocks
When I was younger, I played a lot of chess. In competitive games, you always play with a chess clock such as this:
The following description is take from the wikipedia article on game clocks:
A game clock consists of two adjacent clocks and buttons to stop one clock while starting the other, such that the two component clocks never run simultaneously. Game clocks are used in two-player games where the players move in turn. The purpose is to keep track of the total time each player takes for his or her own moves, and ensure that neither player overly delays the game.
Chess clocks also have a mechanical way of indicating when “time is up” (called a “flag”) which is raised by the minute hand and then falls to indicate the exact moment the player’s time has expired. Chess has also come up with different timing schemes, such as “blitz chess” (every player has 5 minutes for the full game) or tournament versions (40 moves in two hours, then 20 moves in one hour) and interesting time control variations.
Extending the idea
It would be relatively simple to code the app-equivalent of a chess clock (and in fact there are some apps of that kind in the app store), but the main disadvantage of a chess clock is that it can only be used for exactly two players, so it can’t be used for the usual strategy games, typically with four players.
So the idea of the GameTimer app is to provide a way of controlling the time in games with two and more players in the form of an iOS app. I’m in the very early stages of designing and implementing the game, but here is a first draft of what the user interface may look like:
Each player is represented by a button with his name, also showing how much time she has used already (or how much time she has left). Some adornments may show whose turn it is and who is next. By tapping the button, a player (or a designated “timekeeper”) can indicate that his move is finished and it’s the next players turn. I will play around a bit with the interface, maybe I’ll also provide a large “Next” button to switch to the next player. Together with my friends I also want to determine if using a single timekeeper works well, or if each player should finish his move on his own. (With a physical chess clock, each player “presses the clock” after making his move on the board.) Obviously there also has to be a way to set up player names, the time control to be used etc.
So there are quite a few open questions to be answered before I can release a finished app, and I’m very much looking forward to work through them in the next weeks. If you want to keep informed about my progress, please have a look at the marketing page for GameTimer and subscribe to my mailing list. Of course, I also welcome any feedback on my idea!
When dealing with data quality issues such as duplicates, the question people usually focus on is “how do I get rid of the duplicate records?” While this is important, this does not remove the cause of the problem and usually leads to ongoing or recurring cleaning efforts. Therefore, if you really want to resolve a data quality issue, you have to ask the question of “where do the duplicates come from?”
As with almost all data quality issues, there are easy answers to this question:
“McFly, you’re a slacker”
(image from http://images4.wikia.nocookie.net)
After the teacher needling Marty, I’m also calling this the “Strickland Explanation”.
or a bit less harsh
While these explanations may be true in some cases, they are not very helpful: They insult the people that you enter the data, making them a lot less willing to help you resolve the problem. Also, it shows that you haven’t thought about the problem or discussed the issue with the users – as there are always other explanations that take a bit of effort to unearth.
Here’s a list of issues that I found lead to duplicates in your address book:
- Technical Limitations
Older versions of address books were limited in the number of fields you had available. One typical issue is that you could only have one email address or phone-number. If you wanted to store multiple phone numbers for a person (e.g. the home number, the work number and the cell phone) you had to create multiple records that have the same name, but different details. This is especially true for address book programs from older phones.
- Synching Gone Wrong
Synching is a surprisingly difficult problem, and almost everyone has their own horror stories of synchs that have gone wrong. Typically issues are an extra copy of each record, information showing up in unexpected places (for example a zip code being stored in a phone number) or some information being lost during synch (one of my pet peeves is the birthdate).
- Information Hoarders
Some email programs had the option of storing the email address of each person that sent you an email in your address book, resulting in a large number of “sparse” records (records that may consist of only an email address or just a phone number, but not a proper name). Also, the large number of resulting records makes it hard to figure out if multiple records belong to the same contact or if you already for a record for a person.
I’m sure that there are even more causes for duplicate contacts. Please note that these causes require completely different approaches than the “Strickland Explanation”. I will have a closer look at these in a future post.
Where do the duplicates in your address book come from?
If you want to find duplicate contacts, please give my iPhone app “SmarterContacts” a try. You can find it on the app store. Please let me know when you identify other causes for duplicates so I can update this post and provide additional functionality in my app.
As with all data quality issues, it is important to understand the consequences of a low quality address book. Too often this discussion is skipped, resulting in only half-hearted efforts of cleaning up and quickly slipping back into old habits.
Here are a few scenarios that show the impact of low data quality in your address book – for the sake of this discussion I equate a low quality address book as having lots of duplicate records, i.e. more than one record for a single contact.
Which is the right record to use?
When you want to use the information in your address book, it is difficult to pick “the right” record to use. Consider the following excerpt from (fictional) iPhone contacts:
If you want to send an email to McFly, which address should you use?
There are a couple of contacts, but you can’t see the context of each email address. Some might be from his school (is he still going to school?) or from a college, some seem work-related. Just from looking at this list of potential addresses, there is no way to figure out which one is still valid, let alone which one to use.
(This example is not unusual, as older programs were only able to store one email address per contact.)
While you may have some additional information to help you decide (you know that Marty has already left high school and college, and that he has been “terminated” from his job at Fujitsu Enterprises), this is next to impossible for Siri, the iPhone’s digital assistant. Here’s a look what happens if you ask Siri to “Call McFly”:
If you try narrow it down with “Martin” or “Martin McFly”, you’ll still get to choose between two (not necessarily the right choices) – and then you’re stuck and can’t even get Siri to pick one of them:
Which is the right record to update?
A similar problem arises when you want to update the contact information for Marty. If Marty lets you know he’s got a new job and had to move to a new postal address, will you remember to delete the old address? If you just add the new address as a new record or just update one of the records, after a month or two you will have no way to decide which is the right address. If you have multiple records for Marty and decide to finally write down his birthday after missing it a few times – which record should you update? Just one (at least you’ve committed the info to your digital memory) or all (better safe than sorry)?
There is no good answer if you have more than one record for a person. Things get easy if you have just one record for Marty – only one place to store his birthday, and you’ll see what other addresses you already have for Marty when you enter a new one, so you can delete those that are no longer valid.
What’s the data quality in your address book?
One of the main points in the “Lean Startup” line of thinking is to get feedback from “real” users as soon as possible and to use that feedback to improve your product before going to market. Before releasing my next iPhone app, I tried to follow this advice, talked to a few potential users and – based on their feedback – made a couple of changes to the app. This post discusses these suggestions and how I managed to incorporate them into the app.
App before showing it to users
My next app – called SmarterContacts – analyzes your iPhone address book and figures out if there are duplicate entries for the same person. (In keeping with the idea of a “minimum viable product”, all that will be in the first version is the analysis part, merging records will be in a future release.) Before showing it to users, it consisted of two screens, a list and a detail view.
The list view is shown when the app starts. It starts to analyze your address book (showing a progress bar while the analysis is going on) and then shows all your entries:
For each entry, a “duplicate probability” is calculated by comparing it to all other contacts and looking for how closely they match. That probability is the number shown after the name of the contacts. The probability is also converted into a cell color, so you can quickly spot those entries that are probably a duplicate.
When you tap one of the entries in the list view, you get some more information on the particular contact:
This view shows one contact, the contacts that are very close to it (duplicate probability of 99% or more) and the next three closest contacts (even if they are “green”, i.e. probably not a duplicate).
I showed this version of the app to a couple of friends and colleagues. When I was at an Apple developer event (the iOS5 Tech Talk Tour in Berlin), I also took the chance to review the interface with an Apple engineer. With each person, I spent from a couple of minutes on the phone to about an hour discussing the app, its functionality and some potential changes.
Here are the main points I took away from these discussions:
- The colors are pretty intuitive (red – needs work, green – okay), but users still asked for more details
- After the analysis, you end up in the list view – there is no easy way to get an overview of how many total records, how many exact matches etc.
- The ‘duplicate probability’ is too technical for the typical user – everyone asked me “what does this number mean”.
- Some testers suggested that the list shouldn’t show the “green contacts” (i.e. probably not a duplicate) at all.
- The picture was clearer in the Detail View, showing two different groups of potential duplicates wasn’t useful and showing “green” contacts was just confusing to some.
Although I tried to focus these sessions on the user interface and the “flow” of the app, I also got a ton of feature ideas that I can include in future versions of the app.
Based on these suggestions, I implemented a number of changes before submitting it to Apple.
Adding an InfoScreen
In order to give some more information to the users (such as explaining what the different colors mean) I’ve added an InfoScreen with a description of the app and its features. The easiest way to do this was to add a UIWebView that displays some local HTML-file that contains the information and also some hepful links to my website and an easy way to send an email.
While this was providing the information that people were asking for (what do the colors mean, what do “the numbers” mean), I was not completely satisfied with it – it answered questions, but users have to look for the information. It would be better either not to raise questions or to answer them without requiring the user to hunt around for some extra info.
Adding a StartScreen
The biggest change (and the one that required the most work) was a new startscreen. Different elements were suggested by various people, but it took quite a few discussions before all the pieces came together.
When you start the app, the startscreen shows the progress of the analysis with a growing bar chart that is segmented according to the results so far:
Once the analysis is done, the bar chart is completely filled. Everyone loved the animation showing the progress of the analysis, and the screen also answers “the color question” the first time the colors are used to display the number of contacts in each category.
Changes in the ListView
In the list view, I just did a few small changes which addressed a lot of the feedback items:
- No longer display the “duplicate probability” It is still calculated internally and used to decide on which color to use, but the specific number is not that relevant to the user. After all, people will not make different decisions based on subtle differences in the probability. This totally avoids “the numbers question”.
- Change the default of the filter control to “wide” instead of “all” By doing this, the “green” contacts are not displayed by default. However, if the user is interested in them, they can still get to them using the filter control. Of course, you can also get to the info screen using the “i” button in the navigation bar at the top.
Changes in the Detail Screen
I also “cleaned” up the detail screen by just showing one group of potential matches and dropping the “green contacts” from the potential matches:
When I started my test, my expectation was that I would get feedback with regards to the comparison function working properly (i.e. these two contacts aren’t really similar at all or these two should be similar). I got a few suggestions on this level, but I was pleasantly surprised that I got a lot of ideas on “the substance” of the app. There were a couple of great discussions on how to do things better resulting in quite a few changes to the app. The core of the app hardly changed, but the way the functionality is presented to the user was vastly improved.
I’m hoping that these changes are also going to increase sales of the app on the App Store. I’ve submitted the app to Apple at the end of last week, so it should be available by early December.