Modernize default card templates for readability: revised proposal and technical details

No, most of it is for the default templates which will be visible to users if they try to edit something. Otherwise, it breaks some people’s templates or it’s not easy enough for non-tech users to make changes in styling.

3 Likes

But many people would be editing or creating decks on a computer, even if they mostly review using a mobile device.

In that scenario, Anki cannot offer just CSS pertinent to mobile, if it is currently serviing windows on a desktop, etc.

The other issue, of course, is that you are limiting your deck to being used on only one platform.

3 Likes

I’m really grateful for all the thought you’ve all put into this (and for all the work many of you have done on Anki). Since I’m so verbose already, I’ll respond without quoting or addressing every criticism, even though many are apt.

TL;DR

A few small readability improvements are well worth it and not disruptive:

  • Line spacing

  • Margins

  • Divider tweaks

Others are harder to implement, but might be possible behind the scenes:

  • A modern font stack

  • A max width for text, while images can be full-width

But I concede that left-alignment is too big a trade.

Why I still think it’s worth making the default more readable

It seems like it’s harder to agree on an implementation than a design (not that we’ve done that either). I’ve complained about the current balance of priorities, but I actually love Anki’s approach here: bare bones, but customizable, while sneakily introducing users to coding. What I’m still complaining about is that I think readability is underappreciated but can be improved with small changes.

A friend friend gave up on Anki because of its usability. I find the styling genuinely difficult to use at length. The response on Reddit was mixed, but leaned heavily positive. Many commenters are just happy to have an alternative. Many didn’t realize the default could be adjusted. The upvote rate was 95% for a balance of 152. I’m not saying this decides the issue of course, just that it’s a piece of evidence that some users would prefer a more readable default:

As I see it, users can fall into several categories—those who: (1) won’t find the styling pane or try to use it no matter how simple, (2) will only customize it if it’s simple, and (3) will customize it no matter what. The current situation prioritizes the second group, even though they must be pretty small.

A number of you have suggested a different customization interface, or multiple defaults, or a configurable default. I think these solutions could be great. I’m just not sure how to make any of them work. And they might not benefit users who never get as far as customization. Instead, I’m summarizing what I think our conversations suggest: first about what the default card appearance should be, then about what it can be given the implementation constraints.

Card appearance (if it can be implemented)

1. Wider line spacing: Yes!

This alone makes a big difference to readability, and there weren’t many objections.

2. Text alignment: No (not as the sole default)!

This is, by far, the biggest source of objections, both on the Forums and on Reddit. I agree that center alignment is best for very short cards, and that start-alignment is broadly in tension with the minimum information principle and the feel of a flashcard, even when it’s more readable. I still think readability for longer cards carries weight here too, but I can see I’ve lost this fight!

3. Shorter line length: Depends on implementation!

Most of the objections here are about images, an important use case. Line length makes a big difference to readability, but admittedly can be managed by the user through window size. The best design would limit the width of text but not images, but I’m not sure if that’s achievable under the current constraints.

4. Appropriate margins: Depends on implementation!

A modest (but responsive, as others have suggested) top-margin to separate the card text from the button text would be nice here, but is less important. I offer a possible implementation below.

5. Modern fonts: Depends on implementation!

There are lots of objections to the implementation, but fewer to the design choice. On the other hand, Arial mostly becomes a readability issue at smaller font sizes, and while most designers don’t like it for aesthetic reasons, I don’t think that should control here.

FWIW, I agree that Arial was the best choice at the time.

6. A better divider: Why not!?

This is comparatively small, but I don’t see a downside to changing it.

Implementation

1. Wider line spacing: an easier win

I’m unqualified to say for certain whether this could go in reviewer.scss without hurting existing cards, but I’d note that it’s already different in AnkiMobile, and I can’t see how it could affect anything besides vertical spacing. Then again line-height: 1.5 is sufficiently intuitive that, personally, I might just as soon add it to styling.css.

2. Text alignment

3. Shorter line length: for text but not image? How?

I’d like to cap the width of text, but not images.

Right now, reviewer.scss has:

img {
    max-width: 100%;
    max-height: 95vh;
}

For me, with max-width: 650px in the user styling, the following code displays images as they are now: centered, full-size up to the window size, with margins.

img {
    display: block;
    max-width: calc(100vw - 40px);
    max-height: 95vh;
    margin-left: 50%;
    transform: translateX(-50%);
}

But this would break existing note types if the user has overridden some of these properties but not others, right? Is there some workaround I’m missing :crossed_fingers:?

4. Appropriate margins: can they go outside user CSS?

The margins and padding I suggested above were mostly to manage the text block with max-width.

If there’s no max-width, and if it’s OK to adjust cards’ vertical spacing from inside review.scss, I think margin: clamp(20px, 8vh, 40px) clamp(20px, 5vh, 40px); is a gentle way to give some extra breathing room on desktop. (I’m not sure what the default is on AnkiDroid, and I’d leave AnkiMobile the way it is.)

5. Modern fonts: can they go outside user CSS?

Ideally, I’d suggest that something like “sans-serif” in styling.css get the appropriate system font from somewhere not exposed to the user (webview.py?), but this would affect users’ existing cards. Would it be possible to have a value unique to Anki (default-font?) in styling.css, which gets the system font stack from lower down? Or maybe the user-exposed CSS is a bad place for Anki to be doing its own thing?

If there’s not an under-the-hood solution, I’m not sure what the right call is. I still think the card’s appearance should come before the CSS’s, but the font stack is the most intimidating addition to the code.

This is more clever than what I came up with, but I feel like you were just being generous towards me :grin:. I think I’d still rather either find a way to hide the font stack from the user, or double down on a bit more complicated CSS.

6. A better divider: easier

I think this can be done in reviewer.scss, but I’d want people smarter than me to reach the same conclusion before it was changed.


Again, thank you all for your attention to this.

4 Likes

Line spacing: I agree with you that it’s fairly straightforward, and could go in the template

Divider: implicit in reviewer.scss seems appropriate

Fonts: Having a font-family line in template makes it easier for the user to adjust their font. Using some placeholder like ‘font-family: “default Anki font”’ that gets replaced later could work, but it’s not a perfect solution:

  • Users can’t easily make small changes to the existing list
  • It’s complicated to localize into the user’s native language
  • It won’t work when imported into an older Anki client

Desktop margins: no strong feelings here

Readable width: yep, changes to the implicit margins/transform would break existing templates. I suspect this is something we can’t change without some sort of opt-in by the user.

2 Likes

Thank you! I’ll put these in GitHub. (I’m new to this, so it’ll take me a minute.)

2 Likes

I’m not looking to revive a possibly closed thread, but a half–way alternative to cover both scenarios could be margin-inline: auto with text-align: start inside a display: flex parent.

I created a minimally representative example in CodePen where you can change the size of the card by dragging the vertical bar at its right border, and modify the text with a simple double click to add longer paragraphs and observe their behavior.

This way it’s pretty easy to center short text and images, and align them once they have exceeded the width of their container.

1 Like