elk VS jQuery-menu-aim

Graphviz is the classic option but unfortunately it isn't very good. I mean it was great when it was written in the 80s or whatever but then it seems like it was declared "done" and is still stuck in the 80s.

Quite annoying because it totally dominates the mindshare of graph layout tools, making it difficult to find alternatives.

Here's some other options anyway:

* Eclipse Layout Kernel: https://github.com/eclipse/elk

* OGDF: https://ogdf.uos.de/

In fairness both their websites are pretty terrible (would some examples kill you OGDF?) and they don't provide an easy way to try them out, so I guess it's not that surprising that Graphviz dominates.

Anyway in practice if you have a complex graph then doing it manually is by far the best option.

If it's too big to do manually then it's unlikely to be a useful graph in the first place.

The issue I have with a lot of these tools is they work fine when depicting relationships between tables in the same schema (talking mainly about PostgreSQL databases), but few support showing relationships between tables across different schemas.

Also, when the number of tables grows large, few have layouts arranged in an optimal way. I use D2 (https://d2lang.com/) to create ERDs. However, of the free layout engines available in D2, Dagre (https://github.com/dagrejs/dagre) and ELK (https://github.com/eclipse/elk) both don't have optimal placement of layouts for a sufficiently complicated database.

The way to get around this is to do something like the Amazon Menu Hack

I move diagonally to an item in a submenu, and on the way there I accidentally open a different submenu and click an item in that instead. (This is ironically easy to do with the top-level menu on ixda.org, for example.) A rudimentary CSS-only fix for this is dead-spacing part of the route into a submenu. The usual JS fix, meanwhile, is to apply a delay to any hover-induced closing of a submenu, but that makes the rest of the parent menu laggy. The classier fix — pioneered by macOS, popularized by Amazon — is putting an imaginary rubber band around the submenu and its parent item, and applying a delay only in the part of the parent menu that would be inside the rubber band, letting the rest of the menu respond at the usual speed.

And the plugin: https://github.com/kamens/jQuery-menu-aim

>So what exactly did we lose? It's quite simple: by moving software into the cloud and turning them into web-based SaaS offerings, many of the basic affordances that used to be standard have gotten watered down or removed entirely. Here are some examples:

>Menus let you cross over empty space and other menu items, instead of strictly enforcing hover rectangles.

I met the guy who implemented that feature, Frank Leahy, when I was working on a project with Current TV. He rewrote the Menu Manager for Mac SE and Mac II. We were reminiscing about how great the original Apple Human Interface guidelines were, and I mentioned how it actually documented that subtle feature, and he told me he was the one who implemented it, and that he was touched that somebody actually noticed and appreciated it as much as I did.

https://bjk5.com/post/44698559168/breaking-down-amazons-mega...

https://news.ycombinator.com/item?id=17404401

DonHopkins on June 26, 2018 [–]

The comments are actually great -- even Tog weighs in! It also mentions Frank Lehey, who rewrote the Menu Manager for Mac SE and Mac II.

Jake Smith • 5 years ago This was first implemented by Apple's HID team back in the 80s, specifically Bruce Tognazzini, I believe.

Bruce "Tog" Tognazzini Jake Smith • 5 years ago Yes, I did invent it back in 1986 and it is firmly in the public domain. From what I remember, it was Jim Batson who worked out the math and coded it for the Mac OS. The OS X team later failed to copy the algorithm, so I am happy to see that amazon has resurrected it.

Josh Davenport Jake Smith • 5 years ago I think it was yes. It looks like it was originally implemented by NeXT and then removed by Apple when they bought NeXT. Tog himself talks about what happened here: https://www.asktog.com/columns/022DesignedToGiveFitts.html in the answer to question 6 - "When I specified the Mac hierarchical menu algorthm in the mid-'80s, I called for a buffer zone shaped like a <, so that users could make an increasingly-greater error as they neared the hierarchical without fear of jumping to an unwanted menu...........Sadly, the NeXT folks, when coming to Apple, copied Windows, rather than the Mac"

markr_7 • 5 years ago Can't comment on the HID team, Bruce, or possibly the many times it was even implemented at Apple, but as a young developer at Apple in the 80s, I remember stopping by Frank Leahy's office as he was tweaking his code to get menus to "work right." I've often recalled the experience because of the time he was spending to get it right, and how the behavior wasn't simple once you started really trying to meet a users expectations. If I remember right it wasn't just the direction, but also time and therefore velocity. For example, you wouldn't want to stick with the wrong menu if the user wasn't really moving with purpose in the direction of the sub-menu.

Hwre's an article that does a much better job than me at explaining.

Even though it seems like a minor thing, there have been many articles written on this exact issue! For instance, Ben Kamens published a blog post analyzing how Amazon avoided this problem by using trigonometry. An imaginary triangle is constructed with its vertices placed at the cursor’s location and the upper and lower boundaries of the border between main categories and sub-categories. The idea is to avoid selecting another main category as long as the cursor is within this triangle. Smashing Magazine also has a detailed post on this subject that’s worth reading.