Monday, November 5, 2012

Upgrading software

Briefly, upgrade your software only when you want to take advantage of new features or security/stability fixes. That seems obvious, but a lot of people (especially people new to the idea of maintaining a software system) still think that "bleeding-edge" is the way to go, when that just isn't the case. There's nothing to be gained by putting your system in an unstable state at a whim or for the vacuous accomplishment of having the newest thing.

Furthermore, when you do upgrade your software, make sure you have a path back to the previous version so that if something doesn't work well with your system (and there will definitely be times this happens), you can revert without too much hassle. Too many times have I made some install that didn't have a sane un-install procedure--files flying all over the file system, and the only record of where they were supposed to go in a binary executable. Yuck. Avoid using binary executables for setup when you can and it'll save you trouble. And for god's sake, don't make them for your software, but make an install shell script if it wouldn't inconvenience your users. Sure theres the problem of platform incompatibility that comes with that approach, but that's true in any cross-platform system, and there are other ways of dealing with those problems.

Remember, remember the 5th of November...(tee hee)

Saturday, November 3, 2012

Adaptive UX

Adaptive user interfaces (AUI) attempt to change to better suit their users. They typically start in some default state defined by the system designer. A user gradually adapts the interface to himself through a negotiation process undertaken during software usage. My first impulse is to reject this sort of interface for lacking consistency, but let's make a brief listing of the requirements for an adaptive UI in a multi-user system. (The multi-user stipulation is aspirational, but presents some considerations that must be made even in single user systems)

Mainly, my concern with this type of interface is that it doesn't allow for users from one instantiation of the system to use another without recalling to himself the initial set-up for the system. That kind of hiccup may only come up with multi-user systems and public terminals, but I think it would be useful for, say, the military to be able to switch out systems without the users needing to retrain the systems to their particular set of optimizations and preferences. There's also the consideration of establishing a common interface between systems. If each user can change the interface dramatically, there's no hope of standardization. Of course, we can say that each system has its own idioms and should be open to specialization for that system; however, for a class of systems that I'm interested in which may be called "general purpose" there is a great potential for making all uses of the system intuitive with a minimum of training. That is my goal anyway: to accelerate the rate at which we can come upon unfamiliar systems and become adept at manipulating them, removing many of the crude attempts at personalization and real-world analogy that plagued interfaces in the '90s and 2000s when computer use became more widespread.

Friday, November 2, 2012

$300 prosthetic arm