Defenestration 101.01
Over the next little while, I am going to write about how you can reduce your dependence on closed source, proprietary software. I call this series Defenestration 101. I learned the word “defenestration” in high school. Defenestration is the act of throwing someone out a window, but it can also describe a rapid expulsion of a person from a group or organization.
I encountered the word again a few years ago when it was used to describe the process of getting rid of Windows servers and moving to Linux or Unix base servers. Apart from anything else, I was amused by the recursive humor of throwing Windows® out of a window.
All humor aside, it is possible to run a business without using Microsoft’s closed source, proprietary software. In series of blog entries, I am hoping to explain how I handled this change in my home and business, and explain why one would want to.
First, let me start by saying nice things about Microsoft. Twenty years ago, I built my career on Microsoft products. Back then, Microsoft published great books on the products I used and they maintained a BBS where I could download code samples and white papers. I bought Quick Basic and Quick C, and started to write programs at work, helping my employer use computers in new ways.
I was helped decision makers select software packages – basically, I cut my teeth on Microsoft products. However, by the mid to late ninties, the price of Microsoft products started to rise. One client put a project on hold because he had to upgrade to NT. In time, I could see that Microsoft was eating up a large part of the budgets that used to be available to pay me.
I also saw opportunities. There were more developers, more projects, more books, and more magazines. Selling clients on using computers was not longer a challenge – every business had computers. I had a chance to travel, and to dig into some challenging projects. For a while, I ran a company called Workflow Automation Group in Vancouver, and I can not say anything bad about that time.
Even today, there are many good reason to use Microsoft solutions. However, the world has changed, and there are alternatives. Count me as one of the many who have chosen to embrace these alternatives. This week I will explain why.
I will try to be pragmatic rather than idiological. In all probability, your business is not software. The problems you are trying to solve are not technilogical. For you, technology is a means not an end. I get that.
Stop Using Ajax! (Not 2.0)
. . . and I have more to say about the use of AJAX!
Often, I am called in to work on a web application that has existed for a long while. The application may suffer from poor usability as well as inaccessibility. My job may be to extend the functionality by constructing a new component. However, even after I have done my work, large parts of the application remain as they were.
In these cases, not matter what I do, the application will remain inaccessible to some users. In such a case, I use AJAX with no compunction. I can improve the usability and responsiveness of an application immeasurably.
The government of Canada has hundreds of applications that are used every day by civil servants across the country. These applications were developed using old style ASP – or straight JSP running on Tomcat – and old style HTML. Many of these applications do not use CSS at all. Often, they can only be viewed using IE. (Many departments still use IE 6.) Yet these applications represent an investment of hundreds of thousands or millions of dollars each, plus training and maintenance.
What’s more, many of these applications were build by people who knew how to build web pages but did not understand how to build applications. I am not blaming anyone. It is what it is. These applications can be confusing, if only because each developer was reinventing the wheel.
By introducing tab controls, short-cut keys and and accordion controls, I reduce the cost of training and support, and deliver a user experience that takes advantage of what people already know about using the typical desktop application. By refreshing sections of the page selectively rather than reloading the whole page, I can avoid breaking the concentration and flow of the user. This is not a bad thing.
Don’t get me wrong. The Government of Canada takes accessibility seriously. Check out the guidelines I need to be familiar with. Still, you have to know that I often work with applications that were build long before these guidelines were devised. The work may take a while.
AJAX has its place. I might even suggest that the GOL guidelines I refer to above could be expanded or amended to include web applications. The web application is a different beast. It is not a web page, or a site composed of a series of pages. The so-called “page” is a bad metaphor. There should be a separate standard for the common look and feel of web applications used by the government of Canada, but that’s another issue.
The Importance of Web Site Design
I like a nice looking web site, and I especially like well designed web applications. The feedback I get from clients is that my applications are very easy to use. Many people say they look nice.
Having said that, I find that making things look nice is a lot of work. Some aspects of CSS, HTML and JavaScript are fussy. The simplest things can take more time than you would imagine. Especially for me – my strengths are in working with the database, and in designing and writing the backend components.
I often judge companies by their web sites. If a site is not graphically pleasing, or if it is not easy to use, I am likely to be less interested the product’s and services that are offered on the site. However, I am quickly realizing that some people do well by providing usability alone.
Here is an example: the Hwaki site. If there ever was a web page that promised nothing in an age of glitter and glitz, this is the page. Right? It might surprise you to know that this company develops, supports and maintains a product which may be the most widely deployed SQL database in the world.
It would be interesting to find other examples of successful companies that have plain, or even ugly, web sites. It would help us better understand success.