Mavericks has something similar:
I wonder what will happen if one of our breaking api changes fucks one of these queries... They are probably running a proxy cached service to avoid any of those problems.
On Fri, Jun 5, 2015 at 7:48 PM, Corey Floyd cfloyd@wikimedia.org wrote:
@Jon you also 3-finger click to get that popover - or if you have a fancy new force touch track pad you can just push really hard.
On Fri, Jun 5, 2015 at 1:34 PM, Brian Gerstle bgerstle@wikimedia.org wrote:
Our users also *really* want popovers (have a 1-star review on our current version in the US app store complaining we don't have link preview yet).
On Fri, Jun 5, 2015 at 1:32 PM, Jon Katz jkatz@wikimedia.org wrote:
I love this feature and it has changed how I read. Do we know of any browser extensions that do same? Yosemite has a native spotlight built-in that works in any browser (I'm using chrome), but it is hard to discover (command-ctrl-d).
Meta screenshot: [image: Inline image 2]
On Fri, Jun 5, 2015 at 9:49 AM, Luis Villa lvilla@wikimedia.org wrote:
FWIW, they are also doing basically the same thing in the e-ink hardware Kindles.
On Fri, Jun 5, 2015 at 8:25 AM, Dmitry Brant dbrant@wikimedia.org wrote:
+mobile-l
On Fri, Jun 5, 2015 at 11:23 AM, Adam Baso abaso@wikimedia.org wrote:
Okay to move this to mobile-l?
On Friday, June 5, 2015, Brian Gerstle bgerstle@wikimedia.org wrote:
> While they strip out links/citations, they do preserve text > formatting (italics & bold). > > On Fri, Jun 5, 2015 at 10:39 AM, Bernd Sitzmann <bernd@wikimedia.org > > wrote: > >> Nice find. I also like being able to swipe those cards left/right >> between different information sources. Looks like depending on the selected >> words it's: Dictionary, Wikipedia, Translation >> >> On Thu, Jun 4, 2015 at 10:45 PM, Dmitry Brant <dbrant@wikimedia.org >> > wrote: >> >>> I was using the Kindle app on the plane today, and I noticed a few >>> interesting things, including this: >>> >>> device-2015-06-04-225651.png >>> https://docs.google.com/a/wikimedia.org/file/d/0BzcksMsMNpY1SzA3bHY4WF9hM1U/edit?usp=drive_web >>> >>> When highlighting a word or phrase, the user is presented with a >>> definition of the word from Wikipedia. The content is presented in a native >>> component, with only the first section of text shown (all links, >>> references, infoboxes, etc. are stripped out). (I wonder what API they're >>> using?) >>> >>> It looks very similar to the link preview prototypes we've been >>> developing in our apps, and it's very telling that the Kindle app has such >>> a feature, since it helps emphasize the usefulness of this feature in any >>> kind of "reader" app. Perhaps, in addition to link previews, we may also >>> want to think about allowing users to highlight words and show definitions >>> (from Wiktionary?), pronunciations, translations, etc... >>> >>> >>> p.s. I was able to get the Kindle app to crash by clicking a link >>> inside one of the Wikipedia "previews" that wasn't stripped out correctly. >>> In other words, no app is safe from the edge cases of wikitext! >>> >>> >>> _______________________________________________ >>> reading-wmf mailing list >>> reading-wmf@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/reading-wmf >>> >>> >> >> _______________________________________________ >> reading-wmf mailing list >> reading-wmf@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/reading-wmf >> >> > > > -- > EN Wikipedia user page: > https://en.wikipedia.org/wiki/User:Brian.gerstle > IRC: bgerstle >
reading-wmf mailing list reading-wmf@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/reading-wmf
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation *Working towards a world in which every single human being can freely share in the sum of all knowledge.*
reading-wmf mailing list reading-wmf@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/reading-wmf
reading-wmf mailing list reading-wmf@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/reading-wmf
-- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle
reading-wmf mailing list reading-wmf@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/reading-wmf
-- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation
reading-wmf mailing list reading-wmf@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/reading-wmf
On Thu, Jun 4, 2015 at 10:45 PM, Dmitry Brant dbrant@wikimedia.org wrote:
(I wonder what API they're using?)
api.log logs all API requests, but doesn't include referer. Cross-referencing warnings in api-feature-usage (below) suggests at least some requests like
action=query format=json titles=dotage redirects= prop=revisions rvprop=content rvlimit=1 rvsection=0 followed by action=parse format=json title=Dotage text=%7B%7Bwiktionary%20redirect%7D%7D%7B%7BShort%20pages%20monitor%7D%7D (the "Dotage" article returns a rather unhelpful {{wiktionary redirect}}{{Short pages monitor}}).
So Kindle sometimes retrieves the wikitext of the zero section of the article, then requests a parse of it. Using TextExtracts would be so much better, prop=extracts&exintro= would give similar info in a single API call.
On Fri, Jun 5, 2015 at 7:39 AM, Bernd Sitzmann bernd@wikimedia.org wrote:
Nice find. I also like being able to swipe those cards left/right between different information sources. Looks like depending on the selected words it's: Dictionary, Wikipedia, Translation
That is awesome. Link preview and Hovercards should do the same, we do little to surface content in the non-pedia wikis beyond {{Sister project links}} at the bottom of some articles. (Hovercards would have a row of icons as well as the swipe gesture). Which raises the question where should I phile a Reading proposal like that, rather than for each app's implementation of link preview and hovercards?
[Apple's OS-level integration]] Link preview and Hovercards work on a link. But wikis intentionally only link the first use of a term and don't link every term per MOS: overlinking https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Linking#Overlinking, which means I often scroll backwards searching for the first mention of a term. It would be nice if there were an affordance to be able to lookup any text, even if not explicitly linked.
Maybe WMF should offer its own browser- or OS-level integration, pushing the reading experience way beyond our sites. https://en.wikipedia.org/wiki/Wikipedia:Tools/Browser_tools lists various browser addons, such as Lookup companion for Wiki https://chrome.google.com/webstore/detail/lookup-companion-for-wiki/dhgpkiiipkgmckicafkhcihkcldbdeej?hl=en that do this. Meanwhile https://en.wikipedia.org/wiki/Wikipedia:Tools#Searching has "Download 1-Click Answers Wikipedia Edition for Windows (beta) and then Alt-Click on any word in any program on your screen for instant, accurate facts." Who knew?!, makes me want to bust out Windows 2000 :)
On Fri, Jun 5, 2015 at 10:59 AM, Joaquin Oltra Hernandez < jhernandez@wikimedia.org> wrote:
I wonder what will happen if one of our breaking api changes [breaks] one of these queries... They are probably running a proxy cached service to avoid any of those problems.
Good point. I'll forward to Kourosh, who deals with partnerships like this, and we can only hope people writing all these tools are on some mailing list.
fluorine:/a/mw-logs/api-feature-usage.log has a number of 2015-06-07 06:26:39 mw1232 enwiki api-feature-usage INFO: "action=query&!rawcontinue&!continue" from user agents containing "Kindle". ApiQuery.php logs this along with the warning in the API result "Formatting of continuation data will be changing soon. ..." So I hope someone notices the warnings in API responses.
-- =S Page WMF Tech writer
Great find! Since we're mentioning similar features, the Google Dictionary https://chrome.google.com/webstore/detail/google-dictionary-by-goog/mgijmajocgfcbeboacabfgobmjgjcoja Chromium / Chrome extension (by Google) performs a similar function.
[image: Inline image 1]
--stephen
On Mon, Jun 8, 2015 at 2:04 AM, S Page spage@wikimedia.org wrote:
On Thu, Jun 4, 2015 at 10:45 PM, Dmitry Brant dbrant@wikimedia.org wrote:
(I wonder what API they're using?)
api.log logs all API requests, but doesn't include referer. Cross-referencing warnings in api-feature-usage (below) suggests at least some requests like
action=query format=json titles=dotage redirects= prop=revisions rvprop=content rvlimit=1 rvsection=0 followed by action=parse format=json title=Dotage text=%7B%7Bwiktionary%20redirect%7D%7D%7B%7BShort%20pages%20monitor%7D%7D (the "Dotage" article returns a rather unhelpful {{wiktionary redirect}}{{Short pages monitor}}).
So Kindle sometimes retrieves the wikitext of the zero section of the article, then requests a parse of it. Using TextExtracts would be so much better, prop=extracts&exintro= would give similar info in a single API call.
On Fri, Jun 5, 2015 at 7:39 AM, Bernd Sitzmann bernd@wikimedia.org wrote:
Nice find. I also like being able to swipe those cards left/right between different information sources. Looks like depending on the selected words it's: Dictionary, Wikipedia, Translation
That is awesome. Link preview and Hovercards should do the same, we do little to surface content in the non-pedia wikis beyond {{Sister project links}} at the bottom of some articles. (Hovercards would have a row of icons as well as the swipe gesture). Which raises the question where should I phile a Reading proposal like that, rather than for each app's implementation of link preview and hovercards?
[Apple's OS-level integration]] Link preview and Hovercards work on a link. But wikis intentionally only link the first use of a term and don't link every term per MOS: overlinking https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Linking#Overlinking, which means I often scroll backwards searching for the first mention of a term. It would be nice if there were an affordance to be able to lookup any text, even if not explicitly linked.
Maybe WMF should offer its own browser- or OS-level integration, pushing the reading experience way beyond our sites. https://en.wikipedia.org/wiki/Wikipedia:Tools/Browser_tools lists various browser addons, such as Lookup companion for Wiki https://chrome.google.com/webstore/detail/lookup-companion-for-wiki/dhgpkiiipkgmckicafkhcihkcldbdeej?hl=en that do this. Meanwhile https://en.wikipedia.org/wiki/Wikipedia:Tools#Searching has "Download 1-Click Answers Wikipedia Edition for Windows (beta) and then Alt-Click on any word in any program on your screen for instant, accurate facts." Who knew?!, makes me want to bust out Windows 2000 :)
On Fri, Jun 5, 2015 at 10:59 AM, Joaquin Oltra Hernandez < jhernandez@wikimedia.org> wrote:
I wonder what will happen if one of our breaking api changes [breaks] one of these queries... They are probably running a proxy cached service to avoid any of those problems.
Good point. I'll forward to Kourosh, who deals with partnerships like this, and we can only hope people writing all these tools are on some mailing list.
fluorine:/a/mw-logs/api-feature-usage.log has a number of 2015-06-07 06:26:39 mw1232 enwiki api-feature-usage INFO: "action=query&!rawcontinue&!continue" from user agents containing "Kindle". ApiQuery.php logs this along with the warning in the API result "Formatting of continuation data will be changing soon. ..." So I hope someone notices the warnings in API responses.
-- =S Page WMF Tech writer
reading-wmf mailing list reading-wmf@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/reading-wmf
On Mon, Jun 8, 2015 at 1:04 AM, S Page spage@wikimedia.org wrote:
Maybe WMF should offer its own browser- or OS-level integration, pushing the reading experience way beyond our sites. https://en.wikipedia.org/wiki/Wikipedia:Tools/Browser_tools lists various browser addons, such as Lookup companion for Wiki https://chrome.google.com/webstore/detail/lookup-companion-for-wiki/dhgpkiiipkgmckicafkhcihkcldbdeej?hl=en that do this. Meanwhile https://en.wikipedia.org/wiki/Wikipedia:Tools#Searching has "Download 1-Click Answers Wikipedia Edition for Windows (beta) and then Alt-Click on any word in any program on your screen for instant, accurate facts." Who knew?!, makes me want to bust out Windows 2000 :)
A WMF-maintained self-contained javascript library to fetch Wikipedia summaries / Wikidata descriptions / Wikitionary translations (and maybe even Commons images) for a given string and display them in a configurable popup window would be awesome. That could then be used as a bookmarklet, in browser extensions (most of those are written in JS so they just need a trivial wrapper around the library), or in web pages as a functionality provided by the site owner.
+ Kouroush
A summary of ideas:
*WP as destination:* -Sister projects swipable from cards -WMF owned OS integration/browser add-ons
*WP as platform:* -API for 'cards' on topics/JS library -Make sure API changes aren't breaking experience for: apple, google, amazon? -Help kindle optimize their calls -Key partner list...do we have this for major integrations?
These are great ideas, and I don't want to lose them. What should go on the brainstorming etherboard for Q1 https://etherpad.wikimedia.org/p/Q1_Readership_Brainstorm and what should go elsewhere (and how do we make sure elsewhere isn't purgatory).
-J
On Mon, Jun 8, 2015 at 11:34 AM, Gergo Tisza gtisza@wikimedia.org wrote:
On Mon, Jun 8, 2015 at 1:04 AM, S Page spage@wikimedia.org wrote:
Maybe WMF should offer its own browser- or OS-level integration, pushing the reading experience way beyond our sites. https://en.wikipedia.org/wiki/Wikipedia:Tools/Browser_tools lists various browser addons, such as Lookup companion for Wiki https://chrome.google.com/webstore/detail/lookup-companion-for-wiki/dhgpkiiipkgmckicafkhcihkcldbdeej?hl=en that do this. Meanwhile https://en.wikipedia.org/wiki/Wikipedia:Tools#Searching has "Download 1-Click Answers Wikipedia Edition for Windows (beta) and then Alt-Click on any word in any program on your screen for instant, accurate facts." Who knew?!, makes me want to bust out Windows 2000 :)
A WMF-maintained self-contained javascript library to fetch Wikipedia summaries / Wikidata descriptions / Wikitionary translations (and maybe even Commons images) for a given string and display them in a configurable popup window would be awesome. That could then be used as a bookmarklet, in browser extensions (most of those are written in JS so they just need a trivial wrapper around the library), or in web pages as a functionality provided by the site owner.
reading-wmf mailing list reading-wmf@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/reading-wmf
