Archive for the ‘application development’ 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).

What iPad’s Rumored 260 dpi Display Might Mean for Developers

January 27th, 2011 No comments

According to MacRumors, the iPad 2 which should be coming along later this quarter, is scheduled to have a 260 pixels-per-inch “Retina” display, though there is some dispute over whether or not the display, which has a lower pixel density, really counts as a retina display.

As a guy who (happily) used a netbook for about a year and a half as his primary computer, I think people are missing the forest for the trees. A display at 260 dpi, at 9″ yields a screen resolution of 2048×1536! My netbook, and just about every one of them of its generation (frustratingly) is only 1024×600. Doubling that resolution (and nearly tripling it on the vertical end) will make a no-doubt better, more crisp viewing experience. I didn’t dive into the first iPad because of its myriad shortcomings (and a lack of initial content), but having played with them at work and enjoyed the now flourishing application support it has, I am probably going to (possibly literally) be in line for the next gen iPad as soon as it’s available.

When I started at Appiction, they had me slicing images for development, and a lot of the projects that I got into for graphic design came in a mad flurry, where I was getting and slicing up 2 or 3 projects per week. For those who don’t know, slicing involves taking those mocked-up final art pieces and making images out of them that can be used for development. Since Appiction rarely designs things with the standard Coco toolkit available in Apple’s Interface Builder (instead relying on flashier designs even for mundane things like navbars), we would have to export out fancy task bars for the developers. It took a bit longer (one method, the Interface Builder method, literally involves dragging and dropping the navbar you want, the other, what we did on projects, involves creating an entire new object from the image of a navbar), but the results are typically more visually interesting, especially compared to Apple’s standard apps, which can look a bit more mundane by their familiarity.

In slicing applications up, it was a joy to learn that the iPhone 4’s resolution was precisely double the iPhone 3GS and below, from 640 x 960 to 320 x 480. This allowed a very simple scheme for developing applications, where we would export out both sizes for development. If you’ve ever wondered why on your iPhone 4 some of the un-updated app icons for retina display look fuzzy, that’s why. There is a lot more detail that can be shown on the iPhone 4’s screen, since each pixel is doubled.

What this means for an iPad at 260 dpi is an extremely high resolution interface, but for developers, a relatively minor headache. Apple supports the double resolution with the “@2x” extension on file names, allowing devs to simply label a navbar at 130 dpi (on the original iPad) simply “navbar.png” and the 260 dpi “Retina” display “navbar@2x.png”. The compiler handles the rest. Simple!

My friends have been asking me to talk a bit more about Android but the thing with Android is that this ease simply doesn’t exist. While Android has a bit more robust feature set for slicing images and buttons that is integrated all over the application (for instance, you can make a start-up screen for an application compatible with every Android device, past, present and future, by instituting some smarter design standards that I’ve tried to help start here at Appiction), it’s not so simple in a fully immersive application where you are redesigning the entire interface, such as a game.

Android resolutions don’t neatly scale up – rather Android supports resolutions like 640×800 and 640 x 854 simultaneously. Some of this is philosophically consistent, but in terms of providing the same robust application space (especially in gaming) that you see on the iOS platforms, I think the jury is still out. I think it’s a bit unwise of Google to not instillĀ some controls on the types of products their OS runs on, or alternatively, to provide a space in which users recognize that their device is not a “universal” device, but that it will have the horsepower and specs to run some applications, but not others. Kind of like what existed with Windows gaming in the 90’s, and to some extent, today.

What I do know is that as an iOS developer and designer, I’m heartened to hear that the iPad 2 might simply double the original iPad resolution. Doing so would demonstrate the sort of forward-thinking that will allow development on iOS to thrive for years to come.