Flawed Efficiency

Since the arrival of graphically-interfaced operating systems the promise has been timely capability to complete tasks and increased efficiency through the facile manipulation of "windowed" functionality. This is all well and good in most cases.

But when subtleties of behavior are not implied in the interface, not handled explicitly, or not communicated so that the user is aware that he or she must deal with them, we find ourselves on a slippery slope. The features of the operating system can become a hindrance to getting the job done.

Last week, I was setting up a server to use as a development environment. Because remote access to the server was a requirement I installed a copy of RealVNC on the newly-minted XP box. I configured the software to allow access to the IP addresses on the subnet our machines reside under. I then tried testing connecting with the VNC client from my laptop. It kept timing out without connecting. I rechecked the configuration; opened Windows XP Firewall settings and made sure that RealVNC application was listed in the Exceptions tab and pointing to the correct executable.

Retested connecting and still no cigar. I tried several more passes, becoming anxious that such a simple task was consuming so much of the day. I searched online to see if the error I was getting had been encountered and if a solution might be listed. I found some documentation mentioning that upgrades of RealVNC which did not import certain settings could be listening on the wrong port; but confirmed that in fact my installation's configuration had the correct port. I pulled out the heavy guns and went command line, invoking netstat to see what connections were at play. Finally after the day was halfway over, I realized that the XP Firewall might not be interpreting what port the application was intended to run on. My expectation, which I don't believe was farfetched, was that if I add something to the Exceptions tab, XP would use the configuration settings to direct access.

And that was the mistake. The Firewall actually requires that you explicitly make a separate port declaration in addition to the application one already in existence, and besides the naming label there is no specific tie between the two. Once I did that things went without a hitch. However, I found myself wondering what would possess anyone to design a firewall which did not require that pervious points be bounded with the application?

Something as inconsequential as a port number can have wide-ranging impact. That I had to scale the walls of XP, scouring for a foothold to achieve realization of a temporally significant assignment, does illustrate that how a user utilizes a tool is as important in design consideration as the physical elegance of the interface.

Now I am sure there are more hills to climb before I find the Valley of Hallowed Bliss, where interface and design dovetail and dance a sprightly flamenco in syncopated, coordinated steps. I just hope I have enough hooks to sustain me on the trek.