codidact
Add a user preference for size of post previews
This feature request arises out of the discussion on https://meta.codidact.com/posts/287456 .
Post lists show a preview, the first N characters of the body. A site setting, PostBodyListTruncateLength, controls the number of characters, which applies for all post lists on the community (all categories, user profiles, search results). This request is to support per-user configuration too, which would override the site setting.
The requests we've seen so far are almost all about the category list. It seems plausible that even people who don't want to see previews at all on category lists might still want to see them in search results, and user profiles are probably somewhere in the middle. I'm not sure what the best way to handle this is:
- We could add a setting and apply it to category lists only.
- We could add a setting and apply it everywhere (or everywhere except search).
- We could add a setting for the length and a setting for where to apply it (multi-selector).
- I don't think we want the UI complexity of different lengths for different contexts ("category:0, profile:100, search:500", that sort of thing), but I include it for completeness.
How should we address this?
It may be worth considering this in parallel with "Posts with math are very, very tall in the feed".
That relates to MathJax formulas making the preview very tall even with few characters. Other types of tall post (such as code blocks or just very short paragraphs that start a new line after only a few words) will probably be condensed into a single line in the preview. For example, a question with an initial paragraph of only 5 words has the next paragraph on the same line in the preview.
However, this still leaves several sites that have MathJax activated and will see very tall previews. So it may be worth considering a height limit in addition to (or instead of) a character limit.
Personally, I'd rather be able to set a limit of "2 lines of text" for my previews, than try to work out how many characters I should choose to give me approximately 2 lines (and even then some previews would end up spilling over onto 3 lines because they have more ms and ws and the preview is in a variable width font.
A limit on lines of text would also mean that I could view on different width screens (mobile and desktop) and still see the same number of lines (rather than having to set a number of characters, and setting 100 characters to give 1 line on desktop, but then finding that same 100 characters gives 4 lines on mobile).
Other people might prefer to have a fixed number of characters, and be happy with more lines on mobile, so maybe having both options (line limit and character limit) would be best. Alternatively there could be only a line limit, but a separate desktop line limit and mobile line limit.
Those are good points. I have no idea how hard any of that is, but yes, the underlying concern motivating the requests is about screen real-estate, so can we specify that?
I'd expect either way to be easy.
- The current way (restricting the number of characters) should be around a 1 line change to go from restricting to a fixed number of characters to restricting to a user input number of characters.
- Restricting to a user input height should also be around a 1 line change, but a change to Co-Design instead of QPixel (as the height will be restricted by the browser on the client side rather than the text being truncated server side).
In either case the difficult part would be setting up the interface for the user to input their desired setting - actually applying that restriction should be a 1 line change.
That's assuming that QPixel can pick up user settings (which I assume it can but I haven't checked - worst case we'd have to put something in the HTML for it to read the user setting from).
Note that the 1 line change to restrict the height would result in the full text of the question being sent, but only the required number of lines being displayed. This is inefficient and inconsiderate to the user's data allowance, so ideally we'd add another 1 line change to truncate the text to however much is needed on the widest screen (so it would then be sufficient on any screen width). This is still a very small change though.
The server does not directly store user preferences in the database, though you could try get them from Redis. The client side javascript has an endpoint to fetch it from the server which then gets it from redis, so the method is somewhere.
I think the question is more how much control we want to give users over the display. Perhaps it is also better to predefine some templates rather than force them to set numbers directly.
How about full blown themes? I once looked into some options but concluded it makes the html pages quite complex and have duplicate components.
What if we add a user preference for where to show previews, but don't let users override the size of the preview? I'm thinking of options like:
- Never (never show previews anywhere)
- Limited (show previews in search results only)
- Most (show previews in search, user profiles, and tag lists, but not in category lists)
- Always (show previews everywhere we do now)
My impression is that the pushback on previews (particularly where Mathjax is involved) is because people want to be able to scan the question list more easily. Having a preview in search results, on the other hand, seems actively helpful (and what people are used to from search engines). Other cases -- profiles and tags -- seem to my mind to fall between those two cases.
I've just raised https://meta.codidact.com/posts/288103 to make search result previews more useful. They seem like a fundamentally different thing than post previews in category lists, so perhaps we could keep this current issue simple by excluding search from the change?
If we wanted to keep this change minimal to get feedback before judging if there is demand for more, we could just have a single checkbox for whether to show previews. This could affect post lists in user profiles, tag lists, and category lists (all on or all off).