How can long category pages be split into multiple pages?

Question

I'm seeing the following message on a category page I initiated:

WARNING: This page is 51 kilobytes long; some browsers may have problems editing pages approaching or longer than 32kb. Please consider breaking the page into smaller sections.

How should very long narratives (with in-line links to profiles, space pages and sub-category pages) be split into additional pages?

I've considered simply creating sequentially named category pages with links to the next and previous page. That would work were it not for the fact that there are a host of profiles, space pages and sub-categories that would thereby contain corrupted links to the initial (single page) category page.

Note: Notwithstanding browser issues, the utility of the category page would benefit by being divided into sub-pages.

Answer 1

There was discussion on this, and it is better if a category page is brief in content- projects related, general information on what goes there, who to contact if you need help using it- and the bulk of any other information and detail should be on a space page, which can then be linked to on the category page, as well as categorized there. Needing to scroll through a lot of information to reach the categorized profiles is tedious and not how the category pages are meant to function.

Comments

This is for me a webdesign question. If some sections should not be shown you hide them by default ==> no scrolling. If someone is interested in a sectio they click show

Solution: Add a template with the function show / hide of a section

Antipattern is to split a page to more pages....  
 

Answer 2

There has been some discussion about information on category pages. Does copious information belong on a category page at all? I also don't think anything was decided (but I could be wrong).

I think however in this case, you have too much information on your category page. Consider moving the bulk of the information to one or more free space pages, that can be linked to the category page. You can nest/link pages within pages so that you only have one main page.

As an example Category: New Haven Colony links to the space page New Haven Colony that has the pertinent information

Answer 3

Yes trying to improve category structure hits this problem every time. Having to edit numerous profiles to make it work can be daunting. But it isn't just a question of length but of duplication and logic.

As regards narratives, I believe they should be short and address obvious issues. After that a few links are all that is needed. I see no great benefit in trying to make category pages look beautiful.

Answer 4

I would propose that the general principle for content on category pages would be, "Does this content help the person who is trying to find a particular category or profile, or does it help the person who is trying to find a place to put a particular category or profile?"  

In other words, the principle would be to focus on function rather than length.  However, I have seen on a lot of category pages material which is very interesting, informative and useful, but doesn't really address the two questions above. (And before I'd given it this kind of thought, I've created some myself.)  I think putting that content on a free-space profile linked to the category would measurably increase the functionality of the category page without sacrificing much, or even any, of the hard work that went into creating the content.  It would still be there and readily available, it would just not be in the way.

On the other hand, there are numerous category pages containing nothing by way of explanation, which leaves those two questions unanswered.

As a member of the categorization project, I think I could say categorically (did I just do an oxymoron?) that one should NEVER create two category pages which have the same purpose, i.e. Category:  Anne Arundel County I and Category:  Anne Arundel County II, simply because one wants to split up the content -- it would create great confusion as to which duplicate category one should attach subcategories and profiles to.

Comments

Agree 200% that we move the discussions from technical aspects to looking at user requirements....

I started as I always do writing User Stories for the Swedish Parish project....

• User stories SPC project
• Templates created to fulfill those user stories 

For me categorization is a way of 

1. Grouping people in WIkiTree
2. But also add context to a profile (Listen to Future Learn about adding context when doing genealogy)

A category that is used to add context to a WikiTree profile will link other sources of interest to this category. This could be part of something called open linked data = that we point on other sources on internet that also is about this subject see a good video about open linked data 

 

I have started to link WikiTree profiles to other profiles on internet see G2G about how Rubens-1 is linked to Wikidata Q5599 that links to Wikipedia,  The Getty museum, all uploaded pictures and also to the artworks of Rubens and the locations of them see map..

Video of how you WikiTree is linked to WikiData and you can send the coordinates of Rubens painting to your phone 

WikiTree Categories are also good candidates to also be part of Open Linked Data....  as I feel we would like to learn more about the categories in the same way we learn more about people and link them to WikiData P2949

---

The size argument is that not just bad web design?

On a Category page we have at least 2 functions

1. Group people who has something in common with a category
    
2. Add context about a category

People focused in 1 gets irritated when 2 take space ==> suggested solution hide 2.....and let people expand when they would like to see it.... using solutions with a special free space page is in my opinion not working we have done that at Swedish Parish pages and it looks like no people go there.....

1 How to add show/hide

1-1 using TOC

In standard WIkiTree TOC we have if its a long TOC

Profile Jonasdotter-344

Can't we just do the same for categories that are long that we minimize sections

 

My understanding of show/hide TOC

1. Javascript function showTocToggle
   is in file
   http://www.wikitree.com/skins/common/wikibits.js
   1. This Javascript functions look for
      <div id="toctitle">
   2. Then adds Show Hide code
2. The function ShowTocToggle is run on the profile with the following lines big pic

Why not get the same for Categories?!?!? Must be 2 more line of code...

By adding a div tag you activate hide on a category (see G2G about adding div tag

Cookies session

The nice thing with this solution is that if a section should be shown is stored in a cookie ==> if you select to hide the section then all categories you visit during that session will have hide as default because of this cookie

Bic pic

1-2 using div scroll

By adding this <div STYLE="outline:black solid thin; height: 600px; overflow-y: scroll;background:ivory;padding-right:10px;min-width:500px"> 

and end with </div> we get a max height of the text and scroll inside...
 

I tested it on Category Rättvik (W) and its used on Nassau_Dillenburg-7

---

Magnus, categories weren't developed to provide context - the profiles, projects and free-space pages linked to them were developed to do that. That's why those pages have features that categories don't have. 

Also, you are suggesting the use of HTML tags and inline CSS which are not recommended.  Have you read Should project and category pages adhere to style guidelines? where Chris Whitten says:

My inclination is that CSS and HTML should avoided on categories and top-level project pages. It should be removed when we see it. Advanced styling is troublesome for all the reasons discussed here. If it's allowed on categories and high-level projects, people will assume that it's OK or even proper. Then it will end up on lots of categories and project pages.

---

Re Maryanne should we have the same discussion again ;-)

if Css and html is the problem then we "hide" it in a template. The challenge is to get something that is good for the end user.... 

We have already a template on 400+ pages so we can hopefully change all 400 pages just by adding 2 lines in a template. Problem is to find a solution ==> then no CSS or HTML or hard coded tables will be shown on the category page just parameters to a template.....

If the solution is jump away from the category to another Free space page then it's the same we just add a parameter in the template that creates a link to a Free Space page....

Doing Webdesign  since 1995 I hope we get some action from Chris that we either can 

1. Create templates with hide/expand ==> need a Javascript on the server
2. That he does a Category version of the ToogleTOC javascript that exists see above 
   
   The above div scroll solution I feel is not sexy.... but maybe is a solution..... and seems that it's ok to use..... ;-)
    
3. Or we start having empty category pages (done fast by deleting content in Templates... see silent Template:WikiReasonator

 

---

Magnus, use of css and html get to the functionality of the programming of WikiTree, and is way beyond things I understand.  I think that gets to issues that Chris Whitten and IT experts would have to address.

---

@Jack 

step one: Do we agree that hide/show will solve the problem from an end user perspective?  

---

OK, so you're going back to the original question on content placed on a category which is deemed to be too long.  And you are suggesting a possible solution with one or more "hide/show" buttons.  One alternative might be to hide or show all the content.  A second alternative might be, if the content has a Table of Contents, that only the Table of Contents would show on the category page and all else would be hidden unless one clicked on the Table of Contents heading, which would then show it.  The default position would be that one would see no content (hidden) and scroll directly down to the Subcategories and Profiles.  Is that what I'm hearing?

---

Jack, the original question is about pages that contain so much text that some browsers may have problems editing it. 

Here's the reason for that size limit (from Wikipedia): "Total article size should be kept reasonably low, because many users edit from low-speed connections including dial-up connections, smartphones, and low-end broadband connections. The text on a 32 kB page takes about five seconds to load for editing on a dial-up connection, with accompanying images taking additional time, so pages significantly larger than this are difficult for older browsers to display."

Having an option to hide/display the text won't remove the issue because the text is still on the page. The solution to the issue is to remove some of the data.

---

@Jack
If we listen to Maryann you will hear solution A below I guess
If you listen to me I was a E person but feels that it's more party over at WikiData and I care less... I feel the WikiTree discussion lack some user focus and that we don't use tools like Templates when linking is just asking for problems.... 

So we are still at square one. Below the category discussions I have seen too many times and we never get a solution that helps the end user  ;-)

a) should we have empty categories see G2G and G2G
or

b) should we just have a small link to a Free space page

c) should we have an infobox telling what project is responsible for an category and how to contact someone in the project 

d) Can we have infoboxes and illustrations and hatnotes that help the end user understand the category or get more info 

If we say it's ok to have context then people working with categories sometimes complain that the text is to long ==>

e-1) Is it ok with long text if it's minimized?

e-2) Is it ok with long text if it's minimized and just the TOC is shown?

My point of view
The problem with WikiTree is that its based on Wikimedia version 1.11 and that version was released back in 2007 when the concept of linking data was not mature.


Mobile phone 2008

Wikipedia has now moved in direction open linked data and created WikiData and we have a few profiles that are part of it ==> you get a much more mature data model and query engine using SPARQL ==> its no problem to generate a report of all people part of Noble houses that are Royal houses  or just show the people in the report with a WikiTree profile or the people with a FindAGrave profile or people born in Germany...

The future is linked open data and Wiki categories was a version 1 of that vision created 2004 (help page 2004).... is my simple understanding. 

• Linked Open Data - What is it?
• RDF Beginners Guide
• Wikipedia

New Category report by Aleš
Have a look on the new report about using categories. It gives a feeling how different we use Categories. Maybe that is why we never will agree and some feels it's a way of adding context to profiles and other just it should be empty....

• Sälgö-1 
• Day-1904
• Thompson-14289
• Whitten-1

 

---

Reality check WikiTree is based on a version created 2008

"The text on a 32 kB page takes about five seconds to load for editing"

Today 2016 I have 100 Mbit/s ==> 32 kB takes 0,00256 second to transfer ==> its 2000 times faster today

((32 000*8)/100 000 000)

On my phone a bad day I have 15 Mbit/s ==> 32 kb takes 0.017 sec ==> 300 times faster than the dial up modems of 2008....

My guess this is just another text that should be deleted at least the argument that it's a technical issue see <hr> use sparingly Discussion in G2G that was a problem in 2008

A size problem WikiTree has is Longest profiles as most of them are just garbage

1. (hist) ‎Upton-558 ‎[1,678,400 bytes] = 52 times bigger than 32 kB
2. (hist) ‎Levine-623 ‎[867,979 bytes]
3. (hist) ‎Adelstein-23 ‎[842,600 bytes]
4. (hist) ‎Adelstein-21 ‎[826,832 bytes]
5. (hist) ‎Gerber-1173 ‎[811,415 bytes]
6. (hist) ‎Hereford-120 ‎[799,219 bytes]
7. (hist) ‎Warner-4725 ‎[798,975 bytes]
8. (hist) ‎Cohen-2938 ‎[787,859 bytes]
9. (hist) ‎Garbarski-1 ‎[775,266 bytes]
10. (hist) ‎Levine-617 ‎[760,131 bytes]