Agile Ajax

Ajax on Way Out? Slide Down Hype Curve Exaggerated

Aidan Henry over at MappingTheWeb asks whether Ajax is on the way out. Aside from observing that the "frenzy ways of web 2.0 are over," he opines that:

My quarrel lies in the fact that many web designers and developers choose to overuse this technology to the point of stupidity. It is meant to simplify the experience, not complicate it. Using AJAX for the sake of using AJAX isn’t valid reasoning. Some sites incorporate it in an elegant, intuitive way, while others saturate the experience with an absurd amount of on-page activity. A threshold needs to be established based on user intentions.

Yes, the froth may be off the Web 2.0 bubble because of the economy (venture-backed firms take their value from IPO's and acquisitions, which slow tremendously in a recession), but Web 2.0 entrants into the marketplace are here to stay, and O'Reilly's Web 2.0 principles have been vetted by the marketplace.

FlashDevelop: Open Source Flash IDE

Despite my previous post, there is some activity around Open Source and Flash. For one, there is an Open Source Flash IDE, Flashdevelop. Right now it is tied to Windows, and it requires you to download the free debug Flash player and the Flex 3 SDK.

Adobe "Open Screen" is not "Open Source"

So Adobe is opening up their Flash platform via the Open Screen Project. Opening up in this case doesn't mean "Open Source," more like Open Spec. The spec for SWF has been published since 1998, but it came with onerous licensing restrictions. Adobe has now removed those licensing restrictions and promised to publish more API and protocol details.

Why is Adobe doing this? From their FAQ:

The Open Screen Project is working to enable a consistent runtime environment – taking advantage of Adobe® Flash® Player and, in the future, Adobe AIR™ – that will remove barriers for developers and designers as they publish content and applications across desktops and consumer devices, including phones, mobile Internet devices (MIDs), and set top boxes. The Open Screen Project will address potential technology fragmentation by enabling the runtime technology to be updated seamlessly over the air on mobile devices. The consistent runtime environment will provide optimal performance across a variety of operating systems and devices, and ultimately provide the best experience to consumers.

Some bloggers have speculated that this initiative is aimed at creating a Flash/AIR runtime on the iPhone. Maybe. But right now this thing looks more like an industry cooperative (not necessarily a bad thing) rather than a dynamic open source project.

More on site-specific browsers: Webkit-based Fluid

After my recent post on Prism, the Mozilla-based site-specific browsing tool, a commenter pointed me toward Fluid, Prism's Webkit-based cousin. After giving it a test drive, I'm impressed. Although it lacks the cross-platform appeal of Prism, Fluid already offers a nicer user experience than the project that inspired it.

Fluid's advantages:

• Better preferences: Fluid offers a far more polished UI, including preferences that help Fluid integrate with Apple's Spaces multi-desktop environment.
• Tabbed browsing: You can set Fluid up to launch secondary windows in a new tab instead of a new window. This greatly enhances the user experience of webapps with lots of popup windows. It also allows users to more easily open multiple screens of an application at the same time.
• Browse any URL: Prism spawns any URL that's not part of the associated webapp in your default browser. So does Fluid, at least by default. But by changing your preferences for any individual Fluid instance, you can enable browsing to other URLs within that Fluid instance. Want to click on an outside link in a Gmail message? Now it won't take you out of context and into another application.
• Less wonky Dock behavior: In the current version of Prism, when you create a new site-specific instance, Prism restarts the Dock and launches the application. Even then, the icon for the newly created instance remains the default Prism icon until you quit and restart that instance. Only then does the icon you picked - the site's favicon or any arbitrary image - show up in the Dock. With Fluid, upon creation of a new instance, you get a dialog that lets you choose whether to launch your webapp immediately. If you do, it's got the correct icon from the get-go.

Looking for a front-end jedi/ninja/warrior/whatever

Pathfinder is recruiting! Although it's not yet listed on our career portal, we're looking to beef up the Ajax practice at our Chicago office with a talented front-end programmer. This person should be a jack of all trades, master of several, and flexible about which warrior metaphor to adopt for professional use.

Please give me a shout if the following describes you:

• You enjoy hand-coding complex DHTML and Ajax applications. JavaScript is your passion ...
• ... but not your only passion. You also make room in your heart for standards-compliant HTML markup and expertly crafted CSS.
• Speaking of CSS, you're chomping at the bit for CSS 3. Table-free, CSS-based layout is old hat to you.
• You've used more than a single browser and a single operating system in the last five years. You can debate the merits of Gecko vs. Webkit till the cows come home. You can rattle off browser bugs like the names of old high-school friends. The phrase "Opera 9.5 beta 2 on 10.4 Tiger" doesn't sound like nonsense to you.
• You've written production code using more than one open-source JavaScript toolkit and, more importantly, you know how to code without one. You have opinions about why Dojo is better than GWT (or vice-versa) and can intelligently discuss the pros and cons of jQuery vs. Prototype vs. MooTools.
• You're passionate about front-end developement as a discrete category of software engineering, but you can jump in on the server-side stuff when you have to. SQL, Apache and the command line don't scare you.
• You've worked with templating systems in JSP, Rails, PHP or some other framework.
• If you don't have direct experience with Flash, Flex, Adobe Air or Silverlight, you're at least willing to give such competing UI technologies a shot.
• You aren't necessarily a visual designer, but you don't need somebody who went to art school to swoop in and Photoshop a rounded corner or a background pattern for you.
• You have experience working for an Agile shop - or you desperately want to.
• You may not be an information architect, but you understand the world of user experience design. You're comfortable reading wireframes and requirements documents and participating in the design of complex software systems.
• You're not scared of acronyms like XML, XSL and XSLT.
• In short, you know how to put the "V" in MVC.

If this sounds like you, I'd like to take you out for lunch and a little chat about Pathfinder Development. See our jobs page for all the boilerplate about relocation, etc.

Photos (Creative Commons Attribution License from Flicker): PhillipWest | R'eyes' | dizznbon.

Developer's Notebook: Find computed styles in IE, Firefox, Opera or Safari

At my recent Web 2.0 Expo talk, I exhorted developers to get comfortable outside the Firebug/Firefox safety zone. By rotating between Opera, Safari and even IE as our primary development environments, we can really get to know those browsers - and perhaps learn to utilize their non-standard features. Switching things up, however, can inhibit productivity until you learn your way around each browser's tools.

To that end, I offer these step-by-step instructions for finding computed styles in all four A-grade browsers. I chose the display of computed styles as my "debuggers are cool" use case because it's an obscure but useful feature for CSS debugging. Most of the time I can debug styles by looking at my debugger's snapshot of the current cascade for a given element. But sometimes that's not enough. If I've assigned a value of "inherit" to the font-family of an element, then the cascade snapshot won't tell me what font is actually applied to that element. (Not being a designer, I often can't tell the difference between various sans-serif faces, especially at small sizes.) Luckily, computed styles can give me the information I need.

As these examples demonstrate, debugging tools have come a long way in the last couple of years. Let's make the most of them for all of our UI-layer needs.

Internet Explorer 8 and DebugBar

IE's JavaScript debugging tools have finally matured, but its CSS ones lag behind. Even IE8, with its built-in debuggers (under Tools > Developer Tools), won't show you computed styles. Luckily, Jean-Fabrice Rabaute has crafted DebugBar, an plugin for Internet Explorer 5+ that adds all sorts of useful tools. Install DebugBar, fire up your version of IE and choose View > Toolbars > DebugBar to make the plugin visible. Then click the "DebugBar" icon in the resulting toolbar to open the DebugBar sidebar. You'll see two tabbed panes, one below the other. Choose the "DOM" tab on top and the "Comp. Style" tab on the bottom. In the upper pane, you should see a target icon with the caption "Drag target on document to find element." Drag the icon anywhere on an open web page and you'll see computed styles for the corresponding element in the bottom pane of the sidebar.

Rails Development for iPhone with rails_iui

I've been doing some web development for iPhone and Mobile Safari lately, not least because of a series of articles that will be showing up in IBM DeveloperWorks soon.

I was using the iUI toolkit, which contains a number of CSS styles and JavaScript event handlers to make iPhone Web apps look and feel somewhat like native iPhone applications. As I was working with iUI, I realized I was building up a library, so I converted everything to a Rails plugin: rails_iui.

Get the plugin from github: git://github.com/noelrappin/rails-iui.git

Right now the plugin is primarily interested in doing a few things:

It contains a rake task to download iUI, move it's files to the Rails public directories, and change the CSS image URL's accordingly.

There's a controller class method acts_as_iphone_controller, calling that sets up a before filter that captures the Mobile Safari user agent string and sets the request format to iphone for use in respond_to blocks. For testing purposes you can call the method as acts_as_iphone_controller(true), and all calls will be treated as iPhone requests.

There is a module of helper methods that are wrapper methods or combinations of iUI CSS classes. Included are:

• A method for creating the iPhone toolbar at the top of the view.

• Methods for creating the iPhone list structures from a list of elements that know their associated URLs, including a grouped list in the style of the iPod application

• Rounded rectangle classes

• A form helper for the iPhone toggle button, as seen in the settings page.

• A method to specify an Ajax callback when the phone changes orientation

The short term goals for the project are to tighten the code a bit and improve documentation and testing. Longer term goals are to augment iUI's JavaScript handlers with something a bit friendlier with Rails, particularly in handling history and back behavior.

So take it for a spin, let me know what you think. Hope you find it useful.

---

Please check out my book, Professional Ruby on Rails.

GWT and XUL

There are lots of nice things about writing event-based component GUI applications, but constructing UI's using code is not one of them. It's ugly, messy, time-consuming and hard to maintain. It's also a pain to read, which makes the maintenance even harder. There are a number of solutions that have been tried over the year -- WYSIWYG roundtrip GUI designer in particular -- but the one I like the most is the XML-based UI description. Much like the DOM trees that you can identify with id's and to which you can hook up event handlers, XML UI markup languages -- XUL, SwiXML, Luxor -- allow you to construct a hierarchical UI with absolutely no compiled code whatsoever. Just write the XML, load it, hook up the GUI to the event handlers and you're ready to rock. And since the XML file configuration, not code, you can write and load different XML files if you feel like changing your UI a bit. If this sounds like a good idea to you, you'll be happy to know that in the GWT Incubator Joel Webber is developing a project known as DeclarativeUi.

Writing imperative Java code to construct a user-interface hierarchy is awkward, and it makes working with UI designers difficult and/or impossible. What we want is to provide designers (and developers) with a simple way to define the static structure of applications and widgets, without having to write code.

Sound familiar? What does this markup and it's user look like?

Whitepaper - Ajax Roadmap: How to tranform your website without starting from scratch

My colleague Brian Dillard has written a rather decent whitepaper entitled Ajax Roadmap: How to tranform your website without starting from scratch, that lays out an approach to transforming your website or application without having to reengineer the whole darned thing. It offers a number of case studies, rationals and justifications for launching Ajax projects, pitfalls, quick wins -- in short, everything you need to start an Ajax transformation in your own company.

We're quite pleased with it. Come on by and have a look.

Agile Business, Microsoft and the Threat of Cloud Computing

Competition is the keen cutting edge of business, always shaving away at costs.

-- Henry Ford

I've been working with Java and Microsoft technologies -- .NET most recently -- in one form or another for quite some time. My company, now headquartered in Chicago with an office in NYC, was actually founded in Seattle by a group of four developers that had met around developing an Exchange-based bulk email system to replace the sendmail-based ones that Microsoft was using at the time. In that span, despite all of the food fights about total cost of ownership (TCO), etc., I haven't seen any evidence that Linux, Windows, Mac, Java, .NET, etc., puts you at a significant business advantage one way or the other. Until now.