Category: flex

Shortcomings of Flash to overcome (HTML comparison)

By , May 27, 2009

1. UI Navigation. This should have been Flash strength but somehow seems to be one of the common traps for new application developers.

Horrible UIs deserve a volume in my upcoming encyclopedia and modal dialogs will definitely be one of the first chapters. Coincidentally, this seems like one of the most abused UI concepts in Flash applications that I observed. Open up a detail page and do not let a user navigate away from it without pressing Cancel or Save… Why would anyone want to see two detail pages side by side? Work on few things at once? Why would anyone want to open tabs? Just because the dialog is semi-transparent it does not mean it ventured far from its green screen ancestor.

The special award goes to pop-under modal dialogs (AKA “click me if you can figure out that I am there”). Second place is taken by Windows 3.11 style cascading errors that seem to be popular with a bunch of sample Flex applications.

Simple browser option to right click and open new window or tab goes a long way in making applications easier to use.

2. Text search and selection. HTML and good browsers spoiled most users, people do not often even read the page – they just start typing the search word to jump directly to the sentence containing their search term. In addition, text on the screen is normally selectable and can be easily copied into other documents. This trivial common behavior is not so common in Flash – takes special effort to create UIs behaving in data-friendly ways.

To catch up to HTML a good UI framework needs to build good search capability that includes labels, text, form fields. Also have to provide a way to select just about any text in the application.

3. HTTP GET (and bookmarks). Sending, saving and posting links is one of the most common ways of sharing information on the web and the support for this in Flash per initial review is limited to very few 3rd party libraries that I do not see in action. That means that absolute majority of the applications out there offer no way to share anything except the main entry into the application. A good Flex UI framework should provide a way to export the current UI location as URL path.

The Ostrich Security Model by Adobe (being adopted by MS Silverlight too)

By , May 15, 2009

Adobe introduced crossdomain.xml file to control whether Flash application can read data from servers. In a nutshell, the crossdomain.xml file must be present on the website and explicitly grant access to clients originating from other domains for anyone to read data/make calls to this server. Excerpt from Adobe Flash player security white paper (http://www.adobe.com/devnet/flashplayer/articles/flash_player_8_security.pdf):

… if the site serves private documents or anything that requires some form of authentication (such as a password), or if the server is behind a firewall where only certain users can access it, it is risky to put a public policy file on that server. Doing so would enable Flash applications to download documents from the server whenever they run on the computers of users that the server trusts. These applications could potentially reveal private data from the server to people whom the user or website administrator does not trust.

This is just about as dumb as it gets with server security. It essentially shuts down your polite flash clients from accessing data but it won’t prevent anyone reading the same data via their own proxy server (trivial to write/configure), JavaScript, etc.

So we established that the servers are not protected by this. Would this limitation protect clients? Not likely – any “man in the middle” attacker would not be lazy to put crossdomain.xml file to fool clients into reading data. The only remaining questions is who can protect the society from the idiots who designed this “security” mechanism and made life more difficult for developers of internet mashups?

Panorama Theme by Themocracy