5 Replies Latest reply on Jul 8, 2009 3:51 PM by acath

    Separating Design from Development

    neutrino15

      Dear Adobe,

       

      This is my first post on your Labs forums. I just finished playing with the new CS4 -> Flash Catalyst -> Flash Builder workflow and have to say: I am inspired but not impressed. As mainly an AJAX and Cocoa developer, I had to learn AS3 syntax and MXML markup as I went along. I will list my three biggest problems with Catalyst and Builder below.

       

      Design still mingles with Logic

      When I first saw Catalyst and Builder, I was excited to finally see a real separation of code and design. I was expecting Catalyst to be the OSX "Interface Builder" of flex, and Builder to be the "XCode." I do like the <fx:Script /> <fx:Declarations /> and <fx:Design /> separation in each MXML document, but feel as if the <fx:Design /> segment should somehow be "off limits" to developers (or at least discouraged). If Catalyst was only allowed to edit the Design segment of the MXML and Builder only edited the Script and Declarations segments then leaner coding practice could be achieved and true interoperability between Designer and Developer would be reachable.

       

      Please allow for custom transitions and transition copying/grouping

      At the moment, Catalyst strikes me as an extremely dumbed down version of Flash that only lets the designer use preset "transitions" on their component heirarchy. This is suboptimal in two ways: Firstly, if the designer wants anything more complex than a linear move + Rotate3D + fade, they will have to just give up the UI to the developer. We are trying to avoid having the developer write UI code, so the designer should be able to really get creative with their transitions and animations without having to create swcs or swfs in Flash IDE. Secondly, there is no way to save a transition and apply it to elements of the same type. Layouts are often very repetitive and it is inhumane to expect a designer to sit there and drag out "transition" sliders for each dropdown on a page (for example). I agree that this scripting should be done in a GUI like Catalyst, but components need to be able to inherit transitions. I don't even want to imagine a GUI for such a thing, but you are Adobe, this is what you guys do!

       

      Allow us to export to either Air or SWF at build-time, not at import!

      I don't see why this isn't already enabled. Isn't Air supposed to have even more features than Flash? Couldn't Flash Builder just scan your project and warn you of any "air-only" libraries you are using? If you choose not to use anything other than the standard Flash 10 libraries, what would be the harm in giving us the option to export as either at build-time?

       

      I hope that my comments were somewhat useful. Before anybody responds with hostility: I am not a professional Flex developer. This was my first time playing around with the Flex framework and with Catalyst <-> Interface Builder, these were my first impressions.

       

      Thanks for producing such amazing products--

      --Jordan

       

      P.S. Your spell checker converts all ":D"s to .. As in <fx:Design /> to <fxesign />.. Made me chuckle

        • 1. Re: Separating Design from Development
          acath Level 4

          Hi Jordan,

           

          Your candid feedback is extremely valuable to us, as we're always trying to attract more developers to the Flash Platform. You make some great points...let me respond to each.

           

          Separation of logic and presentation

           

          Our model is very different from the Interface Builder/XCode model. I don't have a ton of experience with that model, so I can't engage in a deep discussion in the relative merits, but I do have a few thoughts about why we've done things the way we have...

           

          First, it's not realistic to expect that developers will never have to touch the presentation code. As time goes on, we will evolve the tools to put more and more control of the presentation in the hands of designers, but there will always be something that you just can't do without writing code. I'd be surprised if IB doesn't have this problem. Let me turn the question around: why would prohibiting the developer from editing the presentation code help the workflow?

           

          More importantly, the medium-term goal for the FC/FB workflow is that the designer will own the skins and the developer will own the component logic. I highly recommend Ely's video on this vision: http://tv.adobe.com/#vi+f1472v1501 . I'd love to hear your feedback on Ely's talk.

           

          On a more abstract note (my views do not represent the views of Adobe or its shareholders or emploees (except me)), Cocoa is a very different platform than the Flash Platform. While Cocoa tends to make every Mac application look the same, the Flash Platform allows applications to be totally customized and unique. In my opinion, the Cocoa approach is well-suited to monolithic desktop application development, while the Flash approach is better suited for the web development.

           

          Custom transitions and reusable transitions

           

          Flash Professonal will probably always be better than Catalyst at very rich, highly choreographed animation. Catalyst is optimized for common application development cases - you just want some nice-looking transitions when going between visual states. That said, we will evolve Catalyst's timelines to be more and more expressive, while keeping it simple enough for the common case. Are there particular animation effects that you would like to see?

           

          Reusable transitions are a great idea and definitely something we'll consider for future releases. How do you envision this working?

           

          (One thing that could help you in the meanwhile is the fact that transitions within a component are reused when you reuse the component. As we make components more and more customizable - and therefore reusable - this will be more and more useful.)

           

          AIR vs SWF

           

          We're trying to make this distinction softer. I believe the next version of Flash Builder will have a feature that allows you to switch project types in a single command (i.e. "switch this project to an AIR project"). Would that work for you?

          • 2. Re: Separating Design from Development
            neutrino15 Level 1

            Wow! Thanks for the in-depth response! It's always nice to see that even at such a huge company, you are all still human beings!

             

               I watched Ely's talk on Skins in Flex. I liked how fx:Skin is a completely separate class, even though fx:Design  kinda has it covered already. What's the difference? I am sure you will incorporate "skins" into the next release of Catalyst, so why not keep Skins and Design layouts in completely separate files? I wouldn't mind seeing a C-like setup where each MXML page has a "header file" with object definitions that both the Skin file and Logic file can access. The alternative to this multiple file setup is, of course, just having multiple sections of code inside the MXML file (like you already do). My only gripe with keeping logic and design in the same file is that as soon as you open up an MXML document to a developer's little paws, you immediately render it useless in a GUI program like Catalyst. If the developer is strongly encouraged to   bind event listener and data providers in the "script" partition (using AS3), the MXML could be left untouched so that Catalyst could update the UI. My concern for separating design from logic stems from my experience as a Rails developer where mixing "logic" and "html" is essentially taboo. I suppose in a front-end app where the GUI is what matters most, true separation isn't imperitive. Yet if you want to poise Catalyst->Flash Builder as an application development tool, I would almost expect it!

               Speaking of expectance, I was practically sure someone would flame me for comparing Flex to Cocoa. Upon further thought, Cocoa was probably not the best example I could've chosen. In fact, I don't know of a single application framework which forces separation between logic and UI in any stringent way so that both UI and Logic development can be improved. Why shouldn't Flex be the first?

             

               As for the animation and transitions, Catalyst is currently a tool for grouping artwork into "components" (objects), messing with their "properties" (attributes), and adding "Actions and Transitions" (simple event handlers and calls to transition handlers). While re-naming objects to components, attributes to properties, and event handlers to actions is a-ok, I don't see why the full power of object oriented design can not be unleashed to the average designer. I know there has been a lot of talk on these forums about adding CSS-like properties to components: by unleashing OO architecture into GUILand, you can kill two birds with one stone.

               I believe, for example, that the average designer is intelligent enough to understand that they can create one "parent" piece of artwork (let's say for buttons on a menu), and then slightly modify (extend) that never-displayed parent to produce their buttons in Catalyst. This way, if the designer decides that every button in the menu needs to brighten when rolled over, he/she can simply add the effect to the parent artwork. A nice little GUI to the artwork inheritance structure would be needed, but I believe that such an edition would yield great power to the designers. Hey, it's certainly more humane than having to reconfigure transitions and effects for every single component!

               While I'm at it (I'm having too much fun here!), why not allow designers to save transitions in their own sort of structure. Let us say the designer creates the blinky transition for the main menu button rollover, instead of binding the transitions directly to individual layers, he or she could define more general "sub components" that could be bound later. So the Transiton object here would simply state that the "Front Plate" fades to 50% opacity for 2 seconds. The designer could then apply the transition to any component in the project and just specifying what the "Front Plate" is each time. This is similar to how Catalyst currently handles custom text fields and scroll-bars, you just specify which layers do what, and it "magically" hooks it all up.

             

            The ability to quickly export my SWF as an air app would allow me to more easily explore Air development. That's all. So I guess my answer to you is "Yes."

             

            In all, I really do feel like the new Flex workflow really shows potential. If developers support you, I see no reason why next generation web-centric applications would be written in anything else. If Flex can unify design and application development, it has the ability to take boiler plate looking desktop apps to the next level. I just don't think that taking away features is the way to achieve this.

             

            Respectfully-

            --Jordan

            • 3. Re: Separating Design from Development
              acath Level 4

              Hi Jordan,

               


              Thanks again for taking the time to post your thoughts. Yes, I like to think I'm a real person!

               


              fx:Skin vs fx:Design

               


              I think there's some confusion over terms here. There's nothing in the new framework called fx: Design, so I'll assume you're talking about fx: DesignLayer. Let me clarify:

               

              - Skin: a class that encapsulates the presentation of a component. The word "presentation" is ambiguous, but roughly speaking, I'm talking about the graphics, visual states, and animations between states (transitions).

               

              - Skinnable component: a component whose presentation has been separated from its logic such that the component can be reused with various skins. E.g. a vertical scrollbar component that knows the logic of scrolling (thumb can be dragged vertically inside track, etc), but doesn't know anything about the specific visuals you will use for the thumb and track. SkinnableComponent and Skin are the building blocks for Flex 4 applications.

               

              - DesignLayer: The fx:DesignLayer tag is used by Catalyst to represent a layer (i.e. the thing that looks like a folder in the Layers panel), and is ignored by the compiler (it's like a comment). DesignLayer is a relatively insignificant player in all this stuff.

               


              The separation of logic and presentation is achieved like so: a developer creates a SkinnableComponent with certain business logic (e.g. a scrollbar component with scrolling logic, or a "customer editor" component with validation, database access logic, etc). The designer creates a Skin (using Catalyst) for that component. All the component logic lives in ActionScript in the SkinnableComponent, and the Skin assets live in MXML in the Skin. Voila: separation of the logic from the visuals.

               


              It seems like this is close to what you're looking for, with one exception: the developer can still go in and change the MXML, thus breaking the Catalyst UI. Is that right?

               


              On Inheritance

               

               

              Hey, we're not talking about separating design from development anymore...no fair! =p


              Seriously, these are some really powerful ideas. Some of what you've suggested is possible today - when you create a button, it is parameterizable in certain pre-defined ways (i.e. you can change the label on each instance). I am skeptical of exposing inheritance in a GUI; not because designers aren't smart enough, but because graphics don't lend themselves to extension in a straightforward way. Whenever you show a graphic on the screen, you show a concrete, actual thing. There's no obvious way to display an abstract base class graphic with methods or chunks that the subclass graphic must override. But I'm not blowing off your ideas. I'm just saying that we'll have to Think Deeply about them. Thanks again for your insight!

               


              -Adam

              • 4. Re: Separating Design from Development
                neutrino15 Level 1

                I agree that exposing some sort of inheritance might be tricky. The "end

                goal" I had in mind when describing that system was to have "behavior"

                inheritance. I agree that the actual graphics might not be suited to a

                complex object model, but types of components certainly do!

                 

                Also, can you link me to some tutorials on "Skinning vs DesignLayering?" The

                code that Catalyst generates seems to be completely contained in the

                DesignLayer. Is there a way to specify the exporting of a "skin"?

                 

                Finally, this is all just coming down to me (and my programming oriented

                mind) trying to help create a designer's tool. I admit that most designers

                would probably never use, nor would they want, a tool designed by me.. I

                just like keeping everything nice and clear under the hood. The catalyst

                made a huge step in UI design by allowing Designers to create part of the

                "framework," not just skins. If, however, the designers are allowed to do

                such a thing, the code better be very "nice" to work with (from a dev point

                of view.)

                 

                The first concern brought up at my company's meeting over Catalyst was "this

                can't be another Dreamweaver" (from code-generation POV)

                 

                Respectfully--

                --Jordan

                • 5. Re: Separating Design from Development
                  acath Level 4

                  Hi Jordan,

                   

                  Don't let the eagerness of my responses discourage you! I'm not trying to deflate your suggestions. I really do want your feedback. I'm just trying to understand exactly what it is you want, and help clarify parts of the current design that might be unclear. I totally agree that it can't be another Dreamweaver from a code-gen POV.

                   

                  Re: Skin/DesignLayer

                   

                  When you convert artwork to a component in Catalyst, you create a skin file (check out the generated file - it's root tag is <Skin/>) for a skinnable component. The developer shouldn't have to touch this file (with certain caveats, as we discussed above). In this case, the developer is the guy on the Flex SDK team who wrote the Button or Scrollbar or whatever component. He defines how a scrollbar behaves, and the designer defines how it looks.

                   

                  The medium-term vision for Catalyst is that 3rd party developers (you guys) will write their own skinnable components, with behavior relevant to whatever their app does. This could be a weather widget, a customer editor, etc...any chunk of your app with complex behavior and a complex design. Thus a typical app would have:

                   

                   

                   

                  •   A main application file, which contains a bunch of skinned component instances in MXML (typically organized using DesignLayers), and your top-level application logic in AS.

                   

                  •   A bunch of skinnable component definitions written in ActionScript. This is where you define the contract between the components and its skins: e.g. "the skin must have a Normal, Search, and Results state, and it must have a resultsList and a submitButton".

                   

                  •   A bunch of skins for your components, which may include other skinned component instances (e.g. your search results skin might have a customer editor in it).

                   

                  The only place where AS and MXML live in the same file is the top-level application. Everywhere else, there is a well-defined contract between the AS (developer-owned) code and the MXML (designer-owned) code.

                   

                  Does that make sense?

                   

                  -Adam