Discussion:
A-B comparison of proposed timeline changes
(too old to reply)
Richard Hipp
2017-11-24 14:35:55 UTC
Permalink
Which is better?

A: https://www.fossil-scm.org/a/timeline
B: https://www.fossil-scm.org/b/timeline

Also:

A: https://www.fossil-scm.org/a/finfo?name=src/search.c
B: https://www.fossil-scm.org/b/finfo?name=src/search.c

Surf about from any of the links above for additional views.

The change here is to emphasis the check-in comment and de-emphasize
the links to the check-in details and other information.

In the recent HN discussion of Fossil
(https://news.ycombinator.com/item?id=15752725) some comments were
sharply critical of the timeline display in Fossil. While I think
those comments were overly dramatic, they did bring up the point that
the check-in comment is probably the most important feature and should
be more prominent. This A/B comparison is my attempt to make them so.

Further suggestions and/or comments are welcomed.
--
D. Richard Hipp
***@sqlite.org
Stanislav Paskalev
2017-11-24 15:06:19 UTC
Permalink
Hi,

I'd like to object the default use of low-contrast type in
professional software :)

I use displays that are adjusted for low eye strain by reducing
contrast and brightness. Having type and typography do the same thing
again has the opposite effect and legibility starts to suffer.

Regards,
Stanislav

Stanislav Paskalev
Post by Richard Hipp
Which is better?
A: https://www.fossil-scm.org/a/timeline
B: https://www.fossil-scm.org/b/timeline
A: https://www.fossil-scm.org/a/finfo?name=src/search.c
B: https://www.fossil-scm.org/b/finfo?name=src/search.c
Surf about from any of the links above for additional views.
The change here is to emphasis the check-in comment and de-emphasize
the links to the check-in details and other information.
In the recent HN discussion of Fossil
(https://news.ycombinator.com/item?id=15752725) some comments were
sharply critical of the timeline display in Fossil. While I think
those comments were overly dramatic, they did bring up the point that
the check-in comment is probably the most important feature and should
be more prominent. This A/B comparison is my attempt to make them so.
Further suggestions and/or comments are welcomed.
--
D. Richard Hipp
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
j. van den hoff
2017-11-24 15:08:51 UTC
Permalink
Post by Richard Hipp
Which is better?
A: https://www.fossil-scm.org/a/timeline
B: https://www.fossil-scm.org/b/timeline
A: https://www.fossil-scm.org/a/finfo?name=src/search.c
B: https://www.fossil-scm.org/b/finfo?name=src/search.c
Surf about from any of the links above for additional views.
The change here is to emphasis the check-in comment and de-emphasize
the links to the check-in details and other information.
In the recent HN discussion of Fossil
(https://news.ycombinator.com/item?id=15752725) some comments were
sharply critical of the timeline display in Fossil. While I think
those comments were overly dramatic, they did bring up the point that
the check-in comment is probably the most important feature and should
be more prominent. This A/B comparison is my attempt to make them so.
Further suggestions and/or comments are welcomed.
in my view, variant B might be preferable somewhat (for the GUI -- but
leaving the timeline output in the terminal as is...). but choosing some
pale color shades (or alpha?) makes the text difficult to read. I would
prefer a smaller font instead, leaving the colors untouched.

personally, I rather like the tidiness of the timeline graph available in
mercurial via `hg serve' which beyond the checkin message hides everything
except time of checkin, branch name, and user (and uses a distinctly
smaller font size for the latter info). in effect one mostly notices the
checkin message easily. so one might think about doing something similar
(remove hash display and link the commit message itself to the 'chekin'
page)?

just an idea....
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Richard Hipp
2017-11-24 15:17:26 UTC
Permalink
Post by j. van den hoff
personally, I rather like the tidiness of the timeline graph available in
mercurial via `hg serve' ... so one might think about doing something similar
(remove hash display and link the commit message itself to the 'chekin'
page)?
Fossil has the ability to include links within a check-in message - a
feature that SQLite uses quite a bit. See, for example, the
hyperlinks embedded within the check-in comments for the first few
items on https://sqlite.org/b/timeline?y=ci

If the entire check-in comment is a hyperlink, that would make it
difficult to have hyperlinks embedded within the check-in comment.
--
D. Richard Hipp
***@sqlite.org
Lutz Horn
2017-11-24 15:30:00 UTC
Permalink
Post by Richard Hipp
If the entire check-in comment is a hyperlink, that would make it
difficult to have hyperlinks embedded within the check-in comment.
I totally agree. So far I only use ticket IDs that are automatically
linked but this is very important to me. If the whole commit ci comment
would be linked, this would not be possible.

Lutz
Richard Hipp
2017-11-24 15:13:22 UTC
Permalink
Post by Richard Hipp
Which is better?
A: https://www.fossil-scm.org/a/timeline
B: https://www.fossil-scm.org/b/timeline
Alternative CSS that causes the "details" to appears on a separate
line from the comment:

A: https://sqlite.org/src/timeline
B: https://sqlite.org/b/timeline
--
D. Richard Hipp
***@sqlite.org
Andy Bradford
2017-11-24 15:55:09 UTC
Permalink
Post by Richard Hipp
Alternative CSS that causes the "details" to appears on a separate
A: https://sqlite.org/src/timeline
B: https://sqlite.org/b/timeline
I think it looks slightly cleaner with the ``details'' on a separate
line, however, I still miss the Leaf, which I do find useful.

Leaving out the node status information does make it read more like
prose and look less like a tree structure, however, maybe some don't
find it useful to know what kind of a node it is.

Andy
--
TAI64 timestamp: 400000005a184102
Richard Hipp
2017-11-24 15:58:13 UTC
Permalink
Post by Andy Bradford
I still miss the Leaf, which I do find useful.
Ugh. I didn't intend to omit the "Leaf" and "Closed-Leaf" marks,
though I did want to move them to the end, rather than before the
check-in comment. The omission of that information is a bug.
--
D. Richard Hipp
***@sqlite.org
Richard Hipp
2017-11-24 16:12:14 UTC
Permalink
Post by Richard Hipp
Post by Andy Bradford
I still miss the Leaf, which I do find useful.
Ugh. I didn't intend to omit the "Leaf" and "Closed-Leaf" marks,
though I did want to move them to the end, rather than before the
check-in comment. The omission of that information is a bug.
Now fixed.

Other changes on https://www.fossil-scm.org/b/timeline since the
original comparison request:

(1) The "details" section is shown on a separate line below the
check-in comment.
(2) The "details" are in the same font-color as the comment-text
but have a slightly reduced font size.
--
D. Richard Hipp
***@sqlite.org
bch
2017-11-24 16:22:22 UTC
Permalink
Post by Richard Hipp
Post by Richard Hipp
Post by Andy Bradford
I still miss the Leaf, which I do find useful.
Ugh. I didn't intend to omit the "Leaf" and "Closed-Leaf" marks,
though I did want to move them to the end, rather than before the
check-in comment. The omission of that information is a bug.
Now fixed.
Other changes on https://www.fossil-scm.org/b/timeline since the
(1) The "details" section is shown on a separate line below the
check-in comment.
(2) The "details" are in the same font-color as the comment-text
but have a slightly reduced font size.
I don’t see that reflected on the link. Perhaps consider a .gif snapshot of
the effects so it’s not subject to code change on a live system, and
annotatable if necessary?
Post by Richard Hipp
--
D. Richard Hipp
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Richard Hipp
2017-11-24 16:27:28 UTC
Permalink
Post by Richard Hipp
(1) The "details" section is shown on a separate line below the
check-in comment.
(2) The "details" are in the same font-color as the comment-text
but have a slightly reduced font size.
I don’t see that reflected on the link.
Those are CSS changes. So you will need to press "Reload" in your
browser, possibly multiple times if you use Chrome, before you will be
able to see the changes.
--
D. Richard Hipp
***@sqlite.org
s***@gmail.com
2017-11-24 16:53:32 UTC
Permalink
I understand the need for links, but do users really need truncated hashes
for every line?
Can the link be applied more subtly?
Can there be a similar "quiet" setting for the Timeline like *Per-Item Time
Format = (off) *to conserve space?
My commits prepend a simple timestamp in the comment and multiline text for
more immediate descriptions right up front.
Having this tail every entry -> (check-in: [4dfa592f]
<https://www.fossil-scm.org/b/info/4dfa592f27f88e82> user: drh
<https://www.fossil-scm.org/b/timeline?u=drh&c=2017-11-16+02%3A43%3A49&nd&n=200>
tags: trunk
<https://www.fossil-scm.org/b/timeline?r=trunk&nd&c=2017-11-16+02%3A43%3A49&n=200>)
<-
makes the timeline quite busy.

Thanks for Fossil!
Post by Richard Hipp
Post by bch
Post by Richard Hipp
(1) The "details" section is shown on a separate line below the
check-in comment.
(2) The "details" are in the same font-color as the comment-text
but have a slightly reduced font size.
I don’t see that reflected on the link.
Those are CSS changes. So you will need to press "Reload" in your
browser, possibly multiple times if you use Chrome, before you will be
able to see the changes.
--
D. Richard Hipp
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
David Mason
2017-11-24 18:32:23 UTC
Permalink
I like the B cases... in fact I'd indent the details a bit so that the
comments are easier to find visually.
Post by s***@gmail.com
I understand the need for links, but do users really need truncated hashes
for every line?
Can the link be applied more subtly?
Can there be a similar "quiet" setting for the Timeline like *Per-Item
Time Format = (off) *to conserve space?
My commits prepend a simple timestamp in the comment and multiline text
for more immediate descriptions right up front.
Having this tail every entry -> (check-in: [4dfa592f]
<https://www.fossil-scm.org/b/info/4dfa592f27f88e82> user: drh
<https://www.fossil-scm.org/b/timeline?u=drh&c=2017-11-16+02%3A43%3A49&nd&n=200>
tags: trunk
<https://www.fossil-scm.org/b/timeline?r=trunk&nd&c=2017-11-16+02%3A43%3A49&n=200>)
<-
makes the timeline quite busy.
Thanks for Fossil!
Post by Richard Hipp
Post by bch
Post by Richard Hipp
(1) The "details" section is shown on a separate line below the
check-in comment.
(2) The "details" are in the same font-color as the comment-text
but have a slightly reduced font size.
I don’t see that reflected on the link.
Those are CSS changes. So you will need to press "Reload" in your
browser, possibly multiple times if you use Chrome, before you will be
able to see the changes.
--
D. Richard Hipp
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Jacob MacDonald
2017-11-24 18:52:41 UTC
Permalink
Seems like I'm in the minority, but I prefer the A version. I tend to like
compact UIs and having all the relevant information close together and the
commit hash prominently displayed is nice.
Post by David Mason
I like the B cases... in fact I'd indent the details a bit so that the
comments are easier to find visually.
Post by s***@gmail.com
I understand the need for links, but do users really need truncated
hashes for every line?
Can the link be applied more subtly?
Can there be a similar "quiet" setting for the Timeline like *Per-Item
Time Format = (off) *to conserve space?
My commits prepend a simple timestamp in the comment and multiline text
for more immediate descriptions right up front.
Having this tail every entry -> (check-in: [4dfa592f]
<https://www.fossil-scm.org/b/info/4dfa592f27f88e82> user: drh
<https://www.fossil-scm.org/b/timeline?u=drh&c=2017-11-16+02%3A43%3A49&nd&n=200>
tags: trunk
<https://www.fossil-scm.org/b/timeline?r=trunk&nd&c=2017-11-16+02%3A43%3A49&n=200>)
<-
makes the timeline quite busy.
Thanks for Fossil!
Post by Richard Hipp
Post by bch
Post by Richard Hipp
(1) The "details" section is shown on a separate line below the
check-in comment.
(2) The "details" are in the same font-color as the comment-text
but have a slightly reduced font size.
I don’t see that reflected on the link.
Those are CSS changes. So you will need to press "Reload" in your
browser, possibly multiple times if you use Chrome, before you will be
able to see the changes.
--
D. Richard Hipp
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Martin Gagnon
2017-11-24 21:13:07 UTC
Permalink
Post by Jacob MacDonald
Seems like I'm in the minority, but I prefer the A version. I tend to like
compact UIs and having all the relevant information close together and the
commit hash prominently displayed is nice.
<snip>

Same for me.

With B version, checkin hash links are not aligned, so it's
not as natural when it's time to click on them, I have to find the link
at the end of the comment.

Moreover, when the comment wraps on multiple lines, a quick look make it
looks like 2 separate checkins. It's not the case with A version because
a new checkin start with the hash link.

Regards
--
Martin G.
Zakero
2017-11-24 23:52:01 UTC
Permalink
Looking at the commit message data, it has a 4 types of information:
- The check-in link
- The commit message
- Leaf, Closed-Leaf
- Detail (user, tags)

For me, the most important piece of information is the check-in link. Now,
l have to search for the link because it is no longer in a consistent
location.
The commit message is next. Since the check-in link was usually the same
length, the commit message starts in the same the same location for each
timeline node for either format change. My commit messages range from 1 to
15 lines and I like to see the full commit message in the timeline (Allow
block-markup in timeline = Enabled, Truncate comment at first blank line =
Disabled) So the end of my commit messages varies quite a bit in the
timeline.
Leaf status and Details have not been that important to me, since that
information can be viewed more clearly in other parts of fossil when needed.

And yes, I know that I can click on the "time" to get to the check-in page
with the new changes, but that is another non-obvious / counter-intuitive
addition of the fossil UI. (The more famous being the "click on the
timeline nodes to see a diff")

tldr; This new change of the timeline makes it harder to find useful links.
Richard Hipp
2017-11-25 00:12:58 UTC
Permalink
Post by Zakero
tldr; This new change of the timeline makes it harder to find useful links.
There is now a per-repository configuration option under
Setup/Timeline that lets you choose which timeline format you prefer.

https://www.fossil-scm.org/fossil/ is currently configured so that
when you click on the "Timeline" menu, you get
https://www.fossil-scm.org/fossil/timeline?basic - the "basic" query
parameter declutters the display as much as possible to be friendly to
newbies. You can change this on your repos by searching for
"/timeline?basic" in your "Header" configuration and omitting the
query parameter.

There is an undocumented query parameter on /timeline that lets you
experiment with different formatting options without having to change
the configuration.

https://www.fossil-scm.org/fossil/timeline?commentformat=1
https://www.fossil-scm.org/fossil/timeline?commentformat=2
https://www.fossil-scm.org/fossil/timeline?commentformat=3
https://www.fossil-scm.org/fossil/timeline?commentformat=4
https://www.fossil-scm.org/fossil/timeline?commentformat=5
https://www.fossil-scm.org/fossil/timeline?commentformat=12

The "basic" query parameter simply forced commentformat=5 and then
disables a lot of the complex submenu controls, replacing them all
with an "Advanced" button that turns "basic" off.

Other values for commentformat=N are possible, but are reserved for
future expansion.

Thanks to everyone who contributed comments! All suggestions were
useful, even those that I did not implement. It is important to have
lots of ideas in circulation.

One thing I learned from this exercise is that no two people want the
timeline to look the same way. Consensus is not a possibility here.
There is too much diversity of opinion. Therefore, I had to exercise
my authority as the BDFL and pick one particular behavior for the
canonical Fossil repo and to be the default. You are welcomed to pick
a different behavior for your own repositories, since it is now
configurable.
--
D. Richard Hipp
***@sqlite.org
s***@gmail.com
2017-11-25 00:25:16 UTC
Permalink
Wow, #5 is super clean and easy on the eyes!
And #12 is interesting if I can see it with Per-Item Time Format = (off)?

Thanks for the changes!
Post by Zakero
Post by Zakero
tldr; This new change of the timeline makes it harder to find useful
links.
There is now a per-repository configuration option under
Setup/Timeline that lets you choose which timeline format you prefer.
https://www.fossil-scm.org/fossil/ is currently configured so that
when you click on the "Timeline" menu, you get
https://www.fossil-scm.org/fossil/timeline?basic - the "basic" query
parameter declutters the display as much as possible to be friendly to
newbies. You can change this on your repos by searching for
"/timeline?basic" in your "Header" configuration and omitting the
query parameter.
There is an undocumented query parameter on /timeline that lets you
experiment with different formatting options without having to change
the configuration.
https://www.fossil-scm.org/fossil/timeline?commentformat=1
https://www.fossil-scm.org/fossil/timeline?commentformat=2
https://www.fossil-scm.org/fossil/timeline?commentformat=3
https://www.fossil-scm.org/fossil/timeline?commentformat=4
https://www.fossil-scm.org/fossil/timeline?commentformat=5
https://www.fossil-scm.org/fossil/timeline?commentformat=12
The "basic" query parameter simply forced commentformat=5 and then
disables a lot of the complex submenu controls, replacing them all
with an "Advanced" button that turns "basic" off.
Other values for commentformat=N are possible, but are reserved for
future expansion.
Thanks to everyone who contributed comments! All suggestions were
useful, even those that I did not implement. It is important to have
lots of ideas in circulation.
One thing I learned from this exercise is that no two people want the
timeline to look the same way. Consensus is not a possibility here.
There is too much diversity of opinion. Therefore, I had to exercise
my authority as the BDFL and pick one particular behavior for the
canonical Fossil repo and to be the default. You are welcomed to pick
a different behavior for your own repositories, since it is now
configurable.
--
D. Richard Hipp
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Jungle Boogie
2017-11-25 02:28:33 UTC
Permalink
Post by s***@gmail.com
Wow, #5 is super clean and easy on the eyes!
And #12 is interesting if I can see it with Per-Item Time Format = (off)?
Thanks for the changes!
#5 is nice, and especially with the easy option to switch back to
advanced. Perhaps the basic option can include the user as well, that
would probably be my only suggestion.

DRH, thank you for being so willing to listen to the user base and those
who have probably never touched fossil before (such as HN folks).
Andy Bradford
2017-11-26 04:39:04 UTC
Permalink
Seems like I'm in the minority, but I prefer the A version. I tend to
like compact UIs and having all the relevant information close
together and the commit hash prominently displayed is nice.
The only reason why I said that the separate line was cleaner was
because it made it easier to find the commit hash. When it is all on one
line, I actually prefer the commit hash to be the very first piece of
text on the line. This makes everything justified nicely and it's easy
to predict where I should place my mouse if I want to copy/paste or
click on the hash. If it's in some random place on the line because the
``details'' have been moved to the end of a variable length comment,
then I would rather have the ``details'' on a line by itself which
preserves the ability to navigate commit hashes easily in the timeline.

Andy
--
TAI64 timestamp: 400000005a1a458d
Andy Bradford
2017-11-26 04:34:56 UTC
Permalink
Post by Richard Hipp
Now fixed.
Verified.
Post by Richard Hipp
Other changes on https://www.fossil-scm.org/b/timeline since the
(1) The "details" section is shown on a separate line below the
check-in comment.
I just looked and I don't see the ``details'' section on a separate
line. Is that intentional?
Post by Richard Hipp
(2) The "details" are in the same font-color as the comment-text but
have a slightly reduced font size.
This seems to me to be an improvement.

Andy
--
TAI64 timestamp: 400000005a1a4495
Andy Bradford
2017-11-24 15:45:47 UTC
Permalink
Post by Richard Hipp
Which is better?
A: https://www.fossil-scm.org/a/timeline
B: https://www.fossil-scm.org/b/timeline
I prefer A. I don't like muted colors for text. I prefer seeing text
than to have to look for text that begins to blend with surrounding
colors.

Andy
--
TAI64 timestamp: 400000005a183ed0
Andy Bradford
2017-11-24 15:49:07 UTC
Permalink
The change here is to emphasis the check-in comment and de-emphasize
the links to the check-in details and other information.
Hopefully this change is simply accomplished with some CSS. That way
those who prefer their UI to make text blend in with surrounding colors
can do so. :-)

Andy
--
TAI64 timestamp: 400000005a183f98
Richard Hipp
2017-11-24 15:56:13 UTC
Permalink
Post by Andy Bradford
The change here is to emphasis the check-in comment and de-emphasize
the links to the check-in details and other information.
Hopefully this change is simply accomplished with some CSS. That way
those who prefer their UI to make text blend in with surrounding colors
can do so. :-)
The movement of the check-in hash from in front of the check-in
comment until after the check-in comment is a code change. I suppose
it could be made a configuration parameter, such as the choice between
round or square nodes in the graph. But text movement like that is
not something I know how to do in CSS.

The graying of text after the check-in comment *is* accomplished using
CSS. That can be changed easily. I have a slightly different CSS
over at https://sqlite.org/b/timeline that puts the "detail"
information on a separate line. It is still slightly grayed, though.
I took my cue on the graying of less-relevant text from Google search
result screens, which do the same thing.
--
D. Richard Hipp
***@sqlite.org
Warren Young
2017-11-27 22:13:23 UTC
Permalink
Post by Richard Hipp
Which is better?
A: https://www.fossil-scm.org/a/timeline
B: https://www.fossil-scm.org/b/timeline
I prefer A because I don’t like having to dig for details. Hiding details isn’t the answer to clutter. Drawing the eye to key details first is the right path.

Here is a few minutes spent with option A’s CSS:

https://imgur.com/a/w0mGF

Key changes:

1. More “air” around each comment line
2 Slight opacity drop and font size drop on details span to deemphasize it
3. Details span pushed off to the lower right to visually separate it from the comment
4. Extra “air” around details span; ditto
5. Borders added to separate timeline elements more clearly


Here are the CSS additions:

table.timelineTable {
border-collapse: separate;
}
td.timelineTableCell {
vertical-align: top;
text-align: left;
padding: 0.75em;
border: 1px #ccc solid;
border-radius: 1em;
}
span.timelineDetail {
font-size: 80%;
text-align: right;
float: right;
opacity: 0.75;
margin-top: 0.5em;
}

More could be done, but I think that shows the idea.
jungle Boogie
2017-11-27 22:31:41 UTC
Permalink
Post by Warren Young
Post by Richard Hipp
Which is better?
A: https://www.fossil-scm.org/a/timeline
B: https://www.fossil-scm.org/b/timeline
I prefer A because I don’t like having to dig for details. Hiding details isn’t the answer to clutter. Drawing the eye to key details first is the right path.
https://imgur.com/a/w0mGF
1. More “air” around each comment line
2 Slight opacity drop and font size drop on details span to deemphasize it
3. Details span pushed off to the lower right to visually separate it from the comment
4. Extra “air” around details span; ditto
5. Borders added to separate timeline elements more clearly
I like these changes! I definitely like the horizontal spacing around
the check-ins and the check-in details to be slightly below the single
line check-in information.

Can we see this implemented on a timeline c option?

Thanks for the work, Warren!

best,
j.b.
Richard Hipp
2017-11-27 22:41:55 UTC
Permalink
Post by Warren Young
table.timelineTable {
border-collapse: separate;
}
td.timelineTableCell {
vertical-align: top;
text-align: left;
padding: 0.75em;
border: 1px #ccc solid;
border-radius: 1em;
}
span.timelineDetail {
font-size: 80%;
text-align: right;
float: right;
opacity: 0.75;
margin-top: 0.5em;
}
Very nice!

If you also add:

.clutter { display: inline; }
.anticlutter { display: none; }

Then the timeline will come up in detailed mode.

I have installed the new look (temporarily at least) on
https://www.fossil-scm.org/fossil so that we can live with it for a
while to see how we like it. The big down-side is that less
information is visible on a single screen now, so you have to scroll
more. But that seems to be the trend with websites these days....
--
D. Richard Hipp
***@sqlite.org
Warren Young
2017-11-27 22:46:32 UTC
Permalink
Post by Richard Hipp
The big down-side is that less
information is visible on a single screen now, so you have to scroll
more. But that seems to be the trend with websites these days….
The design ideas I tapped into this were old when desktop publishing was the new hotness. Human factors haven’t changed in millennia. It’s why an iPad is about the same size as books made before Gutenberg first sneezed.
Warren Young
2017-11-27 23:02:03 UTC
Permalink
Post by Warren Young
Post by Richard Hipp
The big down-side is that less
information is visible on a single screen now, so you have to scroll
more. But that seems to be the trend with websites these days….
The design ideas I tapped into this were old when desktop publishing was the new hotness. Human factors haven’t changed in millennia. It’s why an iPad is about the same size as books made before Gutenberg first sneezed.
That’s an incomplete thought.

My point is, what’s changed isn’t that we’re getting sloppy in web site design these days, it’s that screens are finally starting to get big enough and to have high enough levels of contrast and resolution that we can afford to put some of the space in that book and magazine publishers have known is a good idea for centuries, and which has had solid science behind it for decades at least.

Wall-o-text is hard to read, in any medium.

My proposed design changes do not waste space, they buy readability.

Also, I just want to emphasize that I do not think this is the paragon of web site design. I hope someone riffs on it and does something even better with it.
Offray Vladimir Luna Cárdenas
2017-11-27 23:20:44 UTC
Permalink
Post by Warren Young
Post by Warren Young
Post by Richard Hipp
The big down-side is that less
information is visible on a single screen now, so you have to scroll
more. But that seems to be the trend with websites these days….
The design ideas I tapped into this were old when desktop publishing was the new hotness. Human factors haven’t changed in millennia. It’s why an iPad is about the same size as books made before Gutenberg first sneezed.
That’s an incomplete thought.
My point is, what’s changed isn’t that we’re getting sloppy in web site design these days, it’s that screens are finally starting to get big enough and to have high enough levels of contrast and resolution that we can afford to put some of the space in that book and magazine publishers have known is a good idea for centuries, and which has had solid science behind it for decades at least.
Wall-o-text is hard to read, in any medium.
My proposed design changes do not waste space, they buy readability.
Also, I just want to emphasize that I do not think this is the paragon of web site design. I hope someone riffs on it and does something even better with it.
I agree with Warren's design and improved readability by adding space.
Timeline now has more "air to breath" and is more pleasant to the eye.

Cheers,

Offray
Andy Bradford
2017-11-29 05:45:24 UTC
Permalink
Post by Offray Vladimir Luna Cárdenas
I agree with Warren's design and improved readability by adding space.
Timeline now has more "air to breath" and is more pleasant to the eye.
If you're talking about what is currently visible on

http://www.fossil-scm.org/index.html/timeline

then I respectfully disagree that it is more pleasant to the eye. I
found the original timelines more pleasant precisely because they had
more whitespace in them---natural whitespace inbetween comments from
variable length comments. Now it all seems a blur.

If you're talking about something else, maybe an example would be
helpful?

Thanks,

Andy
--
TAI64 timestamp: 400000005a1e4998
Offray Vladimir Luna Cárdenas
2017-11-29 15:30:43 UTC
Permalink
Hi Andy,
Post by Andy Bradford
Post by Offray Vladimir Luna Cárdenas
I agree with Warren's design and improved readability by adding space.
Timeline now has more "air to breath" and is more pleasant to the eye.
If you're talking about what is currently visible on
http://www.fossil-scm.org/index.html/timeline
then I respectfully disagree that it is more pleasant to the eye. I
found the original timelines more pleasant precisely because they had
more whitespace in them---natural whitespace inbetween comments from
variable length comments. Now it all seems a blur.
If you're talking about something else, maybe an example would be
helpful?
Thanks,
Andy
This could be an example of what I'm talking about. I found [1] more
pleasant to the eye that [2] (my current setup).

[1] http://www.fossil-scm.org/index.html/timeline
[2] http://mutabit.com/repos.fossil/mapeda/timeline

Cheers,

Offray
Steve Landers
2017-11-28 01:32:16 UTC
Permalink
Nice work.

Have you considered dropping the borders on the commits?  They do add definition to the commit, but at the expense of repetition and possibly “noise” when the branch isn’t colored

Screenshot at Loading Image...

—Steve
Post by Warren Young
My proposed design changes do not waste space, they buy readability.
Also, I just want to emphasize that I do not think this is the paragon of web site design. I hope someone riffs on it and does something even better with it.
Richard Hipp
2017-11-28 02:01:37 UTC
Permalink
Post by Steve Landers
Nice work.
Have you considered dropping the borders on the commits? They do add
definition to the commit, but at the expense of repetition and possibly
“noise” when the branch isn’t colored
Here are comparison links:

As it was yesterday:
https://www.fossil-scm.org/fossil/timeline
https://www.fossil-scm.org/fossil/timeline?dp=d95f712&n=4
https://www.fossil-scm.org/fossil/timeline?b=2017-09-01
https://www.fossil-scm.org/fossil/finfo?name=src/db.c

Warren Young's new approach:
https://www2.fossil-scm.org/fossil/timeline
https://www2.fossil-scm.org/fossil/timeline?dp=d95f712&n=4
https://www2.fossil-scm.org/fossil/timeline?b=2017-09-01
https://www2.fossil-scm.org/fossil/finfo?name=src/db.c

Steve Landers' modifications to Warren's approach:
https://www3.fossil-scm.org/site.cgi/timeline
https://www3.fossil-scm.org/site.cgi/timeline?dp=d95f712&n=4
https://www3.fossil-scm.org/site.cgi/timeline?b=2017-09-01
https://www3.fossil-scm.org/site.cgi/finfo?name=src/db.c

Please do not restrict yourself to just the links shown. Look at
various timelines to see what works well and what does not.
--
D. Richard Hipp
***@sqlite.org
Steve Landers
2017-11-28 02:04:18 UTC
Permalink
Note that I would retain the rounded corners on Warren’s backgrounds, they make the visuals “softer”.
Post by Richard Hipp
Post by Steve Landers
Nice work.
Have you considered dropping the borders on the commits? They do add
definition to the commit, but at the expense of repetition and possibly
“noise” when the branch isn’t colored
https://www.fossil-scm.org/fossil/timeline
https://www.fossil-scm.org/fossil/timeline?dp=d95f712&n=4
https://www.fossil-scm.org/fossil/timeline?b=2017-09-01
https://www.fossil-scm.org/fossil/finfo?name=src/db.c
https://www2.fossil-scm.org/fossil/timeline
https://www2.fossil-scm.org/fossil/timeline?dp=d95f712&n=4
https://www2.fossil-scm.org/fossil/timeline?b=2017-09-01
https://www2.fossil-scm.org/fossil/finfo?name=src/db.c
https://www3.fossil-scm.org/site.cgi/timeline
https://www3.fossil-scm.org/site.cgi/timeline?dp=d95f712&n=4
https://www3.fossil-scm.org/site.cgi/timeline?b=2017-09-01
https://www3.fossil-scm.org/site.cgi/finfo?name=src/db.c
Please do not restrict yourself to just the links shown. Look at
various timelines to see what works well and what does not.
--
D. Richard Hipp
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Warren Young
2017-11-29 02:17:35 UTC
Permalink
Note that I would retain the rounded corners on Warren’s backgrounds, they make the visuals “softer”.
You can have that without the stroked borders:

td.timelineTableCell {
border-radius: 10px;
background-color: #f8f8f8;
}

That is, don’t define a border style, just apply the border radius to the td element, which rounds the corners of the background color. Set a very pale background color as a default for the “normal” case, then let Fossil override that for branches and such.

With this, I’d suggest increasing padding to 0.75 em. It gets a bit crowded in the corners otherwise.

Preview:

https://imgur.com/a/a7nlN
Steve Landers
2017-11-29 03:43:50 UTC
Permalink
I like it. Thanks
Post by Warren Young
Post by Steve Landers
Note that I would retain the rounded corners on Warren’s backgrounds, they make the visuals “softer”.
td.timelineTableCell {
border-radius: 10px;
background-color: #f8f8f8;
}
That is, don’t define a border style, just apply the border radius to the td element, which rounds the corners of the background color. Set a very pale background color as a default for the “normal” case, then let Fossil override that for branches and such.
With this, I’d suggest increasing padding to 0.75 em. It gets a bit crowded in the corners otherwise.
https://imgur.com/a/a7nlN
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Richard Hipp
2017-11-29 03:58:21 UTC
Permalink
A view of the dbpage branch of SQLite on the GitHub mirror:

https://github.com/mackyle/sqlite/commits/dbpage

The same information from the latest experimental Fossil:

http://www.sqlite.org/srcxb/timeline?ss=n&n=34&p=dbpage&y=ci
--
D. Richard Hipp
***@sqlite.org
David Mason
2017-11-28 02:07:39 UTC
Permalink
I would like yesterdays with a bit of whitespace between commit comments.

Also someone liked the original because the checkin tag was in a
predictable place. If you put the tag last in the extra information it
would be predictably at the right margin.
Post by Richard Hipp
Post by Steve Landers
Nice work.
Have you considered dropping the borders on the commits? They do add
definition to the commit, but at the expense of repetition and possibly
“noise” when the branch isn’t colored
https://www.fossil-scm.org/fossil/timeline
https://www.fossil-scm.org/fossil/timeline?dp=d95f712&n=4
https://www.fossil-scm.org/fossil/timeline?b=2017-09-01
https://www.fossil-scm.org/fossil/finfo?name=src/db.c
https://www2.fossil-scm.org/fossil/timeline
https://www2.fossil-scm.org/fossil/timeline?dp=d95f712&n=4
https://www2.fossil-scm.org/fossil/timeline?b=2017-09-01
https://www2.fossil-scm.org/fossil/finfo?name=src/db.c
https://www3.fossil-scm.org/site.cgi/timeline
https://www3.fossil-scm.org/site.cgi/timeline?dp=d95f712&n=4
https://www3.fossil-scm.org/site.cgi/timeline?b=2017-09-01
https://www3.fossil-scm.org/site.cgi/finfo?name=src/db.c
Please do not restrict yourself to just the links shown. Look at
various timelines to see what works well and what does not.
--
D. Richard Hipp
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Johan Kuuse
2017-11-28 10:12:50 UTC
Permalink
Post by David Mason
I would like yesterdays with a bit of whitespace between commit comments.
Also someone liked the original because the checkin tag was in a
predictable place. If you put the tag last in the extra information it
would be predictably at the right margin.
Post by Richard Hipp
Post by Steve Landers
Nice work.
Have you considered dropping the borders on the commits? They do add
definition to the commit, but at the expense of repetition and possibly
“noise” when the branch isn’t colored
https://www.fossil-scm.org/fossil/timeline
https://www.fossil-scm.org/fossil/timeline?dp=d95f712&n=4
https://www.fossil-scm.org/fossil/timeline?b=2017-09-01
https://www.fossil-scm.org/fossil/finfo?name=src/db.c
https://www2.fossil-scm.org/fossil/timeline
https://www2.fossil-scm.org/fossil/timeline?dp=d95f712&n=4
https://www2.fossil-scm.org/fossil/timeline?b=2017-09-01
https://www2.fossil-scm.org/fossil/finfo?name=src/db.c
https://www3.fossil-scm.org/site.cgi/timeline
https://www3.fossil-scm.org/site.cgi/timeline?dp=d95f712&n=4
https://www3.fossil-scm.org/site.cgi/timeline?b=2017-09-01
https://www3.fossil-scm.org/site.cgi/finfo?name=src/db.c
Please do not restrict yourself to just the links shown. Look at
various timelines to see what works well and what does not.
--
D. Richard Hipp
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
While I agree that it is important to have a default (original) skin that
works well (text must be readable, etc.) , I think the one important thing
is that all involved HTML elements have a 'class' or 'id' tag.
As a positive spin-off effect, I think way users will be more encouraged to
use the Fossil 'skins' feature to modify the CSS to fit her/his taste.
Some people like borders and rounded corners, others don't.
What I consider "enhancement", someone else could consider "noise".
And so on.
I think it is impossible to get "one style fits all"...

BR,
Johan
Post by David Mason
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Richard Hipp
2017-11-28 12:37:49 UTC
Permalink
Post by Johan Kuuse
I think it is impossible to get "one style fits all"...
Indeed. So my latest strategy is to provide a combobox in the submenu
that lets the user selected between a small number of formats:
"Compact", "Relaxed", "Detailed" (new name suggestions will be
welcomed). Each format is separately styleable using CSS. The chosen
style is remembered in a cookie, so that every time you visit a
timeline page you start with the same format as you had the time
before.
--
D. Richard Hipp
***@sqlite.org
Warren Young
2017-11-29 02:29:33 UTC
Permalink
I think the one important thing is that all involved HTML elements have a 'class' or 'id' tag.
Yes. Several times in making my last custom Fossil skin, I’ve had to employ some rather clever CSS selector trickery to target the elements I was interested in, when it would have been simpler if the elements could have been targeted directly.

All these duplicate id and class attributes compress very nicely, so they’re not very costly. It’s just tedious to remember to add them in the Fossil source ahead of need.

I don’t know that *every* tag needs to have an id or class, but if you can think of a way to identify or classify an element, someone else can probably think of a way to style it specially.
Some people like borders and rounded corners, others don’t.
Yes, so rather than try to please everyone, let’s ship something that is pleasant enough to ward off charges of ugly defaults, but which gives lots of ideas for tweaking, to inspire custom skins.

In a word, the new design should be “featureful.”

It’s easier to see something and say, “I don’t like that, it should be like *so*,” than to have a page you consider ugly because it lacks enough styling for your taste, but where all the affordances to fix that are hidden as currently-unused id and class tags.

So, when adding new id and class attributes, think also of a way to show them off visually via the default skin. If someone doesn’t like the new styling, they can strip it back off with a bit of CSS tweaking.
Richard Hipp
2017-11-29 03:08:38 UTC
Permalink
Please offer your opinions on:

https://www.fossil-scm.org/b/timeline

Changes:

(1) You have a selection of styles: Normal, Compact, Verbose,
Columnar. Each can be styled separately.

(2) The style selection, the number of elements in the timeline, and
whether the timeline shows just check-ins or all changes, are all
"sticky". They default to whatever the last selection was.

Limitations:

(3) I have so far only implemented this for /timeline. Still need to
fix it on /finfo and on /fileage.

(4) The four modes are hard-coded. You cannot adjust the number nor
the names of the modes. I could make that a configuration option, I
suppose....

Notes:

To try this out locally, download and compile the tip of the
"sticky-timeline-style" branch.
https://www.fossil-scm.org/b/timeline?r=sticky-timeline-style
--
D. Richard Hipp
***@sqlite.org
Richard Hipp
2017-11-29 03:17:23 UTC
Permalink
Post by Richard Hipp
https://www.fossil-scm.org/b/timeline
Other comparison repositories:

http://mirror1.tcl.tk/tcl-b/timeline
https://sqlite.org/b/timeline
Post by Richard Hipp
(1) You have a selection of styles: Normal, Compact, Verbose,
Columnar. Each can be styled separately.
(2) The style selection, the number of elements in the timeline, and
whether the timeline shows just check-ins or all changes, are all
"sticky". They default to whatever the last selection was.
(3) I have so far only implemented this for /timeline. Still need to
fix it on /finfo and on /fileage.
(4) The four modes are hard-coded. You cannot adjust the number nor
the names of the modes. I could make that a configuration option, I
suppose....
To try this out locally, download and compile the tip of the
"sticky-timeline-style" branch.
https://www.fossil-scm.org/b/timeline?r=sticky-timeline-style
--
D. Richard Hipp
--
D. Richard Hipp
***@sqlite.org
Joe Mistachkin
2017-11-29 03:24:26 UTC
Permalink
Post by Richard Hipp
(1) You have a selection of styles: Normal, Compact, Verbose,
Columnar. Each can be styled separately.
Pretty please, can we have a "Legacy" style that gives the old look?

I think not having the check-in at the front of the line is going to
be a huge pain for me to adapt to.

--
Joe Mistachkin @ https://urn.to/r/mistachkin
Richard Hipp
2017-11-29 03:33:04 UTC
Permalink
Post by Joe Mistachkin
Post by Richard Hipp
(1) You have a selection of styles: Normal, Compact, Verbose,
Columnar. Each can be styled separately.
Pretty please, can we have a "Legacy" style that gives the old look?
Maybe "Verbose" should be modified to include the hash up front....
--
D. Richard Hipp
***@sqlite.org
Joe Mistachkin
2017-11-29 03:35:15 UTC
Permalink
Post by Richard Hipp
Maybe "Verbose" should be modified to include the hash up front....
Yeah, something like that would be cool. Also, having the "Leaf" indicator,
et al, up front as well (like before)?

--
Joe Mistachkin @ https://urn.to/r/mistachkin
Richard Hipp
2017-11-29 03:43:07 UTC
Permalink
Post by Joe Mistachkin
Yeah, something like that would be cool. Also, having the "Leaf" indicator,
et al, up front as well (like before)?
"Verbose" mode now looks like legacy.
--
D. Richard Hipp
***@sqlite.org
Joe Mistachkin
2017-11-29 03:58:34 UTC
Permalink
Post by Richard Hipp
"Verbose" mode now looks like legacy.
Thank you, much appreciated.

--
Joe Mistachkin @ https://urn.to/r/mistachkin
Andy Bradford
2017-11-29 06:18:07 UTC
Permalink
Post by Richard Hipp
Maybe "Verbose" should be modified to include the hash up front....
This was one of the factors that actually lead to my #1 ranking for
Verbose.

Andy
--
TAI64 timestamp: 400000005a1e5143
Richard Hipp
2017-11-29 03:35:14 UTC
Permalink
(5) The selected-entry highlighting is messed up for MS-Edge. Ex:
https://www.fossil-scm.org/b/timeline?ss=n&c=2017-07-07 - suggestions
for how to fix this are welcomed.
--
D. Richard Hipp
***@sqlite.org
Andy Bradford
2017-11-29 06:14:12 UTC
Permalink
Post by Richard Hipp
https://www.fossil-scm.org/b/timeline
I see that you've corrected one of the problems I mentioned previously
which was the melding of different comments in the same branch by
introducing a small border when viewing in Comapct mode. This does make
it more readable.

The Columnar option is certainly interesting. I don't think I could
learn to like it much, but I can see some usefulness to some.

My rankings (1 being the highest rank):

1) Verbose
2) Normal (without rounded edges)
3) Columnar (without rounded edges)
4) Compact

My problem with the rounded edges is that in some of the timeline
displays they don't look right. Specifically /info pages and other
similar timelines:

http://www.fossil-scm.org/b/info/59980b6082f7ffe4
http://www.fossil-scm.org/b/timeline?c=2017-11-29+03:41:17

If I need to provide a screenshot, I can do so.

Andy
--
TAI64 timestamp: 400000005a1e5058
Mike Z.Vand
2017-11-28 10:18:40 UTC
Permalink
Send me your ideas of what you think timelines should look like.  Even better: send me mock-ups.
Since we’re at it, I’m going ahead with some other CSS suggestions. Here I’ve mostly focused on “calendar” demarcations which Ithink should get more attention. Overall, it’s more compact but it uses more visualcues to “guide” the users’ eyes.

These modifications can be directly added at end of the “style.css”verbatim; however, for one or two of these items I had to get into HTML code andunfortunately that can only be applied in fossil C code (Just added a class to TRs for timelineDate and changed Branch background colors opacity).

 

Applying over https://www3.fossil-scm.org/site.cgi/timeline

Loading Image...

And over https://www2.fossil-scm.org/fossil/timeline?b=2017-09-01

Loading Image...

And https://www2.fossil-scm.org/fossil/timeline?b=2017-07-01+18:09:59

Loading Image...

 
That highlighted commit has the mouse hover over it. I wishI could achieve these without modifying the HTML code so this could be a simpleCSS theme change anyone could try it live with a copy and paste; I guess for now Ijust settle for some screen captures.
/* resetting some values */.content {  color: #222;}div.divider {  background: none;  border: none;  font-weight: bold;}table.timelineTable {  border-collapse: separate;  border-spacing: 0px 1px;  margin-left: 20px;}
/* Adds a padding between "days" */table#timelineTable0 div.timelineDate {  padding: 18px 0px 2px 0px;  margin-left:-20px;}/* Skips the first date */table#timelineTable0 tr:nth-child(1) div.timelineDate:nth-child(1) {  padding: 0;}
/* Adds alternate row shades */table#timelineTable0 tr:nth-child(odd) {  background-color:#f4f4f4;}table#timelineTable0 tr:nth-child(odd) td:nth-child(1) {  background-color: #f0f6f9;}table#timelineTable0 td:nth-child(3) {  border-radius: 0px 5px 5px 0px;}table#timelineTable0 td:nth-child(1) {  border-radius: 5px 0px 0px 5px;;}

/* Adds some more padding */table#timelineTable0 > tbody td {  padding-top: 4px;  padding-bottom: 5px;}td.timelineTableCell {  padding-left: 7px;  border: none;}
/* mouse hover over effects */table#timelineTable0 tr:hover:nth-child(odd) {  background-color: hsla(210, 70%, 94%, 1);}table#timelineTable0 tr:hover:nth-child(even) {  background-color:  hsla(210, 70%, 94%, 1);}table#timelineTable0 tr:hover td:nth-child(1) { background-color:hsl(210, 53%, 51%);}table#timelineTable0 tr:hover td:nth-child(1) a { color: white;}
/* No shading for "date" stamps   for this to work, each "date" TR should be classed with timelineDateTR in HTML source */
table#timelineTable0 tr.timelineDateTR, table#timelineTable0 tr.timelineDateTR:hover {  background-color: rgba(255, 255, 255, 0);}table#timelineTable0 tr.timelineDateTR td:nth-child(1), table#timelineTable0 tr.timelineDateTR:hover td:nth-child(1) {  background-color: rgba(255, 255, 255, 0);}
table#timelineTable0 td:nth-child(1) a.timelineHistLink {  display: inline-block;  width: 100%;  text-align: center;}


Also I reduced the opacity of Branch background colors whichI’ve always felt were all a bit too dark and actually made the overlying textless readable. This can only be done in C code and is the most involved modificationhere. Colors are coded as RGB hexes in fossil. They need to be converted torgba(r, g, b, alpha) before sending over. I went with alpha value of 0.5.

By the way, I greatly appreciate all the efforts everyone's puttinginto this project.

Mike.
Andy Bradford
2017-11-29 05:54:11 UTC
Permalink
Post by Richard Hipp
https://www.fossil-scm.org/fossil/timeline
Hard to stomach (as previously mentioned).
Post by Richard Hipp
https://www2.fossil-scm.org/fossil/timeline
Slightly better, but still has the annoying ``feature'' that makes
highlighting text in a comment a terrible experience. The rounded
corners don't seem to look right with the drop-shadow.
Post by Richard Hipp
https://www3.fossil-scm.org/site.cgi/timeline
Of the three this on definitely looks best, but still has the annoying
behavior when highlighting words in the commit message for copy/paste.

Also, for a fair comparison, shouldn't there also be a timeline that has
the original behaviors?

Thanks,

Andy
--
TAI64 timestamp: 400000005a1e4ba6
Andy Bradford
2017-11-29 05:36:49 UTC
Permalink
I have installed the new look (temporarily at least) on
https://www.fossil-scm.org/fossil so that we can live with it for a
while to see how we like it.
I tend to prefer having more information to less, but the biggest
drawback to hiding everything is that now every commit message seems to
blend together with all the adjacent commits in the same branch. Before,
we at least had all the commit hashes at the beginning of each commit
message which served as a natural divider between commits; also there
were some links that were underlined (tags, branches, and users)
providing some level of distinction between them, but now that this
information is hidden, all the comments from a single branch blend
together making it difficult to make sense of it all.

Just my $0.02.

Andy
--
TAI64 timestamp: 400000005a1e4794
Jungle Boogie
2017-11-29 06:21:32 UTC
Permalink
Post by Andy Bradford
I have installed the new look (temporarily at least) on
https://www.fossil-scm.org/fossil so that we can live with it for a
while to see how we like it.
I tend to prefer having more information to less, but the biggest
drawback to hiding everything is that now every commit message seems to
blend together with all the adjacent commits in the same branch. Before,
we at least had all the commit hashes at the beginning of each commit
message which served as a natural divider between commits; also there
were some links that were underlined (tags, branches, and users)
providing some level of distinction between them, but now that this
information is hidden, all the comments from a single branch blend
together making it difficult to make sense of it all.
yes, in this view without the spacing or commit IDs, I agree. Would it
look better if the diff buttons were moved over towards the commits, or
would that get too ugly with multiple branches?

When seen in this view, the commits are a easier to follow:
https://www.fossil-scm.org/fossil/timeline?ymd=2017-11-28

The commit IDs are hidden away so we don't have to skip over them with
our eyes, but we're able to expose it if we want by clicking on the
commit.
Post by Andy Bradford
Just my $0.02.
Andy
--
TAI64 timestamp: 400000005a1e4794
Richard Hipp
2017-11-29 14:26:57 UTC
Permalink
The 4-view-modes timeline change is now on trunk and is the default on
these sites:

https://sqlite.org/src/timeline
https://www.fossil-scm.org/fossil/timeline
http://mirror1.tcl.tk/tcl/timeline
https://androwish.org/index.html/timeline

The "selected entry" highlighting, such as seen here:

https://www.fossil-scm.org/fossil/timeline?c=trunk

Still looks goofy in the Modern View, especially using Edge. Your
help in fixing that problem will be much appreciated.

Bug reports and suggestions for further improvement to the timeline
are also appreciated. Your feedback so far has been very helpful.
Please don't stop.
--
D. Richard Hipp
***@sqlite.org
Martin Gagnon
2017-11-29 14:53:54 UTC
Permalink
Post by Richard Hipp
The 4-view-modes timeline change is now on trunk and is the default on
https://sqlite.org/src/timeline
https://www.fossil-scm.org/fossil/timeline
http://mirror1.tcl.tk/tcl/timeline
https://androwish.org/index.html/timeline
https://www.fossil-scm.org/fossil/timeline?c=trunk
Still looks goofy in the Modern View, especially using Edge. Your
help in fixing that problem will be much appreciated.
Looks really nice, thanks. I like the Modern View with the right
justified extra check-in/user/tags informations and the vertical spacing
between commits.

There's a small display glitch, the mouse cursor over the
Basic/Advanced button is set to "text selection" mode instead of the
usual "hand with the index finger up" for clickable links.

Regards,
--
Martin G.
Warren Young
2017-11-29 15:10:28 UTC
Permalink
Post by Martin Gagnon
There's a small display glitch, the mouse cursor over the
Basic/Advanced button is set to "text selection" mode instead of the
usual "hand with the index finger up" for clickable links.
It can be fixed by adding href="#" into the <a> elements wrapping the Basic and Advanced text. It would take a CSS geek with a bigger propeller than the one on my beanie to tell you why that fixes it, though.
Martin Gagnon
2017-11-29 15:27:24 UTC
Permalink
Post by Warren Young
Post by Martin Gagnon
There's a small display glitch, the mouse cursor over the
Basic/Advanced button is set to "text selection" mode instead of the
usual "hand with the index finger up" for clickable links.
It can be fixed by adding href="#" into the <a> elements wrapping the
Basic and Advanced text. It would take a CSS geek with a bigger
propeller than the one on my beanie to tell you why that fixes it,
though.
Using "Inspect" on chrome, I found that adding:

cursor: pointer;

inside "element.style" fix the problem.

I'm not sure where I should add this to have a permanent fix.
--
Martin G.
Warren Young
2017-11-29 15:32:52 UTC
Permalink
Post by Martin Gagnon
Post by Warren Young
It can be fixed by adding href="#" into the <a> elements
cursor: pointer;
inside "element.style" fix the problem.
That feels more heavy-handed to me. My method works with the browser’s defaults by giving the anchor tags a target.

Notice that there is no custom cursor attribute on the other <a> tags in the menu <div>. They use href attributes, not onclick, which is why they don’t need the cursor attribute to be overridden.

Incidentally, drh, if you ever get around to tightening down the CSP rules on Fossil, things like inline onclick=“” attributes can be a problem. They count as inline JavaScript, so are disallowed at the stricter levels of CSP. For much the same reasons as it’s best to move inline CSS out into a separate stylesheet, it’s best to move event handler assignments out into an external JS file, then arrange for an init function to be called on page load.

Strict CSP can be a pain, alas.
Warren Young
2017-11-29 15:16:34 UTC
Permalink
Post by Richard Hipp
https://www.fossil-scm.org/fossil/timeline?c=trunk
Still looks goofy in the Modern View, especially using Edge. Your
help in fixing that problem will be much appreciated.
It’s applying the style to the containing <tr> rather than to the <td> that most of the recent changes have been targeting. If you move the timelineSelected class to the td.timeline*Cell element [*] and get rid of the padding style override, I think it will give you the result you were expecting:

https://imgur.com/a/TEWjA

[*] To be clear, that means the <td> element ends up with two classes.
Warren Young
2017-11-29 15:25:04 UTC
Permalink
Post by Warren Young
[*] To be clear, that means the <td> element ends up with two classes.
Even more clear:

<td class="timelineModernCell timelineSelected">...

td.timelineSelected {
border-width: 2px;
background-color: #ffc;
box-shadow: 4px 4px 2px rgba(0, 0, 0, 0.5);
}
Richard Hipp
2017-11-29 15:26:25 UTC
Permalink
Post by Warren Young
Post by Richard Hipp
Still looks goofy in the Modern View, especially using Edge. Your
help in fixing that problem will be much appreciated.
It’s applying the style to the containing <tr> rather than to the <td> that
most of the recent changes have been targeting. If you move the
timelineSelected class to the td.timeline*Cell element [*] and get rid of
the padding style override, I think it will give you the result you were
https://imgur.com/a/TEWjA
I think we'd like the selection mechanism to somehow highlight the
entire row, including the parts of the graph and the date/time field.
As it does for:

https://www.fossil-scm.org/fossil/timeline?c=c94f6085&ss=v

If we have to fall back to only selected the check-in comment text,
that's what we have to do. But I think it makes it clearer if the
entire row is selected.
--
D. Richard Hipp
***@sqlite.org
Warren Young
2017-11-29 15:50:00 UTC
Permalink
Post by Richard Hipp
Post by Warren Young
https://imgur.com/a/TEWjA
I think we'd like the selection mechanism to somehow highlight the
entire row
I don’t think it really helps, but this gets you part of the way there:

tr.timelineSelected td.timelineModernCell {
border-width: 0;
border-radius: 0;
}

For some reason, border-radius and the box-shadow effect don’t combine well on <tr> as they do with <td>, at least with Chrome.

You can’t make the white gaps go away without collapsing borders throughout the table, which would remove the white gaps between colored rows, too.
s***@gmail.com
2017-11-29 18:11:17 UTC
Permalink
Focusing on the Compact view:
Is there any chance to limit the click action to just the ellipses?
And to revert, click on the added content, Ex. "check-in:" or "user:".
As others mentioned, it is annoying when selecting text from the comments
to have the background action.
Post by Warren Young
Post by Richard Hipp
Post by Warren Young
https://imgur.com/a/TEWjA
I think we'd like the selection mechanism to somehow highlight the
entire row
tr.timelineSelected td.timelineModernCell {
border-width: 0;
border-radius: 0;
}
For some reason, border-radius and the box-shadow effect don’t combine
well on <tr> as they do with <td>, at least with Chrome.
You can’t make the white gaps go away without collapsing borders
throughout the table, which would remove the white gaps between colored
rows, too.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Andy Bradford
2017-11-29 05:40:56 UTC
Permalink
The big down-side is that less information is visible on a single
screen now, so you have to scroll more. But that seems to be the trend
with websites these days....
There's another extremely annoying downside to this as well---I like to
double-click or triple-click to highlight words in commit logs, and now
that behavior is extremely unpleasant, if not outright hindered.
Clicking anywhere in the commit message, including double-clicks to
highlight words makes copy/paste not fun.

More $0.02.

Andy
--
TAI64 timestamp: 400000005a1e488b
Jungle Boogie
2017-11-29 06:08:58 UTC
Permalink
Post by Andy Bradford
The big down-side is that less information is visible on a single
screen now, so you have to scroll more. But that seems to be the trend
with websites these days....
There's another extremely annoying downside to this as well---I like to
double-click or triple-click to highlight words in commit logs, and now
that behavior is extremely unpleasant, if not outright hindered.
Clicking anywhere in the commit message, including double-clicks to
highlight words makes copy/paste not fun.
In which mode? I think this is only an issue in the compact mode, right?
Post by Andy Bradford
More $0.02.
Andy
--
TAI64 timestamp: 400000005a1e488b
Andy Bradford
2017-11-30 06:30:43 UTC
Permalink
In which mode? I think this is only an issue in the compact mode,
right?
Yes, after further experimentation, the problem only exists with the
Compact mode.

Andy
--
TAI64 timestamp: 400000005a1fa5b8
Doug Franklin
2017-12-03 17:43:26 UTC
Permalink
Post by Richard Hipp
Which is better?
A: https://www.fossil-scm.org/a/timeline
B: https://www.fossil-scm.org/b/timeline
They both use too much vertical screen space, IMO.
Post by Richard Hipp
A: https://www.fossil-scm.org/a/finfo?name=src/search.c
B: https://www.fossil-scm.org/b/finfo?name=src/search.c
B is much better, IMO. Just as clear and less vertical space waste.

Wasting space vertically has become a huge problem in UI designs for me
the last few years.
Post by Richard Hipp
The change here is to emphasis the check-in comment and de-emphasize
the links to the check-in details and other information.
That's a good objective, and I like the examples about equally from that
standpoint.
--
Doug "Lefty" Franklin
NutDriver Racing
http://NutDriver.org
Facebook: NutDriver Racing
Sponsored by Murphy
Reimer Behrends
2017-12-05 14:30:28 UTC
Permalink
Post by Richard Hipp
Which is better?
A: https://www.fossil-scm.org/a/timeline
B: https://www.fossil-scm.org/b/timeline
I don't see much of a difference, to be honest (but that may be because
I'm late to the party and the layouts have changed during the past
days). The modern/normal/columnar views all seem to consume a lot of
screen real estate for my taste.

I'll add that my biggest issue with the timeline UI is the presentation
of check-in links. You cannot copy them without the surrounding
brackets, which means that you cannot paste them into the command line
without editing, or first clicking through the link and then using the
entire hash. This is exacerbated by the problem that on the command
line, `fossil timeline` is very limited compared to what the web UI
offers, so for a lot of use cases, you're forced to use the web interface.

Reimer Behrends
s***@gmail.com
2017-12-05 14:50:46 UTC
Permalink
I agree. Why does the [brief-hash] need to be a hyperlink and bracketed
when the Timeline time stamp has the same link?
Post by Reimer Behrends
Post by Richard Hipp
Which is better?
A: https://www.fossil-scm.org/a/timeline
B: https://www.fossil-scm.org/b/timeline
I don't see much of a difference, to be honest (but that may be because
I'm late to the party and the layouts have changed during the past days).
The modern/normal/columnar views all seem to consume a lot of screen real
estate for my taste.
I'll add that my biggest issue with the timeline UI is the presentation of
check-in links. You cannot copy them without the surrounding brackets,
which means that you cannot paste them into the command line without
editing, or first clicking through the link and then using the entire hash.
This is exacerbated by the problem that on the command line, `fossil
timeline` is very limited compared to what the web UI offers, so for a lot
of use cases, you're forced to use the web interface.
Reimer Behrends
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Richard Hipp
2017-12-05 15:27:28 UTC
Permalink
Post by Reimer Behrends
Post by Richard Hipp
Which is better?
A: https://www.fossil-scm.org/a/timeline
B: https://www.fossil-scm.org/b/timeline
I don't see much of a difference,
Thanks for looking. But the original question is old, and the display
is moved on. I'm not sure there is any difference in the A/B above
any more. Probably I should remove those links :-)

As you can see on the Fossil timeline
(https://www.fossil-scm.org/timeline) I am busy making lots of
changes. And I typically update the server to the latest check-in.
See the light gray text at the very bottom of the page to find which
version of Fossil is running on the server - currently cee662d96e. So
every change I make to the code is quickly reflected on the website.

Please keep a close eye on the Fossil website and report any usability issues.

Also watch https://sqlite.org/src as it is using the exact same Fossil server.
--
D. Richard Hipp
***@sqlite.org
j. van den hoff
2017-12-05 15:53:46 UTC
Permalink
Post by Richard Hipp
Please keep a close eye on the Fossil website and report any usability issues.
just a thought: could/should the boxes+checkin messages be indented,
reflecting the horizontal position of the respective branch in the
timeline graph (specifically, keeping the horizontal distance from the
respective timeline graph bullet to the box constant for all branches)? I
am aware that one would sacrifice some horizontal "real estate" by this,
if there are many open branches (e.g. http://core.tcl.tk/tcl/timeline),
but actually most ci messages are short so that would not cause too many
line breaks. I could imagine
that indenting would help to read through the contiguous ci messages of a
certain branch a bit on top of what the color coding provides, especially
for instances for the colors are recycled for different branches, e.g.
here:

http://core.tcl.tk/tcl/info/dcc6f04732c93947

any thoughts?

thx,
joerg
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Dominique Devienne
2017-12-06 07:37:54 UTC
Permalink
Post by Reimer Behrends
Post by Richard Hipp
Which is better?
A: https://www.fossil-scm.org/a/timeline
B: https://www.fossil-scm.org/b/timeline
I don't see much of a difference,
Thanks for looking. But the original question is old, and the display is
moved on. [...]
Please keep a close eye on the Fossil website and report any usability
issues.
None of the 4 current views have the author/branch/hash links below the
message
in smaller and slightly washed out color as seen at one point on the A/B
testing I believe.
They are all at the far end-right, and when using full screen windows on a
large monitor,
this forces the gaze to move horizontally too much from left to right IMHO.

If there was 1 "modern" view (i.e. with boxes) but with a 2-lines setup,
with the first line
for commit message in the "normal" font, and a second for the meta-data and
links in a
smaller font with a bit less visibility (to allow reading the commit
messages top to bottom
without interfering visually too much), it would fit wide screen much
better IMHO.

We could call it "modern wide-screen" for example. My $0.02. --DD
Richard Hipp
2017-12-06 08:36:11 UTC
Permalink
Post by Dominique Devienne
If there was 1 "modern" view (i.e. with boxes) but with a 2-lines setup,
with the first line
for commit message in the "normal" font, and a second for the meta-data and
links in a
smaller font with a bit less visibility (to allow reading the commit
messages top to bottom
without interfering visually too much), it would fit wide screen much
better IMHO.
We could call it "modern wide-screen" for example. My $0.02. --DD
Good idea. I have assigned the "draft5" skin to you on the main
Fossil website, so that you can experiment with this approach and show
us what you have in mind. If you come up with a good look, I'll add
it as a new "Wide Screen" option.

You'll need to login as user "***@gmail.com" in order to edit
the draft5 skin. I'll send you your password by private email.

A quick web search suggests that using "overflow: hidden; white-space:
nowrap;" might serve to keep the comment text all on one line.
--
D. Richard Hipp
***@sqlite.org
Continue reading on narkive:
Loading...