4 Replies Latest reply on Sep 12, 2009 11:16 AM by EL Kay Dee

    State transitions across components?

    Jaanus Kase



      I've been using Catalyst for a few days now to put together a "clickable mockup" of an app. Instead of working based on a comp, I'm creating the UI in Catalyst directly, using it's built-in components and creating a "wireframe" look. Works fine. I anticipate to work with more hi-fi comps.


      One thing I'm having trouble with, is making deep transitions between states from subcomponents.


      Imagine this setup:


      The app has two states/pages, "1" and "2". Inside each page, I have one component to represent all the states of that page. So for the first page, the internal component states would be 1-1, 1-2 and 1-3. Ditto for 2.


      So, now, let's say that in state 1-3, I have a button inside the component, where I want to transition to 2-2. Currently, it appears that there is no way for me to do that. When I click on the options in "Play transition to state" of the button, it shows me states 1 and 2, as well as 1-1 through 1-3, but it does not show the "child" states of "2".


      Is there any way to accomplish the transition from 1-3 to 2-2?


      Another version on the same problem: let's say I can somehow get from 1-3 to 2-2. Now, inside 2-2, I have a button that jumps back to "1". Currently, when I jump to "1", it jumps to whatever state 1 was in, which is 1-3 in my case, which is undesirable. It would be nice if I could somehow reset the component state on some event (showing, hiding, ...) to its default state, so that when people later jump back to it, it would start in its default state.


      I am familiar with ActionScript and XML and did poke around a bit. I see that in components, there is this kind of code:


        protected function Button_click_1_1():void


      I speculate that this lets me do what I need by editing code, and instead of topLevelApplication.currentState using topLevelApplication.someComponent.currentState... but I wanted to see if there is/will be another friendlier way of accomplishing this?

        • 1. Re: State transitions across components?
          Jaanus Kase Level 1

          Ok, in code, it works. I just edited the mxml for the right component and now have deep transitions across states working.



          protected function Button_click_1_1():



          protected function Button_click_1_1():


          "customcomponentid" is the ID of the right subcomponent (looked it up in Main.mxml), and that's it.


          The UI remains working after doing this, but the UI view of the relevant button is a bit off so, would still be nice to eventually get it working in the UI too.

          • 2. Re: State transitions across components?
            acath Level 4

            Hi Jaanus,


            I'm glad you figured it out.


            The reason Catalyst doesn't allow you to create this type of control flow through the UI is that it gets awful complicated. For a larger project with this type of logic, a developer will typically want to put in some architecture to manage the states of objects, rather than having all the objects run around changing each other. We don't want to make it easy to author "spaghetti code" that developers will hate. So we're erring on the side of caution, for now.


            As the usage of Catalyst evolves, we'll try to observe the patterns that are emerging and then incorporate them into Catalyst.



            1 person found this helpful
            • 3. Re: State transitions across components?
              Jaanus Kase Level 1



              thanks for your comment. Yes, I am glad there is currently a way for me to edit the code to achieve what I need, outside of the UI.


              I agree with your goal of wanting to have some architecture, instead of having objects running around fiddling with one another. However, if you look at what's going on in the UI already today, if you have a state with a bunch of components inside it, and those in turn having further components, you can already change all those in the UI. You just add additional "on click" actions to button and make it change states of multiple components upon the same click, which is already a little bit spaghetti-esque.


              From the above, it's not too big of a stretch to imagine being able to change state of components "above" you, in addition to those "below" you.


              "some architecture to manage the states of objects" — I as an interaction designer actually have a model in my head of what that architecture should be from an IxD perspective. It's an interesting question (which I don't know the answer to) of how to model that in the Catalyst UI — so that button clicks wouldn't just change states on a low level, but it's a clear part of some more higher-level architectural picture (I guess you could call it information architecture/navigation map of your application).

              • 4. Re: State transitions across components?
                EL Kay Dee



                Just my, hopefully helpful thoughts about how to render complex state transition much easier to understand, design and debug ...............


                Perhaps, initially for coders with a solid background in conditional logic, the inclusion of one or two design windows/panels providing the ability to design and display at least state transition diagrams and preferably also state transition tables, could be very helpful when trying to either design or understand complex, inter-related state transitions - actually, even relatively simple state-transitions with only five to seven objects, each with only three or four states to track concurrently, can be difficult to design, debug and test using just a mental model and memory to retain knowledge of the desired vs. actual state transition paths.


                Although I say "initially for coders", many years ago I taught both of these techniques successfully during software "design principles" courses that addressed software developers who's function was to prepare "design specifications" rather than actually write the code which, in those days, was the job of programmers rather than designers.  In fact many of my students were not programmers at all - for example analysts who used state transition diagramming techniques to design functions regardless of whether those functions would become implemented as code, or as a set of human actions, or mechanical machine operations (think pinball!).


                It should be possible using today's technoloy to be able to

                    (a) generate code from a state transition table or a state transition diagram and

                    (b) generate both forms of diagram from existing code (including the code autogenerated during visual design and

                    (c) consistency check existing code automatically.


                It should be possible, using state transition table and diagram functions, to highlight structural logic errors.  How such highlighting should be done, for example:

                    (a) using a classic state transition table or diagram or

                    (b) generating some form of structured text report or

                    (c) inserting colour-highlighted error messages in-line in the code or

                    (c) some other more visual-designer-oriented signalling technique or

                    (d) a combination of several of the above


                would be a design issue for Adobe.  This would not be a trivial exercise for Adobe, but the functionality would be reusable, i.e. transferable into other products.


                After all, the only reason for such tables or diagrams is to render complex state transitions understandable by humans, and these two techniques have proved extremely useful for many decades in many areas of design - programming, electronic circuit design, machine design, business process design......


                Re. Catalys, it's just a classic program design application, with some whizzy UI graphics that need to display, disappear, change colour, glow, shimmer, move, .... in predictable and desirable ways.


                The original pinball machines used mechanical relays to implement their underlying state transition diagrams; pinball designers needed to understand at least two things (a) complex state transitions and (b) a well designed UI. From this point of view, Catalyst looks like a pinball design panel!