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

update copy in 'Message length' accordion box component #2312

Open
dmvancura opened this issue Jan 30, 2025 · 4 comments
Open

update copy in 'Message length' accordion box component #2312

dmvancura opened this issue Jan 30, 2025 · 4 comments

Comments

@dmvancura
Copy link

dmvancura commented Jan 30, 2025

Who discovered this?

deana

What happened?

'Message length' accordion box content refers to message, cost, and pricing.

Environment

production

What pages did this appear on?

the Template creation flow page at the bottom within the accord. currently says "if your message is long then it will cot more. See pricing for details"

Image

change to "View the character counter below the template text box to track how many characters your message uses. We recommend keeping your messages around 300 characters long."

Detail the steps for someone to reproduce

@CathyBeil do you agree with the copy update to the verbiage inside the Message length accordion component? thank you!

What browsers are you seeing the problem on?

Chrome

Relevant log output

@CathyBeil
Copy link

If this is a change we want to make right now, under current message part accounting, then I'd say "View the text message counter below the template text box to track the message length and how many message parts the template uses."

If this is part of the change to only counting messages, the message-parts-counter will be going away (I believe) and the message length box should either also go away, or note that each recipient texted counts counts as one message, regardless of the message length. This could also state or link to content that's I think in the best practices about 300-characters being the rough recommended message length.

@dmvancura
Copy link
Author

hi @CathyBeil this is part of the "message parts to messages" content change effort. the message parts counter is updated already in prod, so this is just about whether we keep the "Message length" accordion box. and if we do, does the text make sense? i worked with what you provided above, so here's version-2 of what it could say.

"Message length" accordion component box copy:
"View the text message counter below the template text box to track how many messages your draft is made of. No matter the character count, the text will likely send all together as one message. We recommend keeping your messages around 300 characters long."

@CathyBeil
Copy link

I think there's still some misunderstanding here: the "Will be charged X message parts" should be totally removed when we move away from message parts. Every message will be one message, so there shouldn't be a need to show users how many parts their message will use. We could include a character counter so that they know how many characters they're using, but that would really just be for them to assess the length of their message, it wouldn't have any impact on how they're charged.

So, if we changed the counter to count characters the "Message length" accordion component copy could be:
"View the character counter below the template text box to track how many characters your message uses. We recommend keeping your messages around 300 characters long."

@dmvancura
Copy link
Author

ooh i was still misunderstanding. but now it's understood (i believe). you mean the UI will no longer have any sort of message quantity counter under the draft template text box. instead it's counting characters. in that case, yes a character counter is still relevant, and i believe @jonathanbobel would recommend it (but i'll let him chime in).

i'll update the copy above with your latest comment. thank you much

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Up-Next
Development

No branches or pull requests

4 participants