I just want to stand on land.
- User Since
- Oct 9 2014, 1:53 AM (265 w, 6 d)
- IRC Nick
- LDAP User
- MediaWiki User
Wed, Oct 30
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.
Mon, Oct 21
Wed, Oct 16
Yep, that was my hope too 😃. Anything that WWT does not work on, should have this effect — citations, images, tables, templates etc.
Mon, Oct 14
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.
Sep 17 2019
So if I understand correctly, the users who haven't confirmed their email addresses see the following message:
Sep 16 2019
I am not familiar with some of the standards around the current NPP design, so, I had two queries:
- What is the difference between the red text that shows up after the title like "No Citations", "Orphan" etc. and Potential issues like 'Copyvio'? I don't understand the conceptual difference between the two.
- I see a few different icons before the title: , , . Should this change if the username is in the article?
Ah, that makes sense. I think lets keep it as is for now and figure out what needs to be done once we have results back from the usability tests.
The text wrapping looks good, I think we can go ahead with it. Thanks for posting the screenshot 👍🏽
Sep 11 2019
Sep 10 2019
Sep 9 2019
@cscott would you be able cut a new release? Happy to do it myself if you can add me on NPM.
- Form states
The way to enable/disable this preference would be a checkbox in Special:Preferences. It'll only show up if the user has confirmed their email. I can think of two places where this setting could be:
Given that the edit summary could in some cases could load very fast (less than 100ms) we don't want a case where we flash the animation for a very small amount of time. I am taking some inspiration from the font-display browser behavior here.
@Samwilson, I think it would also be alright to increase the width of the pop-up enough to fit IPv6 addresses. There are currently two popups sizes in the Zeplin—250px and 320px. Which one is being used screenshot above?
The WhoColor tool currently uses the tabs on top-right, and is represented as a text item (in the same hierarchy as Read and Edit). As you mentioned, we have a few options on where to put this tool:
- Top-left tabs (Article | Talk | Who Wrote That)
- Top-right text tabs (Read | Edit | View History | Who Wrote That)
- Top-right icon tabs (Star icon | WWT icon)
- Tools sidebar
- User menu on the top right (I don't really think this is an option, but still noting it here)
Here is the example I had in mind — https://en.wikipedia.org/wiki/User:Prtksxna/citation-test.:
Sep 5 2019
Should we regenerate the OOjs documentation to test before closing this task?
@ifried, I agree. Always having a full stop . would also be better when there is no edit summary to show.
Sep 4 2019
Aug 29 2019
Aug 27 2019
If the edit summary is the only thing that we'll be waiting to load we could use a content placeholder with an animation, and then switch it out with the summary once we have it - https://codepen.io/prtksxna/pen/OJLmVXZ (data will load after 3 seconds)
Aug 26 2019
Yeah, so the current loading state doesn't have the close icon. If we suspect that the tool can be in this mode longer than a few seconds we should definitely add a close button here as well.
So, will we need both partial and full loading states? What all would have already loaded in the partial state?
Ooh, thanks for this @MaxSem 🤩So the proportion of no(~¼), unconfirmed(~½), and confirmed(~¼) emails looks something like this:
Will the average (or median) be calculated since the page was created? Or will it be the average of that week or something?
Aug 21 2019
Aug 20 2019
Aug 19 2019
I can see how in its current form the target can be confusing. I see two main reasons for this:
- The hover state only changes the background color and the change isn't drastic so is easily missable.
- Since the button for the diff (the area we clicked to open the diff) and the revision target are touching each other its not clear if they're connected or separated. I clicked on it a bunch of times accidentally thinking that it'd close the diff.
Aug 16 2019
@ifried, does this still need any design work?
Aug 14 2019
@MusikAnimal, I didn't know about preload parameters, yeah that is exactly the kind of thing I was hoping for.
Aug 13 2019
|Issue||Time it'll take to resolve||Message|
|Page is too long, time out||Seconds||Something went wrong, Try refreshing the page|
|Page not yet in WikiWho database||Hours||We are gathering the data for this page now. Check back in a few hours.|
|Too many requests||Minutes||We weren't able to make this request. Try again in a few minutes|
Aug 12 2019
Thanks for all this information, @MusikAnimal 🤩
Aug 8 2019
Aug 2 2019
I don't really need this any more, so no need to help me debug 😊
Happy to provide more info if you'd like though.
Yup, the .env file is correct, and I am not trying to log in. When I try to navigate to - http://localhost:8042/File:Speech_bubbles.svg I get an error. Here is the stack trace: