Yesterday I came across a post over at Inside RIA (probably the best place to keep up on RIA ) about a handy new mockup Tool called Balsamiq Mockups.  In the past, I've used a lot of Viso and PowerPoint with various templates for doing mockups, so I'm always interested in tools that help me with quick and dirty screen design to communicate concepts.  I'm even more interested in tools that are built in cross-platform tool kits that can perform this.

This post isn't only about about screen mockup software (though a brief review with follow), it's about the power of Adobe AIR and the Flex platform.  Its been awhile since I've seen some exciting AIR work (I know it probably exists), so I thought I'd write some of my thoughts out...

Since AIR hasn't been around very long, there's not a very long list of applications that really shine and show it off (Twhirl, FCG, DestroyFlickr are really good ones, though).  Most, though, that I've looked at are semi-finished, with minimal polish.  But thats OK, it takes time to build a properly polished desktop application, and I'm sure a lot of the applications were built to play around with the new toolkit.  But none have really held merits on their own as just being must-have applications.  99% of every AIR application I've tried has been uninstalled because either they weren't very polished, only performed a subset of what they'll do (early betas), or there's nothing extra that they do that the versions running as Flex applications inside a browser can do, or that even a regular web application can perform.  And I always say, if it can run in the browser, don't make me install an application to my machine.

I think this is where Balsamiq Mockups really shines.  Its a tool that no matter what it was written in (it happens to be Adobe AIR) that I feel I could finally keep on my desktop, and not just to tinker with because I work with AIR and Flex.  It shows off a rich UI that is well thought-out and very user intuitive.  Flex is being shown off here, too.  The Flex graphics apis are one of my favorite parts of the toolset, and Balsamiq really shows off how nice of a layout engine can be designed (theres other Flex apps, too, that do mind mapping, etc. that I've seen, I just don't have the links handy).  When dragging components onto the canvas, the hinting for aligning with other objects is superb and so simple.   One of my favorite things about Flex and AIR is ability to build modern UIs as Balsamiq Mockups demonstrates. 

Nevermind that they already have an upgrade path to Linux for when the AIR runtime is released.   AIR has the potential to huge for Linux desktop application development.

Things that make Balsamiq Mockups a great little application:

1)  The layout engine and ability to aline things simply

2)  The little iconwidget that lets you explore their library for little icons

3)  Super simple to use

Here's a little mockup I made of Eclipse with Flex Builder in debug mode:

Its nothing fancy, but it did only take me about 15 minutes to put together, and that's including the time needed to explore all the available mockup compoents, different properties they support, etc....Notice how easy things more the most part align.  It was really quite easy.

Some features I'd like to see implemented:

1)  A library of other screen elements that you can browse online and import into the application.  Maybe even have an API so third-party devs could build these UI components and publish them to this browsable repository.  After all, Adobe AIR is about connected applications.

2)  Ability to adjust the font size of screen elements.  Some of the elements, like the Link Bar allow changing the font sizes), but I'd like to see this extended to some of the other elements, like the Tabs Bar.

3)  A tree mockup component.  UPDATE: Found it in the component finder called "Tree Pane"

4)  A vertical Button Bar.  In fact, just make a Button bar that's either horizontal or vertical, and make it really easy to add either icon buttons, text, or both!

5)  A mockup Grid component.   UPDATE: Found the DataGrid, had to type it in the component finder in the top (I didn't see it in the component bar)

6) an online Flex version with saving PNG files locally via proxying through the server.  (Hey, what can I say, I'm a bit adverse to installing software, when a simple software link could do the trick.)  I understand though, the perceptions of paying money for software and having a nice desktop download, and not having to wait for all the graphical assets to load, though...just thinking outloud.

That's about it as far as what I have to say about this usefully simply screen mockup tool.  Though the tool costs money, it's actually useful and pretty polished, so its probably worth the $80 or so.

About cross-platform development in general:

In the past I've looked at a lot of cross-platform toolkits, like QT, wxWindows (and wxPython bindings for wxWindows), and java toolkits such as Swing and QT's Jambi.  I think AIR has the potential to really help in cross-platform application development, because I have some issues with all the prior one's mentioned (I'll write about that later).  My only hope is that Adobe releases other security settings so that you can run AIR applications as full local applications with full access to the operating system and other applications (this is AIR's biggest downfall at the moment).  This is needed to get the hardcore desktop developers interested in building software that integrates with other services (Yeah, I know about the Merapi project, but if I'm going to have to maintain and ship the java JRE with my AIR application, I'd seriously have to consider not using AIR and instead settle for QT's Jambi...actually I'd probably still prefer the AIR and Flex toolkit and deal with shipping the java runtimes...).

Anyway, keep up the good work building these tools and these applications.  Get enough kickin' applications written in AIR, then it wont matter what operating system the user wants to use they'll be able to use your application.

Now that Adobe's released the final bits to Flex 3 with Adobe AIR support, my latest article Digitally signing Adobe AIR applications has been posted over on Adobe DevNet.

Read it if you're interested in understanding a bit about the code signing process, including certificate acquisition, and signing from all the tools Adobe supports AIR application creation from: Flash CS3, Dreamweaver CS3, Flex 3 SDK, and Flex Builder 3.

Cheers.

An article of mine, based on a previous blog entry, has been posted to the Adobe AIR Developer Center for Flex.  Read about Building Flex and Adobe AIR applications from the same code base.  The Adobe Developer Network version goes into more detail and has a pretty UML diagram to make it all sensible.  Check it out.

It's been awhile since I've posted anything here.  Which ostensibly means I've been lazy.  However, in reality, I'm busy as ever, and I have several half-finished postings that I hope to post soon on such topics as:

• Using the new goods in .NET 3.5 and Visual Studio 2008 to write a back end for Flex -- especially interesting is the new Astoria functionality that will add RESTful web services to your .NET backend.
• An ImageProgressBar component that uses an image and selectively applies visual formatting as progress occurs.  In this case, it converts from B&W to color as progress proceeds, or from color to B&W. 
• A component for building thumbnails from a directory of images in Adobe AIR.  This isn't as simple as it should be due to processing long operations in the Flash timeline.  Don't worry, I have an event chaining solution that keeps your application responsive while generating thumbnails.
• Summary of all the different ways and technologies that Flex/AIR can access a back end.  (This is mostly for my own benefit, since it's hard to find a complete listing of both Flex and .NET libraries.)
• Code generation with Python, especially useful when using Cairngorm as a framework (I have some scripts that mimics Ruby on Rails generators.  Don't be shy about the command line.)

I'll get these things polished as I find time, which has been tough these days.  I'll start with one this weekend.

Now that the AirDerby deadline has passed, people are starting to show off their cool applications.  I've been to a few sites that have an "Install Now" badge (like the Adobe AIR Sample Gallery).  These badges allow the user to click on a link and both the AIR runtime and AIR application will be installed for the user.  This sounds very enticing and is a very easy method for the user to install your application.  However,  despite not even working on my system (Windows XP SP2, Firefox and the latest Flash beta), and despite Adobe's touting of this as a feature (AIR Install Badges), THIS IS A VERY BAD PRACTICE.  There's negative stigma associated with installing software from the web browser, especially software that can access local files.  A CTO sees this and their scared-off searching for other development options.

JUST SAY NO TO WEB-BASED INSTALL

The stigma of installing software from links on websites to my local system scares me.  Over the years, I've trained all my users and friends that it should scare them, too.  We can probably thank Internet Explorer and the days of ActiveX Controls for this.  Using the AIR "Install Badge" gives the user a very similar experience as ActiveX in the old days, which nobody in their right mind uses anymore because it's associated with the virus mayhem (not to mention C++ complexity).  Why do we want to bring this into the new and exciting world of Adobe AIR?

Users of fine software understand the need to  install software to their local system, and that when they do, they should really trust the source of where that software came from.  For this process, they're trained to download the .DMG(OSX), .MSI (Win), etc. to their desktop, and then double-click to invoke the installer.  This is something they are comfortable with, and more importantly it's also a process that raises the user's awareness that what they're about to install could be dangerous to their system.  Installing AIR applications from a web-page doesn't make me feel comfortable, despite being prompted with dialog boxes announcing that the code is signed code and asking me where I want to install it. (Adobe is doing a good thing by requiring AIR applications to be signed.)

The use of these badges, and the prompts a user reads, is very reminiscent of Internet Explorer and it's ActiveX control installation process.  And no one trusts that these days, so why duplicate that installation process with the Adobe AIR product?  Some proponents of the badge might argue that there's the automatic FLASH installers.  For this, I'd say that Flash is ubiquitous enough, and has enough familiarity that this falls into a different category because users are comfortable installing FLASH.  It's the Coke-a-cola of multimedia viewing on many web sites.

Let's not confuse users, nor tarnish AIR applications by even offering this service from a web page.  Instead, have your users download the AIR file, and then manually install it.  This sends a clear message:  you're installing a full desktop application that might be bad for your system, you should be aware of this.  This physical act is more important than the reading of dialog boxes.

A suggestion for a better install process

To go a step further, I'm really hoping that Adobe offers some form of packaging for AIR that is native to each operating system.  As a developer I can distribute a single DMG or .MSI file  that the user downloads.  Inside this DMG or .MSI file is the AIR runtime (the version that my application was developed with) and my custom AIR code.  I don't mind the 8 to 10 megs of overhead this brings.  This way, users can install software with the appropriate prompts that they are used to from native installs.  The Mac users can drag the application to their Applications directory; Windows users can answer all the appropriate prompts.  This is an installation process that end-users are both familiar and comfortable with.

Not to mention, this install badge doesn't even work for me!

I'm on Windows XP sp2 and Firefox, and the latest Flash Beta.  It seems most AIR developers are on OSX, so maybe my Windows security configuration is protecting me -- or maybe it's just a bug with the Install Badge?  Personally, I'm glad this is failing.  However, since I've seen this "Install Now" badge on several sites, I have to assume it works on people's computers.  Every application on the Adobe page that I tried to install with the Install Badge, fails.

Summary

The AIR Install now badge is reminiscent of being prompted to install ActiveX controls.  Internet users don't feel good about doing this.  Though it's only in perception, there could (and will) be many malicious applications written in AIR that will do things like erase users images, send files to remote web servers, etc.  This is the price you pay for writing applications that run in the user space.  Let's just not confuse the users, nor tarnish the AIR reputation by using these INSTALL NOW badges for your legitimate applications.  Let's leave that circumnavigation to the nefarious webistes.  And Adobe, please offer us some form of native install user experience for our applications.

What's your take on it?

You can learn more about creating AIR install badges by reading AIR Install Badges, How to: Creating an AIR Express Install Badge, and Using SWFObject and the AIR install badge for easy deployment.

Worked late last night to solidify the functionality of FOTOBlendr, my entry into the Adobe AIR Derby.  It's an application for quickly building photo collages with community shared templates (in progress), as well as a free form tool using custom borders and slapping images on a Collage Canvas.

Currently, it supports the ability to grab images from Flickr, or your filesystem (there's thumbnail generation going on, so it'll take some time to import your local files, but they will be cached for next time).  Then the user can either throw all the images onto a Collage Canvas and then save it, or email it to their friends, or they can enter the Collage Builder mode where their taken to a screen that allows for custom layout.

Here's the 3 minute guided tour

 

The Main Screen

This is where you get started:

1. Import images from the file system (this takes time as a thumbnail is being rendered for each image in a directory, it's cached for future use, though).  Start with only a directory of 20 or so images, to see how it performs on your computer.
2. Adjust the size of the thumbnail (just like Adobe Lightroom).
3. Select the photos you want to build into a collage.  To select photos, press and hold the ctrl-key and select images.  Those selected will have a white border.  (Shift-selecting ranges of images works, too.)
4. After image selection, press either "I'm Lazy" for a jumbled mess of photos, or "Build Collage" to build your own custom collage.

The Custom Collage Building Screen with Templates

1. You come to this screen after pressing the "Build Collage" button on the main screen.  Here you can apply pre-build templates, or free-form layout your images.
2. Try selecting a template and watch your images fly onto the Collage Canvas.  Then try another template.  If you don't have enough images selected, you'll be warned when you try applying a template designed for more images
3. There's lots of good stuff coming with templates: Background images, B&W backgrounds, etc...it's going to be sexy.

 

The Custom Collage Screen with Custom Layout and Border Selection

1. If you don't like the templates, create your own.
2. Press "Clear Collage" button to get a blank canvas.
3. Drag your mouse around, the image will be dropped on the canvas when you click.
4. Change the borders, by pressing either the "Choose Border" button which will bring up a menu of borders, or select "Shadow Border", or "Sloppy Border".
5. Resize your images by pressing the "["  or "]" keys.
6. Rotate your images with "," and "."
7. Cycle through available border with "K" and "L"
8. Press "H" for help.  (See below for a screen shot of all the keyboard shortcuts.)

 

The Border Selector

1. By pressing the "Choose Border" button, or the keyboard shortcut "B", you'll be presented with a preview of borders.  Select the border you like. 
2. In the future, there will be the ability for community members to create border-packs to share.  And the application will be able to filter from the web.

 

The Help Screen

1. Pressing "H" or the "Help" button will bring up the keyboard shortcuts available.

Email or Save the Collage 

After you are done with your collage save it to your local disk, or email it of to a friend (the resulting file isn't very large).

Thanks for looking.

I'll figure out a way to post the .AIR file soon.

A little rant here.  I know Adobe AIR is new sexy and everyone's trying to build apps that run naively on the desktop, but please, if you're not making use of local filesystem, native windows, drag-and-drop, SQLLite, native menus, or any other of the useful AIR APIs, you should really consider not releasing it as an AIR application.  I'd prefer to use your application quickly via clicking a URL in my web browser.  I say this after having spent a few minutes uninstalling most of the AIR applications that have been cluttering my desktop that turned out to be remarkably useless, yet still required network connectivity.  There's no need to clutter the desktop with applications that run perfectly well in the browser!  Let's not forget about the great little thing called the World Wide Web, web applications, Web 2.0, AJAX, and regular-old Adobe Flash/Flex!

  This burgeoning Adobe AIR application market space reminds me quite a bit of the Visual Basic 3.0 days when all of a sudden tons of crappy shareware was developed in it.  Unlike those days, however, we already have a better way of running and trying out these applications, the web browser!  The user doesn't need to bother installing/uninstalling your application!

  Here's a technique that I'd love for all AIR/Flex developers to adhere to when creating their applications.  Make it run in both environments: the browser (via Flash), the desktop (via AIR).  Make the web-browser version limited in functionality -- if you desire -- showing the user the essence of your application.  Make the AIR full-blown sexy that a user might want to upgrade to or purchase (maybe the user wants to use their own personal files and data).  Prompt the user using your web-based version to upgrade to the full version at appropriate moments, like when they press the "Save" button.  This allows me to navigate to a URL, use your Flash/Flex application, and if it's worthy, download the full AIR version.  It even allows for a way to monetize your application.

  Now, I fully understand the desire to take your existing Flex apps and port them to the AIR Framework so you can test the installer and see how it behaves on your desktop.  After all, it's a great new tool, and you get that warm-and-fuzzy feeling thinking about all the new desktop applications that you can build.  But if there's something to learn from yesteryear, it's that there's going to be a lot of CRAPPY Air Applications released -- and I don't want to waste the time installing and uninstalling what are essentially demo applications.  Nor should we want to pollute the world with a ton of weak AIR applications so that when they are prompted in the future to install the Adobe AIR Runtime or and .AIR file, they're not going to want to install it because of all the negative association in their head.  (Any of you who've ever installed shareware made with tools like VB 4.0, etc. know what I mean with this.)  This is one reason why Web 2.0 applications are so great:  I navigate to a website, use the app, hate it, never go back.  Nothing further is required from me!  No installing/removing of software.

  Flash/Flex/AIR provides a very unique opportunity that allows people to try your software before purchasing via a web-browser, with nearly zero hassle.  I can't think of any other tools out there that encourage this. 

  I promise you, all my applications, you'll be trying out on the web first.  When it comes time to using your personal data, you'll download the desktop version!

  If you'd like some ideas on how to structure your Flex/AIR projects in Flex Builder so that you can build both web-based and AIR-based applications from the same Eclipse workspace, may I suggest reading my little tid-bit on How to compile both Flex and AIR Application from the same codebase.

Today, I decided it would be easier for me to demonstrate my AIR application to end users if they could just go to a link on a website.  However, getting AIR code to compile into a Flex SWF file, isn't as simple as I initially thought.  Naturally, there's the additional APIs that AIR allows the developer to use, like all the local file system interaction.  But, I figured I'd just use some form of pre-processor compilation tags, place them around the code I didn't want, compile,  call it a day, and drink a beer.  Wrong.

I searched around a bit and found a few conversations discussing how one should go about doing this.  David Coletta had some ideas posted over at his blog.  But I couldn't find any working code.  Since this took me several hours how to get it working, I thought I'd share my sample project files with you.  Mind you, I'm not totally happy with my solution and think it can be improved upon, but it's a start.

Download the code here.  (It's only for Flex Build 3, Moxie.)

The solution:  create thee projects.  One for your AIR application, one for your Flex application, and one to place most all the code, we'll call it CommonCode.  For these three projects, you create source path references to each other to include common code into their build paths.

The AirCode project includes a source path to the CommonCode project.

The WebCode project includes a source path to the CommonCode project.

The crux of the solution involves coding common code to Interfaces defined in the CommonCode project.  Both the Air and Flex Projects then Implement these interfaces into concrete classes specific to their projects.  For Air, the implementation might include functionality to save to local file system (File.browseForSave).  In Flex, you may prompt the user for an email address to send the file to. 

The other part of this solution is the shared UI.  The UI for both applications is defined in CommonCode::TestCanvas.mxml.  The AirCode and WebCode projects load this in their respective MXML files -- AirCode.mxml and WebCode.mxml -- upon starting.

At runtime when you need to save a file, you selective create the appropriate class depending on the runtime environment (Flex vs AIR), and then call the method on the Interface.   The following shows the basic implementation of the GeneralFactory class.

Misc thoughts :

1. Security.APPLICATION static string declarations exists only in the AIR framework.  Trying to reference that from a Flex project will result in a compilation error.  Use the string "application," instead.   Same goes for Capabilities.playerType DESKTOP, use the string "desktop" instead -- if using that method of determining whether you're running in the browser or in AIR.
2. The Flex compiler will not include any classes that aren't explicitly referenced in the code.  This must be an optimization.  Because of this, you need to include a declaration to all your classes that you want to have dynamically generated at runtime.  (Look at the static const called neededForCompilation in both the AirCode.mxml and WebCode.mxml -- this is essential for compilation.)
3. I don't like having the class names hard-coded as strings in the Common Code.   I could get around this by making some a Factory available on each the FlexProject and AirProject, but this seems to be a little too complicated.  For now, this is a livable solution
4. This is for compilation purposes only.   There's no dynamically loading modules at runtime. 
5. There is one negative side effect:  this slows compilation time considerably.  I now feel like I'm working in C++ back in the mid-90s.

I'm welcome to ideas on improving this implementation.  Also, does anyone have any code or CSS stylesheet for including ActionScript code in a blog without creating an image of it?  Thanks.

In my quest to have high-quality content in my news reader, I've found ten must-have blogs. I tried subscribing to a Technorati search for Apollo/Flex, but it generates 100s of articles to read, mostly of low-quality news re-postings. It has taken me awhile to soak up the full Flex development community, so I hope these offerings will help you in finding some great resources. Most of the resources are duplicated in the main aggregators, but I wanted to point them out so when they post the occasional post, you don't miss out! The numbering is purely for organizational and not meant to be a rating. Also, I'm not including the obvious resources here, like onFLex.org or Adobe's own websites.

Download the OPML file to import the following Blogs into your favorite blog reader. (The links from this page are to the actual websites, not the feeds.)

1) Ted Patrik's is an FLEX/MAX Evangalest for Adobe. Read his blog to keep up on interesting developments on the Flex product line and for handy code snippets and other useful ideas.

2) Quietly Scheming by Ely Greenfield, a developer for Adobe for over 10 years. He works on the Flex SDK. His site has components and code samples, and is a must read for anyone wanting to learn more about the nuances of Flex. Solid, coherent writer. Check out the section titled "Components" at the bottom of the blog for useful items, like the Landscape Zoomer.

3) Mike Chambers, Senior Product Manager for Developer Relations for AIR. The guy works at Adobe, writes book, and has useful knowledge that you need.

4) Sean Moore, the flash guy. Lots of great stuff, frequently updated. Great SQLLite tutorial for AIR.

5) Rico on Flex, Tips, Tutorials, News. I found some useful code snippets at the site, like creating BitMaps from Objects like Canvases. Not many people read his blog, according to Feedburner numbers, and he hasn't been blogging very long, but I find his content of a high quality and look forward to reading his posts in the future.

6) Doug McCune, a wild-man doing some interesting UI work with the ActionScript Physics Engine. He discovered the ImageSnapShot class in the Flex 3, beta framework that I found useful.

7) Tater Salad. Casey writes about both Flex and Microsoft's Silverlight. Useful tidbits, no matter what technology you're implementing with. I found the article on BitMap transformations very useful and educational, in which he takes an image, converts it to B & W. I did something similar, except I went though each pixel and averaged out the RGB values for B&W conversion. It's nice to learn about Flex's transformation and ColorMatrixFilter classes.

8) Horse and Buggy by Brad Umbaugh. He's just starting out, but I think I'll enjoy his writing about mixing Flex up with Ruby on Rails (for those of you who want to use a different backend on your applications).

9) ActionScript CheatSheet Blog. Download nice PDF files of the AIR and ActionScript Class Libraries.

9a) Ryan Stewart - Rich Internet Application Mountaineer. I originally forgot about Ryan, how could I? He likes mountain climbing, I like mountain climbing. Not to mention he's the Rich Internet Application evangelist for Adobe.

10) Adobe's Smart Category blog indexes on Flex and AIR. The following contain a lot of noise as there aggregations of some 1300+ blogs, but there's some useful tidbits in there for the obscure blogger who writes something interesting. I wish there was a way to filter on posts that have reached a certain average rating. There's also a lot of other Adobe Smart Categories that you can read.
Flex Smart Category
Air Smart Category

Other solid blogs thrown in for good measure because I discovered something useful at them:
11) Maikel Sibbald, Labs@Flex Coders, The Netherlands
12) Zeus Labs
13) Ben Stücki
14) Alex Uhlmann

If you know of some excellent blogs out there on Flex/AIR, feel free to leave them in the comments, and I'll update my reader, as I'm always looking for fresh voices and opinions to read.

I'm really fired up on Adobe Apollo right now. I think Adobe's Apollo has the potential to be a lot more than a tool allowing current web developers to write rich Internet applications. With a bit more functionality, I see it as a total competitor against all those old Visual Basic and newer .NET WinForms applications. I'm really looking forward to seeing how the online/off-line APIs work. I'm looking forward to third-party components. I'm looking forward to the applications Google creates with it. Can you imagine Google making their Google Docs application available off-line? That would be huge. The ability to write a Google Doc off-line, let it sync to the online repository upon connecting to the Internet, and then share it, edit it, and publish it from any computer, like I can today. I like this prospect very much. Also, with Apollo, I know it's going to be a lightweight install, and have a modern, sexy interface!

With Adobe's Apollo offering there's a few things to be desired. First, according to the Adobe Apollo FAQ, here's what's not in the Alpha bits, but coming soon:

• PDF support
• Online/off-line APIs
• Full top-level HTML application support
• Settings/data persistence APIs (I'm assuming this is going to be like .NET's app.config file API)
• Drag and drop support
• Copy and paste support
• Native file picker dialog boxes (This is essential since I can't really think of a desktop app that doesn't interact with files. And if you have any friends with Macs, then you know how much they love their file-chooser.)
• Full native window support (I'm assuming that Adobe wants to use native windows for their windowing support, so OSX will by default have those red, yellow, green buttons, and Windows will have it's min, max, close. Vista should look like Vista.)
• File extension registration (Custom Apps = custom data = custom file types. Allowing a user to click on their saved file data to launch the app is essential.)
• Launching an application to handle a file type
• Full control of the right-click menu
• Transparency in HTML

With this in mind, here's my wish list for Adobe Apollo (if they exist, please, point me to the solutions whether third-party or not), I'll update this over time as I discover more:

• Simple database support -- maybe an API for SQLite. (I notice that Adobe Lightroom and Adobe Bridge both use SQLite.)   Updated:  Adobe announced support for this.
• Primitive support for multi-threading. Asynchronous operations? Microsoft's WPF has Dispatcher.BeginInvoke that I can use when firing off long running tasks and allow the UI to repaint itself properly. Currently, in Apollo, I'm having to use an asynchronous Directory listing method (File.listDirectoryAsync) to get a progress bar to draw itself properly while performing a long operation on a file, even though I've already established my working set of files. I'm essentially getting a list of directories everytime I want the screen to repaint itself. (I've tried creating a custom event, even, but this doesn't seem to be working.) Desktop applications need simple ways to multi-thread on takss that aren't solely related to directory or network operations (both of which are supported in Apollo).
• Hot-key accelerators. Real desktop applications need key accelerators, you know ctrl-c that is bound to copy via a menu command? Or having labels of field names with underlined letters that let the user know to press alt/option-"some character" to set the focus to the input field (ex, "First Name:" the user presses alt/option-F). Another example is displaying menus at the top of an application. In Firefox, on Windows, I press alt-V to get the view menu to expand. The prospect of programming this functionality doesn't sound very appealing to me, especially since I know every application I write should have it.