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?
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.
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.
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.
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.
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’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.
Put mouse movement as high as possible.
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".