Mobile First Design

If you are designing for many screen sizes, where should you begin?

Traditionally, most designers will start the design process at desktop size. This is where most content is going to fit in well. Then you figure out how to squeeze it down to a tablet, then a phone.

I believe this is the wrong path to take, when designing a mobile responsive page (or any website for that matter). Just because a desktop page can flow responsively on a small-width screen, it doesn’t make it suitable for mobile.

The best thing you can do is to start with a mobile design. Straight away, you are met with a conundrum: how do I fit all this content into the tiny screen? You can no longer just drop a matrix or a data table on to the screen — there really isn’t enough space.

You are forced to think about questions like:

  • what you are trying to do?
  • what are the most important elements a user needs to interact with?
  • what is the most important action that needs to be taken after viewing the content?
  • can the content/data be summarised and simplified?
  • can you offer a better way to drill down to your content?
  • can my data fit into an existing metaphor (like a map or a calendar)?

Once you are done with the design process, you might have a crazy realisation: all the questions you asked yourself, and the resulting design decisions you made — they apply on desktop too.

That’s right. A good design is already responsive.

Now, desktop design becomes more about enhancement over a lazy content dump. You’ve already made the decision up front on what is important and what is not. You no longer feel dirty, having to add ‘small-hidden’ css classes everywhere.

Start with a mobile design on your next project. Your design will be better for it. When you pick tools like the responsive grid, pick one that starts with mobile too. Bootstrap 3, for example, switched gears to do exactly this.

Responsive is hard. Mobile is hard. But the thoughtfulness and effort we put into what we build will delight our customers. And our customers are the reason we exist.

Why techies make crap early adopters

Recently, I’ve been working on apps and business ideas like AlwaysHungry, 60Hz and Secret Hotels (for lastminute.com.au). Finding early adopters to test these products are not easy. Things are even more complicated because my friends and colleagues tend to be very tech savvy.

It seems like people associate early adopters with being able to use a phone really well, or know their way around Safari with shortcuts on a Mac. What I observed in my time observing people using things I build is that they use products in anger.

What do I mean “using in anger”?

These users deal with the app in an aggressive manner. They press anything and everything. There is no real purpose behind the usage. They experience the product in a very detached manner.

There’s nothing wrong with all of this. In fact, it is a great form of stress testing. What sucks about it though is the lousy feedback you get. Feedback that sets you down the wrong path because the content never spoke to them in the first place.

Comments like “this button looks out of place”, “I like how Tweetbot does it” is irrelevant if they had used the app with a real purpose. These forms of feedback generally point you towards whether you’ve built the product right, not so much if you built the right product.

I think this contributes to even the biggest companies in the world building things that are irrelevant. Designers and developers build things to be used in anger. They go for rounded corners and bug-free apps rather than apps that flow well and really work hard to present content well (rounded corners rarely help the cause).

Reddit is the most relevant example I can think of. That thing looks like a shit website, reminds you of a dirty alleyway in the city somewhere. But it works. It’s got such awesome, random, awesome content I keep going back to it!

Back to early adopters.

If you want these special beings, find places they hang out in like forums etc. Look for people who are already solving the problem manually and bitching about it. The most important quality you are after in a person is that they are “someone who endures bugs, lack of rounded corners and much much more for the right content or solution”.

Good Luck!

How to create a great pitch video for your idea

Creating a professional video is expensive and extremely time consuming. When done right, a video can be very effective in getting users and spreading your idea to a large audience. For a small startup, videos might end up taking their entire marketing budget! I’ve been exploring ways to pitch an idea effectively while keeping time and cash investment to a minimum. Here’s how I got a great video done in 2 days and $35 for AlwaysHungry.

 

Researching for great videos

Epipheo is a great place to start. There is no doubt they make the best pitch videos! They are fun, clear and informative. I love their focus on relaying an idea instead of showing feature X and Y of a product. Of course, these videos also cost around $20,000 to make (I asked).

Take a look at their YouTube channel for some inspiration.

 

Storytelling tools

I looked for a tool that might help me tell a story specifically. I found Adobe Voice!

Adobe Voice is an awesome app that focuses on just telling a story. It only allows you to use icons, graphics and pictures coupled with music and a voice over. If you have a wonderful voice and happy with very simple graphics, this is your stop.


A little more Jazz

I wanted something a little better for AlwaysHungry. So what is similar to Adobe Ideas but has much better animations, and gives you more control over your content? Keynote! Keynote has slides, animations, graphics and all the other bells and whistles you need for a basic video. It also has a nifty feature that allows you to export your slide deck to a movie (mp4 file).

What about the icons? I immediately noticed that Adobe Voice used TheNounProject icons. It just so happens that AlwaysHungry icons are taken from TheNounProject too!

I wrote a script. You have to write a script. It helps you organise your thoughts and keep your narrative concise. You can start storyboarding your idea as you progress the script. Here's the final version of my script: Video Script.

... 
[Subway icon comes in] 
you constantly end up eating the same old thing, because you are too hungry to make a decision! 
[tone and emotion we want to convey is that it’s a downer]
...

I used simple icons, text and graphics to come up with a set of slides on Keynote. I focused on creating slides that supported the ideas conveyed on the script, sprinkling in animations where relevant. All of this turned out to be an exercise in creativity: trying to use the most basic elements to tell a story. I believe this kept me true to what I was trying to achieve.

Additionally I added some screen recordings from my iPhone to show off the app.


Searching for a voice

The right voice helps a video convey its message really well. VoiceBunny has a large number of voice actors who posses many unique attributes. They will deliver audio recordings within a day or two. My script came to about $100 all up for a VoiceBunny job.
#protip: email their support and ask for a discount :)

Another place you can find voice actors is Fiverr. Freelance community has a lot to offer on the Internet. We found @drewthedj who offered to do the voice over for just… $35! As you might have guessed, we went with Fiverr.


Getting it right first time

If you have a small budget, you want to get this audio recording right the first time around. Here’s what I did:

  • I imported the movie produced by Keynote to iMovie.

  • I started reading the script out loud while continuously playing the iMovie file over and over. 

  • Each time, I would shorten or extend the length of a section, based on how long I took to read out the script comfortably.

  • Following these steps, I ended up with about a minute long silent movie. I went on to edit the script and iMovie project further to get it down to about 50 seconds. I found that people generally leave around 50s mark for other YouTubes I've made. 

I sent the silent movie to @drewthedj. Drew was extremely professional, sent me back files with these formats: WAV, MP3, and Video with audio + background music!!! Whoa! If you need some royalty free music premiumbeat.com is great too.

I went back to iMovie and synced the audio file with my video timeline. Exported the video at full resolution and… DONE!

 

Concluding thoughts

The AlwaysHungry pitch video only took a weekend to make and it turned out to be better than a lot of expensively made videos out there! It is really a matter of channeling your creativity through some of the basic tools available to make something awesome. Focus on what matters: conveying the idea. Don't get distracted with showing off everything you have to offer. Simple things are easier to understand.

Image cache compatible with iOS7 in Swift

We recently released AlwaysHungry Brisbane app which was completely written in Swift! We used a few awesome libraries out there to pick up pace on the development. One of these libraries was HanekeSwift, which at the time of development, the only Swift Image Downloading & Caching library around! Despite the lack of competition, it is really good; with one caveat: iOS8+ only!

Given the slow adoption of iOS8, I’ve had to go back and add iOS7 support, which meant writing a brand new image caching library to be used in our app. Keep in mind AlwaysHungry’s image use is... extreme.
 

Research

  1. iOS7 has a new network stack under the NSURLSession classes. NSURLSession comes with Task classes that facilitate uploading and downloading that frameworks like Alamofire is already using in the background.

  2. NSURLCache is how everyone seems to be doing caching these days. It carries and in-memory and disk cache. An app can carry multiple caches too. I highly recommend reading this NSHipster article from @mattt. Focus on the caching policy settings.
     

Implementation Highlights

1. Creating a new cache (20mb memory cache, 100mb disk cache):

var URLCache = NSURLCache(memoryCapacity: 20 * 1024 * 1024, diskCapacity: 100 * 1024 * 1024, diskPath: "ImageDownloadCache")

2. NSURLSession with caching policy set to load from cache:

var config = NSURLSessionConfiguration.defaultSessionConfiguration()
// always try to load from cache
config.requestCachePolicy = NSURLRequestCachePolicy.ReturnCacheDataElseLoad
config.URLCache = URLCache
self.session = NSURLSession(configuration: config, delegate: self, delegateQueue: nil)

3. Structure: we need 3 methods

  • Get an image: SimpleCache.sharedInstance.getImage(url:NSURL, completion:((UIImage?, NSError?)->())?)
  • Get an image from cache without initiating a download: SimpleCache.sharedInstance.getImageFromCache(url:NSURL, completion:(UIImage?, NSError?)->())
  • Cancel a download: SimpleCache.sharedInstance.cancelImage(requestUrl:NSURL?)

4. getImage() method

When a request comes in for a URL, we first create a request:

let urlRequest = NSURLRequest(URL: url, cachePolicy: NSURLRequestCachePolicy.ReturnCacheDataElseLoad, timeoutInterval: 30.0)

Then we look into the cache first!

if let response = URLCache.cachedResponseForRequest(urlRequest) {
var image = UIImage(data: response.data)
dispatch_async(dispatch_get_main_queue()) {
completion?(image, nil)
return
}
}

In getImageFromCache, we just do this part.

Not there? Then we initiate a NSURLSessionDataTask and commit the successful response into the cache:

let task = self.session.dataTaskWithRequest(urlRequest) { [weak self] (data, response, error) in
...
strongSelf.URLCache.storeCachedResponse(NSCachedURLResponse(response:response, data:data, userInfo:nil, storagePolicy:NSURLCacheStoragePolicy.Allowed), forRequest: urlRequest) // commit it into the cache
...
}
task.resume()

5. cancelImage() simply removes the task from the queue.

I chose not to stop the download due to the nature of its use in AlwaysHungry.
 

Usage

SimpleCache.sharedInstance.getImage(request) { image, error in
if let err = error {
// thou shall handle errors
} else if let fullImage = image {
imageView.image = fullImage
}
}
override func prepareForReuse() {
...
SimpleCache.sharedInstance.cancelImage(requestUrl)
}
SimpleCache.sharedInstance.getImageFromCache(itemUrl) { image, error in
...
}

 

Happy days!

https://github.com/m2d2/SimpleImageCache

Performance of this cache is on par with what HanekeSwift was managing. It is extremely simple to use and understand. I am opening the source for this on Github so you can roll your own solutions with this implementation as a start point.

There’s a lot to be improved. Couple of things you may want to tackle:

  • Queueing the downloads by introducing a NSOperationQueue
  • Ability to cancel and resume downloads
  • Better error handling

How to make an Android App (video tutorial)

I did a brownbag session at Wotif office about how to make an Android app. It covers a lot of the basics of making an app with Android Studio.

This is an introduction session for Android. It covers the following:

  • Introduction to core concepts like: android building blocks, activities, intents, back stacks, services etc.
  • Covers project structure using Android Studio.
  • We create a basic app that downloads cat pictures from Instagram API.
  • Work with a ListView to display data.
  • Code is available at: https://github.com/dmendis/android-intro-cat-viewer
  • Cover some core concepts with resource folders in Android 

Resources:

Email me or leave a comment if you'd like to see more videos like this (much shorter ones).

2 things your app can focus on to be successful

Apps that do really well on the App Store focus on PASSIONS & PRODUCTIVITY. The higher you rank in the scale on these two categories, the better chances you have of making a kick-arse app concept that resonate with its users.

 

People are passionate about all kinds of crazy things. What's important is that passions makes us very emotional. And everybody knows emotional hooks are the best way to sell something to a consumer. Your job becomes exponentially easier if you don't have to convince them why something will be of value.

The effectiveness of the 'passion-hook' increases as the reach and the prestige of the passion gets higher. For example, fitness is a great category to be in. Everyone's emotionally invested in it, so your market size is large. More importantly, people are willing to pay to get fit.

 

Productivity is why IT exist in the world. Instead of figuring out what 28912 x 92891 is in your head or on paper, you have a calculator. If you can save time, make life easier, and return the human back its lazy couch potato stage as quickly as possible from real work, you are doing a great service. This service can worth a lot of money.

People pay to make things go away all the time. So if you are designing an app to help people be more productive, you have a great chance to make it. The bigger the problem you are solving, the higher you can charge for it. If it targets companies instead of individuals, then there is even bigger bucks to be made.

 

Then there are really good apps that combine the two. Food apps like Posse or Urban Spoon are great examples. People are very passionate about what they eat, and what says about them to the people around them. They take pride in finding little gems around the city and recommending to friends. At the same time, they are extremely productive. It saves me from having to Google for places to get lunch from when I'm hungry and irrational.

 

Of course there are other angles to succeed by making an app. You can look at improving communications and social interaction. But these are markets that may not follow the general pay for a download model that well. They are also very hard to succeed in.

If you want to keep it simple, make something that target passions and productivity. Analyse where you stand in the two scales when you are at the concept stage. Bring features in to add value in both categories as you go on. Find your own little edge in these scales that make your idea better.

As long as you are helping lazy humans be extra lazy, and help enjoying what they rather be doing, there's a chance of success.

Brief Look Back at My 2013

There was a lot that happened in 2013. Here are some of the highlights!

I learned a thing or two about Marketing

Being a part-time indie developer, I am used to just focusing on the technical aspects of making apps etc. At the beginning of 2013, I figured out that this is just not going to fly anymore. Apps we made under M2D2 were doing badly due to our lack of marketing knowledge. We honestly couldn't find anyone who was as passionate and driven to do some marketing, free, on the side. At the end of the day, I learned to how to make a better app: one with a story.

We ended up increasing our sales by a whopping 100%. When you start at a couple of dollars, jump is significant!

M2D2 became a company #winning

Suneth & I made the best app we ever made to date. I managed to buy myself an iPad Mini Retina from my earnings as an indie app developer!

I made 2 YouTube videos

Back when I was a teenager, this was a huge passion of mine. I wanted to make videos. Eventually this got sidelined with other priorities. I finally got an opportunity to try it out with the introduction of our 60Hz app's second version. We decided we needed a video as part of my own marketing plan. Having no budget set aside, I did it myself.

I Learned Ember.JS & SASS

One of the coolest frameworks around right now -- Ember.JS. If you haven't tried you really ought to. It is hands down the best JS framework ever made to date (that I've read about / tried). We decided to adopt it at Vigil for our next project.

I bought a bicycle + UP band. Lost some weight as a result. Went to a Coldplay concert. Had many birthday cakes. Significantly reduced my time on Facebook. Kept up my hate for Samsung. Tried Airbnb. Got into UX properly. Rekindled my love for Rösti.

I decided love is worth the sacrifices #YOLO

Most of all, I had a GREAT TIME.

 

There's a lot coming in 2014 to look forward to. New product launches, app launches, Europe trip, remote working and much more.

My new year's resolution for 2014: READ LONGER, WRITE OFTEN.

Making Safari Suggested Passwords Sync with Chrome

With the latest OS X Mavericks, Safari browser introduced a very convenient way of generating safe, random passwords when you sign up for a new account with any website. I've started using this feature extensively. It syncs across my iPhone + iPad beautifully as well. Only problem is Chrome...

Right now, I have a manual solution. Turned out to be a little easier than I thought:

  • If you open up the Keychain app on the Mac, You should see two items of interest: "login" and "iCloud". Chrome picks up passwords from Login.
  • Go to iCloud section, arrange by modified date.
  • Select all the recent signups and do a CMD + C (copy).
  • Navigate to login section and do a CMD + V (paste). It's prompt you for your Mac password, go ahead and enter that.
  • Chrome should now pick up the passwords automatically, sync across to all your Chrome browsers from now on.

Why make an iOS app first?

This is a regular discussion that happens under every article on The Verge about some new iOS app. So far they are all flames thrown at each camp. This poster had a really good answer with good supporting facts. I thought it was worth sharing:

mfocazio

It’s not “gibberish” – it’s fact:

1. Android users spend less time with apps. http://www.businessinsider.com/android-users-use-apps-less-2013-6
2. Android users are less likely to pay for apps: http://phandroid.com/2013/07/19/free-apps-android-users/
3. Android users don’t buy stuff with their mobile devices as much: http://bgr.com/2013/12/02/ios-android-black-friday-online-shopping/

There is a meaningful difference, and if you’re trying to make money in the mobile world, you start with iOS.

Taken from the http://www.theverge.com/2013/12/5/5178432/best-new-apps-level

The only thing I'll add to this is the ease of building and maintaining apps due to a more consistent group of devices with users who upgrade to new versions of the OS regularly.

Don't mistake this for developers not succeeding on Android. That is not true -- plenty of developers make a good living out of Android.