Tilt Controlled Views

Recently, I've been working on some views that adapt to the device's motion. The lighting, shadows, and reflections of these views simulate how light would behave on these views if they were three dimensional, and there was a single, overhead light source. These have been inspired by recent work done on the Now Playing screen of the new Music app in iOS 6. The original TLTiltHighlightView reminded me to get working on these views that I wanted to recreate when I first saw the Music app in iOS 6. I've put them all in one project (now not properly named) with a demonstration file. I plan on separating these out and making them a bit more customisable.

Cancel | OK

There's a big debate of what the ordering of two-button dialogues should be. Should "Cancel" appear on the left or right of "OK" ("Cancel | OK" or "OK | Cancel"). There are certainly arguments for both sides.

The argument for "OK | Cancel" is that, at least for those who read left to right, is that you will see the action you most likely want ("OK") and will press it. This argument says you don't need to read cancel because you've already decided on what to press. There are several things wrong with this. Designing for the use case that users will not and should not read the second button (often a word or two) is an awful idea. The only people that should be able to navigate effectively through an interface without reading the second option are users that are extremely familiar with the interface and know all of the interface's dialogues. If a "pro" user already knows the interface well, the meaning of buttons being on the left or right is almost meaningless. The pro user will immediately move their cursor, stylus, or finger to the button and activate the correct button. Now, less talk about the new user that is not familiar with the dialogue box. I think it's safe to assume that the user will read all options before choosing one. If they read all the options, the more likely option will result in having to read the affirmative action, then the negative action, only to go back to the left and read the affirmative action again. This makes the user have to move their eyes in three places (after first reading the dialogue's title and body text) and move their eyes in two directions (first to the right, then back to the left).

Now, so far we've only talked about positioning based on how fast the user will be able to glance at the dialogue and decide what to press. What about which decision makes more logical sense? Again, the answer is also negative on the left and affirmative on the right. All of these are assuming the native language is read left to right and all these answers should be flipped with languages read right to left. If one reads in one direction, that direction should be representative of moving forward, and the opposite side is representative of moving backwards. Affirmative actions are typically seen as moving forward, and negative actions are moving backwards. Let's look at a dialogue book like a page in a book. If there were two buttons at the bottom of the page that would either bring the user back (re-read) or to the next page (continue), the user would certainly expect the button on the right would bring them to the right and continue reading, where the left button should bring them back.

In summary, buttons with negative actions on the left and buttons with affirmative actions on the right.

Finally, a related argument is the naming of the buttons. The buttons should always always always be labelled with the actual action they perform and not a generic yes/no answer that is dependent on the text above it. Answers like yes/no are very often unclear and can frustrate users when deciding which one is correct and can create undesired outcomes. A very common dialogue, the save dialogue, should have buttons labelled as "Don't Save" ("Cancel" can work in some contexts) and "Save". Not only does this make it more clear on what each button does, but it also makes it great for those pro users who love to skip reading the body of the dialogue box.

Growl and Mountain Lion's Notification Center

I worked on something called Roar last weekend. It was a small project I started from scratch to help deal with Growl and Notification Center notifications. It would let you easily add a matrix of radio buttons that would let you either choose to send notifications to Growl, Notification Center or neither. It would only display the Notification Center preference if on 10.8 or above. Then, in terms of code, you would send your notification to one place and in there it would decide where to send it to (Growl or NC). However, after all that work I realised that I should not have done this in the first place. Notification Center has some great preferences built in to show or hide notifications from apps. Why should there be *two* places to control notification behaviour? There shouldn't be. I ended up deciding to display the preference for Growl on Macs running 10.7 and below and show no notification preference at all for Macs 10.8 and above. The app will now automatically send notifications to Notification Center on Macs 10.8+. If the user wishes to disable this, they can disable it in Notification Center preferences. I'm sharing this because if you ever find yourself in this situation, I highly recommend removing the preference entirely and leaving Notification Center to handle it for you. That's one of the beautiful things about Notification Center. I am considering returning to Roar and making changes to reflect what I've learned.

Second Talk this Semester

Today I gave my second talk of the semester about where iOS Passcode is headed. Hopefully I'll have an update to be able to submit for review by Thanksgiving. Then I can finally continue working on Sonar. I gave a quick demo of how Sonar works.

What Passcode Is and Isn't

I just want to clarify what Passcode is and isn't. I do not ever plan on moving Passcode to some central server and storing passwords— that's not the point. The point is that the passwords are never stored and are regenerated every time you want access to that password using SHA256. This means that you can use the app even without internet connection, in fact, I take that very seriously. No data is ever sent from Passcode, whether it be the website, extension, or iPhone app. I've been working on the iOS app for Passcode more than I had originally planned. I'm designing the iPad version of the app and it will function as a universal app. Designing Passcode for iPad has proven more difficult than I thought. I should be done with that soon and putting that through the App Store approval process. There's also going to be an added about menu (don't worry— it won't get in the way). It will be there to explain what the app is, how to use it, some tips for easier and faster use (who wants to spend time in a password app?) and add the ability to contact me for support. Passcode also has the ability to securely store your master password. It was previously stored as just a setting ( [NSUserDefaults sharedDefaults] ), but has been upgraded to taking advantage of the iOS Keychain! I've been getting an overall positive response from those who have downloaded it from the App Store, and have been contacted by a few for translating it into other languages. With some help, I plan on having Spanish, French, German, and Italian Localizations for this update. I've learned a lot about the way iOS deals with different localizations, and it's pretty neat!