Philip Brittan's Blog

Swing 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.

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.

ASP.NET and Smart Clients

Microsoft makes money from Windows desktops, not from browsers

In response to the the latest installment of my Java vs. .Net series, a number of you responded with a focus on ASP.NET. ASP.NET is Microsoft's way of delivering browser-based DHTML applications.

Yes, ASP.NET is an important part of .NET, but I actually do not think that Microsoft is interested in promoting browser-based DHTML clients very heavily. Strategically, they need to continue to lock in Windows on the desktop, and fat clients are the strongest way to do that.

I believe that Microsoft's main strategic thrust will be around "Smart Clients". Smart Clients are .NET fat clients that rely on Web Services (served up by Windows Servers) and that can be trickeled to the client machine byte-by-byte (by Windows Servers), to make installation much more seamless to the end user. But they are still locally-installed Win32 applications.

Usability will be a primary driver for Microsoft to promote Smart Clients. Usability doesn't just mean the quality of the GUI or the richness of the controls (although those are very important). It also includes the ability to interact with other applications on the desktop (a big problem for browser-based apps) to provide an overall superior user experience (anyone remember the "Are you experienced?" campaign?).

Here is an excerpt from a newsletter that Microsoft sent around to ISVs this morning:

"ISVs: Get Ready to Deliver Smart Client Applications The Smart Client Readiness Program for ISVs gives you the software, tools, and technical resources you need to start building smart client applications. If your customers aren't asking for them yet, they will soon see the need for the next generation of anywhere, anytime data access. Enroll in the program today! http://go.microsoft.com/?linkid=215945"

Docs >> Forms >> Apps

There is a natural evolution of platform technologies from document publishing to forms processing to application delivery. The Web is the leading example of this, but Adobe Acrobat PDF and Microsoft InfoPath are on their way.

The W3C has finally published its specification for XForms 1.0, after much delay and without the participation of Microsoft (not surprisingly). XForms is intended to make Web-based forms more usable by doing a better job of separating data values from form description and supporting cascading style sheets. The main benefit of these improvements is to make forms more reusable and easier to change and maintain with less re-coding.

There is an interesting evolution of platform technologies that start out as simple document publication frameworks (displaying read-only text and graphics to users), then, presumably under pressure from users, these platforms get extended to support forms (meaning that users can enter data which is then written back to a database on the server). The next logical step is to make these forms increasingly dynamic until they come to resemble full-fledged application delivery platforms.

This is exactly the evolution that the Web itself has undergone over the past 10 years. Most people agree that the Web does a fine job for publishing documents -- the truly revolutionary paradigm shift that the Web has delivered to date has been allowing all businesses to have universally accessible marketing materials on-line and to let anyone in the world do research through Google rather than the much, much more tedious means available before the Web. Web forms have allowed e-commerce to start to get a firm foothold. But Web technology is not as strong at forms processing as it is at doc publishing, as evidenced by the need for XForms at all. In the past few years, companies have tried hard to shoehorn full-blow applications into browsers using Web technologies, but these efforts have had very mixed results. Many vendors and standards groups have come out with a large stack of add-on technologies designed to patch up the problems that HTTP/HTML present for application developers. Other companies, like my own, have tried to rethink the application delivery problem from the ground up.

Now both Adobe and Microsoft are headed down the same road with the new forms-processing capabilities in Acrobat and XDocs/InfoPath. The question on everyone’s tongue now is how these products will compete with each other. A deeper question is how they will compete with HTML/XForms and whether they will indeed progress towards being full application delivery platforms.

It seems that there is market pressure for a platform to provide a continuum of capabilities from document publishing to application delivery. Maybe docs, forms, and apps are really all meant to be the same thing. But how we’ll achieve that is still far from clear.

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.