Timeline display: A. The B option just feels a bit clunky and slightly obfuscates the check-in.

/brtimeline: A again, it has more information shown and again B feels clunkier. Perhaps if the timeline td were smaller and the timeline button was replaced with the usual "check-in: 78b56efa user: drh"? But even then I think it could have an issue with long branch names not playing well with the formatting.

Timeline with ng: B. Makes it easier to quickly spot where commits are on different branches, especially when branch names are hidden behind an ellipsis, double especially when clicking the commit refuses to show the information (it works on B though, just not A. I don't even see any errors in the console other than "The page’s settings blocked an inline script" which appears on both pages)

I prefer the options with the ordinary links. Clear, consistent, obvious, predictable.

The options with the buttons are blind links and I can't see where they go when the mouse is positioned over them. I worry they might change something with a "POST" request.

Further changes

4.0 Timeline.

Original versus the New look. Please experiment with various skins and formats. (Edit: Fixed "original" hyperlink.)

5.0 New /tarlist page

Follow the "Tarballs and Zips" link on the /sitemap page or use the hamburger menu.

Original versus the New look. Please experiment with various skins and formats.

I think this is the URL for the new look https://www2.fossil-scm.org/home/timeline

Which i don't mind the commit messages being a bit closer to the graph.

How does the tarlist page work? Is there a setting on the file info page to make it a listing on the tarlist page?

https://fossil-scm.org/home/help/www/tarlist

The suggested-tarlist setting. There are instructions on the "Configuration" page under "Setup".

General:

• Please keep text label check-in: at the begging instead of hash: at the end.
• Please keep texts Leaf and Closed-leaf.

/brtimeline:

• Please allow to disable column mode.
• Replace the timeline button by a clickable branch name.
• Show the check-in hash.
• Please keep the ubg query parameter.

Thanks!

Please keep text label check-in: at the begging instead of hash: at the end.

Why? What purpose does this serve? "hash:" takes up less space, and by moving it to the end, it helps people to find it (no more searching in the middle of the text). And since "hash:" is arguably the most important parameter (which is why I experimented with putting it inside of <button>) it should be the easiest to locate.

Please keep texts Leaf and Closed-leaf.

Why? What useful purpose do these annotations serve? Why are they bold? Are they really that important? IIRC these annotations were added many years ago before the Left/Closed-leaf distinctions were incorporated into the graph nodes. Now that these attributes are clearly shown in the graph, it seems a pointless waste of space and user attention to include them in the attribute section of the timeline entry.

• The /finfo page also says check-in:, and hash would be ambiguous, so it's about consistency and clarity, and important things first. (BTW: Is /finfo broken? I don't see any arrows.)
• The leaf and closed-leaflabels provide useful and concise information. The cross-mark in the circle is subtle and maybe overlapped by the red selection-mark.

I don't think it makes sense to de-emphasize the leaf and closed-leaf labels, but emphasize the check-in hash: On a crowded timeline, it's important to quickly spot leaves to work with (review, update/switch to, merge; even if the corresponding graph circle is possibly several rails away). The check-in hash per se, as an alpha-numeric entity, is not important and doesn't need to stand out, but should be in a constant location (as it is, before user: and other tags) so it's easy to click it.

I don't think it makes sense to de-emphasize the leaf and closed-leaf labels, but emphasize the check-in hash:

If everything is bold then nothing is bold. Why is it relevant, during everyday /timeline browsing, whether a given checkin is open or closed? That's a rhetorical question: 99 times out of a hundred, that info will not change any decision i'm making. Contrariwise, i'm frequently looking for the hash to copy or click and appreciate it now being bolded.

I estimate that timeline leaf/not-leaf textualdistinction is important for about 1 in 1000 Fossil users, and that for about 1 in 10000 timeline visits, tops.

All my use of /timeline is about leaves: which one to check-out to work with, which one to merge, at which one to start when reviewing a branch? And the open / closed distinction is handy as a TODO list, i.e. anything open to be ontinued, merged, or reviewed?

Maybe you should use the /leaves page instead of /timeline?

Another option is to use the "Classic" view of the timeline, which still shows the bold "Leaf:" and "Closed-Leaf:" marks.

Couldn't the changes go as another new view option, same as the new "Simple View", so we can try and decide ourselves? My subjective impression is that Fossil quite often forces me to change my habits, workflows, and scripts.

There is now (yet another) setting: timeline-mark-leaves.

Thanks, that's certainly useful for my own repos.

Encapsulating all the current modifications in a new View Style would also allow users to choose their preferred views for fossil-scm.org and sqlite.org. Then yet another setting is not necessary, just the user cookie would save the preference.

For the /brtimeline page, I think it is desirable to highlight the branch name, so I'd apply the bold from ver.B to ver.A (adding the branch name in compact view, where it is currently not shown at all)

The "Details" button could be useful for those unfamiliar with fossil.

The "Details" button could be useful for those unfamiliar with fossil.

Yes, that is the whole point of this exercise. Fossil has many hyperlinks. Newbies can easily become overwhelmed. I was trying to draw attention to the more important hyperlinks, and thereby make Fossil more useful to casual passers-by.

The results of these experiments are now summarized by the change log items 3 and 4 (all subitems).

Please review. If there are no serious problems reported I will merge these enhancements to trunk.

A recent version of the branch is installed on the server that is running this Forum so that you can test out the changes on-line. In the self-hosting Fossil repository, you can see the specific version that is actually running on the timeline because it has the "自" character (meaning "self") beside the "check-in:" detail. This is a change which is not mentioned in the change log because this feature can only occur on the self-hosting Fossil repository.

it has the "自" character (meaning "self") beside the "check-in:" detail

Out of curiosity: why an unicode character? And a one that isn't included in the most popular fonts? For me it looked like an error artifact (because it didn't show up correctly - probably I don't have font with a glypth for it).

Out of curiosity: why an unicode character?

Not an answer, but a bit of contextual trivia...

It was previously a "This is me!" label. In /chat i jokingly¹ suggested that we change it to:

🙋

(Which you can hopefully see - it's one of the more common ones.)

As to why non-ASCII: no specific reason beyond moving with the times. The "this font doesn't have this glyph" problem is real, though.

1. ^{^} Well, half jokingly.

自 (if you can see it) is Chinese (simplified) for 'self'. It is also in the Kanji character set so maybe Japanese too - I am not enough of a linguist to be sure they use it with the same meaning.

So, 'most popular' in what context / on what platform? China is a big place...

As a datum, I have no issue with it, I'm on a pretty standard UK Windows 10 setup and it appears in both browser and email.

Ok, "most popular" was not the best wording ;-) It turned out that on my platform "sans-serif" means a free font that I personally chose and as you might guess, this font doesn't contain many non-ASCII characters... ;-)

The main point was: why use a Unicode character at all if all the rest of fossil-generated text are generally plain English.

Brevity and precision. It is a symbol rather than a word, in this context meaning specifically that this is the checkin from which the version of Fossil generating the display was compiled.

Similar to drawing an arrow instead of saying 'checkin x is based on checkin y'.

Personally I quite like the idea, though it can be overdone.

Trevor

I understand its meaning and agree that shortening the text "This is me" was worthwhile. I was simply surprised by the choice of a character from the extended Unicode set, but that's none of my business anyway... ;-)

PS. This little thing took up way more space than it's worth. ;-)

Thanks for all the improvements you made and the feedback you've solicited.