In the Tokyo release, we introduced a Language Picker for various Service Portal header menus ootb.

To learn more about it, check this post.

In this article I want to go through the notion of User Experience (UX) and how it is a super important concept, which is even more true when multiple languages are in-scope.

The Problem

Let's start with a simple question - "How easy is it to change my language preference when I don't understand what I'm reading on the page?"

Imagine the scenario where you've navigated to a site and you know that it's provided in your language, however because you can't read that language, you don't understand how to change the language. Maybe in my scenario I want to change the page from Japanese (which is a language I can't read) into English? or vicer versa for a Japanese native speaker?

Out of the Box, the platform has this capability in all Service Portals, it's on the profile page for any logged in user when you navigate to it from their avatar:

Then when you view that "Profile" page there is a language choice selector, which when the value is changed the session is updated straight away:

So, whilst not perfect out-of-the-box we need to consider that the Platform provides the building blocks to extend and add more, meaning it's a starting point for your needs, because each Company and each scenario is different from another. It's therefore better for us to provide a starting point which you can extend as per your needs.

Can we do it better?

If we review the problem statement, the question with a UX lens is now focused towards reducing the number of clicks or guiding our end-users to the choice with-out the need to read words in another language. Let's go through some examples:Let's add the "Language switcher" widget to the front-page of our portal:

In the above example, the choice is presented very prominently, however it's only available on the page the widget is present on. So I'd say it's a good step in the right direction, it's scalable and doesn't introduce any technical debt as we are leveraging the OOtB widget, just in a different place. So good start.

We can do better still, let's add this same widget to the menu:

To achieve the above, we need to add the following line in a clone of the Stock header record which is in the [sp_header_footer] table (this specific record is relevant to the /sp portal, other portals will have a different record);

data.lang = $sp.getWidget('sp-lang-switch');

You're essentially declaring a data element called "lang" and calling it specifically from the widget which has the back-end name for the OOtB one called "sp-lang-switch". This will make the language switcher now persistent across the entire portal whilst still leveraging the OOtB mechanism. Meaning we're not having to write anything custom to change our language. So far so good, but we can still do better.Because we're still showing a lot of words which still doesn't necessarily solve our problem statement, you'll actually find in a lot of publicly available websites, that there is more of a dependency on iconography. Here's a demo example where the ootb widget has been cloned and CSS themed to do exactly this:

Note the use of a "globe" like icon. The idea here is to show to the end-user subtly the world, then clicking on it will present in their language the other language choices. In this specific example "Estonian" is being used as a "psuedo-language" for testing purposes, which is a topic I'll go through in another post in the future.If you want to see what I mean in action, just have a look at our Docs site:

Summary

When designing, building and owning a Solution, we always need to bear in mind who will be using it. It's not going to be the Developers, or Solution owners instead we want our target audience. For them to be able to adopt it and use that solution to its absolute fullest, they have to understand what they are interacting with - from that very first interaction.

Of course another option is to preset a user's language by script (like a Business Rule every time a new user is created), either by changing the value on their user profile or by creating a user preference on their behalf. Ultimately, the choice is yours.

Please like, share and subscribe if you found this useful as it always helps.