Issue 17232 - make std.algorithm table more digestable

[wilzbach]

This isn't a complete fix of 17232, but it's a simple step to improve the current status and it also looks nicer on the Desktop as I think it's quite obvious to the reader that he's looking at std.algorithm (title, left sidebar, url, ...)

Before:

After:

[dlang-bot]

Fix	Bugzilla	Description
✗	17232	The index page for std.algorithm looks bad on mobile

[wilzbach]

Btw it would also make sense to me to drop the capital letter and use the actual module name instead of its "verbose" description

[quickfur]

I like the idea.

Though the fundamental problem remains: a giant mass of links isn't very easy to navigate. I wish there was some way of columnizing the links automatically, as a grid of links would be slightly easier to read, but AFAIK HTML/CSS doesn't have such a feature just yet.

[quickfur]

P.S. "Set operations" doesn't immediately translate to setops (though in retrospect it does), so maybe include the module name underneath the verbose description? Not sure if it would look redundant, though, since it would be mostly a repetition for the other submodules.

[wilzbach]

I wish there was some way of columnizing the links automatically, as a grid of links would be slightly easier to read, but AFAIK HTML/CSS doesn't have such a feature just yet.

There's Flexbox

P.S. "Set operations" doesn't immediately translate to setops (though in retrospect it does), so maybe include the module name underneath the verbose description? Not sure if it would look redundant, though, since it would be mostly a repetition for the other submodules.

Yep I know and I came to the conclusion that probably going with setops is the lesser evil than being redundant for all the other modules. A way in-between would be to do sth. like "Set operations (setopts)" for this module only.

[quickfur]

Excellent idea (add (setops) just for that submodule).

[wilzbach]

Excellent idea (add (setops) just for that submodule).

1. Same line

2. Line break:

I went with (2)

[jacob-carlborg]

The problem is that the design doesn't take mobile devices into consideration at all. A table like design doesn't work well on a mobile device because it's not wide enough. What about just a list instead:

Searching

• all
• any
• balancedParens

Comparison

• among
• castSwitch

Of course It doesn't need be a bullet point list and the headers (categories) could be expandable as well.

[wilzbach]

The problem is that the design doesn't take mobile devices into consideration at all. A table like design doesn't work well on a mobile device because it's not wide enough. What about just a list instead:

This won't look well on Desktop devices. I think we are all aware that the CHEATSHEETs needs a better support for mobile devices, but this will take much more work and should be done for all CHEATSHEETs. A good solution could be sth. like this: https://css-tricks.com/accessible-simple-responsive-tables/

As mentioned on the top this was intended as an quick, intermediate solution and as an added benefit makes the page look much better on Desktop devices.

@quickfur or @JackStouffer: could one of you approve, s.t. we can ship this for the time being? Thanks!

[jacob-carlborg]

This won't look well on Desktop devices. I think we are all aware that the CHEATSHEETs needs a better support for mobile devices, but this will take much more work and should be done for all CHEATSHEETs. A good solution could be sth. like this: https://css-tricks.com/accessible-simple-responsive-tables/

There's nothing say that we have to use lists on desktop devices. The problem is that tables don't fit very well on narrow screens. Trying to use the same type of control/widget/element on both mobile and desktop won't work in this case, in my opinion.

Take for example a native iOS application, like Preferences. Here's a print screen from an iPad, with a wide(er) screen:

It has a menu in the left side and the content on the right side. The same app on iPhone will not use the same layout, it will instead have the view that was a menu on the iPad as the first view, then tapping on an item in that view will bring you to the content view, that was the right side on iPad:

As mentioned on the top this was intended as an quick, intermediate solution and as an added benefit makes the page look much better on Desktop devices.

Fair enough.

[JackStouffer]

Auto-merge toggled on