Hi @Aklapper This is a feature request inside the global redesign that the Desktop Improvements is doing. As the redesign touches articles, it also touches Portals (namespace 100; see, for instance: https://en.wikipedia.org/wiki/Portal:Mathematics). And so, Portals are something that may also be subject of redesign, if possible out of the constraints of the fixed width that is actually designed for articles. Most of the portals have been designed to be full width, with lots of sections. When we see them in fixed-width, the design starts to be horrible.

I don't know if this can be discussed here as a task inside desktok improvements. Or it may be something that we can't talk about.

@Theklan: You can talk about anything but I still don't understand what this task is specifically (actionable) asking for.
What's the specific problem with https://en.wikipedia.org/wiki/Portal:Mathematics in new Vector?

The New Vector design has been thought only for articles, what is strange, because we have other things than articles. The Main page won't be redesigned. The categories and special pages won't be fixed width... and there's no proposal for portals. Portals are also a part of our encyclopedic content, and can't be left away.

the Portal:Mathematics (and any other) won't have a full width design because they are treated as articles. This will create burden for editors. And, as there's no proposal por portals, this is not an intended feature, but a bug. The portal will get larger in vertical, and divs will need to fit in a fixed width, with content more cramped.

@Theklan: What is the specific burden specifically for Portals? Could you please provide an example, preferably with screenshots? (Content being too wide is a common problem also on many other, non-Portal pages, e.g. when tables are (ab)used for layout purposes which don't fit mobile screens.) Thanks in advance.

Articles are text. Portals aren't. As the main page isn't.

@Theklan: Could you answer my questions, please? It's hard to discuss (or improve) anything when only you know which specific problems you refer to. Thanks.
(Articles aren't "text". They are also wide images or image galleries, tables, etc.)

I think I have answered before. But I'll try to explain it again:

• Articles are text-oriented, and changes in width there make things better: you can be sure that an image or a gallery will have an exact position when the width is fixed.
• Portals are not text-oriented: they usually have divs and blocks. This gets worse (i.e. larger in vertical) when the width is compressed. You can see it with any portal just switching the width. You can also see the difference for our education portal here: https://eu.wikipedia.org/w/index.php?title=Atari:Hezkuntza&oldid=7780826.
• The width may be fixed for portals and that may be the best design decision. But... should they? As it has been decided that the PAGEBANNER is part of the text content and not the page content, we are losing opportunities to THINK on how the portals should be. Is not about fixing something, is about CONSIDERING if we need to change the layout for portals or not. In the same way, it was decided NOT TO touch the categories and special pages, with are full width per design. Should portals behave as articles, should they behave as special pages or should they have an innovative design focused on what a portal is?

There are three options. I imagine that a redesign process (desktop-improvements is about that) has thought on all of these situations. The reality is that we can't know, because there's no proposal about portals. So, should we...

A) Let it as it is. It is great.
B) Change it to the New Vector. It is great.
C) Make something suitable for portals. It is great.

I also would like to understand why this: https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2018-20/Recommendations/Improve_User_Experience doesn't apply to the desktop improvements.

I will repeat it again, because it seems difficult to understand:

• We need better design. Desktop-improvements team is working on that. That's why I added the tag for desktop-improvements project. Because they are working on this
• Portals are part of our product. And there are no proposals to make them better.
• Desktop-improveents team should work on portals in any moment in the future. Not today, maybe. But portals need to have a design proposal.

Why? you ask.

Because our 2030 strategy talks about that. If we read the content, it says this:

Improving user experience can also help grow content, participation, and diversity. We need to encourage new members into our communities, considering that our projects rely on communities whose core editors — both in terms of contribution and functional roles — have not seen a lot of change in composition.

I'm not inventing it, this is not something I would personally want because I am some kind of narcissistic person. This is something that comes in our strategy, that is a fundamental need and is not being addressed.

As a volunteer, I would like to work on that, but it seems that if I make a proposal to work as a volunteer I am harassesd, silenced, my proposal is vetoed and closed as invalid, what I feel as something that breaks the UCoC. (Point 3.2.1) You are a staff member, you don't own the WMF, nor the volunteers, not even Phabricator. We, the volunteers, are those who may make proposals, work on our spare time developing them, and having those proposals closed or thrown away is completely disresptecful towards our volunteer time.

I repeat it: as a volunteer, I would like to work on that, but to make a proposal I need some privileges that I don't have, and only the desktop-improvement team has, actually. I don't really mind if there's no aim to improve this, because it is written in our *really short* 2030 strategy: "Interfaces designed intentionally for a wide range of devices so users can consume and contribute in diverse contexts."

Portals have been now redesigned as articles. Which they are not. If the current portals are (I cite your own words) "abus[ing] tables for non-tabular data content" and "That's a general anti-pattern to avoid, no matter how wide a page is rendered on some device" then, with even more reasons, there should be a proposal for an ideal portal, as there should be a proposal for an ideal Main Page.

Is this difficult to understand? Sorry, I can't explain it easier.

I'm sorry to see you two talking past one another, since you are both thoughtful and prolific 😂

TK: it can be confusing to follow you, since you're often writing about a few complementary ideas at once. Maybe... try a single very narrow topic per post? (I personally prefer your style of describing everything together, but it allows confusion to slip in at each step)
AK: of course you didn't mean it this way, but it did read to me at first like you were asking rhetorical questions to make TK repeat himself.

I see two issues here.

1. A bug: New Vector decreases the usefulness of full-width pages on desktop (Main Page, other portals), and can disrupt their design. Portals designed in this way need a way to force full-width to avoid disrupting their design (or need a clean alternative to switch to)
2. A feature request: matching AK's last rename of this issue: building a skeleton/template for portals in the NewV aesthetic (or having a portal layout as one of the standard demonstrations of a skin).

Example: the EU education portal, in old + new vector (at 1400px screen width)

{F35252815}

{F35252814}

I think the bug (which now has no ticket) is the more far-reaching issue here: when a default-skin update breaks some pages that people have spent a long time maintaining for a particular use case, what should the skin designers do? Are there a standard list of page-types that should be tested?

~ Each namespace? (main, user, project, file, help, category, portal, draft, mediawiki, template, timedtext, module, [event])
~ A range of Main Pages
~ A range of other pages?

Thanks @Sj. Indeed, it may be useful to narrow down to a bunch of ideas, but the stress that is generated by the harassment by the WMF staff every time a proposal is rised would make the narrowing a really horrible task.

Some of the ideas that are mentioned here come from other tickets. For example, the PAGEBANNER one comes from T292451, but I'm not allowed to decide which task is child/parent of another task (I have received a menace to be banned from Phabricator for doing that... it seems that saying that A is related to B is disruptive). Also, this task is completely related to T293405, but I can't group them in a general task, because, apparently, no one wants to solve both thigs together.

I think that proposing things to make our experience better is a good idea. Furthermore, if those changes have been decided in the Strategy discussions. But, as you can see, if you propose an idea to explore, you can get an answer like "Please either stop edit-warring on this task's status if you would like to continue to be active in Phabricator" once someone decides that this idea can't be even considered. Is not the worst way of burning volunteers, but I would need to think on how to make the experience worse.

In T303258#8013497, @Theklan wrote:

if you propose an idea to explore, you can get an answer like "Please either stop edit-warring on this task's status if you would like to continue to be active in Phabricator" once someone decides that this idea can't be even considered.

@Theklan: That's quite a misinterpretation as can be seen by anyone reading previous comments. You could avoid such situations by not repeatedly ignoring questions.