Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Titles are truncated in Library Cards #1487

Open
Tracked by #1509
ormsbee opened this issue Nov 7, 2024 · 10 comments
Open
Tracked by #1509

Titles are truncated in Library Cards #1487

ormsbee opened this issue Nov 7, 2024 · 10 comments
Labels
bug Report of or fix for something that isn't working as intended

Comments

@ormsbee
Copy link
Contributor

ormsbee commented Nov 7, 2024

There is not enough space to display real-world titles in the cards we use for Component display. For example, in this slice of a screenshot:

Screenshot 2024-11-07 at 6 20 00 PM

Acceptance criteria:

  • Titles in Cards should wrap across multiple lines.
  • If the title is still too long to fit, we can truncate with ellipses at the last line or make the font smaller to fit.
  • Cards should remain the same dimensions they are now, and remain uniform (i.e. cards with long titles should not grow taller than other cards in their row).
  • It is okay to omit the preview text if it's necessary to make more space for the title.
@ormsbee ormsbee added the bug Report of or fix for something that isn't working as intended label Nov 7, 2024
@ormsbee
Copy link
Contributor Author

ormsbee commented Nov 7, 2024

FYI @jmakowski1123, @bradenmacdonald

@ormsbee ormsbee moved this to Backlog in Libraries Overhaul Nov 7, 2024
@ormsbee ormsbee changed the title Titles are truncated in the Card view Titles are truncated in Library Cards Nov 7, 2024
@bradenmacdonald
Copy link
Contributor

@jmakowski1123 @sdaitzman We need a UX plan for this please, and also a decision on if this should be fixed in Sumac or just for Teak.

@jmakowski1123
Copy link

jmakowski1123 commented Nov 8, 2024

I think this will require rethinking the font, sizing, bold, etc. Looking at a wall of bold text the same size of the current titles that takes up the whole tile seems like it'd be too much. Do we rethink the size of the tiles in general, to accommodate maybe two lines of title and two lines of description?

I don't see this as a blocker to Sumac, since the workaround is to click on the tile and see the full title in the sidebar. If we can get a couple of alternative designs, we can bring them into usability tests.

@ormsbee
Copy link
Contributor Author

ormsbee commented Nov 8, 2024

I don't see this as a blocker to Sumac, since the workaround is to click on the tile and see the full title in the sidebar. If we can get a couple of alternative designs, we can bring them into usability tests.

FWIW, I don't think the workaround for people who are using libraries for a lot of content will be "click on the various things that might match to get the full title" if the titles spill over the majority of the time. I think the workaround is going to be making non-descriptive-but-terse component titles like "U2-L4-HW1-P7b", which has downstream effects for people wanting to browse that content at a later time.

@ormsbee
Copy link
Contributor Author

ormsbee commented Nov 10, 2024

I think this will require rethinking the font, sizing, bold, etc. Looking at a wall of bold text the same size of the current titles that takes up the whole tile seems like it'd be too much.

I agree that it's not great. I'm proposing this text wrapping as a short-term mitigation for Sumac. The wall of bold text is not going to look good, but I think it's more usable than the truncation.

I also think that a complete title is more important than including any sort of preview description, because it's more likely to be meaningful. A lot of problems and content start with generic text, or math that we don't properly render at the moment. For instance, a problem will have a title like, "Step 2a: Deriving the Method of Moments Estimator", and the preview text is, "We use the same setup from the previous problem...". With the current truncation, that title can end up as short as, "Step 2a: Deriving...". Two lines only gets you to "Step 2a: Deriving the Method of..."

The most valuable part of the in-card preview is when it shows highlighted search terms. I wouldn't want to sacrifice the preview in those cases, but I still think showing the full title will help people narrow things down more quickly, even if it's ugly and blows the size of the card out a bit.

Do we rethink the size of the tiles in general, to accommodate maybe two lines of title and two lines of description?

I know that I've beaten this horse to death by this point, but I think that these sorts of tiled cards are fundamentally bad for this, and that we shouldn't be using them, even as an option. I believe that we should switch over to an entirely list-oriented view of cards in the Teak timeframe, with one item per row.

That would give us a few big wins. First, we'll be able to write out the full title in one line in the majority of cases. But I think it's also really nice in that it gives us the ability to accommodate outliers more gracefully. One of the issues with our grid of cards is that we have to scale up the vertical height to the maximum of any card in that row, or it just looks really weird:

Screenshot 2024-11-09 at 7 27 44 PM

In the case where we did have to wrap to two or even three lines for a title, a list view could make the card for that row a little bigger without disrupting the layout of other cards.

I know that Merlot was one of our case studies for sites that do this sort of thing, and that it offers list and tile views. I think it's worth re-examining how those views scale up to large titles on their site (I did a search for "evaporation" at the college level).

Screenshot 2024-11-09 at 7 18 33 PM

Screenshot 2024-11-09 at 7 18 41 PM

Screenshot 2024-11-09 at 7 22 57 PM

Screenshot 2024-11-09 at 7 22 49 PM

The density of display is still pretty competitive (and sometimes better) in the list view, despite the fact that the list view always shows the full title.

@ormsbee
Copy link
Contributor Author

ormsbee commented Nov 12, 2024

Another random thought: If we do the listing as a single column, we could bias the responsive layout so that thinner views are oriented towards the author who is regularly working with that content (because the context workspace on the right will take up most of their screen). Wider views of the search results could be more oriented towards people who are browsing/searching for something unfamiliar to them, and display context like how often it's been used, peer/user ratings, a full listing of tags, etc.

@kdmccormick
Copy link
Member

Not a designer, but for what it's worth, I would cast my vote to have some sort of stop-gap fix in Sumac such as Dave's word-wrapping suggestion. I mean, just look how bad the title truncation is in that first screenshot... as a library author, that would drive me crazy.

@pomegranited
Copy link
Contributor

I believe that we should switch over to an entirely list-oriented view of cards in the Teak timeframe, with one item per row.

I agree. A list-oriented view also makes it easier to support bulk operations like "tag multiple components" or "publish multiple components", which I think people will want soon.

@sdaitzman
Copy link

We can consider some reasonable mitigations, and can address this in Teak, but I would not support major changes to the page structure for Sumac. We have testing plans coming up, and will see how much of an issue truncated titles are at that point. For now, I don’t think this reaches a level of severity that justifies a fundamental shift in how we render components across library views. If we identify this as an issue in user testing, we can prioritize alternate view options for Teak. We're already planning to add a list view option (and potentially a 2-column/wide-card view) which will resolve any issue here.

If someone wants to analyze/estimate the percentage of real-world components that are impacted, I’d support that. What proportion of components are not easily distinguished by the first 12-20 characters? What percent are still ambiguous when their content type and a short preview are visible? That could help us determine if this is indeed a more serious issue.

I wouldn't want to rush a change like this for Sumac and get it wrong— happy to discuss the specific UX tradeoffs in more detail at tomorrow's sync if that would be helpful. We’ll have the ability to do testing and feedback and consider options based on the results. Sidebar load performance is extremely fast, which I think makes Jenna's sidebar workaround a reasonable alternative. As an added workaround, we could consider adding tooltips that display the full title when hovering just the card title for more than a moment, to speed up title confirmation.

image

@ormsbee
Copy link
Contributor Author

ormsbee commented Nov 15, 2024

We can consider some reasonable mitigations, and can address this in Teak, but I would not support major changes to the page structure for Sumac.

Agreed. I think we're all on the same page on that point. Though if it helps to clarify things, I believe that moving away from tiles to a list layout is a major change, while wrapping the title text is not.

If someone wants to analyze/estimate the percentage of real-world components that are impacted, I’d support that. What proportion of components are not easily distinguished by the first 12-20 characters? What percent are still ambiguous when their content type and a short preview are visible? That could help us determine if this is indeed a more serious issue.

I think it will be hard to get a truly representative number. In the MIT Stats course I was using for test data, the percentage of Problems that overflowed were the vast majority, say in the 90% range. (I'm not counting the titles that were functionally useless, like blank ones or titles like "1", "(a)", etc. that assumed Unit context–but it's still hundreds of problems) The percentage that overflowed to the point where they could not be meaningfully read/disambiguated was less than that, but still > 50%.

It's hard to do a straightforward data collection for this sort of thing because a lot of courses don't really label their problems in the same way as they would if it were a component in a standalone library, because they have the implicit title of the Unit they're in. So you can name your problem "1" if it's one of three problems in the Unit called "Common Roman Units of Measurement", but not if you expect for it to stand alone.

Also, as I mentioned earlier in this thread, I think that rolling out with this level of truncation could bias library authors into making shorter, non-descriptive titles. So things like "The Empirical Covariance for a Data Set of Vectors" would get shortened to "EmpCov DS of Vec" or "M2U3-Problem7"–shorthand that the library authors could use to disambiguate at a glance, but that would hamper re-use efforts in the future. So later data analysis might tell us that the title length isn't as big a problem, but only because folks have made worse titles to get around the limitations of our system.

I wouldn't want to rush a change like this for Sumac and get it wrong— happy to discuss the specific UX tradeoffs in more detail at tomorrow's sync if that would be helpful. We’ll have the ability to do testing and feedback and consider options based on the results. Sidebar load performance is extremely fast, which I think makes Jenna's sidebar workaround a reasonable alternative. As an added workaround, we could consider adding tooltips that display the full title when hovering just the card title for more than a moment, to speed up title confirmation.

My concern with these approaches is that they hinder scanning for the thing you're looking for. Clicking or hovering over a particular card is okay if you want to answer the question of, "What is this one card showing?". Having to click or hover over fifteen things in sequence to read titles would be extremely frustrating. Could you imagine a mail client that truncated subject lines that aggressively, and then made users click on (or hover over) each individual email to read its subject line? Looking at the top of my inbox, that would be something like:

  • "Reminder: Open..."
  • "Accepted: Mari..."
  • "Fwd: Requestin..."
  • "Help us test t..."
  • "Join Us for th..."
  • a half dozen of: "Re: [openedx/e..."
  • a half dozen of: "Re: [openedx/f..."

I don't think there is a significant downside to wrapping and displaying the entire title in a tile (possibly with a slightly smaller font size). If the titles are short, there's no real difference. If the titles are long, then the browsing experience becomes a bit uglier, but it's still very usable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Report of or fix for something that isn't working as intended
Projects
Status: Backlog
Development

No branches or pull requests

6 participants