I just want to stand on land.
- User Since
- Oct 9 2014, 1:53 AM (285 w, 3 d)
- IRC Nick
- LDAP User
- MediaWiki User
Fri, Mar 27
Thu, Mar 26
Tue, Mar 24
Tue, Mar 17
Mon, Mar 16
Thu, Mar 12
I am feeling a bit conflicted about this. I wanted the filtering action to feel snappy but with the full page refresh I don't think that'll happen at the moment. Auto-submitting on blur makes the interaction slightly faster, but confusing too.
What is the difference between the two? I was trying to get some data out of Turnilo but I could only find filtering through Revision Tags.
Wed, Mar 11
Mon, Mar 9
Adding a time filter to the the compare and especially timeline views might makes sense, but I am not sure if that should replace it in the initial form. My understanding is that CheckUsers always want to retrieve and log the minimum amount of information required to run the investigation. If we only provide this as a filter it would still get logged as if they saw the entire 90 days.
Thu, Mar 5
When the user clicks the Show all 3 IPs of this user button for the first record, User A is added as a target, the page refreshes and that button is disabled, correct? Is the button also disabled for the second record of User A?
Yes - we can disable the button for any users that are already targets in the query.
Got it. I think what you are proposing here is the same as what @Prtksxna had in mind. Let's go ahead with that.
Wed, Mar 4
Tue, Mar 3
Ignore sounds like a good option. I was also thinking about Hide or Don't show:
- Don't show me emails from this user
- Don't show me notifications from this user
I don't think any users have requested a custom time range till now (@Niharika correct me if I am wrong). We might not need the added complexity of Two DateTimeInputWidgets. Let's keep the duration field with the normal OOUI dropdown:
Feb 26 2020
Feb 25 2020
Feb 10 2020
Feb 7 2020
I've uploaded a set of plain screenshots to Google Drive.
Feb 6 2020
Jan 30 2020
Would we want to prioritise just the languages that WWT supports first?
- I don't think the groups need to be linked to anything. The documentation about these groups if we must, but I don't think that is necessary.
- Do we know the users' home wiki, like the one they signed up on? If yes then we can link to their Talk page from the user name.
- The wiki's names could link to their User page on that wiki.
Jan 29 2020
I had a few ideas around this.
Jan 23 2020
@ifried spotted a typo in one of the screenshots, here is the updated file.
Jan 22 2020
@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.
Jan 16 2020
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?
Jan 15 2020
Jan 14 2020
How about something like this:
Jan 6 2020
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
Jan 3 2020
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?
Dec 29 2019
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
Dec 28 2019
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)