How did it happen? I reported the email as spam. I didn't mean to, it was a slip of mouse. Was it my fault for being careless, or Google's for putting two vastly opposite functions next to eachother?

I archive a lot of emails. Keeping inbox zero consisently isn't easy. I sometimes delete an automated message that has no historical value. I rarely report spam, since Google does a great job.

Archiving has a pretty low risk, I can always unarchive it. Same with deleting, although it may be permently deleted in 30 days. Reporting spam is a high risk, not only will it be delete in 30 days, but the next few messages won't show up in your inbox.

Why are the two polar oposite buttons next to each other? Sure, all three buttons "move the email", but I don't always think of it in those terms. And how do I un-report spam? I still can't be sure that Google knows I made a mistake.

Just a quick shift. It seems odd at first. "Back", "move email", "modifiy", "move", "more". Separating the three move buttons? Separating the action buttons by drop down buttons?

There are two types of email: good and bad. Save and tag the good ones, delete and report the bad. The buttons are aligned to your thoughts, not the email.

What else? Maybe the "report spam" button could appear after you delete an email. Google already shows an "undo" link, a spam link wouldn't be much of a stretch. Of course, this would drastically decrease the number of people who report spam.

The iPad doesn't have a way to enter only numbers into a UITextField. Sure, you can use "numbers and punctuation", but that still gives the user a chance to enter errorous data.

To use:

keyboard = [[NumberKeyboard alloc] initWithNibName:@"NumberKeyboard" bundle:nil];
keyboard.textField = youTextField;
keyboard.showsPeriod = NO;
youTextField.inputView = keyboard.view;

 Also, release the keyboard in dealloc and #include "NumberKeyboard.h".

The GitHub project includes streatchable images for most key rows, so you can modify it into any number of different keyboards. It also has the PSD; the skys the limit.

https://github.com/stuartjmoore/NumberKeyboard

But, I also learned to hate some of the non-guideline following apps. Especially the Google ones. I always knew I didn't like the Google Voice app (the app I use 90% of the time), and now I can point to exactly why!

Since the YouTube app has the worst icon, and YouTube is slowly rebranding itself, I decided to whip up an icon that matches the guidelines and their new brand direction. Have fun.

A PSD may be here.

Then, when you move your cursor over one of the tweets, you see your pointer change to the hand (the universal symbol for clickable):

The highlighted red area is the clickable area, or at least it seems to be the clickable area. It's assumed that buttons are one solid shape (most likely a rectangle). But in this instance, there are links contained inside of the entire tweet, creating the button with holes.

This doesn't seem to be a problem, there is still plenty of area to click on the tweet after all. And it's unlikely you'll try and click the non-white space (à la the instragram link), but the white space changes upon hover. The "reply", "retweet", "favorite", and "open" links don't appear until you're hovering over the tweet. So, as you're speeding your mouse cursor over the tweet to expand it, new links get in your way and cause and accidental and unpleasant click.

The design is similar to the iPhone and Android apps. The tweet is so small, and your thumb so big, that the entire tweet needs to be a button allowing you to perform actions on it. But the tweet is only one button, there are no links inside of it. This design pattern is brought over to the web app, but as it's on the web, links are added (since there's a lot more room).

I would leave the clickable areas at just:

The entire tweet will still be a hoverable area to reveal the "reply", etc. links.

Minimizing the clickable area to expand the tweet sounds counterintuitive, but I think it would greatly ease the user experience. In this instance, the area isn't being modified as I'm moving my mouse.

As a start-up darling (at least at the time), I thought Quora would have a better design. The standard iPhone UI elements weren't even the worst part. Just looking at the the screenshots alone confused me. "Home"? "Search and Add"? Add what? Notifications are a tab? None of it sat well with me.

If there's one thing wrong with the app, it's that its designed with a web browser in mind. Web apps and native apps may be converging slowly, but they still have destinctive UI elements. A web app can't look like an iPhone app, just as an iPhone app can't look like an Android app.

"Home"? iPhone apps don't have a home. There are main pages, but they are never titled "home".

Notifications are meant to seek you out, not you seek them out. Notifications are only new items for you to check out, they don't persist as an entire tab.

Search is a great option, as is adding a question. But they really shouldn't be shoved into one tab. If I want to ask a question, where does my instinct lead me? "Search & Add" definitely isn't my first choice. I don't want to search, I just want to ask a question (the system wants me to search so I don't add redundant questions). Search & add is easy to get away with on a web app because you can have a persisant textbox with the placeholder text "Search for or ask a question". App space is more limited.

Nearby seems pretty useless to me. When it comes down to it, it's just another way to search.

Profile is fine, ignoring any minor graphical errors.

Changes

The tabBar is the most important part of the app. It's the top most level of your UI. It lays out the entire organization of your content, so getting it right is nessecary. Here's how I would fix their layout:

The "Home" tab is fine in and of itself (I'll get to the list later), but it needs a new name. "Questions" works.

Search needs to be its own tab. Even if Search allows you to add a question, the user sees that as a last resort, not as an initial interaction.

Same goes for "Ask" (not add). When the user tries to ask a question that has been asked before, the app can still search and intercept them before they do. Just as with a lot of apps these days, the "Ask" tab is more of a button. It stands out and is centered, because it's an action that behoves both the user and the app.

"Notifications" is renamed to "Activity" because activity is persistant, notifications are not. I really wanted to hide the activity under the "Profile" tab, but this way keeps the symmetry. Activity being under profile wouldn't be such an issue, since users only need to tap on the tab when there is something to check out. When the activity tab doesn't have the red number above it, it's essentially useless.

"Nearby" has been completely removed and combined into "Search" (just as "Shuffle" is in "Home"). "Profile" is unchanged.

I forgot to mention the "About" button on the "Home" tab. This view is mostly FAQ and privacy policy, something apps don't usually include. Although you can't see it, the "About" section is moved to the settings app, as is with most apps.

Next?

There are still plenty of web to app translations that need to be done. Lists are definitely number one on my list, seeing as how they allow for the most creativity in this instance.

Although modal views (on iOS) can't have transparent backgrounds, because the parent view is no longer drawn. The solution? Take a screenshot and put it behind the card. It's fast and simple.

https://gist.github.com/1279713

I've been writing a simple game lately to get the hang of Cocos2D/Box2D. Out of all my apps, games just tend to sell better without much effort. The game is about a rabbit running and jumping, so of course, I need a boolean to determine when the rabbit is in the air to stop the player from hitting "run" and gaining speed while not on the ground. 

I first used contact listeners to determine when the rabbit left and hit the ground. But these were called for every body (the rabbit technically has three) and in no particular order. Since you had to make perfect contact with the ground, you weren't able to jump even if you were millimeters away from it. Even worse, the boolean would be erroneously set to "YES" if the player ran into a wall some of the time (update: figured out the bug and how to solve it thankfully).

So, I came up with another idea that I should have used from the start: determine jumping based on the rabbit's vertical velocity. The ground is flat, so there's no need to worry about hills just yet. But the same problem of not being able to chain continuous jumps arose (a big issue for a game about speed). I tried to debug it using NSLog:

NSLog(@"%f %d", body->GetLinearVelocity.y, body->GetLinearVelocity.y == 0);

Which printed out (0 meaning false):

0.0000 0

GetLinearVelocity clearly printed out a value of zero, yet it doesn't equal zero? Is it a casting problem? A negetive zero problem? How could this be? I later figured out it was something simpler. Using:

NSLog(@"%0.10f %d", body->GetLinearVelocity.y, body->GetLinearVelocity.y == 0);

Printed out:

0.0000000009 0

Yeah, Box2D has some crazy precision apparently.

Typical scroll lists just move up and down, showing a predetermined number of rows. But infinite scroll lists have much more data, never switch to a new view, and can continue to scroll far beyond the user’s needs.

They can be best categorized even further as:

• Pull to refresh
• Progressive loading
• Truly infinite

Pull to Refresh

The first such instance of an infinitely scrollable list [note: data pulled from my ass] would be Tweetie’s “pull to refresh” action. It’s very loosely infinite, but it allowed the user to see the newest tweets on their timeline by scrolling, not hitting a button or waiting for a timeout.

When the user wants to see newer items, they scroll up. But if they’re at the newest item, they hit a brick wall. The app knows the user is looking for newer data, and the server may have some, so it asks the user if they want to refresh. They can let go to not refresh or pull down further to ping the server.

Not much to say here except that it is a great way to take the user’s intended actions into account, instead of relying on them to tap a button.

Progressive Loading

Progressive loading is a lot like pull to refresh, except it’s the opposite. When the user reaches the bottom of a list, the server is pinged for older data. The alternative is to provide “next” and “previous” buttons. But, depending on the data, why make a user paginate through multiple views? If they’re at the bottom, just load the rest of the list.

This is where infinite scrolling gets interesting. The assumption is that the older data is so vast, the user may never be able to reach the end. Progressive loading allows a server to send all the data eventually when needed, instead of sending gigabytes of it at once. But, there are a few problems with loading progressively.

Smoothness

Everything about computers needs to be smooth, especially scrolling. Loading more data at the end of a list tends to create a “jump”. You’re scrolling down a page, 40 pixels at a time, and your last scroll is only 15 pixels to the end of the page. Suddenly, the rest of the content is loaded and you’re scrolling at 40 pixels again. Not very smooth.

Google+ handles this very well. They progressively load your photos as you scroll down, but the call is made early enough, and possibly only for size data, that the rest of the images fade in seamlessly. You almost don’t notice the scrollbar getting smaller and smaller.

Twitter’s web app tries, but falls a little short. The loading doesn’t occur until you reach the very bottom (causing a jump), as noted by the indicator. Scrolling is interrupted, since you can’t scroll until the tweets have loaded, leaving the user with lost input. The jump and lost scrolling makes following where you are a little difficult, unlike in Google+.

Bottom Content

I can’t believe I have to say this, but if you load progressively, don’t put content below the infinite scroll list. If the user scrolls down to click a link and the page loads another 1,000 pixels of content, that link will disappear far below their cursor.

Twitter solved this by putting the typical “bottom content” at the bottom of a right-aligned column, out of the way of the infinite list. But Facebook wasn’t so smart. They left their bottom content there, right below the list. Now, every time the user wants to click on “Advertising”, they have to do battle with the progressive loading of their friend’s news. What’s worse is how random the loading seems.

Truly infinite

I have yet to see an example of this, but I’m sure it could exist. Pull to refresh is only reloaded when there is something new, Progressive loading has a limit to how much is stored in the database, but truly infinite lists could theoretically never stop.

A truly infinite list wouldn’t load data, because data is finite, it would have to be used for something that expands forever. Numbers most likely. A calendar that scrolls (instead of kitschly paginating the months away in 3D) would be truly infinite while progressively loading the event data. Time doesn’t end, why should a calendar?

This creates a problem for scrollbars. Scrollbars tell you where you are; a sort of progress bar. They allow you to move easily within a list (although scroll wheels have largely replaced that). How would a scrollbar for a truly infinite list work?

I certainly don’t feel so strongly for or against these buttons. I’ve never really give them much thought—expect for on the 3rd generation iPod, where I had nothing but disdain for them. They work the way I expect and never misfire. Well, let’s think about them.

Pros

• Low failure rate (I’m tempted to say no failure rate)

• Sexy (If only I could find a woman who lit up)

• Notifications (WebOS alerts you without wasting battery for the LCD)

Cons

• Accidental touches

Touchscreens

We can probably agree that any phone worth it’s weight these days is a touchscreen smartphone. And any capacitive buttons are situated right below said touchscreen. Are they so different? Grazing either will result in an undesired action; people know to keep their hands off. Capacitive buttons are never moving from the chin of the phone (where nobody holds it) and always resulting in the same action (back button silliness notwithstanding). They’re more static extensions of  the touchscreen than anything else.

iPhone

The iPhone doesn’t use capacitive buttons. There’s one way and one way only to exit an app: the physical home button. Any “accidental presses” are handled by the app, because they only happen at that level. But how many times do you press that home button each time you use your phone? At least once, and sadly, it feels like the cheapest button on the phone. Double clicking for multitasking is painful since your thumb just doesn’t rotate as well as your index finger.

Android & Windows Phone 7

Android and Windows Phone 7 use three or four capacitive buttons just below the touchscreen. These are the phones that have stirred the controversy. I’ve never used WP7, but I can assume the same things hold true as they do for the Nexus S. Pressing the home button will “close” the current app. The back button will take you back one screen until the app closes. The search button will change to search mode. And the menu button will toggle the menu. These are all radically different interactions.

Accidentally pressing the home button means finding the apps icon again (who knows where you put it?). Pressing the back button means redoing your last action (or finding the app icon). The search and menu button mean pressing them once more to toggle back.

WebOS

WebOS cherishes its capacitive area. It’s more than just a button, it’s also a swipe gesture pad. Instead of wasting 44 pixels for a navigation bar just to get back one screen, WebOS phones have the user swipe back just below the touchscreen. The home button doesn’t close an app, it just pushes it back a few virtual inches so you can get to your other apps.

I’d be shocked if anyone swiped without meaning to. I can see hitting the home button unintentionally, but so what? The app just moves back a little. Nothing is destroyed and returning to your task is one tap away.

Destruction

There’s the true con: destruction. When you graze the iPhone screen, only the app reacts, not the system. When you tap Android’s menu button, it just toggles the menu—something that’s easy to undo. But when you hit Android’s home button, good luck finding that app in your mess of icons.

Confirm or Undo

Whenever the user is about to do a destructive task, the system should give them two back-up options: confirm or undo. Android buttons undo (albeit though multiple steps at times). It makes the most sense, who wants to see “do you want to close this app? Yes or No” everytime they want to do something else?

Well, WebOS confirms. If you didn’t mean to hit the home button, just tap the app again to cancel. If you wanted to close it, just swipe it up and throw it out. It’s not as simple as pressing down hard to close an iPhone app, but it’s a lot more elegant than grazing to close an Android app.

Solution

Since Android is the only one with the problem (and I’ve never used Windows Phone 7), it’s the only one that needs a solution (short of getting rid of them). Search and menu are fine, they’re toggles. Long pressing is okay, but that can be used for other things (multitasking). The best option, as I see it, is to turn home into a toggle. Currently, the stock home button does nothing on the home screen itself (although I have mine set up to load the app drawer). What if it loaded the last app? An easy undo for grazers, and a quick toggle back and forth for people who have fancy widgets they want to check. The back button has plenty of problems, but disabling the ability to close the app would be a good start (and make the apps feel more solid and safe). Oh yeah, and turn them off when I’m using a clock app at night.