Tag Archives: iOS

The Design Brilliance, Intentional or Otherwise, of Windows Phone for Indie Devs

Posted on by
2

Working in the Worldwide Developer Relations team at Palm has made me spend a great deal of time thinking about the pain points in the mobile ecosystem for small, indie app developers. You know, those one-man or two-man shops who are writing cool new apps simply because they love doing it–and aren’t averse to making some money on it in the process.

It’s a challenge to get noticed in a sea of apps of course. And in those happy circumstances when the indie developer’s app does indeed show up in a list of search results (in this case, let’s say I’m searching for “alarm clock”), the indie app developer faces another challenge:

hmmm, which ones am I not even going to consider?

Your icon looks unprofessional compared to those who had the means to get a professional icon done, or the design chops to do it themselves. Nobody wants to download a bad app, and fairly or not, the icon is the first impression people get of your app. When I see a bad icon on iOS, I am more hesitant to download the app for fear it may be bad. When I see a bad icon on Android, I am even more hesitant to download the app for fear of it being not just bad, but a security risk.

What’s nice about Windows Phone is their Metro design language makes it easy for people who would rather be spending time in the IDE than in Illustrator to still give their app an icon that looks “professional” and congruent with the overall design scheme of the OS, and one that will be given a fairer consideration by would-be shoppers. Observe the hypothetical fart app I made (the result of ~3 minutes playing with shapes stencils in iWork’s Pages app) and pasted into a WP7 homescreen: MetroFart

MetroFart

Creating 2-color, high contrast simple line drawings is much easier and faster for someone to pull off than to make an icon fit into iOS.

Those who don’t think there is something to be said for the effectiveness of minimalistic, 2-color designs can take their case up with this guy:

Daring Fireball

Daring Fireball, by John Gruber

Of course, just because developers CAN make such an icon for a Windows Phone app, doesn’t mean they choose to. As this picture I grabbed from PocketNow makes clear, some developers are opting to go Metro, while others go for a more traditional idea of an app icon:

WP7 apps

Screengrab courtesy of PocketNow.com

Given Windows Phone’s market position, this is a great solution to get apps that look better without the sort of leverage Apple has. Apple has enough market weight and gatekeeping power to be able simply tell app developers to make a prettier icon or they won’t get in the App Store.* Android has the same weight and gatekeeping leverage (or does it?) to force developers to make nicer icons, but it doesn’t seem to care to. Windows Phone 7 has created an opportunity for those who prefer grepping to gradients to not only make an icon more easily, but one that looks better than something they would have made if left to their own devices (case-in-point: the icons of most Android apps–whose icons, seemingly lacking any guidelines from on high, are of varying styles, shapes, perspectives, etc)

A sample/smorgasbord of Android app icons

I am not saying the WP7/Metro icon solution is better than iOS–it bears repeating that I love the beautiful full-color icons that some iOS developers are capable of creating–rather, it is simply different, equally valid, and exceptionally appropriate for Microsoft’s current position in the market and its need to do whatever it can to be as friendly to indie devs as possible. Microsoft should be applauded for trying something new, rather than going for a bad imitation of iOS icons.

The real question is if Microsoft did this on purpose, or if they simply stumbled into this as a happy result of Metro. Given the considerable number of apps in the WP7 Marketplace with bad icons, I’d guess it’s the latter. Microsoft really should make an effort to push these indie devs toward more “Metro-ish” icons. It’s in the interest of devs, users, and the Windows Phone platform alike.

——

* While I applaud Microsoft for making it easy for developers to get away without being great designers, I applaud Apple for doing the exact opposite. It is a matter of what role each of these platforms plays in the mobile universe–their dharma, if you will. I’m going to talk more about “platform dharma” (with apologies in advance to Hinduism!) in a future piece.

Advertisement

If You See a Close Button, They Blew it

Posted on by
48

–UPDATE: Hello readers of Marco’s blog! I’m John Kneeland and enjoying my 15 minutes of fame. Feel free to follow me @SirKneeland on the Inter-twits.–

Apple’s iPhone wasn’t the first touchscreen portable device, but it was the first one that didn’t make you want to stab yourself (or the device) with its stylus. One of the many reasons for this was that they were the first big company to realize that a touchscreen should not simply take desktop metaphors designed around a mouse and cursor and shoehorn them into a tiny touchscreen being used with your fat fingers.

One of the most obvious ways in which this is apparent is the replacing of small tiny buttons designed to be hit with a fine point (a cursor or stylus) with much larger buttons that can be accurately tapped with a finger.

Except, of course, for when Apple simply shoehorns desktop metaphors into a touchscreen:

I hope you brought your stylus...

The most egregious example of this interface inconsistency is in the teeny tiny close buttons that pop up on the iOS interface when you want to close apps in the app switcher, delete apps from the homescreen, or close a browser tab. it’s even worse in Apple’s new iOS notifications system, which decided being hard to use wasn’t enough and it should be hard to see as well.

Now featuring low-contrast colors for added inconvenience!

Naturally, since iOS made this mistake, Google made the same mistake when copying iOS designing Android.

Apparently great artists steal bad ideas, too.

In fact, the Android one may be even worse than the iOS one because while the iOS button is located halfway outside the window object’s border and thus catches the attention of the mind that identifies these jarring aberrations in shapes, the Android button is completely nested in the window.

How to avoid using the close button then? People still need to close things after all. I think there are two valid methods. In increasing order of awesomeness, they are: holding down for a contextual menu (exemplified in Windows Phone 7), and swiping away to dismiss (exemplified in webOS).

CONTEXTUAL MENU

Well MS stuck with the teeny tiny close button in their browser windows, they have made a great contextual menu system in other areas, such as app management on the homescreen: Hold down your finger on something, and a contextual menu of actions pops up.

This successfully avoids the problem of having the teeny tiny close button. It also is potentially extensible as it allows for a large number of relevant contextual choices (for example, archive vs delete in Gmail). but runs the risk of replacing the teeny tiny close button with a teeny tiny text menu and leaving it open for the user to accidentally select the wrong contextual option. It also can wind up being used by app developers as a lazy catch-all for actions, leaving users with too many options, rather than forcing the developers to spend more time thinking about minimizing complexity and putting these other options elsewhere.

SWIPING

Swiping things away is, in my opinion, the most natural way to dismiss things as it is the most similar to how one might get rid of things in the physical world–toss them away!

webOS swipe up
Just swipe it away. No teeny tiny buttons required!

Of course, swiping has some problems of its own in terms of extensibility (it has none) and discoverability. In a few years the average user may be sufficiently ‘trained’ in expected touchscreen behaviors to know to try swiping, but for now any system using a swipe gesture should be sure to educate their users on the availability of swiping, ideally on device first-run.

Bottom line, to paraphrase Steve Jobs, is this:

if you see this button:

They blew it.

It should really be called the “blew it button.” I want to see a touchscreen OS that doesn’t have a single one of these (and unfortunately webOS added them in 3.0 for deleting apps on the homescreen). It’s one of those rare cases in which I can say Palm should take a lesson from Android and look at how removing an app from Android’s homescreen involves dragging an app to the trash:

Now THIS is how you delete an app!

Building a Better Tablet Browser Part I: The problem

Posted on by
23

I have an iPad and a TouchPad. I also had a Samsung Galaxy Tab for a week but didn’t find Honeycomb good enough to warrant a permanent spot in my collection.

One thing that strikes me is how awkward tablet browser interfaces seem to be.

Stretch Armstrong can go back without moving his hands. You and me, not so much.

What the tablet makers have done is take the exact same browser paradigm popular on desktops (with Honeycomb even going so far as to bring desktop browser tabs) and shoehorn it into a tablet screen. Since all the buttons are not within the range of where the fingers are, the user has to move their hand from where it was naturally and extend it up to hit the buttons. Instinctively, this just doesn’t feel right. I’ve tried to break this down into more definable reasons:

  1. Economy of movement is good, and the tablet browser as is does not minimize movement well. The less a user has to move to do something, the better. All the more so on a touchscreen, which requires more movement to get from point A to point B (it’s a 1:1 ratio of movement in life to movement on the screen, whereas a mouse/trackpad amplifies the movements you make in a few inches of space to cover a much larger screen). While it may require an inch or so of movement to flick a PC’s cursor 6 inches up to the back button, it requires the full 6 inches of movement for your finger on a tablet. Bad.
  2. Unlike desktops (or even laptops), the hands are not just used for interacting with a tablet; they’re also used for holding it and supporting its weight. If the user has to move their hand to do something, they have to shift how they are holding the tablet every time they need to use one of the browser’s buttons. Bad.
  3. Accuracy suffers. Pick a key on your keyboard and try hitting it with your wrists resting on the hand rests. Now lift your entire arm and try zooming into it with your finger. It’s not difficult (unless you’ve been hanging out with Jack Daniels), but it does take somewhat more effort than the former. I think this is because when your wrist is stable, you only have to move your fingers whereas you have to use your entire upper arm for the latter, which involves more “moving parts” and takes more effort to get the same level of accuracy. Bad.
How can we fix this? I have my ideas which I’ll discuss later. What about you?