Talk:MediaWiki/Homepage improvements 2018

• "Get extensions" links to which does not even explain how to get/download them?
• "Tech blog" - why is this so relevant that it is in the top box?
• "User help" - it is to read and not to ask, but that's not clear from the wording (manual? documentation?)
• "FAQ" - for who, but see bullet point above
• "Communication" - why is this relevant and for who?
• "Wikimedia technology" and "Wikimedia audiences" are some WMF departments, but that's not clear and why should people care?
• "Community portal" - what's that and why should I go there? It seems to link to Project:Help and that feels different than its wording
• "Current issues" - seems to be about the mediawiki.org website only but not clear from the name
• Why are "Recent Changes", "Translate content", "Random page", "Sandbox" not under "Tools" where "Related changes" or "Cite this page" is?

I agree with most of these a bit, but at least some of them are fundamental ways that MediaWiki works, e.g.:

Why are "Recent Changes", "Translate content", "Random page", "Sandbox" not under "Tools" where "Related changes" or "Cite this page" is?

The first set are page-invariant, the second set are related to the page you're seeing it from.

(Also, previous discussion about the sidebar took place at Project:Current issues; not sure where best to talk about changing this?)

In a lot of those cases better content does not exist and would have to be written first. (As an aside, our top pages could use a little more design. Compare the Drupal or WordPress download page with the Get MediaWiki link, for example - and that's one of our better looking landing pages.)

• "Get extensions" is a very basic topic to link to, but the page is not very useful. It is the entry point of a category system that's largely based on facets irrelevant to the reader (Extensions by hook usage? Extensions by visual element‎? etc), does not explain how to evaluate extensions, or how to install them, does not provide any search functionality, does not even mention skins. So that would have to be rewritten.
• IMO get rid of the blog link, it has little useful content. (Most of our blogging happens in Phabricator anyway.)
• The Support section lacks clear audience designations. IMO it should be split up and consolidated with the Development section so we have the three audience groups (wiki editors, wiki owners, developers).
  • Then again, does it sense to have user (wiki editor) help there? I don't imagine users of a random MediaWiki instance come here to find out how to use it...
  • Split "Technical manual" (AKA Manual:Contents) into a separate site admin manual and developer manual. Merge the FAQ (which is really a site admin FAQ) into the former, I don't think it needs a sidebar entry.
  • Support desk and Communication is for all audiences so maybe move it up to. the top.
• The "Code repository" link should probably go to a wiki page that explains code can be found at Gerit and/or Diffusion and/or Github.
• Instead of "Wikimedia technology" and "Wikimedia audiences" (extra confusing with the lowercase) there should be a link about organizations (with at least the a mention of other orgs like WMDE, and some generic info on movement structure). Also that site-hopping header those pages have is super confusing.
• The MediaWiki.org section is IMO largely OK - it is reasonably clear that those links are for contributors of this site, and those links are mostly the ones wiki editors would expect to see there (not sure how useful the translation stats are, but then I don't translate much). Maybe something like "This wiki" would be a clearer name?

Since you asked for feedback: overall I think the data layout right mostly now makes sense. There are six basic components (which I can paraphrase as Potential users, Users, Admins, Developers, Other contributors and News), and each one seems to have between three and eight links - that seems like a reasonable amount of information and complexity for the main page.

I'm glad you didn't link to User hub, Enterprise hub or Academic hub - those are three (in my opinion) mostly useless pages, in increasing order of uselessness.

I also agree that it makes sense to use the existing pages on the wiki, instead of trying to engineer new pages, in order to keep this project manageable. (Though the existing pages could use a lot of work - for example, there doesn't seem to be any rhyme or reason to whether each page is contained in the Help, Manual or main namespaces. But one thing at a time.)

I do have quibbles with some of the choices:

• Maybe the first section should be considered an "About" section rather than just for potential users? That would allow the FAQ page to be linked from there instead of from the "Administrators" section, where it doesn't really belong.
• I don't think it makes sense to link to the "Weekly Tech News" from the front page - it's of minimal interest to anyone who would be going to the front page.

Those are the only things that really jump out at me, though.

Thanks for the feedback. Very appreciated. :) Good points about Tech News (it's linked under Ambassadors on How to contribute already) and making the first section an "About" section.

Regarding the FAQ page, I'd keep it where it is. Though it's horrible in itself. It mixes the very basics ("What's MediaWiki") with very specific technical problems (which might not even be friendly asked) and needs a lot of restructuring in itself. I'm not sure yet how to tackle that though. :-/

A late comment about the very first header on the page ("MediaWiki is a collaboration and documentation platform brought to you by a vibrant community.").

Placement: Do we want to show this header as if it was a normal wikipage H1 header? (Currently that is hidden via .page-MediaWiki .firstHeading {display: none;} in MediaWiki:Gadget-site.css). If yes, then that will alter the design slightly, by placing the image slightly lower on the page (level with the top of the first paragraph).

Length: We might want to shorten the text of the header, as 95 characters is quite long. We almost certainly want to remove the fullstop.

If I do not use the .page-MediaWiki class (I think I don't) for that line which is currently a h2, would that work to get displayed? (It's maybe a bit too early for me to understand exactly what's the current situation, sorry.)

I'm not sure. I would guess it's automatically applied. Sorry :(

Ah. It's fine that the "Mediawiki" h1 line is hidden. Thanks for pointing out more implementation details to be aware of! :)

The new design is fine with me, slim, very clear, cleaned up, silent, modest.

One suggestion: The photo of the community crowd might be wrapped into

<div style="float:right; margin:...;" aria-hidden="true" role="presentation">

Reason: For blind people the photo does not tell anything; should be suppressed entirely to avoid confusion.

The same (by <span>) goes for the OOui icons in the upper left corners of the boxes, and in later page navigation. That is visual information which would be explained to blind visitors, but has no other meaning than the text aside. However, the explanation of the image could sound very strange.

@PerfektesChaos: Thanks a lot, this is very helpful!

All added in , except for the float:right for the photo. It would not work in Modern and Monobook skins on smaller screen widths (e.g. 500px) as the photo will cover some letters in the first line, and in Timeless skin it is even worse as it only shows two or three letters per line, so I cannot do that.

...and after adding that I do not see any aria-hidden left in the rendered source code of the HTML page.

aria-hidden is queued at phab:T204618.

Both role and aria-hidden should have similar effect but slightly different semantics:

• role says: omit, since only decorative.
• aria-hidden says: strip off, since distracting; keep on main track, suppress the hint of the day and the Did you know? box and focus attention on major purpose of the page.

To make it foolproof both properties are provided; at least one should be recognized.

I will have a closer look tonight at the skin problems; there are two methods for layout on right edge, by wikisyntax and by HTML. One should serve all.

Top navigation box has been removed in final proposal

Currently there is a list of five overall links above the three audience boxes. Basically this is fine, but should be reduced:

About this site

Fine

About MediaWiki

Fine

Download

Move into operating and installation landing page.

Not needed for page content editor, confusing.

Help and support

Fine

Contribute

Move into programmer’s landing page.

Not needed for page content editor nor site operator, confusing.

I doubt that advertising here will make article authors to software developers, at least not by placing a prominent link which distracts focus.

A general remark, perhaps in the footer region of the front page, might annotate that volunteers and professionals are developing MediaWiki and that everybody is invited to support. But that needs explanation and is not well done by a link with one word.

Other contributions are not at programming level, but translation, documentation, suggestions. This may be done by everybody even without technical skills.

In the footer region of every landing page and front page it might be mentioned that such non technical contributions are desired (naturally by sharing a template). However, it is not sufficient to say only “Contribute” since nobody will follow such link, expecting coding experience required.

The current page How to contribute lists many different ways to get involved. They are not only for programmers; we also have translators or documentation writers in our community. Maybe "Get involved" could be another phrase instead of "Contribute"?

Regarding the overall entry points, I'm not sure I would call them "entry points". Again it boils down to which audiences we try to target.

While I do feel that the single word Contribute is sufficient to bring in proper folks, perhaps we could may be change it to "Volunteer" ?

Also it may not be best to move this section in programmer's landing page. Moving it into programmer's landing page would mean it is meant only for developers?

Given that one audience that mediawiki.org is for are professional 3-rd party developers (examples which come to my mind Semantic MediaWiki or BlueSpice which just saw its 3.0 release), the term "Volunteer" feels ambiguous to me. I might volunteer my time, but I might not be a volunteer working on MediaWiki related things. :-/

Updated box headers to describe actions instead of audiences in content phase; icons kept but updated in design phase

The three boxes per audience are fine, but their purpose should be made more obvious.

• The audience and their field of interest should be addressed directly in the title.
• Example: Current title “System Administration”
  • That should be replaced by “Install & configure MediaWiki” which is currently in second position only, but explains the path much better.
  • “System Administration” might be a correct summary, but not in the perspective of new visitors.
• Example: Current title “Using MediaWiki”
  • That should be replaced by something like “Content page reading, editing and maintaining”
  • This tells me much more what “using” shall mean.

The gimmick icons in the boxes might be kept.

• They give orientation for users who were used to them over years.
• Images give a better feeling when opening a page rather than a lot of text only.
• Currently it looks like the images are just decorative. It is not intuitive that they are linked to the current hub pages, which should be the major navigation place for the audience. Therefore the current hub might be never found.
• The expection by clicking on images may be to reach the file description page, explaining author and license of the image.
• The image and the box title bar should have identical link target.
• The images should be hidden from (smaller) mobile devices and blind people (role="presentation"). If not the only link to the audience landing page, but only additionally linked, they may be omitted.
• The same images (which might be exchanged by more intuitive ones) could serve as navigation eye catchers on the specific landing pages. It seems this is intended right now on the hub pages, but that is not intuitive now and I detected it after detailed user guidance analysis only.

The prominent link (entire title?) should be the central audience landing page.

• Some very important entry points might be listed below, as of today, serving as a shortcut to bypass the landing page.

In the current stage we are after defining the audiences that we should target on the front page. I agree names such as "Using MediaWiki" are not helpful, and having activity-based headers instead of role-based headers sounds like a good idea (or maybe both is possible, depends on the layout to be defined later).

Discussing the design is a later separate phase of the process, would be great if you could bring that up in that phase. Thanks!

Not aware of any existing page to potentially link from the frontpage, hence closing

This may be out of scope, but I'll throw it out here. I run several wikis, and the social engineering side of turning readers into lurkers and then maybe editors and administrators is a topic I find interesting. Most of this would be generally relevant to users of just about any wiki, not just a mediawiki, so maybe mediawiki.org is not the place for it. And maybe there is no content on mediawiki.org about it that could be linked to. But if it is in scope, where would it fit in with this update of the main page?

Does content on mediawiki.org exist about this topic, to potentially link to from the frontpage? If so, links welcome.

Added a sentence explaining what problems MediaWiki is supposed to solve

I really like the new layout/design! I think it looks much more modern and attractive. My only feedback is that the header section should also state the problems that MediaWiki solves for the user (if we know this). In other words, If MediaWiki is the solution, then what is the problem? What does this software allow me to do that I wasn't able to do before? Does it do something for me personally or something for the business I work for? What do I need to do to solve my problem?

Doesn't the following page linked by the phrase "if MediaWiki is right for you" in the starting paragraph, answer that question?

Manual:Deciding_whether_to_use_a_wiki_as_your_website_type]

@DBarratt (WMF) Thanks for the comment! Do you have a proposal how that could be summarized? (Looking at the current front page I don't see any text either which explains this and could be re-used...)

@AKlapper (WMF) @Kaartic Hmm, well I'm not entirely sure what the problem is we are solving, but I can take a guess. I think we should do research and discover who our customer is, but as a guess, what if we changed the intro from this:

==MediaWiki is a collaboration and documentation platform brought to you by a vibrant community.==

The MediaWiki software is used by tens of thousands of websites and thousands of companies and organizations. It powers Wikipedia and also this website. It's powerful, multilingual, free and open, extensible, customizable, reliable, and free of charge. Find out more and if MediaWiki is right for you.

to something like this:

MediaWiki helps your organization collect and disseminate current, accurate knowledge to your employees, customers, and the world. The MediaWiki software is used by tens of thousands of websites and thousands of companies and organizations. It powers Wikipedia and also this website. It's powerful, multilingual, free and open, extensible, customizable, reliable, and free of charge. Find out more and if MediaWiki is right for you.

And also I think the heading is long and not really necessary. Basically the "problem" (as I see it) is that companies or organizations (like Wikimedia) don't have a way to collect and disseminate current, accurate knowledge to the people who need it. Adding this first sentence acknowledges what MediaWiki can do for them to solve that problem.

Thanks! Does "disseminate" mean "make available"? (I'm afraid I need simpler language.) How does MediaWiki itself make knowledge "accurate" and "current"? Isn't that up to whoever provides that knowledge? Could I replace "employees, customers, and the world" by "people"?

It means to "spread". I actually am stealing this from the Wikimedia Foundation's Mission (which, I think is easy enough to understand?). It doesn't do this on it's own, it only helps your organization do this. Just like how Wikipedia itself doesn't provide a free encyclopedia, it only provides a place to have that encyclopedia. I would assume that your organization would have that knowledge (or know how to acquire that knowledge). It's not like you can just setup a wiki and expect it to be filled with knowledge, you have to know who can provide that knowledge (and train them how to use a wiki for that matter)..

Umm, I think "your employees, customers, and the world" is correct (this is the way Wikimedia Foundation uses wikis). I mean it's really trying to say "the people who need it" but that doesn't make any sense to me... who are those people? Well it's the people who work for you, who "buy" from you, or (in the case of Wikipedia) anyone else who wants this knowledge. There might be a better way to say this, but I'm not sure what it would look like.

Again, this would be easier with more research, I'm taking this from MediaWiki's biggest "customer".

@AKlapper (WMF) To put it another way, if Katherine (or anyone on the C-Team) were to come to the site, it would read:

MediaWiki helps [Wikimedia Foundation] collect and disseminate current, accurate knowledge to [its] employees, [donors], and the world.

Which sounds about right to me and, as far as I can tell, is the problem that is being solved. The problem is "My organization needs help collecting and disseminating current, accurate knowledge." Again, this is a guess, I would recommend doing more research to determine if this is the case for all/most of our current & potential "customers".

Thanks for the explanation! I prefer simple English, so I went for "MediaWiki helps you collect and organize knowledge and make it available to people."

min-width of the boxes reduced so they fit on a screen with 320px width

On quick overview, the redesign looks very nice and very minimal and modern-ish. Great improvement!

I use a small screen device (320x452 as reported by howbigismybrowser.com). I think the layout could use some improvements to make it correctly fit in a single page. Currently, some screen shots of how it looks:

• Screen shot 1
• Screen shot 2
• Screen shot 3

I think a little tweak to the layout could make it work well for that resolution too. As far as I know, a width of 320 is a standard one. So, it would be nice to make it work well for it. FWIW, the current mediawiki homepage works well for the same resolution (320x452) ;-)

@Kaartic, thanks for taking a look and testing!

I was wondering how far to go "down" when it comes to screen width. Thanks for answering that question! :D I've changed the minimum width of the boxes in , could you please try again?

It looks great! Awesome.

Modulo the small issues with "page issues" template. That's a different issue, though ;-)

Page issue template icon overlaps the text.

@Kaartic: Glad it works and thanks for testing! It's not a Page Issue Template but the {{Draft}} Template, and I'm afraid fixing that is out of scope as it will go away once the proposal goes live. :)

For the sake of completeness here are the screen shots after the change:

• Looks great shot 1
• Looks great shot 2
• Looks great shot 3

They look perfect to me :-)

Too late for a redirect; "empty space" in full-width third box mitigated by reducing min-width for boxes

And spent several seconds before figuring out that people here were commenting on MediaWiki/Homepage improvements 2018/Proposal. :)

Also, template at top: "More information and discussion about changes to this draft may be on the discussion page. Do not use the Discussion page". :D

@Elitre (WMF): One problem of MediaWiki is that every page has a discussion page, to encourage decentralized and duplicated discussion in several disconnected places... Maybe I should have dumped the proposal directly into the planning page. If that's less confusing. Hmm. :)

No, I think you could just create the page to redirect here and let go of the confusing disclaimer :)

@Elitre (WMF): Uh, I did not know that I could overwrite a StructuredDiscussions talk page to make it a redirect. Thanks a lot for the tip, too late now as both talk pages have been used already. My fault... Noted for next time! :)

At https://phabricator.wikimedia.org/F28426543 , I've put a screenshot of my Safari browser with the bookmark panel open on the left. The central box doesn't look too nice, I just wanted you to see that :)

@Elitre (WMF): Thanks for the feedback and taking a look! We have five boxes. Do you have a better layout idea how to render five boxes, which works for all screen widths and looks nicer? The current behavior is intentional and I'm open to better behaviors.

Hi, I just saw that you tested "on smaller screen widths", but wasn't sure if that meant "on a regular screen that just happens to have a sidebar open at all time", which I imagine to be a quite regular thing. I think that Olga's team has the gurus for such questions? :) Thanks for all the work so far!

@Elitre (WMF): It's still not clear to me what "does not look too nice" and which potential problem to solve. Is it that the third box has the width of two boxes (that's because 5 boxes cannot be divided by 2 to always have 2 boxes per line on such a screen width)? That boxes are used in general (that was also the case with the previous design in production, with way worse readability on smaller screens in the desktop version as boxes do not wrap into separate lines in the previous design in production)? Or something else?

I reached out to the public Design mailing list in as recommended on Design#How to get involved and work with us . I do not plan to try to track down individuals in some company "black box", as someone doing design work should not be required to do so.

Ciao, in my screenshot the Set up box ends up having a lot of empty space at the right. If its content were split up so that 3 links stay in a column on the left side of the box, and 3 at the right, it would prolly be more aesthetically pleasant for me (when I happen to have a sidebar open). Again, it doesn't prevent me from using the page ;) I just prefer how compact it all looks when the page is displayed in the way it's meant to be, with all the 3 boxes side by side. Thanks again!

@Elitre (WMF): Ah, thanks for the explanation! I agree. In the mean time I reduced the minimum width of the boxes, as requested by Kaartic, so the situation that you encounter should not happen anymore: Testing with Vector skin and 100% zoom level in Firefox 66 on a Linux machine, a content width of 1101px (until 812px) will move the third box to a separate row and now the width/length of the bullet points in the third box is 'long enough' that a second column of bullet points within the third box would not make sense anymore, so I guess the problem is kind of unintentionally resolved? :D

I think it is.