Requests for comment/Interproject links interface/Issues

Add links
From Meta, a Wikimedia project coordination wiki

Issues[edit]

Commons category vs gallery war[edit]

As you perhaps know, there has been a war in wikicommons about category vs gallery for species (For a pro-gallery contributor, there should be no species categories and the media would be referenced only in a species gallery. This because galleries can be followed).
So the question is: Should a wikipedia article link to a wikicommons category or a wikicommons gallery?
Note: wikicommons categories discretly won: We decided that no one could oppose the creation of a more precise category (here, a species category) and that those categories could be appended to a gallery and its media. At the end there are categories for all levels of taxons + always a category of a species and only of the time the corresponding gallery. The gallery are now devoted to presenting the best media with a comment.
Liné1 (talk) 17:48, 11 May 2013 (UTC)[reply]

Layout[edit]

One key aspect of the discussion is the layout. The interface must include among other aspects:

  • It must be simple and clean.
  • It must encourage users to visit the interwiki links.
  • It must be adaptable to the different versions: web, mobile, desktop (iOS, Win8 and Android apps), etc.

What do you think about the layout? --NaBUru38 (talk) 22:21, 24 April 2013 (UTC)[reply]

Comments[edit]

Mobile is irrelevant to the layouts being discussed. Mobile devices are served by MobileFrontend which will always do links like these in a completely different way than will be done in normal skins. Dantman (talk) 23:53, 24 April 2013 (UTC)[reply]

Apps are irrelevant too. This really is just 'web'. Yuvipanda (talk) 04:28, 25 April 2013 (UTC)[reply]

Another (so far ignored) point is that some articles will have a dozen such links, others will have none. We need to find a method that could work well with any number of links. Ypnypn (talk) 18:12, 26 April 2013 (UTC)[reply]

Non-mainspace links[edit]

As I mentioned above, each subject (like w:en:Technology) doesn't just have main pages, but also portals (w:en:Portal:Technology), wikiprojects (w:en:Wikipedia:WikiProject Technology) and books (w:en:Book:Technology), plus its respective main categories. I believe that these should be included in the discussion as well. What should we do about them? --NaBUru38 (talk) 22:25, 24 April 2013 (UTC)[reply]

Comments[edit]

  • None of the current methods would allow for this. What might is a navbox-like template. – Ypnypn (talk) 22:29, 24 April 2013 (UTC)[reply]
  • Categories depend on the skin. Portals and stuff are internal navigational links which don't have a standard or pseudo-standard "storage" system anywhere, so it's currently impossible to handle them centrally and it's also unlikely they'd be added to Wikidata. Additionally, I don't think it's a good idea to try and redesign the whole navigational templates and "see also" etc. etc. all the projects have, all at the same time... You'd never come to any conclusion, and that's more typically "content" than interface. --Nemo 08:39, 25 April 2013 (UTC)[reply]
  • See my Option 6 on keeping some local flexibility. Rd232 (talk) 12:11, 26 April 2013 (UTC)[reply]

Customization[edit]

Because of the variety of situations, and to prevent revolts along the projects and editions, it's reasonable to think that there will be some sort of level of customization with interwiki links. Depending on which options are chosen, what should be customizable? Which interwikis appear, their order, their font size? SHould the customization be per project, per edition, per page? --NaBUru38 (talk) 22:35, 24 April 2013 (UTC)[reply]

Comments[edit]

Customization would be nice, but I imagine it would be technically difficult (or at least burdensome), and also defeat a large part of the "consistency across projects" objective. See my Option 6 which frames the standardised links as additional to whatever the project or page wants to do in its templates (eg to highlight key links or provide alternative links that wouldn't go into the Wikidata links for the page). Rd232 (talk) 12:16, 26 April 2013 (UTC)[reply]

...

Misleading RFC[edit]

"Sidebar" is currently a popular option. Apparent result: no interproject links on mobile devices (the default mobile skin has no sidebar)??

It seems to me that this RFC is misleading and badly designed. The stated objective is to ask the communities for their opinion on proposed interfaces that would allow storing the interproject links in a central location, such as Wikidata.

  1. This stated objective bears no relation to the "current situation" background description, or to the initial proposals, which are all about the design of interproject links. Not a one of the initial proposals (Options 1 to 3) actually requires Wikidata to exist at all: those design choices could just as well be imposed on all projects without it.
  2. There is no clarification of how interproject links will be constructed and maintained. I gather that it'll be somewhat similar to interwiki links, so for instance Wikipedia article X has as an associated Statement a Commons category Y (Property:P373). If this is how it'll be, why has no-one bothered explaining it (or linking to an explanation elsewhere, if one exists)?

But most fundamentally, if my understanding of 2. is correct, then there is no need whatever to have an RFC. Transition to interproject links being stored on Wikidata would happen very easily, with existing projects adapting their templates to pull the relevant wikidata property for that page, and bots transitioning existing interproject links to Wikidata just as they did for interwiki links. (The only awkwardness would be having to build in an edit link to Wikidata - but that's a wider issue to using Wikidata.)

As is abundantly evident from so many of the responses, there is actually a violently different objective being pursued here, which is not to centralise interproject links in Wikidata, but to use the centralisation of project links in Wikidata as an excuse to impose a redesign of interproject links on all projects, making them much more prominent near the top of the page. Some of the things apparently not considered (certainly not evidenced) include

  1. whether the result would be actually any use to users (when they come to a page, are they desperate to leave, and need to be helped to do so before scrolling down... or is looking for related resources something that they will normally do after scrolling down?)
  2. whether one size fits all across all situations on all projects and devices (and no, you can't ignore mobile)
    • and if not, how project opt-outs or exceptions within opted-in projects would be handled
  3. how the inevitable enormous outrage from the large proportion of users who won't comment in the RFC will be handled
  4. how a transition would actually work (bots removing existing templates? edit-warring with users re-inserting them??)

This looks like a mess, and a disaster in the making. Maybe someone can explain to me how I'm wrong. Rd232 (talk) 21:43, 25 April 2013 (UTC)[reply]

Given the page's title and content, it seems fairly clear that this is about the look/design, not about the implementation details. :-) I agree that the current page lead ("This RFC has the aim to ask the communities for their opinion on proposed interfaces that would allow storing the interproject links in a central location, such as Wikidata.") is a little misleading, but I wouldn't say this RFC as a whole is misleading. That's awfully harsh language. This page seems to have been started in—and engaged with in—good faith.
Regarding your actual objection(s):
"whether the result would be actually any use to users (when they come to a page, are they desperate to leave, and need to be helped to do so before scrolling down... or is looking for related resources something that they will normally do after scrolling down?)"
Part of this is to better advertise the sister projects. An "Objectives" section on this page might be a good idea.
"whether one size fits all across all situations on all projects and devices (and no, you can't ignore mobile)"
Mobile will handle itself. It already excludes and includes features as it pleases, don't worry about mobile. This is about the browser version of the Wikimedia wikis, which is fairly consistent (with the exception of a few sites that use still use Monobook, but even that's fairly similar in appearance). If anything, perhaps there should be a bit more anger at the fact that every site uses Vector and you weren't consulted. Oh well.
"how the inevitable enormous outrage from the large proportion of users who won't comment in the RFC will be handled"
This of course depends on which design is chosen. A lot of the proposed designs most users wouldn't notice at all. ;-) A few look like they'd be horribly obnoxious and won't ever be chosen. Don't worry so much.
"how a transition would actually work (bots removing existing templates? edit-warring with users re-inserting them??)"
Again, this is an implementation detail, when this page is pretty clearly focused on design. The final implementation (if there ever is one and "final" really has no meaning) may use wiki templates. It may use Wikidata. It may use templates and then transition to templates. Who knows. --MZMcBride (talk) 05:29, 26 April 2013 (UTC)[reply]
Well, thanks for your response. I'm not really convinced by it. Most especially I'm not convinced by the Mobile will handle itself. attitude. Mobile isn't magic, it's an alternative way of displaying page content. If the interproject links are removed from the page content (which mobile displays) and moved to the sidebar or some other interface element mobile doesn't display, then interproject links will no longer be visible on mobile. If the objective is to make interproject links more prominent, that seems like something that ought to be taken into account! Also, your comparison with Vector is interesting. Any user can opt out of Vector (I did for a while, but eventually switched). How can any user opt out of these proposals? Rd232 (talk) 09:22, 26 April 2013 (UTC)[reply]
PS Sure, I'm not saying there's bad faith here, even if my late-night grumpy posting may seem to have implied it. It seems more of an opportunistic "Wikidata is happening. Let's redesign, and finally give sister projects the prominence they deserve!" sort of thing. At least part of my irritation is the firm belief that if this was advertised on major Wikipedias (sitenotice/centralnotice), you'd be just overrun with people falling over themselves to say "no, don't force any change in the interface on all projects", and in the stampede you'd be lucky if people bothered to add "(unless the design is just fantastically brilliant)". Rd232 (talk) 09:30, 26 April 2013 (UTC)[reply]
Hi Rd232. I am one of the partners of Micru (the proponent of the RfC) in a grant project focusing on Wikisource. That means: this Rfc has been proposed within the task concerning that project. We did not wrote that explicitly (to focus on the proposal here, as this RfC is fairly indipendent as it is), but maybe it's an important disclosure.
Please bear with me in assuming good faith here. We are not stupid enough to think that a RfC alone can force anything in Wikimedia projects. We are proposing a bold paradigm shift, conscious that some people would love the idea and some would hate it. We are asking for comments and feedbacks, in a Meta page (so directed on internal, internationals, very skilled wiki users) to gather data and opinions. We proposed a tab interface, that was very bold and with few chances of being accepted. It was an idea, and I'm glad that Option 5 goes in that direction, but with a more brilliant design.
As for the phrasing of the RfC, we may be made some mistake, but always in good faith. Centralising interprojects links in Wikidata it's an option, not a reality, but it's also the necessary condition of the redesign we are proposing here. So this RfC, if you want, is assuming a change presenting a redesign proposal. We can surely make that more clear, but I really don't see how this can be seen as "misleading".
As for "Wikidata is happening. Let's redesign, and finally give sister projects the prominence they deserve!", I don't see how this attitude can be a problem. We now have Wikidata, born to centralize Wikipedia things". We have the same issue for interprojects links as we had for interlinks. Centralising those could be a low-hanging fruit for Wikidata and a huge step forward integration of Wikimedia projects.
We are proposing a redesign interface to make those links visible. We are proposing this here, in Meta, and I think there'll be a long road for any proposal to be really implemented. We can't use the sitenotice to ask all Wikipedia users around the world. We'll see how this RfC goes, maybe one day we will :-)
I hope I answered some of your questions. Cheers, Aubrey (talk) 10:58, 26 April 2013 (UTC)[reply]
OK, thanks. Perhaps I should have avoided the word "misleading", which is often read as "intentionally misleading", which I didn't mean. And of course there's nothing wrong with wanting to give sister projects more prominence, as long as that desire takes into account what's useful to users and isn't just satisfying contributors. Anyway, the problem is that the RFC has gone straight into "how should a standardised interface look", and totally bypassed all the issues around transitioning to an interface standardised across all projects. It seems to have been assumed that it would work just as smoothly as the interwiki links transition to Wikidata, and it should be clear that it wouldn't be anything like that. Rd232 (talk) 11:35, 26 April 2013 (UTC)[reply]
I've tried to organise these thoughts into a new Option 6 that takes these various issues into account. Rd232 (talk) 12:17, 26 April 2013 (UTC)[reply]
Hi Rd232, just to add a bit on what Aubrey already said. Yes, there are two different discussions: one debate is if it is wanted to give more prominence to sister projects, and the other debate is how. IMHO it was important to ask first about the design options before bringing the other subject to the public light. The reason is that, as we are realizing, there are issues that we were not taking into account (as the one you pointed out: mobile), or that there might be other unknown impediments that would render the debate useless.
I agree with you that this is not the kind of rfc to advertise as a sitenotice, it is more for internal attention. The public debate will have to be prepared in advance in different terms. If you had time, would you like to help us to shape how we bring the topic into attention?--Micru (talk) 13:43, 26 April 2013 (UTC)[reply]
I think my Option 6 now covers most of my points. I think people arguing for prominence at the top of the page should provide some evidence that this is what users actually want and/or need. Structurally, it just doesn't make sense to me. In terms of developing the topic - well it's a bit difficult from here. I would have started with a discussion about objectives, and about technical issues of storing interproject links in Wikidata, and left redesign ideas until after that was clarified - it seems a bit putting the cart before the horse. PS Are you aware of en:Wikipedia:Requests_for_comment/Wikidata_Phase_2, which may well cover using Wikidata for interproject links? Rd232 (talk) 13:58, 26 April 2013 (UTC)[reply]
Well, I think that any conversation about technical issues of storing interproject links in Wikidata should be lead in Wikidata, not here. Regarding WD's Phase 2, yes, I am very aware of that, however it is a different matter. For Commons you can have a link for all Wikipedias, in other projects not so, because there is a link for each language version, so it is not possible to use the capabilities deployed in phase 2 for the interproject linking problem. Agreed that the prominence of sister projects needs a different discussion.--Micru (talk) 12:26, 29 April 2013 (UTC)[reply]

Comments[edit]

...

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Requests_for_comment/Interproject_links_interface/Issues&oldid=16073095"