Hello people. Not sure if this is the right group for this question but I thought I will ask anyway. I wanted to see how will someone approach making a business case between two tools where the only difference between is that one of the tools offers a much better UX, but also comes with a hefty price tag.
More specifically this is between Google chat and slack. Let's assume that I am already invested in chat and getting enterprise slack seems like a very costly deal.
But on the other hand I feel that if the team uses slack then they are going to be happier which will likely increase their effectiveness and hence will be a good investment.
But the end results, if any will be a lagging indicator and with difficult to map to the team's usage of slack.
[Meta commentary β this is on-topic insofar as many of the improvements we strive to make to our programming practice will face this same challenge.]
Personally, I wouldn't make the case on the basis of happiness, since that's not generally valued by businesses, even if it does confer benefits to effectiveness as you point out.
You'd likely need to identify specific things that are measurable, or discernible, and speak to them. I don't know anything about Google Chat so I can't come up with a real example. But perhaps the better UX of Slack means you'd spend less time dealing with frustrating aspects of the chat system, and more time directly communicating and focusing on your work, not your tools. (Spitballing.)
Hard cost ROIs are usually enough. Soft costs are too murky to be of much value in discussions with anyone. Google chat is looking much better (just looked) than it did last time i looked at it, having a demo to make the case would probably help some of the folks who've been exposed to gchat years ago but haven't looked since.
I agree Ivan Reese that such challenges are there in many improvements we tend to make.
I see there been some progress on quantification of productivity with State of Devops report - 4 key metrics
I wonder if some effort like that could go to establishment of dev/team collaboration with productivity.
Thinking more about the wires crossing problem (from Adnan's "portal" conversation) that plagues every node and wire GUI tool after log 2, I was wondering if anyone has seen any great GUI tools that use a "Tube" model instead. The idea is nodes would always have a single parent, and a fixed x/y position, and be connected to their parent by a tube, in which unlimited wires might be threaded. Messages between nodes would have to route according to these layouts (each node would have routing capability). To see the exact connections between nodes, you would likely have to hover over a node and it's relevant wired connections could highlight. Does the EE world have GUI tools that follow a paradigm like this?
π· GraphsVsTubes.png
A thing about this that I immediately dislike is it's not clear what the meaning is for there to be a tube between A and 1 (and not, for example, between B and 1). It seems like having all of the nodes off of the root would be less arbitrary, but then you might as well not even have the root/tubes since they give no information.
Wire crossing in a node-and-wire language probably serves the same useful purpose as "code smells" in other languages: as a signal that you should refactor or that the level of abstraction of the nodes needs to be raised.
I definitely see the appeal of this approach. It sort of feels like a mix of two things..
I definitely won't balk at specifics of your example, since that seems like approaching the idea at the wrong level of detail. More broadly though: I think the thing that'd be required to make this work well is the same thing that'd be required to make regular old node-and-wire work well β a really, really polished UI. Now, it might be easier to do a really polished UI with something like tubes, since the concept might switch out some hard to solve problems (a visual rats nest) with some easier to solve problems (showing a subset of paths).
Neat to think about.
I think the secret to any good diagram is having close relationships between an underlying invariant/axiom/rule and some visual feature. This is what allows them to be learnt. For example, "if node A is to the left of node B, then B is not an input to A", "if node A is bigger than node B then it has more outputs".
In your tube example it's not obvious what these rules are, so while it's very uncluttered it's not (to my untrained eyes), clear.
Maybe if you moved the nodes so that, e.g., D was horizontally between 3 and 4, it would be obvious that D is NOT an input to 1, 2, 3 but it might be an input to 4 (hover to check)
I'll second @Jared Windover, I don't immediately understand this Tube Layout. I am sort of a fan of "nodes would always have ... a fixed x/y position." More than that, I really like having strong rules about orientation. Often you don't have a generic graphs, trees and DAGs are more common. Following the top left to bottom right flow suggested by your Graph Layout, we can choose to omit most of the arrows.
π· IMG_5792.jpg
The black lines are there to show non-adjacent connections. A different background color could be used to show edges that violate the normal flow.
Also messy graphs tend to arise when you have a lot of connections between two similar layers: a bunch of similar As all connected to a bunch of similar Bs. braiding edges or stacking nodes can help in those situations.
Lastly, long distance edges are usually a sign that the distant edge is being used as a word, like a library call, and its connection to the rest of the network is more tenuous.
Yeah from a UX pov I think it's much less readable than conventional node graphs.
Agreed with William, locking node positions does sound really nice, and some software like SpeedTree actually have (or used to? haven't used it in ages) that constraint: you're not allowed to move the nodes freely in the graph, you just add them as you need them, and the layout sorts their position for you.
Though to be fair, this software literally makes trees, which are just ideal for node graphs π
π· image.png
SpeedTree looks very cool! Don't think I've seen that before. Thanks!
A small feature that I have tried in the past, is "focus-mode".. when you select a node, that the directly connected nodes and wires are also highlighted and the rest of the graph is dimmed. In my current implementation I have to re-implement this feature, as it was quite helpful
Maikel van de Lisdonk we have something similar where if you drag a wire, we highlight all the nodes + wires in the graph that can accept the connection.
We did the focus mode thing but users often selected nodes to just check values or move them around, and the constant highlight/dim made the graph look like a Christmas tree at times π
π₯ B2SW7jBUGp.mp4
To get back on topic; Breck Yunits another issue that I noticed with the tubing model is that if ABC happen to need "2", in case 2 holds some value that they all need, all hell breaks loose π you suddenly get back to the wire crossing problem, which I'm not sure how this tubing model would solve.
A portal system could solve this, but portals are delicate and if you overuse them, which would be a necessity in this case, you end up losing the benefit of a tree structure readability, as a property called by the leaf could also happen to be used on a branch, root or anywhere else.
π· image.png
My understanding was that B would have access to 2 by following the tube back to the root, through A, through 1, and then to 2.
Adnan Chaumette Sorry the gray "braids" aren't very clear, but as Jared says there are wires connecting B to 2 (and so on) via the tube.
Which mental faculties are involved in programming? If we knew more about them, could we invent programming languages that were both easier to use and more powerful?
This is not a well-studied area, and very few aspects of programming languages, old or new, are evaluated formally for the quality of their "human factors" or "user experience". For example, among the features of artificial languages, there has been no attempt to separate experimentally those features that are cultural artifacts, from those that reflect our innate, genetically-endowed mental capacities.
From https://chomskyalexander.blogspot.com/2010/03/depth-and-innate-judgements.html?m=1
Has anyone come across other programming languages with a similar idea?
Dr. Andreas Stefik's research is on "evidence based" programming. Designed to create syntax based on scientific studies of how people program.
The Quorum language is the result of his efforts.
Dr. Stefik gave a good talk at Strange Loop about this a few years ago:
The literature* seems to indicate that the strongest correlation between in-born attribute and high levels of programming ability is working memory. This might suggest that reducing the need for working memory would be one of the best ways to make programming easier for those not "born to it."
(* This paper and its references would be a good place to start if you're interested in this sort of thing.)
Hi everyone! I'm adding (retrofitting) an asynchronous request processing (first server-side, then client-side too) to a Web programming language (webdsl.org to be specific). I would appreciate your suggestions and references to existing models, both syntactic and semantic. I'm particularly interested in mandatory timeouts and error handling, and compositionality. As long as request processing is essentially a FSM you can view the question as "nice and composable syntax for describing FSMs". π
Anyone have any recommendations for fun general purpose sim builders?
Specifically something visual, for multi agent systems. Say I want to simulate the behavior of some people at the beach, or the spread of a virus, or spread of a new idea, etc. Hash.ai is building something like this, and I'm excited about it. What else is out there? My goto now are still spreadsheets, but not as easy to communicate with
What is missing from https://hash.ai/ for what you'd like to do? I was about to suggest it. General purpose is the hard part - lots of nice domain-specific simulators out there for stuff like contagion, predator/prey, ecosystems, etc
NetLogo was the winner! Thanks. I had forgotten about itβexactly what I was looking for (and this list: https://en.wikipedia.org/wiki/Comparison_of_agent-based_modeling_software).
Using this form to think aloud. I just came across a really old note about IUPAC naming in chemistry. Maybe particularly in organic chemistry. I wondered if there is a similar naming standard in the world of software. If so can someone point out to me?
It does not have to be successful or adopted. Iβm just looking for some effort that might have gone into this direction.
Do you have a good link where those unfamiliar with IUPAC naming can learn what it is?
I don't think it is possible. In chemistry, you know what your elements are. In coding, you don't, there could be many different ones. You could just name all your functions based on a lambda calculus like SKI and then name them according to their implementation, but almost every function of interest can be implemented in multiple ways. And there is no (general) way to figure out if two implementations are equivalent.
Put differently: maybe it is possible, but if it is, we haven't figured out the foundational science needed to do something like IUPAC.
What one could do is to have names that are not meaningful and build a catalog of IDs to functions, but that's very different from IUPAC.
I think it would be an interesting exercise @Dhruv Kapur! You should go for it. I can't think of any off the top of my head. If there is one, I bet Mathematica would have incorporated it.
Looks like IUPAC was formed in 1919. If you were doing something similar today, you could do it on Git, and make your standards in a computational language.
Off the top of my head some of the meta categories would be:
`*NumeralMap
*BooleanOp
*Machine
*Lang
*Function
*CharacterMap
*Pattern`
