Rich Internet Apps That Just Work—Writing for the User
“The customer is always right.” This time-worn adage—attributed to either Harry Selfridge, founder of the famous British Selfridges department store, or Marshall Field, of the Chicago department store that bears his name—has been discussed and dissected to no end. Undoubtedly, every one of us can come up with plenty of cases when customers aren't right, and it does not make sense to treat them that way. What is true, however, is that if you want to sell (or develop) something that's useful to customers, you must build it for the way they actually work, not the way you want them to work.
In the Web's early days, we were all entranced by the ability to access any application anywhere, without installing anything more than a browser. Developers loved the idea of writing in a single universal language. Even better, HTML is declarative—no interesting components and callbacks, no per-platform or per-OS-version oddities (more or less). Users loved the simple book paradigm. You could go back and forward (which, unsurprisingly, were the names of the buttons), and even click reload. The semantics were simple; writing for the platform was easy, and deployment, compared to managing each desktop, felt like the new Enlightenment.
AJAX was wonderful. We could get what we wanted from the server without reloading the entire Web page. We could process it in the background. We could get as little or as much as we wanted. It seemed Web apps, now called Rich Internet Apps, finally were fully competitive with desktop apps in terms of ease of deployment and performance. It enabled such ubiquitous apps as Google Maps, which would have been impossible without AJAX.
The big problem with AJAX apps is that they broke Web semantics. The Refresh, Back and Forward buttons work entirely on the address in the URL bar of the browser. In the days of static pages, that mostly indicated where you were: http://example.com/store?product=12345 was definitely different from http://example.com/store?product=99999.
In the modern RIA AJAX world, however, the URL was http://example.com/store. With the product rendered using AJAX, the URL unchanged, reloading was highly unlikely to bring you back to where you were.
The first responses were to add complex state to the server. JavaEE, PHP frameworks and others all added session variables in which you could store oodles of information about what the user's last request was, and so you could roughly attempt to reconstruct it for the next request. The entire JavaServer Faces (JSF) framework is built around such complex state semantics. These did the job, more or less, but they were very complex and required lots of effort with which to work.
The next attempts essentially said, “we don't support browser buttons!” Put in other terms, “we and the technology are right, and the user is wrong.” As anyone who ever has been in business knows, this strategy is doomed to failure. It may work, for a little while, if your customer has no alternative, but customers who are told they are wrong and “just don't get it” quickly will look for alternatives. Silicon Valley is littered with the corpses of startups that whined, “our customer just doesn't get it.” Of course, it was the startup (and the engineers) who just didn't get it.
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide
|Nativ Disc||Sep 23, 2016|
|Android Browser Security--What You Haven't Been Told||Sep 22, 2016|
|The Many Paths to a Solution||Sep 21, 2016|
|Synopsys' Coverity||Sep 20, 2016|
|Naztech's Roadstar 5 Car Charger||Sep 16, 2016|
|RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop||Sep 15, 2016|
- Android Browser Security--What You Haven't Been Told
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Nativ Disc
- The Many Paths to a Solution
- Naztech's Roadstar 5 Car Charger
- Synopsys' Coverity
- Securing the Programmer
- RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop
- Glass Padding
- Identity: Our Last Stand