upbeat.it

UX, mobile, freelancing, entrepreneurship

It’s Not C, It’s the API

I’d like to order 10 pizzas”.

We have dough just for 5 pizzas, so we are gonna send you 5 pizzas plus a bunch of private data about other users that ordered pizza tonight”.

This is, in a very simplified way, the flaw behind Heartbleed. XKCD explained it even better, in slightly more technical way.

In my opinion the bug (which was introduced in this commit if you are interested) is not simply due to the code. Sure, as suggested in this advisory, the way to fix it is to change the code by implementing a bound check, but what I see it as a design flaw in the API. Notice that the client, when requesting data, wants a reply of a given lenght. Meg (the client) should never be able to specify the length of the response in the question.

When you call a 3rd party API exposed via HTTP you can ask ”give me the last 10 posts of user X” but implicitly you are asking ”if the posts are less than 10 give me those you have”. There is no server that, in case posts are fewer, fills the response up to 10 with someone else’s posts, unless the server guys are on drugs.

There has been an interesting discussion between Brent Simmons and Mark Bernstein.

My argument is that bugs like Heartbleed should be prevented by a better design of the APIs, regardless of the programming language.

Hit me on Twitter or App.net. I’d really like to know your opinion.

On Why I Am Not Gonna Buy Any Smartwatch

There are many rumors that Apple is designing a smartwatch, while Motorola has already announced moto 360. I work on a Mac, I have a few iPhones and also an Apple display. I am already hearing you screaming “fanboy”. According to your cliché I should line up as soon as Apple announces the alleged iWatch. Wrong!

Even if Apple is really going to ship an Smartwatch I am not gonna buy it. I quit wearing a wristwatch twenty years ago, when cell phones became popular and I am not gonna go back. For the record I don’t wear anything ornamental like bracelets, necklaces, earrings and even though I am married I don’t wear a ring (my wife knew that before we got married). Why? I am mimimalist and I like to “feel free”. A precious bracelet would require me to worry about it, like paying attention to not loose it, remember to take it off before the shower, etc. I solve the “problem” by now wearing it. The same holds for a wrist watch: I don’t need it. I always have an iPhone with me to check the time when I need, plus asking people around you is not a bad thing.

Are you gonna build a smartwatch? Are you gonna put in it a feature that simplifies my life? Like what? Let’s see:

  • mail notifications. I don’t care. They are turned off on every device I own.
  • tweet notifications. I don’t care. While I have push notifications turned on my iPhone I don’t let them distract me. I check them when I want/can.
  • payment system? I don’t care much. The time to swipe a card and put a signature is around 30 seconds most of the time. Are you sure you wanna optimize on that?
  • Fitbit-like tracker. I don’t own a Fitbit or the like. I walk enough and I burn enough calories every day. I “designed” my days to include walking or biking. If, in the future, I am gonna use one of those trackers I’d use one specific for the job, not one that tells you also time/weather/tweets/etc, thus not a watch.
  • I could go on …

When the iPhone was released I bought one because it solved a pain that I had. Browsing content on a mobile device was a PITA. I remember I used to take a break to smoke a cigarette and check RSS feeds. That was supposed to be a pause to stress out but when I was done I was more stressed than before. Authentication via WEP was a mess, font rendering was horrible and I don’t wanna mention how painful it was to select an item from a list. I had a problem, I presume many others were more or less on the same boat, and we all welcomed the iPhone.

Which pain point is a smartwatch trying to solve? I don’t see one. Do you? Tog has a long list. Every item listed in that post doesn’t look like a problem to me. That’s why I feel the iWatch might end up like the Apple TV (which I don’t own), a hobby.

I think it’s fair to say that Apple’s design process has been “pain driven” lately. Mp3 players sucked before the iPod. Smartphones were horrible before the iPhone.

Which pain is a smartwatch gonna solve? I don’t see any.

As usual I’d like to discuss it on Twitter or App.net.

On Naming Macros in Objective-C

Right after my latest post on naming methods with blocks my friend Murray asked for some feedback on the names for his collection of macros. Without even blinking I suggested ALL_CAPS, having in mind mostly the following macro by Apple

UI_USER_INTERFACE_IDIOM()

I think it’s pretty ugly to read but I guess it’s meant call out the fact it’s a macro. If you check UIDevice.h though, you’ll find the following:

#define UI_USER_INTERFACE_IDIOM() ...

#define UIDeviceOrientationIsPortrait(orientation) ... #define UIDeviceOrientationIsLandscape(orientation) ...

WTH?

The first is all caps and the subsequent two are named like classes. Again, not even Apple is consistent in naming. So far I have seen many styles in different projects:

  • UA_invalidateTimer
  • NSStringFromBool
  • IS_IPHONE

My take? The first looks like a method in a category and the second looks like a class or a C function. I’d stick with all caps, ugly to read (and type) but at least it clearly says “I am a macro”. And you? How do you name your macros?

Get in touch on Twitter or App.net if you like.

On Naming Methods With Blocks

Recently I have been very busy with the implementation of the BaasBox SDK for iOS and I had to come up with lots of method signatures. It’s 2014 and we all love blocks, so I used them quite extensively. When consolidating the upcoming version I noticed I wasn’t consistent with the naming. Some method was like this:

-(void) loadCurrentUserWithCompletion:(BAAObjectResultBlock)completion;

and some other was like this:

- (void) updateUserWithCompletion:(BAAObjectResultBlock)completionBlock;

Notice the different naming for the last part, the name of the parameter. Sometimes I even used the “Handler” suffix like this:

- (void) logoutWithCompletion:(BAABooleanResultBlock)completionHandler;

I am 100% aware that it doesn’t matter for the correct execution of the app. You can define a method like this

- (void) updateUserWithCompletion:(BAAObjectResultBlock)completionBlock;

and then implement it like this in the .m. It will perfectly work.

1
2
3
4
5
6
7
- (void) updateUserWithCompletion:(BAAObjectResultBlock)a {

  if (EVERYTHING_IS_OK) {
      a(); // call block
  }

}

Nonetheless, it is pretty likely you are going to use autocompletion to implement the method and a parameter named “a”, although working, doesn’t sound professional, does it? Anyway, my concern here is pretty much on the style, or aestetics if you like, which still matters to me.

So I popped a simple question on Twitter and I got an interesting set of replies.

One good point is brought up by Colin

No, if the second parameter were an int I’d not suffix with it. But when I teach I constantly have to explain to newcomers how to correctly read this method:

- (void)loadPath:(NSString *)path completion:(BAAObjectResultBlock)completion;

The source of the confusion is that “completion” is used both in the signature of the method and to name a parameter. In this case I am prone to write the method like this:

- (void)loadPath:(NSString *)path completion:(BAAObjectResultBlock)completionBlock;

so it’s more explicit. After spending a few minutes on this, as replies came in, I thought I should check up what was Apple’s take on the matter. A pretty known method is:

+ (void)animateWithDuration:(NSTimeInterval)duration delay:(NSTimeInterval)delay options:(UIViewAnimationOptions)options animations:(void (^)(void))animations completion:(void (^)(BOOL finished))completion

and, as you can see, there is no “completionBlock”. Then, how did I come up with it? Well, digging a bit more in the documentation it’s easy to find out. NSOperation for example has a property named completionBlock and so has CATransation. AssetsLibrary has a method named

- (void)writeVideoAtPathToSavedPhotosAlbum:(NSURL *)videoPathURL completionBlock:(ALAssetsLibraryWriteVideoCompletionBlock)completionBlock

The new NSURLSession class has

- (NSURLSessionDataTask *)dataTaskWithURL:(NSURL *)url completionHandler:(void (^)(NSData *data, NSURLResponse *response, NSError *error))completionHandler

and I could go on. Unfortunately there is no consistent naming, not even in Apple’s code.

So I went for what I thought made sense for me. Objective-c is verbose per se, people are most likely going to exploit autocompletion, and I like descriptive method names. That’s why I went with completionBlockin my code. I feel it makes everything more readable in general.

And you? How you do name your methods with blocks? Feel free to yell at me on Twitter or App.net.

Detecting Screen Brightness in iOS

I am a huge fan of small libraries that do just one thing but well. Sure you can detect when screen brightness changes by listening to the UIScreenBrightnessDidChangeNotification, but ASCScreenBrightnessDetector by aschndr is the right sugar on top of that. All you need is to create an instance, set a delegate and implement the - (void)screenBrightnessDidChange:(CGFloat)brightness; method, like this.

If you are already using Cocoapods, including it is a breeze.

I am gonna use it in Neater.

Objective-C Categories for Regular Expressions

I am not a heavy user of regular expression but I have tried this new library by John Wright and I find it very handy.

It basically allows you to write 75% less code. Here is an example taken from the Readme page


While I suggest to know what happens under the hood before using these kind of “shortcut libraries”, I am totally in favor of them when it comes to save yourself some typing.

So here is my general recipe:

  • get the basics right first
  • experience the pain of some API (I am looking at you Auto Layout!)
  • use (or even better build!) shortcut libraries/frameworks.

See you to the next library.

Building a Business Outside the App Store

Written by a solopreneur, this article is not just for solopreneurs, but for everybody noticing that something has changed in the App Store.

Introduction

I must say it’s easy to stare at a shelf and complain about the price of a product. I did it many times and I still do it sometimes. Whenever I see a high price it’s kinda hard to not think the producer is cheating on me and charging too much. I have started changing my mind when I began building products, thus becoming the guy to makes the product that get placed on the shelves. I have always been a “what’s behind” kind of guy, trying to imagine the production process behind a product and making guesses on the production costs, but I have never been an active part of that process. Since 2008 I have been an active (and sometimes the only) contributor to digital product (mostly apps) and my perspective has changed radically. When I got started I thought designing and coding were the most stressing tasks, now I find them the most relaxing. Pricing, besides marketing, is probably the most demanding activity when I build a product.

Pricing

App pricing is a kind of science. Finding the “right” (whatever that means) price for an app means dealing with a mix of competitor analysis, time you spent actually building the app, fixed costs to keep the app running, plus a surcharge to keep paying your bills. In the mobile community the discussion about pricing takes places every two or three months, usually triggered by some bold blog post or a report. A few months ago, Jury’s presentation and Cingleton 2012 was the trigger for the discussion. The morale was “we should charge more”. A few weeks ago the discussion has been revived by a Flurry report, whose conclusion is essentially: ad supported apps are the future. I totally disagree. The 90% of free apps mentioned in the reports includes apps with in-app purchase. That’s very misleading, but still a detail compared to what I am gonna say.

Applications in the App Store are too cheap and developers behave like they are doing a clearance sale. Hey guys, wake up! I don’t believe you didn’t spend at least a night pouring sweat to get that feature working as it is meant to be. If you did, and you are selling your app for free, look in a mirror and you will see a jerk. Raise the damn price of your app, do it right now. I am not saying that because you are ruining my market and forcing me to charge less. I really don’t care. Even if the conclusion of the flurry report were true (and it’s not), I could not care less. My goal is to build a long-term business and I think it does not get along with selling apps in a one-shot fashion. I was very glad to see that Apple charged a full price for a completely new version of Logic Pro. I was also very happy when the guys at MartianCraft charged 199$ for the Briefs app. Those are the prices I’d like to see but I realize both are complex and hard-to-build-solo Mac OS X applications. On the iOS side I know of a few solo devs that make a living off of the App Store. One is Loren Brichter. There are probably a few more, but I think it’s fair to say they are a handful.

Building a Sustainable Business

If you want to raise the sustainability of a long-term solo business, in my opinion you should not focus on the app. iOS and the ecosystem behind it has payed my bills so far (building apps for clients), yet I can’t picture building my core business on it.
We can’t beg users to help us fixing the price on the App Store. Customers pay because we make decisions on their behalf, and price is included in that bunch of decisions. The App Store model was devised six years ago and the options are still the same: sell apps one shot, use in-app purchase, include iAd. Six years is a century in the technology field. Apple has improved a lot of its devices and development tools. I am really thankful for that, but now we need a revamp of the App Store. They have had the guts to radically change the design of iOS with the seventh release. If some of that boldness is left, please invest it on a revolution of the App Store. If they introduce a recurring subscription fee for apps I’d jump on immediately. Let’s hope for that. In the meantime here is how I plan to build a sustainable business.

A Long-term View

At the moment I see two winning pricing models for a long-term business: consumable in-app purchases and recurring fees for a service. Both are aimed at getting in a situation where there is a constant stream of incoming money in the pockets of the developer. The first is probably best applied to games. The app is free, the first levels are free, to go on with the game you have to buy something recurrently, e.g. food for an animal, a virtual coin to build a new farm in a village, etc. People that get engaged with the game will progressively buy more assets. People who don’t like it won’t. It’s a win-win situation, in which you get the attention (and money) of those who care about your app. As “Underscore David Smith” points out, there might be moral concerns related to the way you sell consumables. At the moment I have no plans for games and this brings me to the other option.

The second way of building a long-term business is the one I prefer and keeps the core outside of the App Store. It is based on selling a service for a monthly or yearly fee. You can even sell the app (Instapaper did it), but the core thing is the service. Even if the App Store closed tomorrow you’d still have your service working and you could write apps for other platforms. Some services following this business models are FeedWrangler, Cheddar and Instapaper (all built by solopreneurs). Customers are billed for the service. The App Store gets wiped out? The service is still there, and you can use it via a web app. In this case the app in the store is just a view, a kind of accessory if you like. This model of business seems very viable to me, and has a series of advantages.

  • You are in touch with your customers. You can talk to them via email.
  • The income is steady. You are not selling a product once, you are selling a service recurrently. The customers that go for the yearly fee will give you room to improve the service and add new features.
  • The core is the API.
  • There is no 70/30 split. All you charge is yours (minus the maintenance costs of course)

There are also disadvantages:

  • You can’t be just the front-end guy. Either you partner with some server guy or you need some competence in server stuff.
  • the initial investment (either time-wise or money-wise) is a bit bigger
  • you have to deal with house-keeping stuff like invoicing and payment processing.

There is a third option, but it’s a very long run. The fact that Logic Studio Pro was a brand new application for which people had to pay the full price is a clear move. Apple is trying to educate people that upgrades are not free for life. Everyday new people that have never bought software are getting on board thanks to the iDevices and iOS. They will get familiar with a different pricing for software, one in which you pay full price for major releases. In my optimistic view this might take more than five years, and honestly I can’t wait that long.

Time to Broaden your View

Once the App Store was announced I was extremely happy, for a 30% of the income Apple managed payments, hosting and a part of marketing. A heavily guarded little place, where people went to buy good stuff, seemed a great idea. In the beginning things were great, like the in gold rush, there was some golden dust for everybody there on day one. Things have changed a lot since then. The App Store just had a face lift but it’s essentially the same. Competition has grown a lot, along with crappy released-once-and-never-updated applications. Like Adam and Eve, everything looked great in the walled garden. Now there are ways to cheat on search results.

Outside of the App Store, things moved on. We now have services like Stripe or Paymill that dramatically simplified the processing of payments. Web frameworks have improved a lot and allow you to build and refine a product very quickly. The price of hosting has plummeted. For example Amazon announced an 80% drop of the cost for reserved instances. Spinning up new server machines to enhance the performance of a web application is getting more and more easy.

Curiously, two of the web applications I have mentioned (Instapaper and Cheddar) have been sold. As far as I understood, in both cases that was due to the fact that running them as a solopreneur was very demanding. That does not mean the business model was wrong. Indeed, if they were sold it’s because the business model was working. You’d not buy something if it’s not well done and in good shape, right?

Growing up

All this considerations make sense if I also put myself in the mix. I undoubtedly changed. Six years ago it was ok to rush for one week, get an app in the store and cash in some money without any plan after that. It’s not my mindset anymore. I prefer to cultivate my business day by day, get in touch with people, talk to them, grow gradually without feeling the need to rush. Family changes you, for the better. I still enjoy rushes from time to time, I like the thrill of short deadlines to get the vibe of self-evident progress. But every step, in a hurry or not, is part of a bigger plan for a sustainable business.

You might wonder: why are you building Neater, which is meant for the App Store? Because App.net is an awesome platform, focused on enabling developers to build a sustainable business. They have a Developer Incentive Program which is a great idea to sustain the business of apps built on top of it. It’s the only platform that does that, as far as I know. That’s why I am building Neater. Just to be clear: it’s not for the cash per se. It’s for what an incentive program like that enables: a long-term view.

The rest of my efforts are geared towards a web application based on a subscription-based business model. I can’t provide many details at the moment. I am working on the infrastructure and experimenting with different architectures. I’ll keep you posted, don’t worry.

I know it’s weird but here is my suggestion: if you are a solopreneur, struggling to find a decent spot in the App Store my suggestion is … don’t do it. Don’t focus just on the App, focus on a core that can live even if the App Store is shut down tomorrow. Build a business.

I am happy to review my opinions if Apple revamps the App Store and introduces new business opportunities like recurring fees, although I have the feeling that most of the applications I have in mind will need a back-end, thus will involve some fixed costs for server, thus won’t get along very well with the one-sale-free-updates-forever model.

References

Here are a few articles that I kept around while writing this post:

As usual, I’d like to discuss this topic on Twitter or App.net.

On Excitement in the Apple Land

Last year I wrote about boredom in the Apple land. Essentially I said that we were getting used to the patterns adopted by Apple and that a stretched iPhone was built just to show off. I still think we didn’t need a taller iPhone but I definitely changed my mind about boredom.

It looks like Phil Schiller read my post and replied on stage with “Can’t innovate anymore, my ass”. That was just referring to the new Mac Pro, of which we had a preview during the last WWDC. Unlike the iPhone 5, a device that I bought because I needed to test apps, the Mac Pro is something I will probably buy even if I am aware I don’t need it. Why? First of all, because it’s cool. Second, I’d really like to have something more powerful (now I am working on a MacBook Pro). Third, I think innovations deserves to be nurtured and buying a Mac Pro is my contribution to that cause.

That was just one thing shown at WWDC. The one that has impacted my life most so far is the introduction of iOS 7. Here is Federighi’s implicit reply to my post: “Boredom, my ass”. iOS 7 is the most disrupting update since iOS 3. The latter has changed our lives, given us the possibility to build and sell native applications. iOS 7 is pushing us all (designers and developers) to start over. Craig Hockenberry has rightly compared it to the introduction of Aqua in 2000, a revolution. Believe me when I say that, in this exact moment, there are tons of developers and designers cancelling vacations and spending nights to revise all their plans.

I don’t know how many companies can afford to start over. Apple had done it many times recently: with the iPhone 4, the iPhone 5 and will do it again with the Mac Pro. Those are all “internal revolutions”. The teams at Apple were probably told: “forget what you know, get far away from your comfort zone, we start from scratch”.

With the release of iOS 7 Apple is asking the same of third party developers. Forget about the design solutions you are used to, forget about the interaction language we have used so far, start from scratch. And we are following along. I don’t know how many companies can afford that. Apple, for sure, can. Respect.

If you think it helps I will write more angry posts reporting boredom. My last one worked pretty good :)

Happy to discuss what you think of the Mac Pro and iOS 7 on twitter and app.net.

Now I gotta go back learning a new design language.

On Stealing the Right Thing

TLDR; Be wise in choosing what to copy/steal

Somehow we are all been fascinated by:

Good artists copy, great artists steal.

That’s a quote by Pablo Picasso often “stolen” by Steve Jobs to make his point. He put that in practice quite a few times, “copying” the guts of BSD, which became the foundation of Mac OS or “taking inspiration” from the groundbreaking work done at Xerox in the ’80s. From the quote it is clear that the cool guy is the one who steals. I won’t argue on that, feel free to choose the way you prefer. Once you have chosen it, here is a question that locks you up: copying/stealing what?

This reflection starts from a recent bunch of emails where last-minute entrepreneurs wanted me to build the “next Whatsapp”. That was probably due to a series of tutorials I have written to build an iOS chat. That’s ok but: with all the great apps out there you take Whatsapp as a reference? That ugly looking, probably-based-on-a-non-sustainable-business-model app? I am aware it is probably the most famous but it’s also the most bloated, insecure and really hard to stand. So why copy/steal it? I would understand if it were unique, but there are tons of chat applications out there. So you could have said:

  • we wanna build something like iMessage but working better
  • we wanna build something like Skype, but cooler and with no voice
  • we wanna build something like Viber but with feature X
  • we wanna build something like check-the-mockup-attached

Picking the right example, the right thing to take inspiration from, should not be harder than picking between copying or stealing. Just get out there, and pick the best. I know I should not say this as a UX designer, but if you are new to the field and you have no idea, at least pick the “best looking”.

I myself poke other developers or designers with ideas or plans to collaborate. I might make some reference to other applications or services but I really put care in choosing the ones to mention. Whether I propose to steal or copy something, that something has to be good, if not great. During classworks, whom did you copy from? The first of the class, right? Thus …

Why Your App Needs a Walkthrough

This article first appeared in issue #5 of App Ville. Thanks Tope for allowing me to repost it here.

There has been some heat around walkthroughs in mobile apps. I think it all started with the bold post by Max Rudberg, If you see a UI walkthrough, they blew it. Here is another take on the subject. And by the end of this article, you will understand why you need a walkthrough if you are truly innovative.

How Long Will It Take To Get Familiar With This?

That is a question a designer should be obsessed with when designing a product, (notice I said product in general and not mobile application). While this is a pretty subjective question, in that it relates to way a person develops a relationship with an object, there is also a parallel concept, affordance, which puts more emphasis on the object itself, and focuses on its intended usage. For example, you grab a cup of tea by the handle, because it is obvious it is meant to me grabbed in that manner. Put in another way, the intended use of the cup, is to be grabbed by the handle and to hold liquids.

What Do You Do With A Cup?

This does not absolutely prevent people to be creative and exploit the cup in ways that diverge from its intended use. I am sure you have people grabbing a cup not by the handle (I do for example), not to mention that many tea cups in this exact moment are holding pens, coins, flowers. So even if you are the most objectivist designer in the world, thinking that your object has to be used the way you intended is just wrong: people can (and will) challenge that.

Maybe the cup is an example too easy? Think of a screwdriver. Isn’t it meant to tighten/loosen screws? And yet, when I am in a hurry, I use it to open boxes. The same goes for my home keys. This is not because I like to save the blade of my cutter. This is dictated by me and the context I am living in at the moment: being in a hurry, with no cutter at hand. That is to say that the intended use is influenced by the user and the current context he is living in.

Moreover there is a social aspect. We are using the fork the way our parents taught us to. This means; they gave us a walkthrough to the fork. As you can see the “relative” variables (subjectivity, context, culture) are the key points in this example. So for a while I have come to the conclusion that the “objective” (and somewhat absolutistic) approach, while good for dissertations, is just a waste of time if you want to do business.

Whenever we talk about designers and users aren’t we talking about people? Yes, then it’s all about subjectivity. But turns out I was wrong. Products have a sort of “nature” and you have to consider that as well when designing.

Innovation Needs To Be Explained

Breezi by Cesare Rocchi on 500px.com

If I design a new fork, there is no need to write a user manual to explain its usage, because people can leverage their previous knowledge (yet a subjective trait) about the usage of forks. Along the same lines, if I am building a new mail app, which clones the functionalities to Mail.app on iOS, it is likely there is no need of a walkthrough.

On the contrary, if I am doing something disruptive like Clear (no buttons just gestures) or the first version on Twitter on the iPad (no back button) and I don’t put a walkthrough I am just crazy. Of course I can shoot a video, but I can’t assume people buy my app through your website.

Either I put the video in the app (not the best solution in my opinion) or I resort to a walkthrough. Due to the disruptive nature of the app, I have to guide users through it, otherwise I risk they don’t “get it”, discard it, or even worse, write a bad review. You don’t want that for your app, right?

So the essence of my point is: if the interaction in your app is disruptive/innovative and you don’t use a walkthrough, you’ll get the same effect of a child holding is fork for the first time. He starts to grab it in unconventional ways and possibly drop it once he finds out he does not need it.

Some Will Hate It, Some Will Like It: Who Do You Cater To?

Up until now, we haven’t taken into account the subjective side of things, though. When deciding whether to include or not a walkthrough in your app, think also in subjective terms. What will the user think? Before that you should probably ask yourself: who is the target user? Combine the answers to these questions and you will have a ton of different reactions in front of a walkthrough. Here are a few reactions that I stumble upon frequently:

  • I have this app (with no walkthough), now what?
  • The guys behind this app have been so kind to show me how to use it
  • Do they think I am stupid? I know how to use an app!!
  • Why do they show me how to use it? I wanna explore it myself.

The first set of people are the guys that need to be taken by hand. They won’t touch a button without the fear of doing something wrong. They really need an overview of what’s possible to do and how to do it. Those are the ones that, unless taught by a friend, will not get your app and, if they figure out how to do it, leave a bad review on the app store.

The second set of users is the one you are chasing. It’s made of people that like to be taken care of. They recognize there is a ton of work behind a mobile application and they appreciate the care you put in it. In practice a unicorn.

The third set is always the 50% of your users. They can think your app is crap or great, but they will always complain about the fact that, by making explicit the intended use, you are forcing them to interact with your app in a certain way. Those are the ones that use a screwdriver to open a box on purpose, even if they have a cutter at hand.

The fourth set probably does not influence your choice of putting a walkthrough in your app. Those are the ones that buy a TV set, unbox it and throw away immediately the instructions, because they wanna make it on their own. It is likely they appreciate the option to get out of the walkthrough at any time.

An Example In Practice

Keep in mind who you are targeting and why. It will be easier to decide about the need of a walkthrough. The more your target is a niche, the simpler is your task. Unfortunately my target is pretty wide, so I had to figure if and how to use a walkthrough. When I designed Breezi, I had this in mind.

Subjective traits

“The user wants to get a glimpse of the weather and forecast. He wants it to come up quickly and to be very evident. He wants to bookmark a bunch of favorite locations. He has taste.”

Objective traits

“There are gestures to discover content. The user interaction model is disruptive enough that the majority of people won’t go past the first screen. For them, a quick guide is mandatory. Users of gesture driven apps like Clear, won’t like the guide but I think they will be ok with the option of quitting the walkthrough at any time”

So I ended up putting a quick walkthrough in Breezi. Here is a screenshot.

Breezi by Cesare Rocchi on 500px.com

Key traits are:

  • skippable at any time
  • highly visual, with as less text as possible
  • spotlight like, to suggest the tap point
  • fully accessible

In my case, this solution has proven to be the “lowest common denominator” matching both the needs of people who like to be taken by hand and the “explorers” that can quit the walkthrough at any time.

Summing Up

Should I put or not a walkthrough in my app? There are two main perspectives to account for (subjective and objective), and you should address both before deciding. In particular you should think whether the interaction in your app so disruptive to require a walkthough, of if the user can exploit previous knowledge to get interact with your application.

Check out the Breezi app here. Breezi is a weather app that gets out of the way and lets you interact with it directly. The gestures will blow you away, and yes, there is a walkthrough to help you out.