5 ms·
> This is the second time this week I've seen a system where you could connect nodes by either dragging an edge, or typing a name. Is that the best of both worl
by TuringTest 8y ago
> This is the second time this week I've seen a system where you could connect nodes by either dragging an edge, or typing a name. Is that the best of both worlds? Are we converging?
Working on anonymous objects might be the single killer advantage of GUIs over textual environments for defining automated processes; coming up with good names for variables is hard, and GUIs limit the need to do that to only the essential objects.
Conversely, retrieving objects by name is an essential advantage of textual entry typical of classic programming languages. It allows connecting your current expression to far-away objects in the system, which is hard or cumbersome to do by navigating a graphical interface.
So yes, that is probably the best of both worlds. It's also what spreadsheets do, and they're considered a very successful development environment for end users; so, you might be onto something there...
> What I want is a generic keyboard-driven GUI graph editor
Have you seen Jef Raskin's Canon Cat, and Humane Environment (a.k.a. Archy)? There's a lot of good design on how to build a generic keyboard-based GUI.
I also have some ideas for how such a general, keyboard-driven graph editor could work, largely inspired by Raskin's Humane Interface... One of those would be using comic strips to represent state transitions, as in the example at slide 23 (minute 22 in the video).
P.S. Mockup tools for rapid prototyping are typically heavy mouse-driven, and they're very good for exploring user interactions. So, there may be a niche case for preferring direct manipulation for exploratory work when creating new automations.
- ken 8y agoI've seen some videos of Canon Cat, but I must be missing something because I'm not aware of it being any sort of GUI. It looked to me like a text editor with "no save" (always automatically synced to disk), and keyboard support for Emacs-style isearch (very cool). For ideas on how to map keys to nodes/edges, there's other places I'd look. For example, lots of video games let you easily move along edges of a graph using just 4 (or 8) direction arrows. "State transitions" are one very specific kind of graph, and my thought is a generic editor. Think lower level. State transitions as comic frames could be a major-mode that the user installs, if they know they'll need to edit a lot of transitions, but it should also support "I know nothing about this except it has nodes/edges", like fundamental-mode is for text.
- TuringTest 8y agoCanon Cat did not have graphical capabilities at the time, but its successor the Archy prototype had them. Instead of being mouse-centric like the Mac/Lisa, it was intended to handle graphical objects mostly or entirely by keyboard (like Emacs, but without modes), and Raskin had plans to make it work like an infinitely zoomable browser. The think with Archy is that it contained all the power of a command line for chaining commands, but it also worked on documents, all with a very well thought out interaction model that's easy to learn (in contrast with Emacs, which offers the same power but it's a nightmare to learn). Yeah, a low-level "graph editor" extensible library that could be plugged-in anywhere to provide a common interaction, that would be great. Things like tree widgets provide some of that, but of course they only support a specific subset of graphs.