Fri, Jan 18
Thu, Jan 17
More comments inline....
Thanks @Etonkovidova - please see responses inline.
Wed, Jan 16
Tue, Jan 15
Mon, Jan 14
Thanks @Etonkovidova - I think it is acceptable to have the visible checkboxes on Chrome, and per @Volker_E 's the "selected button" using Accent10 is expected (an oversight on my part earlier). LGTM to sign-off.
Sun, Jan 13
Hi Robin , thanks for going through the proto again, just have a couple comments inline below.
Fri, Jan 11
- Sure, I'd just request the specific Alpha version is clearly marked and uploaded for testing across all participants.
Hey @Volker - looks like both the updated references and existing reference icons were omitted in the export. Here are the updated icons as SVGs - thanks for your vigilance :)
Thu, Jan 10
LGTM as well (tested on Chrome mobile browser on Pixel, Android OS 9)
LGTM too!(Nexus 5)
- Yes, that's fine. The main thing is that the message is intended to start on the same line as the icon. The message wrapping to a second line is bound to occur in some language translations and smaller device widths anyway.
- How many people turned on polling out of all those who saw Notifications?
- Interactions with different notification types - how many Milestone, Welcome and Thank notifications were sent vs viewed?
- Was there a particular notification type that shifted contribution/edit rate more than others?
Tue, Jan 8
I think we don't need to mention this one exception case
LGTM, and not resizing to the standard view after opening when the window was >1366px is fine.
Hiya - animations LGTM for desktop and mobile:
(open fullscreen to view animated gifs)
Mon, Jan 7
Relevant to this are some old designs for the same issue on iOS:
Fri, Jan 4
Thu, Jan 3
Since the intention of the narrower design of the help panel is to not cover too much of the editing UI, I've created an "enhancement" task T212897 to only expand the width when the browser window on Desktop is wider than 1366px
Agree with @Pginer-WMF and @Amire80's point that there is unlikelt to be some universally accepted language icon we could be using instead of the current one. I'd also advocate for appending with more signifiers that this is a change-able language settings by adding the language code and/or a dropdown arrow after the icon, rather than trying to amend/change it to some other icon.
Wed, Jan 2
- @MMiller_WMF can weigh in but I think it would be good to more explicitly provide information to users about this experimental feature here as well.
We may also want to consider looking at search queries from the Help panel, assuming T209301 is implemented.
hi @Volker - re: the last item you added about the different transition in the task description after @SBisson's patch - we can use the standard transition
Dec 20 2018
Thanks @SBisson - can we ideally time it to come in after the editor has finished loading?
E. Help panel dialog header icons color and placement
K. Confirmation icon color
I don't think we can change the icons colors. They can be black, blue, or red. Lighter grey is used to represent disabled state and is implemented by lowering the opacity.
Hmm can we make the icons black at opacity .56 so make it as close as possible to the desired Gray?
A green checkmark would have to be a custom icon.
Nevermind, we can live with a blue checkmark.
Dec 17 2018
Dec 12 2018
Findings summary presentation is complete, with most of the minor recommendations from the testing incorporated into the V1 design.
Updated on each line item in the Task description.
- hi Marshall, these have always been on the same step in the design since they are somewhat related. The other more pertinent reason is that for users who provided their email during account sign-up don't see the email field, only the mentor checkbox question. Having them on same step means not having to have a conditionally shown extra 5th step.
- @RHo -- why do we want it so that users can't unselect a radio button? To encourage them to submit their response?
Not so much that, but more so that is the way single-selection response type questions are by design. I.e., the group of radio buttons offers the gamut of all responses possible, for which users choose 1 response. So if someone has made a selection by accident on option A, they should still be able to select whatever the pertinent answer for them in that list.
FWIW, it is the same radio button control as var A, it has just been styled differently – so in var A as well if someone had selected an option by accident they would not have been able to deselect all either.
Dec 11 2018
LGTM on Desktop and Mobile
I think the risk of confusion by renaming the first button "Skip this question" along with “Skip this survey” outweighs the minor risk of people thinking that the survey questions are mandatory (since we do say they are optional in the intro text on that same first question). Secondly it will substantial effort for the change to auto-advance to the next question when the user picks an answer, not to mention the need for an additional “next” button if the user picks “Other” as the response.
My recommendation is we go with the survey as it is now and monitor response rate. If we see a great decline in completion by people exiting at this first step then we can re-evaluate.
- hi @kostajh - yes, let's make it mandatory on both steps 1 and 2 please.
+1 to this proposal, including for showing the "top 5 editing links" inside the help panel as well rather than opening in a new tab.
Dec 10 2018
Dec 7 2018
- This is actually the updated placeholder copy after feedback from a number of people about wanting it to be clearer that people should be asking for help about editing by hinting at this using the first sentence, rather than expecting users to re-type in "I need help with editing". Suggest we keep this as is for now and see what help questions look like before further changes.
hi @SBisson - one more thing I noticed in the mobile test is that when tapping "Next", it proceeds to the next question without returning the user to the top of the screen. For example if I've scrolled to enter my own interest topics on Q3 and tap "Next", I do not see the "Enter an email" field because the viewport is on the lower part of the dialog. See vid showing the behavior here: https://youtu.be/RF9meXc7K0A?t=21 (start ~21sec mark)
Dec 6 2018
- Yes agree, can we hide "Back" on the first step @SBisson ?
- If a respondent is looking at a question and pushes "Next" without answering it, that is effectively them saying "Skip". Should the button literally say "Skip" until they give a response, at which point it becomes "Next"?
- Let's keep it as "Next" since it is confusing to have two actions that say Skip ("Skip this survey" and "Skip" to the next question)