This post is rekindling my urge to run away and live on a boat :)
I’d propose that another aspect of the steampunk aesthetic is uniqueness—a rebellion against the era of mass production. You don’t live in a standard Mark II Apple iBoat, you live in a constantly changing hand-built ship-of-Theseus that only you could ever understand or operate.
In that aspect at least, Linux has steampunkish tendencies. You may start with a standard distro, but over time it becomes a web of shell scripts and homebuilt jury-rigged tools, until you reach the point where someone asks if they can use your laptop and you are forced to reply in all honesty “probably not”.
A large part of the reason I want to make programming more accessible to people is to give them this sense of ownership over the devices that run their lives. It may end up being messy and inefficient, but it would feel more human.
This overlaps again with ‘choice of environment’. The fact that most people live in rented houses and aren’t allowed to redecorate, let alone replace the stairs with monkeybars, is maybe kind of dehumanizing.
Yeah, part of the point of this post was to highlight that Steampunk and Linux share a lot of commonalities (of the sort you describe here), and the main difference is that Steampunk involves more physicality.
until you reach the point where someone asks if they can use your laptop and you are forced to reply in all honesty “probably not”.
A large part of the reason I want to make programming more accessible to people is to give them this sense of ownership over the devices that run their lives. It may end up being messy and inefficient, but it would feel more human.
I ardently and enthusiastically agree with your goal—giving people a “sense of ownership over the devices that run their lives”—but deeply disagree with the notion (quite common today, indeed) of doing it via programming.
In my other comment, I describe the alternative to what you propose—namely, the “Macintosh aesthetic”. In such a system, one does not write code to customize things (unless so desired!), but nonetheless customization, building novel structures, etc., is very much possible. And, as I say, such an approach is already tremendously more accessible, to non-programmers, than programming will or can ever be.
A digression:
This overlaps again with ‘choice of environment’. The fact that most people live in rented houses and aren’t allowed to redecorate, let alone replace the stairs with monkeybars, is maybe kind of dehumanizing.
This is absolutely correct; I couldn’t have said it better myself. And the same applies to personal computers. But note: averaged across the distribution of humans, the returns from increasingly radical customization diminish (as returns from anything tend to). That is, you get great gains of satisfaction, pleasure, etc., from allowing minor customization—if you live in an apartment, and can move the furniture around, and tack posters to your walls, that is a huge improvement over living in, say, a hotel room—and the gains from being able to replace the stairs with monkeybars are (again, averaged across the population) comparatively minor.
We can notice two things: first, that “increasingly radical customization” is often (though not always) synonymous with “more functional [rather than merely aesthetic] customization”. And second, that—as we know from the literature of occupational psychology, psychology of HCI, ergonomics, etc.—the feeling of control is what directly mediates satisfaction with the experience of some process/task/etc., rather than actual control. But the feeling of control may be induced in many ways, and its correlation with the degree to which one is actually “changing the plumbing” of a process or system is imperfect, to say the least!
A tangentially related, but no less important (though often overlooked), point is that there is often quite a fine line between aesthetics and and functionality, simply because almost any mechanism which is designed for aesthetic customization may be repurposed to provide functionality.[1] Three very simple examples:
Allow users to set an arbitrary their own desktop background (“wallpaper”), and they can use it as a way to keep important and often-referenced information (a daily task checklist, say) in an easily-accessible way. (Of course, in reality, applications exist that are designed just for this purpose; but consider a primitive system with no such applications—there, the desktop background can serve this purpose in an impromptu fashion.)
Allow users to arrange the file icons in a folder (or on the desktop) in an arbitrary way (and maintain this arrangement, in a guaranteed-persistent manner), and they can use this functionality as an additional dimension of structure/organization. (People can remember spatial data organization schemes more easily than abstract ones.)
Allow users to set their own icons for files, and they can use this to create easily visually parseable organization schemes for their digital workspaces, and construct impromptu workflow-enhancing systems.
(These are not made-up examples; I have seen each of them used, just as described, “in the wild”. And there are many other examples, of course—I could list them all day.)
All of this is to say that we can get a lot of “sense of ownership” mileage out of relatively little “customization capability” investment. Make a system sufficiently flexible in its surface details—and you may find that there is very little need to touch the system’s deep nature, to induce user satisfaction and inspire user loyalty.
[1] That this is a general point may be seen by noting that much of aesthetics is visual, and that vision is the highest-bandwidth sensory modality that humans have. This means that any mechanism that allows for the customization of the visual appearance of an interface adds degrees of freedom that allow for the transmission of information to the user. (“Sensory bandwidth”, by the way, is a critical aspect of UI design—and one that is too often overlooked in the popular systems of today, though it once informed much of the orthodoxy in the field, and continues to do so among professional HCI researchers and designers.)
This was, as I said, a digression; I’ve run out of time for now, though there’s much more to be said here—about composability, about importable intuitions, about discoverability, about smooth skill gradients, and more… but that’ll have to wait.
This post is rekindling my urge to run away and live on a boat :)
I’d propose that another aspect of the steampunk aesthetic is uniqueness—a rebellion against the era of mass production. You don’t live in a standard Mark II Apple iBoat, you live in a constantly changing hand-built ship-of-Theseus that only you could ever understand or operate.
In that aspect at least, Linux has steampunkish tendencies. You may start with a standard distro, but over time it becomes a web of shell scripts and homebuilt jury-rigged tools, until you reach the point where someone asks if they can use your laptop and you are forced to reply in all honesty “probably not”.
A large part of the reason I want to make programming more accessible to people is to give them this sense of ownership over the devices that run their lives. It may end up being messy and inefficient, but it would feel more human.
This overlaps again with ‘choice of environment’. The fact that most people live in rented houses and aren’t allowed to redecorate, let alone replace the stairs with monkeybars, is maybe kind of dehumanizing.
Yeah, part of the point of this post was to highlight that Steampunk and Linux share a lot of commonalities (of the sort you describe here), and the main difference is that Steampunk involves more physicality.
I lol’d
I ardently and enthusiastically agree with your goal—giving people a “sense of ownership over the devices that run their lives”—but deeply disagree with the notion (quite common today, indeed) of doing it via programming.
In my other comment, I describe the alternative to what you propose—namely, the “Macintosh aesthetic”. In such a system, one does not write code to customize things (unless so desired!), but nonetheless customization, building novel structures, etc., is very much possible. And, as I say, such an approach is already tremendously more accessible, to non-programmers, than programming will or can ever be.
A digression:
This is absolutely correct; I couldn’t have said it better myself. And the same applies to personal computers. But note: averaged across the distribution of humans, the returns from increasingly radical customization diminish (as returns from anything tend to). That is, you get great gains of satisfaction, pleasure, etc., from allowing minor customization—if you live in an apartment, and can move the furniture around, and tack posters to your walls, that is a huge improvement over living in, say, a hotel room—and the gains from being able to replace the stairs with monkeybars are (again, averaged across the population) comparatively minor.
We can notice two things: first, that “increasingly radical customization” is often (though not always) synonymous with “more functional [rather than merely aesthetic] customization”. And second, that—as we know from the literature of occupational psychology, psychology of HCI, ergonomics, etc.—the feeling of control is what directly mediates satisfaction with the experience of some process/task/etc., rather than actual control. But the feeling of control may be induced in many ways, and its correlation with the degree to which one is actually “changing the plumbing” of a process or system is imperfect, to say the least!
A tangentially related, but no less important (though often overlooked), point is that there is often quite a fine line between aesthetics and and functionality, simply because almost any mechanism which is designed for aesthetic customization may be repurposed to provide functionality.[1] Three very simple examples:
Allow users to set an arbitrary their own desktop background (“wallpaper”), and they can use it as a way to keep important and often-referenced information (a daily task checklist, say) in an easily-accessible way. (Of course, in reality, applications exist that are designed just for this purpose; but consider a primitive system with no such applications—there, the desktop background can serve this purpose in an impromptu fashion.)
Allow users to arrange the file icons in a folder (or on the desktop) in an arbitrary way (and maintain this arrangement, in a guaranteed-persistent manner), and they can use this functionality as an additional dimension of structure/organization. (People can remember spatial data organization schemes more easily than abstract ones.)
Allow users to set their own icons for files, and they can use this to create easily visually parseable organization schemes for their digital workspaces, and construct impromptu workflow-enhancing systems.
(These are not made-up examples; I have seen each of them used, just as described, “in the wild”. And there are many other examples, of course—I could list them all day.)
All of this is to say that we can get a lot of “sense of ownership” mileage out of relatively little “customization capability” investment. Make a system sufficiently flexible in its surface details—and you may find that there is very little need to touch the system’s deep nature, to induce user satisfaction and inspire user loyalty.
[1] That this is a general point may be seen by noting that much of aesthetics is visual, and that vision is the highest-bandwidth sensory modality that humans have. This means that any mechanism that allows for the customization of the visual appearance of an interface adds degrees of freedom that allow for the transmission of information to the user. (“Sensory bandwidth”, by the way, is a critical aspect of UI design—and one that is too often overlooked in the popular systems of today, though it once informed much of the orthodoxy in the field, and continues to do so among professional HCI researchers and designers.)
This was, as I said, a digression; I’ve run out of time for now, though there’s much more to be said here—about composability, about importable intuitions, about discoverability, about smooth skill gradients, and more… but that’ll have to wait.
I wish you wrote more about the other aspects mentioned in your last sentence.