Design

Styling a Site for the iPhone

January 5th, 2010  |  Published in Design, iPhone

Apple’s iPhone App Review process leaves many of us stuck between a rock and a hard place. What can we do to more effectively push out content without having to deal with Apple? A month’s wait for approval for App submissions and updates isn’t unheard of.

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. Read the rest of this entry »

Tabs vs. Windowed

December 7th, 2009  |  Published in Design

This is a debate I’ve been having with a client over a Mac UI, and really only applies to my desktop UI design work. Not so much iPhone or web, but still an interesting discussion.

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.

Plan for the Extremes

December 6th, 2009  |  Published in Design

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.

What a VCR Can Teach Us About UI Design

October 14th, 2009  |  Published in Design, Rants

So, yesterday, my grandma wanted to watch an old movie (“Ghostbreakers”, starring Bob Hope) on my parents’ TV. She handed me this strange, antiquated technology called a “VHS tape”. Maybe you’ve heard of it?

Read the rest of this entry »

Make it Human

September 3rd, 2009  |  Published in Design

As humans, we tend to reach for things that we can relate to – things with familiar and friendly faces, or things with personality.

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

Read the rest of this entry »

UX Design Myths

August 26th, 2009  |  Published in Design

Loving this blog post on UX design myths. My favorite, myth number 2:

People Read

Read the rest of this entry »

Design evolution of an interface

August 25th, 2009  |  Published in Design, iPhone

TapTapTap released “Convert” for iPhone a while back. While I’m a fan of ConvertBot, this one is awesome, too. Check out the incredible overview of the UI design/revision process on it.

Also see their perspective on the app design process. I’m thinking I should follow that approach a bit more closely.

Do It In Strings

April 20th, 2009  |  Published in Design, Random

If the frameworks on which you’re building your app provide relatively easy localization, you’re hurting yourself if you don’t do as much as possible in text that can be translated with that framework. Read the rest of this entry »

Rhyme and Reason

April 18th, 2009  |  Published in Design, Rants

One of the mistakes I made early on was assuming that technical understandings can extensively limit how I design something. That is, saying “oh, it’s harder to do that way, so I’m fine with how it looks and don’t want to bother changing the look”, in cases where I could’ve made some possible changes with just a little extra work. Read the rest of this entry »