[21:04:34] ArchCom hosting a conversation of high-level mobile frontend requirements now on Hangout: [21:04:36] https://hangouts.google.com/hangouts/_/ytl/T7sMtE_gUxWZ4biKxPh5ffreSnwnrIj1L7udZWXlKSk [21:04:57] DanielK_WMDE: that link isnt working for me [21:05:35] coreyfloyd: not working how? [21:05:53] DanielK_WMDE: getting “you are not authorized to start this video call" [21:07:12] coreyfloyd: it just worked for me [21:07:26] maybe my google account… trying somewhere else [21:07:28] coreyfloyd: make sure you are signed in with your wmf account [21:07:40] Is there an equivalent youtube stream, for those of us who just want to watch, without taking up a space? [21:07:41] thank [21:07:43] ah, the wonders of modern technology :) [21:07:48] quiddity: yes but it's not started yet [21:07:53] perfect, ty :) [21:07:58] quiddity: will be https://youtu.be/8W7WrTa3Py4 [21:08:07] James_F or quiddity: might you be able to set the topic to ArchChom - mobile front end high level requirements ? [21:08:20] DanielK_WMDE: so not only hosted in a walled garden but also locked to organizational google accounts? [21:08:34] bd808: shouldn't be. i was able to join, after all [21:08:34] bd808: we don't think it's supposed to be. we're just having trouble making it work ;) [21:09:07] * bd808 waits to read the meetbot summary and full channel logs [21:09:42] quiddity: there's room in the hangout still and we're still having trouble launching the youtube mirror, feel free to join [21:10:29] looks like we have to mvoe on without the stream copy ;_; [21:10:30] disccusing https://docs.google.com/document/d/1jlBl_qAIrGPF7zqOmK77Db8y4InO1j3qX1qqipzJNmc/edit# [21:10:44] #startmeeting high-level mobile frontend requieremtns; discussion on HANGOUT, see https://hangouts.google.com/hangouts/_/ytl/T7sMtE_gUxWZ4biKxPh5ffreSnwnrIj1L7udZWXlKSk [21:10:45] Meeting started Wed Mar 15 21:10:44 2017 UTC and is due to finish in 60 minutes. The chair is DanielK_WMDE. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:10:45] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:10:45] The meeting name has been set to 'high_level_mobile_frontend_requieremtns__discussion_on_hangout__see_https___hangouts_google_com_hangouts___ytl_t7smte_guxwz4bikxph5ffresnwnrij1l7udzwxlksk' [21:11:06] meetbot activated so people can take notes here [21:11:13] thx DanielK_WMDE [21:11:32] joakino about to give intro [21:12:03] dr0ptp4kt volunteered to forward questions from IRC to Hangout [21:12:22] there shouldalso be a hangout-on-air channel on youtube, but i guess we are stil ltrying to get that going [21:13:12] dr0ptp4kt: use #info #action and #link and #idea for minutes. see https://wiki.debian.org/MeetBot [21:14:13] #info lots of research in previous year about new readers / global south markets [21:14:19] #info mediawiki API usage is tough on mobile; REST API with custom services has been friendlier to caching [21:16:09] #info REST API usage addds extra requiments, may be complicated for third-party MW sites [21:16:30] #info open questions about different options. for example, one option might be consuming content-oriented services [21:16:46] quiddity: (OT) you or another op may change the topic: the url changed to https://wm-bot.wmflabs.org/logs/%23wikimedia-office/ [21:17:13] #chair dr0ptp4kt brion [21:17:13] Current chairs: DanielK_WMDE brion dr0ptp4kt [21:17:51] #info a pre-compilation step may be good for reducing the size of the existing ResourceLoader manifest for MobileFrontend [21:17:54] #chair TimStarling [21:17:54] Current chairs: DanielK_WMDE TimStarling brion dr0ptp4kt [21:18:23] (ty Sagan) [21:18:24] quiddity: thx :) [21:18:45] this is a familiar architecture in some ways, going back to purohda's SOA mobile wrapper [21:18:51] #info research suggests people have decent phones but irregular connections [21:19:00] the main thing that worries me is how we are going to encourage mobile readers to contribute [21:19:04] #info in many parts of the world, connectivity is bad but the phones themselves are powerful. good opportunity for heavier client-side? [21:19:09] especially mobile readers with high-resolution screens [21:19:30] heh we duped that one [21:19:34] how do you do that if you have a mobile website which is very loosely integrated with MW core? [21:19:41] yeah, the bigger the screens get the more likely you are to type i think :D [21:20:17] #info open question: how to do editing well when looser coupling from MW core? [21:20:18] #info catering to offline or intermittent connectivity would be preferable. there are several ways to do it [21:20:23] in my mind the biggest criticism of MF is poor integration, the fact that MW core does not support mobile at all [21:20:45] #info for example isomorphic rendering, but interested to hear thoughts. not all research is in yet, either. [21:20:47] therefore you don't get any edit or review tools in it [21:20:50] not even talk pages! [21:21:02] talk pages are as much a reader tool as an editor tool [21:21:14] #link https://docs.google.com/document/d/1id-E_KELGGA3X5H4K44I6zIX3SEgZ0sF_biOY4INCqM/edit# [21:21:22] #link https://www.mediawiki.org/wiki/User:JHernandez_(WMF)/MFnext [21:21:34] #link https://docs.google.com/document/d/1jlBl_qAIrGPF7zqOmK77Db8y4InO1j3qX1qqipzJNmc/edit# [21:22:00] pause for questions: anybody have any? [21:22:10] i can parlay to the hangout [21:22:35] #info brion parlaying question: "what about editing? for example offline?" [21:23:37] #info joakino noting mobile editing is in the pipe. existing editing is using nice bundling techniques already [21:24:19] #info joakino suggesting it may be possible to integrate [21:24:30] #info (in wmf technology 'verticals' terms, editing dept owns the editing side) [21:24:48] #info DanielK_WMDE noting editing of prose on mobile is sort of tough, patrolling might be nice [21:25:42] brion: who owns the patrolling side? [21:25:55] DanielK_WMDE: i guess editing would own that too? [21:26:04] #info joakino noting agreement, framing that better tooling/build would make development a bit faster [21:26:05] i would *guess* so, too... [21:27:13] basically we have to build two complete, duplicative approaches to mobile [21:27:32] #info DanielK_WMDE noting that we need to make the editing pieces a consideration [21:27:32] one with low-powered devices in mind, one with contributions in mind [21:27:45] and this project is referred to as "reducing technical debt" [21:27:56] :) [21:28:51] surely duplication is the essence of technical debt? [21:28:54] #info coreyfloyd noted things are being discussed in light of annual planning [21:29:21] #info Krinkle noting that there may be complexity in bundling of RL assets [21:29:44] ideally, the internals are more related and the externals are more separate [21:30:04] related but in different languages [21:30:10] using different libraries [21:30:31] unless you go 'full nodejs' and use frontend libs on backend mega-rest service. taht might be scarier though [21:30:39] #info joakino noting that the use case and requirements will help inform whether going iterative or more on the side of replacement [21:30:58] that is exactly what they are proposing isn't it? [21:31:22] let's askf or clarification on that [21:31:40] #info Krinkle noting that the offline can imply certain approaches (one of those included in this discussion) [21:32:21] #info Krinkle noting that JS-less / JS-weak is something perf team has been thinking about [21:33:41] #info Gabriel noting that a number of sessions are shallow [21:34:02] #info noting that first render is a constraint [21:34:59] brion, REST as a backend is proposed in https://www.mediawiki.org/wiki/User:JHernandez_(WMF)/MFnext [21:35:06] which is linked from the agenda/notes document [21:35:31] #info want to be careful about duplicating the stack for offline versus online in separate code bases [21:35:37] I appreciate the desire to merge code between mobile website and mobile apps [21:36:03] *nod* [21:36:04] that reduces duplication [21:37:14] #info brion parlaying the multiple codebases concern [21:38:18] #info brion and Volker_E talking about progressive enhancement considerations [21:38:55] #info coreyfloyd asking question about server side serviceworker efficacy for low end devices [21:39:54] #info gabriel noting that it's not for free, but noting that the offline part (and streaming) are compelling [21:40:39] #info joakino noting that safari and chrome constitute the lion's share of access on mobile web (e.g., some 85%). then there's the long tail [21:41:36] I wonder if that includes chrome-like generic branded browsers on android [21:41:59] eg 'Samsung Internet' :) [21:42:27] yeah, my LG phone came installed with a thing called "internet", no chrome [21:42:43] and the UA does not say chrome [21:42:46] yeah not sure if that uses the system webview (which is really chromium) or has its own engine [21:43:23] I really doubt such generic brand browser brings its own engine [21:43:39] UC Browser [21:43:55] with its 10% [21:43:58] UC is quite popular in many parts of world, as i understand [21:44:08] the opera mini of the east [21:44:21] haha, yeah [21:44:26] actually the UA does say chrome (and also safari) [21:44:38] :) [21:44:46] and mozilla and gecko [21:44:56] TimStarling: yes: https://phabricator.wikimedia.org/T146703#3078248 [21:46:47] #info dr0ptp4kt noted increasingly lacking UAs are being replaced with more powerful UAs. did note that webkit-based stuff doesn't have serviceworker. [21:48:13] #info gabriel asking about resourceloader. Krinkle noting that the asset bundling may be worthy of a separate topic [21:49:20] #info Krinkle noting that there's an rfc on asset bundling [21:51:22] #info joakino noting that the asset bundling improvement is more of an improvement and for getting more experience with this to inform the future [21:52:25] #info gwicke asking about architectural approach of consumption of services. [21:52:56] #info DanielK_WMDE noting it's a deep question and we should discuss more [21:54:11] #info Volker_E said it makes one think about i18n [21:55:10] #info Volker_E was noting about non-content elements [21:55:37] #info Krinkle reflecting on comment from TimStarling about duplication of code across service boundary [21:56:26] #info joakino noting the apps have been tackling this advantageously - would be nice to rely on same services [21:58:37] #info gabriel asking for any questions. joakino noting we'd like to narrow in on approach once more info comes back from product requirements [22:00:28] #endmeeting [22:00:30] Meeting ended Wed Mar 15 22:00:28 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:00:30] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-03-15-21.10.html [22:00:30] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-03-15-21.10.txt [22:00:30] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-03-15-21.10.wiki [22:00:30] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-03-15-21.10.log.html [22:00:39] thanks dr0ptp4kt [22:00:45] \o/ [22:00:51] some a/v problems but hey :D [22:00:58] * brion wanders off to re-coffee [22:01:07] brion: thanks you and DanielK_WMDE and others with the assistance. first time using meetbot, even if i've seen it a dozen times [22:01:12] * DanielK_WMDE goes home now to get some sleep [22:01:15] :) [22:01:26] TimStarling: Volker_E brion: these stats are what we look into https://analytics.wikimedia.org/dashboards/browsers/#mobile-site-by-browser [22:01:32] and poor tim can get some breakfast :D [22:01:39] it is insane [22:01:46] dr0ptp4kt: all you really need is #startmeeting, #info, #endmeeting. i had to look up #chair :) [22:01:48] we're also not sure what the 8% of Other is [22:01:56] lol [22:02:51] ttfn [22:03:21] alright gn everyone [22:07:30] joakino: nice! Also IEMobile at 1%, that surprises me. UCBrowser on continuous way up.