Tuesday, November 25, 2008

Flash Catalyst Tutorial: Weather Widget, Part 2

Download the current .fxp file here: weatherWidget_2.fxp


To view part 1 of this tutorial, click here.


Designing the Second State

In this part of our project, the designer is planning on adding some more elements to our wireframe to begin to flesh out the experience design (XD) of the application. In the iPhone and Dashboard versions of the weather widget, the 'back side' of the application has a function to choose which cities you'd like to track the weather for. Our designer decides to begin with this part of the app.

In Flash Catalyst, our designer opens up the .fxp file and creates a new blank state by clicking on the 'New Blank Slate' button in the Pages/States panel. Interface elements are placed in the new state and a state title of 'chooseCity' is given to this second state. In the chooseCity state the user is presented with a list of current cities that are being tracked in a scrolling list. Each item in this list has the name of the city and a button to remove the city from the list. There is also a button to add a new city at the top of the interface as well as a button to go back to the previous view. All of the UI elements are placed on the stage. 


Adobe Flash Catalyst - weatherWidget_2
Uploaded with plasq's Skitch!

Next, our designer realizes that the scrolling list will have more than one city listed for a typical user. Since the items in the list will be similar, he decides to make this a Custom Component... good call! We create the custom component in the same way we created the dayComponent in the first part - select all the items for the component (remove button, city title, surrounding box) and click on the 'Convert Artwork to Component > Custom/Generic Component' in the heads up display (HUD).

Now that our second state wireframe is complete, we'll build the transition from one state to the next. For those of you that attended MAX in San Francisco and were lucky enough to get into the hands-on lab with Catalyst, you'll recognize the transition we're going to build. It is a rotational transition that makes the application flip over like a card to show the 'back side' of the app. This is the same transition that Apple uses on the iPhone and in Dashboard.

Begin by having the Timeline panel viewable - double clicking on the tab works if it's collapsed. Because we had Auto Effects for New Transitions checked by default in Flash Catalyst (it's in the Timelines menu) you should see some standard fade transitions between the 2 states. All the way to the left in the Timeline panel you will see 2 State Transitions - View City > Choose City and Choose City > View City. These represent the names of the 2 view states we've defined so far. We added 2 actions to each state transition - Rotate 3D - by clicking on the row for the item to be transitions (city and cityListGroup) and then clicking on the 'Add Action > Rotate 3D' button. We then selected each Rotate transition and changed the values to the ones in the diagrams below in the HUD. For the second state transition (the one that goes back to the viewCity state) we just reversed the order of the transitions.


transition_1
Uploaded with plasq's Skitch!

transition_2
Uploaded with plasq's Skitch!

To trigger the interactivity for the transitions, our designer selects the round button in the first state, and adds a transition to second state interaction. On the second state, the back button is selected and an interaction is set to go back to the first state. If you run the application, you will see a transition like the one below. (click image to play movie)










Handoff to the Developer

The designer is satisfied with the transitions and basic wireframe positioning of elements and saves his .fxp and hands off to the developer again. Our developer realizes that some changes have been made to our project with a warning presented to him in Gumbo on import of our updated .fxp file. He accepts the changes as none are critical to the functionality already built.

The first thing our developer does is to rename the newCustomComponent that our designer created in Catalyst - I'm hoping that Catalyst will allow you to declare class names in the future so as not to require that as part of the workflow - so that our naming conventions are consistent with one another.

weatherWidgetTutorial_2_4
Uploaded with plasq's Skitch!

After digging into the created code a bit, our developer realizes that the button component that our designer created to transition from state 1 to state 2 is just 'floating' in state 1 and not part of a group or custom component. He thinks that might not be the best way to have this button represented and decides to place it into the group on state 1. The problem is, when doing this, it becomes difficult to access the state transition that occurs 1 level up in the display list chain. There is no event that would allow us to track this user interaction so a custom event class is created: FlipEvent.

weatherWidget_tutorial_2_5
Uploaded with plasq's Skitch!

Our developer opens the cityComponent class and adds a few lines of code to include the new custom FlipEvent we've created. He ties that to the button - hmm, gotta' rename that button ;) - which triggers a function to dispatch our new event.

weatherWidget_tutorial_2_6
Uploaded with plasq's Skitch!

Because our cityComponent is now set up to dispatch our 'flip' event, we can listen for that event in our application! In the weatherWidget_2 file, we add some code to listen for the event to be triggered. Rather than setting up a function to be called to switch the states of the app, we're using a shorthand for that by using the {} with our expression embedded in it to switch the currentState property.

Flex Development - weatherWidget_2/src/weatherWidget_2.mxml - Flex Builder Gumbo - /Users/erik/Documents/Gumbo MAX Preview
Uploaded with plasq's Skitch!

When we test our application now, we have the same effect as displayed in Catalyst, but we are now using a custom event to trigger our transition.

Part 3 - Let's get some skin on this sucker!

Monday, November 24, 2008

Flash Catalyst Tutorial: Weather Widget, Part 1

I've been playing with Flash Catalyst for a few days now and have a pretty good handle on the basics. I was scrounging around the web trying to find a tutorial or any sample files anyone had done with the MAX release of the software, but have not been able to find one. So, I thought I'd put one together myself and share.

The idea for this sample is to try to emulate and demonstrate the capabilities of Flash Catalyst, Flex Gumbo, and the designer/developer workflow. I hope that I am accurate on my assumptions for the software and it's best practices - given that it has only been in the public eye for a week or so. Please feel free to comment on suggestions and ideas for the tools and techniques. On with the show!

Catalyst Weather Widget

The current .fxp document: weatherWidget.fxp.zip

Our client has asked us to build a weather widget application to have on their travel site. They love the iPhone and would like us to build an application that very closely emulates the functionality and design of the iPhone's built in weather application.

The first step in our process will be to create wireframes of the application. In our wireframe, we will capture all of the major sections of content and their basic placement within the constraints of the application footprint. Our designer opens up Flash Catalyst and begins to block out areas for data and imagery.

catalyst_weatherWidget_1
Uploaded with plasq's Skitch!

All of the sections were placed on the Catalyst canvas using the tools in the toolbar (box, text field, circle). The top section was created first with a text holder for the city, the hi and low for the day, the current temperature and an area for the current weather graphic (snow, rain, sunny, etc). This section was then grouped to make it easier to move around the stage.

Create the dayComponent
Next, the designer created 1 day section by laying down a rectangle for the surrounding box, text holders for the day, the hi and the lo, and a box to serve as a placeholder for the forecasted weather graphic. The day section contents were then converted into a custom component by selecting 'Convert Artwork to Component' > 'Custom/Generic Component' from the heads up display (HUD). Our designer duplicated the new dayComponent 6 times and spaced them evenly down the space to represent each of the days of the following week of forecasts.

Create the cityComponent
After returning to the main stage by clicking on the leftmost link (not sure what this is called exactly, but it's the crumb trail that is displayed immediately below the 'Pages/States' section in the interface), our designer selects all of the contents of the application that have been built so far. This includes the top section (in a group), the seven day components, and the little round button on the lower right. With all the items selected, we again convert into a custom component by selecting 'Convert Artwork to Component' > 'Custom/Generic Component' from the HUD. We now have a cityComponent as a custom component that is made up of a top section and seven embedded dayComponents... looking good!

When we test our application at this point, the wireframe has the correct positioning for it's components but not much else. Because the dayComponents are all the same, and Catalyst doesn't support and UI based logic statements, it's time to put our code hats on!

Handoff to Flex Gumbo #1

Our first step of our developer is to import the Flash Catalyst .fxp file. When we do, we're presented with a Flex Package Explorer that looks something like this:


Flex Development - weatherWidget/src/weatherWidget.mxml - Flex Builder Gumbo - /Users/erik/Documents/Gumbo MAX Preview

Editing the dayComponent.mxml
Our first task is to add some mechanism to dynamically name the component text areas within our application. We'll do this in Flex using databinding and with some custom parameters. At the top of the dayComponent file, we'll add some <Script> tags and define 3 variables for the textfields in our component - day, hi and lo. Then, we go to each <TextGraphic> tag and find the 'text' attribute. This defines the text to be displayed in our component. We use the binding symbol of curly braces '{ }' and place the names of our variables on the appropriate TextGraphic tag.

Flex Development - weatherWidget/src/components/dayComponent.mxml - Flex Builder Gumbo - /Users/erik/Documents/Gumbo MAX Preview
Uploaded with plasq's Skitch!

Editing the cityComponent.mxml
Next, we open our cityComponent.mxml document and add the code required for this to be dynamic. We add another Script section to the top of our document, this time including the city, dayHi, dayLo, and currentTemp as variables to display in the top section of the interface. Down on line 37, we replace our text parameters with our curly brace friend and the appropriate variable name. You'll notice that our developer wanted to keep the 'H:' and 'L:' as prefixes to the hi and lo information in the design. The way that is done is with string concatenation which is indicated here by this code:

text="{'H: '+dayHi}"

Basically, that states - take the letters 'H', ':', and a space and then add to that string, the value of dayHi.. easy peasy!

Now then. Since we've already edited our dayComponent.mxml to include a new variable called day (check out the screen shot from above) we can add values for those names in our cityComponent file! The next blocked out section in the diagram shows the dayComponent placed on the stage and at the end of each line a 'day' variable is being defined. One of the cool things about using Flex Builder is the fact that because we've defined this variable in our dayComponent 'class', Flex Builder code hints this new variable for us to fill out... less typing = happy carpal tunnel ;)


Flex Development - weatherWidget/src/components/cityComponent.mxml - Flex Builder Gumbo - /Users/erik/Documents/Gumbo MAX Preview
Uploaded with plasq's Skitch!

Editing the weatherWidget.mxml
Last part of our first handoff is for our developer to open the weatherWidget.mxml document and define the variables that he has created. We define the city, currentTemp, dayHi and dayLo on our cityComponent tag.


Flex Development - weatherWidget/src/weatherWidget.mxml - Flex Builder Gumbo - /Users/erik/Documents/Gumbo MAX Preview
Uploaded with plasq's Skitch!

OK. We've had our designer create a basic wireframed application - blocking out areas of content and imagery. When our designer runs the application out of Flash Catalyst, the blocked out areas are correct, but all the names of the days are the same and information is 'hard coded' into the text fields. Our developer picks up the .fxp file from our designer and he adds a few simple lines of binded variables and scripting code. When our application is run now, the names of the days are 'dynamically' placed and the application has the basic structure we'll need for further steps.

If you open the weatherWidget.fxp document in Flash Catalyst, you'll notice a strange looking thing - What is up with those long curly braced names?


Adobe Flash Catalyst - weatherWidget
Uploaded with plasq's Skitch!

Remember, our developer replaced the names of our 'hard-coded' values with binding variables. If you dig into the components in Flash Catalyst, you'll see that the text name in the HUD's are now the binding names from Flex Gumbo with the curly braces... aha! So don't change them, or our developer friend will have to change them back again. Actually, when the developer re-imports the .fxp after we do some more designing, he'll have the option to write over changes or not, so I guess that last statement is up to your normal workflow process you have at your gig.

The current .fxp document: weatherWidget.fxp.zip

Stay tuned for Part 2!

Tour de Flex: Great AIR App for Flex Developers

One nice utility application that was released at the MAX conference this year was the Tour de Flex AIR application. It's a great utility for referencing Flex and AIR objects and API's. You can download it by clicking on the badge below:

Friday, November 21, 2008

Flash Catalyst in the Wild!

Adobe released a 'MAX Preview' of the anxiously awaited Flash Catalyst (Thermo) this year at the MAX conference. Catalyst is a design centric application that allows a designer to work in tools they are graphically comfortable in - Photoshop, Fireworks, Illustrator - and import them into Catalyst to add expressive functionality all the while creating a working Flex application.

The preview is well executed but does have a 'raw' feel to it. The full application is not expected for a year... or at least that was the general statement from Adobe folks. There are a limited number of components available at this time but when the application reaches a public beta, I would expect quite a few more to be added.

The one thing that Catalyst does seem to be ready for right now is it's use as a wireframing tool! In fact, Catalyst might be THE wireframing tool of choice for experience design professionals. On the flight home from San Francisco, I was able to make 5 or 6 different versions of an application that Christian, Joe, and I have been kicking around! These are fully immersive wireframe models with clickable areas and transitions from state to state. They give the very lo-fidelity prototype 'teeth' that can be evaluated and iterated upon. It's exciting to see the potential! I'll post screen shots and some samples soon.

Chrysler Didn't Win at MAX

Oh well. The Chrysler application that we from Knoware worked on last year did not win the MAX award at this year's Adobe MAX conference. But, it was an honor to be involved with a project that was nominated none the less! Scrapblog.com was the winning entry in the section that the Chrysler application was up for. Congrats to Scrapblog and their excellent RIA!

Monday, November 10, 2008

Woohoo! Adobe MAX Awards Chrysler wiTech AIR app

Joe Johnston of Universal Mind forwarded a link to me the other day regarding the Adobe MAX Awards for 2008. One of the finalists in the contest for the RIA category is an application that Joe, Christian Saylor, Tim Todish, Grant Carmichael, Mike Kopchick and I worked on back in the day - Chrysler's wiTech Auto Diagnostic AIR application. Our team worked with the team at Atomic Object on the original proof of concept as well as a good portion of the final build.

This application was built to display the diagnostics of a vehicle when the mechanic hooks the car up to the 'computer'. Joe, Tim, Christian, Grant, Mike and I worked on this back when we were all at Knoware. Jim Mitchell was our point person over at Chrysler when we worked on this app. Congrats to Jim and the Chrysler crew for all the hard work on the completed app!

Big props to Joe, Christian, Tim, Grant, Mike and the AO crew for all their work on the app - since the original team is nowhere to be seen in the award entry on the MAX site... bummer!