Web designer at the Wikimedia Foundation
@Volker_E I had imagined something like this (perhaps with the list items rearranged):
Fri, Nov 8
I agree that we should increase to 12pt
Thu, Nov 7
Checked this out and it looks good. I've added T237019 as a subtask to this and think we should address the spacing issue there.
Wed, Nov 6
I agree with T235737#5639644. Here are two ways we could do that:
Tue, Nov 5
@Jdlrobson where are you seeing this? Here is what it looks like for me on Watchlist:
|iOS / Safari||Mac / Chrome||Android / Chrome|
There have been complaints about the size of links and how close together they are (see T237204) so theoretically this could help with that. Increasing the font-size seems worth considering as well.
Mon, Nov 4
If possible links to sections or footnotes within the same page should not open in a new tab.
@Masumrezarock100 thanks for creating this task
Thu, Oct 31
Wed, Oct 30
@nray and I just reviewed. Remaining items:
- move Add discussion button to top of topics list (or create a second button there)
- fix View as Wiki page button to bottom of viewport
- add Active discussions header to top of topics list
Looks good to me
Since we've already broken up the text-blog as it appears on desktop I think we should continue on and put the username on its own line
Tue, Oct 29
@Masumrezarock100 @Uostofchuodnego my apologies for the problematic SVG and the delay in responding (I was having a difficult time figuring out what the issue was). I think the issues are fixed now, can you please take a look at this SVG:
Mon, Oct 28
@Jdrewniak and I looked at this together — looks good. Any ideas how we want to do QA?
@Masumrezarock100 apologies here as well. I believe this is fixed now:
Wed, Oct 23
Noting that this issue is also present on Watchlist in Advanced mode (https://en.m.wikipedia.beta.wmflabs.org/wiki/Special:Watchlist?hidepreviousrevisions=1&hidecategorization=1&hideWikibase=1&limit=250&days=3&urlversion=2)
Tue, Oct 22
Mon, Oct 21
width = 77px
height = 22px
I've checked in with the design team about how we usually create these. Here is an updated SVG to use at the proper dimensions:
width = 118px
height = 22px
Thu, Oct 17
@Jdlrobson we discussed this yesterday in kickoff and identified it as a potential iceberg situation. It sounds like this is the right solution but it's not clear that it's worth taking on this work right now. Also to clarify, this task is about the container that notifications get rendered in. There are two other tasks about the styling of the notifications elements within that container (T225535 and T228819) which I've just made children of this task.
Wed, Oct 16
awesome, all set
@Jdrewniak it's kind of difficult to say which option is better until we see how long some of the strings are. If they are rarely long enough to warrant the truncation I think that works fine, however if the majority of the time they're getting truncated we should go with the underneath approach. Perhaps we move forward with the truncation approach for now and then revisit this down the road if we see that they're often being truncated?
Tue, Oct 15
checked on beta...
I've created tasks for the two current issues. Moving this along.
For clarification are we talking about this screen?
Great catch @Aklapper
T216789 suggests expanding all sections by default which adds a new dimension to how we go about solving the in-article navigation problem. Depending on how important we view that need it would be necessary to re-evaluate potential solutions here.
Oct 11 2019
I created a demo to explore the proposal of rendering all sections open by default, while providing a new table of contents mechanism: view demo here. Some tradeoffs worth considering:
Oct 9 2019
Oct 8 2019
Spoke with @Volker_E and we agreed to remove the flip/spin animation but keep the color change. Also noting that it would make sense to remove the spin animation from Vector as well for consistency, but that's not a blocker here.