In struggling to make sense of NicCLIM for the fairly straightforward task of adding movement and tracking-by-scent to the unicode emoji game map before, I was feeling a bit vexed and sought some usability hints from Adler and Winograd whose Usability I am reading. The first few articles of their contributed volume formally either backed up or dispelled enough folk wisdom that I am taking a moment to write this instead.
The book I keep referencing here is
Adler, Paul S., and Terry A. Winograd, eds. Usability: Turning technologies into tools. Oxford University Press, 1992.
defined by Rittel and Webber, 1984 as paraphrased by me paraphrasing Kukla et alās chapter 3 of Adler and Winogradās Usability. Problems where design is attempted are very often wicked problems, having properties
Kukla et al suggest that wicked problems appear to appear so often now because earlier on, computer program operators were primarily people who wrote computer programs, and the newly appearing wicked problems were basically that computer programs needed to be written for users who had never and generally would never, and did not want to ever write computer programs.
Previously, they say that software authors were typically writing software they themselves were key users of, and any time a design decision was to be made, the idea that occured to them for themselves was generally compatible with other likely users, being their close peers.
reduce costs, decrease skill requirements of operators, and increase the rate/yield of a process. (still Kukla et al). Kuklaās list is
Prototyping has significant risks but they are not well understood. They are viewed as early versions of the final system, they are rushed into operation before usefulness is either defined or established, personnel are made to use them without being trained to be able to, then the managers become disappointed with both the technology and users, then the managers blame creativity for the apparent failure. (still Kukla et al).
The prior chapter had been a case study on photocopiers and the common folk wisdom on designing a new photocopier.
The gist being that in the 70s and 80s, the company as such was approaching photocopier design as though the technical problem to be solved was the creation of chemical and physical technology that would allow photographic copying of paper onto other paper as quickly as possible which had been the problem back in the 1940s.
However around 1980, it was no longer a technical barrier to create a machine that photocopied pages at all, but instead to bring together their community, create situations in which very different people and groups were able to genuinely contribute to the creation (and so forth) of the photocopier series, and hence be rightly proud of their participation: on the customer side, the photocopiers sought to be interesting and engaging and accessable to its users, playing to their skills and own innovation as to what the photocopier was and what they could do with it, facilitating them individually and not leaning towards deskilling and shrinking the customersā employee base.
From my personal experience as the sometime operator of a 1980s Xerox photocopier working in a bookshop before I found out about computers, I can remember being unironically engaged by its user manual and the wizardry I could figure out with it, which unengaged coworkers were not able to simply copy and hence replace me in doing; it was sort of easy, but a little more familiarity and interest led to great returns. The symmetry was also there; if you never learned how to navigate menus, back up, save, the photocopier was basically just an expensive boulder older than you were that light objects could be rested on top of when tables were full (as you waited for the guy who could unjam its paper feed to have time to do so). It is interesting to see that that was an extensive and conscious radical design theory.
It is an interesting focus that the proximal objective of my NicCLIM should be to galvanize me myself to want to engage with it. Drawing an inclusive line around
as being coherent and inseparable and a wicked problem.
It seems that by definition veteran game devs are people who can and already have both studied and created their own suites of tools and strategies for making relevant, specific and engaging game maps, both handcrafted and procedurally generated, playing an invented instrument that blends the two for their own games.
I guess what NicCLIM is is quite close to being a spreadsheet view of s-expression data, leaning more into the physical spatial metaphor, with a macro system that has one foot in VIās macro system and one foot in emacs eevās keyboard macro system. Where the data might be graphics, or might be an APPLYable lisp form that can be picked up and carried to a target, and used.
Longer range, the ability to put a slime-connectable NicCLIM inside of C/C++ programs should get things really weird. Also, since the reality of games seems to be that web games are by the nature of modern computer useage exceedingly dominant, I need to get running NicCLIM ā running Kitten ā kitten server happening quickly to see what it might be like.
What the implications are are mysterious, let alone trying to guess how another game dev might seek or succeed to engage with it themselves.
Pretty clearly, I should use NicCLIM to add movement and scent-tracking to that unicode game, and have a notion of myself as a character in that game.
See you on the Mastodon to talk about it as always please.
I am very happy for you to share my reflections on Adler and Winogradsā reflections on Usability when and how occurs to you ; some of the notes (from the 80s!) seem to have become more urgently true with time.
screwlisp proposes kittens