Jump to content

Requests for comment/Interproject links interface/Proposals

Add links
From Meta, a Wikimedia project coordination wiki

Proposals

[edit]

Since there is a big diversity in uses, there might not be a universal solution for every project. Especially difficult is the case of Wiktionary, where each page can link to several articles.

Other projects like Wikipedia, Wikisource, Wikitravel, Wikiquotes, Wikivoyage, etc. could benefit from an unified system where all the links are centralized in Wikidata in a similar way as now happens with language links.

Option 1: Action/Interproject tabs

[edit]
Proposal for an interface with tabs for interproject links

This option would place extra tabs linking to the related sister projects.

  • The maximum amount of tabs would be to 4 or 3 plus an arrow that would display the extra sister project links. The position of each tab would be kept consistent across projects (if it is meaningful to deploy this interface on that sister project).
  • This requires to move the "talk" tab to a new position and maybe some other additional tabs added by sister projects.

NOTE: to avoid the user to get disoriented when clicking on one of those tabs, it is also proposed to transclude the pages from the sister project into Wikipedia (or the relevant project), in a similar way as now is happening with File pages transcluding the file description from Commons.

For more information and mockups check this presentation.

Support

[edit]
  • Support Support As proposer. It could be a good solution wherever it can be deployed. It doesn't need to be everywhere, Wiktionary could be skipped.--Micru (talk) 01:33, 24 April 2013 (UTC)[reply]
  • Support Support Would need some additional thinking, but makes sense. --Nemo 09:27, 24 April 2013 (UTC)[reply]
  • Support Support If it's feasible, why not? --Sannita - not just another it.wiki sysop 11:50, 24 April 2013 (UTC)[reply]
  • Support Support... though the idea of a Vector tab for each sister-site that happens to host relevant content is a bit overkill (imho). Make it one Vector tab with a Vector menu list of all the sister links (or sister searches if redlink there?) under it and that would be still "easy on the eyes" for those who don't care about such things but a useful addition for those who do. -- George Orwell III (talk) 11:55, 24 April 2013 (UTC)[reply]
    • That would reduce the number of buttons, but would also hide the links. Regular users don't click on innocent arrows. --NaBUru38 (talk) 22:28, 24 April 2013 (UTC)[reply]
      • Regular users would quickly adopt whichever approach is selected in the end. We want casual visitors to become regular users and linking sister content may just be the way to achieve that. Slap an animated .gif on the tab if you think extra "eye candy" is needed to draw attention to the newly linked sister content. I see little difference between the drop-down menu under a single tab and what is being proposed in option 5 as well. -- George Orwell III (talk) 15:06, 27 April 2013 (UTC)[reply]
  • Support Support I'm currently working on a template for the french wikipedia, aiming at providing a a knowledge requirement preview with a list of internel link for each concept, and a list of each relevant course on the wikiversity. I think this is exactly the kind of tool we are missing to provide readers with all information which may be relevant for their current research and to bring more contributors to sisters projects, which do need them in order to improve their content. --Psychoslave (talk) 14:10, 24 April 2013 (UTC)[reply]
  • Support Support Making other projects something closer to first class citizens would be one of the most positive steps we could take to re-energize those projects. It will take some serious thinking and design work to figure out how to make it work, given that the correspondence between pages on other projects isn't always one-to-one (there could be many relevant Wikinews articles for one Wikipedia article, or several different Wiktionary definitions, or a whole slew of related Commons categories). But the basic idea of highlight the parallel content on other projects in a high-profile way is totally sound.--Ragesoss (talk) 16:08, 24 April 2013 (UTC)[reply]
  • Support Support I rather like the idea of tabs here, but this may require retooling how we expose the talk page since it currently uses that space in the UI. We may also need to do something like how interlanguage links are being done in wikidata to connect pages together based on topics. There's also the open question of what to show if there is nothing linked up -- show a red tab as a call to action to create one? Hide them? Have a subtler, hidden call to action? --brion (talk) 16:14, 24 April 2013 (UTC)[reply]
  • Support Support I think this option combines visibility for sister projects with a somewhat discreet appearance. A casual user of Wikimedia is more likely to see the links but they are also easily ignored if unwanted. I would not be opposed to a single tab with a drop-down menu (like the current "Move/Delete/Protect" selection) but the choice of title is important; a casual user will not know what "sister project" or "interproject links" means ("External resources" or just "Resources" perhaps?). - AdamBMorgan (talk) 16:21, 24 April 2013 (UTC)[reply]
    Note that the newer "Option 5: Dropdown next to title" also covers everything I'd want with an even more discreet appearance. - AdamBMorgan (talk) 12:07, 25 April 2013 (UTC)[reply]
  • Support Support This tabs proposal is great! I'm very interested in helping Wikipedia readers to reach the other projects. But I'd like the tabs to depend on the page: people would get Wikiquotes, writers would get Wikisource, terms would get Wiktionary, etc. --NaBUru38 (talk) 22:12, 24 April 2013 (UTC)[reply]
  • Support Support Almost nobody knows about Wikipedia sister projects. There are so many people that invest so much of their time. Time = money. So basically there are so much investment on other sister projects but barely being used by people who need them because not many people know about their existence. This would help maximize all the sister projects utility and maximize its potential usefulness. So in the end, our contributions in sister project are not in vain.Trongphu (talk) 02:09, 25 April 2013 (UTC)[reply]
  • Support Support in some form. –SJ talk  03:46, 25 April 2013 (UTC)[reply]
  • Support Support--Wvk (talk) 11:17, 25 April 2013 (UTC)[reply]
  • Support Support if this gets the most votes, but I'd prefer something more like Option 5. PiRSquared17 (talk) 14:33, 25 April 2013 (UTC)[reply]
  • Support Support Excellent idea! It can make other wikimedia project more popular. בנימין (talk) 15:08, 25 April 2013 (UTC)[reply]
  • Support Support It seems very sensible to give prominent links to the sister projects, rather than hiding them away at the bottom of the page, or in the sidebar, and this seems like a sensible place to put those links. Mike Peel (talk) 13:17, 26 April 2013 (UTC)[reply]
  • Neutral Neutral I personally think that Option 5 is better, but if it doesn't get enough votes, then let it be this option. Soshial (talk) 19:35, 27 April 2013 (UTC)[reply]
  • Support Support as Nemo says below I like the idea of associating actions to tabs, this, at least in principle, could invite more people to participate or just browse within the variety ofprojects. Furthermore I like the fact that sister projects will be in a prominent position. Lastly, I think that experience editors workflow will be changed very little, for new editors I think that seeing more stuff in the tabs maybe will lead to more interest/focus on the area (and maybe more people clicking "Edit"). Adding a note: I think that various test with thabs in different order can be made to see which is more suitable to users. -- CristianCantoro (talk) 21:55, 29 April 2013 (UTC)[reply]
  • Support Support really nice, but I think we need links to other projects both at the top and at the bottom of pages. Léna (talk) 11:01, 4 May 2013 (UTC)[reply]
  • Support Support It is surprising that this proposal was not thought of years ago, as it represents the most intuitive method for the reader to switch seamlessly between wiki-projects in their search for related content. It also has the benefit of eliminating the mess of non-standard inter-wiki templates that are randomly placed on content pages that are analogous to the old-fashioned travel stickers that used to be indiscriminately plastered over luggage bags by hotel porters touting for business. The most important consequence of this proposal is that the resulting set of structured links that connect related content between Wikimedia Projects with their overarching subject matter would create an important set of metadata that could be studied and analysed in its own right. --Gavin Collins (talk|contribs) 03:21, 15 May 2013 (UTC)[reply]

Oppose

[edit]
  • Oppose Strongly oppose This area of the interface is defined as the namespaces related to a page. Making links there switch to a completely different wiki is very unexpected and very unfriendly towards users. Dantman (talk) 03:45, 24 April 2013 (UTC)[reply]
    • The tab layout would be the same in other wikis, hence the user will still have the reference, additionally icons can be placed on the tabs. Another alternative could be to transclude the pages into wikipedia in the same way as now is done with the File pages from Commons.--Micru (talk) 04:02, 24 April 2013 (UTC)[reply]
    • It's not about namespaces, it's about actions (in Vector): Read, Discuss. It may make sense to add related actions like "Read books", "Browse media" etc. --Nemo 09:27, 24 April 2013 (UTC)[reply]
    • No it's not about actions. Actions are on the right side of the bar. This interface completely removes links to the talkpage and eliminates the language variants. Dantman (talk) 14:40, 24 April 2013 (UTC)[reply]
    • Now that I see the presentation that shows the talkpage link as moved rather than removed let me rephrase myself; Talk does not belong in the actions tabs. Talk/Discussion is not an action. It's a page in another namespace. And when you go and do something like edit or view the history of the talkpage this is going to lead to the undesirable and confusing behaviour of having multiple action tabs active at the same time. Dantman (talk) 00:24, 25 April 2013 (UTC)[reply]
      • We're not speaking of "actions" in MediaWiki terms (action= in the URL), but of things the reader wants to do/is interested in: currently Article (content), Talk (discuss content), Opinions (in some Wikinews languages, even though may be another namespace or not). I agree Talk should not be moved from the left tabs but I don't think there would be any interface inconsistency in principle. --Nemo 08:45, 25 April 2013 (UTC)[reply]
  • Oppose Oppose Having the links in the sidebar makes so much more sence. Having the links as tabs would give the impression that the pages on the other wmf wikis where pages on that particular project.--Snaevar (talk) 11:25, 24 April 2013 (UTC)[reply]
  • Oppose Oppose terrible interface design, breaking users' expectations like that. One click: talk page within the same site. Another click, on a tab right next to it: related page on another site. No, it's bad. And that's without even getting into the upheaval and upset caused by changing interface on many projects - you can just imagine the zillions of editors who won't participate in this RFC being annoyed by this change being imposed. Rd232 (talk) 16:44, 24 April 2013 (UTC)[reply]
  • Oppose Oppose Many articles will have a lot of tabs (Pedia, Commons page, Commons cat, Quote, Books, Tionary, Voyage, News, Versity, Data, etc), so we'll have to resort to the drop-down menu, which is even less visible. – Ypnypn (talk) 18:09, 24 April 2013 (UTC)[reply]
    • Can you cite some of those articles?--Micru (talk) 18:51, 24 April 2013 (UTC)[reply]
      • United States will have WP, 2 Commons, WQ, WB, WV, WVoy, WN, WD, Wikt, and WS. That's eleven. Cat can have all of them, plus Species.
        • I think that this can be fixed, if we like the general idea. We could make the layout of tabs "customizable" (to display only relevant projects, and put in a drop-down menu the others). Aubrey (talk) 21:29, 24 April 2013 (UTC)[reply]
          • The general idea isn't bad, but I don't see a practical way to make it actually work. The real problem is that these links require a lot of space, which there isn't a lot of at the top of the page. We could put them right under the title, but then the actual content of the page gets pushed down. Above the Article/Talk tabs would be cluttered. I'm open to solutions, but I haven't seen any yet. Regarding "customization" it creates problems if you're on a less relevant project. – Ypnypn (talk) 22:26, 24 April 2013 (UTC)[reply]
        • Is there a Wikivoyage page for Cat? ;) --NaBUru38 (talk) 22:32, 24 April 2013 (UTC)[reply]
  • Oppose Oppose This is the wrong approach in so many ways. Vector and Monobook are already waaay too overloaded with tabs as a navigational element. Currently, even if we reduced the number of tabs, this area of the site navigation is solely devoted to actions on a page (or links to an associated page in another namespace) on the current site. There is zero cross-site navigation, and confusing on-page action areas with interwiki links is a very bad idea for readers and editors alike. Even if it were not, the prioritization of elements is extremely unclear here: how would you include them, in what order, etc. The tabs mockup also does not include/seems to erase Talk and other essential current tabs. Steven Walling (WMF) • talk 04:30, 25 April 2013 (UTC)[reply]
  • Oppose Oppose I don't think tabs are the right way to go about this. Legoktm (talk) 04:37, 25 April 2013 (UTC)[reply]
  • Oppose Oppose As noted, having some tabs at the top direct the user to a completely different website with a different domain name has the potential to be very confusing. The idea with the current tab setup is that on the right hand side you have actions, and on the left hand side you have views to which those actions can be applied. Adding too many tabs, and adding tabs whose navigation behavior is completely different from the existing ones, will make the site more opaque. This type of approach may be viable in a completely different skin where reader mode and contributor mode are more clearly set apart.--Eloquence (talk) 08:01, 25 April 2013 (UTC)[reply]
    • Well, as said above to Dantman, "Read", "Edit" (or variant) and "View history" are something that applies to all of our wikis, so there wouldn't necessarily be an inconsistency if you don't move the Talk tab. Sure, this is quite harder to design, to avoid e.g. hiding talk pages or cluttering too much with more dropdowns. --Nemo 08:53, 25 April 2013 (UTC)[reply]
  • Oppose Oppose--Steinsplitter (talk) 11:46, 25 April 2013 (UTC)[reply]
  • Oppose Oppose like some others already said, bad design not practical--Stanzilla (talk) 11:53, 25 April 2013 (UTC)[reply]
  • I agree with Erik. --MZMcBride (talk) 19:20, 25 April 2013 (UTC)[reply]
  • Oppose Oppose - Interwiki/project links are not expected at this position in a standard wiki. And user on wikis outside the WMF would not expect them there. -- DerFussi 16:51, 27 April 2013 (UTC)[reply]
  • Oppose strong oppose: First of all, I think four tabs is already cluttering. Next, what would happen with the other skins? Finally, I think that some users might be annoyed by this.--TheMillionRabbit 19:52, 27 April 2013 (UTC)[reply]
  • Oppose Brutal oppose - if there's no transclusion we take people to another wiki (eww); if there IS, then they can't edit it. For instance, say there's a typo on a quote--how frustrating and anti-wiki that you can't update it there. Red Slash (talk) 00:27, 30 April 2013 (UTC)[reply]
  • Oppose Oppose This interface is confusing. Mixing actions tabs like read, edit, discuss, etc. together with tabs that link to other projects in one area is confusing. Removing those actions from that area of the interface is confusing and makes participation harder. The image shows the Books tab as being for Wikisource, which is confusing for people when they unexpectedly end up at Wikisource rather than Wikibooks. Wikisource should use a different name, but not Source or Sources as that can be confused with Citation reference sources. I think a better option is to move all actions into a drop down menu next to the namespace tab and allow individual projects to define additional tabs and actions by editing a page in the MediaWiki: namespace like can already be done for the sidebar. The syntax of this page in the MediaWik: namespace could include some type of placeholders to be filled out by content on individual wiki pages using whatever method would have been used to fill out the project tabs. --darklama 14:49, 30 April 2013 (UTC)[reply]
  • Oppose Oppose mixing actions with resources, in a tabs line that someone who justs want to read and not contribute is used not to even watch, is a very bad idea. -Ash Crow (talk) 11:26, 4 May 2013 (UTC)[reply]
  • Oppose Oppose The picture shows something that looks like a very neat and user friendly way of binding together WikiProjects, but the problem lies in the following line of the proposal: "This requires to move the "talk" tab to a new position and maybe some other additional tabs added by sister projects". I cannot agree with moving those tabs elsewhere. They are essential to page development and maintenance and they should have priority for the top tab positions. Sjakkalle (talk) 11:54, 28 May 2013 (UTC)[reply]

Comments

[edit]
  • Comment Comment I'm not sure how feasible is this solution, but I generally think that the current situation is not good for sister projects, because they are completely invisible. Any other solution is better for me. --Aubrey (talk) 08:13, 24 April 2013 (UTC)[reply]
  • Comment Comment Are the tabs history and edit on the talk page related to the article or the talk page? That is not a good idea to move the tabs talk to the right. — Ltrl G☎ – 13:46, 24 April 2013 (UTC)[reply]
[edit]
As deployed on the Italian Wikipedia

It would be another group of links as now happens with the language links. The Italian Wikisource is already using this system.

Comments

[edit]
  • Comment Comment In my opinion this option doesn't give enough relevance to sister project pages, plus it clutters the interface.--Micru (talk) 01:33, 24 April 2013 (UTC)[reply]
  • Comment Comment Same as Micru. I think it's better than nothing, but doesn't solve the issue. --Aubrey (talk) 08:13, 24 April 2013 (UTC)[reply]
  • Support Support Path of least resistance, can be implemented just like Wikidata interlanguage links (with per-page opt-out from standard system and/or locally added solutions). Of course, must be before the "Other languages" section and expanded by default. --Nemo 09:27, 24 April 2013 (UTC)[reply]
  • Support Support --Snaevar (talk) 11:25, 24 April 2013 (UTC)[reply]
  • Support Support This is the best solution so far, and also easy to implement. --Sannita - not just another it.wiki sysop 11:50, 24 April 2013 (UTC)[reply]
  • Support Support, looks like the best of the three options suggested so far.--Ymblanter (talk) 12:06, 24 April 2013 (UTC)[reply]
  • Comment Comment -- I absolutely would take this option over doing nothing at all, but seriously - does anyone really think the sidebar is something that will still be around 2 or 3 years from now? Its a waste of screen-space in its current 'old man's Windows98 frames' as it is & that waste is prime real estate in the still expanding hand-held devices sector. -- George Orwell III (talk) 12:09, 24 April 2013 (UTC)[reply]
  • Oppose Oppose -- normal users don't even notice the sidebar. Yuvipanda (talk) 13:41, 24 April 2013 (UTC)[reply]
  • Oppose Oppose This kind of links should have a for better visibility. --Psychoslave (talk) 14:15, 24 April 2013 (UTC)[reply]
  • Oppose Oppose The sidebar's already cluttered and not a great place to find things. Better than "no links at all" perhaps, but possibly worse than "semi-standard templates with links at the bottom of the page" which we have today. --brion (talk) 16:14, 24 April 2013 (UTC)[reply]
  • Oppose Oppose This would be my next choice after tabs but I would prefer to avoid the sidebar. It is mostly technical tools and functional links as standard and not the place I would normally look for interproject links (nor would I expect a casual user to look there either). Wikivoyage uses the sidebar to keep the links out of the body of the text (which is intended to be just as usable when printed out), which is covered by the tab option as well. - AdamBMorgan (talk) 16:21, 24 April 2013 (UTC)[reply]
  • Oppose Oppose No one notices the sidebar. It's not a problem for interlanguage links, which are sort of pointless, but sister projects are too important to hide. – Ypnypn (talk) 16:44, 24 April 2013 (UTC)[reply]
  • Oppose Oppose - sidebar's already cluttered, and may be on the way out; and there's no need to force a change of design on the projects to get the advantages of Wikidata. Only way I'd support this is if it's possible for a template to override it - so the links are then displayed if no-one's bothered to add an inter-project template to a page, but otherwise hidden. Can't see that happening though.Rd232 (talk) 16:51, 24 April 2013 (UTC)[reply]
    • I see no basis for the assertion that the sidebar is going to go away. There are no plans to ever get rid of the sidebar in Vector. Dantman (talk) 23:49, 24 April 2013 (UTC)[reply]
      • The sidebar has already gone in Mobile Wikipedia. Removing links from the main page content and moving them to the sidebar will make them invisible on mobile. (And while the sidebar is unlikely to be taken out of Vector, it's also unlikely that Vector will remain the default skin forever - remember Monobook used to be the default.) Rd232 (talk) 21:06, 25 April 2013 (UTC)[reply]
  • Support Support above interwiki links, looks like the most suitable option.--Arnaugir (talk) 16:59, 24 April 2013 (UTC)[reply]
  • Unenthusiastic support: It's cheap, but it's better than nothing. --NaBUru38 (talk) 22:13, 24 April 2013 (UTC)[reply]
  • Alternative mockup.
    Support Support This fits in with the defined behaviours of our skins. It's portable to all the skins Wikimedia uses. It can be implemented without hacking core. And as for those pessimistic about the sidebar why don't we use some actual design to make it more visible. Things in the sidebar going unnoticed has nothing to do with them being in the sidebar. It has do do with them being a blob of linked text that's not identifiable at a glance. After all the logo is part of the sidebar but you would never consider that unnoticed. To start with we could include icons for each of the sister projects beside the links. After doing that we could also try other things like wrapping the links in rounded boxes. Adding that would certainly make sister project links stand out. Dantman (talk) 00:35, 25 April 2013 (UTC)[reply]
    • Very good ideas. The image looks great. – Ypnypn (talk) 00:43, 25 April 2013 (UTC)[reply]
    • That's better but I think the sidebar is often used more by active editors than the average reader. Even the grey background colour de-emphasises the section and diverts the eye away and towards the body; if you aren't intentionally looking for it, the sidebar is likely to be ignored. (The exception to this is the interlanguage links section, which I admit are very similar in function and I have no data on how much they are used. The icons would help get a little more attention too.) As it stands, this would be my tertiary choice, after tabs and the dropdown by the title. - AdamBMorgan (talk) 11:55, 25 April 2013 (UTC)[reply]
  • Support Support This area of the skin is already associated by users with interwiki navigation, so it's good place to experiment with ideas for linking to the sister projects. Steven Walling (WMF) • talk 04:32, 25 April 2013 (UTC)[reply]
  • Support Support I'm a fan of the alternative mockup. Legoktm (talk) 04:39, 25 April 2013 (UTC)[reply]
  • Support Support Alt. mock looks good to me as well; some of the favicons may need further polish in practice but it's a good place to start. One additional consideration is whether the focus should be on the projects names as in the mockup, or on the content they provide as in some other approaches. So you could have the Wikisource logo, but the text "Source texts", etc. The "Sister projects" + full project name is very good for promoting the jungle of different brands, but may actually lead to less traffic to the project because readers don't have any idea what the projects stand for. This decision could be made based on data, rather than making a priori assumptions.--Eloquence (talk) 08:06, 25 April 2013 (UTC)[reply]
    • Sure. That can be decided later with some data, very nice if the WMF is so kind as to provide it. I doubt anyone in this section objects to the logos (except that some projects don't have consistent logo and the mockup currently has the wrong one for Wiktionary). --Nemo 08:33, 25 April 2013 (UTC)[reply]
  • Comment Comment: They're still hidden in the bottom of the sidebar, but if I had to choose one of these it would be the alt. Prefer Options 5 and 1. PiRSquared17 (talk) 14:39, 25 April 2013 (UTC)[reply]
  • I agree with Erik. --MZMcBride (talk) 19:24, 25 April 2013 (UTC)[reply]
  • Support Support - Best position to place it and has been considered as very useful for six years now on Wikivoyage. -- DerFussi 16:53, 27 April 2013 (UTC)[reply]
  • Support Support: put it above in the interlanguage links and it will be perfect. But use Wikidata anyway.--TheMillionRabbit 19:52, 27 April 2013 (UTC)[reply]
  • Support Support I like the alternative mock-up, but it misses labels indicating what sister projects host, such as "Quotes" and "Media category."--Erasmo Barresi (talk) 16:33, 29 April 2013 (UTC)[reply]
  • Support Support Far better than nothing; people who are interested will know where to find it and it won't get into anyone's way. Perfect. Red Slash (talk) 00:35, 30 April 2013 (UTC)[reply]
  • Oppose Oppose There shouldn't be anything else depending on the presents of the sidebar. The sidebar hogs valuable screen space that should be used for wiki content. Somethings in the sidebar, like the toolbox should be next to the namespace tab in a drop down menu, and other things should be placed somewhere near the bottom of the page in maybe columns of three or four, like the language interwiki links. --darklama 15:01, 30 April 2013 (UTC)[reply]
  • Neutral Neutral Alt. mock is better, but the sidebar is and will be more cluttered. It is the cheap solution. --Nouill (talk) 19:27, 8 May 2013 (UTC)[reply]
  • Support Support above interwiki links is perfect + Use Wikidata. Liné1 (talk) 18:56, 14 May 2013 (UTC)[reply]
  • Support Support. A logical position to group sister project links near each other. Language links (which really are just another type of sister project) near links to Wikibooks/Wikisource/Wikivoyage make sense. Sjakkalle (talk) 11:57, 28 May 2013 (UTC)[reply]

Option 3: Keep current system

[edit]

Another option is to keep the current system as it is.

Comments

[edit]

Option 4: Current system + Wikidata

[edit]

Each project can keep its current system, and re-develop existing templates to pull the relevant related-project links from Wikidata. This gives the advantage of using Wikidata, with the option to easily override (if for some reason the Wikidata setup doesn't always suit), and more generally allows each project its own design choices.

To be clear: the links would be kept on Wikidata. Thus, if the article Computer gains a page on Wikiquote, all the other projects would immediately gain a link - but their local templates would display it within their preferred layouts.

Comments

[edit]
  • Support as proposer. – Ypnypn (talk) 16:40, 24 April 2013 (UTC)[reply]
  • Support Support (I've taken the liberty of rewriting the Option, as I was about to propose the same and duplication would be bad, hope first proposer doesn't mind). Rd232 (talk) 16:49, 24 April 2013 (UTC)[reply]
  • Oppose Oppose It won't solve one of the main problems, which is Sister Project links being too hidden at the bottom of the page.--Micru (talk) 17:27, 24 April 2013 (UTC)[reply]
    • There's nothing to stop projects putting templates at the top of the page. Rd232 (talk) 18:22, 24 April 2013 (UTC)[reply]
      • That would require a separate option to vote. Besides there is not that much empty space left. The only place could be next to or embedded into the Table of Contents. I am not sure there is a good design that could fit in there, but you can try doing a mockup.--Micru (talk) 19:07, 24 April 2013 (UTC)[reply]
        • That would require a separate option to vote. - no it wouldn't. My point is that projects can do it if they want, not that we should force them to. I agree though that there doesn't seem any good design solution (that I can think of) for making the links more prominent near the top of pages. There's perhaps some potential for making them more prominent at the bottom of pages, with an automatic footer... Rd232 (talk) 19:18, 24 April 2013 (UTC)[reply]
  • Comment Comment this will probably be the default in the future, as we are going to ask the centralization of interprojects links anyway (because it's rational and useful for everyone). But as Micru states doesn't solve many of the issues, at least it won't if we don't find a good template that could be replicated in all projects. I understand option 1 it's fairly strong, and it requires a "paradigm shift" (Wikimedia projects seen as a "knowledge family"), but IMO that it's the direction. --Aubrey (talk) 21:23, 24 April 2013 (UTC)[reply]
  • Support Support, of course this is the solution. One comment: remember that each subject doesn't just have main pages, but also categories, portals, wikiprojects and books. Wikidata item must include these links as well. --NaBUru38 (talk) 22:15, 24 April 2013 (UTC)[reply]
  • Support Support It would relatively easy to do this, as far as I know, and it fits with how Wikidata treats interwiki language links currently. Steven Walling (WMF) • talk 04:37, 25 April 2013 (UTC)[reply]
    The Wikidata team doesn't seem to agree on this, ;) they asked an interface decision. I tend to think they're a more reliable source. --Nemo 08:23, 25 April 2013 (UTC)[reply]
  • Oppose Oppose This is just a more sophisticated version of the existing problem. It doesn't unify or improve the visibility of any project (which, incidentally, includes links to Wikipedia from everywhere else). It still requires the manual addition of a template to the page (which will at best require a bot on each and every project inserting templates if none is there). - AdamBMorgan (talk) 11:27, 25 April 2013 (UTC)[reply]
  • Support Support I can understand why Wikidata wants everything unified, but there's too much that might get destroyed if every project gets forced to file.--Stanzilla (talk) 07:58, 26 April 2013 (UTC)[reply]
  • Oppose Oppose As the template would need to be transcluded on the page for the link to the sister project to appear.--Snaevar (talk) 18:50, 26 April 2013 (UTC)[reply]
  • Comment Comment I think this might be a move in the right direction in terms of being the least drastic of changes. I think some kind of interface would be required though to work because people aren't likely to goto Wikidata every time a new page is added that might be relevant for other projects, and people are likely to be confused if an edit link takes them to a different website. --darklama 15:15, 30 April 2013 (UTC)[reply]
  • Oppose Oppose It doesn't solute the problem of "Interproject links interface" (see the title of the RfC). Wikidata will be use in anyway. So it is similar at "Option 3".--Nouill (talk) 20:03, 8 May 2013 (UTC)[reply]

Option 5: Dropdown next to title

[edit]
Dropdown while open.
Interproject links in title dropdown (version 2)
Interproject links in title dropdown (version by NaBUru38)

Include a dropdown inside the page title that can be used to switch between sister wiki.

Comments

[edit]
  • Support SupportThis option can be done without any hacks to MediaWiki itself (the title markup can be modified from hooks). It's very visible. And having a switch in this location to move between wikis is not counter intuitive like overloading the namespace tabs are. Dantman (talk) 01:02, 25 April 2013 (UTC)[reply]
How will it look when closed? (It should be ovious but not intrusive.) – Ypnypn (talk) 01:34, 25 April 2013 (UTC)[reply]
  • Support Support This would cover everything I would be looking for in terms of standardised interproject links. It's visible but discreet and can presumably be made standard across Wikimedia. I would rate my this as equal to the tab option in meeting my needs and probably slightly superior in terms of appearance and functionality. - AdamBMorgan (talk) 11:42, 25 April 2013 (UTC)[reply]
  • Support Support I would like to see how the drop down menu would like when closed. If it is too visible it will be annoying, if it is too discrete interproject links will be again invisible.--Micru (talk) 13:12, 25 April 2013 (UTC)[reply]
I did an alternative mockup (see right).--Micru (talk) 14:03, 25 April 2013 (UTC)[reply]
[edit]

This option is for a footer, which provides a standardised presentation of wikidata-based interproject links across the bottom of pages. The footer would be in addition to the existing template-based system, which would migrate to the new wikidata setup at its own pace (as in Option 4), and remain a complementary option, with projects and pages choosing whether to use templates in addition to the standard footer.

Interproject links are now usually found near the bottom of pages, together with external links, references and categories. There is a general sense that the bottom of the page is for "related items", for users to follow up who want more or related information. It therefore makes sense to put a standardised presentation of wikidata-based interproject links at the bottom of pages. This also avoids the clutter problem - the top of pages is already full of information. This also allows much greater scope for presentation of the links: more space, prettier designs, more visibility, and easier integration of Edit links. One possible design would be to echo Vector's tab design from the top of the page. Another advantage: a footer approach can more easily be adapted for the Mobile design whilst maintaining a certain consistency (some other options, like Sidebar placement, would require Mobile to do something completely different, since there is no Sidebar on Mobile). Consistency is surely one of the objectives of this standardisation.

This option provides a certain amount of flexibility when combined with the ideas of Option 4. Existing templates can be adapted to pull Wikidata properties into a page, and give particular prominence to sisterproject links that are particularly important on a page, or even to provide alternative links in some situations where the Wikidata setup linking that page with others on other projects doesn't provide a full solution.

Comments

[edit]
  • Support Support Noting that it could conceivably be combined with an unobtrusive version of Option 5, so that you have small and unobtrusive links at the top of the page, and larger and more visible links at the bottom. Rd232 (talk) 11:53, 26 April 2013 (UTC)[reply]
Could you make a mockup? Just to understand better what you mean. Aubrey (talk) 13:37, 26 April 2013 (UTC)[reply]
I'm not very good at that, and it can be done in a wide variety of ways; I'm more interested in the principle. Others are welcome to provide mockups though. Rd232 (talk) 13:53, 26 April 2013 (UTC)[reply]

...

Option 7: Use content to represent the sister sites

[edit]
Design to represent a Wikidata concept as a way to unify information from different Wikimedia projects.

Users are more likely to explore sister sites if they have an idea of what to expect. Making the expected content such as images, quotes and books to surface may help. We can provide an icon for the user to access "additional content". Once the user clicks on the icon, a summary card with aggregated information in a visual manner. Users can access the sister sites through the information on the card. I made a mockup to illustrate the idea, but further though will be required to better determine the icon to use, the location and the visual information of the card.

These cards are potentially linkable so that external sites can also link to a Wikidata concept in the same way.

Comments

[edit]
  • Nice idea, good mockup, but I fear it may require quite a bit of extra work compared to some of the other options. But this is much more appealing and forward-looking than some of the other options, and I'd be happy to see it explored further. Rd232 (talk) 16:01, 30 April 2013 (UTC)[reply]
  • I agree with Rd232. Making sister projects content more prominent in Wikipedia it's probably the Holy Grail :-), but it's a huge work. We should work a lot on transclusion, and probably have the WMF staff dedicated some time to this idea. We culd transclude quotes from Wikiquote, sections of texts from Wikisource, galleries from Commons. I fear that it's paradigm shift that won't happen soon. --Aubrey (talk) 10:36, 1 May 2013 (UTC)[reply]
  • Nice idea, I really like the mockup of the card. I fear that the "+" button is too small and not understandable, though. -Ash Crow (talk) 11:28, 4 May 2013 (UTC)[reply]
  • Great idea! Let's see if we can move it forward! --Micru (talk) 18:54, 29 May 2013 (UTC)[reply]

Option 8:

[edit]

...

Comments

[edit]

...

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