> 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.
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?