Design improvements

[phil294]

from mhutchie/vscode-git-graph#783 @mindplay-dk:

Screenshot 2023-09-01 121435

The original design was much easier to read - things are too small, the text is low contrast, and the full intensity red on black is actually hard on the eyes.

I'm extremely grateful that someone is willing to take over from the original maintainer, so please don't take this the wrong way, but this really needs a designer's eye. I would offer to help, but I'm not a designer either. Maybe we could find someone who's willing to help out and make this look beautiful again?

[phil294]

indeed the design part of this extension isn't particularly great. I'll be glad for suggestions, improvements or even PRs to improve the situation. I don't want to give up the the tenseness though - I like having a lot of information at hand without the need to scroll forever. But why not make it configurable? This extension is all about customizability already anyway, so the more options we have, the better!

So, yes, having someone more UI-knowledgable than me redesigning this thing would be great. We will then have to see what parts we make the default and which stay the same.

There's also a custom css option right now for those who can't wait to change some visual aspects.

[mindplay-dk]

I'm the opposite - I don't like having too much information on screen at once and prefer scrolling.

Since you're open to changing things, I might take a look and see if I can make it look more like the old version, but adding an option to toggle between "compact" and "comfortable", a'la GMail. :-)

[phil294]

Things look a bit curvier now with v0.1.13:

and the row height and branch line width is arbitrarily configurable, and the border is movable:

I think these were the most pressing issues. I think it would be good to prompt the user at their first extension run for how dense they want the interface to be, so to have a convenient way to set these two configuration values.

Other than that, I'm still open for concrete design suggestions, no matter how harsh or substantial (@hansu has been very helpful with this), as I can't look into the heads of my users :-)

[Deab22]

I made some mockups for 2 possible designs for the graph itself, with a more rigid, less squiggly style
The graph algorhithm for these is based on the LazyGit graph system, and the colors are not final

Design 1 is very boxy and square, directly inspired by LazyGit's design
it's basically the opposite of your current design, so it's probably not a valid candidate

Design 2 is a bit more similar to the current design, but with less arching graph structure (more straight paths than diagonal), and clearer branching and merging positions

Here's some more situations (just mockups):

PS: None of these mockups have the black outline around the lines/circles yet, since those are very annoying to make in my graphics software, but would be simple to implement in an actual renderer

[Deab22]

Finished adding the outlines tho one of the graphs, hope this shows the intended design more clearly

[hansu]

Thanks for your work. I think a mixture between your two versions would be the best.
The edges are a bit too sharp - would it be possible to round them a bit so that the line leaves the bubble only at 90 and 270 degrees and then make a curve?
Like this (changed for the blue one only):

[Deab22]

Hmm, true, it looks too jagged
i'll try to edit the path for these points

[Deab22]

here's a possible fix, this extra arc should only appy to connectors that span more than 1 branch, since the direct connector looks good when it's directly adjacent (see top and bottom of graph)

[hansu]

Looks much better now, thanks!

[mindplay-dk]

This looks promising 😄

[dimateos]

TBH the curvy lines still throw me off a lot. I find straight lines much simpler to comprehend, because then:

• Commits done in the same branch follow the same straight path (up to when merged)
  • So curving in means MERGE, if the path goes straight then the branch has MORE commits later....

In the current graph, even commits done in a row in the same branch are curvy!

So commenting on @Deab22 nice mocks, the idea is not about ALL straight lines, simply vertical ones for the same branch as in the LEFT. Horizontal straight lines as in RIGHT looks worse, IMO diminish the "meaning" of vertical straight ones. I also highlighted a merge+new point that looks confusing (occluded line origin).

A few details I noticed over the years that seem to be important:

---

Dont get me wrong, the current graph looks "nice" and is perfectly usable,
but I think I prefer an easier to understand flow even if it takes more horizontal space.

For me, the question is how hard would it be to implement.
If not so much, then an option to optionally toggle to "straight vertical lines" would be an awesome welcome addition for me and my colleagues.

Anyway just sharing my opinion.
Regards!

[mindplay-dk]

Honestly, I would just reference the draw methods in git-graph's implementation - you can't copy the code (because the license doesn't permit it) but referencing the line drawing approach should be completely okay. The graph rendering there is pretty much just perfection. ✌️

[phil294]

Thanks for all your input so far, and sorry I can't really do anything with it yet. The problem is that the rendering logic of GitLG is not much more than a deliberate dumb wrapper around the graph characters that Git send us. If you run git log --graph --oneline --all in command line, what you'll see is already very close to what GitLG will render, except that the latter "densen"s the lines together more so that there are no filler lines, and makes sure the colors of the lines aren't as random but deterministic and stay between branch junctions. The latter part is what most code in log-parser.js is for, the file responsible for the current looks. I'm mostly glad it works as expected by now (at least once #116 is released), but it's not much of a sustainable architecture. And while this in place, it's near impossible to make substantial changes to the lines such as removing the curviness altogether (note that you can already set git-log--graph.curve-radius: 0 in the settings to get less curves and more edges). It would be beneficial to just dump the whole logic and not take Git's graph output but instead keep track of all commits' parents and construct something good with it from scratch. Maybe it won't even be that hard. Most likely it will require a lot of effort and time though, of which I don't have enough / don't really wanna spend on it. So maybe I'm wrong but I don't think I can fix the graph design easily. I should have said that from the start when I opened this issue - I had not the graph rendering in mind when I wrote about "design improvements", but rather everything else. Sorry about that, especially to @Deab22 as you went ahead and even created a demo design. I really like how the latter looks though, a bit too fat for my taste but nicely consistent, and I would also prefer the more rigid version. I hope we can build on this thread in a future date.

In the end, it's open source and all plain JavaScript, so if someone wants to have a go at it, please do so! The entire parsing and preparation code is about 250 lines of logic inside log-parser.js (and small bits in SVGVisualization.vue), so throwing it out at least won't be hard.

[phil294]

Not a fan of stealing code from mhutchie's Git Graph extension code though, that would be both against the authors will and the project's license. Even if we were to decide that taking just a few hundred lines doesn't violate the license (which I can't see why it should not), integrating that behemoth into GitLG is probably as big of an undertaking as writing it from scratch.

[mindplay-dk]

I was only suggesting you reference the line drawing - I wouldn't suggest you copy any code, and yes, the graph itself has a boatload of complexity and interactions. You could even just look at the rendered lines and reference how they're drawn - looking at the source code might make it easier to understand though. There's no rules against that.

[phil294]

ooh, so you mean referencing as in using the logic as a model for rewriting it. sure that could be helpful! thought you meant actually importing and linking to it.

[mindplay-dk]

Come to think of it, earlier versions of the code was MIT licensed and can be freely used, copied, referenced, etc.

The license was changed from a standard MIT license on may 10, 2019:

mhutchie/vscode-git-graph@7e4ccb3

The parent of that commit is 4af8583, which means anything that was in the repository at that point in history is fair game.

Here's the graph rendering code from that point in history:

https://github.com/mhutchie/vscode-git-graph/blob/4af8583a42082b2c230d2c0187d4eaff4b69c665/web/graph.ts

If you look at the image in the README at that time, you can see it already had the nice graph rendering then:

https://github.com/mhutchie/vscode-git-graph/tree/4af8583a42082b2c230d2c0187d4eaff4b69c665

Obviously, a lot has changed since then - but the code was a lot simpler at the time, since the tree took on a lot more functionality in the years after, and it might actually be easier to reference or copy from. 🙂

Note that, under MIT, if you copy from this, you would need to include the phrase Copyright (c) 2019-present, mhutchie in your LICENSE file. For the record, this would also mean you can't change the license from MIT, since the MIT license is "infectious" and that is how the code was licensed.

But if you want, you absolutely can copy this older code and still respect the author's wishes. 😎