I just want to stand on land.
- User Since
- Oct 9 2014, 1:53 AM (276 w, 1 d)
- IRC Nick
- LDAP User
- MediaWiki User
@ifried spotted a typo in one of the screenshots, here is the updated file.
Wed, Jan 22
@Samwilson and I did some digging and it turns out Chrome supports screenshots in multiple languages (its just a very complex process). We are trying to see if we can use SVG Translate to get these translated by our volunteers 😊
I was looking at T229714: Spike: Investigate Possible Errors for WWT [4 hours] and it isn't completely clear to me in which cases it is helpful to Contact Us. We could decide to always give them that option. From that point of view the language you suggested, "Error: Refresh or try again later. If the issue persists, contact us." sounds perfect. However, it is a bit awkward to have the whole sentence be a link, but, I do understand that we might need to do this for i18n reasons.
Thu, Jan 16
Full resolution and retina images on Google Drive.
I'd say 0.5em for the sides and 0.75em for the top and bottom.
Was this an intentional design decision? Should the placeholder behave like other widgets, that is disappear as soon as there is something entered?
Wed, Jan 15
Tue, Jan 14
How about something like this:
Mon, Jan 6
Would this be easier if only the word 'contact' was the link?
@Niharika, based on the information on each page this how I am thinking of splitting the filters
Fri, Jan 3
Thanks for tagging me @ifried :)
I didn't know how to force an API error so I switched off the Wifi to get a generic error, is that the same?
Sun, Dec 29
The IP column currently has four pieces of information:
- Number of edits by this user using the IP
- Total number of users using this IP
- Total number of edits using this IP
Sat, Dec 28
Dec 12 2019
Dec 11 2019
@Mooeypoo, I like your suggestion of keeping the effect the same but showing it only on hover. This will still tell the user if something isn't interact-able, even if it is after they've hovered on it.
Dec 10 2019
I think we should add the PRU setting right before the Email confirmation label. I had a few thoughts around this:
- If we add it right after Email confirmation we'll have to update the message in the yellow box. While this is doable, it groups this setting incorrectly with others that actually do depend on confirmation.
- Since we only need the presence of the email for this setting to work, it is better for it to be closer to the Email (optional) label. As removing an email will actually disable this setting, it makes sense for it to be right after it.
Feel free to re-open if we need more assets.
Feel free to re-open in case we need to reassess this.
Dec 9 2019
I think Special:Block would be better with placeholder text too. Any field that can take two types of inputs is confusing, the one in Special:Investigate can take a combination of both which makes it even more so.
Dec 6 2019
@Mooeypoo good idea. Here is what it looks like on the Create account page:
|Without JS||With JS|
Dec 1 2019
Nov 28 2019
Thanks a ton for this @nettrom_WMF!
If we are getting the bytes changed from the same API call we can't completely de-couple it. From what I understand, if the API returns no edit summary then our tool doesn't show the bytes changed either, though I suppose we do have that information (could someone confirm this?).
I am not against hiding the form elements that aren't being used, but, as Volker pointed out, if we do do this we should make sure that the ARIA mappings are correct and we're using aria-expanded and aria-controls correctly. We'll also need to test with screen readers to make sure its working properly. You can read more at — https://www.accessibility-developer-guide.com/examples/sensible-aria-usage/expanded/
Nov 21 2019
Nov 19 2019
@Aklapper, my understanding is that the legal team doesn't have the resources to do #2 at the moment, and not having #1 is already causing some confusions (people emailing asking where the latest report is etc.)
@dbarratt you're right we should try to reduce the cognitive load on the user on this page, especially with the all the tables and highlights that they're about to see. I was thinking of a few ways to do this:
- Remove the placeholder text from the Reason input. Most people who come to this page know what they're doing and wouldn't need help filling this out. (per your comment T237034#5672684)
- Improve the text of the checkbox label so that we don't need the placeholder text any more. (I'll also explore the options that @Niharika pointed out in T237034#5672832)
- transparency.wikimedia.org (and all sub-paths) should redirect to wikimediafoundation.org/about/transparency/. This might result in some broken links but that is fine (technically not broken, just not as expected, everything should just redirect the the new page).
- Create a new sub-domain transparency-archive.wikimedia.org that will serve the old website. This will be a temporary measure till legal (with the help of devs) figures out a way to move all the historical data onto the new website. AFAIK the internal links on the old website should continue to work fine.
Nov 18 2019
@Tchanders, the default error state looks good, per your suggestion, let's keep it as is.
Oct 30 2019
Is this something that we get from a separate API call or do we have it as soon as the popup loads?
The WWT bar should be on top of all the content (including the Good Article badge). I think currently the user would be able to click on whatever is on top, since the badge doesn't completely hide the close button, and since it can be scrolled away, it doesn't affect functionality in any way.
When the WWT has failed to load it cant show the WWT popups. The reason we disable the links when WWT is active is because clicking them should open the WWT popup, if that is not the case, we shouldn't be disabling the links.
Oct 21 2019
Oct 16 2019
Yep, that was my hope too 😃. Anything that WWT does not work on, should have this effect — citations, images, tables, templates etc.
Oct 14 2019
Oct 7 2019
I think we can keep the placeholder as is, it is still helpful.
Oct 6 2019
Hey @ifried, this is what I had in mind for the Basic Information section. What do you think?
Oct 5 2019
Oct 3 2019
Thanks @Samwilson! Should we also add https://developer.chrome.com/webstore/images#promo?
I agree with the degrees of priority that @ifried shared 👍🏽. I do think that just a link on ChangeEmail might not be a good idea. This is because, when clicked by a user who didn't have an email address, they'll be taken back to Special:Preferences where this setting would still be disabled.
Based on the usability tests and feedback from the design team we've decided to keep this setting as the first checkbox in the Email Options section. We might add some text in the Basic Information section but from what I understand we'll have to check if that is possible.
Yep, based on our discussions:
When a user who doesn't have an email address sets one, or when someone wants to change their email address, they're taken to Special:ChangeEmail. On the Special:ChangeEmail page we'll add a section for Account recovery that explains how we use the email address for password recovery and introduce the PRU setting. The setting will be unchecked by default, unless it was previously checked by the user (for those who are changing their email address).
Oct 2 2019
Looks good 👍🏽
@MaxSem, yeah, password reset preference doesn't really explain much, and we don't call it that on the settings page either.
This is what I had in mind for the icon and promo image:
Sep 26 2019
Sep 25 2019
Sep 24 2019
Thanks for all the clarifications, @MusikAnimal!
Sep 23 2019
I am thinking we should clearly mark the parts of the page on which WhoWroteThat won't work (Templates, Images, Tables?). A way to do that would be to reduce their opacity which would make them look disabled. We can choose to have no mouse events on them so that people don't accidentally click on them and navigate away when they actually expected to see the popup.