On Adobe Thermo

Hi guys, it's been a while since I've last posted but I've received a nice little blog post in my feeds today regarding Adobe Thermo. Some new screenshots, and I'm pretty excited!

The basic premise is that in today's consumer application universe, the technologies behind them (most notably Flex/Air, WPF + Silverlight, Ajax) have produced applications that look wildly different from each other. Roll on the creative design team!

Traditionally applications may be designed in something like Photoshop, handed over to the developer who usually grumbles about the fact that a 3D cube interface would look really nice, but would be a bitch to code for and wholly impractical. The designer grumbles away, and tweaks his design, shoves it back to the developer, and so on and so forth.

There has to be a better workflow. So how do these new technologies make it easier for the designer to work with? They are after all, programming tools, for programmers.

Microsoft seems to have tackled the problem head-on, and produced the Expression suite of software, in particular Expression Blend. This is a vector based, user interface designer, similar in many ways to the original Windows Forms Designer of Visual Studio, but with some arty farty features slapped on. Kind of a Windows Forms Designer-cum-Adobe Illustrator-cum-Flash but with much less functionality.

I've been using Expression Blend for a while, and it doesn't really satisfy it's idealisms. The inteface is clunky, integration with Visual Studio doesn't work very well and designer-type features are sorely lacking. You can't for example, do inner shadows, but you can do drop shadows.

Also I find the separation of design and code not as clear cut as it seems, as lots of user interface features, such as custom timeframe animation, require delving somewhat deeply into XAML and C#. And also, lets face it, XAML isn't exactly the designer's idea of heaven.

We can't be too harsh on Blend though, as it's a new player on the market and we're all so used to Photoshop and Illustrator. It's a good idea, but it needs improving greatly. The fact is, a designer used to Photoshop will find Blend frustrating to use, and in the end, will fall back to the traditional methods of mocking up designs in Photoshop and handing them over to the developer.

Unfortunately, Adobe Flex doesn't do much better. It's a pure programming tool, whichever way you look at it. CSS styles and the new skinning features are all well and good, but just too time consuming for your impatient designer. If he's well versed in Flex, he'll probably create the mockup first, then try and replicate it using CSS/Flex skins. That's a double whammy job.

It seems like the upcoming Adobe Thermo (codenamed Thermo that is) is taking the idea further. You'll be able to import your existing layered Photoshop PSD files into the application, and then, magically hook up all the layers and objects to real-life application components. For example, choose this square here, make that into a scroll bar.

The idea is that the designer can do what he does best, pass on his work to the developer who creates the functionality from the design straight away. It's actually really amazing.

It's difficult to explain how excited I am about this, but please look at these demo videos from 2007:

http://aralbalkan.com/1050

Chumby

I was listening to an RIA podcast this morning (tis an extremely geeky thing to do on the Tube) and they mentioned the Chumby widget player. Streaming WIFI widgets anywhere in the house. Would be great just on the coffee table, I want one!

What direction is the user interface heading in?

It's been a while since my last post, and I promise to follow-up on my previously loose-ended entries eventually! I've recently completed a major project in Flex, and for the most part, the application has been taken to well by our client-base. I'm moving my efforts over to the WPF side of things now. Switching my head from Flex's markup and scripting to Microsoft's offering has been a bit of a nightmare, but also one hell of a learning experience. It'll be interesting to compare these two later.

Today's Topic

Anyway, the purpose of today's post is about something else. With the advent of these two new technologies (Adobe Flex/AIR and Microsoft's Silverlight and WPF), has come the first wave of experimental applications. I've been testing a few Adobe AIR demos and I've noticed one very significant thing.

Never before has any programming API allowed such flexibility and ease and above all, creative freedom when designing user interfaces. WPF's vector engine and AIR's CSS styling engine has allowed our desktop applications to act like the web, by that I mean the developer can make them look like whatever they want, and development time is quick. Very quick.

Indeed this is a major benefit, flexible designs allow richer interfaces, they are more interactive, more dynamic. Usability is increased, we can now display data in ways that have never been imagined in the past, there's much more visual feedback, and well, you have to admit, it all looks pretty sexy.

So what's the problem?

There is also a fundamental design problem that has never before occured in the past, but will completely free and open-ended interface designs hinder the end-user at all? This is an issue that in my opinion we will all have to think about soon. AIR/WPF has given not only the developer, but the corporation complete freedom over how your future applications will look. Every single new application will be branded by the selling company, in their company colours, complete with custom skins, widgets, buttons etc... I'm guessing what we'll see in the next few years, is that every application on your computer will not only look completely different, but will feel and act different as well.

The applications will all be based on the developer's and company's own interpretation of user-interface best practices. It's happening already. Upon installing the first few AIR demos, I can already notice the difference:

The Ebay desktop application. Complete with its own horrific colour scheme. Doesn't look anything like my nice Mac theme, does it?

Adobe Air lets the developer create their own window borders and titlebars. It's real nice looking, but where's the minimize button?

Rectangular windows? Thing of the past, keep up with the times! You can have it any shape you want. Cool. So what happens when you want to tile your windows on the desktop for some multitasking? And which bit do you click on to drag the window? The Kuler logo at the top? Nope, that takes you to the website. Ouch!

Ok, not all applications are like that, and of course it depends on the developer. Don't get me wrong, I'm not inherently criticising the above applications, in my opinion they are generally well designed, but it is in the same way that your average website is nicely designed. On it's own, they're great, but the user's desktop does not work like that. It all needs to be coherent and consistent, and above all, predictable. Compared to the programming API's of the past, it's much easier to make totally crazy interfaces, but it's also much easier to make mistakes. There's good reasons why things like the Apple Human Interface Guidelines exist...

All the Mac applications look, feel and act the same, and in a predictable fashion. Doesn't mean that OSX Leopard isn't drop-dead gorgeous though, does it?

Conclusion?
We should go the way of the Mac and have standards to follow, so all of our applications are nicely consistent of each other, and yet we still retain the benefits of interactivity and rich interface options given to us by AIR and WPF.

Or, eventually these technologies just won't catch on, and we'll be back with Windows Forms. I seriously hope it won't be the latter. Something to think about!

Document Output in Flex (and Office 2007 OpenXML format)

One of the many problems I have encountered in RIA development is the complete lack of ability to generate any decent document output. Our specific need was to have a familiar user-friendly template editing system available for our clients, and then our software would merge this template with the data from our RIA backend, ultimately creating professional, corporate-branded business documents.

A quick search on PDF output functionality yielded two possible results:
Adobe Central Pro Output Server and Adobe Web Output Pak

Apparently, after speaking to their sales representatives, that the above products are obselete and have been for a number of years, and the functionality that I want in our Flex applications can be found in Adobe LiveCycle. (Why those products are still appearing on the site is beyond me...)

This was not only found to be rather costly, but also heavily based on Java servers. It seems ridiculous to me that Adobe, being the standard document pioneers that they are, could not provide easier solutions for even the most simple PDF generation tasks.

Like our previous gripe with SQL server connectivity (and indeed any native database connectivity), we have had to resort to the dark side and implement the required functionality in .NET on our server. Without going into further discussion about the annoyances of relying on external intermediate technologies, in the end we decided the best route was to output to the recent Office 2007 (OpenXML) format.

The advantages for us are numerous, but most notably:

• The OpenXML SDK is free.
• Therefore we have complete freedom to develop our document solutions and host them ourselves without any technical restrictions.
• Even without the SDK, we have complete freedom to manipulate the format. For example, the Microsoft Word 2007 document filetype .docx is nothing more than a ZIP file containing a few XML files and the corresponding document attachments eg. images
• Our clients are already well versed in creating and merging templates using Microsoft Word 2003, and so the learning curve for upgrading to 2007 is minimal.

The data flow is as follows:

• Client creates corporate-branded document template, using text and image placeholders for merging.
• Template is stored on our webserver.
• When client requests a generated document from within our Flex RIA, it communicates with a ASP.NET script on our server. Using the OpenXML packages, it performs the merging with the existing template, and sends a direct response of the .docx filetype back to the browser.

Clean, easy, and elegant. And most importantly free. On my next post I will discuss some problems with the OpenXML API, there are certain quirks that Microsoft decided to implement into their framework, and it seems, for no apparent reason. Still, you have to give them a thumbs up for finally creating an open format for Microsoft Office, soon we'll be able to open up .docx files in all our major applications.

But I don't want those "benefits", Flex vs AJAX

I've been reading quite a few blog posts about why not to use Flex and that AJAX will live forever more, most notably from this guy here:

http://ajaxwidgets.com/Blogs/thomas/7_reasons_not_to_consider_usin.bb

The majority of Flex naysayers fail to understand however, that as Flex developers, we do not really care about those said "advantages" that AJAX is boasting. For example, many people say that Flex completely undermimes the Web 2.0 standards and does not fair well with the "semantic web" etc etc... They seem to miss the point that, we don't want it to.

They also say that it is very difficult (thought not impossible I must remind them) for Flex applications to be Google indexable. Again, they miss the point. The majority of us, dont want it to.

The biggest reason why Flex excites us so much is that finally we have a web-based platform for us to deploy our desktop-style applications. We don't want to follow nice standards, we don't want our content to be easily aggregrated across the web, we don't want our content to be searchable.

What we DO want however, is a nice stable environment for us to code up our business applications. For example, I'm developing an enterprise application, that will connect to a complex database back-end, and in order for the application to be successful, it needs to be web-based. Forget AJAX, it just takes too long. With Flex we can just use our existing desktop application programming knowledge and create a binary application that is web-based in little to no time at all. And the learning curve, in my opinion, if you come from an OO background in traditional desktop programming, is nil.

We just want to bypass all those installation files, all the tedious remote accessing into client's machines, all the complicated synchronisation techniques, and just have an online binary application that just works. We don't need it to fit in to the Web 2.0 methodology blah blah... we just want something elegant that works in the business environment.

It all sums down to 2 important points:

1. No AJAX for me please, I just can't be bothered with XMLHttpRequest, Cookies, Sessions, HTML, and browser incompatibilities.
2. I want a Windows Forms style application that is just glued onto your browser, because then everyone can access it easily. Flex gives me this option.

ActiveX 2.0? So what... It works.

Connecting Flex to SQL Server

Flex/AS3 does not come with the luxury of direct database connectivity, unlike WPF which has access to the ADO.NET API. The only viable solution is to therefore use WebServices to handle the communication between the database server and the Flex client application.

Our system requires connectivity to Microsoft's SQL Server 2005, so we opted for the ASP.NET SOAP WebService to act as the middle man. Returning the results of a query via XML was our preferred method, and luckily ADO.NET's DataSet object contained a very handy method to output the current resultset to XML:

http://msdn2.microsoft.com/en-us/library/system.data.dataset.getxml.aspx

DataSet rs= new DataSet();
... fill rs with query result here
String rsXML = rs.GetXML();

The resulting String can be loaded into your conventional XMLDocument object and then passed back to the WebService caller.

So getting the data from the database in XML format to the Flex client is pretty straightforward. The problem is now binding this XML data to the right objects and their properties.

In our system we wrote our business logic (our semantic objects) on client-side AS3. So we needed an elegant way of performing the CRUD (Create, Retrieve, Update & Delete) operations on our database WebService whenever our business object changes. Basically the classic problem of mapping database tables and fields to business objects.

You may already be familiar with Flex metadata, especially the [Bindable] keyword which indicates that a specific property can be data-bound during runtime.

Not many Flex developers know that in addition to ActionScript's predefined metadata (such as Bindable, ArrayElementType etc...), programmers can also define their own metadata. This is especially useful in our problem in finding a generic technique for mapping arbitary classes and properties to tables and fields respectively.

For example, in our system, a business object class may be defined like so:

[DatabaseTable(tableName="houses")]
public class House extends PersistentObject{
     private var _houseRef:int;
     private var _houseName:String;

     [Bindable]
     [DatabaseField(fieldName="ref",primary=true)]
     public set houseRef(value:int):void{
          _houseRef = value;
     }
     public get houseRef():int{
          return _houseRef;
     }

     [Bindable]
     [DatabaseField(fieldName="housename")]
     public set houseName(value:String):void{
          _houseName = value;
     }
     public get houseName():String{
          return _houseName;
     }
}

As you can see, the above class definition is your basic business object with getters and setters, nothing special here. The PersistentObject class is just our base class that all our business objects will inherit from, for reasons that will be explained later. It semantically represents a house, with a house name. In addition to this however, there are 2 custom metadata attributes applied here, DatabaseTable and DatabaseField. The first, DatabaseTable, is applied to the entire class, and indicates that any instantiation of the house class can be mapped to the database table house. Similarly, both houseRef and houseName properties are mapped to the fieldnames ref and housename found in the house table.

Behind the scenes, during the compilation process the compiler attaches the metadata to the class and property definitions. Note that by default the compiler will strip out any unconventional metadata from your classes and properties, and so the following compiler argument is required to prevent this:

-keep-as3-metadata+=DatabaseTable,DatabaseField

Notice that we use += and not = in order to keep existing metadata such as [Bindable].

When we need to extract the metadata during runtime, we use ActionScript's class introspection (aka. reflection). The describeType function is most useful, returning XML data describing the class and its public properties and methods, including all attached metadata.

From here, it is easy to see how all your CRUD operations can be generically applied to all of the business objects that contain the above metadata, creating SQL queries on the fly for the database on your backend.

In our system, we have a PersistenceManager class that takes any object of type PersistentObject (such as the House class above), then uses introspection to derive the database table name and field names, and then finally create the SQL queries based on this reflected data. Note that the describeType process is expensive, so it is recommended that you store a cache containing already reflected data.

Please comment on this technique. It is how I have developed all my Flex applications that require database connectivity. I am aware of Flex Data Services which is a server-side solution that may possibly solve my data management problems, but I have not had any experience with this due to the fact that I wanted to do everything in-house as much as possible without resorting to additional frameworks. But I may have missed something. Thanks!