hi @Trizek-WMF - here's some review notes for the sample pages, hope it helps!
Fri, Jan 24
The move of the difficulty label to thje separate line is expected and this looks right except for the info icon size which @Etonkovidova captured on T233307, and also if we can add 8px between the task description and the difficulty label when this occurs:
Thu, Jan 23
Wed, Jan 22
Tue, Jan 7
Sat, Jan 4
Based on the example scenario I agree it is not useful and I also do not think it is at all expected that the task type dialog remembers copyedit when it was not "saved" by the user. The first case @Tgr mentions (20=number of Copyedit + Add links tasks in Art) matches my expectations, whereas I would never have expected unsaved dialog changes to be remembered as is outlined in the second case.
Dec 23 2019
Apologies but I am having a little trouble understanding what the conflicts might be that have been pointed out. Would you be able review the selected behaviour as I see it outlined in the following scenario, and highlight what is not feasible and/or problematic?
Dec 20 2019
Thanks @Etonkovidova –this better on the real device.
hi there - I think the mock-ups were based on the v1.0 'final mocks' which have since had minor text changes. I've just updated to match what's in the copy doc and happy to go with option B as well.
Dec 19 2019
– I agree this is OK
Dec 16 2019
Dec 13 2019
Thanks for checking @Etonkovidova - yes the close X instead of back arrow is fine, and this looks good for PM sign-off.
Testing today in cs.betalabs:
|Example 1 (easy tasks)||Example 2 (Mixed task levels)|
Dec 12 2019
LGTM - Thanks!
I thought this was the priority based on the subsequent comment T238231#5691846....
> The other modules have server-side rendered content so they appear well before the Suggested Edits module which is all client-side. On initial page load, we can't use the design here because it assumes we know the initial task title and its task type. It also requires us to render the task filters, previous next buttons, and task explanation on the server-side.
If we modified the design such that the placeholder has no title nor task type it's a little simpler because we just render a totally generic placeholder on the server-side. But we would still then need to render the filters + arrows + explanation widget on the server-side. If we updated the design to remove those from the initial page load placeholder, then that simplifies things more.
We can also do this for the initial load if we can get the skeleton to look like the following:
Skeleton with no server-side rendered elements (except background color)
CSS animated version: https://codepen.io/reets/pen/bGNeMdL
There are also a few other display issues which is covered under point M. in T238280
hi @kostajh - can we show the whole string of text on hover? Maybe like so:
Dec 10 2019
Dec 9 2019
Thanks @Etonkovidova - yes, you're right, the dimming expected is a white overlay @ 50% opacity, but this is using rgba(0,0,0,.8) @ opacity:50%.
hi @Tgr - a few minor points and this should be good, thanks!
Dec 6 2019
hi @MMiller_WMF - can you please take a look at the initial plan and provide input about the type of task that we likely want to go with for testing so that the relevant draft help content can be written. Thanks!
Dec 5 2019
Dec 4 2019
Dec 3 2019
Dec 2 2019
Nov 29 2019
Nov 28 2019
This is working as expected for me as well. The style updates will be tackled in the mobile style ticket (T239442).
Nov 27 2019
This is one of the open questions in the v1.2 planning doc – I agree that the answers should probably be yes, but would want us to be able to show source as via the homepage/SE module vs organically. Another consideration is this would affect the design and copy a little – we could either provide more context and explanation if it is detected that a user got to the article not from Suggested edits, or make the task guidance like this for everyone (re-explaining a lot more about what they are seeing).
Nov 26 2019
Nov 25 2019
Nov 22 2019
@MMiller_WMF - should we close this task in favour of T223221, since its purpose as "a short term solution before the newcomer tasks module and other newcomer module improvements are introduced" is no longer valid?
hi @MMiller_WMF - I've specified the bulk of the pure css style changes for Desktop here, ready for prioritization.
Nov 21 2019
Ah cool. Let's make it 1.14285714em instead since that seems the most straightforward (?) update at this point.
– Basically no, I cannot think of an elegant way to do this. One way might be to show this long explanation as a tooltip that the user must dismiss after reading to continue. However this would draw unnecessary over the top attention to this small piece of info, and you really can't guarantee people are reading it before dismissing, that they won't forget about it when seeing the text again maybe a week later.
– Great, I can see it fixed on beta.
(6) Many text styles are now larger than expected on mobile:
i) Intro overlay and difficulty overlay headers should be 16px, now they appear to be ~19.2px (1.2em)
This is fixed by reducing the base font size in the dialog.
– Actually this is still slightly larger than expected, since 14*1.2 = 16.8px... can we change the base font-size to 13.333px? Or might that lead to a lot of unexpected padding or font-size discreprancies in other places (or a bad idea for another reason)?
Nov 20 2019
hi @Tgr - yes I have updated the mocks so the nav bar is now also dimmed and we can use the standard drawer component. Thanks!