Back to book outline
Brainstorming on BuckyWorks
Chapter 8: The User Interface
by Kirby Urner

A dwelling utility with Java-enabled appliances and environment controls would need control panels from whence users could manually override and otherwise manipulate any user-inputs. A cost-effective approach to panel design uses HTML-embedded Java applets, which allows for easy reformatting and customization of controls according to well-known standards, while providing continuity with remote-server accessibility. Tech support could easily call up a troublesome page and help operators debug various problems. Java's security features will keep the dwelling's environment controls from being meddled with by unwelcome intruders, even at times when certain controls may have been made accessible, for debugging or discussion purposes.

Of course HTML is good for embedding more than simply Java. A Windows-based pod might tie the coffee-maker, air conditioning, light depolorizers (variable-light windows), solar collectors, battery units etc. to custom applications with an OLE link to HTML front ends. The reason for favoring Java might be the pedigree of the Java language: it originally grew up in a device-controlling context (but then so did C, or even ADA for that matter). There's nothing to keep an operator from gathering her own favorite devices and drivers and writing controlling language in Visual FoxPro, for example. Here, the devices themselves will be 'black boxes' concealed in wrapper classes, with the user's native language cementing the devices in a common database table-driven environment, which may be ideal for some applications (our dwelling units are not uniformly deployed, we must keep reiterating -- it's not useful to overspecialize the dwelling unit concept when giving broad parameterizations regarding their internals).

In any case, the central schematic is of user-controllable electronics with automatic features, based on various optimization schemes, including fuzzy logic. Especially with regard to environment controls, where counterproductive heating and cooling strategies can gobble precious wattage, taking away from the other electronics, optimization is critical.

The downloading dish (or other device) will allow operators in the field to try out the most robust beta and commercial device driver suites, which will be tied into the dwelling's other parameter sets (e.g. battery level, collector efficiency, insulation rating etc. -- both constant and variable settings) to provide optimized ways of providing comfort amidst a unique, customizable ensemble of trade-offs and constraints.

The village model brings a new level of VLSI to the picture, with a central server keeping tabs on numerous workspace-level stats, while having central responsibility for shared resource and energy harvesting equipment (e.g. the communal solar farm and hydrogen-by-electrolysis fuel harvesting plant).

Village-level software needs to accommodate both long and short term needs, e.g. building up the hydrogen supply during off-peak usage periods. Villages with power-feed respons- ibilities, e.g. those tending micro-hydel or other energy- source inputs to a more central grid, will likewise use control panelling on a more central server to balance village needs with export/trade formulas negotiated over time, used to bring in various currencies and credits required for accessing remote hosts (which might be other villages, institutions of higher learning, or corporate inventories).

Whether Java comprises the low-level device driving language for all of these dwelling unit and village level applications is not an issue to speculate about: people with strong competence in whatever device-control language will be in a position to bundle useful tools with software controls and a well-defined parameter set (output readouts) plus API (callable routines). Middle-ware can get between the device API-readouts and the user, sometimes hiding low-level device controls in Java wrapper classes or some other language more familiar to the end user.

The market needs to keep the space for user-intervention wide open, as many of the operators who download new controllers will also be in the business of writing the next generation and need to be allowed into whatever internals have relevance to their task, provided they have the requisite training (test modeling requires relatively little training, but software bound for FTP sites and the general public will have to go through stringent testing, meaning its developers will retreat to the drawing boards numerous times in any typical scenario where total quality management practices are in effect).

Prototyping of cooling controls in the Arizona desert can be uncomfortable work for those field-testing next year's model, but the work is interesting, and we'll presume last year's Airstream in the background, with its clunky, inefficient air conditioning, available as a fall-back.

The after market here envisioned parallels the desktop computer industry in that hardware is sold bundled with device driving software and documentation. The higher end hardware has EPROM or other FLASH-type memory allowing as much of the device driving as is practical to remain at the software level, hardware electronics phasing in only at the level where dedicated mechanics are required to optimize performance (where speed and throughput considerations usually predominate). Since changes to the API will have ripple effects when devices are embedded in the local ecology, upgrade paths must be well signed. Users who download a new driver for their coffee-maker need to be clearly warned if the ON switch has been coupled with a self-turnoff default or of any other bell/whistle that, if not documented, might result in cold coffee at 6 AM, or worse.

Most standard configurations of dwelling machine will be leased with preinstalled drivers all known to be well-behaved and compatible with one another, and the models used to control these devices will be standardized around a few simple concepts. The fine tuning and super-optimization experiments resulting in highly efficient designs for desert living and so on, will be part of the after market, with standard unit vendors having the option to enter into this field or not, depending on a host of factors. A vendor based in a harsh environment, like Siberia, had better provide robust heat control ensembles or go out of business. But this vendor may rely on distant sources for its Siberia-rated hardware/software (Nordic input is likely on this front).

Whereas the standard model has internal climate-control and internet/intranet capabilities, specialized models will add or subtract features as needed. One of the more specialized add-ons is the pneumatic VR workstation, which supports the user on a spatially adjustable platform, usually a chair, where tilt and roll are software-linked to the display (either in-helmet or on screen).

Some kinds of development work, either for the entertainment industry, flight, submarine or terrain vehicle simulation, require such pneumatic (or other servo-mechanism) controls for realism. Pods which combine such features with standard kitchenette, head, studio, and sleep space will be prone to their own brand of problem. Tech support for VR requires a special breed of remote user, willing to patch in to an operators problem VR program and feel the buck-and-twist of Mr. Toad's Wild Ride through some wild simulation. In special situations, crash dummies should be substituted for the flesh and blood user.

Back to book outline