Lucid Design Group Uses the Flash Platform to Help Save the World One Dashboard at a Time

With global warming on the rise, Lucid Design Group, a privately held cleantech software company, wanted to create something that would educate and inspire people to change their daily habits to help reduce consumption in their homes and offices (like turning off lights and unplugging appliances). Lucid developed Building Dashboard, a data visualization and communication application that monitors the use of electricity, water, natural gas and heating, and encourages social networking around the topic of resource conservation. It’s available via the Web, kiosks and mobile devices using the Adobe Flash Platform and Adobe Creative Suite Design Premium. With Building Dashboard (a MAX 2010 award finalist) in place, Fortune 500 companies, universities and residential customers saw consistent energy reductions up to 20 percent.

Coined “the first social network for buildings,” Building Dashboard employed the Flash Platform to help develop and deliver widgets, apps, maps and flow lists to encourage users of all technical backgrounds to save resources and understand their resource consumption levels. Currently, nearly 100 U.S. colleges and universities are using Building Dashboard to support key sustainability initiatives to reduce carbon dioxide emissions across campus.

To streamline the developmental process behind Building Dashboard, Lucid used a variety of Adobe products including Flash Catalyst, Flash Player, Flex, Flash Professional, Photoshop and Flash Builder. The advantage of working with various Adobe products is seamless integration. For example, Adobe Flash Builder helped improve the Flex development process while Adobe Flash Catalyst and Adobe Flash Builder expedited design/developer workflow, ultimately reducing design and development time by one third. By adding Adobe Flash Player to the mix, Lucid developers could run their product across different platforms, devices and operating systems, while cutting testing time in half.

To learn more about how Lucid worked with Adobe technologies and to see how New York-based Hamilton College uses Building Dashboard, read their story here.

Adobe Tools and HTML5/CSS3

Two of the people behind the products in Creative Suite have started a blog specifically about design and web technologies.

We have been spending a lot of time internally thinking about how our tools can best support and take advantage of some of the new functionality in HTML 5, and we wanted to share a couple of early ideas with you.

I’ve always thought that once HTML5 got a bit more concrete, you’d see design tools from Adobe that took advantage of it. The benefit of Flash is that we control the runtime and can tie features to the development cycle of our tools. Not the case with HTML5 and CSS3. But now that the standards have started to coalesce and have support in more browsers, we can make those features part of our design tools. Hopefully we’ll see a lot more of the examples above and I’d encourage you to keep an eye on the blog for info about design tools at Adobe and the web.

And the winner is…

Well… Picking a winner in my blog design contest was far from easy. I had multiple favorites and so I asked a few friends to help me pick the winner. We eventually narrowed it down to 2 and then did a final voting round.
The winner is Marten De Jongh, a freelance photographer/designer from The Netherlands. […]

Blog design contest: Design my blog and win CS4 Master Collection!

Last week I realized that I am not 100% happy with the blog theme I recently installed. I like it but it’s not quite exactly what I wanted. In all honesty, I don’t really like fiddling around with CSS and HTML. I hate having to navigate around different browser implementations and therefor never really got […]

Introducing “Contextual Applications”

We did a soft launch with some information of a concept that Adrian Ludwig and some of the other brain-trust folks at Adobe came up with recently called Contextual Applications. I have absolutely fallen in love with this term (and I had nothing to do with thinking of it). In a lot of ways I think this is RIA 2.0. One of the problems with RIA was that it had a grossly vague definition. It was kind of a Frankenstein combination of a desktop-like user experience, better design, real-time communication, rich media, and Web 2.0 ideals. In the end, RIA encompassed almost everything; Ajax, Flash, Silverlight, Adobe AIR, WPF, etc. That’s not a bad thing but it became hard to distinguish the value of RIAs because everyone could claim they were doing “RIA stuff”. The important thing is that we made a lot of progress with RIA and changed how people thought about software development.

Defining Contextual Applications

Contextual applications are a lot more concrete and have a better value proposition for both end-user and developer. It isn’t defined by a particular technology but instead a particular type of experience. So what is it? The idea is fairly simple. You’ve got a core set of data and a core experience that you have to deliver. But in today’s web there are multiple “touch points” out there. What about mobile? The desktop? A browser experience? A widget? An experience specific for social networking? Maybe a television? Users expect to have their content everywhere, on demand, regardless of how they’re connecting to it. The user experience and design challenge is creating a unified brand and experience that leverages the same content and is tailored to the specific technology limitations of a particular “touch point”. Solving that challenge will give you a contextual application. An application that moves with the user across a number of screens/devices while maintaining content and a user experience that is consistent but unique to each device.

Finetune: The Ultimate Contextual Application

The Contextual applications site has a number of examples but my favorite is definitely Finetune. They are a great example of one of the earliest contextual applications. They started out with a web-based application. Then, with the benefits of the desktop they created an AIR application that had native windows and used the file-system capabilities of AIR to tie into the iTunes library and pull artists that were interesting to the user; using the technological features of the underlying touch point to customize the experience. Then they were interested in deploying a version of the Wii so they created a Wii-specific browser application that ran on the Flash Player in the Wii and maintained the Finetune branding. Then of course mobile was a big demand. So they built to mobile applications; a Flash Lite app that reused a lot of code and still maintained the Finetune experience but customized for the small screen. They also built an iPhone app with touch support that captured the experience of the iPhone while maintaining that core Finetune interface.

To me, the Flash Platform stands alone at being able to let developers and designers easily deploy contextual applications. With so many different operating systems and screens supported, it becomes easy to reuse the tools and workflows to create applications that are tailored for those screens while maintaing a sense of continuity. And think about the server infrastructure. Are you using FMS to stream Flash Video content? That content will be supported everywhere the Flash Player is so you can quickly jump between screens and be sure that your base content, the most important thing, is completely in tact. It lets you design around your content and maintain that emotional branded connection with your users.

Ultimately it is about productivity. The number of touch points is only increasing and to be able to deploy on as many of them as possible you need to be able to reuse code, design assets, and workflows as quickly as possible. The Flash Platform gives you the broadest reach with a large community of designers and developers who are skilled with the tools. Ultimately that means you’ll be able to create contextual applications quickly and reach your users wherever they are. That’s why I’m so excited about this concept: ultimately it gives the user more control.

Iterative Design/Development with Flash Catalyst and Flash Builder

As I talk to more and more designers and developers one of the things that comes up is whether or not Catalyst makes it easier or harder to do iterative design on a project. The workflow most people have seen is you start in a tool like Illustrator, Photoshop, or Fireworks; create a high fidelity visual design in that tool and then import that into Flash Catalyst where you can start turning that artwork into visual components. I think that’s a pretty powerful workflow for designers of all stripes.

The issue that comes up most is that not everyone starts that way. In a lot of cases people create a skeleton application first in Flash Builder and then want to apply visual designs later. Themes are one option, and we’ve got a new Theme chooser in Flash Builder to help that, but one of the great things about Flex 4 is that it’s easy to create very customized, unique skins for components. So without the ability to do round-tripping between Flash Catalyst and Flash Builder in the 1.0 version of Catalyst, what can designers to to iterate on a design alongside a developer? The answer is the Flex Library project.

I realize this is far from an ideal workflow, but I think for Flash Catalyst 1.0 and Flash Builder 4 it works okay and provides a way for teams of designers and developer to iterate together without stepping on each others toes.

Core Steps

  • Export assets to a Library Project in Flash Catalyst.
  • Import that Library Project as a Library Project into Flash Builder
  • Link the imported Library Project to your main Flash Builder project.
  • Make design changes in Flash Catalyst.
  • Re-export the Library Project and import it by overwriting the old Flash Builder Library Project
  • Your main Flash Builder project will be updated with the new design.

Detailed Walkthrough

So lets say a developer has an application that they’ve created with the default components. I’ll start with something really basic:

<s:Button x="19" y="78" label="Button"/>
<s:HSlider x="210" y="31" />
<s:List x="152" y="108">
 
</s:List>
<s:TextInput x="10" y="31"/>
<s:Button x="152" y="77"/>

iterate_design_01

Clearly a great RIA in the making. But I take a lot of pride in my work and I want to use the power of Flex 4 to create a unique set of skins and components that stand out. In the ideal workflow I would be able to give this to my designer, they would open it in Catalyst, create some great components, and send it back to me. I can’t do that, but I can do some design in Catalyst and then bring those designs in a special way. First I’ll create some great looking components in Catalyst by starting with a blank project and importing Illustrator/Photoshop assets then converting them to components.

itreate_design_03

After I turn all of my artwork into interactive components I am going to pop over to the library panel and start giving them usable names. By default Catalyst calls the created components “Button1″, “Button2″, “ItemRenderer1″, etc. I give them names that will mean something to the developer and help differentiate components.

iterate_design_02

Once I do that, all I have to do is export my library file into an FXPL file by right-clicking anywhere in Catalyst’s Library panel. Once I can do that, I have the ability to import that FXPL file as a new Flex Library project in Flash Builder.

iterate_design_04

That library file contains all of the assets and skinned components I just created. In order to use those, all I need to do is add that project to my main Flex project from the project Properties->Flex Build Path and I can start changing the skinClass attribute for my components to point to those new files.

<s:Button x="19" y="78" label="Button" skinClass="components.BlackPushButton"/>
<s:HSlider x="210" y="31" skinClass="components.MetallicSlider"/>
<s:List x="152" y="108" skinClass="components.GreyDataList">
 
</s:List>
<s:TextInput x="10" y="31" skinClass="components.MetallicTextInput"/>
<s:Button x="152" y="77" label="Button" skinClass="components.GreyButton"/>

iterate_design_05

But now the client tells us they want that black button to be an interstate sign (who knows). I have that asset in Illustrator so I can open my original Flash Catalyst file that I created the library project in and I have a couple of options. I could create a new button with a unique name or I can change the original button component using the round-tripping between Illustrator. I’ll do the latter.

iterate_design_06

Once that’s finished toggle back to the Library panel and re-export the assets making sure to overwrite the original file. Then switch back to Flash Builder and go through the import process again. By default, it will try to create a new project and just append “_1″ to the project folder. Make sure you overwrite your project by removing that. You’ll get a warning, but that’s fine.

This is where the magic happens. Without doing anything, you can run your application and you’ll automatically have those new assets. Any event handlers you’ve wired up to the button or any code you’ve created that use that button will remain unchanged; only the button graphics will change. Because the projects are linked, any change we make to our imported assets filter down to our core project.

The designer can use that original Catalyst file and the re-export process to make modifications to any asset we want. They can also create new components from artwork, create custom components, or add image assets and all of those will be available to the developer inside of that main Flex project.

iterate_design_07

This is all still kind of a work in progress, but I think this will work for some of the design-develop problems people need to solve. While the 1.0 version of Flash Catalyst will have some limitations around the Flash Builder workflow, there are still a lot of basics there that can be built on. If you’ve tried this or have other ideas on how this could work, definitely drop me an email. I’d love to hear feedback.

Flash Catalyst best practices article published

An article I wrote on Flash Catalyst best practices for the Adobe Developer Connection site went live yesterday.

Flash Catalyst and Flash BuilderOne of the things I’ve found with Flash Catalyst is that the quality and usefulness of the assets and component skins that you’ll make available for the developers you are working with can vary depending upon how you’ve organized your project, as can the amount of rework and restructuring required on their part when they receive your FXP file. By thinking about naming, structure and being organized throughout the design phase of the project, you’ll help to ensure a smooth flow of assets from design into development.

If you’re considering using Flash Catalyst for creating the user interface for a rich Internet application then I hope the hints and tips shared in the article will help you to make the most from Flash Catalyst and ensure that you’re structuring your projects with the eventual output to the developer in mind.

The article is posted here.

If you have any feedback on the article or additional hints & tips then please do share them using the comments.