High Priest of App Design | Hacker News Reader

High Priest of App Design

online.wsj.com

125 pointsmitmads38 comments

A developer who is a designer. The ultimate goal. This is what most people/companies don't get when they want to build an iOS app. That the developer SHOULD be the designer. Especially on iOS. Yet startups still waste a ton of money of some UX monkeys, some designers and a developer.

Just get one or two guys (depending on project size) who can code AND design. It's always going to be more efficient and better.

Sorry but why the derogatory UX term? Yes it'd be great if everyone could do everything, but that's not realistic on most projects.

Most startups don't stop and think about it. They end up looking for all parties not thinking about the cost benefit. It's cheaper _and_ better with a developer who can design.

It's much harder to find somebody who is really good at design and development than it is to find somebody good at just one of the two. As soon as you have enough fulltime design and fulltime development work, you can have people who specialize in each rather than people who split their time between the two.

It costs more not to. And specialise is such a bullshit thing to say. A developer has a better approach to design than a designer that doesn't know the ecosystem as good as the guy coding.

As a full-time mobile developer, I have to call bullshit on your claims. The vast majority of mobile devs I've met are only semi-competent on design, if not entirely incompetent.

Sure, the perfect mobile person is someone who has a deep understanding of the code and incredible design skills and taste - but what you're talking about is a unicorn. I'd be surprised if there were more than a few dozen of these people in existence.

Here in the real world your choices are:

- Mediocre-to-shitty engineer with solid design skills. He/she will shit all over your codebase and mask a boatload of technical debt by how beautiful the app is (until your crash reports roll in, or it's time to add features).

- Good-to-great engineer with mediocre-to-shitty design skills. He/she will create a solid, stable, extensible codebase but the app will range somewhere between "buttons goes in right places" and "buttons WTF".

On the other hand, there is an increasing demographic of designers who do understand the ecosystem. I'm lucky enough to work with some of them, who understand the nuances of touch target sizes, gesture-based control, etc. They're a little harder to find than your typical web designer, but they're a hell of a lot more common than your unicorn engineer-designer-fused-archon-deity.

A good engineer pairing with a good mobile designer is a combination far easier to achieve than hunting a near-mythical figure.

Those are massive generalizations. Yes, plenty of engineers have terrible taste. Plenty of designers have no deep knowledge of data-structures. It's status quo to compartmentalize talent. This attitude is so entrenched in my experience, that it's best to pretend that you don't know anything about design if you're working in an engineering department. But, a different level of insight in design can occur when the designer intimately understands the technological constraints.

Hahaha, those are the choices you give me? I am not going to debate this any further, you've made up your mind.

"near-mythical" huh? Good to know.

You don't need to know how to write Objective-C to understand conceptually how a mobile app goes together--and good interactive designers do. Maybe you have not worked with any yet?

I think the negative responses are coming from the fact that you say the developer SHOULD be the designer. As people have pointed out below, this is a rare combination, and hard to achieve at business scale. But, I gotta say that I agree in general that this is a good direction to move in. You see it in aerospace, industrial design, automotive design, architecture -- fields where aesthetics are intertwined with the technological constraints of the medium. When pg talks about what a developer working on their own can achieve, it's logical to extend that to what a developer who is also a designer can achieve on their own...

I was unimpressed when Apple removed their 'refresh' button in iPhone 'Mail' and replaced it with a pull-down gesture. How would a someone who has never before used a touch-screen device know how to refresh the list?

I've been having lots of conversations recently about the lack of affordance in touch interfaces. To some extent, this is simply because the visual language hasn't developed yet - when you see something engraved on a 3d plinth in a desktop application, you know that it's a button that can be clicked. Touch interfaces haven't got to this level yet. Pretty much the only widely used affordance I can think of is a folded corner to show that you can swipe to turn the page, but even that is inconsistently applied.

How do you know on an android contact that you can swipe sideways to SMS and the other direction to phone? Or even that swiping horizontally in either direction does anything at all? I could imagine some universally agreed way to indicate this, perhaps very subtle visual hints or gradients or a system where if you press and hold without moving you get a set of icon overlays that show you what you can do.

There are a few different options, but to form a useful language they need to be widely adopted.

One of the articles that triggered these conversations was "No to NoUI" http://www.elasticspace.com/2013/03/no-to-no-ui which laments the modern tendency to hide interactions.

Plain old drag and drop on desktop computers, which I guess has been around for at least 30 years by now (disclosure: figure out of the air, not researched) still hasn't developed much of a visual language.

It's almost impossible to know when you can drag and drop things, and the only way to learn is to start trying by dragging on random UI elements. Of course, knowing what happens once you drop them on something that cares is just as impossible as knowing what you can drag in the first place.

Sorry if I sound pessimistic, I hope development and focus is better now, and of course touch screen devices are in front of a much wider audience which might prompt a more rapid development of some standards.

Pull to refresh makes a lot of sense where you have a vertically scrolling list with the most recent entries at the top. The user will discover it naturally as they look for more entries past the current top one.

However I've seen it used in different contexts (eg. a web browser) where it's less easy to defend.

Other, similar gestures:

1. Swipe to delete

2. Shake to shuffle

How would someone know what the trio of "min, max, close" buttons do on Windows?

The smartphone market has reached a level of maturity and ubiquity that we can start setting down a baseline for knowledge, and build on top of it.

It happened to the PC before, and it's happening to smartphones now. The original iPhone was criticized (especially in demographics like ours) for being insultingly shallow and toy-like. This is the smartphone becoming more complex now that (nearly) everyone has had a go.

Mail checks for messages on launch and at intervals by itself. If the user doesn't know the gesture, they still get their messages. If the design blocks the user, then it's a problem. It is also very easy to trip over the feature by scrolling the list.

Yeah, I hate pull to refresh and a lot of these other "innovative" gestures. It's much more efficient to just have a refresh button, even if it's not as sexy.

The same way you and I learned how to use it, I think. I don't really recall being trained on it. One day my refresh button was gone, and I was just scrolling and dragging around, and "Oh what's this do?"

If this hypothetical person has never used a touch device before, they'll be stuck on the "scrolling and dragging around" step, but it won't be long 'til they stumble upon the pull-down.

Wow, not a single screenshot in the article...

> Mr. Brichter was the first developer to create or help popularize app features such as pulling on a touch screen to refresh a page, panels that slide out from the side of a screen and the "cell swipe," which is swiping to uncover a list of hidden buttons.

Actually, all of these three examples seem bad to me. I guess such hidden features make sense on an iPhone with small screen and one button, but there always has to be some indication that additional buttons are there. Conformng Android apps have a menu button, either hardware or on-screen, and you can always be sure to find functionality there. I really don't want to have to swipe around to find expected features.

Well - the drag-down to refresh feature is discoverable. It's what you naturally do to "scroll up" - and when you're at the top of the list the same gesture turns into "refresh". It's one of the ones that don't need to be taught when I've done user testing.

I didn't know who he was before reading this, but much respect to him. Truly awesome ideas.

loren gave a great talk at stanford. it was a while back but still interesting.

http://www.youtube.com/watch?v=7Zd3iNOXTow

I still don't think most devs know what to do with the 'hamburger button'. Although some follow Brichter and use it as a handle to slide a side panel out, I've also seen it used strictly as a toggle to slide the same pannel out (OSX 10.8, OrderAhead). In other cases, I've seen it used to just reveal a popup options menu (Chrome) or act as a handle to reorganize lists (iOS).

Some consistency here would be nice.

Yeah a big problem on iOS is that Apple use it to indicate history while everyone else basically uses it for a sidebar.

Though I kinda blame apple here as they seemed to have started to introduce this after the sidebar use got a foothold so they aren't making it easier.

I've used the 'hamburger button' in my designs, as it's become a standard UI pattern, but I really dislike it.

It's an abstract icon that says "here's a bunch of hidden stuff that you're probably looking for"

I like it when used to simulate the affordance of a textured control that you can use as a virtual tactile handle, but as a symbol that represents 'menu'... I think it's a flawed convention.

The "hamburger" button is very strange element. It's often used in panels that slide horizontally, in which case the "grip" is going the wrong way. In my mind, the button would work in the physical world if it was rotated 90°. I've never been able to find out where it came from through, baring it's first appearance to me in the Facebook iOS app.

Yes and no, I did that in my most recent designs, but a touch grip is a skeuomorphic affordance -- which is fine as long as the control bar is always skeuomorphic as well. As you move more into a flat design, the 3 bars as a grip makes less sense.

It may have existed earlier, but the earliest I'm aware of it was in Path - who also invented a couple of other UI bits themselves (background-pan images, for example).

It definitely existed much earlier on the desktop. Avid Media Composer, non-linear editing software first brought to market in the late 80s had it. Not sure at what point it was added, but remember referring to the hamburger menu in the mid to late 90s.

What was interesting to me in this piece is that he lives in Philadelphia, not Silicon Valley. In contrast to all the "there's not enough developers!" and "everything happens in the valley - you have to move here", there's someone who is universally recognized as a leader in this industry, and he lives in Philly. Perhaps more companies expanding their views beyond who lives in a few square miles on the planet might discover, nurture and benefit from more "outside" talent.

> In contrast to all the "there's not enough developers!" and "everything happens in the valley - you have to move here"

I see these phrases most commonly come from people who work with makers, not the makers themselves -- they're probably busy making, and not paying attention to sweeping statements of "truth".

Interesting (and cool) that he came to design with a EE degree, so he really does understand the entire stack, from elegant user experience down to the p-n-p junction.

Maybe he does know all of it but that is not directly implied. Just because one is keen on the two endpoints doesn't mean you've also got all of the creamy filling. There's quite a bit in between that one can be ignorant of and still be effective.

same /w Bret Victor. likely no coincidence.

I've noticed that EE actually has a lot to teach software engineering in terms of creating and designing systems - architecture, composition, testing etc are much more mature in that field. A lot of the ideas we 'discover' with regards to software seems to be old best practice / fundamental in that field.

Things like designing modules that are separate, reusable and fully testable (Remember ICs?)

How interfaces translate to action, too. We even call the process 'wiring' to this day.

You'll be surprised at the number of UX and design folk who have come from a engineering/dev background. From conversation it's a lot more than many folk seem to expect.

Reply on news.ycombinator.com