Re: A stacked bipartite graph visualization and traversal UX
New here? Learn about Bountify and follow @bountify to get notified of new bounties! x

This is a reposting of this
bounty/contest to give those trying to fulfill it a bit more time. The original bounty tipping promises remain unchanged. I'll paste the original below...

I'd like a Javascript+CSS graph visualization and graph browser/traversal UX.

My base bounty is only $25, but I do plan to tip the winner more than $200 (if allowed) for a
good/compelling solution. I'm seeking a result worthy of that value.

The solution need not be a complete implementation, but I would like to see enough of the design implemented to prove (or disprove) the concept and to prove that a compelling version of it can be implemented in HTML + Javascript and CSS.

You may do this with React or whatever is your favorite client-side tool. Whatever
you are comfortable with is fine as long as the solution is basically

To make this long textual description a bit easier to understand, I'm linking to an image that characterizs the data model described here. My image hints at some of the components of one possible solution, but feel free to think creatively based on the description below. (To save yourself time, if you are uncertain that I'll value the direction that you have in mind, please do contact me for feedback.)

Something that simply implements what is in this image is not sufficient because that image is ugly, static, and does not deal with the complexities of rendering sections of an arbitrarily large recursive data structure in a limited visual space. See other requirements below.

Here's that link:

Also see the link to a more visually appealing rendering lower in this description.

The graph to be browsed consists of "A" nodes and "B" nodes.

"A" nodes have 1, 2 or (very rarely) 3 outgoing edges to child "B" nodes below.

B nodes have tend to have zero to eight outgoing edges to child "A" nodes below them. That number of outgoing edges can be as high as 100, but generally there will be zero to eight child nodes. At least 4 should be able to fit on the screen without scrolling. If there are child nodes than can fit on the screen, it is valuable to have some sort of "more" interface for pointing out that there is more and suggesting how to see those. That "how" might be as simple as scrolling to the right or left to see what is off screen.

Each of the B nodes will have some text associated with it. That will tend to be about 100 - 200 characters. That text should be readable or partially readable. If only partially readable, at least 60 characters of that text should be initially visible and a trivial gesture/action by the user should render the rest of the text.

"A" nodes will not have any text associated with them. With that being said, it is important for the user to be able to visually distinguish between sibling "A" nodes. What distinguishes one "A" node from its sibling "A" node is the "B" children that each has. So... it is imporant for the children of that A node be located physically close to that A node so that the user can quickly see the text of those B nodes. (See the example link below demonstrating one way to do this.)

B nodes will tend to have zero or one incoming edges from parent "A" nodes from above but might have more. Potentially, many more. If there is more than one, the UX will primarily render one of those and provide an indicator that there are also alternative
parents that can also be explored. The solution should demonstrate how interaction with that indicator can be used to traverse up to a different set of ancestors.

"A" nodes will have exactly 1 edge coming in (from a parent B node above)

As I have mentioned, B nodes tend to have zero or one incoming edges. There can be more though. But usually if the user has recently traversed down one of those edges, there's a reasonable chance they'll want to traverse (or "pop") back up that one (rather than back to a different parent). Nevertheless, the UX should provide a way to explore those other back edges to other parents (occasionally) as well.

The edges themselves have no particular attributes. You do not need to label them as "child" edges. (I used the word "child" and "parent" here just to simplify the explanation.)

Most of the time, these graphs are directed acyclic graphs. Nevertheless loops are possible, but rare and indicate an error in how the graph was built. Extra bounty credit can be earned by providing a way to indicate the existence of a cycle, but please do not sacrefice the more common "tree" user experience to create a way to highlight errant cycles.

In the absense of cycles the graph (aka cross-linked tree) rarely is taller than 10 hops (5 x B and 5 x A). Six (3 x B and 3 x B) and four hops is more common.

What I would like to see is a user interface that allows a user to "drill down" to see children and children of children, etc by "scrolling" down through selected children. And be able to return to or visit parents by scrolling up. When scrolling up there should also be a way to visit alternate parents, but that way need not be as natural as simply scrolling up to see the (currently preferred) parent and ancestors.

There should be a view that shows just a B node (near the top of the screen) and (most of) the child B nodes below. At the edges of the view there might be user interface indicators of what one would see if one scrolled in that direction. If it seems to provide a superior ux, the this rendering should initially resist scrolling. (This resistance to scrolling will earn extra bounty credit.)

One should be able to zoom out from this view to see more than one level of the tree at once with some loss of detail. Ex. One might not be able to read the text within the B nodes when zoomed out. If zoomed out sufficiently, the user interface to visit alternate parents might also disappear.

I've spoken here of parents being above children, but if you decide it results in a better solution, it is equally good for the graph to be rotated so that parents are on the left and children to the right. This might help with the fact that the text is probably most naturally read from left-to-right and require a wide box for the B nodes.

This user interface should be visually appealing.

It should be possible to render it on a typical 2018-vintage mobile phone screen oriented in the direction of your (not the user's) choice.

It's behavior on a laptop browser should also be reasonable but need not be as good as the phone experience.

I'll provide another sample here:

This is sufficiently visually appealing but it lacks a lot of the details above.
- It is static.

- It does not demonstrate what happens if the text is long.
- Two of the children of the top B node are not rendered and there is no visual indicator of how to view them.
- It does not demonstrate how to zoom out to see more layers of the tree/graph.
- It doesn't suggest a UX for scrolling up to alternate parents of that top B node.
- It doesn't suggest how the user would focus the drill down scroll on one particular child to avoid microscopic text and boxes in lower layers.
- etc.

BTW... the example uses arrows and they are pointed in the wrong direction. You don't need to use arrows at all.

Thanks. Please contact me if you have questions or suggestions.


PostScript: Licensing

This bounty does not require that the code you use have no license restrictions on it, but I will reward 10% less if it does. Apache and MIT license are absolutely fine. What this bounty does require is that there be no known patent / intellectual property restrictions on the user interface concepts that your code demonstrates.

PostScript: distinguishing A nodes and B nodes

The solution must render A nodes and B nodes in a way that the user can quickly identify if they are looking at an A node or a B node.

PostScript: Go.js

Go.js has some very impressive capabilities. That team has clearly created solutions for a lot of interesting problems. With that being said, none of the solutions I see on their web site satisfy this bounty, out of the box.

PostScript Go.js IVRTree

The Go.js IVRTree demo is pretty nice. I will point out some shortcomings relative the requirements of this bounty

  • It does not demonstrate visual distinction between A nodes and B nodes.
  • It does not demonstrate long text for the B nodes.
  • It does not demonstrate the ability visit an alternate parent.

It does hint that use of +/- button unfolding/folding could be valuable here for managing screen space.

It does demonstrate support for scrolling right and left.

It does basically work in a mobile browser.

hi @jasonnet, i have posteda solution a day ago for this bounty, could you check it?
Chlegou 10 months ago
awarded to Chlegou

Crowdsource coding tasks.

1 Solution

Hi there,

Here i'm finally posting for that bounty. i started from the IVRTree i have mentioned in last bounty, the biggest problem i have encountered, was the looping in folding/unfolding action. by finding a solution for that, everything was working smoothly.

i have made a simple tutorial, that demonstrate, what you mentioned in last bounty:

  • distinction of A & B nodes: starting by adding a category attribute, to the node objects, that will handle the node types. demo have NODE_A && NODE_B.

  • solution for unfolding /folding in very complex loops in graph. it hide shown child elements when collapsing.

  • long text in B nodes: B nodes can have an optional description in them, so if exist, it's shown.

  • visiting alternate parent: just to demonstrate, i added a function, that will scroll to a node in the graph. with that, nodes could be listed, next to the graph, with ability to filtering node and navigating on click. it's UX and javascript, nothing is related to the GoJs Library, (in my last project, we have this functionality, since we have a really huge graph/

  • other options, you already wrote them, regarding the default IVRTree solution i suggested.

Here is the demo link:

i hope this is what you really want, as i said, it's only a default demo, that demonstrate functionalities, we can add any customization we want! ;)

FOR CREDITS: GoJs provide that plugin for personal use only, not for production or distribution, if this is your case, so you don't have to buy the library.

waiting for your response.

Thanks Chlegou. I looked at this briefly the day you released it. I'm trying to evaluate it both from what it teaches me about what can reasonably can/should be done... and also to evaluate how closely the challenge was achieved. I know that I wasn't happy with how the cycles seem to be flagged with long arrows that travel across much of the graph visualization. I'm still hoping there's a less distracting way to flag that. I think what you have done is useful in suggesting how we probably don't want diamond graphs to be rendered like this. Instead I think we'll probably need to have a simple drill down and avoid so clearly indicating the details of the diamond unless requested. (Those diagonal lines seem distracting.)
jasonnet 10 months ago
Both of these probably suggest that we instead need some small indicator that this B node exists elsewhere as well. Or maybe we should do that only in the case of loops. I think this also demonstrates that we'd probably prefer that the graph not be fully expanded when first rendered and instead the user needs to hit the "plus" buttons to drill down where they are interested.
jasonnet 10 months ago
Hi jasonnet, as I highlighted in the bounty, its just a default demo, to demonstrate functionalities, you can see advanced functions in the gojs samples. For the arrows also, could be customized. I didn't want to advance in the prototype, unless I know if you want that or not. knowing your use case, I could give better example. I suggest you examine all gojs example, definitely will help you out with that.
Chlegou 10 months ago
Those are all negative examples and still possibly valuable. As a positive example, I think it demonstrates a reasonable way to handle long text strings. OTOH... when we have long and small boxes next to each other, the visualization is less appealing but it's not a disaster. Hopefully we can find an even better way. == GoJS's support for moving nodes runs in to all sorts of problems, but the very idea of it is interesting and it might be worth investigating a better way.
jasonnet 10 months ago
The small indicator mentioned above might be similar to the small indicator for alternative back edges. I'm pretty sure we don't want to bring a lot of attention to them because it's probably 10% of the time that someone traveling backwards would care about those. Nevertheless, it's good to a have a way to explore alternate back edges. That's why I'm thinking it needs to be small.
jasonnet 10 months ago
Ok, if you want, you have my email in the last bounty solution, feel free to contact me (by my profile also), we could have a call, I believe it helps more understanding your case. We could give customization a try or even trying something else.
Chlegou 10 months ago
We could make the lines thicker, and/or/and-or minimize arrows, then problem solved
Chlegou 10 months ago
Hi @Jasonnet, i have received a notification for the bounty. first, thanks for rewarding it, and for the tip. i wanted to ask, if you really managed to work with it, or what was your final decision? As i said, we could customize it, for a better UX. i waited for your decision, and if you will contact me privately or not.. anyway, feel free to contact me for future work or improvements.
Chlegou 9 months ago
Hi Chlegou. I emailed you on Sunday. Hopefully you received that. If not, let me know and I'll resend that note.
jasonnet 9 months ago
I didn't receive any private emails, from you. Please resend it using my account or directly to my email:
Chlegou 9 months ago
Okay. I just resent it.
jasonnet 9 months ago
@jasonnet, I don't know if this is normal or not, but I also didn't receive any email related to the bounty project Yet! Try to send me an email, using the contact area in my profile (under General tab). Or if you're adding some attachments to that email, try to delete them. Or use the email sent in the last comment, and send only a welcoming email, just saying hi, if I receive it, I will reply back, then we start talking about the bounty. Or you could reveal your email here in comment, and I will try to get you back, in a way to get in contact. Later on, you could delete that comment, to hide your email. .... if you have Facebook, I could send you my profile, and you message me you email privately, to my profile.
Chlegou 9 months ago
I received the bounty email, and sent you one, reply to it to confirm receiving it.
Chlegou 9 months ago