It's my feeling that with the new "Responsive" Site Map, to list links in 1 to 3 columns depending on the display width, it's more difficult to find specific links, as they can suddenly be in another column, and they can also move horizontally even if the number of columns remains constant, as the columns seem to be evenly distributed across a certain minimal width, instead of being just as wide as required (and left-aligned).

I would prefer the site map to group links into at most 2 columns, with one well-defined and controlled column break (i.e. don't randomly break after level-1 heading-items and between level-2 sub-items, but only before one distinct level-1 heading-item), so that the level-1 heading-items are more useful for orientation. Currently, with 3 columns, heading-items can become the last item at the very bottom of a column, with their first sub-item at the top of the next column, which I think is not ideal to recognize the context of sub-items.

The two columns should have just the necessary width and be left-aligned, so the links can be found at constant positions, even if the browser window has been resized. In my opinion, this allows for much faster orientation and navigation. This even holds true if some of the heading-items can have a variable number of sub-items (if an administrator is logged-in, for example), as this will cause just small vertical offsets, compared to full-column jumps.

For tiny displays, the two columns could simply be stacked above each other into one single column.

So, I would prefer this layout (maybe the text of the overlong item could be shortened):

o Home Page                    o Wiki
  o Documentation                o Wiki Search
  o Download                     o List of Wiki Pages
  o License                      o Recent activity
  o Documentation Search         o Sandbox
o File Browser                   o List of Attachments
  o Tree-view, Trunk Check-in  o Login
  o Flat-view                    o Subscribe to Email Alerts
  o File ages for Trunk        o Repository Status
  o Unversioned Files            o Collisions on hash prefixes
o Project Timeline               o List of Artifacts
  o Activity Reports             o List of "Timewarp" Check-ins
  o File name changes          o Help
  o Forks                        o Wiki Formatting Rules
  o First 10 check-ins           o Markdown Formatting Rules
o Branches                       o List of All Commands and Web Pages
  o Tags                         o All "help" text on a single page
  o Leaf Check-ins               o Filename suffix to mimetype map
o Search                       o Test Pages
o Tickets                        o CGI Environment Test
  o Ticket Search                o List of file renames
  o Recent activity              o Page to experiment with the automatic colors assigned to branch names
  o List of Attachments          o Random ASCII-art Captcha image

over this one (confusing column breaks marked with <!>):

o Home Page                               o Tags                                  o Collisions on hash prefixes
  o Documentation                         o Leaf Check-ins                        o List of Artifacts
  o Download                            o Search                                  o List of "Timewarp" Check-ins
  o License                             o Tickets                               o Help
  o Documentation Search                  o Ticket Search                         o Wiki Formatting Rules
o File Browser                            o Recent activity                       o Markdown Formatting Rules
  o Tree-view, Trunk Check-in             o List of Attachments                   o List of All Commands and Web Pages
  o Flat-view                           o Wiki                                    o All "help" text on a single page
  o File ages for Trunk                   o Wiki Search                           o Filename suffix to mimetype map
  o Unversioned Files                     o List of Wiki Pages                  o Test Pages
o Project Timeline                        o Recent activity                       o CGI Environment Test
  o Activity Reports                      o Sandbox                               o List of file renames
  o File name changes                     o List of Attachments                   o Page to experiment with the automatic
  o Forks                               o Login                                     colors assigned to branch names
  o First 10 check-ins                    o Subscribe to Email Alerts             o Random ASCII-art Captcha image
o Branches <!>                          o Repository Status <!>

I'm not at all familiar with CSS, but is seems that CSS Flexbox gives greater control over user-defined column breaks and constant/as-required widths than CSS Columns?

I've also had the same feeling with the new file view, I find it significantly more difficult to navigate to a sepcific file in a crowded directory, as everything is jumping around with the variable number of columns. I'm never using any file browser with this view mode.

There need to be some compromise to support tiny displays, but at least the site map should be as comfortable as possible, being a valuable handmade navigation aid, and not just another list.

Adding this to your style CSS helps some:

div.columns > ul li {
  break-inside: avoid;
}

This prevents li elements from breaking across columns - using avoid rather than avoid-column is allegedly more compatible and should future-proof against changing to a flex or grid layout. Selecting all child lis should keep items in sub-lists from breaking, too.

Unfortunately this is a partial fix - the sitemap page only generates some sub-lists as children of the top-level list items, so some can still break across columns. Specifically: the File Browser, Project Timeline, and Branches <li> elements do not contain their child <ul> elements. Changing this requires patching sitemap.c.

I modified fossil in a private repo to address this inconsistency and add the above CSS to the default. The columns aren't quite even anymore, but it avoids having sub-lists or list items broken across columns which I find difficult to read. Here's a patch against the current trunk.

These are good hints, thank you.

I would like to vote for the default built-in site map to have at most 2 left-aligned columns, so it's easy to spot links at constant/well-known positions also for newly created repositories, before the skin and other settings are customized.

A good example of a column-free page is the Fossil Documentation Index. Columns, more so if evenly distributed, would make it almost impossible to find anything (visually).

Thanks for the "break-inside: avoid;" hint. I had no idea that CSS existed.

Here is a suggested improvement that somebody can help me with:

Demonstrate how to add a hamburger menu that, when pressed, uses XMLHttpRequest() to pull down the /sitemap page, extract the feature list from the middle of that page, and insert the list below the menu-bar. Clicking on the hamburger again causes the list to go away.

Bonus points for animation that makes the list appear to slide into place.

Demonstrate how to add a hamburger menu that, when pressed, uses XMLHttpRequest() to pull down the /sitemap page, extract the feature list from the middle of that page, and insert the list below the menu-bar. Clicking on the hamburger again causes the list to go away.

Maybe we can just create a /sitemap.json endpoint for the API, which only return the list of link as a json dictionary. It'll avoid the extraction part, which seems a bit hazardous to me. What do you think?

Demonstrate

Here you go. :)

I've checked the diffs in on the jquery-hamburger-button branch.

I don't think it's ready to be pushed to trunk even if your taste and mine matched exactly. The menu width could use some work, it isn't tested on mobile yet, and the font sizes could use some work. I also have yet to see it go multi-column, yet it should.

EDIT: I've also seen it refuse to pull the menu down the first time you click it on a fresh page load. Sometimes it works, and sometimes not. I think the open and close click handlers are fighting, creating a race condition.

Anyway, this should certainly get you started.

Bonus points for animation that makes the list appear to slide into place.

Just so long as you don't take points away for using jQuery. ;)

In defense of my use of jQuery, it's about more than just my familiarity with the library. I think the code would end up being 2-3x larger with hand-rolled JS without even considering the animation. XHR is a particularly ugly API, as you must know, and jQuery's selector API is more powerful than the one built into JavaScript. I'm not sure, but I think that inner "find the ul#sitemap" bit might not be too easy with plain old JS.

As for my use of Google Hosted Libraries, that's largely just for the purposes of the demonstration. It's fine for any use case where Internet access is available; it's even really fast, thanks to Google's unexceeded ability to cache and serve static content. However, it'll break any time someone uses Fossil offline.

Therefore, I'd take these as opposing forces and make an engineering call: embed jQuery in Fossil, or rewrite it without the benefit of jQuery.

Consider also the possibility of shrinking some of the other JS code in Fossil. jQuery got popular fast for a reason.

I've also seen it refuse to pull the menu down the first time you click it on a fresh page load.

That's fixed now, both on the branch and on the MySQL++ site where this feature is currently live.

Nice demo. Thanks!

Note that it has issues on mobile, thus defeating a big part of the original purpose for having a hamburger menu. Nevertheless, it is a very good proof of concept.

I like it, definitely more modern. Good job and thanks for putting this up so quickly.

How would someone go about customizing their sitemap? I'm not so sure help options on using fossil need to always be shown. Maybe the help and test pages could automatically be folded up and out of the way. Doing this would cut down on the vertical scrolling needed on my monitor (which I never have the browser full screen).

By the way, all the links lead to https://tangentsoft.com/mysqlpp/honeypot

Javascript is enabled and if I browse to the timeline by clicking on timeline, it will load correctly.

How would someone go about customizing their sitemap?

Currently, it's hardcoded in src/sitemap.c. As you can see, it's almost entirely HTML, with just a bit of logic interlaced. It probably wouldn't be difficult to convert it to TH1 and offer it as part of the skin.

Patches thoughtfully considered. :)

Doing this would cut down on the vertical scrolling needed on my monitor

That's one of the reasons I want this menu to go 2-column on typical desktop browsers, at least.

I never have the browser full screen

Yes, just as Gutenberg intended. :)

all the links lead to ..../honeypot

That's Fossil's anti-robot defense. I have defeated it. Muaaahaha!

While I was in there, the anti-robot defense code cried out to me and begged for a jQuery conversion, so I obliged. It's now about half the size as before and clearer besides, to my eyes, at least. I checked it in separately to make the change easier to back out, if this campaign to adopt jQuery into Fossil fails.

Just to be clear, Fossil is not going to pick up a jQuery dependency.

I've converted the feature to remove the use of jQuery, using standard JS and CSS transitions instead. It's now running on the MySQL++ site.

It's "only" about 3× the size of the jQuery version because I chose to use a few features that will limit its portability to old browsers. So far, the only thing I'm sure of is that this code requires at least IE 10. This is arguably a safe requirement.

I don't talk about older versions of other browsers since Apple, Mozilla, and Google are far more aggressive than Microsoft about keeping their browsers up to date. I believe all browsers from those providers which are likely to be found in the wild will run this new hamburger menu, but I haven't yet run it through my collection of bottled browsers to be sure.

I've also solved the mobile and multicolumn problems noted above.

I've renamed the branch since the old name no longer makes sense given the later checkins on that branch.

I think the sitemap contents should be reduced for this use, perhaps via a query parameter so that the Ajax call can request the "light" sitemap. As it is, the sitemap is a bit verbose for use as menu content.

Known bug: the current 25 ms delay in showPanel() is still not sufficient in Firefox in some cases. 100ms seems reliable, but that's easily noticeable by a human. Maybe someone can suggest a better way to solve the issue brought up by the comment on that code.

I've increased the menu drop-down delay from 25ms to 40ms, and it seems to have solved the problem with Firefox 62 on macOS, at least. That's about as far as I'm willing to go given human perception limits, so if someone sees the menu just pop into existence on the first click, some other solution is needed.

Nice work, you must be Speedy Gonzales!

I have a few general questions and remarks concerning the hamburger menu:

• Isn't the hamburger button meant to be a placeholder for menu items that don't fit the (width) of the browser window? If there's enough room for the entire menu bar, the hamburger button could probably go to the right, and be labeled with ［More ▼］ (with the arrow indicating the drop-down feature) instead of ［☰］ (which is somewhat "cryptic")?

• As already mentioned, having the site map as a popup menu seems redundant. I think a hand-picked (possibly admin-customizable) list of links may be more useful? Also, shortened descriptions give a better overview, and allow for faster navigation.

• Couldn't the contents of the hamburger menu be output with the HTML the first time the page is generated, to a hidden <div>, or a <script> containing JSON-data, so no extra XHR is needed? (The XHR result is cached in a JavaScript variable, but is thrown away when navigating to another page, which is likely to happen each time the user is opening the menu.)

• The hamburger menu can't be closed while the hamburger button is out of sight. Closing by keyboard shortcut (ESC), and by clicking outside the menu, would come to the rescue. An additional ［Close］ or ［X］ button on the menu itself may be required for the corner cases where the menu covers the entire browser window (and no keyboard shortcuts are available).

• The animation (if really necessary) should be fast, see:

  • Optimal duration for animating transitions
  • Response Times: The 3 Important Limits.

• I'd like to vote for the hamburger menu to be an optional feature. The JavaScript code could simply abort if the <div id='hbdrop'> element is missing on the page.

Due to its modest system requirements, Fossil can be used on old (virtual) machines or embedded systems. I'd vote to support at least IE8. The /timeline graphs also require more recent versions of IE, but the /timeline web ui is still usable down to IE5.5.

"Please note that Fossil no longer supports Internet Explorer" sounds like a feature borrowed from GitHub ... ;-)

you must be Speedy Gonzales!

No, this sort of thing just happens to be in my professional wheelhouse.

Most of your points I agree with; they just require time, will, and skill.

having the site map as a popup menu seems redundant.

That's why I removed the More → /sitemap link at the end of the default skin.

I have no objection to reverting that switch when space allows. This is first and foremost a tech demo, not a finished product.

[☰］ (which is somewhat "cryptic")?

It's an established convention, probably about 5 years old now. What sort of Fossil user doesn't understand its meaning?

I prefer text labels to iconographs myself, but the whole point of the hamburger menu is that we need a convention to replace one or more menu labels when space is too tight to allow them.

I'd vote to support at least IE8.

No, NO, NOOO.

IE8 implies that you're still targeting stock Windows 7 as your base, which dropped out of mainstream support years ago. As I linked above, Microsoft's been saying for about 2 years that the only thing they'll support is IE11 and Edge.

I can't even come up with a good argument for supporting IE9. I looked, and it wasn't part of Win7 SP1, the minimum version to get extended support from Microsoft.

Win7 SP1 will run IE11. I haven't tried running such a system in a long time, but I wouldn't be surprised if it's marked "Recommended" or above in Windows Update on Win7 these days.

IE10 is where Microsoft began to approach the standards compliance of competing browsers. There was a point where Microsoft was 5+ years behind the rest of the industry!

The only thing I'd be willing to do for ancient IE is to add checks to skip the drop-down when run on them, and then only because I don't want a JS error to stop all JS processing in that session.

Ironically, your argument about old and small machines is typically self-defeating, since on such systems, you're usually using something based on Firefox, KHTML, Opera, or Chromium, which are generally more capable than IE8 or IE9.

The only time I see IE < 10 these days is when I happen to fire up one of the IE test VMs which used to be hosted at http://modern.ie/, which are purposely crafted to be superannuated. (This is part of what I referred to by my comment about "bottled browsers." I also keep ancient versions of SeaMonkey and such for this purpose.)

the /timeline web ui is still usable down to IE5.5.

That one's on my hit list, too. It needs to be redone with SVG canvasses or similar.

"Fossil no longer supports Internet Explorer" sounds like a feature borrowed from GitHub

That's an exaggeration of my position, which simply reflects a reciprocal relationship: if Microsoft wants us to support them, they need to support us.

Microsoft captured a major market lead with IE6, then let it sit there static for years upon years, while the rest of the industry pulled ahead. Microsoft still hadn't moved forward very much by the time they lost their market share lead first to Firefox, then to Chrome, which allowed the bulk of the web to decide they could actually start using these standards. By that point, IE was ~5 years behind their competition, and it took them years to catch up.

That cost Microsoft years of lifetime in the platforms this happened on.

You'd have a better argument if you found that the stock browser on Raspberry Pi didn't run the new code. At least that's a supported platform.

EDIT: I've just tested it, and a Pi 3 running a version of Raspbian Desktop I last updated back in December runs the new code just fine. Its default browser is based on Chromium 60, which is 9 releases old now.

[The timeline graph] is on my hit list, too. It needs to be redone using SVG canvasses or similar.

The /sitemap hamburger is optional. A site admin can choose to use the hamburger or not, by adjusting the header on the skin. I think it would be reasonable to have some skins that use the /sitemap hamburger and some that do not. That way, admins who want to support IE8 and earlier can use one of the hamburgerless skins. Even with the hamburger, Fossil still works pretty will on IE8 - just the hamburger isn't quite right. (The last sentence is conjecture - I don't have access to anything earlier than IE11 circa 2013.)

But the timeline graph is another matter. If the timeline graph depends on more recent features of the browser, Fossil becomes much much less usable with legacy browsers.

I did consider using canvas when I first invented the timeline graph. But, sadly, the W3C standards limit the height of a canvas to 32,768 pixels and timeline graphs often far exceed that size. So if you were to convert the graph to a canvas, you'd have to create a stack of canvases.

A site admin can choose to use the hamburger or not, by adjusting the header on the skin.

I actually have no plan to reflect any of this into the other skins, since they are more space-efficient and handle horizontal wrapping much better. Only the default skin needs it!

admins who want to support IE8 and earlier can use one of the hamburgerless skins.

Or, hack the menu item out. As Florian proposed, the JS code now bails early if the item is missing.

The code also falls back to non-animated show/hide behavior when CSS transitions aren't available.

The transition time is shortened a bit to 400 ms, and the constant is now reused rather than being repeated.

I don't have access to anything earlier than IE11

Sure you do: get the test VMs linked above. Microsoft kindly ships them in all the major VM formats, so it doesn't matter which VM tech you happen to use. (Microsoft of old might've shipped them only for HyperV, but not Nadella's Microsoft.)

Be sure to snapshot them before starting them, so you can just roll back to the snapshot rather than re-download them when they expire.

If the timeline graph depends on more recent features of the browser

That becomes a policy question: when can we drop support for old IE versions, and on what schedule?

At $dayjob, we support some very conservative clients, and we were able to move the minimum supported browser up to IE9 years ago without a peep from anyone. We could probably move it to IE11 with just as much reaction. It's rare for us to even see IE, and when we do, it's usually IE11 or Edge.

the W3C standards limit the height of a canvas to 32,768 pixels

I don't think that's the major hurdle. Consider line heights in the face of differing platform fonts, differing browser stock stylesheets, differing OS zoom levels... Where do you draw the arrows on the Y axis?

I think you'd have no choice but to draw the graph in segments, simply in order to get the arrows to line up properly. That makes the canvas height restriction moot.

You can't stretch the graph vertically to cope, because that would distort anything that isn't just a line, such as arrowheads.

In that case, you should see if drh will give you a developer login so you can check it in yourself, and thereby get full credit for the contribution.

I won't be able to get to this for many hours yet.

Ok, now I have a developer login, and I will try and commit the suggested changes to a separate branch.

So far, I have always been using Fossil with (local and remote) administrator capabilities, and I will take some time to look into the workflow with non-admin capabilities (i.e. start using private branches, or better start off with a fresh clone of the Fossil master repository, to make sure I won't commit anything unrelated, or with phantom dependencies).

I will take some time to look into the workflow with non-admin capabilities

Just say fossil sync https://USERNAME@fossil-scm.org in one of your checkout directories to associate your clone of the fossil-scm.org/fossil repository with your new user name on that repo.

start using private branches

I wouldn't recommend using that feature on fossil-scm.org. The goal is for everything to become public eventually, else why work on a FOSS project?

To me, there should only be two common kinds of commits on a FOSS project repo:

1. Commits which go straight to the trunk because they're uncontroversial, carry little risk, and can be done in a single checkin.

   That latter is important, because we want trunk to build and run correctly after every checkin, if only so that we can do fossil bisect operations with near-zero risk of running into a build we can't mark "good" or "bad" because we can't even get it to build.

   We can call these "atomic commits."

2. Commits which go on a public feature branch. Take my libbind-ns-alternative branch as an example. What it's trying to accomplish isn't controversial, but I knew I couldn't do it in a single checkin, so I created a branch for it instead of making my changes directly on trunk. I kept the branch open yesterday instead of merging it to trunk, even though I thought it was mostly done, because I knew Release 2.7 was coming soon, so I didn't want to merge the branch down knowing it wouldn't have time to be properly tested before the release was tagged. Also, I still hold hope that the branch will cover more platforms before being merged.

   The hamburger menu branch is another good example: it stayed open for most of a week with about a dozen checkins, during which time it received a fair bit of community testing. Only once drh was happy with the result did it get merged to trunk.

   We can call these "experimental commits."

The difference with private branches is that no one else can see what you're up to, it's difficult to sync changes across testing machines, and the result drops onto trunk as if you'd written it in a single large commit. If a feature is complicated enough to require a branch, it's probably also complicated enough to deserve some other eyes on it before it hits trunk.

make sure I won't commit anything unrelated

Between fossil diff and fossil extra, you should have a very clear understanding of what differs between your local checkout and the version on fossil-scm.org.

phantom dependencies

That's another good reason for using public branches: so you can check the branch out on another platform and build there before merging the branch to trunk.

(Somewhat OT but I’ve seen at least you and drh ask this question more than once…do the folks with commit access not have a google doc or something containing a list of approved contributors? Might be a better system than just asking the people submitting the patches, just saying!)

Hi,

I'm sure drh has a list of contributors. If not, he can see how many user accounts there are on the fossil repo and likely figure out who here also has a commit account. I don't think Warren has access to that part of the Fossil repo.

a list of approved contributors

Actually, such a thing does exist, and you're right, I should have checked it before asking, that being faster than asking and waiting for the answer. The list is on the repo's /reports page, which gives a list of those who have made commits to the repo. Anyone with "Read" permission can see this, not just those of us with commit bits.

You can get false negatives by looking at this list, since you might not be able to correctly guess the user's repo login name, but if you do find a plausible match, the question need not be asked. I will try to remember to look first in the future.

This list doesn't include those who have logins but have never exercised their granted powers, of course.

Just to clarify…by “approved contributors” I meant people who have a signed contributor agreement on file, which I thought was a superset of those with commit access.

According to this a person needs to have signed that piece of paper and have a history of quality patch submissions (which would obviously have to be committed by others) before they would ever get commit bits. Looking at the /reports page would not include people in that in-between stage. And that is the group I thought you were asking if Florian was in. But perhaps in practice people don’t stay in that stage for very long?

Sorry for the diversion!

Brilliant work. Thank you!

I got the email notifications of your check-ins yesterday, but I have not looked at the code yet. I agree that the /sitemap needs improvement. But your have established a good foundation for doing that.

I have not looked at the code yet.

Despite my griping about the coding inefficiency of the DOM API and XHR vs jQuery, the diff is pretty compact.

your have established a good foundation for doing that.

So, do you intend to merge it and take over?

I'm quite willing to hand it over to you, but if more is needed before you can do that, let me know.

I'd like to see this merged at some point, yes. But right this moment I'm busy with SQLite work. Please feel free to continue refining your idea, including making enhancements to the /sitemap page if you like, and I will try to review the changes and merge them when I get a chance.

Slightly off topic:

When I picked up my phone to browse to the the MySQL++ site link to try it out, I also noticed that deeply nested forum pages such as this one do not display well on narrow screens. Suggestions on how to improve that situation are welcomed. :-)

deeply nested forum pages such as this one do not display well on narrow screens

Fall back to a chronological flat view.

There are a bunch of ways to do that:

1. You could pass a query parameter ?flat=1 to tell the remote Fossil instance to return the posts in flat chrono order. That can be a choice at the top of the /forumpost page and held in the cookie as a default. The tricky bit is how to set that value properly on the first page load. Maybe some JS code in the footer checks the window width and sets the value if it hasn't been manually set and reloads the page. It'd be better to do this out at the /forum level.

2. You might be able to back the threading out with pure CSS, but that'll leave the posts in the wrong order. Notice that in this thread, the most recent posts are about in the middle of the page, as currently rendered.

3. You can do it purely in JS so the server doesn't have to be involved at all, but I think you'd have to move to an Ajax thread pull model so you can reorder the post blocks in the DOM before rendering it to the page. That then pushes you towards a SPA model in order to avoid double synchronous HTTP hits on each forum page load.

Implicit in all of the above is that each post then have a way to indicate "In reply to" since in flat mode, posts will not necessarily immediately follow their parent.

Last week-end I browsed the Fossil forum itself on my iPhone SE, i.e. a narrow-screen phone, and indeed it was rather horrible, with wrapping every 3 letters, completely on the right-hand-side, "outside the box" rendering, "offscreen" rendering requiring horizontal scrolling, etc...

Needless to say, I stopped doing it rather quickly, and moved to GMail to read the email notifications instead.

Post-indenting on a phone just doesn't work IMHO. FWIW. --DD

Yes, I'm experiencing that now as well.

With the recent commits of hamburger stuff, none of the links or working because of the honeypot thing. I'm sure it's a work in progress, so I'm just reporting what I've noticed.

Edit

It looks like the links are working. Maybe I had old cache.

I understand you point, but disagree your two columns layout.

The « problem » here is the automagically repartition of the links over three columns, thanks to CSS.

I like the three columns layout for wide screen as I found it more readable than two long columns.

My proposal would be to keep the three columns layout for wide screen and two or one column for little screen, and fix the links in their columns.

With a schema it would give us:

Wide screen:

| col A | | col B | | col C |
|       | |       | |       |
|       | |       | |       |
|       | |       | |       |

Less wide:


| col A | | col B |
|       | |       |
|       | |       |
|       | |       |

| col C |
|       |
|       |
|       |

Tiny/mobile screens:

| col A |
|       |
|       |
|       |

| col B |
|       |
|       |
|       |

| col C |
|       |
|       |
|       |

And with the real links, I would purpose the following repartition:

o Search                              o Branches                               o Login
o Home Page                             o Tags                                   o Subscribe to Email Alerts
  o Documentation                       o Leaf Check-ins                       o Help
  o Download                          o Tickets                                  o Wiki Formatting Rules
  o License                             o Ticket Search                          o Markdown Formatting Rules
  o Documentation Search                o Recent activity                        o List of All Commands and Web Pages
o File Browser                          o List of attachments                    o All "help" text on a single page
  o Tree-view, Trunk Check-in         o Wiki                                     o Filename suffix to mimetype map
  o Flat-view                           o Wiki Search                          o Test Pages
  o File ages for Trunk                 o List of Wiki pages                     o Wiki Sandbox
  o Unversioned Files                   o Recent activity                        o CGI Environment Test
o Project Timeline                      o List of Attachments                    o List of file renames
  o Activity Reports                  o Repository Status                        o Page to experiment with the automatic  
  o File name changes                   o Collisions on hash prefixes              colors assigned to branch names
  o Forks                               o List of Artifacts                      o Random ASCII-art Captcha image
  o First 10 check-ins                  o List of "Timewarp" Check-ins

In the above example, you can see that I take the liberty to move the Wiki sandbox page to the last column, in the « Test Pages » section. This makes the columns to have the same height and is a bit more understandable IMHO. I move « Search » in the first position too as it is the best way to begin with, when you are lost.

What do you think of it?

That's also a possibility.

Our visual fields and our brain's working memory capacities impose limits on the viewport we can efficiently overlook, and I believe that's why common paper sizes are relatively small ("A4", or "Letter", even smaller for most books).

Due to the widths of my browser windows, my view often toggles between 2 and 3 columns. My argument to set a limit of 2 columns was to reduce the likelihood of changing column count with only small variations of the browser window width.

But maybe, in the end, it's also a question of personal preference.

I just noticed there's check-in to restrict column breaks to whole blocks of links, and ensure columns always start with a heading-level link. That's a really great enhancement, (my) visual orientation has significantly improved by this.

My other points (vertical spacing of blocks of links, left-aligned instead of evenly-distributed columns) only seem minor in comparison, and might not add the same relative benefit as the current change.

Thank you very much for listening to us, and for all your appreciated work.