Managing UI Development Expectations with Flex
DIGG IT!
11
Comments
Published
Wednesday, November 14, 2007
at
8:38 AM
.
The default skin in Flex is pretty nice and I have regularly seen this cause problems with consulting projects. The issue is that when you mock up a user interface it looks good by default and the client thinks that development progress is much farther along than it really is. While I was consulting I used a default skin to remove the shine from the Flex UI allowing me to better manage client expectations.
Clients want to see a steady progression of development and if you show them shiny polished ui very early in the development process it can lead to confusion. Clients rarely realize how much work it takes to wire up a UI but they can see visual improvements. My recommendation is to use a plain CSS skin for Flex and dial the chrome down to black and white. It allows you to focus on control layout in prototypes vs having the chrome distract your client.
Here is a simple test. Which UI is more complete?
See my point. To the non-developer manager the first UI looks much better and more complete. The key is to show them the plain one, then later in development work on the custom skin and reveal your development progress later. You will get some strange looks from other developers but your client will have a better set of expectations and the plain skin helps you explain the progress of their application.
SAMPLE PLAIN CSS PROJECT
SAMPLE PLAIN CSS PROJECT SOURCE
Here is a sample project that contains the plain css style. Feel free to use it to manage your clients expectations.
Cheers,
Ted :)
The Napkin Skin is good for this too.
Not always true. ;)
It's ok if give your fresh client with default skin in early stage, after several weeks you need at least change skins to be a little more shiny but no default skin that will be bored to them. And give them final polished UI to make them happier another several weeks(months).
But if the client has experience with Flex already, default skin no longer work for them, more shiny please. :)
Actually, I believe Adobe was smart in giving us a complete looking skin right from the start. Although I can see some scenarios where we don't want to get the client too excited about the progress, this is not my standard approach as a Flex consultant.
I'm in the business of taking jobs posted in craigslist calling for a "Flash Developer" to work on an enterprise data-driven project, and going in and convincing the prospect to go from Flash to Flex. Using the default skins to show how much progress I can make the first day usually does the trick.
Although, having said that, I did have one client try to integrate my Flex app into an existing HTML app, and they needed me to de-shine it so the integration appeared more seamless visually. So I had to go into the CSS and try to create more neutral-looking HTML-like controls. This would be a perfect CSS for that client.
In Alan Cooper's About Face 3, he touches on this subject. One downside, as you say, is that it gives the impression that you are farther along than you actually are. The other downside, is sometimes it gives the user a biased view of the UI which can stunt any further exploration.
It turns out that the closer to "hand-drawn" it looks, the better. I think the Napkin Skin might be a bit too far. I think the skin Ted shows is good. I have used a similar technique to flatten the Halo style just for these reasons.
excellent!! great work..
Is it bad that I like the "plain" skin better than the default Flex skin?
Personally, I don't like the default flex skin (Halo), and actually think some of its changes over Flex 1.5 were for the worse. In general, there's too much in the way of gradients, bevels, transparency, etc.
I like the clean look of the plain CSS. And to me -- and this may be just because I've looked at a lot of vanilla flex apps -- the default Flex skins screams "unfinished" while the plain CSS says "finished!".
So, I *think* what you're saying is that we can get the app working with the plain skin, play golf for a few weeks, spend 5 minutes restoring to the default skin, and make it look like we were REALLY busy in between......right?
:-p
David
David,
I am saying that the default Flex skin can give a client a incorrect impression that your app in development is more complete than it is. Clients can grock visual changes to an app and the cannot comprehend the code that makes it work. My take is that if you set things plain to start with, you can manage expectations a bit better.
You are supposed to be playing golf consistantly through development, not in a burst period of no work.
Cheers,
Ted :)
I completely agree with increasing the UI polish as the project progresses. But where you start can also be important.
Napkin is certainly fun and cool, but totally inappropriate IMHO for mock-ups or draft-quality interfaces. At the very least, you run the risk of the client wanting their final product to be with Napkin. Ugh.
Napkin goes too far. Presenting a consistent level of abstraction important. Napkin makes sense if you typically include some restaurant napkin-sketches along with a typewritten proposal... (umm, no comment).
Lessening the polish of the draft imagery has long been a technique of the 3d CG world. A cute trick is to turn off (or lower) anti-aliasing until the (near) final revision. One reason this works well is because up until that point, as the project comes together, the client sees a lot of progress, until near the end when the changes tend to be less and less obvious. A quick and easy boost in quality always makes you look good.
That said, flat colors are a good idea, but so are other things like using a less-appealing typeface. Say, Courier, for example. Arguably, the WinXP or Aqua-esque skins would be better choices. They look like the interfaces the client the client is accustomed to seeing. Just about anything Halo or beyond would appear impressive.
Ted,
I get what you're saying and it's a double edged sword. Reflecting back on my Flex background and Flex Skins being one of my specialities in the past, it can bite you.
In that a lot of the time and energy inside Flex isn't always the composition of what the functionality does and doesn't do, it's also tied up in skinning and rigging the GUI to execute on UX points of interest.
The client most likely doesn't care about the nuts and bolts and i'd argue they are looking for the end polish & shine or close to it.
That being said, if you're looking to architect your RIA at it's infancy and still at the project kickoff stage whilst throwing around ideas for features, then the halo / plain skin is ideal as you're still in what i'd call the POC stage.
Prototype is something that isn't always restricted to the innerds, it also has to do with skinning (as you need to know how far you can execute on creative vision, to underpin the Rich piece to the RIA discussion).
I'd also caution using existing O/S skins, as you raise the bar of expectations and i've found this can easily backfire on ye.. you're for ye warned flexer's :P and why emulate the existing skins when you can carve out your own?
-
Scott Barnes
RIA Evangelist
Microsoft.
i wish i had come across this post earlier. in a recent project of mine, where I introduced flex to replace an existing applet, it was hard to explain that besides the mock that I had setup in 5 days to present the PoC, there was more to do :). nice post. I am gonna be using this more often.