After a project our company makes it a practice to sit down together, go over our successes and short-comings, and develop a plan of action to avoid reoccurring issues in future projects, as well as spread the word to the rest of the agency about what works best. This meeting is called a postmortem. Not all projects are the same, and not all postmortems should be handled the same. In this 2-part article, I explain when and why a postmortem is important, explore best practices in our agency, and how you develop action to learn from your experience.

When should a postmortem be done?
A postmortem needs to happen after and as close to the final sign-off as possible. People will move on to other projects, and it’s good to get them in the meeting while the project is still fresh in their minds. Sometimes projects span over several months and issues in the beginning are easily forgotten. It is good practice to take notes throughout a project when problems (or successes) arise. This will be valuable when it comes time to meet in the postmortem.

A postmortem should always happen, whether the project was a complete success, a small project or small team. A postmortem doesn’t just have to happen at the end. You can have a mid-project check-in where the team can share any concerns or issues, and thus enable you to improve on the process before the project is complete.

Why should it be done?
Even successful projects have areas we can learn from. Not all points brought up need to be negative items. If a new way of accomplishing a task was really successful, it should be noted as well for helping those in the agency who are unaware or follow alternative methods.

Often times, we learn most from the pain points throughout a project. If every project keeps detailed notes on these issues from the postmortem and the management team is able to review these notes and compare to other projects, we can identify reoccurring problems within the agency and find ways to address them.

Who should be invited?
Every team member involved in the project should attend the postmortem. This is very important. Sometimes scheduling a postmortem can be tough because people move on to other projects. If you have to, make it during lunch and see if you can get lunch delivered. Come up with something to encourage participation. For example, ask everyone to bring a list of two items they thought were done well and two items they felt could be improved on.

OK, so great — we know when to have this discussion, why we’re having it, and who is invited. What is the best strategy for reviewing a project when you have so many people involved and multiple phases of the work?

In Part II, we will go over important items to cover in a postmortem, some questions to ask yourself and team members regarding a completed project, and find out what we can take away from the meeting to be successful in the future.

 

Steve Jobs recently gave a statement about Adobe Flash that has since made HTML5 one of the biggest buzzwords of our time. Bloggers, techies, and industries are all weighing in the future of Flash, the current state of HTML5, and where we are headed. I don’t have all the answers, but I do have some areas of clarification.

So what is HTML5? Everyone has a different idea. If you look in Wikipedia, it has a fairly basic definition. The one part causing all the debate between HTML5 and Flash is in the last sentence of the definition: “The new standard incorporates features like video playback and drag-and-drop that have been previously dependent on third-party browser plug-ins such as Adobe Flash…” The question is, does HTML5 replace Flash, or will both serve their own place in the future of the web? Let’s start answering this question by clearing up some fallacies of HTML5.

Fallacies of HTML5 

1. CSS3 means HTML5. False. CSS3 is part of the HTML5 family, but it is its own separate standard used for visualization of HTML5. Keep this in mind: HTML only outlines the content structure, while Javascript provides the behavior and CSS provides the presentation.


2. When someone says “I need an HTML5 website!”, they know what they’re talking about. Possibly false. You need to probe further. Ask what, exactly, they are looking for. Usually they want something that doesn’t use a plug-in, has animation and doesn’t refresh the page to get new content. HTML5 is not necessarily used to accomplish this. We may use some parts of the HTML5 core library, such as the <canvas> tag, but most of the visual experience they are looking for is done with extensive use of CSS and Javascript.


3. HTML5 is a replacement for Flash. False. This is currently not the case. For almost all of the Flash work we currently do, you cannot accomplish the same level of interaction and visual experience with pure Javascript, CSS, and HTML. We’re just not there yet, and definitely not there on every browser. However, if the user specifically wants something to work on an iTouch device, we can provide alternatives to the Flash experience via HTML, CSS and Javascript. Depending on the complexity of the Flash piece, the experience might not be the same as in Flash. It all depends on who the client is catering to, which devices the majority of their audience is using to view the piece, etc. From there we can decide on the best implementation.


4. HTML5 is the new standard for viewing web content. Currently false. We’re getting there, but we’re still years behind the adoption of HTML5 as a standard across all browsers. Fortunately, some areas of the HTML5 family are gaining headway faster than others. In fact, a large part of the HTML5 core is currently supported across all the latest browsers, but most of these have nothing to do with replacing functionality that has advantages in Flash.
   

So what can I do in HTML5 today? Not all browsers support all features. Not all features perform as well as we want them to. In Part II, we'll cover the current HTML5 elements, browser support, and performance for these new features. 

 

Our Rich Media team recently attended an Adobe User Groups (AUG) tech tour for Adobe Flex 4 and ColdFusion. Needless to say, we were a bit cautious (given the word "ColdFusion" in the title). In a nutshell, ColdFusion is a commercial rapid application development tool for interfacing with databases through its own markup language, all bundled into one hefty-priced package from Adobe. Most of our Flash/Flex developers have experience interfacing with open-source tools and languages for pulling data, so naturally we were reluctant about this part of the presentation. Still, we wanted to hear about the new Flex 4 features. It was disappointing to say the least.  

First off, the presenter spoke for some time about a new tool called Flash Catalyst. It’s a tool for non-developers to use when designing interfaces. Hmmm...non-developers. Must mean designers. Do you really think ANY designer will give up Photoshop and Illustrator when it comes to designing web applications? Of course not. So basically, Adobe spent all this time making a tool no one will use and still have yet to address many of the problems with the Mac Flash CS4 IDE. I ask you: Why spend money on building new useless products when you could be fixing and improving on your top-selling ones? Flash CS4 on the Mac has so many problems we only use it when necessary. Help us, Adobe-Wan Kenobi, you’re our only hope (sorry — that was bad).

After designing a simple interface in Catalyst, the speaker opened it up in Flash Builder (the new Flex Builder) and published it. When I say simple, I mean VERY simple — one text field and one dropdown. One of our developers asked the speaker how big the file is. It’s a known fact that when creating a SWF from Flex, it adds in all the Flex overhead and is much larger than a SWF published from Flash. We were hoping this might be addressed in the latest Flash Builder application.

The file was 500k. The same piece published from Flash would have been about 30k. So unfortunately no, this was not addressed — yet another reason why we shouldn’t introduce Catalyst as a bridge between designers and developers. That same application could be built in Flash by a developer and much less expense in file size.

ColdFusion came up next and we were out the door. Honestly, the speaker knew very little about Flex 4 and integration with anything besides ColdFusion. This provided a very lopsided view of this new framework and thus didn’t help us much as far as learning about the true benefits of Flex 4 and the new Flash Builder IDE.

Adobe needs to stop focusing on tools that will get limited to no use. What we really want is to hear that Adobe is making their tried-and-true tools better.

I used to work on the development team at Springbox before moving over to the Rich Media team and working in Adobe Flash. Now that I’ve been introduced to Flex, I see that many of the projects going to the development department could just as easily go to the Rich Media team, possibly even saving time and money for the client while providing a better user experience.

Here are my top 5 reasons to choose Flex for building large data-driven web applications:

1.    Faster development time. When it comes to rapid prototype development, Flex is the perfect choice. Flex has a set of components to easily and quickly build an interface for loading and manipulating data. It can be very useful to test out UI controls and overall layout, as well as verifying data retrieval.      
2.    Faster data retrieval. James Ward created a benchmark-testing tool to show the benchmarks for data loading between different frameworks. Flex AMF3 leads in faster loading times. Try it out yourself!
3.    Richer user experience. With Flex you get all the added benefits of Flash. This is important to remember. Any rich UI design elements, animations, video and audio playback, all come with Flash and therefore come with Flex.
4.    Portability. Let’s say you want to take a Flex application you serve over the web and build an AIR application that users can install on their system. This is a quick and simple process and requires little change to the code.
5.    Open source. Beat that! Flex is open source. This allows a community to get involved in making Flex better for everyone. With a community of Adobe users as large as it is, you don’t need to worry about the framework becoming a tool of the past.  

I’ve been exploring some of the APIs available for enhancing Flash/Flex applications for social networking, and am excited to start using them to solve our clients’ needs. For the Flash community, open APIs allow developers to tap into some great content and functionality.

The specific platforms I’ve been researching are Twitter, Flickr and Facebook. Here are some of the things I’ve discovered along the way:

• Twitter. While I flinch when people say the word “tweet,” everyone from news programs to large corporations seems to be jumping on board. A few days after Super Bowl XLIII, I discovered an API for Flash developers to tap into Twitter feeds (the New York Times used it in a really cool way to show what’s on people’s minds during the game). While implementation can present logistical challenges (due to time zone issues, “Springsteen,” “halftime” and “commercial” appear in the 2nd quarter, not halftime), we can still use applications like this to help our clients understand their customers better.

   

  
  Enter in a search term in the example above or click on the trends at the bottom of the window to see what people are tweeting about right now. Example built using Lee Brimlow's Flex tutorial.

• Flickr. I love my Flickr pro account. Although the data structure of the Flickr API is a little complicated, it has huge benefits. So many development companies out there reinvent the wheel when it comes to developing a back-end tool for their customers to upload, sort, organize and edit images. Thanks to the API, we can simply have them upload images from their Flickr account, then create custom Flash applications that leverage those images. Why buy a CMS when Flickr has everything you need?
• Facebook. The Facebook API is particularly useful, given the popularity of this social networking website. How many of you have played a game with friends on Facebook? Many of those games are built with Flex and Flash. Say you want an app that puts your face on an animated character (think “Elf Yourself”). Using the Facebook API for Flash, we can do it.

Social networking is the soup du jour right now. People keep connected to friends, colleagues and family on a daily basis using these types of tools. With these open Flash APIs, we can make it look and feel cooler and more engaging than ever.