Why AIR is so kewl

Developers like me, who wanted their applications to look cool, must've surely passed through a phase when we used a Flash UI for a VB application and thought – "Wish Flash could do much more than just being a snazzy UI". It wasn't simple to make the UI look good. Every time you needed an extra bit of functionality, you needed to edit and re-export the SWF. It was also a bit of a mess when it came to the workflow. The VB developer and the UI developer had to keep making changes and pass on the list each time a change request came in. We used to call such apps – "FSCommand Splash". As the Flash versions released, we needed that bit more to help us make better applications. Component Binding was a blessing and so were the Data connectivity components. They certainly made tasks easier. Still, there was something we all wanted and tried to accomplish somehow – FILE IO. Of course, there were third-party applications such as MDM Zinc that gave us quite a bit of power, but, that was a separate investment and a different story altogether.

When AIR was launched, I guess it was a big turning point in most of our lives. We could do much more than just building applications with skins. We had something more powerful than that! Cross-platform and Browser-free meant we could build those "Rich Internet Applications" we always wanted to, whether you using a Flash, Flex or Dreamweaver user. AIR helped us use what we already knew and extend capabilities of our applications by harnessing the power of the internet and combining it with the power of the desktop. With built-in File API, well, it really pushed a lot of hurdles away. You also got a built-in database in SQLLite. We didn't need good ol' VB to do the job anymore. This was good in the business sense too. Not only could they give the client an application that looked great, but, they could also leverage their existing resources to build these applications, thereby, cutting costs. They could also cut costs by employing only necessary resources, eliminating the necessity to have other platform developers. Meaning to say, you team now only had a UI Designer > Flash/Flex/Web Developer > Tester with other platform developers as an optional. Previously this was – UI Designer > Flash Developer > Other platform Developer > Tester.

I think with the launch of AIR 2.0, Adobe would create a much bigger landmark. Reading about the new features made me and a lot of other people go "Wow". With new features such as – File monitoring, Volume monitoring, Asset caching, Native application support, online synching etc, AIR would certainly be a technology that needs no convincing.

For a more detailed list of AIR 2.0 features:

http://www.mikechambers.com/blog/files/presentations/fotb2009/advanced_desktop_development.pdf

It sometimes takes a lot to convince the client when he questions the choice of the development platform. It takes more convincing when you mention the fact that an extra layer needs to be installed on the user's machine to run the application. They don't really care about the development friendliness or the fact that we are using one or two technologies instead of using 4 or 5. A lot of times, we used to say that we are using Flex and keep the AIR deployment a secret. With the Installer doing the silent AIR runtime installation, nobody has to know. J

“Best practices” or just do your thing?

The daily life of an IT professional is filled with "Best practices" and "conventions". Most IT organizations, these days, make sure that people follow what has been laid down strictly and have effective mechanisms to penalize bad and unorganized work. It is only when things are standardized that other people working on the project will understand what needs to be done. Some developers believe that "Free thinking" is lost when you follow things that strictly and coding becomes a "best practice" guide. Well, I used to believe that too in the beginning of my programming life, but, as the days went by, I strongly stood for these norms and conventions and even went far enough to lay down a system in my previous workplace.

We have "Best practices" for everything almost – design, development, UI building etc. I believe that "best practice" is a process by itself. It starts from design/layout and moves through development, testing and release. On many occasions, I have seen apps fail due to designs that don't follow these practices. To start with, Photoshop layers are not named or Flash libraries are cluttered with items that haven't been properly named. By the time the application releases, it would have changed from one thing to a totally different thing, far from what was initially visualized. I remember that we once had a hard time trying to change the UI (for adding a feature) of an application just before we hit beta. The structure of the design was such that it took us more time to actually figure out some of the layers and how things actually flowed. It is a simple best practice! But, most people blame "time" for doing a sloppy job, even if the final output is classy!

Here are some best practices that designers must follow:

1. Give proper names to Layers. If a layer contains a button, call it "Button" and not "Joe".
   
2. Make sure that the final version (that goes to development) has all unused elements deleted and items optimized.
   
3. Make sure that the design works in specified resolutions. Sometimes designers use a higher screen resolution while designing, whereas, the target screen resolution could be 1024x768. Here, the elements of the UI would look really large!
   
4. Use folders to organize page content or specific related content. This applies to Library/layers etc. For example, all elements used in the Homepage of a site could be in a folder called "Homepage".
   
5. Use Web palette colours where ever possible to make sure that colours are easily coded.
   
6. Name files properly and organize it into folders.
   
7. Use colours to darken/lighten text instead of using Layer alpha property (esp. in Photoshop).
   
8. "Usability" and "flexibility" of the interface need to be kept in mind while designing layouts.
   
9. Use system Fonts for dynamic text fields esp. For HTML pages.
   
10. 
    

..and the list goes on.

Best practices for developers:

1. Every programming language has coding conventions that should be followed.
   
2. Name your variables, functions, classes etc with sense and in context.
   
3. Use functions and make code more reusable.
   
4. Keep code in one place as far as possible.
   
5. Comment code properly with proper descriptions.
   
6. Avoid using "reserved" words.
   
7. Make sure you test the performance of your code and optimize it before you release stages.
   
8. Avoid those last minute "IF" fixes. These are mostly done before beta.
   
9. Create a proper structure – for your code, for the application as a whole.
   
10. Make sure your code can be easily extended, so that, if some additional features are requested, you can add functionality easily.
    

..this list goes on too!

Best practices for Managers/Leads:

1. Make sure your team exactly understands what they have to do. Hold meetings/discussions that would help this purpose.
   
2. Establish a proper workflow to enable not only easy management, but, a smooth functioning as well.
   
3. Make sure the people get enough time for everything. The client says something has to be done in x amount of time, make sure that your team can handle it. If you are able to convince the client for an extension, it is most ideal.
   
4. Establish a proper process to help monitor progress and workflow.
   
5. Layout a proper project plan, which needs to be communicated to the team.
   
6. Make sure all team members follow "best practices" and standards laid out.
   
7. Have a system in place which enables code/design checks to help make sure things are going as per plan.
   
8. Have a Management dashboard to tell you exactly how things are and communicate the good/bad with the team.
   
9. Make sure that team members have a proper work-life balance.
   
10. Showing your stress is a strict NO-NO.
    
11. Never expose you team members to clients or involve them in remarks during discussions with clients. This will be your downfall.
    

..this list could go on too!

There is not real definitive guide to all these things. Most come by practice and with experience.