Topic on Project:Village Pump

Current proposal: Project:Side bar redesign 2022

I propose to change some items from the crowded MediaWiki:Sidebar on mediawiki.org. Because it's crowded.

• Remove "Main page" - already reachable by clicking the logo above.
• Rename "Get MediaWiki" to "Install MediaWiki" and link to Manual:Installing MediaWiki instead which covers all steps (including downloading and additional extensions).
• Remove "Get extensions" - is an overwhelming unhelpful page and installing extensions is another optional part of Manual:Installing MediaWiki already.
• Remove "Tech blog" - already linked from Communication.
• Add "Recent news" - linking to News.

• Rename "Communication" to "Get help and support".
• Remove "Support desk" - linked as the first item from Communication already.

• Remove "Code statistics" - not a common enough use case to justify having this clutter the sidebar.

• Remove "Community portal" - all its content is already covered by several other sidebar items.
• Remove "Translate content" - linked How to contribute already links to Special:LanguageStats.

• Remove "Create a book" - it is uncommon and disabled functionality.
• Remove "Printable version" - already available via any browser by selecting "File 🡒 Print" or pressing Ctrl+P in the browser.

Thoughts?

That looks good for me.

The items "Create a book" and "Printable version" are not editable from MediaWiki:Sidebar. The first one is provided by an extension that would need to be disabled or uninstalled for this wiki. The second one is a core MediaWiki feature that has no option to disable AFAIK.

Seems good. If you rename "Communication" to "Get help and support" I would also suggest renaming "User help" to something else to reduce confusion. btw "User help" also has what I guess is a truncated mouseover ("The place to find out") which should either be fixed or removed.

I think this is a good idea. I agree with Clump that renaming "User help" would be useful too. In Dutch that is simply called "Help", so, looking at the title on Help:Contents, "MediaWiki.org help pages" perhaps?

Thanks, that makes sense, yes. Probably "User help" should become "User manual" to be aligned with "Technical manual" (though naming these things is very inconsistent across wiki pages).

Regarding the tooltip, that's literally what's in MediaWiki Core's languages/i18n/en.json file for tooltip-n-help: "The place to find out".

I am always happy with focussing to important things. Many wikis do offer a confusing bunch of very very interesting links, in the end nothing will be found by newbies any more. Go ahead.

For those confused like I was, "User help" is MediaWiki:Help which is over-ridden in English, Farsi, Russian, and Polish, but not other languages where it's just "Help" like on other wikis.

Changed in 2007, presumably to differentiate it from help with installing MW.

The only one I would disagree with is "Main Page" I unfortunately deal with too many sites & systems where the logo either doesn't go back to the main page or goes somewhere unexpected, so I always try to hunt out a main page type link on systems i'm not familiar with.

Meanwhile I examined all links in detail.

• Positively, the question is which links are important for a less experienced user when visiting any page anywhere.
• Judging this in context of a software development wiki, which is only consumed by outside readers. They are not supposed to contribute content about their city or favoured music right now, but learning from manuals and documentation pages.
• Other than with other wikis, this entire wiki is a manual and pile of help pages. On a wikipedia a help page is describing means to achieve something in content but here it is the main purpose itself.

Logo / Main page

Explicit textual link towards mw: is okay.

Many websites do offer a link to their start page this way, but not every user did learn already to try that.

From the view of accessibility this link is appearing with link description but no link title. That does mean: Blind users are in advantage against those who can see the icon but would not guess the effect.

MAKE EXPLICIT

Get MediaWiki

Get extensions

Not necessary to get this access on every page.

From start page there is a prominent box for this branch.

Not helpful on reading a manual page.

REMOVE

Tech blog

Interesting detail for experts. Nice to have.

Leaving the current project. Unexpected behaviour. Confusing.

That’s what a community portal is for.

There is more space to explain to what kind of things I will be transferred to.

REMOVE

Contribute

Advertise volunteer staff recruiting.

Very important to remind everywhere. Hope for the best.

KEEP

User help

Technical manual

Crucial navigation.

KEEP

Support desk

Invites me to ask for support.

It is not obvious to me that there is a responding help desk anywhere.

KEEP

Communication

Crucial navigation to support.

May be renamed to a more intuitive title.

KEEP

Developer portal

Shifting me to another website. Confusing.

Avoid that.

Linked by a particular box on general start page.

No need to visit that to readers of a manual.

REMOVE

Code statistics

One of many many interesting things.

Nice to have for some insiders.

Does not tell anything to readers of a manual.

May be accessible from any insider navigation.

REMOVE

Community portal

Important navigation access for insiders.

Should bundle all insider links, while particular expert stuff can be removed from side bar. Shifting to expert mode.

KEEP

Recent changes

Interesting feature for content wikis like a wikipedia.

Pointless for readers of a manual.

Supervising will be done by a few insiders. Such RC people will find their way on every wiki.

REMOVE

Translate content

Needs special experience, permissions, training.

Might be made visible for registered users.

Should be hidden for anonymous.

CSS rule for hiding (MediaWiki:Group-user.css) see en:MediaWiki:Group-user.css

Is there a group assignment for translating accounts? Not my business.

Random page

Interesting feature for content wikis like a wikipedia.

Pointless for this wiki.

It might be nice to experience how some random encyclopedic articles look like, but not meaningful how a random page about software issues will appear.

Here users are looking for something specific, not to get any fun fact on some technical feature. A random encyclopedic article might bewitch me.

REMOVE

Village pump

Important for all visitors, direct access meaningful. Everybody who knows this term might join that.

Could be more close to item “Community portal” and is actually a shortcut for a community issue.

KEEP

Sandbox

Important for a wiki with one major purpose to explain wikisyntax.

Should enable everybody to test any wikisyntax manual page examples and their variants.

KEEP

What links here

Navigation to find related pages if the current page did not satisfy.

Helpful.

KEEP

Related changes

Interesting feature for content wikis like a wikipedia.

Similar issue to Recent Changes.

Pointless for readers of a manual.

Supervising will be done by a few insiders. Such RC/RC people will find their way on every wiki.

REMOVE

Upload file

Interesting feature for content wikis like a wikipedia, where I could upload a photograph of my town hall.

Visitors are not supposed to contribute a lot of content here, nor uploading many images.

Available via Special Pages.

Regulars will manage that anyway.

REMOVE

Special pages

Important navigation access to >100 functionalities.

KEEP

PermaLink

Generally important.

KEEP

Page information

Generally meaningful.

KEEP

Cite this page

Well, yes, okay, maybe.

Quite a lot of redlinks which should be diverted to enWP.

On BibTeX entry please obey this change respectively, which avoids that every citation of anything from any wiki will get the identical identifier. This needs to be unique and must not be wiki:xxx everywhere. I asked for that modification. MediaWiki:{{REVISIONID}}, is fine.

KEEP

Wikidata item

Generally meaningful navigation. See what happens. Perhaps connected to a wikipedia in certain language.

KEEP

Create a book

Download as PDF

Printable version

Does not work, or is not meaningful.

We are providing dynamic manuals which might change every hour, not static books to be archived in book shelves.

Every browser has a function to download every web page if needed, including CSS and JS.

REMOVE

In other projects

Helpful to find the similar page in a wikipedia, in certain language, on Commons or whatever.

KEEP

Even if not configurable by system message or Local.php, undesired items may be hidden via site CSS for all users, or for anonymous.

• Some of the insider links could be limited to login.

@AKlapper (WMF) Seems good but please do not remove Main Page item.

I think this would be a lot more manageable as a a policy page with discussions of overall of strategy and potentially individual discussions per item being changed, rather than a mass change of dozens of different directions.

I really like the broad plan. I agree with most of the proposals and earlier comments.

I recommend leaving in "Translate content" as I believe that is a primary link used by some of our most active editors, to access the aggregate-groups they want to prioritize each day. I.e. Similar to Recent Changes as a core workflow destination (which is my most-used link on many wikis!).

I agree with leaving in "Main page", per comments above.

• I agree that a separate project page Project:Portal UI improvement 2022 would allow a more structured discussion on particular items and agreements, and a better introduction including goals.
• There should be made use of CSS hiding for all, then unhiding at least for registered visitors of some internal issues.
  • Note that SUL wikipedians looking for a software description are registered users but not necessarily software experts who are able to contribute nor getting involved in page editing and translations and surveillance.
  • Recent changes are one click away at Special:SpecialPages #Recent changes and logs. The Community portal should offer structured access to many many very interesting links supposed to be used by experts.
  • Consider an Opt-In CSS gadget making thinks visible by selector translating- or another one for content contributors.

To clarify, I myself do not plan to review/edit Project:Help (if that's meant by Project:Portal UI improvement 2022?) but only what's in MediaWiki:Sidebar. If anyone thinks some project page might help in some way, please feel free to create.

Trying to summarize the proposal which adds "mw-news", renames "User help" to "User manual", renames "Communication" to "Get help and support", and removes numerous items not listed anymore below:

* navigation
** mw-mainpage-url|mainpage-description
** mw-news-url|mw-news
** Special:MyLanguage/How to contribute|mw-contribute

* SEARCH

* support
** Special:MyLanguage/Help:Contents|help
** mw-faq-url|mw-faq
** mw-manual-url|mw-manual
** Special:MyLanguage/Communication|mw-communication

* MediaWiki.org
** mw-portal-url|portal
** mw-discussion-url|mw-discussion
** Project:Sandbox|Sandboxlink-portlet-label

If we add back in these 2 lines, under ** mw-portal-url|portal, I'd support.

** recentchanges-url|recentchanges
** Special:LanguageStats|mw-translate

Because: RC is in the sidebar of every Wikimedia wiki, and is a core workflow for some site maintainers. And mw-translate per my comment above.

I'd also like Recent Changes to stay; I use this very frequently in RC patrolling. It is especially useful on non-MobileFrontend mobile.

Alright, that makes the proposal:

* navigation
** mw-mainpage-url|mainpage-description
** mw-news-url|mw-news
** Special:MyLanguage/How to contribute|mw-contribute

* SEARCH

* support
** Special:MyLanguage/Help:Contents|help
** mw-faq-url|mw-faq
** mw-manual-url|mw-manual
** Special:MyLanguage/Communication|mw-communication

* MediaWiki.org
** mw-portal-url|portal
** recentchanges-url|recentchanges
** Special:LanguageStats|mw-translate
** mw-discussion-url|mw-discussion
** Project:Sandbox|Sandboxlink-portlet-label

Again, please split this single thread into a proper page with multiple discussions for each suggestion, so they can be individually commented on and resolved.

I'm afraid I have no idea how to do that, sorry.

1. Make a page, e.g. Project:Side bar redesign 2022
2. Explain the overall set of changes you propose and why
3. Let people have talk page threads per idea.

I don't have time for that. I neither see an advantage in discussing single disconnected lines instead of the entirety, nor seems to be consensus that such a page would help much.

I won't stop anyone from doing so though if they are interested. :)

Just do it if you want it, please. Thanks in advance.

I'm confused. You're spending a huge amount of time in this discussion with no over-arching justification, merging multiple concerns together, and acting like repeated calls from people to properly discuss this would take too much time?

I'm also confused as I do not think that I have spent a huge amount of time in this discussion. My perception is that there is pretty much consensus, apart from discussing a small number of individual items.

If there are repeated calls to "properly discuss" (implying that this is not a proper discussion?), then please feel free to "properly discuss" - I'm not stopping anyone from doing so. :)

He thinks that a regular forum page with some threads in chapters on groups of items and a common understanding of goals and UI approach would be more helpful. May be one page with sections, or subpages. However, I regard a common wikitext page more comprehensive.

Regarding recentchanges I stick to my opinion that this should be visible for at least login users, but not meaningful and overload for anonymous searchers. CSS permits hiding things by user group. The argument “on every Wikimedia Wiki” is ignoring that on a Wikipedia everybody may contribute by details on his preferred movie or his city, but here there are few contributors and a large listening audience who better should not try to edit translatable software documentations.

There is a lack of common understanding, goals and deriving an approach.

• This needs to be agreed first.
• From a common path it is easier to judge on particular items.

I do not know if a "if logged in" condition to show items or not is possible. I am proposing to change some items by editing MediaWiki:Sidebar. I am not proposing software changes which I consider out of scope for this discussion.

I did mention it above via en:MediaWiki:Group-user.css

• Unfortunately encyclopedic Wikipedia authors are carrying their SUL when they are jumping from one WMF wiki to another, but those are not necessarily software developers.

BTW, my answer one contribution before received a kind of edit conflict with Jdforrester who answered your question as well.

I do think that this single thread conversation format is not applicable to a complex issue:

• What are the overall goals of this UI strategy? Which audience is addressed? Experts and developers, or people from outside looking for information? Who is able to contribute?
  • There are thousands of links which some people regard as helpful to be present everywhere.
  • It is very confusing to be overwhelmed by a lot of links with titles which are not obvious to those who are not experts.
• Which links are really needed in section top, support, development, MW.org, tools, print/export, and are all these groups really needed?

Makes sense. I don't plan to pursue this anymore due to lack of time.

I've created the requested overview page, in a format that I think is relatively clear. Plus a section of "Next steps" at the bottom.

• Project:Side bar redesign 2022

Please tweak/fix/clarify/improve that page, so that it is ready to be mentioned elsewhere. (Thank you!)

Then in a few days we could notify elsewhere (as needed, e.g. MediaWiki talk:Sidebar at minimum), and then continue to discuss/support/object (at the Project talkpage there).

Overall: I recommend keeping this as simple as possible (i.e. not pursuing ideas about showing different links for logged-in/out users, and not trying to hide default "Tools"/"Print" links), in order to increase the likelihood of fast consensus and actual improvements.

Hope that helps.

Looks good to me? I like how clean that page is and explains the individual changes neatly. As far as I'm concerned, it's ready to be announced.

The second step is more clear now, but the first step is still missing and not yet mentioned nor discussed.

Who is the audience of this site?

• Which experience or background have visitors of this site?
• Are there differences against a Wikipedia?
• Is every reader of this site supposed to translate pages, or to add software documentations in the same way as all readers of a Wikipedia are called to add details regarding their village, upload photos of their railway station or add other interesting things?
• Is a person with a SUL registration, e.g. a Wikisource author, automatically an experienced member of the software development community?
• In other words: What is actually the target, who with which needs shall be guided by this portal navigation?

First the target, the characteristics of the addressees need an agreement.

• Then it may be derived which links, groups etc. are needed to reach exactly this target.
• Otherwise it is pointless to discuss which links are really required if it is not clear what the purpose of this sidebar is.

I agree that doing this at an ideal level would include a detailed analysis of the audiences (like WMCS's simple version, or going even deeper with interviews and metrics), and of more complex technical options (like you've suggested), and of pageviews, and beyond… (deep discussions about the nature of sidebars-as-UI, and the complexities of skins, and other areas of valid & subjective disagreement!). But I don't think anyone has the time/energy to prioritize that, at the moment.

Instead, the current proposal gets us a step towards "better than it was". It's not perfect, but like most wiki edits it just needs to be an improvement. As the old saying goes, w:perfect is the enemy of good. Maybe something more detailed can be done in the future.

The proposed version is a clear improvement over the current, and the arguments given all seem quite clear and valid: please go ahead with the next steps.

I've noted it at MediaWiki talk:Sidebar. If anyone has further places they think it ought to be mentioned, please do so.

Otherwise, let's discuss any final tweaks (perhaps at Project talk:Side bar redesign 2022?).

If there are no unresolved concerns in 2 weeks, I think it could be boldly updated.