wordplaydev / wordplay

An accessible, language-inclusive programming language and IDE for creating interactive typography on the web.
Other
63 stars 44 forks source link

Toggle space indicators #256

Closed amyjko closed 8 months ago

amyjko commented 1 year ago

What's the problem?

The editor always shows spaces and tabs as indicators of where spacing is. One creator became confused by these, since the space indicator was the same as the product indicator, but a different color. They requested the ability to turn off the space indicators.

What's the design idea?

Just have an editor toggle that turns off spacing indicators. This could be synced as a setting in the cloud, or local to an editor, or local to a project. I think the best design is probably an account feature, since its a work preference.

Who benefits?

Any signed user editing code.

Design specification Draft

Here is the second draft of the design specification, please give me feedback and let me know if you have any questions! Thanks!

Functionality

How the Setting is stored

Design Considerations

Design Drafts

Figma design draft image

leahjia commented 1 year ago

I attempted to add a space indicator mode in en-US.json since that is where I saw all other settings being listed, but it shows a warning saying it's not allowed.

Some notes & suggestions from @amyjko:

en-US.json is the English locale file; it contains strings that are used to localize the interface, not settings.

To make a space toggling setting, there are a number of design considerations:

Those are all key design questions to answer before you start on an implementation, because the implementation would change depending on their answers. Design first, then build.

amyjko commented 1 year ago

Clarification: settings are not listed in en-US.json, or locale files. That's only for localizing strings in the interface; you likely are referring to the settings key in the locale file, which just contains the strings used in the settings dialog.

After you have an approved design, likely places to implement this, depending on the design, are SettingsDatabase, Space.svelte, Spaces.ts, and CaretView, all of which are involved in rendering spaces.

leahjia commented 1 year ago

Yes I was referring to the settings. I wanted to see if I could have these space replacement calls depend on a toggle somewhere (settings in this case).

After you have an approved design, likely places to implement this, depending on the design, are SettingsDatabase, Space.svelte, Spaces.ts, and CaretView, all of which are involved in rendering spaces.

Should I pull in the design team first?

amyjko commented 11 months ago

Eek, looks like GitHub didn't give me a notification about this comment. I just noticed.

Yes, this issue has the needs design tag, so it needs design before it can be built. Implementation comes after design. Per the design process on the wiki, this won't be ready to build until the issue has an approved design specified in the issue body above.

momoko0719 commented 11 months ago

Hi! I've updated the issue section with the first draft of the design specification. Please provide me with some feedback, and feel free to ask me questions if any part is unclear. Thanks!

amyjko commented 11 months ago

Overall, this design proposal is clear and complete. The only unresolved parts are 1) whether you're proposing to allow for space indicator customization, and 2) whether you're proposing to provide indicators for the line the text cursor is on. Design proposals are complete when they have no ambiguities left, so these have to be decided before this is ready to build.

If you do offer customization, one engineering constraint to know of is that not all symbols are equally simple to support. The font may not support the symbol and some symbols are not fixed width. So you'd likely need to limit it to a specific set of symbols. That said, I'm not sure customization is particularly valuable. I'd want to hear more about why you think it's needed, who it would benefit, and who it would harm.

momoko0719 commented 11 months ago

Overall, this design proposal is clear and complete. The only unresolved parts are 1) whether you're proposing to allow for space indicator customization, and 2) whether you're proposing to provide indicators for the line the text cursor is on. Design proposals are complete when they have no ambiguities left, so these have to be decided before this is ready to build.

If you do offer customization, one engineering constraint to know of is that not all symbols are equally simple to support. The font may not support the symbol and some symbols are not fixed width. So you'd likely need to limit it to a specific set of symbols. That said, I'm not sure customization is particularly valuable. I'd want to hear more about why you think it's needed, who it would benefit, and who it would harm.

Thank you for your insightful feedback on the design proposal. I appreciate your comments on the clarity and completeness of the proposal. Regarding your concerns:

After reflecting on your feedback and considering the practical aspects, I agree that allowing for space indicator customization might introduce unnecessary complexity. The engineering constraints you mentioned, such as font support limitations and the varying widths of symbols, present challenges. Moreover, choosing appropriate symbols for space indicators is not a straightforward task. Given these factors, I now believe that customization may not be essential for the project's success.

As for providing indicators for the line where the text cursor is located, I propose we do not include this feature in the current scope. Keeping the design simpler at this stage will help us focus on the core functionality and ensure a more streamlined user experience. We can always consider adding this feature in future iterations based on user feedback and demand.

I've updated the design specification and I'm open to further discussion on this and look forward to your feedback, thanks!

amyjko commented 11 months ago

Okay, I agree. Design approved! I've marked this buildable.

Will one or both of you be acting as the developers for this? If not, I encourage you to recruit someone.

leahjia commented 11 months ago

Thank you @momoko0719 @amyjko. Happy to take on this one, and I'll ask if anyone wants to collaborate.

amyjko commented 11 months ago

Hi @momoko0719 and @leahjia!

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

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

leahjia commented 11 months ago

Hi @amyjko thank you for checking in. I've invited a couple of developers to work on this together and we've looked over the design, but I'll confirm by end of this week whether they would like to continue over the winter break.

leahjia commented 11 months ago

Update: Looks like most of us will be traveling over the holiday. I'll unassign myself.

amyjko commented 8 months ago

It's the end of Winter! Please provide an update on this issue, including:

If you do plan to continue work on it, carry on. Otherwise, thank you for your contributions!

lpjjj1222 commented 8 months ago

Hi @amyjko , I have resolved the whole issue and my pull request has already been merged =) https://github.com/wordplaydev/wordplay/pull/360

amyjko commented 8 months ago

Ah, it looks like you didn't include the required "Fixed #256" in a commit, so this didn't auto close. Closing :)