7 Replies Latest reply on Jun 28, 2009 4:55 PM by acath

    Many question regarding work flow and best practices


      First off hand off to the team that is working hard to bring us such an app.


      1. Q: Why is Catalyst missing all the layout components used in builder, i.e. Canvas, panel, Vbox, Hbox, etc.?

      2. Q: Is the idea to eventually include these components?

      C: Part of making a full prototype we really need the ability to show flexible screens, i.e. use a Hbox to show that the screen is (user driven) adjustable, this is one really important selling point in choosing to use Flex rather than other technologies. A similar topic that I don't see addressed with Catalyst is percentage based layouts. Q: What are your plans around this?

      1. Q: What type of workflow are you guys promoting? In other words if my team is to eventually use the code from my prototype generated from Catalyst, correct me if I am wrong but the code and the assets that are being generated are inline and one offs, rather than the approach that we (I) have been using which is to programmatically skin the app with Flex CSS.

        To maintain standards and consistency in an application built in Flex it is important that styles used on one component look the same on all other similar components in the app. It is also important that the styles can be maintained in a single document i.e. CSS rather than inline. So what is the suggested workflow for these issues?

      2. Q: Also in the same light as my previous question where does FXG play into this? Is FXG supposed to be a substitute for Flex CSS?

      3. Q: What type of image compression is being used on content that is created that can't be maintained as a vector graphic? Are you guys paying attention to the fact that the end user is using this application over the Internet. How realistic is it that an application can provide data, functionality, compile programmatic styles and load graphical assets in a reasonable time. Part of user experience is how long users have to wait around for their application to load, knowing the tolerance is low what type of image compression is being used?

      4. Q: What about other missing components? Many of the other form components are missing, i.e. jump menus. Q: Are you guys planning putting in these components even if is just as default out of the box Flex components? (meaning I am less worried about turning a monkey into a scroll bar and more interested in being able to use a jump menu or a standard tab component to demonstrate navigation concepts.

      5. In other beta forums I brought up the topic that Fireworks was 90% there so why didn't you guys just build on top of it rather than creating a whole new applications,,, I am trying to refrain from that topic again as it just frustrates me that you guys (Adobe) should have done more research to see what was our work flows and what tools we were using,,, never the less the most frustrating thing I find about Catalyst is asset and Layer  management., Any chance that you guys will look into the Fireworks workflow to create pages so that some layer stays constant (or editable in the master page) and the rest of the pages have an independent (with the flexibility to share) set of layers.

        This is one of the reason why I think the Illustrator layer work flow is much less effective.
        • 1. Re: Many question regarding work flow and best practices

          I think in fairness to the Catalyst developers, designer/developer workflow varies quite a bit. I know designers who explicitly use Photoshop, others Illustrator, and others yet use Fireworks, like yourself.


          Isolating a tool from these three pieces of software allows flexibility and accommodates many different workflows.


          What I see that needs to happen is that Catalyst has to be able to go back and forth to Flash Builder, so that design and development can be iterative, all the way through the process of building an application. While Catalyst is useful in its current incarnation, it forces my developers to wait until I complete the design, when I could have already handed off pieces to him. Exporting as a library project partially resolves this problem, but it's really just a workaround.

          • 2. Re: Many question regarding work flow and best practices
            Matt Cannizzaro

            Catalyst currently supports absolute positioning only, so that's why you don't see components that are useful in dynamic layouts like HBox and VBox. In general, you probably won't see every component that Flash Builder supports in Catalyst.


            You can reuse the components you've created in FC throughout your project. For example, you could create a Button skin to use for all the generic push buttons in your application. Whenever you need a Button, rather than creating a new one from scratch (with a different skin), just drag out your skin file from the Library panel onto the artboard. If you take care to build your application in this way, you won't end up with many duplicated assets or FXG code.


            In regards to the relationship between FXG, Flex CSS, and programmatic skinning, these three tools are intended to solve somewhat different problems. FC will generate FXG, which may be ideal for many cases, but sometimes you might find that a skin is more maintainable for the developer if it is implemented with CSS or a programmatic skin. In these cases, the new skin can be implemented in Flash Builder.


            We are aware that more control over asset size and compression is necessary and we are looking into addressing that in the future.


            Thanks for your questions!

            • 3. Re: Many question regarding work flow and best practices
              acath Level 4

              To add a bit to what Matt wrote...



              Dynamic Layout


              Supporting a good authoring experience for dynamic layout is easier said than done. We had to make the hard decision to cut this feature from the first version of Catalyst. You'll have to add dynamic layout in Builder for now. Needless to say, this will be a high-priority feature for future versions.


              By the way, the new Spark component architecture has a new way of doing layout that isn't based on components (Canvas, VBox, etc), but rather the ability to change the layout dynamically on any container. This also means there's no reason for List, HorizontalList, TileList, etc - there's just one List whose layout you can change:






              There's more on this in Ely's video on the new component architecture: http://tv.adobe.com/#vi+f1472v1501



              Workflow/Skin reuse and FXG


              You can still use CSS to use the same skin everywhere (in fact, we've improved CSS support significantly: http://opensource.adobe.com/wiki/display/flexsdk/CSS+Advanced+Selectors) The difference is that the skin is now defined declaratively in MXML, using FXG, and is much, much more powerful and flexible than it was in Flex 3 (http://opensource.adobe.com/wiki/display/flexsdk/Gumbo+Component+Architecture).


              I highly recommend Ely's video on the design/develop workflow in Flex 4: http://tv.adobe.com/#vi+f1472v1501


              The workflow is roughly like this:

              1) A designer converts artwork to, say, a Button component in Catalyst

              2) This creates a Skin file that can be reused like so: <Button skinClass="MyButtonSkin" label="Some other label"/>

              3) You can also set skinClass in CSS: Button { skinClass: ClassReference("MyButtonSkin") }

              4) Profit


              You'll probably have to do a few more steps to make the skin fully reusable:

              5) Make sure the "Label" part is defined, so that the label you set on the Button instance can be piped into the skin

              6) Add dynamic layout to the skin so that it can be used at different sizes.



              Compression/SWF size


              As Matt said - we're working on it.



              Other components


              We're creating a whole new set of components ("Spark" components) to make the Catalyst/Builder workflow possible. It will take time to round out the set. We know people like the advanced components - that's why you can still use the Halo components in your Flex 4 projects (just add xmlns:halo="library://ns.adobe.com/flex/halo" to your root tag, and then you can add <halo:DataGrid/> or whatever you like).

              • 4. Re: Many question regarding work flow and best practices
                Christian3D Level 1

                Thank you Matt and Adam,


                Adam your explination was great. It is starting to make a lot more sense now,, thanks.


                I am a bit dissapointed that HBox and VBoxes wont be supported (yet) becasue like I mentioned before they are one of the selling points of using Flex. They are also key to telling the story of how the user will interact with the UI.


                @Mark I am not suggesting alienating Photoshop or Illustrator users, but by deciding to take the Illustrator approach to layers Adobe is alienating FW users and their work flow. I don't know about you but other than Mordey I don't know a single Illustrator/Print designer who knows the first thing or has any interest in application interaction design. Again it is real easy to get into the debate over customers and their tools so lets not go there, rather lets look at a work flow in general.  Catalyst is very much designed so that the view states content are managed by layers, grouped items in layers and by showing and hiding elements. One of Fireworks many powerful features is its ability to have more layer control.


                Example - because in FW we have the use of pages, we have a set of layers (and content in those layers) that are always constant. For intance I might put my header elements in the Master Page layers. Now in additional pages I can see the content from the locked set of  layers from the Master Page. In other pages I have a complete set of independent layers, thus making layer management for each page much much easier to control. In addition FW allows some layers to be shared accross pages. allowing even more flexability since the content lives in one place but the control over that content (lock/unlock, view/hide is controlled in the page itself.  Obviously Catalyst is working with view states rather than pages but the concept could be the same. I think you would be hard pressed to convince me and other Fireworks users that this kind of control, organization and flexability is inferrior to the layers in Photoshop and Illustrator. The added plus,,, if you look at the way catalyst is set up, users from IL and PS would still be able to import their content the same way they are now,,, the only difference is that they would have even more control once their content is in Catalyst. Thus this feature idea would make it so that no one would be alienated.


                Just a side note (again trying not to put fule on the product of choice fire), in my experience ever person that I know that does interaction design and or they are a designer for flex apps, every single one of them use Fireworks.  Just my experience.


                ~ C

                • 5. Re: Many question regarding work flow and best practices
                  acath Level 4

                  Catalyst's layers panel is a blend of the various other tools, and some of our own secret sauce. Our states concept, on the other hand, is very different than the other tools.


                  I think I can help bridge the gap between the "master layer" concept from FW and the way we think about things in FC...


                  In Catalyst, an object can be shared in multiple states, and its appearance can change between states (this is the basis of animated transitions between states). You don't do this by putting the object in a "master layer" - we found that to be too restrictive for real application design. Instead, you can share any object between states simply by going to the various states and turning on the eyeball in the layers panel (or by choosing "Share to State" from the context menu).


                  Here's the catch: unlike "master layers", most changes you make to a shared object ONLY affect current state. In the current Beta, there's no straightfoward way to push these changes to other states (we'll fix that soon). There is an obscure way, however: choose "Share to State > Current State Only", then "Share To State > All States". This will make the selected objects look the same in all states.


                  Once you get used to this approach, I think you'll find that it's much more powerful than the "master layer" concept, but I admit it is more confusing at first. You can simulate "master layers" by simply deciding that a given layer will only contain shared content. You can then share that content to all states using the techniques I described above.


                  Thanks for your input. Maybe we should consider adding "master layers", where changes are shared to all states by default...thoughts?

                  • 6. Re: Many question regarding work flow and best practices
                    Christian3D Level 1

                    Hi Adam,


                    Again thaks for your reply.


                    Here is my responce and feedback.


                    The Master Page (not to be confused with a master layer) has a unique purpose in that you use it for common elements that you don’t plan on changing. On the other hand it also gives the user the ability to make a change to an object or layer order in the master page and it is reflected every where.

                    Example in my prototype I might have a logo. This logo needs to be in the same location, the same font and the same color treatment throughout the entire application. Because of this, this particular asset goes into a layer in the master page. Later some one comes up to me and says that the logo always needs to be 10px from the top and 10px from the left, since I messed up and had 16pxT and 16pxL, if I were using the standard layers approach I would have to update this item in all my pages (states in Catalyst). If this one item was in a layer in the master page than I just make my edit in the master page and all other pages (states) would have that same update.

                    Correct me if I am wrong (very possible), by not using a master page approach, the simple act of trying to correct my mistake, Catalyst will want me to manage transitions in all the states not realizing that I am only trying to fix a mistake rather than move an object.

                    Now the second advantage to a Master Page, when I am in another page, all the layers that make up that master page are grouped into a single layer that is locked (without the ability to unlock it except in the master page). Now each additional Page (states in Catalyst) has their own clean set of layers. This makes it extremely easy to manage layers.

                    Don’t get me wrong,,,, I do understand that states are a bit different than pages in the sense that you are transitioning items in a layer from one state to the other. I get that. But the part that is a bit more work is that some stuff might only have to live on the destination state, so in that case why should I have to manage that content in layers on all states.

                    Example I have a panel that has read only data… The panel needs to live in both states but the text needs to only live in the first state. Now in state two the panel grows, since I don’t care about fading my read only text, rather I just want to introduce my form elements in its place. Current functionality is that I am forced to have this huge Layer structure where on both states my read only and my form content unnecessarily live in both places. Not only do I have this extra content, I now have to worry about what happens to that content between states (meaning extra animation, extra issues regarding the sequence in which the text fades versus when my box grows and then even more issues regarding how the form content is introduced ect. It is nice to have this ability but impractical to have to manage this granularity all the time if I don’t care to.


                    Honestly I didn’t realize that these other state options that you describe were available, yet when I tried them they didn’t work as I would expect.

                    On state two I introduced a sphere. I right clicked to select current state only. Assuming that it would only show on that particular state. I then I switched to state one. Guess what? The object is there in state one, the only difference is that it is hidden by default. But there is nothing that prevents me from un-hiding it or from unlocking it.

                    Next test I choose Share to All states. Yes it does this but there is nothing from preventing me from moving it in a particular state. Thus not the same behavior as the Master Page concept.

                    This is why I think FW has this most flexibility when it comes to layer and content management between pages. (states)   ----  (which is extremely important in prototyping).

                    -          I want some stuff to remain constant and not have to worry about it

                    -          I want the ability to make a correction to the constant content

                    -          I want the ability to share across states (primary task)

                    -          And I want the ability to only see particular content in the state that I am in.

                    -          I want the ability to fade something in without having to worry about fading something out first.


                    I am not really seeing this kind of control with what you are describing. Maybe it is there and I just need to learn the tool a bit more and forget about the workflow that I am used to.


                    ~ C

                    • 7. Re: Many question regarding work flow and best practices
                      acath Level 4

                      Hi Christian,


                      I totally absorbed your comments. Your insight into your own workflow is really useful for us as we evolve these concepts.


                      By way of explanation, when I said that the Catalyst concepts were more powerful, I meant it in terms of what you can build, not how you work. But that's a minor point. Thanks again for the comments...we'll take them to heart.