Consider a better UX for the listings

[r-lyeh]

It might be better if it were all one list but the exceptions were tagged in some way, because it's kind of a UX nightmare to have to check multiple lists (most people probably won't realize they should, and therefore won't), but maybe it's difficult to come up with a "UI" for displaying that cleanly.

Originally posted by @nothings in #213

[r-lyeh]

Also looking for a more compact layout for each entry, so there is extra room for the description text:

Original:

tag	library	license	API	files	description
image	stb_image	PD	C	1	Image loading/decoding from file/memory: JPG, PNG, TGA, BMP, PSD, GIF, HDR, PIC

Proposal:

tag	library	description
image	stb_image (1 C, PD)	Image loading/decoding from file/memory: JPG, PNG, TGA, BMP, PSD, GIF, HDR, PIC

[mateusmoutinho]

I think it should include more informations,like these:
where on C/C++ you can say if a lib compiles native in C++ or if it runs by AR or Linkage.

Releases

tag	library	license	Plataforms	Cpp	C	files	description
file	DTW	MIT	-Linux -Windows	-Run By AR -Run by Linkag	Compile Native	doTheWorld.h	lib to work with files and dirs

[r-lyeh]

The younger version of me was geared towards efficency and complexity as I was told to do everywhere else. When I peaked complexity I suddenly started to appretiate the beauty of simplicity and minimalism, which are the correct way to nirvana dev. I've gone that road since then. and not going to look back ever again. That's why I advocate for C again after writing C++ for more than a decade; but that's another story.

tl-dr; I'll make the list shorter and shorter. In fact, here we have a 2-columns layout I just figured out:

library	description
Image: stb_image (1 C, PD)	Image loading/decoding from file/memory: JPG, PNG, TGA, BMP, PSD, GIF, HDR, PIC

[r-lyeh]

It might be better if it were all one list but the exceptions were tagged in some way, because it's kind of a UX nightmare to have to check multiple lists (most people probably won't realize they should, and therefore won't), but maybe it's difficult to come up with a "UI" for displaying that cleanly.

Originally posted by @nothings in #213

Also have an idea for this issue. Will merge first+second listings together; entries from first listing ( 1+C+PD ones) will have description in strong bold, whereas the others (either 2, C++ or MIT/BSD) will not be highlighted. Then the current tertiary list, which is small, will become a secondary minor appendix to the big main list.

[r-lyeh]

Also, another idea: just 2-columns with a <br/> separator as follows:

[nothings]

In my opinion, that's worse. The two-column format allows you to scan down one column and read just that column ignoring the other more easily. That makes it faster/easier to scan for things you're looking for. Putting them on alternating lines makes the eye travel over both when it's trying to only read one or the other.

My expectation is that skimming over the "what it does" column looking for either something specific (or just looking in general to get a sense of options) is the most common use case.

[r-lyeh]

Hey, we can talk about it, np. I understand the concerns but also i'd like to add that going two-columns fits much better in lower resolution scenarios like mine (1366 px with 150% dpi scaling); otherwise the descriptions may take a few lines long and the "vertical" aspect of it is even worse than what you showcased.

We can still find even a better way all together. The changes are minimal and revertible (ie, replacing | with <br/> and viceversa) in any case :D

[r-lyeh]

suggestion from @zpl-zak in Discord group:
consider also using GH Pages in addition to the readme view, so listing can be rendered at 100% content width (via css styling) without all the GH cluttering.

[nothings]

Well, my personal experience is that scrolling more often doesn't seem particularly slower to me with a scrollwheel, regardless of scale, whereas removing the table split definitely makes me slightly slower to locate and read. But, I mean, that's just me personally.

Maybe it could be a page with JS to allow you to configure the formatting to user-preference, or based on page metrics.

[r-lyeh]

Also a note to future me: Using markdeep + .md would render everything nicely without too much trouble. Done that before.
PS: markdeep is awesome!

[r-lyeh]

Meanwhile GH webpage materializes (if ever) thought about another variant, <br/> between category and link this time as follows:

library	description
hash XxHash (2 C, BSD)	Fast hash function
image Bitmap (1 C++, MIT)	Bitmap decoder and utilities
Image stb_image (1 C, PD)	Image loading/decoding from file/memory: JPG, PNG, TGA, BMP, PSD, GIF, HDR, PIC

[nothings]

You could also split the table into multiple tables, one for each 'category', and not have to include the category in the table at all. I didn't do this because it caused the table column horizontal positions to jump around as you scrolled to each new table, but if there's a way to make them consistent, that will pack things down quite a bit compared to above.

[r-lyeh]

Added a small, fixed-width, invisible image under the first column header to pre-allocate a minimum width. See both tables below. (it renders ok on Chrome at least):

3d libraries	Description
Stb_voxel_render (1 C, PD)	Minecraft-esque voxel rendering "engine" with many more features

Image libraries	Description
Stb_image (1 C, PD)	Image loading/decoding from file/memory: JPG, PNG, TGA, BMP, PSD, GIF, HDR, PIC

[r-lyeh]

Update: trick above does not render right on Chrome mobile. I'll think about it.