Category Archives: User Experience

No perfect iPhone size

Some people bought the iPhone 6 and then went back to the 5S. Some people bought the iPhone 6 Plus and then tried the 6. Some worked their way up to the 6 Plus after adapting to the 6. Some never upgraded to the 6 or 6 Plus because both are too big.

Marco’s post is a good formal summary of a few write-ups I’ve read this week:

“Having used an iPhone 6 full-time from its launch until these 6 Plus experiments over the last few weeks, I can confidently say that neither phone is extremely well-designed. Both have nontrivial and completely avoidable flaws. But the 6 Plus has bigger advantages over the other phones, while the 6 seems to sit in a mediocre middle ground.”

The lesson from all these switches couldn’t be more clear: there’s no longer one perfect iPhone for everyone. What works great for one person might be terrible for someone else. I personally love the 5C design — the size of the screen, the way the plastic feels in my hand, flipping or spinning it on my fingers without worry that it’ll slip, using it without a case, adding a little color to my life — but many people never even tried it because it contains underpowered hardware compared to the latest models.

Apple would be crazy to discontinue any size. I’m more convinced than ever that we’ll see a 4-inch 6C alongside a new 6S and 6S Plus later this year. They won’t have identical specs, and that’s okay. I’ll happily pick the 4-inch model even if its camera is a year behind the cutting edge. The iPhone market is so ginormous now that I know there are millions of people who feel the same way.

Footnotes follow-up (and the Newton)

I expected to get a little more negative feedback on my footnotes blog post than I did. Most feedback was pretty good. Thomas Brand agreed but also wrote:

“That being said, footnotes can be fun when used sparingly. They lend themselves to the kind of personal anecdote common to the tech blogs I read. If you are going to use footnotes to break up your articles, Bigfoot.js is not a bad way to do it.”

Definitely. If you’re going to do footnotes, might as well do them with the best user experience possible.

Thomas has had some really good posts lately. Before it expires off his home page, don’t miss the recent one on the Newton MessagePad 2000:

“I doubt a 25-MHz ARM710 would have been very effective as a laptop replacement, and it the Newton engineering team knew it. That is why the MessagePad 2000 was simultaneously designed with two different CPU architectures and its own form of Universal binary.”

I couldn’t afford a MessagePad 2000 at the time, but I still have my MessagePad 130. Along with my original iPhone, I’ll never part with the Newton — a wonderful device to use and develop for that was way ahead of its time.

iOS 7 and UI debt

Jared Sinclair writes about iOS 7 as a squandered year for third-party developers:

“Fast-forwarding a year, the effect that iOS 7 has had on third party development is disheartening — which sounds like a fatuous thing to say, since there have been so many well-liked redesigns over the past year. But that’s the rub: the vast majority of third-party developers’ time has been spent redesigning and reimplementing apps to dress the part for iOS 7.”

I agree with Jared that it was a sort of lost year for app features, but Brent also has a point:

“Jared argues that iOS 7 wasn’t urgent, that evolution rather than revolution would have been fine, since customer satisfaction was extremely high with iOS 6. In retrospect I agree, but were I at Apple I would have argued that the situation is like tech debt — UI debt — and it’s best to deal with it quickly, completely, and early.”

They had to deal with it all at once because UIKit’s look and feel didn’t really evolve the same way Mac OS X usually does, a little each year. Even Aqua, the most dramatic change ever to the Mac’s UI, was fairly straightforward for developers to adopt; if you stuck with consistent Mac controls, you got a lot for free. There was very little of that kind of consistency on iOS because developers frequently built their own custom UIs which had to be thrown out when iOS 7 happened.

Tint color misuse

It has been nearly a year since the first iOS 7 beta, and something about tint color still bugs me. In fact it bothered me enough at the time of the early betas that a filed a bug on it with Apple, something I very rarely do. The problem isn’t so much in the concept of tint color, which I like; having a consistent color for buttons and links, especially now that buttons are so understated, makes a lot of sense. The problem is the implementation in apps that use tint color anytime they want to highlight something, whether it is tappable or not.

Here’s an example in Apple’s calendar app. It uses a red tint color for buttons, but it also highlights the current day with a round circle using the tint color. It looks tappable, but it’s not.

Calendar

And here’s an even worse example, from the App Store app. “Categories” in this screenshot is a button, but “Paid” directly underneath it — same blue, same font and style — is just highlighted to show that you are viewing paid apps. It’s actually “Top Grossing” that is the button.

App Store

These kind of usability mistakes turn the great potential of tint color into a disadvantage. It’s like underlined text on the web that can’t be clicked. Apps should use tint color to improve usability, not to become even more difficult to use than if everyone rolled their own button styles.

Here’s what Apple’s iOS 7 UI Transition Guide says:

“In iOS 7, tint color is a property of UIView. iOS 7 apps often use a tint to define a key color that indicates interactivity and selection state for UI elements throughout the app.”

But that’s not specific enough. The app screenshots above are following this rule, and it still looks wrong. Bold text or a gray background for highlights are much more effective to show selection state than tint color. I would completely avoid tint color for selection state except for controls that have 3 or more segments, such as a tab bar, and even then sparingly. Highlighting a 1- or 2-segment control with tint color is always going to be confusing, because the selected segment looks like it can be tapped.

With this in mind, fixing the App Store app is a simple change:

App Store

(You could make the “Top Grossing” button blue or not. I don’t think it’s necessary in this case.)

The best iOS 7 apps I’ve seen follow the spirit of Apple’s guidelines, but they know when to push beyond Apple’s built-in apps and when to pull back and do less. Tint color seems like an obvious case of where we should be more consistent and strict than Apple intended.

Layered glass

Nate Barham describes iOS 7 as layered glass:

“The best developers will see iOS as an operational model, not a visual one. Imagine a Tapbots app that, instead of removing the cute ‘I’m a twitter robot in your phone!’ aesthetic, doubles down on it. Zooming metal plates, ratcheting gears not shadowed from without but appearing from within the device, only now it isn’t a robot-esque layer over the stock controls, the UI becomes the character that the developer envisions—even more so than it has ever done before.”

I really like this post, but I’m not totally sold on the paragraph quoted above. Done right, it could be brilliant. But this is a very difficult thing to pull off, keeping the playful spirit of Tweetbot with a lighter, minimalist iOS 7 UI.

And related, if you missed Christa Mrgan’s recent Macworld essay, she also covers how iOS 7 will use depth and motion to switch from “faux 3D to real 2.5D”, with an example from Adobe’s After Effects. Makes me wonder if designers will need new prototyping tools.

The $229, camera-less iPod Touch

Ahead of WWDC, Apple dropped the 4th-generation iPod Touch from their lineup and replaced it with a slimmed down $229 iPod Touch. To achieve this lower price, they made a big sacrifice: no rear-facing camera.

Most surprising to me is that this change comes just weeks after the iPhone’s Photos Every Day commercial, one of the most beautiful ad campaigns Apple has ever run. Removing the camera from the iPod Touch transforms it from a peer of the iPhone, capable of the same kind of photos and videos, to nothing more than a game and internet device. It is the only shipping iOS device that can’t be used as a traditional camera.

As we know, people frequently use even the iPad as a camera, holding it up to take pictures at concerts, their kid’s basketball game, and at any family gathering. When all you have is a cheap phone, you absolutely want to use the iPad as a camera, because it means you can sync and share the photos.

My daughters have the older, smaller-screen iPod Touch and frequently use the camera with friends. Instagram, in fact, has become very popular with teens and pre-teens. Can you imagine how great it would be to have grown up in the 1980s, for example, with the ability to take essentially unlimited photos? Angry Birds may have taken the mobile spotlight when iOS went mainstream, but in a dozen years when these games are just a fun memory, we’ll still have some of the JPEGs, first-hand accounts of life in middle school.

I’m sure dropping the rear camera was a very tough decision for Apple, especially thinking about wanting more memory and speed to run iOS 7. But I’d rather have no FaceTime, slower CPU, less memory, and only 8 GB of storage any day of the week if it meant I could take photos. The rear camera is priceless.

Design in grayscale

Adam Keys has several tips for programmers, to make our web sites look better by keeping things simple. I often just use grayscale, too:

“Most important: design in greyscale. Color is hard and can lead to tinkering. My goal is to get in and out of the front-end bits quickly, so tinkering is the enemy. Greyscale is one dimensional, greatly simplifying matters. Give important information higher contrast and less important information or ‘chrome’ less contrast. Now you’re done thinking about color.”

These days I also start everything with Bootstrap, which adds great defaults for layout, buttons, and text. It makes everything looks better, right away. It’s not a replacement for a designer, but it does save hours (or days) of getting the basics up and running.

Little Outliner

Yesterday Dave Winer and Kyle Shank launched Little Outliner, an impressive JavaScript outliner that uses HTML5 local storage. It’s also completely hosted on S3:

“Thanks to the W3C and to Werner Vogels (for persisting in getting the ability to access the root of a domain from an S3 bucket). As a result, we get unlimited scaling with zero investment. Consider this an endorsement for both innovations.”

I used Frontier a lot back in the earlier days of the web, so I’m always looking out for what Dave does next. It’ll be fun to see what they build on top of this.

Three ADN clients for iPhone

Lots of new people are joining App.net. If you’re one of them, welcome! In this post I’m going to briefly review 3 of the most popular iPhone clients: Netbot, Felix, and Riposte. You can’t really go wrong with any of these three apps. And if you’re looking for a Mac client, my current favorite is Kiwi.

Netbot

Netbot is nearly identical to Tweetbot. It shares most of the same source and all of the same UI design. That common heritage is great because it’s familiar to fans of Tweetbot, and it allowed Tapbots to launch onto App.net in a big way, leapfrogging all other clients that were under development at that time.

But the familiar design is a double-edged sword. Not just because the App.net API will evolve and diverge from the Twitter API, but because if you switch between both Tweetbot and Netbot often, you may need to be careful that you remember which app you’re posting from. This was a problem for me since I no longer post to Twitter, and the last thing I wanted to do was accidentally leave a new post there after a 5-month absence.

All the usual features you’d expect are present in Netbot: timeline, mentions, private messages, multiple accounts, and sync with Stream Marker. It even has an iPad version, which you may want to pick up even if you chose a different primary app on the iPhone.

Netbot also has one big feature that most App.net clients don’t have: post search. This is not part of the core App.net API. Tapbots rolled their own search server so that they could offer this feature inside the app.

Sidenote plug: if you want search for all the posts from anyone you’re following, and your own posts, consider my web app Watermark. You can subscribe on the web or in the iPhone version.

Felix

Felix is possibly the most mature and actively maintained of the App.net-exclusive apps. You can tell from his App.net posts that the developer is passionate about App.net and determined to keep making his app better.

The current version supports all the basic features as well as push notifications, narrow inline image previews that take the full width of the screen, iCloud sync for drafts, starred conversations, and a brand new feature in version 1.5: collapsing posts you don’t want to see, similar to Twitterrific 5’s muffling. The only omission is that it does not yet support multiple accounts.

Felix is also unique in that it is the only one of these 3 apps that is not free. The other apps are counting on the Developer Incentive Program to send them a check each month instead of relying on traditional sales. Felix is a good value at $5, though, and the price shouldn’t stop you from trying it out, especially as it is a very small amount compared to the paid App.net subscription itself.

There are a number of gestures in Felix. One interesting shortcut — which may also be familiar to users of Twitterrific 5 — is swipe right to quickly start a reply. I personally found that this breaks the illusion of gestures as direct manipulation, though. Since swiping to the left pulls forward the conversation, doing the reverse swipe should go back to the timeline. (Update: There’s actually a setting in Felix to switch this behavior.)

Felix also added a clever trick in its post composition window. You can swipe the text view to move the selection cursor one character over, or use two fingers to swipe across an entire word at a time. This saves a lot of time tapping-and-holding and fiddling with the magnifying glass. Felix is packed with little details and shortcuts like this.

Riposte

Riposte is beautifully done, with a clear design and a simple left/right gesture system to navigate through anything in the app. By default, there is no toolbar or tabs; everything is full-screen. Following Netbot’s lead, the developers of Riposte have decided to make their app free, and they have written up some thoughts on why.

Multiple accounts are handled well and it’s easy to switch between them. Like Felix and Netbot, push notifications are supported. Riposte uses large square inline images. It’s got a great interactions view that shows users who have recently followed you or starred your posts.

Riposte mirrors Felix’s compose text view gestures, and Riposte was the first to introduce 2-finger swipes in that text view. I love that both apps now support these gestures about equally, and hope to see many more apps steal this feature soon.

Since it doesn’t have tabs, switching between timeline, mentions, global stream, and other views is done through a slide-out panel, popularized in early apps like Facebook, Path, and Sparrow, and now very common everywhere, including my own Twitter app Tweet Library. It’s a swipe and a tap instead of the single tap of Netbot or Felix, but it is space-efficient and fits the flow of gestures in Riposte.

While Riposte holds its own against the competition, I think it will be chosen most not for its features but for its design. The striking full-screen look and consistent, discoverable gestures make this app feel great. It also has probably the most readable conversation view of any app I’ve used, where the focused post appears immediately and then is surrounded with the full conversation using smaller text. That design is even maintained in HTML email when sending a conversation from the app.

Business vs. user experience

Some companies seem willing to do anything for a profit. The worst domain name registrars and their pages filled with up-sells. News blogs that spread articles across several sections to increase page views. We see examples all the time of blatant attempts to increase sales just a little at the expense of usability.

But the reverse can also be a mistake. For example, my own Tweet Marker. I wanted the setup user experience to be so effortless that the user merely needs to flip a switch to enable it in their favorite apps, or do nothing for the apps that choose to use Tweet Marker by default. There’s no formal registration, no prompt for an email address.

Now I find myself with 500,000 total users who have tried Tweet Marker, but no way to follow up with them to see if they are interested in upgrading to the $1/month subscriber plan. The service is, frankly, a financial failure. More like a charity experiment than a business.

I’ve been giving this a lot of thought, and introducing the subscriber plan was the latest part of a renewed effort with Tweet Marker. I’m determined to make it work, even if it’s too late to shift the balance between business needs and user experience to something that makes more sense.

Safari extension for Tweet Marker

Since introducing the Tweet Marker $1/month subscriber plan earlier this week, I’ve received a few questions about how the Safari extension works, and whether Watermark customers will also receive the new features. Yes, Watermark subscribers automatically have access to the Tweet Marker extension, which can be downloaded here.

I’ve prepared a screencast to show how the extension works. It’s about a minute long, and you can view it right here.

Thanks to everyone who has already subscribed to either Tweet Marker or Watermark.

Favorites in Tweet Marker Plus

favorites sidebar I’ve written about saved filters in Tweet Marker Plus, and now I’m happy to announce the latest new feature: favorites. Tweet Marker Plus now grabs your favorites from Twitter so that they’re included in the searchable archive. The UI is better too, so you can tell at a glance what tweets have been favorited, and a new sidebar link can show just your recent favorites.

A few days ago was the 3-month anniversary of Tweet Marker Plus’s launch. This is a significant milestone for me because all the early subscriptions were only billed once every 3 months. For most subscribers, this week is the first time recurring billing will have kicked in. (New subscribers are on monthly billing, which is a lot simpler for customers to understand and for me to predict.)

I also rolled out some other fixes tonight, and improved performance for how background tasks run. Enjoy.

Bootstrap CSS

I’ve been using Twitter’s Bootstrap in an internal project at VitalSource for a few months, and over the weekend I finally switched to using the CSS framework in Tweet Marker too. The layout now works in more browsers and provides a much better foundation for design changes. It also allowed me to integrate this excellent date picker.

Here’s a short screencast video showing the date picker in a new browsing feature in Tweet Marker Plus. I’m very happy with how this turned out — both the look and functionality. On the server the date ranges are implemented with a Sphinx query, so they can be combined with search terms to help find old tweets.

Saved tweet filters

When I created “Tweet Marker Plus”:http://tweetmarker.net/plus, I thought I was creating a new way to search Twitter. Limit the search to just people you follow and you can store more tweets, and more relevant ones. But as I’ve been adding new features to it, I’m realizing that Tweet Marker Plus is really a new kind of Twitter client — a client that has search and filters at its core.

Here’s what the sidebar looks like in my Tweet Marker Plus account:

saved filters

Seems simple enough. But quickly switching between saved filters is very powerful. Because Tweet Marker is routinely fetching new tweets in the background, even when you haven’t opened your web browser in days or weeks, there are no gaps in the timeline. When I use a filter, it’s showing me everything that any of the people I follow have said since I first started using Tweet Marker Plus.

I’m excited about this. I’ll keep adding features and growing the storage, to make Tweet Marker Plus the best value $2/month could possibly get you.

10 years and 37signals

Every year on March 9th, as SXSW is getting started, I like to mark the anniversary of this blog. This time it’s the 10th year.

“My second post back in 2002”:http://www.manton.org/2002/03/ernest_kim_and_jason.html was about a panel run by 37signals. I wrote:

“Ernest and Jason really get it — I hope they inspire some designers to think about web sites in a new way, and finally start focusing on usability and page load time and cut the fancy graphics, roll-overs, and animations.”

This was a couple years before they reinvented themselves as a software company with Basecamp. As the “new Basecamp launches this week”:http://37signals.com/svn/posts/3129-launch-the-all-new-basecamp, it’s fascinating to think back on how far 37signals has come. The web is bigger now and more complex. Subscription web apps are everywhere. But I think the focus on performance that drove Jason Fried and his original co-founders to promote simple design in that SXSW panel a decade ago is still very much at the heart of what 37signals does.

The Daily

“David Barnard chimes in”:http://davidbarnard.com/post/5649151852/orchestrating-magic on The Daily:

“The carousel is a fun bit of UI (at least in theory, it’s still a bit laggy and jittery for my taste), but there’s just no way to quickly deliver enough content to make the carousel usable. The front page and table of contents, on the other hand, could likely be fully delivered in the 4-5 seconds from the launch of the app to the end of the launch animation. Sending users directly to the front page (or potentially a redesigned table of contents, but I wont get into that) will make it feel as though the app has been magically filled with content.”

David makes some great points. Put another way, if some of their design decisions were too ambitious for their technical plumbing to keep up with, they should update the design and optimize it for speed. With such a mainstream app, though, you can’t really win. I’m sure if it was only fast and not fancy, it would have been criticized as too bland.

The initial criticism of “The Daily”:http://www.thedaily.com/ always seemed overblown to me. It’s not perfect, but they got some of the difficult things right: navigation that makes sense, original content, good layout, clear subscription model.

Off and on for the first few weeks, I would read several articles each day in The Daily. There were a couple crashes and glitches, but nothing that made the app unusable. If no one else had been complaining, I’m not sure I would have noticed anything so wrong it was worth mentioning.

They can make it faster and polish up the rough edges over a few subsequent bug fix releases. And maybe enough of the fundamentals are right that they can get pretty far even without the design changes David suggests.

Now that I’ve “written a few e-book apps”:http://www.vitalsource.com/, I can say with certainty that getting the basics right is more challenging than it looks. Other traditional companies moving their content to the iPad have launched much farther off-course than The Daily.

Tweetbot

After about a day of using Tweetbot, “I said”:https://twitter.com/manton/status/58723721728360448:

“Tweetbot gets nearly everything in the UI right. Love it. But.. it’s a basic client. I still think the future for third parties is features.”

I only got a few responses, most defending Tweetbot as something special. I agree, and there’s a lot to be inspired by from it. In an odd way, though, just being the best Twitter client isn’t enough.

“Marco Arment writes more”:http://www.marco.org/2011/04/18/ben-brooks-on-tweetbot (following a “post from Ben Brooks”:http://brooksreview.net/2011/04/appsuration/) about why Tweetbot isn’t for him despite being such a good client:

“A new Twitter client that essentially offers the Twitter app’s features, but in different places, isn’t enough of a difference for me to switch. If anything, it supports Twitter’s ‘don’t make full-featured apps’ position. Maybe they were right.”

The problem isn’t that third parties shouldn’t make full-featured clients; it’s that they shouldn’t make clients that have exactly the same features as every other client. If Twitter discourages all apps from being made just because many will fail, we’ll miss out on all the things Twitter will never add to their apps and platform.

I see three compelling reasons to use Tweetbot 1.0: the design, swipe for conversations, and related tweets. The last is actually in the Twitter API — I’ve been meaning to add it to Tweet Library — but it’s not yet documented outside of an email message to the dev mailing list. Congrats to Tapbots for being the first I’ve seen to add it as a high-profile feature.

Last September I wrote about “next-generation Twitter apps”:http://www.manton.org/2010/09/next_generation.html:

“I believe we’re about to see a third generation of clients that will go way beyond what the web site can do. There was worry when Twitter bought Tweetie that it would destroy the third-party Twitter market, and sure, some developers will fail or be discouraged from trying to compete against a free official product. But really what it does is raise the bar — that to succeed Twitter clients should be more than just a one-to-one mapping between UI and the Twitter API.”

I hadn’t announced Tweet Library yet when I wrote that. Now that I’ve shipped it, I believe even more strongly that we haven’t seen anything yet from Twitter apps. Tweetbot is a great 1.0 and my go-to app on the phone because it’s better in lots of small ways than anything else. But that it’s not for everyone is actually great news. I hope there are plenty of unique features still to come from a variety of other apps.

Consider this: Tweetie already “won” the market. No matter what we do as Twitter API developers, none of us can ever have the most popular Twitter app. This frees every app to focus on its core strength. For Twitterrific, that’s a unified timeline; for Echofon, that’s last-read sync; for Hibari, that’s keywords; for Kiwi, that’s themes; for my own Tweet Library, that’s curation.

What’s Tweetbot’s core strength? For now, overall user experience, not standout features. But I’ve been a Tapbots customer long enough that I’m excited to see where they take it.

For more Tweetbot discussion, check out “this collection of tweets I made”:http://tweetlibrary.com/manton/tweetbot1.0 about the launch.

Tweet Library filters

“John Chandler wrote a nice post”:http://www.byjohnchandler.com/2011/01/28/filter-friday/ on the filters he uses in various Twitter apps. Here’s a clever one for “you missed it”:

“I try to limit how many people I follow so I can read most of what they say. So, if they preface a tweet with something like ‘If you missed it,’ or ‘In case you missed it,’ I probably didn’t.”

As I mentioned in the comments, I have a few filters I like too, such as filtering out all old-style RTs. I even experimented with filtering out all hashtags. It’s great when I want to completely un-clutter the timeline of gimmicky tweets, but I can keep the filter toggled off when I have more time to read.

The advantage of how I built filters in “Tweet Library”:http://www.riverfold.com/software/tweetlibrary/ is that they are dynamic collections inside the app, kind of like smart playlists in iTunes. This means while it filters the junk out of my timeline, I can still occasionally go and review what it filtered out.

(I just submitted Tweet Library 1.2.1 to the App Store with a handful of bug fixes. Hopefully it’ll be approved soon.)

Next generation Twitter apps

I’ve been thinking about and playing with the official Twitter app for iPad since its release last week. The best praise I can give Loren Brichter and his team for the UI “stacking” breakthrough is: I wish I had thought of it.

But it’s clear after an informal survey of friends, and listening to folks on Twitter, that the UI might be too clever for its own good. Many people can’t quite figure out if they love it or hate it. And on top of the UI risk, Twitter for iPad doesn’t bring any new features to the table.

Third-party Twitter clients won’t be wiped out by this. So now what?

The first Twitter clients (led by Twitterrific for Mac) provided a quick way to check on your friends without visiting the web site. The second batch of Twitter clients (mostly on mobile) provided a full replacement for the site.

I believe we’re about to see a third generation of clients that will go way beyond what the web site can do. There was worry when Twitter bought Tweetie that it would destroy the third-party Twitter market, and sure, some developers will fail or be discouraged from trying to compete against a free official product. But really what it does is raise the bar — that to succeed Twitter clients should be more than just a one-to-one mapping between UI and the Twitter API.

One feature is filtering. “TweetAgora for iPhone”:http://tweetagora.com/ has muting and an interesting live aggregation view, like a client-side extension of Twitter lists. “Hibari for Mac”:http://www.hibariapp.com/ recently shipped with an attractive UI and keyword filtering, muting, and integrated search results.

And there’s other stuff I want to see, like archiving tweets and better search and curation beyond simple favorites. I’ve been working on some of these too, in a brand new iPad app for Twitter. I can’t wait to share the details as it gets closer to release.

Not unlike “Marco’s post on the subject”:http://www.marco.org/208454730, my hope is that free apps and paid apps compete in separate worlds of the App Store. When Twitter for iPad shipped it jumped to the number 1 spot in free apps, but maybe you don’t have to compete directly with that. Maybe if you hold your ground somewhere in the top paid list, that’s enough to find an audience.

NetNewsWire production process

I like “this Flickr set from Brent Simmons”:http://www.flickr.com/photos/brentsimmons/sets/72157623879850432/ showing the stages of building NetNewsWire for the iPad. It’s exactly the process I’m going through right now with my new app. Get some placeholder views and tables in there, then iterate, each time filling in more of the missing pieces.

iPad interface design is also proving to be much more difficult than I thought it would be. Concepts that work on the iPhone don’t necessarily translate to the larger device, and there are very few iPad apps to draw inspiration from. There’s no standout app from Apple’s lineup either, at least not in the way that iTunes 1.0 defined nearly every Mac app to follow. With the exception of some very basic ideas like splitviews collapsing in portrait mode, and a generous sprinkling of popovers, I’ve yet to see much consistency from new touch apps.

Apps that have had the biggest influence on me so far: from the iPhone, Birdfeed and Pastebot; and on the iPad, Mail and Twitterrific. Send me a reply “on Twitter”:http://twitter.com/manton if you have any other recommendations.