Empty UITableViews with DZNEmptyDataSet

One item on my iOS 8 wish list from May was a new UIKit API for empty content views in UITableView. A simple UITableView data source method where you can return a UIView. UITableView would then intelligently display the provided UIView whenever there was no content in the tableView.

But WWDC passed and no such luck. Luckily, DZNEmptyDataSet to the rescue! You can find it here on Github.

It's easy to add to any project using UITableView or UICollectionView and it's being updated regularly.

So this...                                                                                  ...Becomes this!

UITableView with default no content behavior.

UITableView with default no content behavior.

UITableView with an empty content view

UITableView with an empty content view

I've tried many other open source projects and rolled a few techniques myself but none came as close as DZNEmptyDataSet.

Why use an empty content view? Primarily for communicating to the user why the screen is empty and how to add content. It's highly unintuitive, especially on first launch, to display blank rows (as seen in the first image). While a good UI design is self-explanatory and helpful, the default implementation is not.

In the example on the right (taken from Bug Trackr 1.2), I tell the user there isn't any content saved, what they can expect this view to contain, and how to add content. In this case, even though I have an add button at the top right of the screen, I include an "Add Bug" button in the empty content view. Both buttons trigger the same action. This makes it crystal clear that to get new content, you have to tap the add button.

It may seem obvious but, for users launching an app for the very first time, an empty tableView is jarring and confusing.

Apple's default implementation in UITableView is far from ideal and it's interesting that for most of Apple's own apps they implement an empty content view (private API). Until Apple makes their empty content view API public, DZNEmptyDataSet is here to fill the gap.

Coding Nits

But I’ll take the opportunity to point out some things I noticed.

Accessors shouldn’t be of the form getSomething. Drop the get.

#define SOME_CONSTANT 10 isn’t Cocoa-like. Better is static const NSUInteger PBSSomeConstant = 10; (Where PBS is replaced with your prefix.)

If you’re calling something a Handle, it should be an actual Mac memory Handle. And we shouldn’t be using Handles anymore.

All of your class names should have a prefix. All of them.
— http://inessential.com/2014/05/03/more_coding_nits

A sample of Brent Simmons' rules we Cocoa (Touch) developers should all be following. Some great stuff in there.

iPhone 6 Protruding Camera

Images posted on Weibo claim to show an iPhone 6 under testing at Foxconn, via GforGames. The validity of these images cannot be confirmed, but the shots do line up with previous rumours. The iPhone 6 depicted here has a protruding camera (similar to the current design of the iPod touch), rounded edges and a considerably thinner profile than the current iPhone 5s.
— http://9to5mac.com/2014/03/31/purported-iphone-6-pictures-show-protruding-camera-rounded-edges/

If Apple has made the (supposed) decision to use a protruding camera design for the next iPhone model, then clearly we're still missing a large part of the puzzle.

The obvious reason for Apple to use a camera module that sticks out from the main device body is to minimize overall device thickness. It's also a decision, I'm guessing, that Jony Ive would want to avoid at all costs. The iPhone camera has been flush with the body for every model including the current iPhone 5s. So why bring attention to it?

For the iPhone to become even thinner than the 5/5s, they would need thinner components like the display and battery. It appears, based off of leaks and rumours this far, that Apple has accomplished just that. But, they couldn't thin down the camera module any farther.

If thinness is the only reason for a protruding camera, I would rather stay at the iPhone 5s thickness. This phone is already pretty damn thin, I'm happy with it and I suspect the vast majority of users are.

Apple wouldn't make a design decision like this unless they had a great reason to and I highly doubt "thinness" is it.

Could we be seeing magnetic optical lens support? Apple has patents on the subject and this is the best guess I can come up with.

Aside from that, I'm baffled.

App Review Fatigue

When is the last time you reviewed an app on the App Store?

When is the last time you wrote a positive review?

I ask because the app reviewers have left the building. Vanished. Gone.

The number of reviews compared to new users has decreased significantly in the last 18 months. In 2010, I was seeing an average of one new review and rating per 10-20 new users. Today, it's somewhere between one out of 200-300 new users.

This drastic decline in reviews for my apps happened shortly before iOS 6 shipped, summer 2012. Is there an App Store related reason for the change in behaviour? I can't come up with any hard evidence to back that up.

It's not just in my own apps that I've seen this trend develop, it appears to be Store-wide. I can't remember the last time I looked at an app on the Store and noticed more than one or two reviews for the current version, and even then, they're never all constructive. (I'm excluding, of course, major apps like Facebook and Apple's apps because those have exponentially more downloads than the 'rest of us'.)

Users are not reviewing apps like they once did. It might be because the average user has more apps installed on their iOS device, thus less attention to give one app. It might be caused by recent App Store design and layout changes.

But my best guess is that users are tired. They're fatigued. And why shouldn't they be? They've been poked and prodded with Review Prompts for years. They've had enough.

What incentives do users have to write thoughtful, constructive, and detailed app reviews?

I see plenty of fantastic apps on the App Store with virtually no reviews and terrible apps with dozens or sometimes hundreds of nasty one-star reviews.

The incentive to write negative reviews is clear. A negative review comes from a user who is usually either angry because they feel they've wasted money, the app doesn't work as expected, or they're holding the developer at ransom because their app doesn't have feature X and they'll change their review when feature X is included. (They won't actually change their review, FYI).

For a user to write a positive review they have to be delighted enough to navigate to the App Store themselves or be prompted by the app and still be delighted after seeing that irritating dialogue. This is very rare although it does happen.

Based on that criteria, we have a broken system that favours negative reviews over positive ones. A system that provides little incentive for users to actually participate in and one that adds very little value to developers unless they're a multi-billion dollar company.

The purpose of App Store reviews was for existing users to tell potential customers about their experience with the product. In a perfect system, the sum of an app's total reviews would paint a clear picture of the product. But if an app lacks enough quality (honest, insightful, in-depth) reviews, it's impossible for a potential new user to gain any real data from existing users.

That's what's happening here and it's a downward spiral. The top 1% of apps see ever higher install rates because of the sheer number of reviews they receive in volume. The rest of the Store barely gains any traction.

The App Store review system is quickly becoming ever more skewed and irrelevant. Users and developers alike are no longer taking it seriously.

It's time for it to go the way of the dodo bird. And until the review system is either fixed or replaced by something better, I give it one star.

Dan Counsell on App Review Prompts

I’ve put together a basic set of rules I think anyone involved with making apps should follow. It’s nothing fancy, and by no means comprehensive, but it’s a good start:

1. Don’t ask at launch. Seriously, never do this.
2. Choose the perfect moment, after a positive interaction is best.
3. Try not to interrupt the users workflow, don’t be annoying.
4. Only ask once. If they’ve said no, never ask again.
5. Ask passively if possible, place it in the app settings or updates notes.

I know having to ask for ratings is far from ideal, but until Apple changes or improves the way app discovery and search work in the App Store, we’re all stuck with it. Spend time thinking about how best to ask your customers for reviews. If you stay honest and respect your users, you shouldn’t go too far wrong.
— http://dancounsell.com/articles/prompting-for-app-reviews

Totally agree with Dan. It just doesn't make sense to ask a user for a review while interrupting their workflow. Sometimes though, it's not easy to find that perfect time.

This is the approach I'm taking in my apps. Only present a modal prompt for review at the best possible time. If I don't see a clear way to do so, then users simply won't be prompted.