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 iden

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.