Juan Sanchez

This week, RJ Owen, Leonard Souza and I presented a multiscreen app we built for Adobe MAX. The app was a “social jukebox” that lets party attendees play a role in DJing the party. That is, they can vote for the songs they want to hear at the party and songs with the most votes get pushed higher in the song play queue. We built a touch-enabled desktop app that acts as the “host” for the music and then there is a mobile app that allows people to interact with the desktop application.

The apps were fun to build and we used a number of Adobe technologies to pull them off. We’re hoping to keep pushing the multiscreen experience to include TV using Adobe AIR and an app for iOS. In the meantime, you can check out the images of the app in this post, our slide deck and our presentation on Adobe TV as soon as it’s available. We hope to follow up with a series of blog posts on how we built these apps.

Really great seeing an evolution in the way people might interact with media that was originally created for print. I wonder if at some point print will be phased out and offered at a premium price.

via Introducing a New Digital Magazine Experience – Adobe Digital Publishing.

Recently, I gave a talk on why Adobe Fireworks is the de facto tool I use for designing applications and websites. People seemed to be amazed at how well Fireworks is set up for designing for highly states-based projects and how quickly you can make broad changes so quickly.

During the presentation I went on a tangent about how Fireworks should be *the* design companion to Flash Catalyst, because the applications map nearly one-to-one in the way projects are organized. Much better than Photoshop and Illustrator, which you can currently import into Flash Catalyst.

Anyways, I thought I’d run through in more detail (a.k.a. ramble about) some of the reasons why Fireworks should tie more tightly into Flash Catalyst more than other applications. Lately, it feels like Fireworks has been given little to know attention and I’d like to see that change.

Vector and Bitmap Editing

One of the things I like about Fireworks is the Vector and Bitmap editing environment. This means vector precision for artwork and powerful bitmap filters and effects. The reason I like this that I can bring vector artwork from Illustrator into Fireworks and have complete access to all the vector points. I can do bitmap editing with images I might bring in from Photoshop. I can copy/paste artwork directly from Fireworks into Flash. All this just makes it easier for me to produce a design for Flash, HTML, iPhone, or whatever.

If I could import a Fireworks file into Catalyst and Catalyst could use all of Flash’s powerful vector and bitmap rendering without any loss of fidelity, that’d be awesome.

Pages, States and Layers

If you’ve played around with Flash Catalyst you may be familiar with Pages and States. Maybe you’ve thought, “Man, it’d be great if there was a design tool that mirrored the Pages and States of Flash Catalyst”. Well, there is. It’s called Fireworks. Check it out:

Fireworks Pages and States

Catalyst Pages and States

If you’ve never used Fireworks, Pages and States is a super powerful feature. It makes my life so much easier keeping things organized. It pains me to see the files of designers who’ve created designs for apps/websites in Photoshop and Illustrator (I used to be one). So many files and layers to navigate. Here’s a little diagram I put together showing how you might organize a file in Fireworks.

Basically, Pages are major views of your app and States are the sub-views (like things expanded/collapsed, tile/list view, etc.). Everyone knows what Layers are (Fireworks has them too). Symbols are used for common elements, like Buttons, Navigation Bars, etc. Styles are things like Drop Shadows, Gradients, etc. saved together as a Style for easy application to other artwork.

Sharing to Pages and States

Another feature that is common across Fireworks and Catalyst is the ability to share artwork across States. In Fireworks you can share across Pages too. This means that if I have a common element, let’s say an icon in a button, and I want that icon to show up across all States, I can just share that Layer to all States. Again, this is a great way to optimize your workflow when a client asks you to make some kind of global change.

Symbols

Many Adobe applications support Symbols. A Symbol is like a group of artwork, but when you change the artwork it changes across every instance of that Symbol. For example, I can make a graphics that represent a blue button into a Symbol. If a client says, “Please make the blue in the buttons grey” I just drill into the Symbol, change the colors and anywhere I used that blue button symbol would now turn to grey. Symbols really help insure consistency as you design, just as you’d like to maintain consistency in an application you might be designing.

The way I think about Symbols in Fireworks are almost like components in Flash Catalyst. In Catalyst, if I turn artwork into a component, that component has States and I can change the State of that component from outside the component. I’d like to see this translate to Symbols in Fireworks, so I can define some States within a Symbol and then change a Symbol’s state without being inside the Symbol.

The thing is, Fireworks already let’s you define States within a Symbol. However, I have no way of changing that State from outside the Symbol. Even if it was just a little combo box that showed up when I selected a Symbol so I could change the state, that would be awesome. And, when I brought my Fireworks file into Catalyst the States would map 1:1.

Rich Symbols

Rich Symbols take regular Symbols to a near component level. I can make a Rich Symbol that has a space for variable text, define States, etc. and then changes any of those properties from a panel in Fireworks. However, it’s a pain in the ass to make them. I would like making Rich Symbols as easy as converting artwork to components in Fireworks. This coupled with a solution to my bitching in the previous Symbols section would make me a happy guy. And, again, this would integrate well with Flash Catalyst.

9-Slice Scaling

If you’ve worked with Flex or checked out CSS3 stuff you’re probably familiar with 9-Slice Scaling. You define some grid lines in a Symbol which dictate the way artwork scales. This is that magic feature that prevents your rounded corners from flattening out. It’s a great feature that should carry through importing from Fireworks into Catalyst.

In fact, I think it’s the only app where 9-Slice can be used on a text box, so as you scale artwork that has a text box in it the text box with scale rather than the text. It’d also be nice to see better/advanced text handling in Fireworks, kinda like the Text Layout Framework, which should import flawlessly into Catalyst.

Prototyping

Right now, I use Fireworks to prototype HTML apps, iPhone apps, desktop apps, etc. The built in features for this are great for getting something together really quickly, but I feel like they could be taken a lot further by carrying that functionality over to Catalyst. Just ditch that functionality in Fireworks in favor for using Catalyst’s strengths of a interaction design tool.

So…

I think there’s also a lot of untapped potential for Fireworks, but I’m more concerned that Fireworks will get killed off. If I had my way I would make it the design companion to Catalyst and drop support for Photoshop and Illustrator in Fireworks just because Fireworks and Catalyst overlap so much. I know those both drive revenue more than Fireworks for Adobe, but I’m talking if I could wipe the slate clean and focus on a specific workflow versus making every app under the sun work with every other app.

For all I know maybe all this stuff is coming in Fireworks CS5 or CS6, but I just thought I’d call out some of the things I, as a heavy Fireworks user, would like to see as part of the future for the product.

Recently, I had the opportunity to create some skins for Adobe’s Open Source Media Framework (OSMF) Flash Sample Video Player. Even though this was a quick project, I thought I’d put together a post that talked a little bit about the OSMF, the sample video player, and give a summary of how the whole thing went from design to final deliverable.

When I first heard about this opportunity I was a little worried about how difficult it might be to implement any designs I might come up with into the video player. Then I learned that Adobe was working with my friends at RealEyes and that I had a chance to influence the way the skin template for the video player would come together. I was sold.

The nice thing about this project was that a lot of the functionality had already been thought through, so it was purely a design and implementation project for me.

The Design Phase

Every project starts by getting everything that’s in my head on to paper via sketches and notes. I also try to get inspired in some way. Between my sketchbook and some inspiration, I can start to formalize ideas and develop some themes based on goals for the project.

Initially, I struggled with designs, mainly because when I think of a video player, I think of something that should almost be transparent or evident only when I need it to be. At the same time, these skins needed to represent different levels of customization that can be achieved with the OSMF Sample Video Player.

The way I broke through this was to draw inspiration from the visuals that would be displayed through the player e.g. movies, anime, TV shows, etc. I began to explore the idea of having the video player fit the content it would be playing. That idea was carried through the sketches and into some more polished design comps.

I always try to give my designs names to capture a concept and for easy reference, so we’re not referring to things like, “that blue one with the dark glossiness”. The designs that were chosen to move forward with were Formula, Core and Lunar.

In addition to the initial designs, there was also some time spent on developing some color variations. I tried to narrow down the colors to a minimal color scheme of 1-3 colors to make it easy to customize the skins. It was color theory class all over again.

Production and Implementation

After going through a round of color variations and picking the final designs I got to switch into production mode. I do all my designing in Fireworks, so I brought the designed assets into the Flash skin template that RealEyes was working on. States, animations and other visual design elements were also added once I had the necessary assets in Flash.

All along the way I was testing how the designs looked in the player itself. As I started putting the skins together there was a great deal of collaboration between myself and RealEyes. The result was a skin template that had a nice structure, but also allowed a wide spectrum of customization. You can use a skin and make minor changes to colors and fonts, or you can dream up something completely crazy and implement it very easily. It was pretty fun to work with actually.

Wrap Up

RealEyes kicked ass bringing this thing together and I appreciated them using me as a sounding board for ideas around how the final skin template should work. Adobe’s OSMF team let us do our thing while giving great feedback and direction all along the way. We all wanted people without any programming knowledge to be able to jump into a template and bring their designs to life as easily as possible. I think we achieved that.

You can learn more about Adobe’s Open Source Media Framework on the website. Check there to find out where to access the skins and sample video player.