This is definitely true, mostly because great programmers have learned to do some research before writing anything at all. However, even great programmers tend to be absolutely terrible at graphic design, even though the solution is exactly the same: never design what you can steal.
Well, my point was that you don’t have to be good at graphics – you just need to be good at COPYING.
For example, I think this website has a fantastic, simple layout. If I was developing a web app that had similar functions, I’d copy the hell out of it: http://www.basecamphq.com
For example, I think this website http://www.basecamphq.com has a fantastic, simple layout. If I was developing a web app that had similar functions, I’d copy the hell out of it
Why does a page full of people claiming to have uber design skills have a gigantic gray bar across the bottom that leaps and lurches all over the place when you scroll? That’s excruciatingly annoying - especially given that the bar is a completely useless vanity. And that fog effect at the borders of the screen is a blatant reduction in usability.
I did think step 2 (as linked above) of their process was great. The redesigned text was far superior. But once they started adding all those vaugue icons and the strange numbering scheme, I found it a lot less compelling.
Developers might suck at designing, but designers trying to show off are at least as bad for the user experience.
This September I had the pleasure of listening to Jeff Veen (of Adaptive Path - now Google - fame) talk at the dConstruct conference in Brighton. His talk was mostly to do with interface design choices on the web, but a lot of it is universally applicable, even outside of the web.
One of the great things about Jeff is he’s able to bring in seemingly unrelated subjects and demonstrate how they are metaphors for the decisions and problems we face on a daily basis. So when he started talking about one of his favourite book - “Sea Kayaker: Deep Trouble”, it might initially have seemed like he was digressing in a big way, but it actually contained a very pertinent message.
The book is a collection of stories from sea kayakers who’ve gotten into life-threatening situations, so as to help you learn from their mistakes. Jeff quoted one important line from this book:
“Obeying rules without an understanding of the reasons behind them creates an approximation of competence which leaves one vulnerable to the exceptions.”
The point I’m somewhat laboriously trying to make here is that simply copying a good design from somewhere else won’t necessarily solve the problem. In fact, it’s only likely to work if what you’re creating is actually identical to whatever you’re copying. If you’re making an online bookstore then copying Amazon makes sense, but that doesn’t mean it’s even remotely sensible for a website selling cars.
Unfortunately, programmers who copy design patterns for UI from programs they like aren’t necessarily even choosing the good stuff. They’re more likely to copy features which suit their own needs (as how else are they likely to appreciate them?) rather than those their end users will find of benefit.
So, to cut a long story short: don’t just copy. Find out what works best for your specific users, and do that instead.
I believe that if you use someone’s code and you improve on it there is an obligation to give them something in return. A blog review, a link, whatever.
Immature poets imitate; mature poets steal.
The one I like goes like: Success is dangerous. One begins to copy oneself, and to copy oneself is more dangerous than to copy others. It leads to sterility.
Finally, paraphrasing:
A programmer is a man who programs what he sells. A developer, however, is a man who sells what he programs.
It’s what I do! I make really crappy, basic HTML layouts. Then I fool myself into believing crappy, basic HTML layout is a good thing because it’s, you know, lightweight. Like Google!.
No! Lies! My HTML layouts ARE good! Because they are lightweight… bah, who am I kidding?
This September I had the pleasure of listening to Jeff Veen (of Adaptive Path - now Google - fame) talk at the dConstruct conference in Brighton. His talk was mostly to do with interface design choices on the web, but a lot of it is universally applicable, even outside of the web. http://sudostock.ru
The only reason why you do not like Flash is because there are too many marketers telling good programmers what they want rather than asking them what would be best. Flash used for the correct reason - i.e. to add high performance ‘pizzaz’ without ‘in your face’ crap is really good.