I noticed some controversy about the new Mosaic view. Personally, I don't like the view much, but it doesn't seem to be universally hated by the community.
I identified some use cases while looking on the forums online, so I could give you a free analysis. I'm not a professional analytic, but with some background in software development, I'm not entirely foreign to it either.
Member has two roles depending on their intended action in the use cases:
Sender (of message)
– Creates a message with multiple pictures and sends / posts it.
Recipient (of message)
– Receives the message from Sender and might want to read it.
Admin (of server where the message is sent)
– Sets up rules and moderates the server's Members.
Form – the preferred term for "view" in this analysis, as it isn't viewer-defined.
Gallery – Form that prefers Mosaic view, with images grouped and/or tiled.
Vertical – The pre-existing Form before introduction of Mosaic view.
Use cases (as found online in various places):
1. As a Sender, I want to post multiple pictures as a Gallery.
– This is already implemented as we've learned the hard way.
– Further tweaks to preserve aspect ratio and limit cropping might be advised.
2. As a Sender, I want to be able to post multiple pictures in a Vertical Form.
– This behavior has been replaced by (1) and needs to be re-introduced.
– You will need to implement some form of choice to harmonize (1) with (2).
3. As an Admin, I want to have a way to prevent text channels being flooded by images
– Some admins consider Gallery a solution to this use case.
– Other forms of control might be even better to prevent channel flooding.
– Limiting image count per message could also help, throttling already exists.
4. As a Recipient, I want to have a control on how the message is viewed
– Recipients would need some settings to override the Form set by Sender.
Choices (and configurations):
1. Sender should be able to set their long-term preference.
– A new entry in User Settings, with three options: Prompt, Vertical, Gallery.
– More entries or options if harmonization with server side preferences requires them.
2. Sender should have a choice of the Form of the message.
– If Prompt is preferred, modal window shows up when Sender adds multiple image.
– If Vertical or Gallery is preferred, the modal window can be available on click.
– Editing the Form of an existing post should also be allowed.
3. Admin should have a choice to disallow a Form channel / server-wide.
– This can override the Sender's settings if their preferred form is disallowed.
– This doesn't apply retroactively to existing messages.
4. Admin might have a choice of preferred Form.
– A form of soft assertion where admin recommends using some Form.
5. Recipient might have a choice to override the Form selected by Sender.
– Their experience will differ from the one intended by Sender, at their own risk.
– This could be a part of Nitro as it might introduce some extra costs for Discord.
The backlash of some existing users is pretty clear. The retroactive change made some posts in slow running channels a jumbled mess.
Rolling back the changes and announcing some further work before it's released is a good conservative approach that allows users to keep the existing Form of their posts, if they relied on it upon posting.
Running another round of UX testing with some actual gamers before rolling it should be advised. Discord started mostly as a network for gamers, and they have different needs than most users of other social networks like Facebook. Changes like this one can alienate them and motivate them to start looking for alternatives.
Rolling the changes out (again) will be safe once both Sender use cases are harmonized.
Du måste logga in om du vill lämna en kommentar.