Weight and Italic Shortcut in Palette

[brightuw]

What's the problem?

It can be confusing and unclear as to how to bold, italicize, underline, etc. a phrase. For example, you have to wrap the phrase with `` and then also wrap it with a certain syntax depending on what type you want it to be (bold, italic). This also requires users to memorize how to markup these texts, (ie. remembering that ** is bold, ^^ is extra bold, etc.)

What's the design idea?

Creating a shortcut menu in the palette that allows users to easily toggle the weight or italic status of the phrase. For convenience's sake, the buttons will mark up the entirety of the phrase.

Who benefits?

This will benefit users who might want to use font weights and italics. This can also be a learning experience for them, seeing that when text is toggled as bold/italicized, it is actually just being wrapped in a markup syntax (ie. **, ^^, ~~, etc.)

Design specification

General description

We are proposing to add two (2) features/shortcuts that will enable fast markup, located in the palette menu. One is a dropdown menu displaying all the available weights of the current font, displayed as what it would look like (seen in Figure. 2). The second is a boolean toggle that italicizes the text.

Visual representations

Figure 1. Proposed palette menu layout.

Opening the weight menu will open a dropdown menu that allows users to select an available weight size, dependent on the font face chosen.

Figure 2. The weight dropdown menu opens and displays the available weight sizes

Depending on what the user selects, the Phrase code in the program will be altered to the appropriate markup syntax and the text displayed on the Stage will be altered as such. For example:

Figure 3. Unmodified, original text with regular weight size and without italics or underline

Figure 4. Text with bold weight size selected and underlined. Does not have italics

Additional specifications

1. Each weight size (400, 700, 900, etc.) will have a standardized name. Common names and labels for weights can be found here. Look for the header "Common weight name mapping"
2. Marking up the text using the features/shortcuts in the palette menu should mark up the entire text in Phrase. As opposed to giving users the option in the menu to choose which splices of text should be bolded.
3. Even if the original text in the Phrase was wrapped in single or double quotes (ie. ', ") if the user uses the markup tools, backticks (`) will then instead be used to wrap text until manually changed in the program script. This also applies when users select the "regular" or default font again after selecting a different weight size.
4. If the text was already marked up in two or different formats (for example: my *test* /string: with "my" having no markups and in regular (400) size, "test" as bold (700) size, and "string" italicized), display weight as "Mixed" and italics as false (because the entire text is not italicized), with both options always available to be changed. Override the entire text when a specific weight is selected and italicize the entire text when italics is toggled to true. "Mixed" will only be displayed in this edge case and is not an option in the default dropdown.
5. In this case where a user selects a font as bold and then switches to a different font, maintain the markup and keep it bold. In the edge case where the second font (the font being switched to) does not support that weight, change the mark up to the closest weight in size available. (For example: User selects Noto Sans and extra bold (800), showing text as ^text^. Then the user changes the font to Arvo which only has regular (400) or bold (700), markup should change to bold (700) *test*
6. Note: Font weight support can be found in the repository (wordplay > src > basis > Fonts.ts) However, due to font synthesis, font faces that do not formally support a bold weight, the browser will "fake" a bold interface by thickening the font. In this implementation, maintain this behavior if the font face does not support a bolder font.

[amyjko]

I'm looking forward to the design for this!

[brightuw]

@amyjko Requesting a design review!

[amyjko]

I like it! A few edge cases:

• What should the active/inactive state of the new controls be if the text already has some formatting that's not supported by the controls? (e.g., my *test* /string). Should there be a "custom" in the weight dropdown, for example, and a dash in the checkbox? Or are the controls hidden and a message is shown?
• What weights do you propose count as bold? Typically its 700 or higher, but some faces appear bold even at 400. How should we define bold? (Italic is well defined).
• I think if the face is changed, bold and italic should be maintained if supported, and not otherwise. This preserves intent, and just requires a bit of intelligence to map the previous setting on to a reasonable default.

[brightuw]

Thanks for the insight! I will respond to each bullet point with bullet points respectively.

• To my understanding, you're asking what to do if a single text has three (or more) formats: regular on the "my", bold on the "test" and italics on the "string" (in your example of my *test* /string. If that is the case, I would propose to display weight as "Mixed" and italics as false, with both options always available to be changed. Then I would propose following Google Docs's behavior and overriding everything when a specific weight is selected and italicizing everything in the text when italics is toggled to true. "Mixed" will only be displayed in this edge case and is not an option in the default dropdown.
• I think we should categorize "bold" as 700. Although certain fonts appear as bold in 400, that is still their "regular" form.
• I agree. Additionally, if we marked up a text as extra-bold ^text^, and then switched to a face that has bold but not extra bold, should we:
  1. Maintain the markup since ^^ defaults to bold
  2. Switch the markup to ** (the closest to the previous)
  3. Default back to regular (400) weight

In my opinion, I think option 2 is the most beneficial, maintaining the user's original intention of font weight while also not confusing them with markup notations. This also allows the font to eventually be defaulted back to regular (400) weight when a face with no other weight support is chosen.

[amyjko]

Thanks @brightuw, I think these are good defaults. I like "Mixed" instead of "Custom"; it's more accurate. Once you incorporate these design details back into the design spec, I'll remove the needs design tag from this and add buildable.

[brightuw]

Hi, @amyjko. I've made changes to the design specifications to include these new edge cases. However, now I have two additional concerns.

1. Wordplay also uses markup to underline text. Will the usage of these shortcuts eliminate the need to even use markup, hence, users might not remember that they can underline. As a solution, we could also add an underline toggle, similar to how the italics toggle behaves. Additionally, would it be appropriate to have that toggle next to (to the right of) the "italics" toggle?
2. I have looked at the Fonts.ts file in the repository, and I noticed that there are a lot of weights set as just [400], so I assume that they do not support bold. However, after testing on Wordplay directly, a lot of these fonts labeled as only having 400 size weight actually support bold. Examples of this include the font faces: Short Stack, Graduate, Crafty Girls, and a lot more. I'm actually having trouble finding a font that doesn't follow this behavior.

[amyjko]

1. It won't eliminate the need to use markup, since these toggles will only wrap the entire phrase, not subsequences of a phrase. Additionally, the point of these shortcuts is to help creators learn that markup even exists. So yes, underlines should be included. Placing it next to italics seems reasonable, though from a layout perspective, the row of controls could be too long, so a row below might be justified.
2. Thanks for catching the discrepancy between the fonts metadata and the browser behavior. This is due to something called "font synthesis", where browsers take fonts that do not support bold and italic and "fake" it, but slanting characters or making them appear bold. So the fonts you're mentioning technically don't support bold, but the browser tries to simulate it. That leads to a decision decision: do we show what the browser will try to do (and sometimes fail to do), or do we only show what we know is actually supported? I'm leaning toward the first option, since it's mostly supported, just sometimes with unexpected font ugliness. You can read more about this here: https://developer.mozilla.org/en-US/docs/Web/CSS/font-synthesis

[brightuw]

@amyjko I finished implementing these new aspects in the design proposal and am now requesting a design review.

[amyjko]

Okay, this looks ready to build to me! Fantastic work on getting the details right for this. I think this will be a solid improvement to the styling experience, and help with teaching the markup syntax.

[amyjko]

Hi @brightuw and @simku22!

It's the end of the quarter, so please post an update on this issue. Things to consider:

• Should you still be the assignee? (If you're planning on working on it, yes! Submit a comment explaining your plans. If not, then unassign yourself, so others are eligible to grab it).
• Do you have any work products that are hosted outside of GitHub? Embed them in this issue, so others can build off of them.
• Are there any branches associated with this issue? Please link to them in the issue.

If there's nothing to change above, then at least post a comment indicating that you've seen this. Thanks!

[amyjko]

No reply, unassigning everyone to free up the issue for others to work on. Reassign yourself if you're still working on it.

[amyjko]

Phew, building this was a beast! But I'm pretty happy with the final implementation. I mostly followed the design spec, with a few additional tweaks for UI consistency, and a few changes in behavior due to technical limitations of formatting (e.g., we didn't account for multi-paragraph text).