Hi y’all,
I’ve been lurking around the forum and reading stuff. One things I noticed is that there seems to be no clear list of ways in which UI —probably the most opaque part of software—allows us to peek behind itself. So here’s my small list of patterns for transparent (sorry for the overriden term) UIs:
When I try to imagine what an optimistic far future will be like, say 100 or 200 years from now, my best answer so far is, “like today but more evenly distributed.” Inspectors are awesome but sadly not ubiquitous. Ways to explain code are awesome but sadly not ubiquitous. I think it will be wonderful when both sides are indeed ubiquitous. To be able to easily look at the source code for a program and also look at the runtime values of things, that feels like the ideal separation. Right now our inspectors struggle under the burden of the user not understanding architecture, and our code explanations struggle to convey possible evolutions of values at runtime.
Right, even distribution of inspectors to people is a good humanitarian goal! 
To be able to easily look at the source code for a program and also look at the runtime values of things, that feels like the ideal separation.
Sources I’m not sure about. Not the procedural sources, at least—too many extraneous details. If only we had good declarative languages/UIs… like HTML and CSS? That’s as close as it gets to understandable sources behind the UI nowadays. But yes, looking at sources is empowering enough and a good step in the right direction!
Cross-link to my belief system on “declarative”:
Mutating a declarative representation is wonderful once you gain some fluency with it, but gaining that fluency becomes a hurdle. And a lot of declarative representation is very hard to wrap your head around. For example nobody it seems can guess ahead of time what any non-trivial CSS will do. With simple imperative programs I feel like I can always understand things to arbitrary levels of detail. Whereas with CSS I’m stuck cargo-culting black boxes. Declarative representation is nice if you consider just the declarative code in isolation, but realistically I think it can still be intimidating proportional to the size of the implementation. At that point, is it maybe better to just write imperative code in a very simple way?
Definitely a weak opinion, though. Maybe we just don’t know how to implement good declarative notations yet.
Point on CSS taken, it’s hard for me to un-learn it and remember that it’s hard 
Modal (by Wryl) and Tote by @neauoire might be good examples of declarative-ish systems that are simple enough to understand and get productive with in a short enough time. And (I can’t emphasize it enough) HTML too, despite its XML syntax. But we could indeed have better declarative systems!
I see “declarative” as a means to an end, not an end in itself. For me, human-readable source code must first of all be locally understandable, meaning that small pieces must make sense without a prior study of a larger systems architecture. I think I read about this concept first in some article by Richard Gabriel, but I don’t remember which. Probably something related to Christopher Alexander’s “quality without a name”.
Mutability is often, but not always, an obstacle to understanding at a small scale. Declarative languages are sometimes, but not automatically, locally understandable, CSS being a good counterexample.
As so often, I think CS people overestimate the importance of formal language features in this space, and underappreciate the informal aspects of code, such as well-chosen names that match domain concepts. My current belief (weakly held) is that the best way to get to human-readable code is having non-developers read code and provide feedback. Which is what I am aiming at with my HyperDoc project.
I like this definition a lot.
I found the reference: Patterns of Software, page 6:
The primary feature for easy maintenance is locality: Locality is that
characteristic of source code that enables a programmer to understand that
source by looking at only a small portion of it.
There’s also a nice short discussion here.
I much prefer this other quote by Richard Gabriel from Patterns of Software (pg 42 [1]):
If I look at any small part of it, I can see what is going on—I don’t need to refer to other parts to understand what something is doing.
If I look at any large part in overview, I can see what is going on—I don’t need to know all the details to get it.
Every level of detail is as locally coherent and as well thought out as any other level.
The question of life, the universe and everything is, “On what page of Patterns of Software did RPG reveal the goal of programming?” ↩︎