Pinderkent

A public beta of Windows 7 was made recently, and one area that has seen some change is the Taskbar. Not everybody is happy with these changes, either. One article that I read focused on how it's difficult to tell which applications are running, and which are not. I have to agree with the points that were made there. It really isn't immediately obvious which items on the Taskbar represent executing programs, and which are just icons to start the applications.

One of the commenters to that article, going by the name technology, suggested at 3:04 PM that it doesn't matter if one can tell whether or not a given application is running: In the majority of use cases, what does it matter if a program is running or not? If I want to browse the internet I click on the Firefox icon. If I want to check my mail I click on the Outlook icon.

I have to disagree very much with this stance. Not everyone starts an application, uses it, and then closes it once done for the time being. Myself, and many others, start an application, use it, let it continue to run while we move on to some other task, come back to the application sometime later, use it some more, move on to another task, and so forth.

I may have several different instances of PowerShell or cmd.exe open at one time. Depending on the task, they might have been changed to different working directories. Some may have also had certain environment variables set. What I don't want to be doing is starting up a new instance of say cmd.exe, when an existing instance has already been adjusted to allow me to perform a certain task.

I would like to see Microsoft make some changes here. It needs to be clear to users which icons represent applications that are currently executing, and which are icons that can be used to start a new process for a given application. Starting new processes and managing existing ones is a core aspect of using a desktop environment. Mistakes here can have significant productivity impacts for the desktop environment's users.

Today I was reading about the "Reduced Functionality" capability of Windows Vista. According to that article, Microsoft has now enabled this capability, which renders a "nongenuine" copy of Windows essentially unusable.

Frankly, I just can't see why anybody would want to use Windows Vista. I'm sure the questionable nature of this sort of functionality is quite obvious to most. And it's also pretty obvious how the misidentification of an installation as being "nongenuine" could be quite disasterous. A completely legitimate installation of Vista locking up accidentally because of such functionality could cost an individual or business a great deal of time and money.

Beyond that, we have readily-available, high-quality alternative operating systems that don't bother with such nonsense. These days, Ubuntu provides a very usable desktop or workstation OS. There are other Linux distributions that are more suited for server-oriented tasks. FreeBSD is another alternative for desktop/workstation and server usage. Of course, there are also NetBSD, OpenBSD, and DragonFly BSD. And we can't forget OpenSolaris.

Using such systems is just the safest thing to do. First of all, you get access to virtually all of the software used on such a system. Even if you have no interest in modifying or redistributing it, having the code available allows for inspection, should that be necessary.

The redistribution of such software is usually allowed, and often encouraged. With ISO images typically available for (free) download from the distribution or project itself, one has to worry little about accidentally obtaining pirated software.

And in terms of functionality, the essentials are all there. For many people, the transition would be quite easy. Those who use software like Firefox and OpenOffice.org on Windows could immediately use those same products on Linux, BSD or OpenSolaris.

The hardware support Linux offers today is excellent. For the past few years, I've encountered far more hardware supported out-of-the-box by Linux than I have with the Windows installations I have performed. The need for installing a separate driver is often nil.

So when it comes down to it, it really just doesn't make much sense why any person or organization would subject themselves to Windows Vista. The benefits just aren't there, and the dangers appear to be many. And what's more, there are free alternatives out there that can perform the same tasks just as well, if not better. It's really a no-brainer: Linux, OpenSolaris and/or BSD is the way to go!

One computing myth we hear quite often is that of Microsoft Windows offering a "common UI". That is, one toolkit or framework that is used by all applications, thus giving an experience that is well-integrated and shared. But anyone who has used Windows recently should know that this is clearly not the case.

Some programs offer theming of skinning support. Programs like Winamp, Mozilla Seamonkey and Mozilla Firefox fall into this category. Although they offer themes that mimic the appearance of other Windows applications, there are usually slight differences that aren't always obvious, but are noticeable.

Then take programs from Apple, like iTunes and Safari. The Windows versions of these programs clearly draw much more from their Mac OS or Mac OS X heritage than from Windows. In the case of Safari, you might as well consider yourself as using a Mac. Not only are the UI components completely different from that of virtually all other Windows programs, but they even go so far as to override the title bar at the top of the window.

We can't forget Java, specifically Swing. Although Sun has put a lot of effort into their Windows look-and-feel, a number of Swing-based Java applications use the cross-platform "Metal" look-and-feel. Thus they do not appear similar to other Windows applications in many cases.

Finally, we can't forget that even Microsoft makes radical changes to the UI quite frequently. The appearance of Office 2007 clearly deviates from most other software available for Windows, especially past versions of Office. Likewise, the UI for Internet Explorer 7 changed quite significantly, compared to previous versions of IE. But even between IE7 and Office 2007, there's relatively little UI commonality, especially when compared to past releases of those products.

So before suggesting that the Open Source community should decide on a single GUI toolkit to match the supposed "common UI experience" on Windows, realize that such an experience just doesn't exist. Windows suffers from as much UI fragmentation today as does a typical Linux distribution. Some of this fragmentation has even been caused by Microsoft itself, with some of their most popular products. The idea that a common UI exists on Windows is nothing but a myth.

Today I shared the experience a friend had with one of the companies he works with. It involved a failed transition from what was mainly a console-based suite of applications powered by Sun systems and Oracle, to an AJAX and Web-based system running on Windows, .NET and SQL Server. It seems that that entry was submitted to Reddit, and so I've been reading some of the comments that were left there.

Some of the comments were quite insightful. But there were two that I found to be just plain funny! Here is the first comment, and here is the second comment.

In those comments I am accused of being "biased against windows and ajax" and guilty of "discrimination against Windows & dot-Net". Well, I would like to address those allegations!

First of all, I've been doing this long enough to not get to attached to certain products or technologies. In the end, it's all about solutions that work to solve the client's problems in an efficient and financially-sound way. I'm glad that I get to mostly work with Solaris, HP-UX, AiX, FreeBSD, Linux and other UNIX-like systems. But I've worked with Windows many times before. As long as the job gets done properly, I really don't care what software is being used.

In this case, my feelings regarding Windows, .NET and SQL Server have absolutely no impact on the problems that that company experienced with their transition. Beyond hearing about it from my friend, I had no involvement with the development of the old system, nor any involvement with the development of the new system.

Furthermore, the fact remains that the old, UNIX- and Oracle-based system worked just fine. The new .NET-based system did not work in a suitable manner. Pointing out that certain software did not perform in an adequate fashion in a certain situation does not indicate bias. All it indicates is that the software in question was not capable of performing what needed to be done.

Likewise, the AJAX-based UI proved inefficient compared to the previous curses-based interface. That's just how things worked out. Again, my feelings, thoughts or biases would have had absolutely no impact on the situation, as I was not involved.

I do thank the two comment authors for their thoughts and opinions. However, I also urge them to be more careful in the future when accusing others of bias. Just because a particular technology fails to work in a particular situation, and this failure becomes a topic of discussion, there is not necessarily bias against that technology. Sometimes technology fails. We must admit this, and learn from such failures.

Last night at the pub, a friend and colleague of mine was telling me of a recent experience he had at a company he was doing some IT work for. I think the lesson learned is a very important one, and thus I wish to share it. But first I'll describe the situation he encountered.

In the mid-1990s, the company in question built their IT operations around systems from Sun. They wrote much of their in-house code using C++, and used Oracle for their database needs. On the front-end, they used PCs running a mix of Windows NT 3.51, FreeBSD 2.x, and even OS/2, depending on the department. While that is not a unique setup by any means, what is somewhat unique is that they essentially continued to use those same systems up until 2006.

One of the main reasons why they didn't switch is because their software systems worked just fine, even if the UIs were somewhat archaic. Their software was mature and well-understood by the company's employees. They even got extremely lucky in the first place, as the developers who initially designed and implemented their software systems did so in a way that allowed for the systems to easily scale as the need arose over time.

The hardware proved to be the main instigator of change. After a decade, many of the front-end PCs they were using started to exhibit a variety of physical problems. Some had been replaced earlier, but eventually it was decided to replace them all with newer systems. However, to the best of my friend's knowledge, the back-end Sun systems were working just fine.

However, at the same time they decided to also replace the back-end systems. A variety of consultants were apparently called in to appraise the situation. For whatever reason, it was eventually decided that the new back-end systems would be built around Windows Server 2003 and SQL Server 2005. The new back-end software was to be built upon .NET, while Web-based client-side apps would be developed and used. My friend wasn't sure exactly when this effort started, but he believed it was in early 2006.

By the end of 2006, the consultants and developers deemed the new system ready to go. Over the course of the December 2006 holidays, the new systems were rolled out. It turned out to be a pretty major disaster. The first problem they ran into was a complete lack of performance. As they moved into the first weeks of 2007, their back-end systems just wouldn't scale. As an emergency fix, they ended up throwing more hardware at the problem, which did ease the burden on the existing servers somewhat. But it was in no means a permanent solution.

The front-end software systems proved to be an even bigger disaster. Many of the AJAX-based applications used Internet Explorer-specific functionality. But the IT managers of some of the front-end networks would not allow IE to be used, for security reasons. They only allowed for Firefox to be used. So the Web-based front-end software needed significant modifications right away, as well.

What was perhaps the worst failure involved the in-house users and their productivity. Large portions of the old system were built around a curses-based UI. Although it apparently wasn't very pretty, it did allow for a great deal of user productivity. One of the main complaints about the new Web-based software was that the keyboard support was quite poor, requiring the user to select input fields using the mouse, and at times even having to scroll the page to input or manipulate certain data. With the earlier system, the navigation could rapidly be performed using just the keyboard. Some of the more experienced users were apparently so efficient with the older system that their productivity was reduced to 25% of what it was before the switch.

My friend and his colleagues were called in to try to remedy the situation as best they could. The company was not willing to invest in a completely new system, but instead insisted that the old system be brought to a usable, if not optimal, state. The work is still on-going, as we speak, five months later.

There are many lessons to be learned here. The one my friend emphasized the most was that it's often a good idea to leave existing systems as they are. What they had worked, for the most part. The problems they experienced with their front-end hardware could have been easily dealt with by buying new PC systems. But the decision to replace their working server hardware, and to rewrite their existing (and well-functioning) back-end software, were obviously terrible ones. The use of AJAX and Web-based software for their front-end systems was also a poor idea.

I think some of the other major lessons are as follows:

• Use mature, well-tested, effective software (eg. Solaris, Oracle, FreeBSD).
• Avoid immature fad "technologies" like AJAX.
• Traditional applications offer more flexibility than Web-based applications.
• Always give much consideration to back-end scalability.
• Sometimes a text-based interface is far more efficient than a GUI.
• Get user feedback on software early and often.
• Maintain a reasonable level of heterogeneity, when it comes to software, hardware and vendors.

Hopefully we can all learn from these lessons made obvious by this situation. Although given my years of experience, somehow I think that won't be the case.