~ April, 2007 ~


Design is about taking a stand – CS icons, MTV.com and more

Over the years, I’ve had the chance to work with some top notch designers, and I always try to learn what I can from each of them. One quote I that has stuck with me over the years is from Michael Gough, who taught me that design isn’t always about finding the “best” solution to a problem, it’s about deciding what the right solution is, and taking a stand.

The original discussion about design happened years ago, during the redesign of the Macromedia website. We had decided to show hyperlinks by using a light blue background color on hover. This is pretty common now, but back then, no one was really doing this. I was wondering why we were using this method of displaying hyperlinks, and we got into a discussion about the philosophy of design. It made me realize that I was looking at things from the usability angle and he was looking at things from a different angle.

The usability angle and the design angle

Back in the 80s, I was drawn to the mac because of the philosophy around usability. I did software projects on the mac and devoured the Inside Macintosh books. I read the human interface guidelines and I thought about usability. I took this perspective with me as I worked on projects like Dreamweaver, Contribute, and so on.

When you look at interfaces from the usability angle, you think about software from a purely functional perspective. Does the customer understand how to use the thing? Does the software do what they want it to do? In a sense, you get the sense that for any usability problem, there is a “perfect” answer out there somewhere for the most usable design, and that our job is to strive toward that “perfect” answer.

Meanwhile, Michael was looking at things from the design perspective. Usability is one of the considerations in design, but it’s not the only consideration. Great designs are more like alchemy than science. Think about the designs of people like Saul Bass, Paul Rand, and Ray and Charles Eames. Their designs take a stand. They express a point of view. They evoke emotion.

The importance of taking a stand

The point of “taking a stand” is not to be needlessly different or to throw out conventional thought. In fact, designs that are needlessly controversial tend to fail, and great designs usually build on conventional wisdom (grid layouts, etc). The important thing, in my mind, is to have confidence in following your ideas and to express them in the fullest. Designs that aim to avoid controversy end up being watered down, “lowest common denominator” designs. In order to push designs forward, you need to take a stand and be prepared to face the naysayers.

Recent design controversies: Adobe CS icons and MTV.com

During the last few months, I’ve been following a few design controversies. The first controversy is around the CS3 icons. Some people love them, while others hate them. I personally love them. The more I look at them, the more I like them.

Before, I could never remember the difference between the hexagon shape and the weird one with the feather. Now, I know what everything is. Not only that, I love the saturated colors. Splash screens tend to be mostly grey or white, with some icons and text. I love the big block of saturated color I get when I launch the new apps.

Whether you like the new branding or hate it, I’m sure you can see that the new branding system has a thought process behind it with a definite point of view. I don’t think you’ll see the designers backing down from their point of view on this one.

Another interesting case study is MTV.com. They launched an all Flash site called MTV Overdrive that caused considerable controversy. Some of the concerns may have been valid (too slow to load, too much stuff going on), while others were just reactionary (Flash sites are stupid, etc). I personally thought this was a good design direction for MTV, given who they are. The MTV site needs to be dynamic, focused on video, and willing to push the envelope.

I learned, via Ryan Stewart, that MTV changed their site back to HTML. You can read about the reasoning and see the comments at the MTV blog.

Now I don’t have any insight into what happened backstage at MTV, and perhaps there were very good reasons for switching back, but from my perspective, it looks like they are not helping themselves any by flip-flopping back and forth. If you read the comment thread, you will see that there are lots of angry people (again).

So what’s the lesson here? Is it that Flash is better than HTML? Or vice versa? I don’t think so. I think the lesson is that when you go for a gutsy design, you need to really believe in it and fortify yourself to see it through. MTV went for a gutsy design with MTV Overdrive. There were some issues (it was overwhelming for some, and slow for others), and from my outsider’s perspective, it seems like they should have kept iterating on it. Again, there may have been very good reasons for the switch, but that’s the way I see it.

Does that mean I have to stop listening?

Does “taking a stand” mean not listening to customers? Not at all. In the end, if people don’t buy into a design, then the design isn’t working. The advice to “take a stand” may seem like a directive to stop caring about what customers want, but in an odd way, I feel like the advice to “take a stand” is the paradoxical answer to how to reach customers in a deeper, more authentic way.

To me, it’s a bit like the conundrum that politicians face. People say they want leaders who are “authentic” and “know what they stand for”. At the same time, if the leader doesn’t follow the will of the people, the leader is “out of touch”.

It is important for politicians to listen to the people, but not at the expense of being who they are. In the final analysis, a politican who derives his/her opinions purely from polls is a politician who doesn’t stand for anything and can’t be trusted. In the same way, a design may require iteration based on feedback from customers, but not at the expense of being what it is.

So don’t be afraid to take a stand. But listen to your customers and be willing to iterate.


More thoughts on open source Flex and community

It’s been interesting reading reactions from folks like Ted Leung and Ryan Stewart on the Flex open source announcement. I imagine that more interesting discussions are going to happen as people slowly digest the news and start digging deeper into what this all means and how it will all work.

One of my concerns around open sourcing Flex is around how we stay disciplined about what goes into the framework. As it stands, it is quite difficult for the Flex engineers to balance between the things they would like to add to the framework versus practical considerations like download size and runtime performance. We are going to make sure we don’t get bogged down in feature-itis or “design by committee”.

One thing that I think could help is a clearly articulated philosophy about what Flex is, what Flex is not, and how it should evolve going forward. One community that has done a particularly good job at this is the microformats community. In many ways, the microformats movement grew up as a reaction to some of the more ambitious movements around adding semantics to the web. Because of this reactionary nature, the value of practical, small, incremental steps was greatly appreciated by everyone in that community.

As we open up Flex development to the world, my hope is that we can build a strong, core philosophy around Flex that is similarly grounded in keeping things practical, small, and focused.


Flex SDK being open sourced

I don’t usually glom onto these news postings, on the theory that you already have plenty of blog sources for this kind of stuff. However, this is a topic that is near and dear to my heart, so I thought I’d write a little about it.

Today, we announced that we are going to open source the Flex SDK under the Mozilla public license. in my mind, this is just another step in our continued push to open up our platform to make sure that our community can feel confident in building their applications (and in many cases, their businesses!) on top of it.

I’m obviously pretty excited about this, which begs the question: should we have open sourced it earlier? I don’t think so. We have gone through quite a bit of change between Flex 1.0 to where we are now (remember ActionScript 2? remember the old pricing model? remember the huge API shift from 1.5 to 2.0?) and IMHO, it might have been more difficult to make some of the radical changes we did if we were following a completely open process.

Now, the situation is quite different. The Flex community has reached critical mass and is growing daily. The Flex SDK codebase has had most of the rough edges smoothed off of it, and we are at a point where we no longer expect huge API changes in our existing core API. Most importantly, it feels like the right time to invite the community to become part of defining what Flex is.

We are still working out the details, but I think this is pretty exciting. More details can be found here.


Asynchronous calls explained

Someone emailed me recently to ask about a case of asynchronous calls that I think is fairly common. At the risk of opening up the floodgates (no, you cannot email me every time you have a Flex question!!!), I think it’s worth answering publicly because it probably trips a lot of people up.

Note that this is a more basic (and common?) case than the stuff I was talking about earlier. For more advanced solutions, see here, here and here.


I have two loops. One grabs an Xml file that contains a list of a bunch of Xml files I use to layout data to print. (What I am doing is printing a set of documents).

So, as I loop through each, I call the URLRequest to grab the Xml to process and register the Complete event (which takes care of processing the Xml).

So if I have 20 documents, I find only the last one gets handled, the rest are ignored. I am guessing this is because the thread does not stop. I am thinking synchronous events are not an option either.

What I want to happen is one fires, it lets me do what I want to do, then the next one fires. Or alternatively, one is processed, then the next one is processed.

Am I making sense?

Yes, it does make sense, and I bet a lot of people get stuck on this. So here’s the answer.

More »


Digg API, Flash, and Flex

Digg has released a Flash API for accessing their content. The API was created by Stamen Design which is the company responsible for the cool visualizations on Digg Labs.

I’m not sure yet whether the Flash API works directly with Flex, since it’s written in ActionScript 2. However, in looking through the API, I think you may not need the Flash toolkit at all within Flex, since the “standard” API is accessed through HTTP and XML, which is built into Flex.

Does anyone know more about the Digg Flash API? Do you need it for Flex? I happen to know one of the founders of Stamen from my DJ days, so I’ll be asking him as well.