Page MenuHomePhabricator

MPIC: Style and UX review
Closed, ResolvedPublic3 Estimated Story Points

Description

T360731

Description

Review design mocks and make visual styles of MPIC staging and production match accordingly.

This ticket can be used when onboarding new designer to enumerate style and UX issues.

Acceptance Criteria

  • Issues checklist epic of tickets is created (aggregated by priority?)
  • Associated tickets are created to track fixes with priority-assignments and linked to checklist epic
  • Documentation of visual changes if different from original designs?

Related Objects

StatusSubtypeAssignedTask
OpenNone
ResolvedSarai-WMF
ResolvedSfaci
Resolvedcjming
OpenSarai-WMF
ResolvedSfaci
ResolvedSfaci
ResolvedSfaci
ResolvedSfaci
OpenSfaci
OpenSGupta-WMF
OpenBUG REPORTNone
OpenBUG REPORTEChukwukere-WMF
OpenNone
Opencjming
OpenNone
OpenNone
ResolvedSfaci
OpenSarai-WMF
ResolvedSfaci
OpenNone

Event Timeline

cjming updated the task description. (Show Details)
cjming renamed this task from MPIC: Style fixes to MPIC: Style and UX review.Aug 12 2024, 6:28 PM
cjming updated the task description. (Show Details)

Some outstanding questions (from Slack):

  • Should we change the text of the form button we use to register and edit instruments? It always says "Launch instrument" but, at this time, we only register or edit instruments when submitting the form. The default value for status is Off so the way to launch an event is enabling it after registering it. Should we change instead the default status value with On to enable/launch any instrument after being created? In theory, the instrument only should be run when status + start date are correct so there is no risk of any instrument running before its start date if they are planned for the next week, for example.
  • When editing an instrument the button is still with "Launch the instrument" but the instrument could be already launched, disabled, . . . and there is a text above that says "Modify instrument: . . . .". Should we change it?

A new question from Slack:

  • Should we highlight the Enable/Disable button for the Dialogs we have to enable/disable instruments?. The Delete button for the Delete Dialog is highlighted with red color but I didn't take anything into consideration about this when working on the Enable/Disable dialogs

Regarding T369237: MPIC: Redirect to Catalog view on form submit and depending on what we decided about the questions above (https://phabricator.wikimedia.org/T371928#10058996):

Should we change the text of the form button we use to register and edit instruments? It always says "Launch instrument" but, at this time, we only register or edit instruments when submitting the form. The default value for status is Off so the way to launch an event is enabling it after registering it. Should we change instead the default status value with On to enable/launch any instrument after being created? In theory, the instrument only should be run when status + start date are correct so there is no risk of any instrument running before its start date if they are planned for the next week, for example.

We might need to reformulate that ticket. The current design says that we should redirect to the catalog view and show a text after registering/editing any instrument. But the text says The instrument INSTRUMENT_NAME has been successfully launched. Monitor in Grafana. And it's not clear yet if we are launching always the instruments after registering/editing them.

Who is assigned to this task?

hopefully i got the right @Sarai-WMF << there are 3 Sarais in phab - i think 2 are from WMDE days?

That's the right profile, @cjming. Thanks for assigning this task to me!

I've drafted the ACs and collected the design verification issues found so far in the following document. I thought it would be a good idea to collect your and Virginia's priority assessment for each suggestion in the table included there. Hopefully this will help us align and decide together what we should focus on fixing first, in preparation for usability testing. Once priorities are clear, I'll update this task's description and include all the necessary changes/specs based on our combined review.

In case the format works for you, please go ahead and add your input using the option provided in the table 🙏🏻 I was wondering if we should also involve @Sfaci in the review of the findings? In that case, we could just copy and paste the relevant select. Feel totally free to skim through the list and only focus on the issues that sound more critical, that'd be perfectly fine.

Please feel free to also leave comments regarding the ACs. The document also includes a lot of open questions that might influence further design suggestions: I'll ping you and Santiago in the ones that I find more relevant. Really appreciating all your support. Thank you!

cjming updated the task description. (Show Details)

It will be a pleasure to be involved here. I'll take a look at the document.
I'll copy the dropdown but, anyway, I'll try to agree with @cjming what to do from our perspective to avoid confusion. It wouldn't be fair having two Eng votes, right? xD

Thank you, @Sfaci! Double-voting wouldn't be a problem, no worries! It'd be great if you focus on reaching consensus, of course.

In parallel, I'll start creating specs to cover all the basics (typography, colors, spacing) so things are ready for when we can hit the ground running.

VirginiaPoundstone raised the priority of this task from Medium to High.Oct 15 2024, 8:46 PM

Priority changes due to Designer's allocation to a different team. We need to capture this information before Saria rolls off our team.