4 ms·

So much great stuff here! Rough around the edges, but it's a research prototype. Thoughts: - This reminds me of Subtext ... oh, they cited that as an influen

by ken 8y ago

So much great stuff here! Rough around the edges, but it's a research prototype. Thoughts: - This reminds me of Subtext ... oh, they cited that as an influence! I love it when people learn the state of the art and take previous work and build on it. Surprisingly uncommon. - Paraphrased: static types are an indirect way to look at a function's behavior, data is a direct way. I never thought of it that way! - Is that a single quote used as an icon to indicate that it's a string? Neat! (I use icons in Strukt to indicate data types, but I went the other way, and no-icon means string, with a "#" icon indicating a number.) - 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? - I love that names are optional, and not restricted to C-style identifiers. This is a perfect example of something you can't easily do in plain text: without an out-of-band place to put identifiers, you need to deal with escaping, or character ranges, or ... That said, while I love the concept, I disagree with them on some basic points. One that wasn't explicitly mentioned: - It's still a highly-specialized mouse-driven environment, and I'm still not convinced there's any future in those. It makes for a nifty demo, but plain text really took off because everybody has a text editor which can edit any text, and learning to edit one format helps you learn how to edit other formats in the same editor. (Can you tell I'm an Emacs junkie?) What I want is a generic keyboard-driven GUI graph editor. It should be able to be hooked up to live visualizations, via other processes, too. It just needs to be able to edit any kinds of graphs. I don't want my investment in learning this editor to be limited to one specialized type of (mouse-y) programming. Somebody needs to make a great graph-based editor so all these people experimenting in this space don't need to keep re-inventing the UI wheel. (Note to self: me?)

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 ago
  I'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 ago
    Canon 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.

by ken 8y ago

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 ago
I'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 ago
  Canon 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.