Shortening long list pages with Tables

[Mathew322]

So the other day I took it upon myself to create the pages for the seven PvP accolade powers because they didn't exist before and I couldn't help but notice afterwards that the Temporary Powers page and other similar long-list pages are quite long.

 

Below I've used tables to demonstrate a way they could be shortened and wanted to see what other people thought about it.

[AboveTheChemist]

I am mostly ambivalent, leaning slightly toward disliking the idea. I find the table examples to be a bit smashed together and harder to read than the lists as they exist now.

[Mathew322]

I think if being squished is a concern, vertical and horizontal are going to have the same issue, though the advantage of horizontal would be that it would be harder to press the wrong link on mobile.

[BlackSpectre]

As long as the page is searchable using CNTRL+F anything’s fine I think. For a wiki, utility and easy access to the desired data is the most important thing… at least in my eyes. I’ve noticed that sometimes making sub pages or even collapsing lists can make the data invisible to a simple text search. I’d have to test it at this wiki to be sure. 
 

Collapsible tables are not my favorite thing for a wiki, BTW.  It makes finding the data I seek much harder by forcing me to click on the collapsible tables to see what’s there. On the other hand, having a collapsible table be open when the page is first viewed is great as it gives readers the ability to reduce the amount of text by collapsing a table or two if they choose.
 

Table of Contents allow for categorization, and quick access,  while still keeping the long lists.  As long as you know what you’re looking for that is. 

[Mathew322]

Well these are just basic tables, not the collapsible kind, so searching with shortcuts should work perfectly fine as any standard wiki layout.

[Kai Moon]

Tables for non-tabular content is bad for accessibility, mobile experience, performance, and SEO.

 

Inline-blocks would give a similar appearance and be fine.

 

I'd go with {{columns}}, though.

[Mathew322]

On 2/1/2024 at 10:25 PM, Kai Moon said:

Tables for non-tabular content is bad for accessibility, mobile experience, performance, and SEO.

 

Inline-blocks would give a similar appearance and be fine.

 

I'd go with {{columns}}, though.

Well now that is an exceptional suggestion indeed! Columns solve all the same issues Tables would but with a lot simpler coding!

[Dacy]

Okay, question for ...well, anyone who cares to weigh in. We're wanting to update the base information wiki with the new, updated and corrected information, which is quite a bit larger in scope than the information currently listed. Now, the listing of bases is currently separated into tables of different categories of bases, as well as by shard.  What we would like and need to know before we can progress to actually importing data, is answers to the following:

1. Everlasting base directory alone currently is 400+bases in total. Would that many bases need separation by category? Or could they be all in one table and just sortable/searchable?
2. Even if they could all be in one table, would that be the best way to present the information?
3. If they need to be separated into categories, what's a good size of a pool of entries to aim for? We have many categories (to help people with specific searches), likely too many to make effective tables for each, but we could combine categories into more generally applicable, with searchable or sortable options to fine tune a search.

Referencing the above snippet on columns, I don't know if that is applicable for something such as this information, where all of the information on a row relates back to the first column in that row, and sorting changes how the rows are organized?

 

We'd like to get the information transferred, we just need help with what sort of formatting would be best. Thanks!

 

 

[AboveTheChemist]

Just some general thoughts, but a good starting point might be just to do everything in one table and see how it looks and how it sorts. If it looks like too much info, or if the sorting doesn't look right, then count up the number of base categories to see how many potential separate tables there might be. Assuming you decide to separate them, maybe 4 or 5 separate tables would seem to make sense, if you could consolidate your categories to match that number. That's just ballpark, of course.

 

I mentioned in the other thread but I've completed my mod updates and have some time to devote to this project now, finally!

 

Edited March 7 by AboveTheChemist
typo