Programmatic Yahoo Skin Library update

I have added some new skins to my programmatic version of the Yahoo Skin Library. The new additions are the ComboBox, CheckBox, PanelTitleBar, PanelControlBar, PanelCloseButton, ToggleButtonBar.

The demo below is the actual Yahoo Skin Demo MXML with my CSS attached. So, you will see that not every component in it is styled correctly yet. As I add new skins to the library, this demo will be updated.

You can see the demo and download the source here

The Case Against Flex-Based App UIs...Really?

Last week, someone pointed out to me this article from intelligententerprise.com and asked for my thoughts on the author's arguments. In his article the author compares RIAs built with Flex to those built with Java Applets. While there are similarities between the two conceptually, any Flex developers who experienced building an enterprise application with AWT and Java 1.1 will surely agree that they have many differences.

So, here is my take on his "arguments".

"They almost always violate web accessibility guidelines"

No platform for web-based applications gives you accessibility entirely for free. Flash(Flex), AJAX and even web 1.0 HTML applications require effort to make them accessible. Flex gives developers an API to make applications keyboard accessible and able to be used by JAWS. If I am not mistaken, this capability existed with Flex before any AJAX framework had it. One could argue that making a straight HTML application accessible is far easier than making a Flex or AJAX application accessible. However, there are a lot of other user experience benefits that you can't get with plain old HTML.

"They create support nightmares"

He seems to be confusing AIR with Flex. Flex is a technology used to build applications. AIR is a desktop runtime used to run applications. AIR applications could be created with Flex, Flash or AJAX. Like any desktop application, pushing updates is not as simple as web-based ones. However, AIR does provide the ability for automatic updates that is easy to implement. "The potential for trouble remains" sounds to me like "There is no problem now but someday there might be"... you could say that about any technology. Flex applications that run in the browser have very little need to worry about this type of issue. Adobe frequently updates the Flash player but maintains backwards compatibility better than anyone I have ever seen. Applications built for Flash 5 will still run in the Flash Player 10. The only changes that may have caused problems are some security changes. While this is something that could break backwards compatibility, I would argue that it is worth it in those cases.

"They are prone to performance problems"

Memory leaks are just as likely in non-Flex applications. With JavaScript (AJAX) based applications it is very easy to cause memory leaks. Even Microsoft points out some patterns that cause them (http://msdn.microsoft.com/en-us/library/bb250448.aspx). Good developers can watch out for the types of coding patterns that cause memory leaks. FlexBuilder has tools to help developers identify leaks. With AJAX applications, it is more difficult.

"You can't easily modify them"

This is probably the most outrageous claim on here. He clearly doesn't understand how Flex applications are built. Changing the look and feel is one of the key features of Flex. Scalenine.com and fillcolors.com both showcase the ability to change the appearance of Flex applications in some cases very dramatically. The decision to not allow this type of "skinning" is really a business decision not a technology limitation. The demo situation he describes is rather amusing. None of the problems he describes had anything to do with Flex as the technology. Rather, they point out the vendor’s lack of a good interaction designer. He points out that the answer they wanted to hear was "You can modify the UI yourself on a role-by-role basis, and our platform is properly tiered, so we can show you how to customize it in a release-safe way." This is exactly what a well-designed/well-implemented application does allow for…regardless of technology.

Yahoo Skin Library - Programatic version example with source

I am currently working on a project on which I am using the Yahoo Flex skin library. If you haven't taken a look, I suggest you check it out. In my opinion they look a little better than the default Halo skins.

The other day, a developer asked me why changes to the fillColors style were not working. I explained that the styles could not be changed using CSS because they were graphics. This led to the question of "How can I make a red version of the primaryButton?". I got about half way through my answer of "I can create a skin graphic for you" when I realized that this was a major drawback of the graphical skin.

So I set out to create a programatic version of the Yahoo skin library.




Check out the live version with source here.
UPDATE: I changed the demo app to be the actual Yahoo Skin Library demo application. When you launch it you will see that some of the components still have the Halo skins. As I finish each component skin, this file will be updated.

My immediate need was to create a button skin which is all I have so far. It still needs to be cleaned up a bit but I figured I would post the example and source code in case anyone else ran into the same problem. I plan to create the whole set so stay tuned. If you would like to contribute some skins for the other controls, feel free to post a comment.

User Experience Designers...Listen up!

A couple days ago I posted a question here (and on some other discussion lists) regarding how usability can fit into the Agile process. I revised it slightly and added some clarification:

What are the best methods you’ve experienced with regard to incorporating quality design & usability practices into Agile software development?

There is some debate in the software industry regarding the scope of UI design work to be completed before Agile software development can begin. What are your thoughts? When is a detailed prototype necessary? When is it not necessary?

I promised to post my thoughts so here they are.

The method that I am currently using involves some upfront design time which I consider the architecture phase. During this phase is when you gather and process all the data about various types of end users and their goals. Throughout the architecture phase, we work on low-fi wireframes and/or mockups that address high level global interaction patterns such as type of navigation, inline editing vs. popups vs. separate edit screens, etc. I liken this to the engineers' decisions to use a particular technology, library or persistence strategy. Some of this stuff needs to be thought out early since changes later are expensive and destabilizing. Because, end user satisfaction is a top priority for our customers, I propose doing usability testing during this phase (and all through development). 

While wire-frames and paper prototypes can certainly be tested, we have found that nothing works as well as a clickable prototype. Someone suggested above that just build the real thing and test that. We have repeatedly seen that a very detailed prototype can be built in 4 to 6 weeks where the actual product can take 6 -12 months. Of course with agile development you have something every 2 - 3 weeks but it does take a while to get to something that can be a true test of the user experience. The level of detail in the prototype and wireframes/mockups is really determined by the complexity of the interaction. If one pattern can be reused, there is no reason to prototype every use case of it.

This process can work very well but requires some commitment of time before development begins. This doesn't have to be a year long effort but depending on the type of application somewhere between weeks and months seems appropriate. Regardless of the amount of time required, this is often labeled "Anti-Agile or Waterfall". 

What lead me to asking my original question was my desire to know how others are doing it from a tactical perspective. Can the process I describe above scale? Is it truly anti-Agile? If it is, does that really matter if the result meets user's needs better? 

If the goal is to deliver really good software, not just really good code, I am ok with being slightly less Agile.

Do prototypes help or hinder the Interaction Design process

Almost ten years ago, Alan Cooper (author of About Face and The Inmates Are Running the Asylum and my personal hero) of Cooper wrote a journal article titled "The Perils of Prototyping". It made me think about today's software and the way in which we designers communicate our vision to developers. I posted a comment on that blog asking this question:

"Do the capabilities of today's tools and the expectations of today's users change the need for prototyping?"

The reason I ask is because it isn't as easy to test interaction design patterns on paper if they require visual transitions, sounds, tactile responsiveness (on touch screens), vibration (think Nintendo Wii).

I have seen numerous times that communicating complex interactions to developers with paper mockups, or even digital mockups, is far more difficult than showing a prototype that actually does what is required. 

I have also heard first hand from developers that say a prototype really helped them with the details. Not only does it display how the software should behave, it provides and idea of how it might be implemented. This might be unique to the fact that the prototype built with Flex was for an application that was also built in Flex. So there was the ability for direct reuse of custom components, etc.

What do you think. Is there value? Can it work in an Agile environment? Or is it still as unnecessary as it was ten years ago? 

User Experience Designers... speak up!

A colleague posed a question to me today that I think is a very important question:

What are the best methods you’ve experienced with regard to incorporating quality usability practices into Agile software development?

Before posting my answer, I am interested to hear what all of you think.

Handy IPhone app for... Flex/ActionScript developers?

Mike Chambers released a cool little reference guide for Actionscript for the IPhone. Now, to me, there seems to be something wrong with using an IPhone app to create RIAs that won't run on the IPhone. Plus, if I am in Flexbuilder working on a Flex app, the Actionscript reference is only a key (ok... two keys Shift + F2) away.

But, since I have a new found love for my IPhone, I will probably install this to check it out anyway.

For more info, visit Mike Chambers' blog or you can find it on the App Store.