1. 15

I’m trying to map known & probable influences among the systems I intend to research & cover, specifically in terms of user interface ideas. This includes programming models when the intended user of the system is a programmer or interaction with the system is performed primarily with a programming language (ex., shells).

This has some known gaps and skips (for instance, I’ve collapsed all early Smalltalk into ‘Xerox Alto’ & dropped ‘Self’ from the lineage of ‘Morphic’, & Oberon has a predecessor named Cedar that I need to research to see where it fits in here), but it’s already pretty hard to follow & will need pruning if I add more items.

If I’m missing anything interesting in this graph, let me know.

  1. 3

    honestly it’s really hard to consume data when presented this way. i don’t mean this to troll… but, ironically, you should improve your ui design

    1. 1

      It looked better a couple hours ago. Dot apparently can’t use edge labels when edges are outside of spline mode.

    2. 2

      Great content, and as others I’m very interested in tools/methods for laying out this kind of quantity of data in a more browseable/interactive way, in case anyone has recommendations.

      1. 2

        I’ve got a structure (and the basics of a layout algorithm) in mind but I think I’m going to need to implement it myself. (I would have expected dot to do it this way, but it clearly doesn’t by default, & I haven’t been able to figure out how to hint it to do so.)

        Algorithm goes like this:

        Each cluster is laid out in order of declaration. Nodes within a cluster are laid out in a single rank and arranged to:

        1. first minimize their distance from the nodes in already-laid-out clusters (if any) by choosing the rank position closest to the average of the rank positions of connections in prior nodes,
        2. secondly to minimize their distance from nodes in the same cluster by choosing the rank position closest to the average of the rank positions of connected peers, rearranging not-yet-laid-out nodes with mutual connections to minimize that distance among currently-empty slots (if not overridden by rule #1)
        3. lastly, not-yet-allocated nodes fill empty slots based on declaration order (if #1 and #2 do not apply). Embedded clusters are arranged among nodes as though they were a single node whose position is the average of all the ideal positions of individual nodes in that cluster, and then they are internally laid out by the same rules (constrained by the bounding box of the embedded cluster, which forces all members to be laid out side by side). The distance between adjacent nodes in constant.

        I’ll see if I can put together a POC of this, since it’s bound to be useful for other types of data. It should be faster than most graphviz layout algorithms because it’s greedy, rather than properly solving a complex multi-constraint optimization problem.

      2. 1

        Great work! A couple of high-level points:

        • You’re missing labels on the arrows. What exactly was influenced or adopted? What form did the influence take? What people were involved? How do you know?
        • It would be helpful to see this laid out as a timeline, maybe something a bit like this Tufte classic.
        1. 1

          I’d love to make these changes. I think I’m straining at the limits of my ability to make graphviz behave properly, unfortunately: I eventually gave up on convincing the decades to be in order! (I’ll eventually make this look a lot more professional, but I’ll either need to change tools or understand dot’s layout algorithm a lot better.)

          1. 3

            In my experience with drawing bigger-than-small graphs, I always end up spending more time wrestling with graphviz than I would just laying out the damn thing by hand. It’s like LaTeX but worse. When the data is mostly static and the presentation is important, manual layout seems to be the better way. Totally understand if that’s not yet a high priority for you, though. It is labor intensive.

            To present this as a timeline, you may want to consider something like a Gantt chart, with labeled arcs between the interval bars. Then you could use color to show attributes like popularity or ownership, and it could still be laid out automatically.

            1. 1

              I don’t think a gantt chart quite fits what I’m trying to do, but it’s in the right direction. I’m probably going to need to write my own software to do this, tbh.

        2. 1

          I believe iOS (and thus copycat Android) owes less to PalmOS (and probably less to NewtonOS!) than it does to Jeff Han’s work on multitouch. See his 2006 TED talk. Han started a company called Perceptive Pixel, which was bought by Microsoft and commoditized as “Surface”. Before that, though, he had some kind of DoD contract.

          1. 2

            I hadn’t put in multitouch, in part because I consider mobile interfaces to be less interesting for my purposes (writing a survey of interesting alternative UI approaches from history, to expand the horizons of designers and developers), and in part because actual multi-touch gestures are really unusual on mobile devices. The only one people actually use is pinch-to-zoom, and only in a handful of circumstances.

            The model of multitouch gesture interfaces in Sun’s Starfire demo reel is more interesting to me, and I plan to cover it, even though the Starfire was never implemented & some of the tech it uses (like large curved touch-sensitive displays that also act as scanners) aren’t quite here yet. (Microsoft had some experiments with ubiquitous computing & combining cameras with displays in a table form factor, probably influenced by Starfire, around the time they were pushing the Zune media player – so, fifteen years or so ago? They did it by putting a multi-inch gap between the actual screen and a glass surface and ringing that gap with cameras – touch control was actually based on video processing, not capacitance. Presumably this could have done some of the things the Starfire was supposed to.)

            The thing I think both iOS and Android got from palm is the model of application-as-resource-database (which palm in turn got from the macintosh, where it appears to have originated).

          2. 1

            Digibarn got to it first, but their graph is less complete.

            1. 1

              This is really interesting - Some of these lines overlap so much that it’s hard to follow. I’m particularly curious to see what the lines coming from ZOG all go to, since I have a personal connection there. Is your dot file public?

              I’m specifically curious about the reasoning behind the links, I see they have some annotations but it’d be interesting to hear more. It’s also interesting that KMS has no influenced systems while ZOG apparently has several. I remember more about KMS than ZOG, since I’m only about as old as KMS. So for example, I remember they thought the way that KMS showed a visual three-button mouse that supported chorded mouse actions was a new and powerful idea - I originally looked to see if KMS was there and if that feature had been assigned any influence. But maybe ZOG had it too? The old PERQ-2 systems did have three button mice, but the ZOG techreport that wikipedia has doesn’t mention it.

              1. 1

                The dot file is here.

                For the sake of this graph, I’m assuming that most 1970s and 1980s card-based hypertext systems with jump links got the card orientation model directly from ZOG instead of from things it influenced, but info is a little thin on the ground and I haven’t had a chance to research them deeply (the whole graph thus far was made in one day, & most of the hypertext stuff added in the latter half of that day), so I expect the connections there to change as I get more information.

                Mouse chording with three button mice is something that’s included in the graph – Plan9 and Oberon have it, possibly from NLS directly – but I didn’t realize KMS had it.

                The plan9 section should be broken up, because there seems to be a lineage between BLiT, MUX, Help, Acme, and Rio that’s interesting independent of the connection to the plan9 base system.

                Since what I’m working on isn’t a history of hypertext per-se but a survey of unusual-but-interesting UI systems that can easily be run or emulated by readers, card-based hypertext systems probably won’t be covered (except perhaps hypercard) – I’m on the fence about whether or not card-based hypertext in general is unusual enough to cover. As a result, the family tree with regard to the lineage of these systems can be even more impressionistic: while I’m endevouring to make it basically accurate and non-misleading for folks who are completely unfamiliar with most of the systems mentioned (or more likely, everything but Macintosh and Android), the primary function is to illustrate the vastness of possibility space in this domain & give hints to readers about what might be worth looking up, as well as giving a general feel for further research paths when a reader already likes a particular model & would like to see similar systems.

                However, I’m also a hypertext nerd & although I mostly stick to Xanadu’s cohort, I’d be interested to hear anything you have to say about ZOG and KMS. (ZOG is hard to research because searching for it produces mostly antisemitic conspiracy theories.)

                1. 1

                  Thanks for the dotfile link.

                  Rob Akscyn’s new project Expeditee is based on KMS, and runs on MacOS & linux, so I just tried it out - it has mouse chording but it doesn’t do the thing I remember from KMS, where the cursor was a graphical representation of three mouse buttons. Expeditee just shows a menu along the bottom of the frame like `“L: go back M: draw line R: Draw Rectangle LR: vertical format. I haven’t dived too deeply, but Expeditee is actually pretty fully-featured from what I can tell. Its navigation setup is identical to what I remember from KMS, and it’s causing some extreme nostalgia.

                  As for what I have to say in general about ZOG and KMS, I actually don’t have a lot of first-hand technical knowledge. Don McCracken is my dad, so I remember him working on KMS, and I did play with it occasionally but he moved on before I was old enough to really get into it. I remember more about the graphics demos of the PERQ machines he ran KMS on (and the impressive bigger-than-an-LP-sized hard disk platters we pulled out of a broken one) than anything really about KMS. If you have any specific questions though, I could probably forward them along.

                  1. 1

                    Thanks! I’ll check Expedite out.

                    Is there anything particularly notable about the PERQ machines specifically, aside from running KMS? PERQ keeps getting referenced on various GUI timelines but a cursory look at it didn’t indicate that they had anything that other machines at the time weren’t already doing – but for the time period, I would expect every architecture to have some interesting idiosyncracies.

                    1. 2

                      I don’t have great context for this off the top of my head. PERQs had powerful graphics for the time - specifically they had hardware-accelerated graphics. I think they had better graphics than the other workstations available at the time. I was certainly impressed by full-screen black-and-white dithered animation. :)

                      There’s a lot of detail in this collection of PERQ notes I found. There’s also a ton of historical detail in this history of a defunct UK computing lab that used PERQs. I also found a video on youtube showing off the Sapphire window manager on a PERQ. It’s pretty cool to see it live again, I’d only seen screenshots the last few times I looked.

                      I think they used them for ZOG and KMS because they were good workstations, but also because 3RCC was also a CMU spinoff, so they knew those guys. Later on, KMS was ported to Suns, Apollos, DEC Alphas (I don’t know if they used VMS or not) and I’m pretty sure SGIs.

                      1. 1


                      2. 2

                        Looking a bit further into the final ZOG writeup, it says they moved to PERQs for the trial on the USS Carl Vinson aircraft carrier. There’s some background about the usage of PERQs with the carrier in this Navy report.