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
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.
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.
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.
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.
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.
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)
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.
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’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.
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.
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.
> 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'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.
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".
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.
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.
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.
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 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.
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.
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.
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.
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.
>>> 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.
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.
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 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 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.
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.
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.
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.
> ... 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.
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)
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.
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.
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.
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).
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.
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.
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.
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.
"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.
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.
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.
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 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).
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.
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).
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.
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.
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 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.
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!
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?
189 comments
[ 2.2 ms ] story [ 230 ms ] threadThe 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.
https://github.com/mermaid-js/mermaid
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.
https://sketchviz.com/flowcharts-in-graphviz
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.
0: https://flowchart.fun/
1: https://sourcetarget.email/editions/43
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.
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.
I’d definitely be interested in that!
https://dreampuf.github.io/GraphvizOnline
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 made a tool for this if you'd like to use a dependency first project management tool! [1]
[1] https://recalllab.com
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.
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?
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.
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. :)
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".
Put mouse movement as high as possible.
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.
[0] https://crashedmind.github.io/PlantUMLHitchhikersGuide/layou...
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.
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.
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.
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.
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.
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.
Tiny text, ugly colours, incomprehensible patterns, totally random alignment, etc. Looking at [this](https://upload.wikimedia.org/wikipedia/commons/f/ff/LabVIEW_...) would give anyone a headache.
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.
> 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.
Ok is this any better?
https://ni.scene7.com/is/image/ni/597f9f24966?scl=1
Still looks awful, and that's from the official documentation.
> LabVIEW has several features over text-base languages as well.
Really? Like what?
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.
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.
https://mermaid-js.github.io/mermaid/#/
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.
And all this because SVG export was bugged (not valid syntax) on Mermaid to get similar quality.
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.
[1] https://www.lyx.org
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)
However, I think more research and experimentation are needed.
And phones are portrait and web browsers all naturally want to scroll up and down.
The Git graph tools are vertical because terminals naturally scroll up and down.
So all my hand-drawn graphs are vertical, too. Top to bottom, just like code or very narrow prose.
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.
I’m not sure if anyone’s testing the UX of these or whether designers are just following convention from other tools, however.
Speaking of signal flows, I've almost never managed to put together a flow graph in gnuradio companion that wasn't a visual nightmare.
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.
https://en.wikipedia.org/wiki/DRAKON
[0]: https://github.com/stepan-mitkin/drakon_editor
[1]: https://github.com/stepan-mitkin/drakonhub
[2]: https://github.com/stepan-mitkin/drakon.tech
> - 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.
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 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.
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.
> A keyboard shortcut to bring up the right click/edit menu.
Ya that would be cool
> pick nodes that not right next to each other and or delete connections
If you right click on a connection (line) you can delete it. You can also cmd+click to expand the selection to multiple non-adjacent nodes.
> a way to search in the graph
Ya that will be necessary once these graphs get huge. I'd like to do a search-to-scroll feature where you can jump to nodes that match.
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 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).
- [0] https://www.knotend.com
- [1] https://news.ycombinator.com/item?id=27256861
- [2] https://www.knotend.com/waitlist
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 ;)
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.
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 love how you can use the tools without first giving any information about you.
> I'd love more feedback especially about any UX issues.
Embarrassingly, it took me a moment to understand what the ^ sign meant in shortcuts.
Alt + L is "Ł" in some keyboard layouts (namely Polish (programmers)).
I suppose KeyEvent.location combined with default prevention could help here: https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve...
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 ÑÃÕ.
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.
If it ever becomes worthy of your time I'll put it on https://withoutdistractions.com and add a separate reply here :)
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.
[0] https://github.blog/2022-02-14-include-diagrams-markdown-fil...
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!
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?
Yep thats a critical piece
https://www.knotend.com/waitlist