Philip Brittan's Blog

Tools Archives

RAD Tool Let-down

Rapid application development tools let you put together a great-looking mock-up of your app in no time, but often are of little use for the production version of your system. Visual GUI builders and data-aware controls are two such culprits.

In yesterday’s post, I mentioned that all too often tools that help developers put out a really quick version of their application are frustrating to use when trying to create a sophisticated production version of the same application. This forces the developer to back-track and gives rise to the concept of the "throw-away" prototype, meaning that any effort put into the prototype has to be chalked up solely for the purpose of getting early feed-back but has to be tossed when it comes time to build the "real" system.

Today I'd like to illustrate what I mean with two very common examples of this phenomenon: visual GUI builders and data-aware controls. I have a love-hate relationship with them both.

By visual GUI builders, I mean WYSIWYG editors for laying out components in an application window. It's great to be able to sit down at a blank project and just start grabbing controls and laying them out on the screen, one after the other, changing positions if you change your mind about the layout, setting properties and seeing those properties immediately reflected in the representation of the window you are building. It is very satisfying to be able to put together a window so quickly, and it is much easier than instantiating all those widgets and setting their properties in code.

However, building the GUI through code does have some big advantages, and, personally, I almost never use a GUI builder for a production application. Here’s why. GUI builders give developers a component-by-component interface onto the window and treat properties as literal values. So, if I want to set the background color of a bunch of my components to red, I have to go and set the background color property of each of those components manually in the GUI builder. And, if I want to change the background color of all those components to something else, say orange, then I have to go through and change them all manually again. The GUI builder gives me a really quick way to put the window together but ends up with a pretty brittle design that requires lots of manual labor to make subsequent changes.

If, on the other hand, I set the background color of those properties in code, I can simply make a variable that represents the background color, set the color properties of those components to the variable, and then set the variable to red. It takes more time to set this up, and it’s a non-visual development process, but my design is now more flexible and I can change the background color of all those components by simply resetting the value of the variable to orange. This is exactly the benefit that Web apps get from CSS, and Joshua Marinacci posted a great article yesterday, CSS and Swing, about how you can achieve similar results to CSS in a Swing app by making a properties file that is read in at run-time. The problem, however, is that this takes you out of the GUI builder and into the code. I want a GUI builder that can handle this for me. Fortunately, many GUI builders generate source code which allows you to take a hybrid approach: use the GUI builder to generate basic component instantiations and properties, and then modify the generated code by hand from there. Still, I wish I didn't have to switch modes -- and that approach is generally a one-way street.

This problem can be more much sophisticated than just setting properties on components. I find that I often want to create bunches of components programmatically, with a loop, reading component specs from a database or config file or based on some algorithm. At that point, even a CSS mechanism can’t help me. I long for a GUL builder that can give me a visual environment to see what my window looks like at all times but to be able to create and manipulate components algorithmically as easily as I can create and manipulate them visually.

I feel similarly about data-aware controls. Manually wiring up GUI controls to database values is admittedly a pain, so data-aware controls are also a great boon in helping developers get a basic version of their app up and running quickly. However, I have rarely written a sophisticated data-driven app where I didn’t need to massage data while reading or writing from/to the database. Hard-wiring controls to the database tends to be pretty brittle. So, once again, for production-quality apps, I have to abandon the data-aware controls for a manual, code-intensive process that gives me the flexibility I need.

I would sorely love to have versions of these tools that can support the flexibility I need for production systems as well as the RAD capabilities I value for prototypes without having to backtrack and change gears along the way. Maybe such things exist, but I haven’t seen them.

ROI of UI Technology

I recently wrote a paper for The SAP Developer Network on user interface technology in the enterprise. I'd like to pull out one small section of that paper for further discussion here:

There are three main factors that affect the ROI of any UI technology: ease of use of the application, ease of deployment and on-going maintenance, and ease of initial development. Based on the total cost associated with each of those factors, they should be assigned the following order of priority:

1. Ease of Use: The usability of an application affects the bottom line of a company every day and that effect is multiplied by the number of users the application has.
   
   
2. Ease of Deployment and Maintenance: The costs associated with the deployment and maintenance of applications affects a company’s bottom line on an occasional but usually repeated and perhaps regular basis. These costs are incurred whenever an application needs to be deployed to new users, upgraded with new features, and have bugs fixed.
   
   
3. Ease of Initial Development: The costs associated with the initial development of a new application affect the bottom line of a company only once per app, and they scale with the number of developers involved, which for the vast majority of applications is far less than the number of users of the application.

The temptations of the immediate gratification of fast initial development can be so strong, in fact, that some UI development tools focus entirely on the ability to put together a good-looking but simple application really quickly. This is valuable for getting early user feedback. However, many of these rapid development systems are ironically difficult and time-consuming for creating sophisticated applications, because of an inherent lack of flexibility. A good UI technology will enable rapid prototyping but won’t do so at the expense of production version development.

Therefore it is imperative that companies apply sufficient discipline in their technology selection and implementation to ensure that an economically correct ordering of priorities is followed.

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

"I wonder when the Java developers will be as happy as the Mickeys"

What do you think about when you write Java?

I recently came across this blog entry, Java vs. .Net developers, in which the blogger, Steve Noel says:

"Mickeys [developers who use Microsoft technology] in general are very happy with the latest new tools thrown at them from Redmond, and very generalized also look slightly happier. Java developers on the other hand have a slightly more weary smile, and especially the open source-addicted ones like to make a lot of fuzz about Sun not doing justice to the great platform that Java is.

Technically, the differences in both software platforms are getting smaller every day. I wonder when the Java developers will be as happy as the Mickeys."

I was talking about the quote above with a guru-class developer friend of mine whom I respect totally and who has extremely deep experience with Microsoft technologies and Java. His immediate reaction, and explanation, was that when he uses Java, he finds himself thinking mostly about the technology itself. And when he uses Microsoft tools, he finds himself thinking mostly about the problem he is trying to solve. Somehow, he believes, Java distracts the developer with a sense of itself and its character, whereas Microsoft technology seems to blend into the environment, almost disappearing, and thus allowing the developer to concentrate more fully on the task at hand.

If this is true, this is a very powerful statement for Microsoft tools. Microsoft hopes to drive developer adoption of .NET by offering a superlative set of tools to make it extremely easy to create Web Services and user applications. Microsoft also offers a rich set of tools to migrate existing Java code to the .NET framework, a perfect “out” for Java developers who become enchanted with .NET. If Java cannot match this, it has yet another hurdle in its fight with .NET.

I have to give Java its due credit. When I used to code in C++, I had to think about memory management all the time. Now, thanks to Java, I don’t think about it any more. What a relief! Java has taken care of that issue for me, so that I can concentrate on my task at hand. Java needs to do much more of this type of complexity-hiding. I presume that this is the goal of Sun’s Project Rave.

.NET on Linux

Could Microsoft co-opt Linux?

I have read a number of articles and blog entries speculating about whether or not .NET will catch hold on Linux and on what it would mean if it did. Much of the speculation centers around whether Microsoft will put out its own version of .NET for Linux, but there is also a lot of discussion of Mono, Ximian’s version of .NET on Linux, which has been released without Microsoft’s participation and is gaining some traction.

Some of the commentators are concerned about the power that .NET on Linux will give to Microsoft, many others think that it would be a victory over Microsoft. To explore this, I’ve been considering the following “thought experiment”. Imagine this timeline:

1. Microsoft releases .NET framework for client and server.
2. Microsoft gets excellent traction with .NET on the client-side (which I firmly believe they will, unless they are more seriously challenged there, as I outline in my Java vs. .NET blog series)
3. Microsoft strongly encourages the adoption of Windows Servers by marketing the synergies between the client and server pieces of .NET, and makes some headway there
4. IBM, Sun, Oracle, and other Java vendors push hard to drive Linux adoption in the marketplace, at which they also make good headway. .NET starts to get some adoption on Linux thanks to Ximian Mono.
5. Then, suddenly, in the face of "customer demand", Microsoft "capitulates" and releases a version of the .NET server framework for Linux. It is not free but inexpensive, and perhaps nets them an amount of money approaching a basic OEM Windows Server license.
6. Microsoft then drives adoption the .NET server framework on Linux using the strong synergy with the large and growing base of .NET client applications, taking share away from Java app servers. Mono is crushed by Microsoft in the process.
7. Microsoft releases the .NET client framework for Linux and a version of Microsoft Office that runs on it.
8. Microsoft ends up owning the developer APIs for Linux, client and server, which is perhaps more important than owning the operating system itself.
9. Since no company owns the Linux kernel or the lower-level Linux APIs on which this .NET for Linux will be built, there is no one to thwart Microsoft’s efforts to control how software is developed on Linux. If Microsoft succeeds in taking control of the developer APIs for Linux, it makes money from Linux’s popularity, and once again there is no one to challenge Microsoft desktops.

Interestingly, Microsoft is already offering a portion of .NET for Mac OS X and FreeBSD. These might well be experiments to test the waters or perhaps simply ways to keep the DOJ calm. What if Microsoft helps BSD compete more effectively against Linux?

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.

Java vs. .NET, part 4 - Java is a language, .NET is not

Java takes a language-specific approach to solving problems, .NET takes a platform-specific one

One of the striking differences between Java and .NET is that Java is, fundamentally, a programming language and .NET is not. .NET is a framework that supports many languages. There has been a lot of identification of C# with .NET, but C# does not equal .NET, and you don’t need to use C# in order to build .NET applications. You can use one of the 20+ other programming languages currently supported by .NET. .NET’s view of the world is from the platform. It is designed from the ground up to leverage specific aspects of the Windows platform to its advantage.

Java, on the other hand, has a language-centric view of the world. Yes, with J2EE, Java has started to create a framework around itself, and extension technologies like Jini and JXTA certainly strengthen Java’s platform, but the way in which Java attacks problems is from a language point of view.

One immediate result of this difference is that it leaves Microsoft with the opportunity to surround Java with other languages. Not only does Microsoft already control the enormously popular Visual Basic and have the ability to make C# very popular, but it can appeal to companies that already have large code-bases in COBOL, C++, Smalltalk, Fortran, and other legacy languages. Java’s answer to those folks is: port your legacy apps to Java or use some kind of awkward connector bridge between the legacy code and Java. It is not natively tolerant of legacy code.

There have been attempts in the past to support other languages with the JVM. Eiffel can compile to Java bytecode. But those efforts have not gained any real support in the Java community. Bertrand Meyer, the creator of Eiffel, writes this in a paper describing his successful efforts to connect Eiffel to .NET:

This ability to mix languages offers great promise for the future of programming languages, as the practical advance of new language designs has been hindered by the library issue: Though you may have conceived the best language in the world, implemented an optimal compiler and provided brilliant tools, you still might not get the users you deserve because you can't match the wealth of reusable components that other languages are able to provide, merely because they've been around longer. Building bridges to these languages helps, but it's an endless effort if you have to do it separately for each one. In recent years, this library compatibility issue may have been the major impediment to the spread of new language ideas, regardless of their intrinsic value. Language interoperability can overturn this obstacle.
….
The language openness of .NET is a welcome relief after the years of incessant Java attempts at language hegemony. For far too long, the Sun camp has preached the One Language doctrine. The field of programming language design has a long, rich history, and there is no credible argument that the alpha and omega of programming, closing off any future evolution, was uttered in Silicon Valley in 1995. Microsoft's .NET breaks this lock.

Everyone will benefit, even the Java community: Now that there's competition again, new constructs are—surprise!—again being considered for Java; one hears noises, for example, about Sun finally introducing genericity sometime in the current millennium. Such are the virtues of openness and competition.

In summary, .NETs multi-language support is another threat to Java. Java needs to blunt this threat. Specifically:

• .NET will surround Java with alternative and legacy-compatible languages. The Java platform needs to become more language neutral while continuing to make Java the best language possible by dynamically incorporating new ideas such as Aspects and built-in support for Web Services.
  
  
• Java's language-specific solutions will isolate it. Make sure technologies mesh with no language assumptions (object layout, data types, calling conventions, runtime context, etc.)
  
  
• .NET as a platform has more hooks into the OS. Java needs to support desktop integration (icons, file linking), which is stuff that happens before any Java code gets run. This is client side, but it's all about what you can deliver end-to-end with Java application code.
  
  
• Deploying server-side J2EE applications is a bear. Java needs platform capabilities to make this much easier. The approach of offering wizards helps, but because they are glued on, they are brittle (hard to change after you’ve gone through the process once) and not compatible between different compilers.

(To be continued. And yes, I am about to offer some hope…)

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"

Paradigm Shifts

Two articles recently got me thinking about the fact that paradigm shifts can be born out of convenience or necessity.

In his post, Another paradigm change is taking place right now..., Michael Nascimento Santos talks about the paradigm shift from Object-Oriented Programming (OOP) to Aspect-Oriented Programming (AOP) that he sees unfolding. AOP has very interesting features that may well advance the way we think about programming.

It got me thinking back to when I was first introduced to C++ and OOP. At the time, my team and I were all hard-core C programmers. We had already stumbled across the need for dynamic data binding and we so we used a lot of void* and function pointers, along with explicit type variables passed around in parallel to the data values, to simulate the effect you get with base classes and dynamic binding. We even implemented our own exception mechanism. That all seems pretty scary looking back on it now, but it actually worked very well in practice (don’t worry, I’m not recommending it).

When we were exposed to OOP via C++, our initial thinking was that C++ was simply a pre-processor on C that added some features that we had already implemented anyway in straight C, and that the main effect of C++ was to bloat and slow down our ripping fast code. And so we spurned it for a while.

But the industry moved forward and C++ became more widely adopted, and eventually we too started using it seriously. Once we did that, we quickly came to realize that the really interesting part of OOP is not in the specific mechanics of classes, inheritance, polymorphism, etc., but rather in the fact that it gives you a whole new way of thinking about software design and development. Once our minds had made the shift to the OOP way of thinking, there was no turning back. Today, it’s difficult for me to conceive of sitting down to write an application of any complexity using a non-OOP language. So the paradigm shift I experienced with C++ was much subtler but much more powerful than what I had initially imagined, and it took a while to sink in. This was a paradigm shift of ‘convenience’ – we could write software without OOP, but OOP gave us a better way to do it that opened up all sorts of possibilities.

There are also paradigm shifts of ‘necessity’. Water rising in a reservoir is going to experience a sudden paradigm shift when it starts overflowing the dam. The second article I read recently states that if China achieves the growth in individual personal wealth and standard of living that it projects to by 2020, the world’s natural resources would not be able to sustain it. For instance, if every person in China owned a car, the way that every American (on average) does, we would immediately exhaust the Earth’s supplies of metal and oil. If this is true, and accepting for the moment that China actually can reach that standard of living, then it’s clear that a major paradigm shift will have to take place. Either people in 2020 (in the US and Europe as well as in China) won’t have nearly as many cars as they do today, even if they have the same level of personal wealth, or we will have a completely different conception of what a car is. It will have to be something that does not consume metal and oil the way they do today.

So sometimes paradigm shifts take place because they provide excellent marginal benefits, sometimes they take place because there is no other way to address a looming problem.

Java vs. .NET, part 2 - The Nature of the Beast

What is Microsoft trying to do?

Microsoft is the uncontested champion of the desktop. In the business world, they own essentially the entire client-side market. This is a huge advantage for them. But it is also a limitation. In order to fuel its growth, Microsoft must find new, less-tapped-out markets to go after. The server room is one such market. Microsoft is already strong there, but they still have a lot of share to grow into, and it is a lucrative market.

In my previous post in this series, I claimed that Microsoft has the upper hand when it comes to the quality of the user experience. Microsoft’s user experience leadership is completely bound up with their domination of the desktop. It makes sense for Microsoft to use their hegemony on the desktop to their advantage. The client PC is their solid base, and .NET is the lever to get back to the target. .NET is an expansive strategy with many interlocking parts, and these parts come into play at various stages in Microsoft’s siege of the server room.

The UI layer of .NET is the tip of Microsoft’s spear. Microsoft leverages its usability advantage, combined with its very strong tools offering, to convince developers to adopt .NET as their platform for application development and deployment. .NET apps are delivered either as ASP.NET Web pages or as managed CLR fat clients. The thing is, in order to deploy and power .NET apps on the client or in the browser, you really need to install Windows servers, preferably Windows Server 2003 (formerly known as Windows .NET Server), in the server room. Ideally, you’ll also finally upgrade to XP on the desktops to boot!

From there, Microsoft uses the expansiveness of the .NET strategy to push out Oracle in favor of SQL Server and gets companies to install BizTalk and other Microsoft server technologies. The fact that so many companies already rely on Exchange for email helps in this. Microsoft will demonstrate the power and ease of using a pre-integrated stack from a single vendor to get customers to adopt more and more of their technology.

This is the threat that non-Microsoft vendors and the whole Java community faces. This plan is ambitious, but it is by no means easy, even for a company with the resources and advantages of Microsoft. Its success hinges largely on Microsoft’s ability to convince developers to adopt .NET. Therefore, the Java community’s challenge is to keep the tip of Microsoft’s spear from getting in by convincing developers and sys admins (and the companies that employ them) that Java has a more compelling answer for applications delivery than .NET.

(to be continued)

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.

No More Programmers

I hear that Macromedia Flash is going to alleviate the burden of having programmers. I’ve been hearing for the past two decades about how this or that new software development system was going to allow business users or designers to create software, and therefore companies wouldn’t have to employ expensive programmers. As a further benefit, IT would be much more responsive because users would just create what they wanted on the fly without having to wait for developers to come get requirements, do design, code, test, refactor, code and test again, etc. (or maybe nerds are just unpopular).

There have been a number of visual languages that have promised this but none of them has gained widespread usage. Sun has even announced something in this category, and it appears that some folks are moving beyond visual programming into audio debugging. I have a friend who left the software development world entirely to go get an MBA and become a banker because he thought that Microsoft Access would allow business types to create their own software and therefore put an end to the profession of programmer – that was 7 years ago. The Web was supposed to allow graphic designers to easily create on-line applications without gorpy tech skills. Guess what happened?

The flaw with the programmer-less vision is that building software involves a lot more than the memorization of programming languages. Any experienced developer knows that learning new languages is not hard. The hard part is understanding how to design software (and I don’t mean just the graphics) and how to use whatever tools are available to create systems that solve the right problems, and that are robust, scalable, and maintainable. Learning how to dip your brush in the paint is the least part of being an artist.

This work is licensed under a Creative Commons License.