First of all, I really like the concept of grid based flow charting. It's one of the popular metaphors used in "wiring" software based musical instruments and effects and works really well for a significant percentage of signal flows that don't have too many back looping or crossing virtual wires.
However, would it be possible to make the flow go vertically rather than horizontally?
I find that a vertical direction of flow is
- more practical because of the ubiquity of mouse wheels for easy up/down navigation compared to the various less common ways of navigating horizontally
- the much more common direction for sequential steps in programs or scripts
- more culturally global, since there are quite a few right to left languages (as in addition to the left to right language used on this site :-)
- distance between boxes is easier to keep constant vertically while still allowing different size boxes (due to longer or shorter labels)
I agree with all of your points, I just wanted to highlight I just learned about a few months ago, that maybe others don't know about as well :)
> - more practical because of the ubiquity of mouse wheels for easy up/down navigation compared to the various less common ways of navigating horizontally
You can actually do horizontal scroll by holding shift and scrolling the wheel. Learning this was a revelation.
"You can actually do horizontal scroll by holding shift and scrolling the wheel."
Yep, that is helpful. But note that this is no universal standard. But most mainstream applications and browsers have it indeed implemented. Useful for big pictures etc.
I thought this was implemented on the OS level or something like that, as I've never not been able to use it for horizontal scrolling. I'm mostly on Linux but worked everywhere on Windows as well as far as I can remember. Maybe on macOS it's different.
It's likely possible to force that mapping via some configuration tools. On Mac and Windows, such tools are usually rather visible, but on Linux it's probably just config files for some components of X or the input layer.
It's interesting to see this perspective. My experience with canvas-based flow charting applications shows that users prefer the horizontal left-to-right flow. The ability to shift drag the canvas usually makes horizontal scrolling a lot easier. I believe it's mostly due to the fact that people find writing to be the closest metaphor. It is expected that adding a new node or step will appear to the right of the current one.
However, I think more research and experimentation are needed.
In designing similar interfaces, I noticed that our users who were more familiar with physical documents preferred horizontal, while those more familiar with digital interfaces preferred vertical. Tiny sample size though.
If you look into the world of visual effects software, there's a lot of node graphs and it quickly becomes apparent where they fall into place.
Horizontal is for data flow based graphs where nodes pass specific data blocks to each other. This is the norm in shader editors, Maya's node graph, blender geometry nodes, Unity shader graph, Unreal blueprints etc...
Vertical is for pass the world or step based graphs. Each node represents a step, and nodes mutate a combined state that gets passed down. Nuke, Houdini and Katana are like this
the vertical graph has a lot of familiarity with people because it's like a Todo list of steps.
Horizontal graphs are better for data flow because they can have tons of labels that run vertically and get connected to each other.
In some cases you even have hybrid graphs. Where data processing runs horizontally that feed into steps which run vertically. You'll see this in Pixar's Presto, and Unity's Visual Effects graph.
For sure, what you're saying is true, but I suppose it depends on the content, layout, and how it's used. Vertical is typically better when first word type scanning is important, like data tables or anything similar. Horizontal scrolling in data tables is something I hate with a fiery passion and do everything I can to avoid, for example. When a workflow or series of interconnected elements are what's important than horizontal tends to work better for how people think about those things, imo, but there are exceptions to every rule. Basically, it just depends.
With a lot of marketing flow builders I’ve noticed that some if the older software has workflows that go right to left, whereas newer tools go from top to bottom.
I’m not sure if anyone’s testing the UX of these or whether designers are just following convention from other tools, however.
I prefer vertical as well. Find it much easier to follow, possible because I'm used to working with code, which is also laid out vertically (and where I tend to break and indent long lines to make them easier to read).
Besides the Desktop TCL [0] implementations there is also two web implementations [1,2] that I assume would be possible to package with Electron or similar.
Mermaid uses a grid layout and it sucks in practice, so you might want to adjust your expectations.
There needs to be some kind of way to say ”these things are siblings so arrange them side by side”, and likely some other ways of grouping and placing constraints on node positions.
Otherwise, the result will be essentially random placement.
What would really be a game changer: abstraction levels, so you could have a nice top level diagram of things and then decrease level of abstraction to reveal more details.
I'd like to support vertical layout, I just found for most the initial use cases that horizontal was the most intuitive. I find that its nice to have child nodes be left aligned with the horizontal layout so you can quickly read them top to bottom. But I know a lot of interesting tools do vertical layout for the reasons you mention.
"the ubiquity of mouse wheels for easy up/down navigation"
I have maybe used a mouse once in the last decade (I use a trackpad)...and that mouse didn't have a mousewheel. And before that I used trackballs for a decade (again, no mousewheel). And before that, my laptop had a nubbin.
I recently set up a keyboard with mousekeys (on that computer, I have no mouse-ish-thing at all), and since I saw there was mouse wheel emulation, I attached that to a couple of keys out of curiosity, but I had literally no idea what those would do when pressed in any program since a mouse wheel is completely foreign to me.
Not saying you're wrong, just that the assertion of ubiquity struck me as strange.
on a trackpad, it's a two-finger gesture (see https://support.apple.com/en-gb/HT204895). On the mouseless system, it depends. For coding, I'd tend to search rather than scroll.
Hey all, author here. Graphs are used for tons of purposes across a lot of disciplines, but we don't have a fast general-purpose graph editor. That's what I'm trying to do with knotend [0]. It's a keyboard-driven directed graph editor. I made it for myself for planning project dependencies. It's also a great tree editor.
I actually posted a very early version as a Show HN [1] which you can see was mostly met with question marks, and rightfully so. It was literally a grid, with the gridlines rendered, and had very cryptic keyboard shortcuts. I've spent the last year just working on the UX, to make an intuitive and fast editing experience.
I'd love more feedback especially about any UX issues. It's free to use the purely client side version, and you can join the waitlist [2] if you want a user account to persist graphs to the backend (I'm slowly onboarding people).
I was wondering about version controlling flowchart and came across mermaid. As soon as I saw your tool, I thought adding export to mermaid plaintext would be nice.
And you already have that in there! I am looking forward to using your tool ASAP.
Github natively supports mermaidjs in their markdown, I wonder what kind of Github integration can be possible in Knotend.
My feedback: I don't like when web apps override default browser right-click behavior. I understand why you did it, and it seems reasonably well implemented, but it's still a peeve of mine.
I tried to not override default behavior as much as possible. Maybe I can find a way around this one too. I just found that people naturally right clicked on nodes to do various actions because they're used to doing it in google sheets, docs, etc.
Don't try to work around it. If you found in your user studies that people wanted to use right click, you'll be inconveniencing the majority if you remove that behavior. Speaking for myself, I get mildly frustrated when a web app doesn't give me a custom right click menu, because discovering whatever they chose instead is much harder.
If you could find out more about why people like OP dislike overriding the default behavior, you might be able to provide those functions that they are missing. If it's devtools, you're out of luck, but someone who needs those probably already knows ways around the click hijacking.
I'm the opposite. Shift-right-clicking when I need to access the default behavior is not a big deal, and right clicking is such a natural instinct for me that I love it when web apps support it.
Hey, really cool idea! Would love to see this fleshed out more.
Some UI feedback:
* On Windows, the tab and ctrl-enter shortcuts seem to be "captured" by the node input, like you have to push them twice if you're in the middle of typing something. You can't just type "test" and tab to the next node, you have to tab-tab.
* Box-selection (drag a rectangle around one or more nodes) would be super helpful.
* When you drag a node to move it, it's not immediately obvious what will happen to it. A move "preview", like a shadow where it's going to end up, along with how the lines will change, would be awesome.
* It would be REALLY cool to be able to import/export UML (https://plantuml.com/sequence-diagram). I love the semantics of UML, but darned if it isn't hard to edit quickly. Being able to use a keyboard interface, along with maybe a quick dropdown-selection to select node type, to quickly prototype a diagram and then export it to UML when done would be something I'd be VERY willing to pay for.
* It isn't super clear to me, in this system, how the connections between nodes work. Are there different arrows, strokes, etc.? Are there different node shapes (rectangles, diamonds, circles) like traditional flowcharts that represent different types?
Overall, really cool to see this happen. Thanks for making this and looking forward to future changes!
> On Windows, the tab and ctrl-enter shortcuts seem to be "captured"
It's like this on alls systems at the moment. For example you can't use Tab to add a new node while you're currently editing the text of another node. I'm working on this but its a bit complicated because some shortcuts interfere with system shortcuts for text editing.
> * Box-selection
I agree!
> * When you drag a node to move it, it's not immediately obvious what will happen to it.
This is a really good idea. I was just a little lazy and didn't add any ux niceness here. I could probably add some phantom connection lines showing what edges would get aded.
> import/export UML
I'll take a look on exporting to UML. I'd like to support as much import/export formats as is feasible.
> how the connections between nodes work
The connections are simply an edge in the graph. There isn't any styling or way to convey meaning to an edge. One of the big differences with knotend and other diagramming systems, however, is that knotend isn't geared towards making particularly pretty diagrams. It's very much designed around speed. So for example it supports colors, but doesn't support any manual layout or custom shapes. To be honest I'm not sure if/when it will. But I'm happy to export to those systems. If you email me with any example diagrams that you've made using UML (or other systems) I can see how those may work in knotend now or in the future.
Thank you for all the great feedback, it really is super helpful!
I really enjoyed the few minutes I spent with it, and I've got it bookmarked for the next time I want to visualize a large number of tasks and requirements! Your described use case of "project tasks dependencies" particularly struck a note in my head.
Anecdote: part of the initial hook in playing with knotend (i.e. fun) was trying to infer the key mappings. I didn't end up checking out the demo.
Regarding the larger picture of "diagrams for stuff", my own take is that it's a realm that one tool can't cover all use-cases. As an exercise, I started listing some of the broad use-cases and my go-to tools for them...
- simple (simplistic often) for presentations - where refined tweaking is key (Lucid chart, previously Inkscape)
- large, autogenerated - "I'll trace the flow, it just needs to be sane" (graphviz)
- structured customized, small/medium flow charts (yed/plantULM in the past, next time probably mermaid)
- gantt charts or other task dependency trees... these are like the "project task dependencies" you wrote of, but with a time aspect added in... (I don't make these much...) It seems like tools are likely to do gantt or flow charts well, but not both.
- nested text lists (not really a flow chart, but a common way of organizing my thoughts)
- flat lists (not really a flow chart), how I often dump large lists of todo tasks for projects. (I like using google sheets for this; I just wish I could drag and drop rows)
Having bumbled my way through listing all of that: I was going to ask if you think knotend is still on the path to being a general-purpose flow-chart editor... but then realized you specifically talk about "graph editor", and I have not formed opinions on that topic. So I don't have a question here really ;)
I agree there's no one tool for all possible diagramming cases. Knotend actually isn't geared towards making highly pretty graphs since it uses autolayout. It's specifically for fast editing of a structured graph. For example there's no way to have a dangling edge to nowhere. I personally like this because it was the main pain point I felt with miro, lucid, etc. and I want to continue down the path of what we can do if we have a super fast editing experience for structured directed graphs (eg, could you export this to another tool that consumes it and does some computation).
Thank you! I made a mistake here by making the keyboard shortcuts a little too sparse on info. I like how some other tools show a little visualization of the key + words describing it. I'll work on it.
Nice work! If it will support ASCII export I may stash one of my side projects forever :)
Minor feedback: not all buttons seem to be accessible to keyboard-only users.
I'm just a Vim snob with a browser plugin, but for people who actually can't use a mouse your app seems like it would be perfect for them if you fixed that.
Edit: just making the "shortcuts" button accessible may be sufficient, as that shows how to use the keyboard shortcuts.
Thanks. If you have any more specifics on accessibility I'd appreciate it. I'd like knotend to be usable 100% from the keyboard, and eventually via screen reader.
I'd like to (optionally) see an arrow direction on edges. Most of the graphs I work with are directional. If I drag to try and create a back edge, it doesn't seem to care about direction and just assumes everything is left->right.
+1 for arrows. Since the edges are directed I like the option (maybe default?) to render the edges as arrows. The flows just reads better in that way.
It is a very nice tool with a lot of potential. At the moment I use tools like https://dreampuf.github.io/GraphvizOnline, knotend just adds the missing gui for editing with drag/drop and easy keyboard interaction. With arrow rendering as option and some basic way of styling (changing the background color is good enough for me, to distinguish different types of nodes) this can become my default tool for documenting flows.
The dot file import and svg/dot file/mermaid export as very useful for creating flows, including the svg/mermaid in documentation files and using the dot file for archiving / future changes.
I agree, it's needed. It is one of several reasons that I need to rewrite the layout algo for both better positioning of nodes and edges (which makes drawing the arrow heads simpler since they won't overlap each other). In terms of back/forwards arrows -- the lines should be rendered differently if they are going from right to left (with a dashed line).
What do you think the grid actually helps with though? Seems like most of the benefit is the keyboard shortcuts to create child/sibling nodes? Is it just because the grid provides keyboard nav (arrow keys) to the different nodes?
One minor feedback about the keyboard shortcuts: On macOS I would treat Option+Letter as reserved shortcuts because they are used to write special characters like Ω≈ç√∫.
Option-N is used to write any letter with a tilde, such as ñãõ and ÑÃÕ.
Im working on this…its tough. I noticed several webapps make this mistake, like Miro. I think something clever is required since google sheets gets it right.
> After dragging around boxes for a few minutes you need to take a break and ice your wrists. It's just too slow, there's too many micro-interactions, and it distracts you from what matters most: defining your dependencies.
This is an interesting claim. I've programmed LabVIEW professionally and didn't have to take breaks every few minutes. And neither do PC gamers.
What about PlantUML and other text-based diagramming solutions? How do those compare here?
>>> I've programmed LabVIEW professionally and didn't have to take breaks every few minutes.
It might vary with individual physiology. I worked in LabVIEW for several months, more than 25 years ago, and the combination of eyestrain headaches and wrist truma were practically debilitating. To be fair, I also had problems with any software that involved tiny graphics, elaborate menus, and fine mouse work, such as CAD.
Text based programming, and plain text editing, are actually things that I use as a refuge from the physical demands of operating GUI based software.
Yeah to be fair, LabVIEW is the absolute worst graphical programming system. For something that is literally all about graphics you'd think they'd hire a graphic designer. LabVIEW looks like they tried to make an example of how not to do it.
I'm not a fan of graphical systems in general for other reasons, but we probably shouldn't decide anything based on something as bad as LabVIEW. Simulink is way better for example.
Nobody should write programs like that. That would not pass code review in a serious LabVIEW team.
> Yeah to be fair, LabVIEW is the absolute worst graphical programming system.
That's a strong statement. I am unaware of any visual programming environment as powerful as LabVIEW. Nothing is close. LabVIEW has several features over text-base languages as well.
However, I am a strong critic of LabVIEW, but not for the reasons you list. The UX could definitely be improved, and this is something I'm looking into.
NI did embark on the LabVIEW NXG (next-generation) project but boggled it. It is tough. LabVIEW is thirty something years old. The only remaining product from the NXG endeavor is the LabVIEW NXG Web Module. There were some improvements but there could have been more. It failed due to mismanagement.
I tend to separate LV into the language and its graphical representation. The language is highly optimized dataflow programming with extensive hardware libraries for data acquisition and control. If your problem lends itself to a performant dataflow solution, LV is worth checking out. The machine that discovered the Higgs Boson was programmed in a custom LabVIEW.
There's a belief that LV is easy for novices to learn, such as test technicians and engineers. Interestingly, the other easy "language for the rest of us," Excel, is also a dataflow programming environment.
The graphical "language" was introduced for the Apple Mac II at a time when there was a lot of excitement for "graphical everything," and again a view that the graphical flow chart would make it intuitive for non-programming engineers. The simplest LV programs had an almost 1:1 correspondence to things that were familiar in test hardware such as knobs, switches, meters, and so forth.
Now my main critique is the sheer physical labor required to write and edit programs. This could actually lead to sloppy code, if it's too painful to refactor things. I think that if there were a good text based dataflow language, and LV adopted it, the graphical language would fall into much more limited use (e.g., for adding user interfaces to programs). That's just my hunch.
I haven't tried the editor in the article yet, though I'm looking forward to giving it a real shot.
I've created a fair number of architectural diagrams in the past 4 months and I keep bouncing between PlantUML, Mermaid, and Visio. I always end up frustrated with all of them, though mermaid is my current go-to.
Mermain and plant UML are great for simple graphs, but more complex graphs always end up doing something that makes it hard to read. If I could manually re-arrange the nodes I could make it more readable but both solutions are all or nothing solutions.
While I don't get wrist pain all the dragging, manual graph editors are slow because it requires a ton of micro managing that's pointless, but once you have a graph setup it makes it really fragile to update based on feedback, a lot of time requiring significant rework for very little logical changes.
Possible in Mermaid, too; it deduces directions of connectors from the edge definitions so you can just swap the start/end nodes to shift things around.
I agree that graph layout tools could be much better. My main comment was to address what I felt was a blanket dismissal of the paradigm in the primary post.
I think the way graph layout should work in visual tools is that it should be domain-specific automated layout with user adjustment. However, the tools aren't anywhere close to that. And in fact, I have struggled to find existing graph algorithms for this stuff. None of the graph layout algorithms I have found can take user defined constraints as input, and they definitely cannot take local, manually adjustments. There's a lot of work to be done here, but it doesn't seem like anyone is interested.
What I've found all the mouse-based tools I've ever used exceptionally bad at were sequence diagrams, and I think PlantUML has won me over for those entirely. For block diagrams, still a mouse I prefer, like draw.Io.
What helped me most of the time if I needed one or two nudges to improve the layout was [0]. What is notoriously bad, but I think a dot deficiency and not PlantUMLs fault, is the order of components and packages, especially if you link between a package and another package's children.
I use plantuml and draw.io depending on the diagram. Sequence diagrams for example are very easy to do in plantuml no matter the complexity. Where I need more flexibility I switch to draw.io that I prefer over Visio. I find making connections between objects is better made, the stencils are also not bad and I can export a png or svg that includes the source.
It's clearly an exaggeration, but whenever any program wants me to click and drag stuff I immediately feel the struggle. The same reason I hate tools like unity where instead of simply typing my logic and data, one has to navigate menus and buttons, scrolling and selections, to do simple stuff (say, ctlf+f in a header file for configuration etc.)
I had wrist issues with LabVIEW. When doing a lot, I had to be very particular about my posture and equipment.
I had always wished they'd integrate those demos where there is no more manual layout. Pixel level layout, even with an auto layout shortcut, is just asking for people to waste time on it.
To note, I had coworkers switch to stylus input depending on the tasks (they had trackpad and a cheapish pen/tablet setup connected at all times, and left one on the side when not needed). Graphs and presentations were one of those.
On the carpal tunnel claims, I'd expect the author to be using a setup that is ergonomically massively more comfortable for typing than anything else. Basically the opposite of PC gamers who won't settle for meh ergonomics on their interfaces.
This seems to be a tad faster and easier to use that PlantUML/Mermaid/WedDiagrams when representing simple flows, or at least straightforward diagrams.
The main trade-offs I personally see:
- I actually want control over the layout. The goal of the diagrams is to convey info in a readable way, and getting a spaghetti when it becomes too complex doesn't help.
- Straight text base solutions allow for pattern replacements, snippets, whole copy/past from different docs etc.
- Aliases don't seem to be supported. Typing over and over the node names isn't fun.
Knotend supports copy/paste of subgraphs tosay. I want to also support things like pattern replacement, snippets, autocomplete (that creates nodes not just text in a node). Like a text editor.
I agree with your take on the layout. It isnt an easy problem. I’m looking at adding a grouping concept so the user can add more hints about the layout.
At work I've been using GraphViz and PlantUML, but we all have Visio Professional.
They don't make me want to throw my mouse. I can work on the diagrams in my IDE. There's next to no context switching. I write code to generate diagram markup.
The best part of tools like plantUML is that you get meaningful diffs between multiple iterations of a diagram. Haven’t tried it, but I’d imagine the source or generated SVG would be searchable as well, which is very nice.
It’s also more accessible than a diagram to someone visually impaired. And you can even dictate the contents of the diagram if you want to and your UI supports it.
In my view text-based is the way to go for most types of diagrams. Easy to source control and once you are used to the syntax, very efficient. Diagrams are code.
Yes, it does take some adjustments, but the same is true for typing. I use Logitech's ergonomic solutions for both mouse and keyboard, and it helps a great deal.
Most recent popular games (FPS, MOBA, MMO) make use of the entire mouse movement area.
However gamers are more prone to adjusting their mouse DPI for comfort. To some this means wide sweeps across the desk for minimal movement to maintain accuracy at the elbow. For others it means the slightest flick of the wrist sends the cursor across the screen for maximal reaction speed.
And of course many games don't use the mouse much at all still. I don't think you can really categorize gamer mouse usage in any way other than "comfort to efficiency ratio per task".
I'd expect gamers to be serious about their setup and adjust it to fit their body at best: mouse size, weight, buttons arrangement etc. same for the keyboard. Also gaming gear is usually better in almost every dimension.
On a different note, it's interesting to look at the pricier XBox/PS/Switch controllers through time, their goal being to fit as naturally as possible. And then we get round mouse pucks and straight edge phones from Apple.
It’s more about consistency. Whatever is comfortable comes first, and should be done at the same time as finding what works (i.e. is good hardware: good sensors, keyboards (and with newer custom boards some have strange firmware latencies likely related to denouncing(see the gmmk pro.))
Once you have something comfortable and good enough, the hard part is building the muscle memory and moving layers of the game into unconscious domains. Aim should fall below thought, and with time, understanding the state of the game and the potential space of options of (for example) positions of an enemy based on the state of the game and what information you have. These start to fall outside of what you may call conscious thought.
These are much more important than the gear you have, because the reality is there are millions of options for hardware and most of them are fine. The tool does not make the craftsman. They can be tools, for example, I have a separate desk for gaming and for work. If you mix the two, the space becomes less meaningful and does not have a single dedicated use. This is also why I use separate keyboards, separate machines, separate monitors, etc for compartmentalization within my mind, so that I can get away from work or get away from gaming. I also do the same with clothes. Work clothes have textures I associate with work, and use texture differences in clothing to get into home mode or work mode. Showers help for creating a state change. :)
Stock console controllers are an ergonomic nightmare because they are designed for a particular grip which is not used by people trying hard to be good at these games.
No, because games can be competitive and therefore there is an adversarial selection effect. If there is a motion which is hard then it follows that the other players will force you to make it. This isn't theoretical. It isn't uncommon for people to grow frustrated to an extreme while playing games against someone so much better than them as to make the contest nearly pointless. Even outside of that extreme regime of adversarial selection, just look up some OSU videos. Flowcharts aren't at all harder than gaming; they are pathetically, trivially, absurdly easy in comparison to gaming.
I tried this out for a bit and it was definitely interesting. For flowcharts that are closer to a pure tree it's blazing fast and simple to work with, more than anything else I can remember trying. Though for more complicated flowcharts that break out and remerge it can be very confusing to both edit or read. If the the tree-style or pure linear is more your use case I highly recommend trying it out despite its demo state, even if just to export the topology into a tool that will draw it fancier if this isn't "wowing" you on the looks side of things.
The "make a salad" example is an exception to the above but I think it gets away with it because the branched paths are of equal length and overall it's not too large. Once you get even slightly off this, like the Mars example where a branch is 1 box longer than the other, it can easily fall apart. Such branching and reconnecting topologies tend to result in things in the editor moving around on you a lot while you're trying to create the paths which can be disorienting as well. Other options such as code2flow which have already been mentioned here can get away with as much on the fly restructuring as they want because they separate graph construction and graph representation in the UI whereas this combines them. Maybe an option here would be a toggle to disable overall graph auto-layout but keeping the keyboard shortcuts and auto default placements? Or maybe it's just best to focus on where it's unique.
An "easy win" feature add for knotend might be a set of shortcuts to change the symbol and maybe some automatic ones like terminals or decisions that get set based on their connectivity in the drawing (unless otherwise manually set). As it is now everything is a rectangle which typically means "process" in flowcharts.
In terms of the lines crossing, you’re right I have to work on the algo. It’s just not been something I prioritized because its not often a problem until you get into larger graphs.
I’d like to avoid manual layout because I haven’t found a way to support that without sacrificing speed. But I dont disagree it would be nice if theres a clever way to do it.
Love this. I think we are missing a UI paradigm for visualizing and editing graphs effectively, and I love seeing stabs at the problem. It is absolutely insane that dependency graphs aren't a first-class feature in all issue trackers. The fact that graph visualizers are so complex is probably a big part of it. I'm a fan of your approach because it's reusing familiar UX patterns that people already know, like making nested lists.
If you haven't already, you should check out Workflowy! You would be a fan of their design, since everything is centered around recursive lists and operations on them. They also noticed that lists are isomorphic to boards, so any list can be shown (and edited!) as a board without loss of information. I could imagine a similar isomorphism from those lists to graphs, which knotend visualizes.
I had trouble using the tool though, here's some things I noticed:
* <Tab> doesn't work when the graph is empty, and causes the "Sign in" link to get selected instead.
* It feels like nodes can be in different states depending on if I'm editing the text, or just have it selected. For example, typing a name and hitting <Tab> does not create the child. Looks like the app is trying to mimic spreadsheets, so this is surprising. Same with <Enter>, I'd expect it to make a sibling whether I'm in editing mode or not.
* The curved connecting lines between nodes don't scale well, and look a bit strange. This is a big problem, because knotend has to work just as well with small or huge graphs. Given a node, I have to know which nodes are up- and downstream of it immediately. As is, it gets confusing the moment I have two sibling nodes each with disjoint/shared children. ObservableHQ handles this by highlighting connectors to the parent and child nodes.
Definitely looking forward to seeing how this grows! I think it's close, but for it to be as easy as writing lists, there can't be a distinction between editing and not-editing.
I’m still playing around with allowing the keyboard shortcuts to take effect even when editing a node. At the moment they conflict, like the option- prefixed ones. But I agree it could be nice to find a fluid way of doing it because it means fewer keystrokes.
Agreed. I wish dependency graph are more common than it currently is. I think the problem is it's much more demanding work than people are doing. You actually need to plan ahead and put them down on paper.
I made a tool for this if you'd like to use a dependency first project management tool! [1]
I love the goals here, and this can definitely work.
The current key shortcuts seem a bit wrong to me though.
A few issues:
- Tab is never ever used as a "create something" button. It's always "move between things". So this is the wrong choice. And making shift-tab create something in a different direction is completely unintuitive. Shift-enter or ctrl-enter or something would be better.
- It shouldn't be possible to have multiple created-but-empty cells. UIs seem to work much better when there is only one cell in that state. If you create one then move away from it before editing it, it should go away.
- Needs bigger visual difference between editing state and selected state.
Also, I'd suggest that there can be a preview mode that uses pretty layout (non-grid based) then edit mode which uses the grid.
The tool from TFA can export to Mermaid. I've used Mermaid to lay out some DAGs to visualize prerequisites & parallelizable tasks in large projects, and it certainly isn't as fast to use as Knotend seems it'd be.
TFA could be Two Factor Authentication, but it does not really fit and I prefer to use 2FA. Searching online yields Database Availability Group for DAG, but I prefer to ask.
Mermaid is more of a WYSIWYM tool where Knotend is more WYSIWYG. WYSIWYM tools are quite valuable in the right contexts, but there's a reason why LaTeX never really threatened Microsoft Word.
> ... there's a reason why LaTeX never really threatened Microsoft Word.
Apropos of nothing, LyX[1] is a pretty good stand in depending on one's needs and tolerance.
There are some challenges if you need something that has more complex styles (e.g., customizing the Memoir book styles). These are well within the range of programmers and not super hard if you're reasonably competent and/or willing to search / read. The payoff is that you're forced into using styles instead of kludges, and you don't have to worry about layout (much) anymore.
I just spent 5 hours yesterday to make a flowchart with tikz on LaTeX.
Well the quality is excellent, but I made the same graph in 10mins on Mermaid...
And all this because SVG export was bugged (not valid syntax) on Mermaid to get similar quality.
I really like what you've done here, and I think it has broader applicability as an input/editing mode for all sorts of graph-like information.
I love the varied export options, my one suggestion is to be able to export or copy/paste some of the information into a more flexible, less marked up format - e.g. a text file, csv, etc. even if it means a loss of some of the information.
Why? A visual flow chart isn't always the (only) end product. Eventually you'll want to extract information out of the tree without having to parse or regex a dot / mermaid file to do it.
I went down this route back in the 00's with various mind mapping tools. I used them to explore projects, processes, sort out designs, think through problems. It was so quick to get relationships down and see the bigger picture.
But then I was left with a bunch of mind maps that I wanted to turn into other things, for example todo lists, project plans, document outlines, flow charts etc. The mind map software tended to export exclusively into either images or other mind map formats, so all that information was effectively locked up.
Sure I could write a script to regex what I wanted out of those formats, but why couldn't I just copy and paste the titles from the tree into a text file?
PlantUML is my favorite... but it is all texual. There is a great support for it on VSCode and Emacs for previews. I prefer VSCode to create my UML diagrams and Gantts (even though I am mainly Emacs)
I have started using mermaid to create flowcharts. It lets me break free from having to think about layout entirely. Plus, I can use my favourite text editor.
Graph layout is extremely complex and there is no good automated way to do it yet (or ever). Even specialized software like plantuml, cytoscape or gephi (depending on the kind you want to do) struggle on some graphs that a human can layout decently well by hand.
Coming from the computer networking space this is somewhere I've been hoping to see a big machine learning splash like language translation has seen since large network graphs are either a big ball of mess or out of date because it takes too much human time to keep up to date.
It seems no matter how complicated you make the layout heuristics or what kind of dynamic iterating system you use when it comes to large connected graphs they just look nothing like a human would make. I'm not sure how would would get a large enough quality training set but it just feels like something that could be better done by machine learning than further manual definition.
The tool from TFA also breaks the user free from thinking about layout entirely, and can export to Mermaid. It's a pretty fancy-looking way to _quickly create_ a graph that I plan to try instead of manually typing Mermaid syntax next time I need to make one.
Had a play with it, and it has great promise. I love that the keyboard interface is given priority.
I have a a couple of thoughts around the interface that might (?) be useful. I absolutely realise this is a work in progress, and you may already have these in mind. :)
* A keyboard shortcut to bring up the right click/edit menu. There's the existing menu key on non-Mac keyboards, which is probably the best thing on non-Mac keyboards to hijack.
* There doesn't seem to be any easy way to pick nodes that not right next to each other and or delete connections. ie; Something that emulates holding down control, and clicking on multiple items (or even just two).
* Potentially, a way to search in the graph using the node text. ie; hitting / would create a search box, which typing it would select the subset of nodes that have text matching the search text, which could be use to select from.
This is cool, but I've given up on visual editors for graphs long ago.
Graphviz and, more recently, mermaidjs, have been very useful for me for all my diagram needs.
I'm not sure I understand the underlying problem being that most tools are too mouse intensive, for me, the issue is that there are shortcomings that make it so that you need to use the mouse a lot and which don't need to be solved with a keyboard.
For example, if the tools could shift stuff around so that boxes don't overlap, I won't need to spend ages shifting stuff; if when I link one box to another with an arrow, it doesn't weirdly snap to different places on the box, then I wouldn't need to fiddle with it to try and separate/combine lines; If I could set the mode to curved connections (mindmap style) or square (all lines are angled by 90 degrees) then it would lay things out well.
It might suit a different use-case than what I think of as a flow chart though so hope it helps people.
I just use a pen and notebook and take a picture with my phone to share it. No software has ever been able to let me switch between drawing boxes, drawing arrows, and writing text as quickly and accurately as I can with a pen.
FWIW, I 'whiteboard', flow chart and everything using google Sheets.
It's not pretty for presentations, but it works really well for engineers in many situations where the flow isn't super complex (think 2d-array instead of tree w/ many branches).
But if you want more tree like structures - there are a number of mind-map software that can change the representation to tree AND have keyboard navigation and control. Freemind being one.
I once used a tool called "PAP Designer" ("Programm AblaufPlan" Designer), which had a great system for allowing you to put new boxes. But I am not sure it still exists and fullfils the all needs, as a plain flow chart might not be all you need. You might want to add comment boxes and stuff. Otherwise I usually use yEd Graph Editor and haven't found anything better and lightweight yet.
I want a flowchart editor which doesn't give me carpal tunnel but I also want (some) control over the layout.
So far Graphviz is the closest. Plain text in, flowchart out. I would say "you can't beat that" but I think that you actually can. I think that it is possible to create a good interactive tool for editing DOT, it's just hard and probably would be pretty niche.
Fully agree with the problem the article says. This is why I also built Recall [1] (shameless plug).
Constraints goes a long way. Auto layout and grid like structure helps to make things neater. I don't see a problem in using a 2D canvas to show these dependencies.
But the issue is that the typical flow doesn't really match how we think. For example, we think about what needs to be done after X. Meanwhile the typical flow is: Write X, then Y, then connect the arrows.
From building and using Recall, I also found that we (at least myself) don't always think linearly. I often need to add or remove tasks in the middle.
Most often, I am already working on a task when I realize that something else needs to be done. Or I put a note that something needs to be done later.
If you're interested in this kind of project management, I'd love to get your feedback on Recall. I'm also constantly improving the experience so let me know if you'd like to be updated!
Over last 10 years have used Freemind & (last few years) Xmind to kind of make superfast flow charts in the tools dressed as mindmap tools. So i can see the appeal of knoted here for quick jotting down of thought flows.
But have also enjoyed making nice diagrams in mermaidjs especially the sequence diagrams. Prefer markdown to digram for code maintainability. Was recently seeing a youtube talk from C4 author on composable diagrams and agree to a lot of what was said in the talk. Src: https://www.youtube.com/watch?v=Za1-v4Zkq5E
Keyboard to diagram is much faster than mouse based diagram tools and have found them better for long term use cases. Quick diagraming in excalidraw or figjam doesn't hurt though when brainstorming especially with not very technical folks as they can easily contribute.
I wonder though, how people really use stuff like this and what are the key things that make them find it useful?
I've tried different approaches and found flowcharts mostly only work for really trivial things, and even then only if there's a very strict hierarchy (which almost nothing actually is).
Get into even a single module of code (never mind the whole system) and a chart at any significant level of detail becomes an illegible mess. At best just an image to gloss over in a slideshow to try to look impressive, without actually trying to explain anything. Anything with any complexity needs a wikiweb of details and relations. And that's a mess to maintain.
But I do love the idea. And making it simple and easy to do with the keyboard is great. Just wonder how people actually use it.
Breakdown notes also comes with some helpful keyboard shortcuts to not use the mouse as much. This was added not so much for flowcharts, but to make it easier to write notes quickly.
-Tab to add a new figure on the canvas
-Enter to add a new paragraph in the shape
-Arrow keys to move a figure
-Shift arrow to move between figures
For me, the lack of speed in creating the dependency graph has never been an issue. The issue when it comes to flowcharts has primarily been creating the correct scope for the particular task, to have the right visualization tools to display my intent and to fill the chart with relevant information. When I have tools all of this, a high amount of conceptual information can be baked into a small and easy-to-access space. In my experience, "all" the info is very rarely required (which the speed-dependency-chart implies), since very few can process it anyways.
No specific strategy, I'm still trying to figure out what makes some diagrams better than others, and how to design diagrams which "works".
The one I've used which have gotten the most spread in the company I'm working at were is one which mapped the transformation of a specific state in the microservice architecture. The state in question is highly central to our products success, and it reflects many (but not all) the relations between services. The dataflow were from leaf entrypoints, through processing, and finally stopped at internal consumer endpoints. The result is a reversed tree structure where each node is a microservice/external service (text in node explains which one, and linked to gitlab project) and each edge said which protocol is used for them to communicate. So, it reflects what services are required for a specific customer, depending on which path the customer takes in order to produce this state for internal consumers. Doing this enabled us to also analyze the "hot path", and "cold path" to know what services were problematic (rarely used/overused/too poorly written considering their importance/etc) and not.
But in general, it needs to look nice. It should be pleasing for the eye to watch the diagram, should spark curiosity to investigate how the system works. Straight lines, consistent shapes for specific meanings, colour coded blobs. Directed edges also seems to work well. Once I told an ops guy "start here at the leaf, then follow the arrows", it really clicked for him. And at the end of the day, it's a frontend, with all it's ups and downs, and should be treated as such.
https://www.smartdraw.com/ - SmartDraw has done this for about 20+ years. I can draw entire flowcharts using keyboard shortcuts (although I still have to click a button for split paths) and everything is automatically spaced correctly / adaptively even if I delete shapes.
The other chart types I use this for are org charts, mind maps, and network diagrams which are all similarly automated.
Great idea, It’d be even better if you could add functionality for more complex diagrams, like what draw.io offers. In my OOP classes for every project I’d be assigned to upload a UML diagram, which is incredibly tedious to do with drag and drop software, especially for large projects. If this keyboard shortcut flowchart editor could support UML diagrams this would have saved me a lot of time!
If I may suggest a feature, It'd be great to have probability estimations of each of the node, and then the leaf nodes (last node in a stream of dependencies) would have its probability computed as the multiplication of all parents.
This would make it obvious when something is not gonna happen :)
And it would make it easy to detect which part of the chain with a low probability kills the entire chain :)
I'd like to add some kind of computational support, and you're right that probability fits pretty naturally. Do you know of any other tools I can take hints from? Or any domains/disciplines that need this?
This is cool. Being afk right now, I initially thought i couldn't use it on mobile but the menus and icons saved me.
The one thing i couldn't find a way to do is to multi select items on mobile.
I saw in the demo video it's possible with the keyboard on the desktop UI but unless I've overlooked some shortcut then it seems like it can't be done on mobile.
I suppose tweaking the menu/ icon sizes when it's recognised as being in a mobile browser might be an idea (or at least something to let the user toggle to/from slightly more mobile friendly sizing of icons) would be handy
Co-Founder of ShiftX here. We are building a flowchart/BPM/knowledge-graph hybrid. We also use a grid and support splits/loops/joins in a way where we try to optimize for readability. Feel free to try: https://shiftx.com. Feedback welcome!
I let my wife who is almost 2 times smaller than me to train her jiu-jitsu skills on my hands at moderate force/speed/pain - works like a strong massage/stretch for the joints and any carpal-tunnel like discomfort (more than 30 years with mouse&keyboard) is gone :)
Do you know of any tools that export to airflow? I’d be happy to implement it. Would you want to write python code in the nodes, or just the names of functions (or modules)?
while I like the user interaction, and while diagramming tools really do need this kind of quick way of creating diagrams, at the moment, this tools end result is not really that nice for doing flowcharts, and looking through the examples there really is nothing compelling, and some of the examples seem a bit odd ( like the onboard customer example). As this demo gets expanded, it will be interesting to see if it can stay simple as things like conditional paths / loop back mechanisms are created. If that's not the intention, then this is more of a tree builder than a flowchart editor. A simple example I'd like to see is a flow chart for traffic lights / pedestrian crossing control system.
Right now its geared towards right-to-left directed graphs. Probably because most of my use cases have to do with time (like project timelines). So the state machine you mention towards the end isn't an immediate goal because a) it probably needs nested states, and b) it probably has tons of cycles which knotend doesn't do great at the moment.
No, you need the lightest wired optical tracking mouse you can buy which is the right size for your hand to rest on. Forget wireless mice with the added weight of batteries, these will increase your carpal tunnel syndrome!
Graphviz has a syntax for directed graphs, it’s fairly intuitive. Not sure why it couldn’t have a text box on one pane and an immediate graphical view on the other.
(in on a phone atm) the example video needs enough complexity to make it worth using the tool. Its simple enough to understand that i think you can do the full tutorial as the demo.
http://webgraphviz.com + add an on-key-up event to the text area that clicks the button = my favorite graphviz editing experience.
if you're doing anything more complicated by hand than you can achieve in that kind of setup, you're likely better off with a more sophisticated dedicated tool / manually doing all of your layout. but I have yet to see anything else get even close to beating this setup for "zero to a usable diagram" time or effort.
Arrows will come. Shapes I'm still figuring out because I don't want it to interfere with the keyboard-centric ux it has right now. It helps to have all nodes be the same shape/size. But there may be some wiggle room to add simple shapes, like rects with a corner taken out etc.
Since all of the other comments are just people pasting links to their personal favorite thing that is tangentially related, let me be the first to say that this looks fantastic. I often run into the same frustrations that you're attempting to solve here, and for a demo version it looks like its in great shape. I will likely try to use this at work this week to take it for a test drive.
However, would it be possible to make the flow go vertically rather than horizontally?
I find that a vertical direction of flow is
- more practical because of the ubiquity of mouse wheels for easy up/down navigation compared to the various less common ways of navigating horizontally
- the much more common direction for sequential steps in programs or scripts
- more culturally global, since there are quite a few right to left languages (as in addition to the left to right language used on this site :-)
- distance between boxes is easier to keep constant vertically while still allowing different size boxes (due to longer or shorter labels)