[00:00:19] o/ [00:03:07] +1 [00:07:39] dbrant bearND mdholloway|afk: if you check the dev console for beta, you can see we now have multiple apks [00:08:19] nice [00:08:23] coool!! [09:55:54] o/ [15:09:39] o/ [15:11:47] mdholloway dbrant bearND|afk: hm, so i just logged into the play dev console this morning and am seeing zero apps :| [15:12:04] mdholloway dbrant bearND|afk: did more account stuff change? [15:12:12] (since last night?) [15:12:17] niedzielski: i'm seeing them just fine... [15:13:03] mdholloway dbrant bearND|afk: nvm, there's a team drop down with a couple options "Wikimedia Android Team" and "Wikimedia Foundation". the latter has the apps :) [15:13:21] niedzielski: nope, just checked [15:13:25] niedzielski: lol right, we're still members of the old "Wikimedia Android Team" account. [15:14:39] niedzielski: dbrant: we should probably ask tfinc to remove us now that it's defunct [15:20:13] dbrant, do you know how many people have upgraded to the latest android beta? [15:21:58] yurik: looking [15:28:33] yurik: it doesn't look like there's an appreciable spike of upgrades yet. Give it a couple more days -- it usually takes ~2-3 days for a good fraction of users to upgrade, and we only released it yesterday afternoon. It also takes Google Play a day or so to update the stats. [15:29:09] dbrant, thanks! Will ping you in a few )) [17:05:04] bmansurov: do you get `Error: Module not found: loggingSchemas/SchemaMobileWebSearch` on latest master? [17:07:56] bearND: sorry to cut you off in the meeting! i'm working to keep meetings close to schedule [17:09:26] dr0ptp4kt: no worries. [17:10:47] niedzielski: dbrant|brb mdholloway bgerstle: so, about read more results from the service: add an extra section to remaining.sections[] or a json object with the necessary info to remaining.readmore [17:10:51] ? [17:11:28] bearND: i'd vote for a json object [17:11:50] bearND dbrant mdholloway bgerstle: to me, one of the points of restbase is to provide granularized data wherever possible [17:12:02] (so json) [17:13:49] i think it would be a json object in both instances (just a member of remaining.sections[] in the first option), no? but it might be nice to have it broken out separately under "readmore," so i'll also vote for 32 [17:14:00] ^#2, that is [17:15:04] bearND dbrant mdholloway bgerstle: the html sections are more like big html blobs that happen to be in json. that might be the case for read more, at least initially, but i would prefer for distinct fields wherever possible [17:17:24] bearND: niedzielski: yeah, if providing it as an html blob is part of option #1, then even more so #2 [17:17:51] niedzielski: +1. i say use HTML if you're gonna put it in the browser. otherwise go for JSON (or whatever format your app likes to parse into objects) [17:18:01] HTML is (usually) meant for presentation [17:18:16] so unless we're rendering read more in the webview, i don't see a point in putting it in HTML [17:19:00] fetching read-more separately allows us to fetch it lazily after the user has reached the bottom of the page [17:19:13] (along the same lines of laziness that i mentioned before) [17:19:57] kristen|voyager jdlrobson sorry if I'm a couple minutes late to retro. I tried to run out and pick up some food in that half hour and traffic is worse than I expected! [17:19:59] The proposed added section would have had it in HTML, of course, and would long-term simplify the app since it would not have to know anything about read more at all: no adding read more sections and toc entries manually by the app. In the short-term it may need to be a bit more complex since in that case we would have to disable the read more native display [17:19:59] (until it's only using the service.) [17:20:50] bearND: so, this hits at the larger question: which platform/view is responsible for X-feature? [17:21:12] if we're doing readmore in HTML, it should (IMHO) ideally be web's responsibility to implement and for us to re-use [17:21:20] if we want to [17:22:03] bearND dbrant mdholloway bgerstle: html is our data, css or native views are a presentation, javascript and java is our controller. in some cases it makes sense to keep our data as html, but for things like these article _titles_ are similar to the current article, the formatting seems extraneous. however, regardless of the contents of the data, re [17:22:04] ad more entries should be a field [17:23:27] do you see a need to format 'read more' very differently depending on device / use case? [17:23:38] niedzielski: bearND for example, the feed stuff is all implemented natively in iOS. that's not say we couldn't do it in web as well, but doing it natively allows us to structure the rest of the app navigation around iOS norms instead of native<->webview interop limitations [17:24:34] bearND dbrant mdholloway bgerstle: i thought the service was supposed to be useful to more than just our two apps? it's a lot harder for me to write the hello world demo app for read more if i have to parse html on the client side to get the titles [17:24:41] gwicke:^ [17:25:36] gwicke: yeah, ideally we'd do as much as we can to specialize it for iOS in terms of OS integration, presentation, and performance [17:25:42] or Android, what have you [17:25:44] jdlrobson & I were chatting about this yesterday; it sounds like mobile web will soon have very similar API needs to what you are doing right now [17:26:10] especially the lead section + metadata / remainder split [17:26:20] right [17:27:08] niedzielski: we currently try to blend in the native view of read more to look like it's part of the web view but it isn't, which makes things unnecessarily complex. The idea wat to just use the web view for this and not parse HTML on the client. [17:27:12] gwicke: my point is: we need to separate concerns related to representing article content, and supplementary content [17:27:44] bgerstle: yeah, agreed [17:27:57] bmansurov: you there? [17:28:05] yes [17:29:12] generally, exposing data leaves more flexibility in the client [17:29:13] bearND: my opinion is that restbase should not be a raw cat of a given article that is expected to be pumped into a webview. it should be an api easy to extract bits and pieces of articles from [17:29:51] bearND: some pieces make sense to deliver as html chunks, others should have no html content [17:30:31] bearND: how could we ever make a purely native app if all we support on the backend is html soup? [17:31:12] niedzielski: bearND gwicke specifically: article content should (mostly) be HTML. since that's very suitable format for describing a document. that could still be parsed and rendered natively in some cases (given a sufficiently-specced DOM), but lots of other stuff doesn't leverage the strengths of HTML as much [17:31:44] e.g. the various "box" elements (e.g. all the info & navbox variants) [17:31:46] ToC [17:31:46] etc. [17:32:04] bgerstle: i agree that most of the content delivered should be html. but it should still be partitioned and granular wherever possible [17:32:40] if the "see also" section is essentially a list of titles, then formatting those is probably not very hard [17:32:53] gwicke: it's literally the result of a search API call [17:33:22] bearND: e.g. what's the impetus behind putting in HTML? [17:34:00] if it's putting it in the webview, that's fine, but it seems like doing it natively will make it easier to interact w/ it natively—which is how i assume you want to interact w/ things in an otherwise-native app [17:35:00] even if you wanted to put it in the webview, you could still have a JSON endpoint, which (in-proc) powers the HTML "view" you want of the data on android [17:35:09] bgerstle: yes, to put it in the webview [17:35:22] which allows you to have a concrete data schema, and you can even use templates to generate the HTML [17:35:34] which is how i imagine web wants to use the API [17:35:52] get blobs of content, and create other UI elements by generating HTMLs w/ templates & structured data [17:35:57] jdlrobson: ^ ? [17:36:09] yeah, I definitely think we'll see more client-side rendering based on data provided by the API [17:36:10] in a meeting sorry [17:36:20] looks like there's an overwhelming majority for the json data and native presentation [17:36:56] bearND: i think at the end of the day you're dealing with structure data. what you do with it (wrap some HTML around it and put it in a webview) is a function of that data [17:37:09] the HTML is (arguably) less portable [17:37:32] bearND: I know that the escaping stuff around building up HTML sucks to some degree, but apart from that building up a HTML list shouldn't be too bad [17:38:17] bearND: niedzielski all that said and done, i don't even think we need a RESTBase endpoint for read more [17:39:09] nor is it necessary (or arguably advisable) to inject it into other responses (except maybe a special case for the "last" section, but we're only fetching the lead & "remaining" sections, not specific ones) [17:39:35] gwicke: do you know which room the performance team is in? [17:39:52] bgerstle: #wikimedia-perf [17:39:55] sweet, thanks [17:40:16] they cut of the "ormance" in the interest of speed, I believe [17:40:23] *off [17:41:02] bgerstle: why would you not have the read more content in the page content response and hit the search api separately? You'd lose out on a lot of caching infrastructure. [17:41:07] ormance is dead [17:41:17] gwicke: lol [17:41:35] bearND: in the case of "remaining" i suppose you could since it's only 3 extra JSON objects [17:42:10] bearND: i might also want to fetch it independently of the article content entirely [17:42:19] niedzielski: ha! [17:42:24] e.g. let a user explicitly request recommendations on the current article [17:43:04] bearND: also, i would argue that you're losing out _more_ on caching infrastructure since you're tightly coupling expiration of related search results & article content [17:43:13] which dr0ptp4kt previously mentioned has a much shorter TTL [17:43:57] e.g. i don't want to fetch the same 1-N sections of an article due to the expiration of the "read more" section alone—which is entirely orthogonal to the article content [17:44:23] niedzielski: unless your an ormancemancer [17:44:30] 😣 [17:44:41] niedzielski: even you have to appreciate that one [17:44:53] oh i do [17:45:23] bgerstle: I think this should be fine for a read more section expiration to couple it to the expiration of the real sections. It's not that this is meant to be a search request. It just happens to use the search API [17:46:08] bearND: disagree. in the case where an article doesn't update very frequently (which is probably true in a non-trivial number of cases), you'd like to get the latest suggestions even if the revision hasn't changed [17:46:21] e.g. if i go to the same, unmodified article 5 days later [17:47:01] bearND: also, coupling it with the article response adds further incidental complexity when you consider how you'd "extend" the current read more results (e.g. kicking off another request w/ the "continue" field of the previous result) [17:47:19] which we use in the iOS "feed" (e.g. "Here's 3 articles related to 'Food'. Tap this button to see more") [17:47:50] * bgerstle caveat: we're not actually using continuation on the iOS app—yet, but using the search API directly means there aren't any technical barriers to doing so [17:48:02] * bgerstle caveat2: assuming read more even behaves properly w/ continue [17:48:37] bearND: but, we can go back and forth on this all day. let's pick an approach, try it, and learn something [17:50:01] last thing: don't not sure how you guys are doing read more, but on iOS we're showing little "previews" of the article using extracts. doing so means we need to specify how many extracts characters we want to ensure the card is sufficiently populated for a given device/orientation [17:50:47] so you're either _further_ fragmenting the "remaining" endpoint caching on "numExtractChars", or forcing a "one size fits all" response which is too much data for some, and potentially not enough for others [17:52:00] bgerstle: interesting thought about the continuation and the extracts. Looks like we don't have a common way to present read more. So, it's not a pressing enough feature for now, so, let's postpone it. [17:52:08] k [18:36:34] jdlrobson, updated the release notes patch [18:39:35] jdlrobson, hopefully it's mergeable now. i'll be back online in about 5.5 hours. [18:39:39] later [18:50:29] bgerstle gwicke yes i can confirm that the reason the web team wants to move to parsoid is to get more access to the content components. Structured templates and structed data = win [18:50:42] k, thanks jdlrobson [22:17:37] jdlrobson: lets talk about this bug, i will like to work on it now. [22:17:50] https://phabricator.wikimedia.org/T113667 [22:19:50] d3r1ck: what do you need to know? [22:24:10] jdlrobson: screen resolution of 768px or greater [22:24:27] how do i do that? I don't even know how large my screen is :) [22:24:46] d3r1ck: what browser do you develop in? [22:25:06] Google Chrome [22:25:39] Version 45.0.2454.101 (64-bit) [22:25:53] jdlrobson: thats it. [22:26:16] d3r1ck: Google Chrome under developer tools has an emulator button. You'll have to familiarise yourself with that yourself http://www.hongkiat.com/blog/chrome-mobile-emulation/. Once you've worked that out you'll want to search the code for instances of @wgMFDeviceWidthTablet and learn from that to see how we change styles for mobile/desktop. If you do not [22:26:17] know what responsive design is that is also necessary pre-reading! [22:30:26] jdlrobson: i see it. I am doing something [22:33:31] jdlrobson: i am logged in now. [22:37:13] jdlrobson: so what is specific that i am suppose to see. [22:39:51] d3r1ck: i haven't got much time but the issue is the line at the top of https://phabricator.wikimedia.org/T113667#1687524 - there should be no whitespace to the right of the watchstar or the left of the page image. If you throttle your connection you'll notice a flash in styling. It's really up to you though to work out why and fix it otherwise I am fixing [22:39:51] it for you. There is ample clues in the task itself. [22:43:38] jdlrobson: i have not understood exactly what the problem is. Your English too is really hard to decode :) [22:44:45] jdlrobson: ohhh, i see an image you posted on phabricator. That will help [22:44:50] https://phabricator.wikimedia.org/T113667 < if that's not clear d3r1ck i suggest you find another bug :) [22:46:20] jdlrobson: well just fix that one. :) [22:46:25] will move on another :) but really wanted to fix this one. [22:47:08] jdlrobson: can you do some guide? or mentoring? [23:09:28] d3r1ck: i personally can't i'm afraid. I already did GSoc this year and I can't commit to mentor someone right now as I have too much other stuff going on. [23:10:14] d3r1ck: https://phabricator.wikimedia.org/T113667 is a low priority so if you understand what the problem is there you should just attempt to fix it, you'll learn a lot in the process. [23:11:16] jdlrobson: i was not talking about mentoring me like GSoC. just guiding me to fix the bug :) [23:12:28] d3r1ck: i'm not sure what more i can tell you right now. If you don't understand the problem I don't know how to explain it any better, and if you do, the best mentoring I can give you is when you have submitted a patch. [23:12:47] You'll have to work out what's causing the issue and how to fix it yourself otherwise I would be doing it all for you! :) [23:14:06] jdlrobson: i understand, i will check this out. :) [23:52:19] o/