Who cares about user interfaces? (by alaric)
Developing user interfaces to software systems is incredibly rewarding.
If your software system has a user interface at all - and most do, even if it's just for service engineers - then interacting with a human is, presumably, part of its function. And since humans generally pay the bills or otherwise reward and motivate the development of software, I'd hazard a guess that whatever interaction your system has with the user might be the most important thing it does. So having a poor user interface might well mean that whatever else is wonderful about your software is meaningless, because nobody can use it.
I think I first became aware of the "user interface" as a thing in its own right from a pretty young age. I had a ZX Spectrum, and for Christmas or a birthday one year I was given an AMX Mouse; and while a point-and-click graphical user interface is just one kind of user interface - and I'd been writing software with command-line or joystick/keyboard-based graphical interfaces until that point - mice encouraged a more object-oriented style of user interface, where one clicked on objects onscreen and dragged things around and opened contextual menus to perform operations on a selected object and so on. This sort of thing required more software infrastructure than simpler interfaces, and implied the development of cross-application conventions, and with resizable windows even opened the door to having multiple applications on the same screen - all of which pointed towards there being a dedicated piece of software that was "the graphical user interface", which applications were clients of; unlike the kind of user interface development I'd been doing before, which was just putting stuff on the screen and asking the user occasional questions with prompts or responding to button presses. And around that point in history, the Apple Mac was taking off, things like GEM were starting to appear, and so on. This was pre Internet-at-home, but books on these topics were appearing in my local library, and articles on fancy new GUI computers appeared in computer magazines, so I at least had pictures of them to look at; and the AMX mouse came with some basic GUI widget primitives in its ROM.
The idea of being able to write applications with access to things like on-screen draggable objects, menus, and windows, rather than needing to code everything in terms of pixels and mouse clicks from scratch, certainly appealed. So I attempted to write a multitasking graphical interface for the 48k ZX Spectrum+. In BASIC.
Needless to say, I never got it working. My plan was to support two running applications, each given half of the screen (left or right), with a menu bar along the top that would change based on the context, Apple Mac style. I had a snippet of machine code from a magazine that would renumber ranges of lines in Spectrum BASIC programs (including patching the GOTOs and GOSUBs to reference the changed lines), so I developed a scheme whereby the GUI would be contained in lines 0-999, apps would be written and saved to tape to load into lines 1000-1999, then the system would renumber them into either 2000-2999 for the left hand app or 3000-3999 for the right hand app after loading. Each app would have an entry point at their first line (2000 or 3000) that the system would GOSUB to with variables set to ask the app to respond to some event - initial drawing of the app's screen, a keypress while the app was selected, a mouse movement inside the app's side of the screen, a menu selection for the app, or the app being unloaded. The app, in turn, could GOSUB to some fixed line in the GUI itself to update the app's menu bar (which the GUI managed for it, adding its own system menu with options to load/unload apps).
I struggled with bugs in the renumbering machine code, which I had no effective way to fix, so only got as far as prototyping it with apps written directly into the 1000-1999 range and run from there in the left hand pane, and I never figured out a good way for the two applications to manage their state other than in their alloted region of the screen; ZX Spectrum BASIC had a fixed set of variables named after the letters of the alphabet, and while I could (in principle, if not in practice) renumber the apps into their slots, I didn't have a way to "renumber" an app to use its own range of variables for state storage. And I didn't understand the ZX Spectrum memory map enough to allocate regions of memory the apps could PEEK and POKE their data into. So, I gave up on that.
But the dream lived on - having infrastructure to build a rich, interactive, user interface, rather than needing to build loads of bespoke code in my applications to do that would mean better interfaces: they would be consistent between apps, and a central shared core would justify more time spent on adding nice features to it. And it would mean easier application development, as I could focus on the application's logic rather than on the minutiae of tracking mouse clicks and animation.
Tue 8th Jul 2025 7:39 pm 
Subscribe