[HN Gopher] Displaying Content as a Graph
       ___________________________________________________________________
        
       Displaying Content as a Graph
        
       Author : serverlessmom
       Score  : 23 points
       Date   : 2024-01-01 19:52 UTC (3 hours ago)
        
 (HTM) web link (thisisimportant.net)
 (TXT) w3m dump (thisisimportant.net)
        
       | thom wrote:
       | Just don't. There's no real use case where people need to
       | perceive this graph. It's embarrassing to see the dreadful
       | redesign of the C2 wiki shown here - the original wiki, no less!
       | - which basically made it unusable. Hypertext is one of the most
       | successful UI paradigms of all time, don't overthink it.
        
       | thih9 wrote:
       | I guess we're used to dealing with non-hierarchical data in real
       | life. I have a shelf of books, some list of movies, and a stack
       | of documents.
       | 
       | Popular platforms are already prioritizing "recommended" views
       | (as opposed to nested or hierarchical lists). With ai assistants
       | and vr becoming more popular, I could see graph UIs following
       | too.
        
       | Veuxdo wrote:
       | Graphs work really well for displaying relational data if you can
       | get labels on all (or most) of the arrows and you can zoom in /
       | change perspectives to see different relations between the same
       | nodes.
       | 
       | Graphs with unlabeled arrows can still be useful, but not without
       | someone there walking you through what the arrows mean.
       | Otherwise, when embedded in an article, they're not much more
       | than stock imagery.
        
       | aworks wrote:
       | The article mentions Glenn McDonald's musical genre page
       | (https://everynoise.com/, no longer refreshing with new Spotify
       | data) as an example of a flexible graph-like exploration format,
       | without being burdened by explicit connections.
       | 
       | The author also has a thorough description of pros and cons of
       | the general concept.
        
       | CrimsonCape wrote:
       | The article ends with classifying the challenge as a UI problem
       | and doesn't explore the underlying logical design which is not a
       | UI problem.
       | 
       | As the author identifies, a graph of all permutations is useless
       | to a user.
       | 
       | And, as the author identifies, a hierarchy provides some
       | organization.
       | 
       | Hierarchy and graphing are not equal. Hierarchy is a subset of
       | graphing, where binary weight has been applied to the direction.
       | 
       | For example, given the set [Foo,Bar], we get the graph with equal
       | weights.
       | 
       | Foo <---> Bar
       | 
       | If we want a hierarchy, we give full weight to the edge:
       | 
       | Foo ---> Bar
       | 
       | Given a set and a graph with a weighted edge, we have a
       | direction.
       | 
       | The challenge is to dynamically weigh the edge. In reality, an
       | edge with a binary weight is useless. For example,
       | 
       | Foo <10%------90%> Bar
       | 
       | is a more realistic weight, as in computer programming Foo Bar is
       | almost always the intent, unless the intent is to search a
       | `.Reverse()` method, in which case Bar Foo makes more sense and
       | the most common weight is not valid.
       | 
       | However, to the author's point, neither the programmer nor the
       | user know the optimal direction between vertices to arrive at the
       | ideal path. The challenge is to generate a state machine in which
       | the weights are dynamically adjusted as the user navigates the
       | graph, resulting in the optimal direction. The best we can do is
       | to analyze the input of other users to generate weights. "Crowd-
       | sourced" weights.
        
       | tbwriting wrote:
       | wikipedia! https://wikijumps.com
        
       | Agraillo wrote:
       | Wikipedia has categories that from what is perceived, should form
       | a DAG (Direct Acyclic Graph). But very often they don't. I saw
       | this with my own eyes when tried to implement "DagView" (a visual
       | control trying to navigate DAGs similar to trees). So you keep
       | opening sub-categories and one of them suddenly is a super-
       | category noticed before. This indicated for me that despite the
       | fact that DAGs have luxury of having many "parents" it doesn't
       | make things easy in the heads of those who try to work with them.
       | Probably our brains are not very good at dealing with non-
       | hierarchical structures
        
       | lmeyerov wrote:
       | This is a great article and fun to see fundamental concepts get
       | (re)discovered here!
       | 
       | A perspective that we can generalize from the hierarchy
       | discussion is to think about tool-for-the-job: what is the
       | 'content' job, and what 'jobs' graphs will do? We think about
       | this a lot as we work on problems like how to make it easy to
       | explore 100,000X+ more relationships on screen than they're
       | showing: https://github.com/graphistry/pygraphistry .
       | 
       | First, what do graph visualizations do?
       | 
       | - They let us see the relationships in data. The article
       | discusses hierarchy. But there is also progression, root cause,
       | scope, and basically any correlation/causation relationship ML/AI
       | figures out.
       | 
       | - They let us directly manipulate the nodes & edges, such as for
       | drilling down, navigating, reclustering, etc.
       | 
       | - A useful 'aha' is thinking of modern information visualization
       | as trying to optimize some sort of time-to-insight through a
       | sequence of visual interactions. So each view must be information
       | dense for visually revealing certain insights, and make it easy
       | to get to the next set of visual Q&A.
       | 
       | - Ex: When the entities are the interesting thing wrt questions,
       | being able to drill down into individual nodes/edges into great
       | dedicated views becomes important, so graphs get to need to be
       | multimodal. And if the relationship aspect is unimportant... then
       | graph view hurts more than it helps.
       | 
       | - From optimization perspective, it now makes sense to specialize
       | for specific domains. Maybe what is needed is more of a small
       | diagram, and not actually investigating a lot of relationships.
       | Or a graph of subway stops, which has additional visual
       | considerations. For a website, a sitemap navigation vs
       | clickstream product analytics view would likewise need
       | 
       | A good analogy is a map. Sometimes exploring Google Maps is
       | great, and you drill into a business inspector sidebar or down to
       | a street view. But other times, it's better to have the map
       | embedded into Yelp.com restaurant entry when you just need a
       | quick view of mapping information as part of some broader
       | context. Or you don't care about that map at all and can skip it.
       | 
       | Given all that.. it's interesting to revisit asking... what is
       | the 'content' job to be solved? What kinds of content lean
       | towards graph, and which don't?
        
       ___________________________________________________________________
       (page generated 2024-01-01 23:00 UTC)