Agents: UI questions/suggestions/improvements.

radist · June 2020

This thread is for support agents to talk among ourselves about improvements we could make to the UI based on tickets and confusion we've seen from the clients.

My hope that is that this gives @mike and @ElizeRowe a casual space for bringing this up without needing to wait for someone else to come online. You can ask questions here and clarify, and post example tickets for further discussions.

This is a good example of something that might come up to put in this thread:

https://github.com/vanilla/support/issues/1592

A small tweak to the UI might make this easier, but if we gather suggestions this together and can group them by area, they are easier to make into projects for the developer.

radist · June 2020

(reserving this post to edit in solidified idea lists later)

Unknown · August 2020

When a client accesses the Vanilla Accounts page, there is an option to allow them to manage their authorized accounts. Since I can remember, this has thrown a 'Something Has Gone Wrong' error, which is confusing for the client and leads them to seeking Support. Support Agents aren't able to adjust authorized users, so we pass it over to Billing, who verifies their identify and (I believe) works with Ops to get them added.

It's a frustrating and kind of confusing client experience. It would be great if that function was restored, or (at the very least), it was replaced with instructions on who they need to reach out to to adjust the authorized users for their site - this would reduce the feeling from the client that we're just passing them around the company.

Unknown · October 2020

Currently, it is not possible to update the order of profile fields when using the 'Profile Extender' addon.

If a client wants to re-order, it's either a Support ticket or they have to delete the fields and re-create them in the order they want.

A slide-and-drop system like we have with categories would be a great QoL enhancement.

Unknown · October 2020

One of the most time-consuming tasks for agents and CSMs is updating email locales. It is a giant pain to set one (especially if the client wants a lot of extra stuff in it - lists, links, images etc) and some can be annoying to test.

This should definitely be something that Vanilla should look into as a Dashboard enhancement - an easy way for clients to pull the default text of emails and edit them as they want. This would cut back drastically on the amount of time that CSMs/Agents have to dedicate to updating that information and allow the client to change the information in those emails as their community grows/changes.

An additional enhancement would be if it was possible to trigger those specific notification messages from the Dashboard (rather than trying to trigger it live on a site). We can already send a test email to any email - but having the ability to trigger an updated registration email to go to an address without having to register a new account on a site would save a ton of time for both CSMs and client.

Unknown · September 2021

We have customers with multi-lingual sites who want to replace default text. We can, of course, do this in locale to replace the English text, but that means that the replaced text won't get translated elsewhere, leaving the English locale text in place.

I'm guessing that's because locale uses the same text-replacement process as translation and takes priority, which is why it doesn't get translated itself.

In other words, the text-replacement process must be something along the lines of, "If the text being replaced is in locale, replace it from locale, otherwise replace it from Transifex."

Anyway... I thought it would be nice if we could use locale to replace text for multiple languages. And I think I thought of a way it could be done without making the text-replacement process significantly more complicated. The locale could be formatted like so:

{
    "I would like to replace this multi-sentence string. I would like to do so in multiple languages."
    {
      "en": "I would like translations of this string in multiple languages.",
      "cy": "Hoffwn gael cyfieithiadau o'r llinyn hwn mewn sawl iaith.",
      "it": "Vorrei traduzioni di questa stringa in più lingue.",
      "de": "Ich möchte Übersetzungen dieser Zeichenfolge in mehrere Sprachen."
    }
}

We'd still start with the existing text to be replaced, followed by another level of replacement, which consists of the language for which the replacement is needed, and the text to replace it with.

Now the text-replacement logic would go something like this, "If the text being replaced is in locale for the language in use, replace it from locale, otherwise replace it from Transifex."

This isn't meant to replace Transifex, only to allow customers who run multi-lingual sites that want text replacement to be able to take advantage of locale.