[15:36:21] Genymotion has 6.0! [15:43:58] niedzielski: wait, the Ken Burns animation has never made it to production? lol how on earth did I miss that?! [15:44:20] dbrant: i think i added a todo in one of those hygiene patches :) [15:47:32] niedzielski: are you taking care of https://gerrit.wikimedia.org/r/247753 ? [15:48:01] dbrant: yep, i'm working on that now [15:48:08] nice [15:51:09] dbrant: actually, that patch seems to work fine on the api 19 emulator. where were you seeing an issue? [15:51:50] niedzielski: on my physical devices with API 19 and 18. [16:38:12] bgerstle: Remove TOC "Introduction" and use article title. https://github.com/wikimedia/wikipedia-ios/pull/179 - it's not in 5.0.0.411 ? [16:38:40] etonkovidova: let me see... [16:38:53] bgerstle: ok [16:39:00] i feel like we should've gotten another build by now.. [16:39:18] etonkovidova: doesn't seem like it's in 411 [16:39:21] let me see what's going on w/ jenkins [16:39:52] * bgerstle sigh [16:39:53] it's broken again [16:40:32] ok, i'll see what i can do about fixing it in a bit [16:40:40] hopefully just need to upgrade a few things [16:40:57] bgerstle: right :) Thanks [17:41:38] etonkovidova /dbrant https://phabricator.wikimedia.org/T107791 can be closed. thanks [17:42:06] matanya: thank you :) [18:12:53] niedzielski: in emulator I see 2.1.131-alpha-2015-10-09 - I thought that the update to the latest is done automatically... [18:13:22] niedzielski: I did git pull before starting the emulator [18:13:46] niedzielski: something else needs to be done? [18:15:30] dbrant: Is all of the following correct: A "session" in the app is 30 minutes long (unless set otherwise in the developer settings). It begins on when the app is first launched with the session funnel enabled, and when the session timeout is reached, the collected session data is logged and recording for a new session immediately begins? [18:15:43] etonkovidova: it should be. the alpha updater runs on launch when the last check was more than 24 hours ago. [18:15:54] etonkovidova: if you file a phab for it, i'll check it out [18:16:40] niedzielski: hmm... ok Yes, usually it's the latest. Let me restart android studio - again [18:17:40] mdholloway: yes, except for the first sentence: A "session" can be arbitrarily long; and the session *timeout* is 30 minutes. (i.e. 30 minutes of inactivity must pass before a new session begins, and the previous session data is sent to eventlogging) [18:19:01] dbrant: i see, thanks! [18:20:00] niedzielski: android studio asks me to update - Current version 1.3 Beta New version 1.4. Should I? Or there are some other versions already? [18:20:49] etonkovidova: i'm on 1.5 preview and it's working fine. i suspect 1.4 would work well too and is likely more stable. [18:21:05] niedzielski: ok then [18:40:31] niedzielski: dbrant|brb FYI the tools we use for devops are going into beta for android! https://github.com/KrauseFx/fastlane/blob/master/docs/Android.md [18:41:27] bgerstle: i didn't even know these existed. this looks very promising! [18:42:10] it's been great for iOS [18:42:44] bgerstle: so you guys have been using this for a while? [18:42:51] yep [18:47:00] bgerstle, re stability of thumb urls: we need those to be reasonably stable for cached / stored content in any case, so I'd consider them a public API [18:48:12] gwicke: i guess, but you can you even construct the URLs with only knowing file name? [18:48:34] gwicke: the other problem is that (AFAIK) they don't fall back gracefully [18:48:43] so we need to also know the max resolution of the file [18:48:49] the only complication is the commons vs. local wiki thing [18:48:49] and (manually) fallback on the client [18:49:05] but, given a path to a thumb it's easy to get a thumb in another size [18:49:35] gwicke: i don't think i'd call parsing a filename out of a thumbnail URL "easy" [18:49:54] we just recently fixed the regex for it [18:49:58] well, reasonably easy, as in 1-2 lines of code [18:50:52] gwicke: yes, but we need to re-implement it everywhere [18:51:04] why can't we have a reasonable interface that takes a filename and some resolution parameters? [18:51:20] instead of asking clients to construct URLs and limit sizes manually? [18:51:23] url.replace(/[0-9]+(px[^/]+$/, desiredWidth + '$1'); [18:51:39] url.replace(/\/[0-9]+(px[^\/]+$/, desiredWidth + '$1'); [18:52:08] yeah, but that's ugly and hacky [18:52:25] and sometimes they don't have a prefix [18:52:31] e.g. if you get the original size [18:52:53] as a client developer, I don't want to care about any of this [18:53:13] IMO we're forcing complexity onto people who shouldn't have to deal with it [18:53:17] yeah, the API design isn't as regular as it could be [18:54:03] hopefully we can clean that up while moving to content-based addressing [18:54:26] https://phabricator.wikimedia.org/T66214 [18:57:02] gwicke: yeah i guess that would help? but i don't see how that solves the problem of being able to dynamically retrieve images w/ only knowledge of the filename [18:57:28] we're still (sort of?) figuring out how to even _render_ images on a page (ideally) [18:57:35] e.g. some forms want full-width [18:57:46] others (i.e. desktop and/or tablet) might want floating [18:58:04] https://phabricator.wikimedia.org/T66214#1743306 [18:58:11] _some_ clients (getting crazy now) might want to download lower-res versions and then go get the higher-res ones [18:58:38] yup [18:58:51] srcset is a bit too narrow-minded really [18:59:03] you might have a high-dpi display, but your connection might still suck [18:59:33] browsers *could* be smarter about considering both factors, but afaik right now only JS code can actually do this [19:00:42] similar with not / deferred loading of below-fold images [19:01:15] gwicke: exactly [19:01:36] i was going to comment on phab, but we might (in some cases) only return filenames for images [19:01:47] clients with JS (or native) rendering capabilities can take care of the rest [19:02:02] ... assuming we had an API for requesting image thumbnails based on a filename [19:02:25] better: original content hash [19:02:29] but yeah, API is key [19:03:39] gwicke: sure, some kind of identifier that we can use when making an API request to get a thumbnail [19:11:14] niedzielski: When you have a min ... I attached two screenshots to T109346 Contextual toolbar share icon should be ifRoom [19:11:32] etonkovidova: will check soon. thanks [19:11:39] niedzielski: it looks better, but I may miss smth :) [19:21:16] mdholloway: T1111958 Lead paragraph shifting improperly terminates when a list is encountered - do you think that iOS should think it too? they still have it ... [19:24:14] etonkovidova: good point! let's add the iOS app and I'll do a quick pull request [19:24:35] mdholloway: ok :) [19:27:57] dbrant bearND|afk mdholloway: ok, keyboard fix is up 4 realz (?) [19:28:11] niedzielski: lookin' [19:28:59] etonkovidova: T109346 looks good to me! [19:29:12] niedzielski: i'll look now too. [19:29:25] etonkovidova: your screenshots are great documentation and save dev and design lots of time! [19:29:31] niedzielski: nice - thx [19:29:37] dbrant mdholloway: thanks! [19:31:07] dbrant mdholloway: it seems like there's a lot of confusion about how input filtering is supposed to work. i blame the api! :) [19:32:36] dbrant mdholloway: some of the most obfuscated code in android i've come across lives in the text classes. it's a shame such a fundamental part of the platform is so difficult to comprehend and work with [19:38:48] niedzielski: works for me! looking at the code now [19:39:29] \o [19:54:33] dbrant mdholloway bearND|afk: i've ordered a 6P :) [19:55:12] wow, well done! [19:55:24] niedzielski: me too, i signed up for project fi and have one on the way :) [19:55:41] mdholloway: nice! i'm giving fi a try too! [20:19:04] niedzielski: nice [20:19:53] dbrant: hey! i think there's some product input needed on this guy: https://gerrit.wikimedia.org/r/#/c/247616/ [20:20:27] niedzielski: oh I'm writing it, believe you me. [20:20:38] * niedzielski believes [21:51:58] kaldari: hey! "which git-review" (with the hyphen) return a location? [21:52:07] does ^ [21:52:30] yes: /usr/local/bin/git-review [21:53:00] kaldari: ok nvm :) [22:11:37] dbrant: we'll do android-focused design review at half past [22:15:51] niedzielski: wouldn't #777 make it resolve to #707070, instead of #777777? [22:16:13] dbrant: i don't think so. if you hover over it, i think it should resolve to the true color [22:17:02] dbrant: or maybe you have to click on the color in the gutter [22:17:20] niedzielski: right you are! [22:17:44] mbinder: nice project thumbnail :) [22:17:45] dbrant: i think you used to be able to hover but that doesn't seem to be working for me at the moment [22:20:29] mdholloway: :D it was that one or one that looked like metal poop [22:21:49] hmm, tempting, but i think you chose well! [22:25:27] mdholloway: two questions: 1) have you seen sluggish behavior or flickering since DanReyLop's patch? 2) have you seen that weird lead image offset bug you reported the other day? i tried hard but can't repro on the patched branch or master [22:29:11] niedzielski: i haven't seen either today. [22:29:28] mdholloway: great. thanks! [22:29:38] niedzielski: no problem, have a good evening! [22:29:49] mdholloway: you too! [22:34:27] bgerstle: sorry to bring it up - but it could be discussed already :) Is everybody happy with present Back navigation - there is no direct access to Home, Saved, Settings etc? [22:36:24] etonkovidova: no need to be sorry! we know it's less than ideal [22:37:09] bgerstle: less than ideal - ha! it violates sacred fundamentals of UI navigation :))) [22:37:10] etonkovidova: there are some prototypes going through user testing, but the likely strategy will involve having articles be kept in a separate, modal view which is easy to navigate to/from the main root view [22:37:29] etonkovidova: right, because we hide the tab bar [22:37:51] etonkovidova: the ticket you want to follow is: https://phabricator.wikimedia.org/T113550 [22:38:03] bgerstle: thx - let's hope... [22:38:22] etonkovidova: something like this https://vid.me/uIeX [22:38:41] so you tap the "down" arrow (or some variation of it) to shirnk teh modal and go back to the tab interface [22:39:17] bgerstle: yes, it looks like back to normal [22:39:51] etonkovidova: but the edge swiping is nice, right? ;-) [22:40:10] bgerstle: yup :) [22:40:16] etonkovidova: actually, have a second for a hangout? [22:40:20] or are you still in design review? [22:40:35] bgerstle: yes I am [22:40:42] it ends soon [22:41:18] ok [22:41:40] etonkovidova: TL;DR; JoshM and I have been starting to write specs for the app and have some thoughts on phab will play into it [22:41:49] i'm going to head out for a bit, but maybe we can talk sometime tomorrow [22:42:16] perhaps i can enlist your help to add acceptance criteria & populate the specs as you go through the column [22:42:39] bgerstle: tomorrow is fine - any time after 11:00 am PDT [22:42:49] ok [22:53:58] ^will send a calendar invite [22:55:15] niedzielski: do you think distraction free mode would take out tables too? [22:57:36] kaity_: i picture distraction free mode as a full screen book like experience as much as possible. i think the kindle paperwhite does a pretty good job and would be a good starting point. i think we'd still have tables (excluding popular links, read more, etc -- all distractions) but they would be styled simpler [23:00:15] kaity_: i hope to work on it sometime as a prototype [23:01:11] niedzielski: cool [23:01:27] i think tables are a distraction too though [23:01:58] the collapsed version could be made even smaller/simpler for simple read mode [23:08:38] kaity_: i think minimizing distractions is obviously the most important part about distraction free mode but i think we should still have some interactions like wiktionary for example [23:08:52] true [23:55:09] dbrant: do you happen to know the name of the table/schema with data on retention of android app users? [23:55:29] (jonk mentioned we have one, i'd like to include that in the weekly metrics report alongside the 7-day retention metric for iOS) [23:55:58] HaeB: that would be https://meta.wikimedia.org/wiki/Schema:MobileWikiAppDailyStats [23:59:25] dbrant: thanks! how does this work? is it correct to assume that the app generates that event every 24h, or whenever it is opened and more than 24h have passed since the last event?