-
Notifications
You must be signed in to change notification settings - Fork 81
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
Comments
@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. |
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. |
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. |
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.
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: 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). 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. |
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. |
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. |
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. |
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.
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.
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:
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. |
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:
Acceptance criteria:
The text was updated successfully, but these errors were encountered: