Philip Brittan's Blog

Community: JavaDesktop Archives

The Rich Client Strikes Back

Microsoft is redefining the application interface around rich clients, and if Java does not have an answer, it faces being cut off from end users. The answer lies in matching Microsoft's richness while trumping it on security.

FYI, I just published an article in Java Developers Journal: The Rich Client Strikes Back.

Avalon: A new UI for Windows

Avalon gives Microsoft an opportunity to demonstrate its leverage over the user experience and to shake up competitors.

There is a lot of buzz in the Microsoft community these days in advance of the first public educational events around 'Avalon', one of the many new pieces of the Longhorn version of Windows. Avalon is the new Windows API, and it apparently represents a major jump in UI capabilities. Part of its value proposition is in the ease of use to developers and part in the experience for end users.

In order to increase developer productivity, Avalon will rationalize and reduce the number of APIs in the Win32 stack from over 70,000 down to 8,000.

On the user experience side, Avalon will feature advanced support for 2D and 3D vector graphics as well as standard GUI widgets. Some descriptions of Avalon suggest that it is more comprehensive than just the graphics layer, and will incorporate support for paradigm-shifting "task-oriented" UIs.

Microsoft has already said that they will be releasing a version of Microsoft Office for Longhorn based on Avalon, which should help drive user demand for Avalon’s capabilities.

I see several immediate ramifications for this:

1. It is a shot across the bow of Macromedia Flash MX. Flash has traditionally been focused on adding real-time vector graphics to Web pages for decoration or on-line advertising. Microsoft played along with Macromedia, bundling Flash into IE, because it never really cared about those fluffy things. But in the last year or so, Macromedia has been actively re-positioning Flash (now called Flash MX) as an alternative for building the user interfaces for enterprise applications -- smack into Microsoft’s home turf. It has been inevitable that Microsoft would respond at some point (there were early rumors that Microsoft might even try to buy Macromedia), and now it seems to be doing that with Avalon. Even though Longhorn isn’t due out until 2005, the mere fact that Microsoft will be baking into Windows the same kind of real-time 2D and 3D vector graphics capabilities that Flash promises, nicely integrated into same API layers as standard GUI widgets, could create enough FUD to slow down companies considering Flash MX. The fact that Flash is a client-side UI execution engine, just like Microsoft technology, means that it doesn’t have a strong differentiation over a Microsoft offering. Strategically, Microsoft can potentially always turn off its bundling deals with Macromedia, leaving them high and dry.
   
   
2. Introducing a major change in the UI API means giving Java a good shake. It is likely that it will take client-side Java long time to support the new capabilities of Avalon. If Microsoft can get its users addicted to the new paradigm (by using it in Office, which they plan), then they make Java look even more out-dated on the client side.
   
   
3. As I have argued elsewhere, Microsoft doesn't really like the idea of browser-delivered apps because it weakens the Microsoft desktop. Just as with Java, if Avalon gives users an amazing experience which is just not available through the browser, then browser-based apps don't seem like such a good idea to users. Alternatively, the browser might support these capabilities, but only through IE when powered by IIS on a Windows server.
   
   
4. Longhorn requires hefty hardware support, so Microsoft will undoubtedly time release to coincide with a price/performance level for new PCs that will allow them to encourage a massive hardware churn. That means that the Longhorn release will likely be coordinated with hardware partners like Intel and Dell.
   
   
5. The depth dimension of the desktop is catching on. Sun’s Project Looking glass uses depth by letting users angle windows away from them, thus using less of the 2D space of the desktop while still giving users an oblique view of what’s in the window. Microsoft’s new desktop, Aero, which relies heavily on the capabilities of Avalon, also makes more use of the 3rd desktop dimension by supporting transparent windows (so you can see the whole stack underneath at once), and also supporting real-time window rotation.

Of course, a rich thin client technology could take advantage of all the advanced features of Avalon and still let the business logic be powered by Java.

.NET on Linux, part 2 - "It's the API, stupid"

Speculation on a strategy for Microsoft to co-opt Linux

Pardon the title. I'm not actually calling anyone stupid. Just couldn't resist co-opting President Clinton's '92 campaign theme.

While writing my previous blog entry on .NET on Linux, I started thinking about what makes up an operating system. Certainly there is the kernel, there are system services, and there is the developer API. If one company is going to control the flow of money related to an OS, it may not need to control the whole OS. And if it set out to control just one part of the OS, the developer APIs would be that part. Controlling the developer API means controlling how software is built on that platform. It means being in the best position to provide tools for that API. It means being the one to arbitrate interoperability.

I believe that Microsoft has a shot, if they so choose, at making .NET a cross-platform developer API that would give them almost as much money-making ability and control over open-source OSes, such as Linux and FreeBSD, as they have over Windows itself.

A good description of the value of controlling the developer API is found in Jerry Kaplan’s book, Startup:

Creating an API is like trying to start a city on a tract of land that you own. First you try to persuade applications programmers to come and build their businesses on it. This attracts users, who want to live there because of all the wonderful services and shops the programmers have built. This in turn causes more programmers to want to rent space for their businesses, to be near the customers. When this process gathers momentum, it's impossible to stop.

Once your city is established, owning the API is like being the king of the city. The king gets to make the rules: collecting tolls for entering the city, setting the taxes that the programmers and users have to pay, and taking first dibs on any prime locations (by keeping some APIs confidential for personal use).

This is the great secret of the computer industry. While the newspapers chronicle the daily skirmishes of computer companies and their products, the real wars are over control of APIs, a subject too arcane to attract the attention of the press. But once an API is established, the owner has a natural monopoly of unprecedented proportions. API wars are brutal, winner-take-all conflicts in which the losers become mere shadows, eking out a marginal existence in specialty markets.

But it didn't work. Every pure Java office project, for instance, failed. Developers on those projects have told me that it was Java’s lack of focus on usability and performance that killed them. Those types of apps have to be pixel-perfect and Java was not pixel perfect. So Microsoft retained app supremacy and also retained control of the developer APIs on Windows, which has become essentially the only business desktop platform that matters at this point. Microsoft also performed an "embrace, extend, extinguish" on Java, almost immediately adding proprietary features to their version of the JVM, the result of which has been lawsuits, C#, and banishment of the JVM from Windows XP.

However, Java did go on to find big success on the server, where cross-platform does still matter (because there are still several vendors selling servers; if Microsoft sews up the server market too, then cross-platform won’t seem important on the back-end either). Plus, on the server, Java’s usability issues are far less of a problem.

To reconnect with my original point, I fear that Microsoft is maneuvering into a position to turn the tables on Java and provide what Java set out to provide in the first place: an abstraction layer that will allow developers to write to build high usability apps for many platforms at once. And it has a much stronger starting foundation: firm control of the most prevalent desktop platform, a reputation for getting things "pixel-perfect", and the world’s most popular desktop software, Office.

If Microsoft chooses to go down this route, it can jump-start the process and start making money from Linux and other OSS platforms by making its vast catalog of applications available for purchase on those platforms. Those apps will pull the .NET framework onto desktops that don’t already have it.

A world in which every computer is running Windows is probably impossible, because users get to choose, and there are users who don’t want Windows, for one reason or another. But only developers choose the API and write software to it. Users don’t necessarily even know about the API. If Microsoft successfully attracts large numbers of non-Windows developers to .NET as a way to develop Windows-style apps across all platforms, then they don’t have to wait for users to adopt Windows. The essential parts will be baked into everything they could possibly buy.

Of course Microsoft has to want to do this, which is not a given right now (although they are already testing the waters with the Mac and FreeBSD), and the success of this strategy will depend on how strongly Microsoft can establish .NET as the client side technology standard.

Java vs. .NET, part 5 - Rich thin clients

Let Java play to its strengths and co-opt Microsoft’s advantages

In the previous parts of this series on Java vs. Microsoft .NET, I lay out the threat that .NET poses to the Java ecosystem and the advantages on which Microsoft is relying to carry out that threat.

So…what is the response to this threat? Those of you who know me already know what I’m going to say: rich thin clients. In fact, a month ago java.net readers byronsebastian and d_bleyl forshadowed this entry.

The concept of rich thin client technology is to deliver the user experience of native locally-installed desktop software (co-opting Microsoft’s strength) from server-based applications (playing to Java’s strength). With this approach, Java gives developers a cross-platform method for delivering applications that feature the desktop benefits that users want with the deployment and administration benefits that CIOs are looking for.

I’m not talking about Java Applets, Flash, or other disguised fat-clients. In order to deliver on the full benefits of the server-based model, and to avoid walking into a Microsoft trap, rich thin client technologies must leave 100% of application code on the server. Putting code on the client means putting it in hostile territory where it can be attacked and thwarted by Microsoft. Additionally, rich thin clients need to be browser deliverable, but must also be able to operate independently of the browser.

It may, in fact, be necessary to use Microsoft’s own technology to implement the generic client-side piece of a successful rich thin client framework on Windows PCs/devices. I know that there is a feeling in the purist Java community that applications must be 100% pure Java to be acceptable, but I believe that the most important piece of the chain is that the applications themselves are written in Java -- that’s the part that builds a developer community. If those applications are then displayed by Microsoft technology on the desktop so that they can take advantage of all the desktop benefits, so be it. If Microsoft really does banish Java from the PC, it just won’t matter to rich thin client Java apps running safely on the server. On non-Windows desktops and devices, J2SE, J2ME, or even native technology can be used for the generic client. The desktop technology doesn’t matter -- in the rich thin client world, it’s invisible to the application.

I am also not talking about terminal server technology, like Citrix or X-Windows. Today’s rich thin clients can offer an immediate, responsive native desktop user experience, with no lagging “remote mouse” and with very high server scalability and super low bandwidth usage. They can offer the user experience that Microsoft promises with Smart Clients.

The Java platform must offer compelling benefits beyond simply matching Microsoft. Rich thin clients can do this:

• Write Once, Run Anywhere: I just read this article titled “Java Everywhere”, which stated “To get Java working properly on all devices, we must compromise one of Java's most recognized principles: Write Once, Run Anywhere (WORA).” How sad, and unnecessary. With rich thin client technology, a single Java code base can run on the server and project its UI onto a very wide variety of client platforms. WORA can be preserved.
  
  
• Open Standards: Move the entire balance of power to the server. Then open standards have some teeth.
  
  
• Security: Keeping all your code on the server means that your application cannot be a vector for viruses and destructive bugs to client PCs.
  
  
• Developer Productivity. Writing software that has 100% of its code on the server is easier to architect, debug, and manage than either client/server or multi-layer Web apps. Rich thin clients let developers architect their systems into as many layers as they want, not as many as the technology dictates. And it’s easy to bring standard, best-of-breed tools -- Java IDEs, debuggers, profilers, optimizers, etc., -- to bear on the entire code base.
  
  
• Resource-leveling: Utility computing promises to help companies save costs by virtualizing processor load and other resources across a managed grid. Keeping all the code on the server means all the code can benefit from this.

Rich thin client frameworks are also architecturally amenable to supporting a variety of languages. As I argued in the last part of this series, the Java platform needs to recognize the huge investment companies have in legacy systems and provide a way forward for those companies without requiring that they rewrite their apps in Java. Rich thin clients bring that legacy code into a server-based, network-centric environment and then give developers a way to add new features to those legacy apps in Java. Since all the code is on the server, it’s architecturally easy to deal with big piles of spaghetti (without having to disentangle them) and to mix and match languages and technologies, all under the covers and away from users and hard-to-manage desktop computers.

If rich thin client technology takes off, then it has the effect of marginalizing the desktop PC, a big strategic win for the Java camp. Rich thin client apps don’t generally care what kind of client hardware is displaying them. Customers can go with whatever is cheap and convenient, not with the platform that happens to support their favorite apps. This paves the way for non-Windows desktop proliferation.

I believe that our industry is shaping up for an epic battle between the Microsoft ecosystem, wielding .NET, and the non-Microsoft vendors, championing Java. The battle will be very hard fought and Microsoft will give no quarter. Already they have put Java into a difficult position. The best way out of the trap is not to fight them on their terms, but to redefine the battlefield. This opportunity is available because the world is moving towards being always connected. Microsoft realizes this and is trying to use our increasing connectedness as a way to drive their platform from the desktop to the server room. The Java world needs to head them off at the pass and make real the fear that Bill Gates had of the Internet in 1995.

Software Usability Case Study: Novices and Power Users

Yes, you can support both

In his post, Widgets follow form follows function, Chris Adamson ably describes the dilemma many software designers face when trying to design applications that support both novices and power users. In my post, Brittan’s Rules of Software Usability, I introduce the idea that software usability strategies can be seen through the application of three concepts: perspicuity, alignment to personal workflow, and style.

The dilemma that Chris describes stems from the fact that novices need more perspicuity (so they can figure out what to do) and power users care only about workflow efficiency (they already know all the functions by they just want to work fast). And this is a problem because perspicuity and workflow can interfere with each other in application design (wizards are an example of this).

But there does not have to be a conflict between perspicuity and workflow. I can’t resist offering up a case study from my own experience on an approach we took to support both novices and power users. My first company, Astrogamma, developed and sold single product called FENICS which performed pricing calculations and risk management analysis for foreign exchange options traders in large banks and brokerage houses. FENICS was able to capture 80%+ market share of institutional FX options traders around the world. We sold the company in 1995 but it continues its market domination today, in large part because of the quality of its user experience.

Traders are a very tough group to design software for. They are incredibly demanding. Speed of execution is critical for their business. They certainly have no patience to read a manual and learn how to use obtuse software. FX traders are very international (our customers were spread across dozens of countries) and many spoke very shaky English at best, so long explanations were lost on them. But traders also engage in a pretty narrow set of activities all day long, day after day, so they are prime candidates to become power users quickly. Our software was core to their ability to do their jobs, and most traders used only FENICS during their day.

In order to support a quick learning curve for impatient users, we used a fairly typical perspicuous GUI layout. All the fields were visible on the screen at once. All the functions were clearly labeled and visible at all time on a toolbar. The goal of our layout was to make sense of a trader’s world and present them with a full dashboard of fields and functions that would seem intuitive to them the first time they used our software.

So handling novices was pretty straightforward (we also had very complete but wildly underutilized documentation). But how did we handle power-users (the bulk of our user population) in that same interface? For that, we used a variety of strategies including the ones below, some of which admittedly took us a little astray from what is standard Windows GUI behavior today:

• Keyboard navigation: Mouse navigation in FENICS was totally optional and was in fact rarely used. All the data fields were arranged in two vertical columns, and the user could navigate from any field to any field with the arrow keys (more like spreadsheet cell navigation than a typical form) and we provided hot-key combinations to instantly move focus to any specific field. We also supported Tab which moved focus to the next empty field.



• Smart parsing: All data fields on the main screen were edit boxes. No radios or checkboxes on the main screen. And each of those edit boxes featured a smart parser that knew a lot about the type of data that was being entered into it. The parser would engage as soon as the user left the field or hit “Enter” in a field. We would try to interpret whatever the user typed in. Our parsers understand specialized lingo of FX options traders. We could parse dates in multiple formats, for a simple example. If there were ambiguity, the parser would pop up a list of choices for the trader to select among. If the user entered blank into a field, a list of all possible choices would pop up (obviously we didn’t do this for numeric fields!). The Esc key instantly dismissed the pop-up. As soon as input was parsed, it was immediately re-displayed into a standard format to let the user know that what they entered was understood.



• Use context: Not only did parsers know about the type of data being entered, but they also knew about the context. For instance, let’s say that at that time the exchange rate between Deutsche Marks and US Dollars was 1.5 Marks/Dollar and the exchange rate between Japanese Yen and US Dollars was 150 Yen / Dollar. If a trader entered “14” into an exchange rate field, then the parser would look at which pair of currencies had been specified for this options contract. If it was $-DM, then that 14 would be interpreted as “1.4000 DM/$” and if the currency pair was $-Yen, then that 14 would be interpreted as “140 Yen/$”.



• Multi-field parsing: In some areas we let the user enter values for several fields into a single field. They we would parse of the individual pieces and populate the correct fields with those pieces. This was extremely fast for the power user and a novice could always fill in the individual fields. So for instance, a power trader could enter “150 $ DM Dec Call” into the upper left field (which had focus when you first entered this main screen). This string of seeming gibberish is how an FX options trader naturally describes a contract anyway, so it was very natural, and it was translated as a “Call option to exchange US Dollars for Deutsche Marks in December at a strike price of 1.5000 DM/$”. We would parse all the pieces of that out and populate the individual fields: option type (call/put), each of the two currencies, the maturity, and the strike price.



• Auto-calculation: An option contract has many interlocking pieces of data, and specifying some number of pieces of data would necessarily imply what the remaining pieces would be. FENICS just did this automatically. For instance, there is a set relationship between the current exchange rate between two currencies, the interest rate of one currency, the interest rate of the other currency, and the ‘forward’ exchange rate of the currencies. As soon as any three of those four pieces of data are specified, the forth is calculable. So, in FENICS when any three of those fields was entered, the fourth was immediately automatically calculated and filled in.



• Default values: We tried to fill every field possible with an intelligent default, like today’s date or the most common market for a particular instrument. Some defaults were customizable by the user on a set-up page. Any default field could be overwritten on the main screen. If the overwriting value were erased, the default would reappear.



• Color coding: Using different font colors in the edit boxes, FENICS would show the user which fields had been filled in manually, which had been calculated, and which had default values in them.



• Get rid of things that interrupt flow: Everything vital to pricing an FX option took place on that main screen, and it was very ‘flat’. We featured no wizards, and used pop-up windows as sparingly as possible.

The main screen of this application was incredibly reactive. The user could move around the screen very rapidly, could enter values as they wanted to enter them, and the system was constantly interpreting what he user was doing to try to remove any unnecessary steps. These concepts proved so useful in FENICS that we carried them forward into subsequent products. They are even supported in our current product, Droplets.

To wrap up, this case study was intended to illustrate that there are ways that the seemingly conflicting usability needs of different types of users can be addressed at the same time, and to provide a description of what we did so that others can build on those ideas.

Brittan’s Rules of Software Usability

I am not going to pretend that I am a usability guru. There are plenty of folks who have studied the issues of software usability far, far more rigorously than I have, people like Jakob Nielsen, Tog, and Alan Cooper, among many others: Joel has solid advice on User Interface Design for Programmers, the Interface Hall of Shame is very entertaining as well as educational.

However, usability has long been a central interest of mine, and it has been a hallmark of all my companies. For the first two companies, it was the usability of our software products that helped set us apart. In my current company, it’s about enabling developers to deliver highly usable software to their customers. I believe that usability matters – big time. If users can’t use software, there’s no point in writing it. I think this comes from simply caring about what I do and wanting to do a good job. “Quality is caring,” as Bob Waterman points out.

The experience that I and my colleagues have had in these three companies has led me to boil down good usability into three rules about what really matters most:

1. Perspicuity. Merriam-Webster: “plain to the understanding especially because of clarity and precision of presentation”. Perspicuity in software means making it clear to the user what choices are available to him or her. This was the big improvement of GUIs over command-line interfaces: menus, buttons, radios, and checkboxes let the user know what commands and what choices were available at any given time. The GUI lays it all out.
   
   I often hear people say that such-and-such software “has too many features” which makes it difficult to use, and that the software would be improved by removing features. I rather assume that all the features are useful at one point or another and that removing them would degrade the software, not improve it. The problem that these users are grappling with is that too many choices are laid out on the same level – they have lost the sense of what is more important and what is less. It is unclear how to accomplish a simple straightforward task because there are so many controls for advanced tasks mixed in with the controls for the common tasks.
   
   My colleagues and I have often talked about the perfect user interface, one which appears extremely simple at first glance with just the core functions of the application in evidence. But then, as the user pushes the app and demands more of it, more detail and advanced features seamlessly appear out of the woodwork, as it were.



2. Alignment with personal workflow. This is really important and takes many forms. Generally speaking it is about letting the user move through the software and accomplish his or her tasks in a way that makes sense with how the user works. It means putting the user in control of the flow, and not fighting with them.
   
   Although wizards seem like a good idea on the surface, users often find them very annoying. That’s because they brutally take control of the workflow from the user. This often happens when an app designer is having trouble with perspicuity and feels the need to take the user by the hand to lead him or her through the minefield.
   
   Personal workflow does not refer only to how a user moves through the functions of an application, it also refers to how a user interacts with the controls of the application. For instance, smart parsing is a feature that my users have always enjoyed. My first company’s product was designed for use by currency traders. These folks have a whole specialized lingo to describe their world, and it was important for our app to be able to understand that lingo. For example, if a trader needed to enter a currency type, such as French Franc, into a field, we would let them enter “french”, “franc”, “frank”, “france”, “français”, “paris”, “FF”, or “FRF” into that field, all words that traders commonly used, parse it and then redisplay the value as a standardized “French Franc” to let the user know that what they typed had been understood by the program. The program is operating on the user’s terms.



3. Style. Yes, style. Charisma. If products don’t look good and appeal to users, users won’t feel good about using them. We all like interacting with good-looking things: cars, gadgets, people… I have heard extreme cases where a programmer simply added some color to a drab application, and the users reacted as if the app had been incredibly enhanced. I am a real stickler about this. An app should look sharp. If the correct spacing between two components is 3 pixels, then 2 pixel spacing doesn’t cut it.
   
   People generally like apps that have native OS look & feel, particularly for business apps. They get uneasy if the app doesn’t fit in with the other apps on their desktop. Style deviance can distract the user and force him or her think more about the app than about their task at hand. Having consistent apps for the user’s desktop OS also means that the user will be able to perform basic functions intuitively (cut & paste, get help, etc.). Some core controls, such as drop-downs, can vary surprisingly in how they work in different OSes or different GUI toolkits.
   
   Unfortunately, when we’re under the gun of a tough deadline (and it seems like that is always the case), style considerations are usually the first thing to get ditched. Getting style right actually takes a lot of time. And it seems like a luxury when the heat is on. But if user acceptance is important for your app, it’s no luxury -- it’s a necessity.

Having rules helps, but don’t get me wrong – developing highly usable software is darn hard. My colleagues and I struggle with it all the time. Even with the guidance of rules, the correct path is often difficult to discern, and we find ourselves sweating to make the right decisions. But that sweat is well worth it.

Java vs. .NET, part 1 - Usability

Microsoft has the upper hand on the usability front

This Blog entry is the first in a series in which I plan to analyze the challenges that Microsoft .NET poses for Java and explore ideas for overcoming those challenges.

Many people love to rail against Microsoft products, saying how bad they are. And there is a sense in which this is justified: many Microsoft products are not as robust and scalable as some other products, and perhaps they don’t have all the conveniences for system administrators that other products do (at least they don’t in early versions).

But let’s face the hard facts, folks: Microsoft user applications rule. They are slick, they are sharp, they have tons of great features. Users like them -- overwhelmingly. Here is what one disgruntled CIO had to say about Microsoft product usability vs. that of the Linux community:

McCourtney added: "Microsoft is just more functional and useful. They actually conduct usability studies to see if people can intuitively use their apps. I don't recall any postings on SourceForge in that topic area." And if there are, I'll bet they say something like, "Users are dumb! They don't DESERVE to run Linux!!"

And it’s not just Microsoft applications. It is the Windows operating environment and all the ISVs who natively write to that environment. Microsoft sets the style and the ISVs (to one degree of success or another) follow that style, locking in the Microsoft leadership.

Please pardon me for saying this, but most Java apps look shabby compared with other desktop apps. Java now has a reputation for shabby-looking apps on the client-side. Swing was supposed to address this and has failed. IBM’s SWT comes closer but still hasn’t really challenged native MS technologies on the client. I am encouraged by Alan Williamson’s review of Juliette as a project that takes the UI seriously, but they apparently had to provide their own GUI layer!

There was hope a few years back that the Web would change this equation. The expectation was that all applications would move out of the native environment into the browser, where they would be much more intuitive than that complicated Microsoft stuff, and of course would be powered by server-side Java.

Well, although many apps have moved into the browser, usability issues haunt those Web apps – badly. Many Web app projects have become shelf-ware. The Web architecture has been sold to the CIO (and possibly CFO) as a way to reduce costs and increase flexibility; and the potential for that is real. But there has often been tremendous push-back from users on the sluggishness and low usability of those browser apps. For day-in-day-out usage, users generally prefer the experience of their old client/server or desktop applications. Amy Fowler gives a great example of this for the consumer market. (And by the way, who controls the browser?)

The non-Microsoft camp likes to claim that MSOffice is so popular simply because it is often bundled with new PCs, and there is no doubt that plays a role. But it is also the case that Office and other Microsoft-based apps are very sharp and highly usable for the vast majority of users. We must take product usability very seriously to make inroads against Microsoft domination.

This work is licensed under a Creative Commons License.