Adobe and HTML5 – it is in their DNA

May 19, 2010

Interesting to watch the the Google IO keynote tweets this morning.

Adobe announced an HTML5 extension for Dreamweaver CS5. It includes support for the newest WebKit engine, CSS3 properties, HTML5 starter layout, code hinting, and more. The first technology preview version is available today on Adobe Labs:

Also interesting is the support for HTML5 in the coming release of AIR 2 for the desktop. Adobe AIR leverages Webkit – the open source HTML rendering engine – supports preliminary HTML5 functionality such as the canvas element, HTML5 section tags and offline detection and caching. We will continue to add functionality as the HTML5 specification matures.

HTML5 will take years to get agreement on let along implement. During that time HTML will continue to exist and Flash Player will continue to be a valid platform. Even if standardization takes another five to ten years it’s great to see Adobe involved and committed to support it in their tools from the get-go. No doubt the cross-platform (which Adobe is extending to mobile, tablet and other devices) will play a part in the overall scheme of things.

Not supporting HTML5 for a company like Adobe would be nothing short of committing slow and painful suicide. Adobe has always been progress and pushing the envelop (Flash is everywhere and they are the leaders in the RIA domain) so why would they not support HTML5? Such a ‘head-in-the-sand’ strategy would no doubt raise eyebrows, even on the Board of Directors. Anyone who thought that Adobe would not support HTML5 has probably spent the last few months bobbing for Apples – it is probably time to come up for AIR 🙂

Frankly Steve …

May 11, 2010

So, like everyone else listening to the Apple-Adobe exchanges over Flash on iPhone/iPad (or lack there of), I have an opinion too, which largely I have kept to myself. Not that one voice in the cast of tens-of-thousands makes a difference it sometimes feels good to express ones self anyway. At this point Steve is doing is admirable job, demonstrating once again a strategic doctrine based on deception, misdirection, and the judicious use of force against enemy weak points (Sun Tzu would be proud) can make for an entertaining diversion.

So how goes the war or is it a battle? It started off interesting enough with iPhone being first to the field with a well organized supply chain of applications aggressively guarded by AppStore process and procedure. Apple penetrated the market rapidly and as device manufacturers scramble to bring products to market Apple follows-up with another blow – the iPad. If you were to believe the spin, one would think at times no one would ever catch-up. Adding insult to injury Steve snubs his noise publicly at Flash and Adobe. All of this stirs up loads of press, blogs, postings,… all containing truths, half-truths and outright bovine road buns. Oh, did I mention – deception and misdirection – well done Steve, especially that part about Flash being buggy, doomed by HTML5, yadda, yadda,…

In Silicon Valley though, when you have them by the developers their hearts and minds will follow. In the battle over developers, who is winning anyway? Based on Appcelerator’s survey prior to Apple’s announcement in January 90% of developers said they were very interested in building an iPad app within the year. By March this had dropped to 80% and with increased competition among mobile platforms showing that Android (81% very interested in the platform) is closing in on iPhone (87%), while Blackberry (43%) and Windows Phone (34%) have doubled and nearly tripled their developer interest numbers, respectively, in just two months. According to the 2010 Ovum survey poll of 217 developers found that the iPhone OS garnered the most support, with 81 percent of developers, 74 percent of developers plan to develop for the BlackBerry, 66 percent said the same for Windows Phone. Also interesting at the time was the Admob Publisher Survey (Mar 2010) in which 31% of developers surveyed (albeit 108) were developing for more than one mobile platform and almost half (47%) said they plan on developing on more than one platform in the next 6 months. Sadly Steve, more than 70% of iPhone developers plan to develop for Android over the next six months whereas only half of Android developers (48%) plan to develop for iPhone. Developers are in a word ‘hedging’ on their way to ‘trending’.

So why all the hedging and where could the trend go? You could visit Google’s campus and hear the buzz, observe the flood of hirings, and a whole building being sectioned off. Or why not watch the numbers as A Wave of Android Smartphones Outsells Apple where “Android-powered phones accounted for 28 percent of all smartphones sold in the U.S., exceeding Apple’s 21 percent share during the quarter, NPD said. Research in Motion’s (RIMM) BlackBerry models led the category with a 36 percent share.” See also: Report: Google Android surpasses iPhone in U.S:

Add to this the inevitable explosion of imitators, that by next Xmas, will have spawned numerous tablets as are starting to emerge: Android-based tablets.

If you were Apple would you worry about a cross-platform development environment that could not only deploy to iPhone and iPad but also push the same code to all of your competitions platforms? And if you were a developer why learn 4 or 3 or even 2 SDKs when you can learn 1 and compile for any device?

‘Ou et la guerre’ anyway? It is not a real quote but in that way appropriate. What I really am amazed at is that anyone gives a damn about what Steve has to say about the tides of consumer interest and spending. Apple and Steve are playing the market positioning game, pure and simple. This is not about the purity of their platform but take and hold market share. And how has that worked in the past? Apple has historically relegated themselves to 10-15% but they seem to think that doing the same things will deliver different results? If they are not worried about the coming storm of cheaper and equally capable devices coming from the likes of Nokia, Motorola, HTC, RIM and HP supported by Google, Microsoft and others then they should be worried about the choices available to developers that allow them to not only create but distribute their applications across all of those platforms without going Back-to-the-ObjectiveC.

So frankly Steve…

Evolution of RIA Design Principles

March 8, 2010

So you can not only have a flaming logo, now you can make it fly around you application. Just because you have the power in an RIA application to do this does mean you should. So, given that much more is visually possible in a Flex application there is a greater challenge for developers to know how but when is it appropriate. If you have a Flash background this may be old hat but for those with an HTML, Java, .Net,… pedigree this is not so obvious.

This weeks 360Flex panel discussion “What are the Principles of RIA Design” will bring 5 experienced user interaction and design practitioners together to discuss this point. This panel discussion will investigate the question of ‘what are good/bad principles and practices in RIA UI design for business, enterprise or other apps?’. All the books you peruse at the local (Borders) library on interface design largely work within the constraints of a non-RIA design/development environment for websites or applications. Now that designers and developers have significant animation capabilities in Flex for applications, when is it appropriate to have glowing, moving, and morphing UI components like buttons, forms and video? Currently the screen ‘pages’ will essentially ‘snap’ from one layout/page to another. This is an un-natural and abrupt change that you can get used to, but is mentally disruptive, especially if you have to re-assimilate the page to find information or next steps. Apple has raised the bar for the industry in the design of its products and particularly the iPhone which employs a natural flow and movement in the UI – transitions are animated and employ more natural-physics based movements, fades and scale (things growing and shrinking). Come out and participate in this discussion on what may be the ‘new’ design rules, principles and guidelines for RIA user experience development.

Panelists (alphbetically):

Paul Giurata, Lead Solution Architect at Catalyst Resourceslinkedin | blog
Chet Haase, Senior Computer Scientist at Adobe Systems – linkedin | blog
Bill Scott, Director UI Engineering at Netflixlinkedin | blog
Ehud Waizer, Senior User Interaction Designer at SAP Labs linkedin
Radley Marx, Professional Design and Flash Developer of vj.tvlinkedin | blog

The Evolution of a Flex Developer

November 15, 2009

Over the past few years of learning Flex and being a participant and manager of a Flex user group I have become aware of a the learning process of new Flex users. I hope this post will be helpful to those considering or are in the process of learning Flex. Radley Marx and I manage is a large and active group in the Greater San Francisco area (SF, SJ and the East Bay). Radley and I complement each other (regularly, I might add) Silvafuglogo3in that he has a Flash/Designer background and I have an enterprise/ business Flex background. We have had more than a few conversations over the content of SilvaFUG events and how we need to consider the demographics of our members.

To start with there are two distinct groups or sources of Flex developers, which is important to understand as each of these have slightly different paths:

  1. Designers and Flash Animators. This ‘Designer’ constituent is largely made up of Creative Arts graduates who use Creative Suite applications for website graphical design and animation. Given the Creative Arts (CA) versus Computer Science (CS) training there are relatively few coders in the crowd although the numbers are increasing due to the need to code to get the best out of Flash Pro and other packages.
  2. Software Engineers and Developers. The ‘Developer’ contingent originates from the somewhat gargantuan, software development community. Lately the has been a large influx of developers into the Flex community due to economic and professional factors. Although some of these developers are ‘new grads’ the large majority are experienced engineers and developers with 3+ years professional working experience in Java, Microsoft, PHP, database and  other technologies.

There is an emerging sub-group, to use Kristopher Joseph’s term ‘developsigners’ who can carry design artifacts into code. That being said these two groups are very different and have little knowledge of each other’s ‘dark arts’. Until Catalyst and FXG hits the streets that is.

Sticking with what I understand best, the evolution of a Developer new to Flex occurs over 3-6 months depending on how much time, training and mentoring is available. There appear to be five stages, the time associated with each stage can be 1 week or 1 month depending on your circumstance):

  1. Flex Framework Stage. This involves learning to build applications based on the Flex Framework using MXML and the Actionscript. The first projects involve using the design view to layout controls (buttons, combobox,….), navigation containers (TabNavigator, Viewstack, …), and states (save me Catalyst and Flex 4!). This is followed by adding handlers and logic using Actionscript. Anyone with experience in object oriented languages will quickly explore building and using new classes.
  2. Flex and Data Services. You quickly learn that Flex is about building client-side RIAs and that clients need to be fed with data to really come alive. As you continue to explore the framework you will now learn about connecting to data sources and services (check out Yahoo and Flickr). Creating and using HTTPService, RemoteObject, and WebServices to bring data into your application is second only to understanding how that data is managed and consumed by the different components. During this stage the nuances of XML, XMLList, and Collections as data providers come clearer (however frustrating that can be at times). Many developers with ‘backend’ experience will get deeply into available and suitable back-ends for Flex, particularly remoting based on ‘Action Message Format’ or AMF that is available in such Flex-oriented implementations of WebOrb, Granite, BlazeDS, ZEND_AMF, etc.
  3. Flex and Frameworks. Now that you have applications that have a few screens and pages, a number of viewstacks, popup dialogs, and states you start to wonder ‘how do I coordinate all this?’. Additionally, your components have a mix of visual components, data and logic making it difficult to follow and even more difficult to re-use and maintain.  At this point you start to look at Frameworks to help bring order to the chaos. There are a growing number of available frameworks with very cool and unusual names such as Cairngorm, swiz, robotlegs, mate (the French not Australian pronunciation)… Frameworks are/is a favorite subject at user group sessions every three or so months (note how that syncs with the evolution). Checkout this presentation on frameworks which I am starting to maintain.
  4. Styles and Skinning. Depending on your creative nature this may have been something that interested at an earlier stage. Essentially you realize (or someone tells you) that your application looks a little grey and boring (it might not be on such nice terms either). At this point you start digging into styles, CSS and skinning. I highly recommend start attending Designer oriented user groups to get familiar with the CS Suite of applications that produce the graphic design artifacts you need to deal with as a developer. You will also learn that designers are nice people however under-privileged they may be in terms of having the benefits of a few years of coding.
  5. Custom Components. This is not a subject that everyone will agree is important, until you attend or watch a session from Ely Greenfield or Deepa Subramaniam. At that point you realize you should rebuild everything that you did in the last 4 months 🙂

Now I am going to go out on a limb and talk about Designers getting into Flex. Designers have an advantage of knowing the CS suite and artifacts that can be created for applications. Here is are the variations to the Developer evolution:

  1. Flex Framework Stage. What is this MXML stuff? and please release Catalyst – NOW! Seriously, with a little background in Actionscript it just takes a little time getting used to the Flex Designer and how MXML is used to declare visual components.
  2. Styles and Skinning. This is where Designers will start to feel at home in Flex. The difficult part is learning patience with Flex as it is challenging (a nice word, you will have others) to get the look and feel that was so easy to do in CS and Flash.
  3. Custom Renders. This again is arguable and arguably essential. These are similar to custom components and get easier in Flex 4 – see Deepa and Ely’s blogs above.
  4. Flex and Data Services. Remember Flash Remoting, this is largely the same thing only make friends quickly with a Developer with backend experience. You will make a great team because they are scratching their heads over symbol libraries from Flash.
  5. Flex and Frameworks. After watching Radley suffer through the first hour of Frameworks at MAX I can tell you this is only for the bravest of Designers. As per Stage 4 – find a Developer friend.

I hope this post has informed and entertained you. Remember you are not alone and if there is not a Flex user group near you then you should start one. Strength in numbers.

SilvaFUG Session from Chet Haase ‘Animation Rules and How they apply to RIAs’

November 11, 2009

I was at SilvaFUG Tuesday, Nov 10th session and thought Chet’s presentation was excellent because it was not only full of great technical information (code and demos) but also some very informative material on the rules/principles for cartooning/animation and how they apply to GUI applications UI design. This is something that I have not seen before and very valuable for those exploring/using RIA and what differentiates a RIA from a regular web application.

Chet’s preso raised a question in my mind, ‘where is there guidance or commentary on the design rules, principles and guidelines for RIA development?’ All the books I have perused at the local (Borders) library on interface design largely work within the constraints of non-RIA website or application design. Typically this principles stress:

  • Consistency and standards
  • task/use-case orientation and logical/work flow
  • use the right widget for the right task
  • users need to know how to work with the application you built
  • keep it simple and focused
  • etc

As an example, the typical well designed interface will move logically and progressive from one task or use case to another. However, currently the screen ‘pages’ will essentially ‘snap’ from one layout to another. This is an un-natural and abrupt change that you can get used to, but is mentally disruptive. In bad UIs you will spend time looking at the new page to understand where the next thing is you are interested in or need to do. The things (buttons, controls, information,…) that you should be able to follow from one screen to the next can get lost in the clutter and page ‘snap’. Apple in the design of its products and particularly the iPhone has employed a natural flow and movement to the UI – transitions are animated and employ more natural-physics based movements, fades and scales (things growing and shrinking).

As Chet pointed out, Flash and now Flex provide developers with built-in and easy-to-use animation features that require gobs of coding to achieve in Java (improving in JavaFX) or other languages. These are facilities that are largely new to developers and completely new to enterprise developers. These new capabilities are appearing in internet sites because differentiation can give a new service a competitive edge. This is not the case in (meaning internal to) the enterprise it is hard to come up with an ROI in ‘making things look cooler’. This is not entirely true because some of these capabilities improve usability, speed, accuracy, efficiency and ultimately productivity and cost effectiveness, which can be measured.

As food for thought (and not wanting to scoop Chet’s blog on the subject too much), here are some of his ‘rules’ derived from accepted cartooning rules:

  • Timing – effects happen within an appropriate time and do not become drawn-out, tiresome and ultimately irritating;
  • Designed – color choices, look & feel, consistency;
  • Smooth – natural and liquid
  • Transitioning – flow from one state/page to another should not only be logical intellectually but also visually keeping the users attention on the things that are common from one state to the next;
  • Realistic – learn to use the natural physics-engines available in Flash/Flex and including graphical hints that are analogous to real-life
  • Anticipation – give user hints about what is going to happen (example, appropriate hover effects);
  • Simple – keep it simple and clearly communicate what is happening and important

See Chets blogs:

Other commentary:

Great UI Style Guides listing (but nothing on RIA)

360Flexpress Success

November 9, 2009

This weekend (Nov 7-8) ran a weekend of budget training ($149 for two days) for Flex enthusiasts at eBay Town Hall in San Jose. The event was co-operatively conceived and run by 360Conferences and Silicon Valley Flex User Group (SilvaFUG).

Described at, the event was intended to give Flex beginners a head-start in learning the ropes and building their new skills and knowledge. The event was attended by 35+ beginner and advanced developers from as far as Florida! Participants were very complementary about their experience which was evident in the lively, in-depth questions, discussions and experience sharing.

The first day was given by Tom Ortega and covered not only coding but the thought process from requirements through to a working ‘Thanks Giving Survey’ prototype. This approach gave participants insights in coding in MXML and ActionScript, features of Flex Builder and also the differences and nuances of creating Rich Internet Applications (RIAs).

The second day included 3 parallel tracks that were repeated in the morning and afternoon that took the prototype built on Saturday and walked through coding it in Cairngorm (Tom), Mate (Harry Garland) and PureMVC (Keith Sutton). The sessions on frameworks involved a lot of indepth coding and discussion of the advantages and disadvantages of each framework. Stay tuned for a blog regarding these different versions.

It was great to see the enthusiasm and interest generated by newcomers. I would like to express appreciation to Tom Ortega and John Wilker of 360Conferences, Harry Garland an upstanding SilvaFUG member for presentations on Mate, eBay for the use of their facilities, and of course the participants who took the time to attend. We are all looking forward to 360Flex coming to San Jose March 7-10 !

Bare Bones PureMVC App Skeleton

November 8, 2009

PureMVC like any other application model-view-controller framework takes some time and effort to learn and apply to real world situations. In general there is no shortcut to reading the documentation, reviewing the examples and building a few demo applications. After having gone through this myself and helping a few others through the process I have developed some insights and assets that have proven to be useful. The content of this post is based on a presentation that is available on SlideRocket.

For those getting started there is an application skeleton available from PureMVC site. This example is great and provides a set of components and code that gives you a leg-up when creating an application from scratch. However, it includes a little bit more that most can handle in their first practice project. For that reason I have created a stripped down version ( that provides a good ‘first application’ start-point.