This field is supposed to carry to usernames as opposed to one ATM. The problem with separating through slash, is that the users might have the same username causing ambiguities. Any good UX suggestions?
I’m not sure that I understand. Why would it have two usernames? Can you explain the use case?
Here’s the case in detail; the extracted portion screen capture is from a web based application that has users synchronized with others that are available under a desktop application. Now, we created a mapping schema for the purposes of user management between the hereupon mentioned applications, that is why we want to display two different usernames under the same field to translate the mapping. I hope this was clear
Is the audience of this information the users themselves or is it for the management/ staff?
Based on what I’ve understood from this & for what I’ve not, I’m making the assumption that:
The user is necessarily registered on both platforms & has two usernames, irrespective of whether they’re same or not. There’s no case of a single platform registration.
There are a few ideas I can think of:
- Using a different color for each platform. So, 2 platforms = 2 Colors. This is not foolproof & is not the best practice, but if the audience is just the staff, it can be a simple & effective solution.
- Defining the order of platforms in column heading, or subtext if there’s no table, & then ordering the usernames in the same order.
- Also why are you using input boxes to show this information? Are the usernames editable? If not, there’s a third solution, you can use clickable buttons(like tags) to represent username of each platform & use shades of grey(or brand colors) as button color to differentiate the platforms. This would also allow an easy access to the profiles. Even if they’re editable, you can use an edit icon near/over buttons.
I hope I understood the problem correctly. Feel free to correct me if I didn’t.
Thank you for the reply. I think the first option that you have provided might be the choice we go for because of the nature of the application we have. Now, when it comes to the field being editable or not, it is disabled but servers multiple purposes thus it has to be on the UI instead of it being a profile based approach as you mentioned under the third option. This is of great help, thank you again