Oh baby, just where do I start with this one. In it's infinite wisdom, Sydney mass transit (known as the RTA) has decided to begin replacing IMHO the already effective train station displays. Here are the new ones:

Let's breakdown the ways in which this active signage is confusing.

1. Primarily, instead of the previous congruous interface on one screen - two screens are now provided, yet the interface is divided. This immediately separates the information uneccessarily. confusion around what the purpose of each display is immediate, especially for existing commuters who are accsutomed to the single screen, single interface of yore. The real estate of the prior single plasma panel is probably 75% of this combined two screen format. This could unfortunately be an example of the classic management mistake of a) having the requirement to expand the visible area (the new 25% provided by 2 smaller screens combined) yet b) realising that the software to run the screens cannot merge the information into 1 display or otherwise remove the vertical separator that divides the displays. This may be the inital culrpit behind why usability was lost, very early on in this civic projecte.
2. Eye tracking will show that the most prominent and inital hot spot is actuall the "Following Trains" which look like embossed buttons on top of a contrasting blue display. This is unfortunate for someone who didn't bother to look back up and to the right for the "Next Train" which is camouflagued amongst a wash of white in the right scrolling monitor. Incidentally, I assume the business requirement here was to provide "more information about following trains;" something which was not availible in the prior interface. So, what should have become a benefit, implemented incorrectly, now is a distraction to the single most important use case: "When is the next darn train?" I can almost imagine a designer reflecting that the right screen should be used to replicate the original display (from an information architecture perspective, it does) and simply using the left panel to display otherwise new and auxilliary information. This approach fails to appreciate overall analysis of the combined result, while trying to correctly minimise changes to existing commuters.
3. In fact, the effect power of borders and box shapes even creates an area of more attention towards the blue box for "8 cars" than the time of the next train. Now let me  ask you as a commuter, how many times have you really cared about the exact number of cars on a given train, or how often this actually factored into a decision about your travel? I can honestly answer never for me - perhaps more important for the staff or authorities on patrol.

We'll look in our next blog post on how I would have redesigned this interface for greater usability.

Sanebull

is an innovative and functional desktop for active traders. I thought I was in love with Google Finance, but this takes a drastic leap forward in terms of creating a unified dashboard. Although I'm a big fan of the live updates, until charting is implemented, I can only bank on this site for it's potential. I'm looking forward to account management features, as reentering your stock picks is less than ideal. More than just targeting the finance sector, which is IMHO the wisest of decisions when creating incubator software for a specific audience, I really enjoy the overall framework built for window management. By far the best implementation I've seen to date.

Not that I'm considering starting a trend here, with this post that could be considered a flaming of the Web 2.0 poster child, but having spent the last few months frustrated and now back at square one, it should be clear my warnings are in your best interests. Oh Rails, where to begin. Why don't we start with the coy marketing. What better a demo than to have your prospects actually use your tool, and convince themselves that they are empowered. I should tell my boys in Sales Engineering at RedDot to work this into the standard demo - it's absolutely brilliant, along with the rest of the compelling story painted by the boys at 37signals (no need to trackback). So, after the seasoned Java developer swallows his pride and scaffolds out a recipe or two in Rails, the suspicion begins to grow into a semi-solid confidence that "this could work, its got potential." I only wish it would stop there, but it doesn't, and most developers, as they should, begin their first forray into this new technology. To make a long story short, I've just backtracked while leading a start-up project with 3 seasoned Java developers who were all similarly turned on by Rail's appeal. What's not to like? You have several engineering best practices baked in, and some lightning fast efficiency boosters, who wouldn't go for that instead of setting up scripts to distance yourself from configuration quagmires in Hibernate, or whatever mile-high J2EE software stack you've got cluged together, eh? I'll tell you what's not to like:

• Nothing is well documented.
• Nothing. I'm serious. I know, becuase I built a Rails server on Linux from scratch, not using InstantRails like you did when building the Cookbook sample.
• Capistrano is a joke. Again, maybe I'm missing some treasure trove of documentation, but even so, there are no best practices in place, that's for sure. Even if there is a convention, great, where is it?
• All but the most trivial associations require laborious hardcoding and retrofitting to get the level of detail and elegance you'd expect in Java. Point blank: ActiveRecord is NOT complete, nor robust. This is a known shortcoming to the Rails-cognescenti
• Good luck performance tuning, beyond using the right SCGI processor / Web Server combo (Apache/FastCGI).
• I don't know if any of you have ever heard of Eclipse (grin) but forget any of the efficiencies you would expect when using RadRails, the Eclipse clone for Ruby. Not even close. Can we say Ctl-Space does nothing? Ouch. Scaffolding is great, but mama don't take my IDE away. That's zero-sum.

So, why then, I ask, all the buzz about Rails?

• In my humble opinion, the authors did a guerilla-worthy job targeting non-technical web folk: designers, UI engineers and lightweight programmers who are NOT Java zealots. For all but the most trivial applications, you will run into issues long term issues that are often gamebreakers.
• Couple this lay audience with the fact that Rails has so many classical architectural patterns baked in by convention, they created the impression that Rails was going to turn little old me, a graphic designer, into a veteran, MVC-smokin' software engineer! Keep smoking. Just don't jump out of any windows, Superman. Um-kay?
• That sense of empowerment is a dangeours thing, becuase it breeds fanatacism. And fanaticism leads to evangelism. Ask Rackspace. So now, every Harry who can complete the incredibly straightforward Cookbook sample is now a Rails pundit with 3 years of hands-on experience, spewing Rails mantras all over the internet clutching for a piece of the blogosphere, cautious as land developers in Vegas.
• Let's not forget that the developers of Rails had the luxury of lifting best practices from software engineering, in terms of deployment, MVC and scaffolding, from other known frameworks AND at the same time was not limited by the conflicts of supporting multiple codebases. Anyone who has configured a deep framework has had that Devil on his shoulder telling him or her that they could have just built a stack from the ground up in less time. That's a luxury the Rails group had: they controlled the entire stack: MVC, OR mapping, application deployment... literally the entire shebang! This is the kingping for pulling of "convention" becuase you can't enforce conventions when wrangling someone elses off the shelf code.

Am I being a hardass on Rails? Absolutely. Rails has made some fantastic claims that need to substantiated, as far as I'm concerned. However, I give 2 Big Guerilla Thumbs Up to the authors for sneaking in this immature technology as capable of dethroning Java in the enterprise. All I can say, if I haven't said it already, is "not today." Maybe in the future I'll eat my words, but I think a counter attack will be out of the gates before tha ever happens. Java on Rails? Why not, its been in the works since '05. What good has come of the Rails movement? Plenty.

• Rails is a great, great tool for rapid prototyping. Bulid it in Rails, get VC, and then deploy using Java, just like my startup did (OK, sans the VC part). I'm a huge fan of build to throw away, and lessons learnt are lessons leveraged when you do it right. Rails to me is the first measurement in the carpenter's law.
• The concept of convention is long overdue. SAP relies on convention in it's development paradigm. An architect spends a long time making a decision from atop the mountain, it is written in stone as the best practice, and then the product is tailored around these best practices. Dogmatic? Potentially. But then again, how many people do you see starting their own public transit companies because they dislike the route? They don't, becuase the systems in place are reliable, dependable and follow a convention, wether or not it is the best, that's life. But as a corallary, you try letting all the passengers decide what the best route to lay the tracks are.

I expect Rails to mature over the years, and I think it would be a great tool for Compute Science departments since students can leverage OOD, command line driven programming, web application development and so many other tennants in one nice stack. But until then, I'll just be smug as bug developing in Java.