Talk:Requests for comment/MediaWiki.org Main Page tweaks

Requests for comment/MediaWiki.org Main Page tweaks/Sandbox/v5

What's the point/purpose of the "Popular pages" box? --MZMcBride (talk) 22:46, 26 February 2012 (UTC)

Purpose of redesign

I think it'd make more sense to first focus on the actual issues you're attempting to address with a redesign before making a bunch of redesign drafts. It still isn't very obvious to me what problems are intended to be solved here. (Or how this requests for comment is intended to solve them.) --MZMcBride (talk) 22:54, 26 February 2012 (UTC)

... right. --MZMcBride (talk) 22:33, 6 March 2012 (UTC)

Initial reactions

I've quickly looked at all the variations submitted so far (up to #10), and all of them are much, much more cluttered and confusing than the current main page. Our current main page looks pretty good, but I agree is a bit dated and is not necessarily meeting our functional needs. However, all the given designs look - to me (as a professional web designer) more dated, more confusing and less professional.

If these designs are currently just wire-frame style mockups to discuss arrangement of content, then obviously this criticism is invalid and premature, and I will look at them again in more detail, but if they are broadly what the finished designs will look like, then I say no, no, no!

On a more constructive note, here are my thoughts on where the current home-page succeeds and falls down. I am not going to discuss visual design at this stage, just content. I've numbered the list to make it easier to refer back to specific comments. The comments are not in any particular order.

1. The 'about' box is actually pretty good. A succinct description of what MediaWiki is and a couple of key notes about the site, plus links to the general overview stuff. Download and Help & Support links are duplicated elsewhere, but I don't think that does any harm as these are likely the most common links that new visitors to the site will be after, but could be removed if the duplicate links end up sufficiently prominent.
2. I think that the explicit delineation of content into users/admins/developers is something that we have got very right on the home-page (though less-so elsewhere in the site) and should definitely remain. It think there is a tendency for developers to feel that they are under-represented as they are here all the time and because they are the people who will, ultimately, be driving the redesign. However, you should remember that the home-page is most important to new or infrequent visitors as a jumping point to find what they want. Therefore anything which side-lines the users, or which bloats the page with developer-specific stuff, is a bad idea in my view. In particular, any design mock-up which simply reserves an area of the page indicating 'link 1', 'link 2', etc. (which applies to most of them) is going about things the wrong way. First identify what these links are that are important enough to go on the home page, and then work out how much space is required and how it should be laid out.
3. We have three hubs on the site, geared towards these user types: one for users, one for sysadmins and one for developers. Currently these are underdeveloped and somewhat bit-rotten - largely just link dumps. I think that it would be better to focus this redesign effort on making those hubs useful and powerful, rather than trying to get more stuff onto the home page.
4. I think the icons for the different user roles are very clear and are quite important. They should be used more widely on the site (as was the original intention) to flag the level of relevance/skill-level for different pages/sections/box-outs/etc. I feel very strongly that each target-group should have a distinct icon. I am happy for new icons to be considered, but no-one has yet put forward any suggestions in this regard.
5. The current version box is almost redundant. This was introduced at a time when we had several different current versions (due to PHP4 compatibility being removed in 1.7) and therefore a lot more content to go in it. The news box was also shorter, so the whole bottom row occupied less space. I think the current version box can be replaced by a single prominent [Download 1.XX] button, with smaller links underneath it to older versions and release notes, a bit like here (just one of many possible examples I could have used). This should be near the top of the page, not tucked away at the bottom.
6. The news box is completely and utterly redundant. Remove it. Aside from the two recent notices about Git migration, the only news that has been published in since 2007 has been to announce new releases. This is not front-page fodder! We know the latest release from the download box. If the date is important, we can add that too. There is no need to have such a prominent history of prior releases.
7. New opportunities - this new addition, I like. A great idea, so long as it is kept current.
8. The idea of adding a 'popular pages' section just seems wrong to me. If this is not already covered by our (already long) side navigation, then there is something very wrong indeed. Of course, that comment assumes that it will be a static list that someone updates once-in-a-while based on the pages that are likely to be most useful. If the suggestion is actually for a dynamically updated list (of what - most reads? Most edits? Over what time-scale?) I can very much see the point... though I must admit I'm a little sceptical. Would be a great idea, so long as we get the algorithm right, and it actually churns out some relevant stuff that changes once in a while (hint: none of built-in special pages give us anything very meaningful).
9. Re: splitting extension writers away from developers - I can see the conceptual sense, but is there actually much of a delineation. Are there many extension writers who don't dabble in the code, at least a bit? I'm not yet convinced, but would like to hear the arguments for this delineation (particularly in the light of points 2 and 3, above).
10. Re: 'A block to showcase sites made with mediawiki'. I think this is potentially a great idea, but only if (1) we have images for all sites that get listed - no benefit in just having text links (2) they are not too dominant (which is a danger if this is the only non-iconic image on the page - we don't have a screen-shot of the vanilla software after all, as the whole site is an interactive screen-shot, and it could be confusing if there are other screen-shots present). I would suggest implementing this as a carousel, cycling through one site at a time, showing a screen-shot of the main page plus the site name, both of which link to either the site, or a page/section on MW.org giving more details about it.
11. Re: statistics about mediawiki. Nice idea, if useful/interesting to visitors and automatically updated. Waste of space and high likelihood of bit-rot if not.

Hope these comments are taken in the constructive vein they are intended, and help focus the discussion onto what we actually want to do, before we go any further in discussing specific layouts.

--HappyDog (talk) 23:56, 14 March 2012 (UTC)

Thank you for the constructive and thoughtful feedback. Unfortunately a lot of the background conversations have been on IRC, so context to answering the above is lost. I should also note that the Sandbox is just that - a place to play around with some ideas. I don't think any of them have been tweaked enough to be presented as an actual proposed replacement. Although others may feel differently. Here are some comments on the above:

2. I don't think any designs removed the links that appeared under user. Beyond the public domain help section, there is not much intent or content supporting users of MW software - so giving them false hope that there is doesn't seem a good use of homepage space. Regarding the other comments, there are obviously lots of different ways to approach design work. I gave up trying to force folks to use one process over another. So you're welcome to start a conversation on what links are needed and then do some work in the sandbox based on it. Be bold.  :)

3. I agree the hubs need help as well. However, they're not used nearly as much as the homepage - so the feeling was to start there. Again, be bold and feel free to start work on them as well. Maybe a sandbox for each one or at least a talk page conversations on what's needed in a possible redesign of them? The Community Portal also needs help badly IMHO.

6. I don't feel strongly about this either way. My impression has been that some folks see it as important or a must - but I'd be curious what others think. Towards later variations I played around with cutting down the number of stories displayed considerably.

8. Those are more pages that have been frequently requested or referenced by folks providing support via this site either in IRC or support desk. The idea was to help route folks to areas they've commented have been helpful in answer questions they've otherwise gone to someone directly for help with. The idea being the easier it is for folks to find their own answers, the more time developers can spend developing and not doing support. "Popular pages" is perhaps not the best title - I'm not sure the actually most trafficked pages are the ones most helpful to finding what you're looking for (if that makes sense). Definitely open to ideas on ways to showcase some of the sought after links we don't really have a good place for currently on the homepage. v10 has better examples.

9. There is definitely a distinct extension developer community. Someone probably has the stats on the difference in number of folks with core commit access and extension commit access. This was done in response to an effort to foster that community more. Similar things have been planned by others for future Hackathons and Wikimania presentations.

10. & 11. I'm not personally a fan of these - but perhaps the originators of those ideas can speak to them.

Again, I think designer's personal preferences on process aside, sandbox is open for folks to play. You're obviously welcome to offer a design based on what you feel is needed or seek some feedback on that. I can't speak for everyone discussing this idea here, in email or in IRC - but I certainly try to consider feedback when I tinker around in the sandbox - so any constructive feedback you have or want to solicit will certainly be pondered by at least me.  :)

--Varnent (talk) 00:34, 15 March 2012 (UTC)

Lessons from Manual:Skins

A while back, I ran across Manual:Skins, and thought "Why are they bucketing people instead of actions?" So, I was bold and changed it. I haven't gotten much feedback on it, but I think we could apply the same theory to the mw.org Main page. Here's my thought:

1. Bucketing people makes it less likely that they'll find what they need if they try to change roles. If you say "Developers, go here", then the editor who's delving into coding for the first time might not think to look there. When I rearranged the Skins page, I reworded this to "Create a skin for yourself or others." This applies to new sysadmins and new users, as well--they might go to the wrong place because they identify with a group that doesn't usually do what they're currently trying.

2. Bucketing people reinforces (unnecessary) boundaries between groups. This is bad because it means less conversion between the groups. If we say "There are two types of people in this world, them that drink Coke and them that drink Pepsi", not only are there going to be fewer RC drinkers on MediaWiki.org, but the Pepsi people won't ever try a nice delicious Coke for fear of betraying their group. We might want developers to branch out into being sysadmins, or users to branch out into being developers. And hey, what about those translators and documenters? Where do they go?

3. Bucketing people is not always accurate. While a developer might often want the CC page (for example), they might also need to set up a test instance, so they'll need Installation instead. Similarly, someone trying to work on the parser or Parsoid might need the Help:Editing pages section, which is under "Users", not "Developers".

These are just hypotheses, and I'm sure there's a more accurate way to test, but I happen to think they're pretty clear concerns. --MarkTraceur (talk) 22:00, 24 September 2012 (UTC)

That is a very good point! I had not considered it before (I was the person who came up with the current main page structure). I have been bold and updated the main page as per your suggestion! --HappyDog (talk) 12:28, 27 September 2012 (UTC)

Awesome! There's still a lot we could change about the wording ("how to become a hacker", for example, is a little suspect), but I overall am happy that we've changed it. Thanks! --MarkTraceur (talk) 20:37, 28 September 2012 (UTC)

Additionally, I think there are a lot of other actions that are awesome (translating, documenting, backing things up, writing gadgets, writing Lua modules, etc.) that aren't documented at all on the main page....truthfully there's not enough screen space for all of them, but instead of using huge parts of it for "hacking" and similar potentially scary words, we could use the screen space for a friendly word like "building" or "making better". --MarkTraceur (talk) 22:02, 28 September 2012 (UTC)

Show MediaWiki Testimonials

Related to showcasing sites using MediaWiki, there could also be a link to MediaWiki_testimonials after it undergoes some updating. --Mitevam (talk) 14:02, 21 February 2013 (UTC)

mediawiki.org sidebar refresh

I fyi have started drafting the contents of a refreshed sidebar at User:Qgil/mediawiki.org_sidebar. Feedback welcome.--Qgil (talk) 15:40, 15 April 2013 (UTC)

OPW project: Redesigning mediawiki.org homepage?

I'm thinking of proposing the redesign of the mediawiki.org homepage as a FOSS Outreach Program for Women project. I could act as co-mentor with the help of someone else. The RFC process held so far would serve as a source of feedback, but the project would imply basically a restart. The progress of the project would be public and anybody could chip in and have their say. If there is agreement overall, we would aim to substitute the current homepage or implement changes progressively. If there is a strong lack of consensus that no OPW intern will fix, we would continue the exercise as a prototype, and at the end of the internship the mentors would take the responsibility to drive the project until its implementation. What do you think? Any volunteers to co-mentor?--Qgil (talk) 14:12, 29 October 2013 (UTC)

See Mentorship_programs/Possible_projects#mediawiki.org_homepage_redesign.--Qgil (talk) 21:31, 29 October 2013 (UTC)

I'm selected to participate of OPW and I will work at MediaWiki Homepage Redesign project in which Quim and Heather are my mentors. Right now we are preparing the Design Document and all collaboration is welcome. --monteirobrena (talk) 11:50, 16 December 2013 (UTC)

Closing this RfC

The goal of this RfC is being pursued now by the MediaWiki/Homepage_redesign project. I don't see any reason to keep the RfC open. Any objections? How to proceed? Ping Varnent and Sharihareswara (WMF).--Qgil (talk) 21:03, 21 February 2014 (UTC)