Archive for the ‘application design’ Category

Designing Scaling Projects

April 7th, 2011 No comments

>A lot of times, people have ideas for apps or games that ultimately will rely on a lot of actual content. This generally is user-generated content, which is a smart model, as it has worked for tons of Web 2.0 companies such as Blogger, MySpace and Facebook. These sites work by providing potential users with rich content that they can access just by joining in, and existing users the ability to add to a content base that they can claim ownership of (this is my profile, these are my blog posts, or these are my friends).

The problem, of course, is that these potential apps don’t (yet) have any users, and thus, they have no content to draw new users in with, and nothing for anyone to yet take ownership of.

I have some ideas for how new applications can overcome this hurdle, but to protect client ideas, I’ll throw out a mythical application. Lets give it a really Web 2.0-y name, “CHECKR”. CHECKR is an application that let’s you scan product bar codes and write/share quick reviews of the product with people within the CHECKR universe or your friends on social media outlets.

Now obviously, when CHECKR first launches, it has 0 users and 0 reviews unique to CHECKR. How would you, as a user, feel if you downloaded this promising new application, only to find that there’s a vast wasteland of content? This dearth of content must be hidden at all costs!

One way to get started is to link your application up with a set of already-there data. Many services have APIs that would let you pull location data or information from them, within their guidelines. For instance, a similar database to what CHECKR is attempting to build can be found on, when a product is pulled up. Amazon has done a fantastic job of cultivating a culture of reviewers at the ready, and all of that data is sitting there on Amazon’s servers, hopefully waiting to be exploited with an API. Even if Amazon doesn’t allow that data to be mined, it’s almost assured they have competitors who do. Services like Yahoo! BOSS allow you to aggregate and shape your own custom search engine using data already mined. Parsing and presenting this data (initially) or using it as a “Reviews from Web” button (after version 2) would help ensure your users can use the app.

Second, sites like Amazon, but even more importantly, applications in this generation, generally do a very good job incorporating game elements into their review processes. Giving users virtual currency, badges, differently-colored usernames, special titles, and other minor rewards helps integrate them into the community you’re building.

Finally, a lot of applications (a LOT of applications) are ultimately drawing some marketing data from it’s users. The demographic data that would be required is hard to get… If you had an app you’d never heard of, and they suddenly asked your first name, last name, a photo, gender, home address, etc, what would your reaction be? For most people, it would be to run, but I bet many of you have shared that much and perhaps more to Facebook. The difference between your idea and Facebook is that Facebook has already demonstrated value. It’s like a pool party that you’re invited to where you can see everyone’s already jumped in and is having fun. It’s rather natural to want to join in.

Once CHECKR has demonstrated a use, and if I design it in such a way that people naturally want to give it good data instead of garbage data, people will populate it with rich analytics data. When people put their high school yearbook photos on Facebook, they are thinking that they’re sharing it with friends, not with Facebook. No one wants to tell Foursquare where they are, but they don’t mind telling their friends where to find them. If your users need to input their real names to ensure their friends can find them, or want to put their address in so they can find the hottest local reviews, then you’ve succeeded in rolling in the analytics into the application’s design naturally.

However, one thing to note is that as you move along through the process, that you roll out features that might “expose” your application’s lack of early content. While it may be cool a year down the line to have a badge for people who have done something in the application 25 times, to make that a search filter criterion in the application’s first iteration is to both put a feature that’s impossible to use, but also a feature that gives away your application’s newness.

Another way that you can avoid this is by building a scaling function directly into your application from the start: to say that when you have 0-10,000 users, the application is more forgiving with when it, say, leaves a posting active or how long it leaves a spot on a map marked. When it has 10,000-100,000 users, it can be less forgiving, and when it has more than 100,000, the application can assume the info is essentially in real time. In CHECKR, for instance, maybe I put a little pin on a map where someone has submitted a review “recently”. When I have only a few users, “recently” could mean within the last week. When CHECKR is a household name and verb, I can let reviews only stay on my map for a few hours. My goal, either way, is to hopefully ensure that the application looks the same to a guy who found it on day 1 as the guy who found it 3 years after it launches.

And ultimately, that’s my goal- I want to appear to be a tightly formed system that users will trust and populate. While I have moral qualms about harvesting analytical data from users, most app makers don’t. Yet, if they force users to give that data, they will end up with unsuccessful apps from at least one standpoint (either they get garbage data, no users or both).


April 1st, 2011 No comments

So I haven’t been able to write for a while. February was a tremendously busy month for me. At Appiction, we both closed and finished off the biggest single-app deal that we’ve ever done in a project that… I can’t talk about yet. (But I was happy to be the lead designer of it!) Another one of our Appiction apps that I designed has been getting some major ink, but I don’t think I’m officially allowed to say anything about it yet either. And earlier this week I was happy to do the dev handoff for another project I designed that I’m not allowed to talk about (but honestly, I should be able to… it’s the coolest little application for its niche ever).

And my friends at OAK9 have been putting in some of the best work in that I’ve ever seen on an iPhone video game for an upcoming action title that… I can’t talk about yet. (But I was happy to be the lead designer of it, too!)

And meanwhile, production has kicked up on my desk as I’m working on the iPad (read: HD/enhanced) version of a game that has been bumping around at Appiction since I’ve been here (back in September). I was able to join the design team for the iPhone version, but the iPad version? I’m developing it myself. So believe me, I’m super excited about it and would love to talk about it, but I can’t yet.

So, that’s what I’ve been up to lately. Informative, no? 🙂

Let’s have some standards, people!

January 7th, 2011 No comments

A funny Tumblr blog is making the rounds in the office today – Read The Fucking HIG. It’s full of horrible examples of developers trying to reinvent the iPhone interface, and with the new Mac App Store launching yesterday, a clusterfuck of terrible designs given a virtually unlimited development space for application UI.

I’ve talked about the Human Interface Guidelines in this very blog before, and they’re incredibly important. At Appiction, the first thing they had me do was read the HIG and get acquainted with its requirements and guidelines and I’m a better designer for it. A lot of people think restrictions tend to inhibit their creativity, but at a certain point, the fact that actual people are going to use the app, and are going to come into it with a set of assumptions about how an app works, becomes more important than needing your special “two-finger swipe backward to go back” design.

It’s not about what the phone/OS is capable of, it’s about what’s reasonable to expect people to deal with before they close your app and move on to one of the other hundred solutions that could probably also solve their problem. The less impediment you put between your user and their enjoyment of the app, the better. Period.

[link Read The Fucking HIG]

[link Or just read the actual HIG! :)]

My Number One Pet Peeve In iPhone Apps

January 6th, 2011 No comments

Allow me to rant for a second here…

The iPhone sprang from the meaty loins of what? The iPod. In fact, one of the coolest things about having an iPhone is having an integrated iPod. It even has its own app.

Given that the iPhone has essentially swallowed up an iPod Touch on its way to being a smartphone, one would think that it, or maybe more appropriately, developers, would implement better controls for allowing its iPoddy goodness to shine through. Read more…

Mobile Wireframe Gallery Gives Preview of How Companies are Building iOS Apps

January 4th, 2011 No comments

Building software from a design standpoint has always been a bit more art than science. Prior to working for Appiction, I used to do really raw mockups in Photoshop as quickly as I could to get the point of the screen across to the developer. A lot of times, these were very, very abstract, as all that was really important was the placement of elements on the screen.

Preliminary wireframes for an eReader application I designed a couple of years ago. Yes, there are things I'd change about both of these wireframes now!

App development remains a fairly new frontier, and while there are Apple’s standard Human Interface Guidelines and Google’s Android Developer Guide, most of us are still figuring out the best way to communicate to developers our design visions in a way that fits both a functional and aesthetic sense. The MOObileFrames blog is a collection of wireframes from various companies showing their process as they take the first step to cement their mobile visions into concrete realities. Hopefully you can use some inspiration from what other companies and individuals are doing to apply to your own designs. Good luck!

Categories: application design, mobile design Tags: