Designing with Air and Flex

Last night, I finally had a chance to sit with a developer and try and style something inside of an Adobe Air application, using Flex 3.  I have about 1 hour of that under my belt.  Here is what I learned so far:

Flex 3 is a mess for styling.
In HTML, I feel like I know what is going on.  HTML/CSS/JavaScript, Server-Side logic, the DOM tree…I get it.  Firebug makes it easy to see.  I understand the separation of tiers.  With Flex, I was instantly lost.  There were several different files, each of which was responsible for different parts of the style.  Sometimes it was CSS syntax with new fangled Flex attributes like HorizontalAlign: center.  Other times it was configuration in programming like HorizontalAlign = “center”.  Sometimes you needed 40 and other times 40px.  Even though the programmer had intellisense, we were guessing half the time on how to do a certain style.  The model is messy and I couldn’t find clear documentation on how to do what I wanted.  When you google for help, you get a variety of formats.  Pages like this are very hard to parse or find something specific.  MSDN, Mozilla, W3C all do a better job of defining what is possible.

Apparently, Flex 4 is a re-do of this issue.  I tried to convince the team to use Flex 4 right from the get-go, but that didn’t work.  So I am stuck with Flex 3 until later in 2010.

Goodbye cross-browser testing.
Let’s assume you have an application that does not require any form of SEO for Google.  And let’s assume you can learn enough of AIR to make an application install.  Last assumption: The application is just a reference to a URL.  What have you just done?  You have delivered a web application to a customer that only needs to be tested in Webkit.  You can build the application anything you want, jQuery, ExtJS or whatever.  The application launches the application in a window with no chrome in webkit.  It’s fast and looks great.  I was stunned at how quickly that worked.  I wish we tried this at Marketo.  It would eliminate ALL cross-browser testing and make the application twice as fast.  It seems a no-brainer to do this for all kinds of applications in this category.

But something is screwy.
Look at the image below.  This is AIR pointing to a webpage and Chrome also pointing to the same web page.  Notice the selectbox.

Why did AIR completely change the select box?  It’s supposed to be Webkit insde AIR.  What else is it changing?  Does this mean I can’t test in Webkit in Chrome?  I have to test the HTML inside AIR?  This is completely disconcerting.  I need to know what else changes.  If I had to guess, I think that the form controls like select, input, checkbox, radio buttons are all going to change.  I need to do more testing to see if this is the case.

Summary
Ultimately, AIR and Flex are kinda black boxish. They are doing things that are not crystal clear.  The learning curve is much steeper than HTML/CSS.  However, if we can get over the hump, I think the end result could be really fantastic.  More work on this to come.

8 Replies to “Designing with Air and Flex”

  1. I’ve gotta admit, I’ve always liked the way Flex and AIR apps looked, but the learning curve and non-openness of it has always prevented me from starting development with it.

  2. CSS Styling with Flex has a long way to catch up with HTML and I am not sure why they even try. I understand the separation of concerns that CSS gives but the core reason for CSS was to allow documents to be viewable without CSS. Flex apps are not.

    Regarding the AIR replacing your drop down, WebKit basically asks the host to supply standard controls. Look at the difference of look of such controls between PCs and Macs …or the iPhone that completely changes controls like select boxes to that interesting wheel UI. Air is doing the same thing. Since AIR/Flash cannot use native controls, they have built a series of standard ones that webkit can leverage. Your designs should basically not care what the system controls look like since they change system to system.

  3. I’m agree with Glen’s opinion. When I work with Flex I need to guess the styles of the element. The styling of flex components could be much better if we have a detailed reference of styles and how them can be applied to the components.

  4. Styles in Flex never need “px” added to the value. The unit is always pixels, so a plain number isn’t bad practice. However, I think you can generally add “px” safely and only the number will be used, but I don’t think that’s officially supported, so maybe that’s why you saw differing behavior. In short, skip the “px” and you’ll always be okay.

    Styles may be set in MXML using horizontalAlign=”center” as a shortcut, but all those same styles can be set in CSS as well horizontalAlign: center. A better approach, I think, would be to set styleName=”whatever” in MXML and then set styles using .whatever {} in your CSS file so that you don’t have to be confused by inline styles.

    The Flex 3 Language reference contains properties, methods, styles, events and everything available for all the Flex components. There should be no need for guessing. If you’re unsure, check the docs.

  5. I don’t have the answers for you. Styling isn’t my area of expertise. But perhaps can clear up a few inaccurate statements in the post:

    “Ultimately, AIR and Flex are kinda black boxish.”

    Actually, I believe this should be “AIR and the Flash Player are black boxish”. Flex is open source, so if you really want to you can go ahead and look at the Flex Framework classes or the Flex Compiler. There are even specs for the SWF file format if you want to dig deeper into what the Flash Player does. I doubt that digging into the SWF file format would help with your styling issues. Yes, styling components in Flex is not the same as styling components in HTML. CSS syntax is similar, but the styles may not be.

    When looking for styling information, you would be best suited to using the ASDocs reference

    http://www.adobe.com/livedocs/flex/3/langref/mx/controls/Button.html#styleSummary

    You talk about how HTML pages looked different if you loaded them in safari vs loading them in AIR; but I’m a bit confused. Are you loading HTML pages or SWF files? If you’re loading HTML pages, then how does that relate to issues with styling and Flex? I would have expected a styled Flex ComboBox to look similar when viewed on a web page or when in an AIR app.

    I believe arpit explained why the HTML pages may display differently.

Leave a Reply