So what is it? It’s meant to be a collection of classes for Mac or iPhone, allowing your app to post links (well, the user, technically) to Instapaper and Delicious.

It needs some cleanup and more docs yet, but should be usable enough for now. It’s part of an example app project – build and play with it to get an idea for what it can do.

Download the latest zip package of the project, or check it out on Github to contribute what you can. I’m aware it’s kind of messy and my code style needs work, but I hope it’s enough to get something started.

Gruber has discussed the idea that we move in the direction of web apps. This can be a great solution, if you’re an online news site, and don’t need advanced device feedback or complex interaction. This is what we did for the ABA Journal mobile site, and it’s working well enough.We kept it simple because a large part of our audience is on Blackberry, which doesn’t have the horsepower to take on the more “fancy” effects that something like jQTouch could do. Check it out – you can take care of some of the animations and stuff that closes the gap between web and native apps.

One more thing: I recommend using this little blurb:

meta name="viewport" content="width=320"

That sizes the page to better fit iPhone, but it’s still viewable on any other browser just fine. Keep the markup simple, and do all of your special styles in CSS3. The iPhone is good with CSS3 support, but don’t place essential functionality in it if you need Blackberry support.

Use standard HTML to provide your list of stories, headlines, etc. Blackberry and iPhone both tweak the proportions/display of text based on h1, h2, h3, p, and so on. You can override those, but it’s better to use standardized markup and work with what the platforms do natively. They change those sizes to make them easier to read on their tiny screens. Blackberry also lacks the fonts that iPhone has, opting for a hideous, blocky screen font.

Don’t depend too much on typographic creativity or consistent layout. It won’t happen here. Blackberry will screw up any attempts at floating columns, so stick with a single column. Fortunately, colors are (mostly) there, so you can use color where needed.

Don’t use frames, iframes, or divs for important layout or columns. Safari and other mobile browsers change the way those behave.

Hope this helps a bit. I’ll post more on some other experiments I’m doing at a later point. This is an interesting space, now that the iPhone is bringing web standards back to the front (Flash is not part of web standards, by the way. Stop using it.). Apple and others are really innovating here, and it’s very likely that we’ll soon have the same features on web apps that we do on native apps.

I’ve seen very few cases where a tab UI can work for multiple documents in a Mac app. Tabs are okay for browsers, though that debate is only personal taste. This gets tricky with document-based apps, especially when you need to be able to drag and drop items between documents. Notice that Coda, a tabbed UI and my favorite web IDE, doesn’t need this as much as most apps (usually). Adobe added a tabbed UI on Photoshop CS4. This really got in my way, since I need to be able to move visual items quickly between documents, and copy/paste is harder in Photoshop than in a text editor (the key being the drop cursor in a text editor, which PS doesn’t have). Drag and drop is to the Mac like deep-dish pizza is to Chicago. You need to have it, and you need to do it right.

Sure, I can drag the item up onto the document tab to (hopefully) switch to that document, but it’s not consistent on all apps and is often clunky when implemented if it’s even implemented at all. On Coda, I don’t mind it, since I don’t drag source code.

Alternative design: use an iTunes-like “source list” on your big master window, with all of your documents listed there. This design can vary based on your app, but it’s going to take more real estate than a horizontal tab bar. iTunes allows this, dragging between playlists. It feels more natural than tabs when I need to move stuff from point A to point B. Bonus cookie points if you can give it the “spring-loaded folders” style behavior. When I’m still holding down the button and hovering over the target, it “flashes” for  a second, then switches to the view so I can drill down or pick the specific place to drop. The “flash” appearance adds a bit more visual hinting for the user than most of the tab implementations I’ve seen.

Ultimately, separate windows seems to be the quicker, easier option for users who are in a hurry, like me. It also allows more specific drops, rather than having to use a delay that the spring-loaded folders option would need to have (if you don’t have a delay before switching tabs, that can be another source of confusion).

I would rather that you, as a developer or designer, pick the best option for your app and stick with it, rather than making it a preference check box. Interesting note: TextMate opens new documents in a new window for me, but if I open a Rails project, it has a document list in a drawer (ew), and selected documents open in tabs. Of course, like Coda, you can control-click to break tabs out to new windows. It seems that text editors can get away with these different styles better than other apps.

Which style do you prefer? Which have you used?

Edit: Slashdot discusses this, but they’re so geeky about it that they’re not really thinking the way I am here. I still feel separate windows are better. I have dual monitors on my desk, and even my laptop has a huge screen, so space isn’t a problem for me.

What we need to do to design is to look at the extremes. The middle will take care of itself.

- Dan Formosa, Smart Design, from “Objectified” the movie

I loved Objectified, and this quote stuck out at me the most. This applies in UI design as well. I find that your best test user is the cranky, impatient one – the one who needs to have that project done two hours ago. If I can make them happy, then users with calmer temperaments will also have a better experience – often without noticing it. The angry users are merely drawing attention to the problems with your UI. When they’re stressed or in a hurry are the times when even the smallest bit of friction is magnified by a factor of ten. I find that I can even test my own UI designs on myself, when I’m home after a bad day and at my most stressed out. I test the UI, and notice things that I wouldn’t normally catch when I’m in my “builder” mode. I catch things like jQuery page load stalls or drag and drop quirks that are only “minor annoyances”. I’m not as forgiving, and after taking a ton of notes, I pass out on the sofa. But those notes are the most helpful in early design.

Okay, so I’ve used these things. Even had one in college. You insert the tape, and it plays. You also have to do this “rewind” ritual when you’re finished. But how hard could this be? So I stuck the tape into the player and powered on the TV. After two seconds, the tape was ejected without any obvious reason. There wasn’t another tape in the player, that much I knew. So what gives?

After two more tries, and a few “what the hell?” mutterings from me, I figured it out: the VCR was in an “off” state. But this wasn’t obvious to me at the time. My expectations were also different, due to my experiences with other players. This was a recent model, even including a built-in DVD recorder. But older, cheaper, and junkier players all did something this unit did not: when a tape was inserted while the power was off, the unit would assume that I wanted to play that tape. So they would power on, accept the tape, prep it, and play it. Since these older units could do it, why couldn’t a state-of-the-art 2007/2008 model do it? There’s no technical reason why not.

A few UI lessons:

1. Follow your user’s expectations and platform conventions: make sure your device offers an appropriate response to conventional user interaction. Even if it’s not quite the same reaction that they expect, do *something* – don’t just spit their input back at them and bark “no!”. For further example: if all standard Mac apps and most 3rd party apps respond to Command-H as “hide current application”, that’s what it should do for your application, too. Even if it changes the way *you* think it should work, you need to provide the user a way to make that command do what they expect – hide your app. Adobe, are you listening?

2. Provide consistent/clear feedback for modality and actions: why isn’t this working? It should have been more clear that the power was off, and that tapes can’t be played in this mode. Ejecting the tape doesn’t give me an explanation as to *why*, either. Similarly, if your device just beeps at me, is it obvious? Sometimes, better/more clear feedback would be more helpful to the user.

It drives me nuts when they don’t do user testing for these cases. Even if other manufacturers aren’t making the tape play automatically, don’t you want to do what you can to make the experience with your player more seamless and easy for your customers? If you do, then your customers will enjoy your player just a little bit more. That subconscious seed will be planted in their mind that, somehow, your product is better-build and just plain better than the others, and maybe they’ll buy your products again in the next purchase cycle.

Just something to think about.

I haven’t finished it yet, but I’m finding it very engaging – it covers how the church changed from a grassroots group of renegades avoiding martyrdom in the hands of the Romans, to being the “official religion” of Constantine, but being corrupted by his superstitions and pagan rituals (it was basically something to honor the emperor through Roman liturgy). Even the Reformation didn’t get the church back on track.

They continually go back to the New Testament, to point to what the church “should” be like. They use scripture to demonstrate how Christ removes all need for that old liturgy. I’m finding it incredibly interesting. And since I hate dry, old traditions, I like what they have to say.

Oh, and there’s a Kindle version, too.

He kept it fairly “secular” and “generic” to fit with a wider audience, as my sister noted. But I think the points he was trying to make were still there and still strong. I’m waiting for the book to arrive, to see where the intersection is, and pick up on anything that my tired brain missed that night.

In terms of things I noticed that didn’t have anything to do with what he said, it was how Steve Jobs-like it was: big screen behind him, simple clothes, glasses, close-shaved head, strangely overly-enthusiastic audience.

But what he said was still very powerful. The root topic had to do with pain, and intersecting with artistic expression. Pain shapes us, and it’s up to each of us to determine whether it’s a positive or negative result. Pain makes us honest, and pain gives us a common bond, even beyond stupid, petty things that we come up with to divide ourselves.

Like I said, I’m still thinking about it all, but I recommend checking it out – Rob Bell’s “Drops Like Stars”. He’s currently on tour, but there’s also a book. I just got it – on first page-through, it looks to be virbatim.

Slightly-related: check out what people can do creatively, despite their limitations.

Correction: The hack apparently works against anything prior to 2.8.4. So get out there and upgrade!

Whether it’s software or hardware, the things you design should be a natural grasp for other people.

Physical objects should be pleasant to the touch, and have obvious hinting – where to hold it, where to grab or pull. Software should, to some extent, imitate things in the “real world” that the user would already be familiar with. Don’t try to blaze your own trail in UI design until you’re sure that users will “get” it. By all means, please do innovate! But test it first, to be sure it’s a viable concept. Test it in all kinds of environments as well, to be sure it can stand up to whatever they decide to throw at it.

End users won’t put up with much if they can go elsewhere, so make sure you go out of your way to make it easy, make it simple, make it human.

So, here’s a few tips to make sure you aren’t being an ass, and providing truly constructive criticism…

1. What experience do you actually have producing a work like this? If you aren’t experienced, you should back off a bit from assuming something “shouldn’t be too difficult” or “that won’t take long”.

1b. Don’t assume that you know what the root cause is. There’s probably a number of deeper factors that went into what you see. Instead, do some research, and give them the benefit of the doubt.

2. Give as precise a description of the issue as possible. This mainly refers to technical products. We call these bug reports, but in order to fix the bug, we need to be able to see it happen ourselves. If it’s a visual glitch, a screenshot may help. Most often, writing out instructions with step-by-step details will be most helpful. What did you click on, and when?

3. Don’t get personal. Don’t make attacks on the person or say things like “you can’t do anything right!”. That won’t get you anywhere, and just starts a war. And, of course, I’d like to see you do better.

It’s easy to be a critic (the web is infested with them), but it takes courage for someone to put their work out for public view. Be courteous and respectful – give them kind feedback that they can use, and we’ll all be able to improve our work together.