We haven't planned this far out...we're trying to keep it simple and then see what people need.
I can say that we're not planning to add much more sophisticated scripting logic in the first version. After that...who knows?
Would you prefer to be able to drop in simple ActionScript, or would you prefer visual building blocks (similar to the way Interactions work now, but more complex)? Or something else?
I'm at the exact same place. My first time playing with Catalyst, I decided to try and recreate the interface of an existing Flash app we'll be taking to Flex at time point in the future. The first screen I try to replicate is the Login Screen.
I'm thinking that the Catalyst interface is something similar to the existing approach for handling onClick. After onClick, you'd have to add a step to Validate Text Input. The developer/designer would have to supply a string for each of the text fields used on the page state. Once that step is complete, the developer/designer would define which state to transition to depending if the validation returns true or false. To keep it simple, limit the developer/designer supplied string to a single string without spaces.
As a workarond, I put a row of buttons below my login screen, so I could click each one and navigate from initial state, to login error, to server connection error, without entering text into the input text fields. I have all three states for the login screen. Problem is it interrupts the production flow from design to development. I'll need to remove the extra buttons before moving to Flex to complete development.
That makes me wonder. I've not gotten to that step yet where I'm moving out of Catalyst and into Flex. Is there a way to identify components or layers that should not be exported to Flex? That might solve a larger list of obstacles for designers/developers who need to navigate to different states depending on text input or selections from one or more data lists. We could add a layer that lets us do more complex navigation within flex for ourselves, clients, etc. and then just not include those navigation tools when the time comes to move from UX development to Flex app development.
thanks for bringing this thread up. I am at the same crossroads as an IxD. ESPECIALLY for login scenarios, it would be very helpful to add some basic conditional logic. the use case that i got stuck at was that the user could arrive at the login page from many different scenarios (sign up, etc etc) and as a prototyper, i would like to be able to control where the user will go depending on where they came from..
I have the same needs — controlling the UI behavior and appearance based on some conditions.
It is currently possible if you have multiple buttons. So specifically, for sign in, you could have a "Sign in - right password" and "Sign in - wrong password" buttons, which go into a different next state. Or, before that state, you have another meta-state, where you pick "start scenario - sign in with right password" and "start scenario - sign in with wrong password" which take you to two different states that look the same but behave differently.
This is kind of similar to Wizard of Oz experiment. If you are just designing the interface, you are the same person as experimenter and designer — you just change the system state and see how it behaves in all states.
So, just a random idea, you could imagine that outside of the actual UI that is loaded, there is another "Wizard of Oz" panel, where you manually set variables at runtime. And you can then design around these variables.
Specifically talking about the password case, you can have a Wizard of Oz variable "password" with two states, "correct" and "wrong". And in your design, you can say "When password variable = correct, goto state X", "When password variable = wrong, goto state Y". Similarly to how you currently can say that some transitions happens based on what state the system is currently in.
Pushing this example a bit further, you can imagine rich and complex designs when you can not only get variable values from the Wizard of Oz panel, but also set them. (if button X is clicked, set variable A to value B.) This probably goes really into Builder/developer territory, but if you limit the variables to really basic things (e.g only simple textual values, or the values must always be predetermined and you can only select one of multiple values instead of free input etc), feels like this would be the scope of interaction design and Catalyst.
Now, let's say the Wizard of Oz panel and the UI loaded in the browser do not need to be running in the same computer: that the user and "experimenter" can be on two different computers. This would facilitate true interactive Wizard of Oz testing.
These are really interesting posts. Thanks for sharing your thoughts. We're listening.