This is my new preference over the text editor metaphor both for the simpler shape, and also fitting in with the other icons sets in terms of pencil placement. For the RTL version, 002 Menu AEB (i.e., use same as LTR) works best in my opinion, as it is the same direction of the pencil in RTL as the regular edit pencil, and is writing inside dotted line page as you note.
Wed, Sep 22
It would be helpful to know the usage of mobile gestures for the wider Design and Design systems team as we start adding these to more of our products. Would it be OK to add if it is minimal effort?
Tue, Sep 21
Not sure if this has been discussed on a separate task, but showing both Edit and Edit source is actually dependent on the language wikis as well. So for example on cswiki both tabs are shown by default (even for logged out users).
My questions for you all are:
- do you have time to form an opinion about this (which ideally would include thinking through all use cases — desktop, mobile, apps, etc. — and coming up with a coherent icon plan)? it's fine if you don't, we can also run this through our general design team process and get it sorted out in a more generic way
- have you considered using a toggle instead of a dropdown in the editor, therefore removing the need for a "parent" icon? I bring this up because a) if we didn't have a parent icon it might simplify things (two icons instead of three), and b) according to UX collective it is bad UX practice to have a dropdown with only two items in it (link to article). E.g.
Is there a possibility to remove the toggle/switch entirely from the wikitext/VE editors when there are two Edit/Edit source tabs?
Mon, Sep 20
from my perspective it seems straightforward enough to do on its own, unless @MMiller_WMF wants to pause it with the other Add image tasks anyway and concentrate on 'lull' tickets these next couple of weeks.
Sat, Sep 18
Fri, Sep 17
Thu, Sep 16
Wed, Sep 15
Hi @aminalhazwani - agree with @alexhollender and @Theklan that the last option (frame #1011) works well and also appreciated your thorough and well-documented exploration process.
Added replies to Alex and your comments about icon styling in the menu below.
Thanks for this idea @kostajh and interesting @Tgr that there was a proposed experiment. I can see the benefit, but also worry about it having the opposite effect of discouraging further edits so my inclination is to not prioritise this right now.
In terms of how we would show the additional revert user education piece, I think it work better as a guided tour type pop-up that appears over the notifications icon so that users are reminded that that is where revert notices are posted, and to keep it as a single succinct explainer message rather than multi-step flow, given this would need to be translated and configured to different wikis (that might have different ways of handling reverts that won't be easy to translate over multi-steps).
Thanks for the ping @alexhollender - my belated 2c below.
Agree with others that the new star on list icon makes sense, and second @Volker_E's suggestions about revising slightly so the placement of the star is top right instead.
Tue, Sep 14
Mon, Sep 13
Aug 23 2021
Low prio, skipped for this prototype.
A consideration that @Prtksxna asked about during the regular design meeting was to make it more MediaWiki agnostic so that it could be used by developers for example on WMF Tool labs, as well by designers and developers creating prototypes for Wikimedia projects that are not yet on MW.
I would also strongly support MW-agnostic library as this would serve the principle of making this accessible to more people and to enable more people to start participating who are not yet using MW. It speaks a little as well to the Movement Strategy UX recommendations around being more inclusive of designers, who are again not necessarily utilising the MW library yet but wish to prototype and build tools using the design system.
Aug 22 2021
Note one issue opened as https://phabricator.wikimedia.org/T289444
Aug 20 2021
Posting issues found by @MMiller for posterity:
Aug 19 2021
This and the item from T289004 are all sorted, thanks!
Done - but filing a follow-up task to show the reject as a dialog within the edit page
hi @mewoph - fyi I added back in the onboarding for concept A since we want to use the same onboarding (concept B) for both concepts during this round of usability. The only thing that needs to be done is changing the position of the pointers to match where the relevant elements will be located in concept A
OK that's sorted too so all deployed, thanks!
Thanks all, LGTM!
Thanks Kosta! Merged and looks good on the ConceptA branch but I think I need to figure out how to get the changes showing up on the localised versions (ConceptA_en and Concept_es)
Aug 18 2021
hi @kostajh, sorry I realised I didn't clearly ask - would you prefer I merged PR14 first and fixing the "Yes" Preview in a follow up?
One point that was raised in the summit (apologies I forgot who specifically raised this point) was where and how people could see what one-off components are available. I wonder if there is a case to be made for documenting all one-off components in the same place? This may help surface when one-offs could be elevated and reduce redundancy in people potentially starting work to propose a new component for which a one-off already exists.
- The first issue is not only on iPhone but all smaller devices where there is scrolling on the card so would prioritise this as High. I think it would be better if for layouts where the screen height results in scrolling, for the bottom edit bar to not be shown and to move the arrows back to left and right of the card:
|Fallback for when device height overflows|