iphone

Android's back button is a problem. A big problem.

Others have already identified this in a broad sense, but I wanted to give a few concrete examples of why I (as a guy who wants to simply port a couple apps from the iOS platform to Android) think the back button (especially) is a bad idea.

Disorientation

Mobile phones, and tablets especially, require a lot of UX work in the area of interface orientation. For my extremely-basic CNL app, I've spent hours tweaking little interface elements that change when the interface is rotated from portrait to landscape.

The tendency in iOS is to use a 'back' button with the label of the previous function/screen in a given app in a navigation bar at the top of the current screen. This allows a user to freely move about inside an app, and is pretty much consistent across all apps. Additionally, this 'universal back button' is always at the top left of the screen—just like a web browser.

I haven't seen much about this feature yet, so I figured I'd put it through its paces and share what I found. WYSIWYG editing on iOS devices is finally here! For a long time, contentEditable support has been lacking on iPads, iPhones, and iPod Touches, and it's been slightly annoying, as the only way to add richly-formatted text on these devices was doing a two-step through finding the carat characters and writing the HTML yourself.

Plus, some WYSIWYG editors (like TinyMCE) simply disabled the WYSIWYG from attaching to a textarea if it detected an iOS device. No longer, however: I've tested CKEditor (latest nightly) and TinyMCE (latest nightly), and both work perfectly (surprisingly well, in fact!) on the iPad running iOS 5 beta 6:

The above screenshot was taken while editing a page on a Drupal site (flockNote) using the WYSIWYG module and the latest nightly build of TinyMCE. You can get nightly builds under TinyMCE's 'Develop' section.

Demonstration:

Here's a video of me using TinyMCE on my iPad (it's fast, and works great!):

The second app developed by Midwestern Mac is Catholic News Live, or CNL for short. This app, which is the iPhone/iPod Touch/iPad/Android interface for the content aggregated by the Catholic News Live website, showcases a simple list and map layout on mobile phones and tablets, as well as Drupal's great flexibility.

The Catholic News Live website uses the Drupal distribution Managing News, which allows the site administrator to add news feeds that are automatically imported on a set schedule from websites all around the world. Each story is geotagged with a location (if proper locational keywords exist in the article), and then stories have latitude and longitude values for map display.

The iOS app takes these stories and allows users to not only view and read them in a simple list, but also share any story via any popular social media service (making use of the popular ShareKit for this purpose). Stories can also be displayed in a map view using the iOS MKMapView.

The Android app has similar features to the iOS app, but uses Android's built-in sharing service and the Android MapView.

Or... "Best Practices of In-App Web Browsers"

Being the usability nut that I am, I have decided that my goal of making a perfect in-app browser for various iPhone apps is an impossible task. But, judging from what I've been able to do so far, and from many different Web View examples I've seen from around the web, there are some basics that every in-app browser should get right.

I'll start by showing the in-app browser in two very well-known iPhone apps: Facebook and Twitter.

Facebook's Browser

Twitter's Browser

Fundamentally, and functionally, these two in-app browsers are the same. And, after looking at maybe a few hundred other browsers, It seems like the list of essential features of a usable in-app browser are:

Midwestern Mac, LLC worked with the Archdiocese of St. Louis to build a location-aware, news aggregating, and content submission app for the iPhone and iPod Touch. The app, Catholic STL, has three main features, and leverages many different iOS APIs.

The Parishes view (and subviews) shows all parishes (about 200) in the Archdiocese on a map (MKMapView), as annotations, and when a user taps on an annotation's details, he is shown the parish's address, various parish event times, and more links for the parish website and location. The Parishes view also has two different types of search: the user can enter an arbitrary address, and the map will show parishes around that address, or the user can search for a parish by name or by city.

Parish data is managed through Core Data, and was originally imported using a standard SQLite database, using a template provided by our app's core data model (the Base app for the Mac was very helpful in this regard!). We're working on more advance OTA syncing of this data for a point-release.

From strictly a hardware perspective, the Droid cannot beat the iPhone. (For those who don't yet know: the Droid is Motorola's 'savior phone,' which they hope will make them a prominent phone handset maker again). How can I be sure? Well, look at the below diagram:

Basically, it comes down to originality, memorability, and design.

Feature for feature, the Droid competes well with the iPhone. Google Android 2.0 is pretty cool, too. But look at the above marketing images: