http://devhub.wmflabs.org is a prototype of the "Data and developer hub", a portal and set of articles and links whose goal is to encourage third-party developers to use Wikimedia data and APIs. Check it out, your feedback is welcome! You can comment on the talk page of the project page https://www.mediawiki.org/wiki/dev.wikimedia.org , or file Phabricator tickets in the project dev.wikimedia.org [1].
Since December 2013 Moiz Syed and others discussed creating "a thing" to expose our APIs and data to developers. When S Page moved to WMF tech writer, he wrote some articles for this on mediawiki.org and with Quim Gil developed a landing page from the wireframe designs [2].
The prototype is using the Blueprint skin and running on a labs instance, but the articles are all regular wiki pages on mediawiki.org that we regularly import to http://devhub.wmflabs.org
Thanks to everyone who participated in the gestation of this idea! -- S Page and Quim Gil
== FAQ ==
Q: How can I feature my awesome API or data set? A: Create a task in the #dev.wikimedia.org and #documentation projects [3] with "Article" in the title. You can draft an article yourself, following the guidelines [4].
Q: Yet another site? Arghh! A: Agreed, T101441 "Integrate new Developer hub with mediawiki.org" [5]. It's a separate site for now in order to present a different appearance.
Q: But why a different appearance? Why a separate skin? Our competition for developer mindshare is sites like https://developers.google.com/ . We believe looking like a 2000s wiki page is a *deterrent* to using Wikimedia APIs and data. We hope that many third-party developers join our communities and eventually contribute to MediaWiki, but "How to contribute to MediaWiki" [6] is not the focus, providing free open knowledge is.
Q: Why the Blueprint skin? A: The Design team (now Reading Design) developed it for the OOUI Living Style Guide [7] and it has some nice features: a fixed header, and a sidebar that gets out of the way and combines page navigation and the TOC of the current page.
Q: So why not use the Blueprint skin on mediawiki.org? A: Agreed, T93613 "Deploy Blueprint on mediawiki.org as optional and experimental skin" is a blocker for T101441. We appreciate help with it and its blockers.
Q: I hate the appearance. A: That's not a question :) You can forget the prototype exists and view the same content at https://www.mediawiki.org/wiki/API:Data_and_developer_hub
Q: What is "dev.wikimedia.org"? A: http://dev.wikimedia.org will be the well-known shortcut to the landing page. And dev.wikimedia.org is the project name for this "Data and developer hub".
Q: I thought dev.wikimedia.org was going to integrate source documentation/replace doc.wikimedia.org/enumerate all Wikimedia software projects/cure cancer, what happened? A: One step at a time. For now, its goal is, to repeat, "to encourage third-party developers to use Wikimedia data and APIs".
Q: Why are the pages in the API: namespace? A: That's temporary, they will probably end up in a dev: namespace on mediawiki.org that uses the Blueprint skin by default (T369).
Q: Where are the talk pages? A: It's a bug that the sidebar doesn't have a "Discussion" link (T103785). The talk pages on the prototype all redirect to the talk pages for the original pages on mediawiki.org, and Flow is enabled on them.
[1] https://phabricator.wikimedia.org/maniphest/task/create/?projects=dev.wikime... [2] https://www.mediawiki.org/wiki/Dev.wikimedia.org#Structure [3] https://phabricator.wikimedia.org/maniphest/task/create/?projects=dev.wikime... [4] https://www.mediawiki.org/wiki/dev.wikimedia.org/Contributing [5] https://phabricator.wikimedia.org/T93613 and its blockers [6] https://www.mediawiki.org/wiki/How_to_contribute (a fine general entry point) [7] http://livingstyleguide.wmflabs.org/
S Page wrote:
http://devhub.wmflabs.org is a prototype of the "Data and developer hub", a portal and set of articles and links whose goal is to encourage third-party developers to use Wikimedia data and APIs. Check it out, your feedback is welcome! You can comment on the talk page of the project page https://www.mediawiki.org/wiki/dev.wikimedia.org , or file Phabricator tickets in the project dev.wikimedia.org [1].
Since December 2013 Moiz Syed and others discussed creating "a thing" to expose our APIs and data to developers. When S Page moved to WMF tech writer, he wrote some articles for this on mediawiki.org and with Quim Gil developed a landing page from the wireframe designs [2].
The prototype is using the Blueprint skin and running on a labs instance, but the articles are all regular wiki pages on mediawiki.org that we regularly import to http://devhub.wmflabs.org
I'm glad that we're using mediawiki.org as the data source.
Q: Yet another site? Arghh! A: Agreed, T101441 "Integrate new Developer hub with mediawiki.org" [5]. It's a separate site for now in order to present a different appearance.
Q: But why a different appearance? Why a separate skin? Our competition for developer mindshare is sites like https://developers.google.com/ . We believe looking like a 2000s wiki page is a *deterrent* to using Wikimedia APIs and data. We hope that many third-party developers join our communities and eventually contribute to MediaWiki, but "How to contribute to MediaWiki" [6] is not the focus, providing free open knowledge is.
I don't think a cutesy FAQ section absolves you of your sins. You've created yet another wiki and increased our collective technical debt. I also find the argument that anyone cares about the appearance of documentation over its content a bit insulting.
That said, I appreciate the informative e-mail and the collection of tasks filed for future improvement.
The content of this "data and developer hub" is currently pretty... anemic. Where's the information about database dumps (XML and SQL)? Where's the information about the replicated databases available on Tool Labs? Where's information about how I can take my pre-existing skills in Python, Perl, PHP, Ruby, etc. and use a library or framework to easily retrieve content from Wikimedia in my application or script or bot? Where's information about creating a bot? I clicked over to https://rest.wikimedia.org/ and now I get the strong impression that I need an api_key? Yet I can't find any place where I might generate such a key and I can't find any information about why a key would be necessary.
More to the point: why not just make dev.wikimedia.org a round robin that points to either https://meta.wikimedia.org/wiki/Research:Data or https://www.mediawiki.org/wiki/How_to_contribute? I think it would be a lot more valuable like that. I don't see how pointing people to the Wikidata home page or Commons home page or a list of Wikimedia projects is helpful at all and these are the three most prominent links on the page.
MZMcBride
P.S. If it sounds as though I'm frustrated, it's probably due to the limited design resources we have being allocated pretty much exclusively to dubious microsites like the Transparency Report and this Data and Developer Hub, instead of having design resources devoted to, y'know, improving the real sites that receive billions of views per month.
On Fri, Jun 26, 2015 at 5:53 AM, MZMcBride z@mzmcbride.com wrote:
I also find the argument that anyone cares about the appearance of documentation over its content a bit insulting.
I recommend reading [[Emotional Design https://en.wikipedia.org/wiki/Emotional_Design]] and [[The Design of Everyday Things https://en.wikipedia.org/wiki/The_Design_of_Everyday_Things]]. tl;dr: appearance and design are extremely important to how people perceive and interact with, well, just about everything.
Luis
Thanks for the feedback (seriously).
On Fri, Jun 26, 2015 at 5:53 AM, MZMcBride z@mzmcbride.com wrote:
More to the point: why not just make dev.wikimedia.org a round robin that points to either https://meta.wikimedia.org/wiki/Research:Data or https://www.mediawiki.org/wiki/How_to_contribute? I think it would be a lot more valuable like that.
"How to contribute" is the golden arch for people who want to contribute to free open knowledge. dev.wikimedia.org is for people who want to _take_ it; as I wrote, we hope some of the latter shift to the former. It's tricky to discern how and when to reel 'em in. After T101441 "Integrate new Developer hub with mediawiki .org", I think these pages can become the Web API column under "How to contribute", and we can reduce some redundant redundancy.
P.S. If it sounds as though I'm frustrated, it's probably due to the
limited design resources we have being allocated pretty much exclusively to dubious microsites like the Transparency Report and this Data and Developer Hub, instead of having design resources devoted to, y'know, improving the real sites that receive billions of views per month.
Sure, that's a valid point (though "exclusively" is an exaggeration). The absence of data beyond Luis' "design matters" makes the decision to do yet another site hard and frustrating. I lack the Eloquence to present it calmly; I can do levity and nobody dies if we made the wrong call, but I'm not trivializing it.
Developing a new skin ought to be easier (obviously!). AIUI there isn't a common approach underpinning Blueprint, Minerva (the mobile web skin), Winter, and the Fixed Header and Compact Personal Bar beta features, though the people who worked on them and other skins built up a lot of expertise. https://www.mediawiki.org/wiki/Requests_for_comment/Redo_skin_framework seems stalled .
Regards,
You have to think that the primary audience dev.wikimedia.org wants to attract is the big population of developers that want to build their own projects and know Wikipedia just as users. These developers will ask what Wikimedia can do for them before thinking what can they do for Wikimedia. Contributing to our projects it's not their motivation and maybe not their thinking at all. At least today.
Yet... by using our APIs they will be contributing to spread Wikimedia's free knowledge, and maybe once they learn more about our APIs and our projects they will also contribute to improve that knowledge sending actions from their users in our direction. A portion of those developers might miss a specific feature in an API, or a specific API altogether, and then we can show them our FOSS side, and ask them to share their plans and send us patches.
Still, for each third party developer that ends up contributing code to our projects there will be many more that will remain as third party developers, busy with their own projects. However, if they keep using our APIs more and better, they will also contribute more and better to our mission.
We haven't done much for third party developers, and this dev.wikimedia.org project attempts to change this trend.
On Fri, Jun 26, 2015 at 2:53 PM, MZMcBride z@mzmcbride.com wrote:
I don't see how pointing people to the Wikidata home page or Commons home page or a list of Wikimedia projects is helpful at all and these are the three most prominent links on the page.
Most of these developers don't know what Wikimedia has to offer apart from Wikipedia. They have never heard of Commons or Wikidata, and they have never really thought that they could get from us repositories of media and structured data.
I agree that the homepage of these projects is not the best destination, but this is a pragmatic prototype using what is available. Now imagine that, instead, these three links would point to three pages, each of them introducing these areas (basically text, media, data) and highlighting what developers can do with them.
P.S. If it sounds as though I'm frustrated
Note that probably the complementary side of your frustration is the frustration of designers and others trying to improve Wikimedia and its projects, only to find a strong resistance to change almost every time that fresh ideas are proposed. In our case here, currently we are not very successful at attracting third party developers to use our APIs, definitely not at the scale that one would expect considering Wikipedia's relevance. We welcome ideas and help from people willing to solve this problem. We are happy to take risks trying solutions, even if that means that we will make some mistakes along the way.
On 26/06/15 21:21, Quim Gil wrote:
Note that probably the complementary side of your frustration is the frustration of designers and others trying to improve Wikimedia and its projects, only to find a strong resistance to change almost every time that fresh ideas are proposed. In our case here, currently we are not very successful at attracting third party developers to use our APIs, definitely not at the scale that one would expect considering Wikipedia's relevance. We welcome ideas and help from people willing to solve this problem. We are happy to take risks trying solutions, even if that means that we will make some mistakes along the way.
It should perhaps be noted that this seems a continuation on a general trend to avoid learning how to work with the communities and existing designs. It may be faster and less frustrating to simply sod off and do something new somewhere else, but this does not solve the existing problems - all it does is introduce more inconsistencies and more things that need to be consolidated later, if they survive at all. Except they usually don't, because ignoring what people do and use and expect does not lead to practical designs, it leads to things people don't use, maintain, or contribute to, which brings us back in part to the technical debt associated with having so many different wikis.
But when it comes to working with what already exists, I know from experience that this is far from easy, and in fact often incredibly frustrating in practice. Thing is, though, we have to - the existing products need to be worked with in order to move forward. That's just how it is.
As we tend to say about the unsolicited redesigns of (en) wikipedia, it's always a lot easier when you don't have to design with reality as a constraint. There's a reason we never use any of them.
-I
Isarra Yos wrote:
It should perhaps be noted that this seems a continuation on a general trend to avoid learning how to work with the communities and existing designs. It may be faster and less frustrating to simply sod off and do something new somewhere else, but this does not solve the existing problems - all it does is introduce more inconsistencies and more things that need to be consolidated later, if they survive at all. Except they usually don't, because ignoring what people do and use and expect does not lead to practical designs, it leads to things people don't use, maintain, or contribute to, which brings us back in part to the technical debt associated with having so many different wikis.
But when it comes to working with what already exists, I know from experience that this is far from easy, and in fact often incredibly frustrating in practice. Thing is, though, we have to - the existing products need to be worked with in order to move forward. That's just how it is.
As we tend to say about the unsolicited redesigns of (en) wikipedia, it's always a lot easier when you don't have to design with reality as a constraint. There's a reason we never use any of them.
Yes to all of this.
Quim Gil wrote:
Vector is the skin powering Wikipedia and hundreds of Wikimedia sites (and more), and for this reason changing anything there takes a lot of effort discussing and implementing (see Winter, and see several other projects that took so much time and brought so little changes to our users). We don't have design resources for this project, but we don't want to renounce to bring a fresh look to it. We are recycling a skin that already existed, we are filing bugs, and then Prateek, S, and maybe others contribute whenever they have time, motivated by their willingness to see that fresh look arriving to users.
You're kind of defeating your own argument here. You start by saying you have no design resources, then continue on by listing the people who are contributing time and code (which I'd call resources).
Meanwhile Vector is, in fact, in desperate need of design love. Creating a separate wiki and skin is adding to our technical debt, instead of really moving us forward by working on the skin that's seen by hundreds of millions of people. That was my takeaway from Isarra's post.
MZMcBride
On Thu, Jul 9, 2015 at 5:15 AM, MZMcBride z@mzmcbride.com wrote:
Quim Gil wrote:
Vector is the skin powering Wikipedia and hundreds of Wikimedia sites (and more), and for this reason changing anything there takes a lot of effort discussing and implementing (see Winter, and see several other projects that took so much time and brought so little changes to our users). We don't have design resources for this project, but we don't want to renounce to bring a fresh look to it. We are recycling a skin that already existed, we are filing bugs, and then Prateek, S, and maybe others contribute whenever they have time, motivated by their willingness to see that fresh look arriving to users.
You're kind of defeating your own argument here. You start by saying you have no design resources, then continue on by listing the people who are contributing time and code (which I'd call resources).
I'll try to be clearer. We don't have any *committed* design resources for this project. We are not stopping anybody willing to contribute their own time in our project, writing Blueprint skin patches or in any other way.
Meanwhile Vector is, in fact, in desperate need of design love. Creating a separate wiki and skin is adding to our technical debt, instead of really moving us forward by working on the skin that's seen by hundreds of millions of people. That was my takeaway from Isarra's post.
I will just repeat that today our plan for this documentation project is to improve an existing namespace in an existing wiki, and to use an existing skin that provides the UI we are looking for.
Il 26/06/2015 01:09, S Page ha scritto:
Our competition for developer mindshare is sites like https://developers.google.com/ .
"Act fast when you see a new opportunity and monetize your web content with just a small snippet of JavaScript." vs "Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment."
Competition?
On 6/25/15, S Page spage@wikimedia.org wrote:
http://devhub.wmflabs.org is a prototype of the "Data and developer hub", a portal and set of articles and links whose goal is to encourage third-party developers to use Wikimedia data and APIs. Check it out, your feedback is welcome! You can comment on the talk page of the project page https://www.mediawiki.org/wiki/dev.wikimedia.org , or file Phabricator tickets in the project dev.wikimedia.org [1].
Since December 2013 Moiz Syed and others discussed creating "a thing" to expose our APIs and data to developers. When S Page moved to WMF tech writer, he wrote some articles for this on mediawiki.org and with Quim Gil developed a landing page from the wireframe designs [2].
The prototype is using the Blueprint skin and running on a labs instance, but the articles are all regular wiki pages on mediawiki.org that we regularly import to http://devhub.wmflabs.org
Thanks to everyone who participated in the gestation of this idea! -- S Page and Quim Gil
== FAQ ==
Q: How can I feature my awesome API or data set? A: Create a task in the #dev.wikimedia.org and #documentation projects [3] with "Article" in the title. You can draft an article yourself, following the guidelines [4].
Q: Yet another site? Arghh! A: Agreed, T101441 "Integrate new Developer hub with mediawiki.org" [5]. It's a separate site for now in order to present a different appearance.
Q: But why a different appearance? Why a separate skin? Our competition for developer mindshare is sites like https://developers.google.com/ . We believe looking like a 2000s wiki page is a *deterrent* to using Wikimedia APIs and data. We hope that many third-party developers join our communities and eventually contribute to MediaWiki, but "How to contribute to MediaWiki" [6] is not the focus, providing free open knowledge is.
Q: Why the Blueprint skin? A: The Design team (now Reading Design) developed it for the OOUI Living Style Guide [7] and it has some nice features: a fixed header, and a sidebar that gets out of the way and combines page navigation and the TOC of the current page.
Q: So why not use the Blueprint skin on mediawiki.org? A: Agreed, T93613 "Deploy Blueprint on mediawiki.org as optional and experimental skin" is a blocker for T101441. We appreciate help with it and its blockers.
Q: I hate the appearance. A: That's not a question :) You can forget the prototype exists and view the same content at https://www.mediawiki.org/wiki/API:Data_and_developer_hub
Q: What is "dev.wikimedia.org"? A: http://dev.wikimedia.org will be the well-known shortcut to the landing page. And dev.wikimedia.org is the project name for this "Data and developer hub".
Q: I thought dev.wikimedia.org was going to integrate source documentation/replace doc.wikimedia.org/enumerate all Wikimedia software projects/cure cancer, what happened? A: One step at a time. For now, its goal is, to repeat, "to encourage third-party developers to use Wikimedia data and APIs".
Q: Why are the pages in the API: namespace? A: That's temporary, they will probably end up in a dev: namespace on mediawiki.org that uses the Blueprint skin by default (T369).
Q: Where are the talk pages? A: It's a bug that the sidebar doesn't have a "Discussion" link (T103785). The talk pages on the prototype all redirect to the talk pages for the original pages on mediawiki.org, and Flow is enabled on them.
[1] https://phabricator.wikimedia.org/maniphest/task/create/?projects=dev.wikime... [2] https://www.mediawiki.org/wiki/Dev.wikimedia.org#Structure [3] https://phabricator.wikimedia.org/maniphest/task/create/?projects=dev.wikime... [4] https://www.mediawiki.org/wiki/dev.wikimedia.org/Contributing [5] https://phabricator.wikimedia.org/T93613 and its blockers [6] https://www.mediawiki.org/wiki/How_to_contribute (a fine general entry point) [7] http://livingstyleguide.wmflabs.org/ -- =S Page WMF Tech writer _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
So at first, I had a little trouble wrapping my mind around the intended goals of this project. But I think I understand now.
In essence, this is an advertisement aimed at programmers not associated with the Wikimedia movement, to use various Wikimedia APIs in their programming projects that are unrelated to Wikimedia. In a sense, targeting these programmers as a distinct group of users, and trying to convince them to use our "product".
Is that right? If it isn't, may I suggest that this should be the intended purpose?
If so, I think the content of the developer hub should have a little bit of a different focus. It should concentrate on things that make us unique, and things that are likely to have wide applicability and value outside of Wikimedia.
First of all, the links at the beginning, should not go directly to the projects in question, they should go to pages explaining how to use those projects in question on the outside. If they wanted to just visit the wiki, they would have done that (Perhaps, this was already planned, and the current version is still just an early draft with not all the pieces in place yet?)
Second, the existing showcased projects, seem to much like the sort of thing someone making a mobile Wikipedia App would want. Most people probably don't want article excerpts in their search results (I assume anyways). Most people aren't searching through a list of Wikipedia articles, unless they are wikipedia or related to wikipedia.
But we do have one of the largest collections of (mostly) organized knowledge available for free (In both senses of the word). This is valuable, and quite unique on the internet. We should capitalize on this.
Things like "Show a short snippet about this topic from Wikipedia" (+ a link to more information) could be quite useful to many people. After all lots of people have websites having pages about various things (In order for there users to rate, discuss, etc), maybe that'd want an easy to add widget explaining the topic at hand.
Commons is another great resource because its information can be easily broken up into digestible parts like a single image (Which is much harder for a Wikipedia article). I think things like https://www.mediawiki.org/wiki/PhotoCommons which would allow a website operator to quickly allow their users to add stock photos to whatever it is their users do, is a good thing to focus on.
Wikidata seems almost custom made for the type of user who would like to add cusom knowledge to their website.
The other thing that should definitely be on the dev hub, is probably a link to our terms. We should emphasize that you can use your data, and we generally don't track you the way a facebook like button does. That you don't need an api key or anyone's permission. Of course we should also state what you do need to do (Give credit/follow license, set a user-agent header)
-----
However, I might be wrong about the intended direction of the dev hub (Also, the name is very confusing. The very fact that in [[mw:dev.wikimedia.org]], it states its not for MediaWiki "hackers" despite the fact that in our community (And particularly in the larger Wikimedia community), "developer" as a word is much more commonly used than the word "hacker" is, for what the document means by "hacker", should attest to the confusingness of the nomenclature).
In particular the proposed persona's suggest a different target than what I commented above. To quote:
- Ankita, mobile developer willing to use Wikimedia data to enhance mobile apps.
- Alberto, data scientist employed at an organization gathering and releasing data that could be synced with Wikimedia's.
- Reetta, cultural activist working on mass-upload activities for public institutions.
- Yanhui, academic researcher needing a massive data set to sustain his thesis.
I think these four users have too broad an interest to be effectively handled by one hub (maybe). I think the focus should be mostly on "Ankita", with a somewhat prominent link to the research hub for Yanhui.
If the goal is truly to focus on people who are not Wikimedians, than "Alberto" seems mostly out of scope, as syncing data with Wikimedia is inherently interacting the the Wikimedia community (Unless you mean syncing data unidirectionally away from Wikimedia).
I'm not sure what to make of "Reetta". If they are uploading to commons, than they are clearly involved in the Wikimedia community, and furthermore, if we are requiring our glam coordinators to build bots from scratch with the API, we are failing in other ways (but that's a side topic for another email). If you mean in another direction, it seems somewhat unlikely that a cultural institution would want to mass upload commons to somewhere else, but even if they did, I would still consider that to be an activity quite integrated with the Wikimedia community (Or should be).
Thanks, Bawolff
On Sun, Jul 5, 2015 at 10:41 PM, Brian Wolff bawolff@gmail.com wrote:
First of all, the links at the beginning, should not go directly to the projects in question, they should go to pages explaining how to use those projects in question on the outside.
Agreed, T104282 'Create landing pages for the free open knowledge sources on the Data and Developer Hub.'
If they wanted to just visit the wiki, they would have done that (Perhaps, this was already planned, and the current version is still just an early draft with not all the pieces in place yet?)
Second, the existing showcased projects, seem to much like the sort of thing someone making a mobile Wikipedia App would want. Most people probably don't want article excerpts in their search results (I assume anyways). Most people aren't searching through a list of Wikipedia articles, unless they are wikipedia or related to wikipedia.
But we do have one of the largest collections of (mostly) organized knowledge available for free (In both senses of the word). This is valuable, and quite unique on the internet. We should capitalize on this.
Things like "Show a short snippet about this topic from Wikipedia" (+ a link to more information) could be quite useful to many people.
Sure, that's Hovercards. It's a subset of http://devhub.wmflabs.org/wiki/API:Page_info_in_search_results#Showing_usefu... and I mention it at the end. Should we provide more than sample API calls? Would a JS module that formats the results be useful?
The interesting challenge is how to identify "this topic". Will websites manually link to Michael Jackson (radio commentator) https://en.wikipedia.org/wiki/Michael_Jackson_%28radio_commentator%29 or just link "Michael Jackson" and hope for the best? Should we be evangelizing wikidata numbers like Q6831566 for external apps?
Another thing sites can do is related content, I just learned about CirrusSearch's morelike: search operator. https://en.wikipedia.org/w/api.php?action=query&list=search&srsearch... . Such page retrieval and searches all tend to query for lead image and textextract or wikitext description, so articles on them would overlap, but that's OK.
Commons is another great resource because its information can be
easily broken up into digestible parts like a single image (Which is much harder for a Wikipedia article). I think things like https://www.mediawiki.org/wiki/PhotoCommons which would allow a website operator to quickly allow their users to add stock photos to whatever it is their users do, is a good thing to focus on.
Wikidata seems almost custom made for the type of user who would like to add cusom knowledge to their website.
https://www.mediawiki.org/wiki/Dev.wikimedia.org/Contributing , you can propose these and if you know of examples doing this, even better.
The other thing that should definitely be on the dev hub, is probably a link to our terms. We should emphasize that you can use your data, and we generally don't track you the way a facebook like button does. That you don't need an api key or anyone's permission. Of course we should also state what you do need to do (Give credit/follow license, set a user-agent header)
Yup T317 '"Terms of Use" must be prominently featured in the Developer Hub'. I was thinking of mentioning it in the three adding it to the footer, but maybe that's not prominent enough.
Great feedback, thanks.
On 7/6/15, S Page spage@wikimedia.org wrote:
On Sun, Jul 5, 2015 at 10:41 PM, Brian Wolff bawolff@gmail.com wrote:
First of all, the links at the beginning, should not go directly to the projects in question, they should go to pages explaining how to use those projects in question on the outside.
Agreed, T104282 'Create landing pages for the free open knowledge sources on the Data and Developer Hub.'
If they wanted to just visit the wiki, they would have done that (Perhaps, this was already planned, and the current version is still just an early draft with not all the pieces in place yet?)
Second, the existing showcased projects, seem to much like the sort of thing someone making a mobile Wikipedia App would want. Most people probably don't want article excerpts in their search results (I assume anyways). Most people aren't searching through a list of Wikipedia articles, unless they are wikipedia or related to wikipedia.
But we do have one of the largest collections of (mostly) organized knowledge available for free (In both senses of the word). This is valuable, and quite unique on the internet. We should capitalize on this.
Things like "Show a short snippet about this topic from Wikipedia" (+ a link to more information) could be quite useful to many people.
Sure, that's Hovercards. It's a subset of http://devhub.wmflabs.org/wiki/API:Page_info_in_search_results#Showing_usefu... and I mention it at the end. Should we provide more than sample API calls? Would a JS module that formats the results be useful?
Well not precisely hovercards (Although it is the same idea). Hovercards is basically a rewrite of NavPopups with a more "aesthetic" UI. As such ultimately its targeted at ourselves. Ideally we would emphasize things that fully target outsiders, as they are the audience of this. We don't want people to think, "oh here's some code from the Wikipedia website I could maybe sort of reuse", we want them to think "Oh here's some awesome way I could augment my project with information from Wiki[pm]edia. Alas, we don't have a wide pool of projects to draw on that are targeted at outisders as the first (and perhaps only) intended user, and making new ones would probably be a lot of effort that I'm not sure anyone at the moment would volunteer to do...
But yes, maybe a js snippet that people could just insert into pages that display roughtly what a hovercard would, might be a good idea. I was kind of thinking of, how you often see movie related sites display imdb widegts with a films rating.
The interesting challenge is how to identify "this topic". Will websites manually link to Michael Jackson (radio commentator) https://en.wikipedia.org/wiki/Michael_Jackson_%28radio_commentator%29 or just link "Michael Jackson" and hope for the best? Should we be evangelizing wikidata numbers like Q6831566 for external apps?
Well, as the saying goes, "There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors". I don't think there are easy answers to this one that will satisfy all users, and ultimately that may be getting to far into an implementation to worry about, at least at this stage.
Another thing sites can do is related content, I just learned about CirrusSearch's morelike: search operator. https://en.wikipedia.org/w/api.php?action=query&list=search&srsearch... . Such page retrieval and searches all tend to query for lead image and textextract or wikitext description, so articles on them would overlap, but that's OK.
Commons is another great resource because its information can be
easily broken up into digestible parts like a single image (Which is much harder for a Wikipedia article). I think things like https://www.mediawiki.org/wiki/PhotoCommons which would allow a website operator to quickly allow their users to add stock photos to whatever it is their users do, is a good thing to focus on.
Wikidata seems almost custom made for the type of user who would like to add cusom knowledge to their website.
https://www.mediawiki.org/wiki/Dev.wikimedia.org/Contributing , you can propose these and if you know of examples doing this, even better.
Wikidata is so new (especially given the status of its querying ability), I'll be honest I haven't seen much in the way of doing things like this. But it seems brimming with potential.
The other thing that should definitely be on the dev hub, is probably a link to our terms. We should emphasize that you can use your data, and we generally don't track you the way a facebook like button does. That you don't need an api key or anyone's permission. Of course we should also state what you do need to do (Give credit/follow license, set a user-agent header)
Yup T317 '"Terms of Use" must be prominently featured in the Developer Hub'. I was thinking of mentioning it in the three adding it to the footer, but maybe that's not prominent enough.
Terms Of Use were slightly different than what I had in mind. More a friendly paragraph explaining responsibilities (Attribution, SA). Terms of use is rather long legal document, that mostly satisfies the needs of the WMF legal department (which don't get me wrong is important, and should be linked to definitely) than what the community feels is most important when reusing content.
-- bawolff
On Jul 6, 2015 01:13, "S Page" spage@wikimedia.org wrote:
On Sun, Jul 5, 2015 at 10:41 PM, Brian Wolff bawolff@gmail.com wrote:
First of all, the links at the beginning, should not go directly to the projects in question, they should go to pages explaining how to use those projects in question on the outside.
Agreed, T104282 'Create landing pages for the free open knowledge sources on the Data and Developer Hub.'
If they wanted to just visit the wiki, they would have done that (Perhaps, this was already planned, and the current version is still just an early draft with not all the pieces in place yet?)
Second, the existing showcased projects, seem to much like the sort of thing someone making a mobile Wikipedia App would want. Most people probably don't want article excerpts in their search results (I assume anyways). Most people aren't searching through a list of Wikipedia articles, unless they are wikipedia or related to wikipedia.
But we do have one of the largest collections of (mostly) organized knowledge available for free (In both senses of the word). This is valuable, and quite unique on the internet. We should capitalize on this.
Things like "Show a short snippet about this topic from Wikipedia" (+ a link to more information) could be quite useful to many people.
Sure, that's Hovercards. It's a subset of
http://devhub.wmflabs.org/wiki/API:Page_info_in_search_results#Showing_usefu...
and I mention it at the end. Should we provide more than sample API calls? Would a JS module that formats the results be useful?
The interesting challenge is how to identify "this topic". Will websites manually link to Michael Jackson (radio commentator) https://en.wikipedia.org/wiki/Michael_Jackson_%28radio_commentator%29 or just link "Michael Jackson" and hope for the best? Should we be evangelizing wikidata numbers like Q6831566 for external apps?
Yes. Having clear identifiers for identifying concepts for these usecases is exactly what Wikidata identifiers are made for.
Another thing sites can do is related content, I just learned about CirrusSearch's morelike: search operator.
https://en.wikipedia.org/w/api.php?action=query&list=search&srsearch...
. Such page retrieval and searches all tend to query for lead image and textextract or wikitext description, so articles on them would overlap,
but
that's OK.
Commons is another great resource because its information can be
easily broken up into digestible parts like a single image (Which is much harder for a Wikipedia article). I think things like https://www.mediawiki.org/wiki/PhotoCommons which would allow a website operator to quickly allow their users to add stock photos to whatever it is their users do, is a good thing to focus on.
Wikidata seems almost custom made for the type of user who would like to add cusom knowledge to their website.
https://www.mediawiki.org/wiki/Dev.wikimedia.org/Contributing , you can propose these and if you know of examples doing this, even better.
The other thing that should definitely be on the dev hub, is probably a link to our terms. We should emphasize that you can use your data, and we generally don't track you the way a facebook like button does. That you don't need an api key or anyone's permission. Of course we should also state what you do need to do (Give credit/follow license, set a user-agent header)
Yup T317 '"Terms of Use" must be prominently featured in the Developer Hub'. I was thinking of mentioning it in the three adding it to the
footer,
but maybe that's not prominent enough.
Great feedback, thanks.
=S Page WMF Tech writer _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I want to address Isarra's feedback (below), but before let me complete S's reply to Brian.
On Mon, Jul 6, 2015 at 7:41 AM, Brian Wolff bawolff@gmail.com wrote:
In essence, this is an advertisement aimed at programmers not associated with the Wikimedia movement, to use various Wikimedia APIs in their programming projects that are unrelated to Wikimedia. In a sense, targeting these programmers as a distinct group of users, and trying to convince them to use our "product".
Is that right? If it isn't, may I suggest that this should be the intended purpose?
This is the intended purpose, yes. The rest of your reply is spot on.
Comments:
If so, I think the content of the developer hub should have a little
bit of a different focus. It should concentrate on things that make us unique, and things that are likely to have wide applicability and value outside of Wikimedia.
Yes. We have been underestimating the importance of looking at our APIs with external eyes. We are so used to look at our own use cases, and so do most of the developers S relies on to document APIs. Proposals for projects / people we should contact and interview to gather ideas are welcome.
(Also, the name is very confusing.
After more than a year we haven't solved the problem of finding a clean association with "developer" for the many reasons many people have provided. It has been proven difficult to add the "data" aspect too. The feedback received after the announcement of the prototype confirms this problem.
As a solution, I'm proposing to focus on the Api aspect, improving the Api: namespace in mediawiki..org and finding a project name that stresses the Api aspect. Once the discussion about the namespace at https://www.mediawiki.org/wiki/Thread:Project:Current_issues/Adding_a_dev_na...) is resolved, we will rename the project accordingly.
The very fact that in
[[mw:dev.wikimedia.org]], it states its not for MediaWiki "hackers" despite the fact that in our community (And particularly in the larger Wikimedia community), "developer" as a word is much more commonly used than the word "hacker" is, for what the document means by "hacker", should attest to the confusingness of the nomenclature).
Yes, yes, edited.
In particular the proposed persona's suggest a different target than
what I commented above.
Also agreed, and as soon as the namespace discussion is clear, we will update those personas accordingly. The more we got into details, the clearer it has been that we should narrow the focus of this project. Let's produce something interesting and useful for those third party developers that could use our web Apis in their own projects. We also need to make happy the other personas, but one step at a time.
On Thu, Jul 2, 2015 at 9:15 PM, Isarra Yos zhorishna@gmail.com wrote:
It should perhaps be noted that this seems a continuation on a general trend to avoid learning how to work with the communities and existing designs. It may be faster and less frustrating to simply sod off and do something new somewhere else, but this does not solve the existing problems
- all it does is introduce more inconsistencies and more things that need
to be consolidated later, if they survive at all. Except they usually don't, because ignoring what people do and use and expect does not lead to practical designs, it leads to things people don't use, maintain, or contribute to, which brings us back in part to the technical debt associated with having so many different wikis.
But when it comes to working with what already exists, I know from experience that this is far from easy, and in fact often incredibly frustrating in practice. Thing is, though, we have to - the existing products need to be worked with in order to move forward. That's just how it is.
As we tend to say about the unsolicited redesigns of (en) wikipedia, it's always a lot easier when you don't have to design with reality as a constraint. There's a reason we never use any of them.
The problem I have with this reasoning is that we are not proposing a different skin for Wikipedia. The design of this site doesn't need to be efficient for the multiple use cases and the heavy legacy of Wikipedia. There is more than Vector out there. We can allow ourselves to experiment with something fresh, and then fine tune or revert.
Vector is the skin powering Wikipedia and hundreds of Wikimedia sites (and more), and for this reason changing anything there takes a lot of effort discussing and implementing (see Winter, and see several other projects that took so much time and brought so little changes to our users). We don't have design resources for this project, but we don't want to renounce to bring a fresh look to it. We are recycling a skin that already existed, we are filing bugs, and then Prateek, S, and maybe others contribute whenever they have time, motivated by their willingness to see that fresh look arriving to users.
It is not strange to find developer sites not following the user experience of their super-popular products. This gives them freedom from the "product people" and this allows them to focus on the specific purpose and audience of their developer sites. Having a skin deployed in mediawiki.org that looks contemporary and not-like-Vector, not-like-Wikipedia cannot be harmful. As said, the worse that can happen is that we must revert and fallback to Vector. Fine, at least we can say that we tried.
On 06/07/15 16:41, Quim Gil wrote:
The problem I have with this reasoning is that we are not proposing a different skin for Wikipedia.
This has nothing to do with skins. This is making another new site when we already have sites that could serve this purpose, that are already /supposed/ to serve this purpose. We have portals on mw.org, on meta, on wikitech, and places where the documentation should be... but instead of cleaning that up, making the mainpages more informative and useful and directing the different types of users to the correct places, filling in the information itself, we need another site? Why?
On Mon, Jul 6, 2015 at 9:34 PM, Isarra Yos zhorishna@gmail.com wrote:
On 06/07/15 16:41, Quim Gil wrote:
The problem I have with this reasoning is that we are not proposing a different skin for Wikipedia.
This has nothing to do with skins. This is making another new site when we already have sites that could serve this purpose, that are already /supposed/ to serve this purpose. We have portals on mw.org, on meta, on wikitech, and places where the documentation should be... but instead of cleaning that up, making the mainpages more informative and useful and directing the different types of users to the correct places, filling in the information itself, we need another site? Why?
Sorry for my misunderstanding. Then we agree.
Right now the proposal is to improve the API: namespace in mediawiki.org, instead of creating a new Dev: namespace in mediawiki.org. See and join https://www.mediawiki.org/wiki/Project:Current_issues#Adding_a_dev_namespace...
The very initial plan was to have a new site indeed, but that was a long ago, and I pushed (hard) to go for a solution integrated with mediawiki.org.
On 07/07/15 08:07, Quim Gil wrote:
Sorry for my misunderstanding. Then we agree.
Right now the proposal is to improve the API: namespace in mediawiki.org, instead of creating a new Dev: namespace in mediawiki.org. See and join https://www.mediawiki.org/wiki/Project:Current_issues#Adding_a_dev_namespace...
The very initial plan was to have a new site indeed, but that was a long ago, and I pushed (hard) to go for a solution integrated with mediawiki.org.
Ah, cool. I missed that.
wikitech-l@lists.wikimedia.org