Show if collapsed field has any content

Ideas & Features
1

I’ve created this feature request after the recent release of collapsible fields.

I’d love if I could get a count or an indicator that a (collapsed) field has content, so it’s obvious at a glance. Otherwise, if we have collapsed a field, we have to expand it to check if there is any content.

The solution we have with comments for example, makes it so we don’t have to expand it to know if there is any content. We can see directly “No comments”, if there are no comments.

For example, we can now have our rich text field “Notes for editors” on wiki pages, and we can just keep them collapsed, since they are only relevant in some cases, when making edits, and most of the time, you are reading.

And a few (only) articles could have files or whiteboards attached, though as a reader it would be nice to have that field collapsed most of the time, since it’s so uncommon.

image
image1305×920 57.7 KB

1 Like
2

There is a tradeoff between convenience and performance here: when a Field is collapsed, we don’t query any data at all. To show an indicator if a Field is empty or not, we have to send an extra request — in the case of a rich-text Field, it would be a request to a separate /docs service.

Comments and back-references are special cases: both Fields are hidden when empty (Comments for read-only users only) so we have to query at least the aggregate data anyway.

So far we have decided to prioritize performance for all other Fields but we’ll keep an eye on the feedback.

1 Like
3

That make sense, I suspected it might be a performance tradeoff.

1 Like
4

This is a UX tension that needs to be resolved. I would recommend one of the two following approaches:

1. Making Empty Fields Semi-Transparent

Fields without content are displayed with reduced opacity, indicating their empty status. Additionally, empty fields could be made smaller to reduce clutter.

Rationale:

  • Declutter Interface: Helps in reducing the clutter, especially if an entity type displays many fields.
  • Visual Consistency: Maintains a uniform look by showing all fields, filled or empty.

Performance

  1. Backend Check: Just like the badge approach (see below), the system would fetch a simple boolean value (has content/doesn’t have content) or a count (e.g., number of items in a list field). This minimizes data retrieval compared to fetching the entire content of a field.
  2. Frontend Rendering: Instead of displaying a badge based on the backend check, the system would adjust the CSS properties of the field. For instance:
  • If the boolean value indicates content is present, the field remains fully opaque.
  • If the boolean value indicates the field is empty, the CSS would render the field as semi-transparent.

2. Content Indicator Badge

The Content Indicator Badge displays a visual cue next to a collapsed field to signify the presence of content without having to expand it. This can be an icon or a simple “!”.

Rationale:

  1. Balanced Approach: This method strikes a balance between user experience and performance. Users get immediate feedback on whether a collapsed field has content without having to fetch the entire content.
  2. Minimal Performance Impact: Fetching a simple count or a boolean value (has content/doesn’t have content) is typically less data-intensive than loading the full content of the field. This means quicker load times and less strain on the server.
  3. Universal Application: Unlike hover previews, which are not suitable for mobile devices, a content indicator badge works across all device types.
  4. Intuitive: A badge, especially if designed with familiar visual cues (like a “!” or a number), is easily understood by users without requiring additional explanation.

Implementation Considerations:

  1. Optimized Backend Queries: To minimize the performance impact, the backend should be optimized to fetch only the necessary data for the badge (e.g., a count or a boolean value).
  2. Caching: If feasible, implementing a caching mechanism can further reduce the need for repeated queries, especially for frequently accessed fields.

Here are some other approaches:

3. Lazy Loading Loads content only upon user interaction.

  • Benefits: Fast initial page load.
  • Drawbacks: Delay when expanding.

4. Background Fetching Loads data in the background after the main content.

  • Benefits: Seamless user experience.
  • Drawbacks: Additional bandwidth and processing.

5. User Preference Settings Allows users to choose if they want indicators.

  • Benefits: User flexibility.
  • Drawbacks: Added complexity in settings.

6. Hover Preview Shows content preview on hover.

  • Benefits: Immediate feedback.
  • Drawbacks: Not mobile-friendly.

7. Caching Mechanism Stores data for frequently accessed fields.

  • Benefits: Faster access.
  • Drawbacks: Risk of outdated information.

8. Optimized Queries Refines backend queries for efficiency.

  • Benefits: Faster than full content fetch.
  • Drawbacks: Possible slight delay.
5

Related: