Many websites invite their users to visit a regional version of the main site, but unfortunately few seem to manage to get the localization right. I recently had to renew my Norton AntiVirus subscription and I was directed the European Symantec site, where I was confronted with a classic example of poor localization. This is the subscription renewal form that came up:
Click to enlarge. |
—Why an earth offer a list of states of the union when it's a European site and I've selected United Kingdom as the country?! That's just laziness.
As another example, yesterday I was investigating Sun Microsystems' Java certification, which led me to the support and training site for UK and Ireland.
Down the left hand side of the page I was invited to Request a Catalog. I had a dilemma at this point because I didn't want to request an American catalog but rather a British catalogue. Fortunately, as it turned out I could do neither, because clicking the link took me to the site map, for the page could not be found. Well done Sun!
The problem of what to do about the browser Back button has reared its ugly head again. Actually it's never really gone away, it's just gone out of focus because other issues have come up and because it appears intractable.
Our latest thinking on the matter is that we'll display a friendly error message (whatever that is) to the user if they click Back until, like a dog learning by repetition, they come to know that a web application is not a web site; even though it looks the same and is accessed in the same way. I'm skeptical that this attempt to refine the user's mental model of how the application behaves will be successful and I hate the current technological limitations of web applications for forcing me to inflict this crippled solution on my users, who are not dogs and don't need to be taught new tricks.
I've just started reading the book Dealers of Lightning which is a detailed account of the astonishing level of creativity and invention that occurred at the legendary Xerox Palo Alto Research Centre (PARC) in the 1970s. For those who aren't familiar with the story, the brightest minds in the industry were brought together at PARC, the result of which was that (for example) their 1973 Alto personal computer had a mouse with which to access the familiar desktop GUI that we all use every day. Oh, and you could hook it up to other Altos too, using Ethernet technology that was also invented at PARC. Or perhaps use Bravo, its WYSIWYG word processor invented at PARC, which is the grandaddy of Microsoft Word. Remember, this was in 1973 when Britain was driving about in the Ford Cortina and listening to the Bay City Rollers!
Every family in Britain had a Cortina in 1973. |
For various reasons Xerox were not able to capitalise on their twenty year head start in modern computing, although it's often forgotten that PARC paid for itself many times over from the revenues generated by its invention of the laser printer alone. Incidentally, I've never understood why computer monitors don't follow the A4 portrait form factor used by the units at PARC.
Where all this nostalgia is taking me is to the thought that with web applications, we've dragged to the trash can icon over thirty years of research, innovation and refinement of HCI technology, and have effectively gone back to the time of the IBM 3270 dumb terminal. The network may be the computer, but if I create a conventional desktop application then I have a rich variety of widely-used and understood user interface widgets to choose from. On the other hand, creating a web application constrains me to structuring the interface in a way that tries not to expose the limitations of the underlying technology, but in fact does end up exposing them. I have to coerce the users into working a certain way rather than giving them the freedom to choose how they'd like to work within the boundaries of the application. Apart from the intellectual challenge, the pleasure I get from programming is from the thought that in some small way my software is making the lives of my users just that little bit better, or certainly less tedious, but I'm denied that feeling when constrained by the HTTP straight jacket.
As someone who has had the pleasure of rolling out a slightly complex Visual Basic 6 application to a few supposedly identical PCs that turned out to be anything but identical, I can well understand the lure that the zero footprint web application model offers. From an IT support department perspective this is great; just send out a URL to the application and then you can happily spend the rest of your day installing Microsoft security patches or perhaps working out how to get Linux to do what that nice Windows 2003 Server start-up wizard did for you. I exaggerate the point for comic effect but apparently the reduction in the support burden in a reasonably sized organisation—which is not the same as a reasonable organisation—is huge. I've never been entirely convinced about this, mind. It should be possible to control DLL hell in a tightly controlled corporate environment on the proviso that you have people who know what they're doing. I think a lot of the problems stem from programmers developing internal applications—probably using VB—not entirely understanding what it is they're doing (accidental programming) or crucially, not knowing how to package up and deploy their applications properly.
Half-way houses between full-blown desktop applications and half-cocked web applications are starting to emerge. In response to my original article Nigel McFarlene helpfully pointed me to an excellent article he'd written about Mozilla's XUL and more recently Microsoft are pushing their own XAML for Windows Longhorn. Both seem like worthy ways to address the problems of current web applications (I know there's more to XAML than that). However, neither help me because unfortunately Mozilla isn't an option where I work and Windows Longhorn is years away from shipping and even further away from widespread adoption.
For corporate software that is never going to be accessed from a PDA or phone, thin client applications are a criminal waste of all that Moore's Law horsepower packed into that new black and silver Dell gigabox sat on your desk—a miracle of technological progress that was brought to you not without environmental impact, so why waste it? Ultimately what it comes down to is this: are you creating software for your IT department or for your users? And herein lies the problem: the difficulty I have with web applications is that they're designed to benefit the IT department and not the user. The user may as well be a dog.
If there's one thing that's guaranteed to make people distrust a particular piece of software, it's when it trashes their data. I've often heard users complain of losing data whilst using Microsoft Office. I can't recall ever having had that particular pleasure, but today I did lose an afternoon's work because of using Oracle software. To be specific, their 9i SCM source control system.
Fortunately, I only lost some easily re-creatable prototype code built around the Display Tag library I raved about last time. I'd definitely added the code to the repository using JDeveloper (I remember typing the check-in comments and clicking OK), but when I looked for the files later on using the Repository Object Navigator administration tool, they weren't there! Unfortunately, in the meantime I'd deleted the local copies of the files so that I could get clean versions from the repository.
We have lost so much time at work because of this flaky tool, that frankly I'm relieved that it looks likely that we'll finally be getting rid of it and using something else. I normally try to touch on my experiences in my day job in a more oblique fashion, and I feel guilty writing this because I know that Oracle employee Brian Duff reads this blog and vice-versa. This afternoon was the final straw though and I need to let off steam and this is my outlet for doing that.
I can only go by my personal experiences and they've not been good. My impression of Oracle SCM is that it's not a first class citizen in the Oracle software line-up. It needs dropping or investing in, because as things stand, the Oracle 9i database may be unbreakable—to quote their marketing—but some of the software built on top of it definitely isn't.
Maginot Line Security
I booked some train tickets earlier this week using the corporate interface to TheTrainLine. They sent me an e-mail which explained how I should have total confidence in the security of their site and any transactions carried out using it. Then the e-mail quoted my user name and password. Oh, the irony! When will these companies learn that e-mail is not a secure medium?
One of the things that has struck me whilst learning J2EE is the fact that there's a symbiotic relationship between J2EE and the world of open-source software. There's a bewildering choice of open-source software available to the enterprise Java developer, encompassing everything from application servers to string libraries and anything you can think of in-between.
It's quickly become clear to me that there are two hard and fast rules to follow on any J2EE project:
- Identify what open-source projects are out there that can help you.
- Decide which ones are appropriate for use on your project.
As an example, on my current project we have a—by no means unusual—requirement to display potentially large amounts of tabular data, so we needed some way to provide paging of the list. We were about to design and implement our own solution, when I remembered reading about a JSP tag library on TheServerSide.com. A Google search later and I'd located the Display Tag library which does everything we need and a lot more besides. It would have taken us weeks to produce a fraction of the functionality ourselves.
I know this will be old news to some of my readers but it really is a fantastic component. Creating a four column, pageable list, where the first two columns can be clicked to sort them is no more complicated than these six lines of code:
<display:table name="somebean" sort="list" pagesize="8">
<display:column property="col1" title="Column 1" sortable="true"/>
<display:column property="col2" title="Column 2" sortable="true"/>
<display:column property="col3" title="Column 3"/>
<display:column property="col4" title="Column 4"/>
</display:table>
—Pretty neat, huh? Like all great components, virtually everything is fully configurable so it can be tailored to meet the exact requirements. If not, then you can always download the source. Go and play with the examples on the website if you're still not convinced.
One of the things I used to love when I was a Delphi developer was the large selection of open-source (or free closed-source), components. There were some real gems hidden amongst the endless chaff of clock components and rotated labels.
I remember when IE 3.0 first came out sporting its “revolutionary” flat look toolbar buttons. Shortly afterwards a friend came across a TExplorerButton component on one of the main Delphi sites and suddenly, with a few mouse clicks our applications could look like that too! Gimmicky perhaps but that sort of instant gratification was exciting to me in those days as a rookie programmer. I also think it was a powerful illustration of the power of OOP and a testiment to the great design of Borland's VCL framework. I get a real kick out of using a well designed, developed and documented component and Display Tag is all of those things.
2003–2024 John Topley