[00:47:41] a sprint called chickenburger? :O [12:06:18] Has this https://phabricator.wikimedia.org/T142019 or something like it already been implemented in the iOS app? [14:04:08] srdjan_m: o/ there's a separate iOS-specific channel, #wikimedia-ios, where somebody would probably know the answer to that [14:04:40] mdholloway: will give a go there, thanks [14:45:05] Oh, there's another thing I ran into yesterday. There's this "A" thing in infoboxes that have the hlist class specified and use bullets in the source code. http://i.imgur.com/Z5ztWm6.jpg [15:04:28] srdjan_m: thanks for the report! looking into it now... [15:05:17] The page shown is bs.wikipedia.org/wiki/Rock_muzika and the template in question is https://bs.wikipedia.org/wiki/%C5%A0ablon:Infokutija_muzi%C4%8Dki_pravac in case you need it. [15:34:58] i've seen that too recently, for example in [[Minecraft]] [15:58:31] T158067 [15:58:32] T158067: Misplaced characters are injected after certain list items - https://phabricator.wikimedia.org/T158067 [15:58:44] srdjan_m: dbrant: wrote it up ^ [15:59:32] ty [16:12:26] niedzielski: hello, sir. [16:13:00] kaartic: o/ [16:15:01] niedzielski: A month or so ago, I noticed a few lead images that had human faces that were not centered correctly. I thought that the app didn't have a feature for centering them. [16:15:35] Since you had said that there face detection is done by app. I wanted to know if it was a good idea to create an issue about the face detector not centering images correctly ? [16:16:54] in case i could see them not centering correctly now. [16:18:40] kaartic: sure! but keep in mind a few things: 1) sometimes face detection fails because a face is not prominent enough in a photo 2) face detection is the most likely method to silently fail on your device because of the out of memory work around we put in 3) when faces are detected, the photo is panned to center the face but is never panned beyond the edge; this means a face on the edge of a photo cannot be [16:18:45] centered [16:20:03] so if you find a bug, hopefully you can identify it across a few images so the confidence and ability to reproducible are high [16:23:31] niedzielski: i thought the out of memory work around was only present in the production release. Is it also present in the aloha release. [16:23:48] correction: aloha -> alpha [16:24:51] BTW I get your point, sir. i'll file one if i could see the same problem in other devices (just to ensure it's not device specific). [16:24:55] kaartic: only in production :] [16:26:05] I could use the "Alpha release" after i reflashed my ROM. So i guess there wouldn [16:26:23] not be a problem with the work around [16:27:18] niedzielski: One more thing i wanted to ask is : Is it a good idea to file an issue to disable the "article toolbar" when the article load fails ? [16:27:24] dev / alpha / beta will crash if you run out of memory during face detection so there can be no mistake [16:28:18] kaartic: that sounds like a good idea to me! [16:29:40] so that means I could file one. Right, sir? [16:32:37] kaartic: yep :] [16:35:20] niedzielski: one last thing, sir. Is there any reason behind opening any article from the reading list (or) the links from the explore feed in a new tab? [16:38:47] kaartic: we were concerned that a user may accidentally lose their place by tapping an entry in the feed. if the user presses back after following a feed link, the tab should be removed [16:40:53] niedzielski: is "losing the place" also the reasons for opening articles from a reading list in a new tab, sir? [16:42:38] kaartic: that's my recollection. is your app workflow a little different making this a hindrance? [16:47:57] niedzielski: No, sir, It's not an hindrance actually. I thought there wasn't much use in opening them in new tabs thus increasing the number of tabs unwantedly. I didn't think about the "lose the space" as I didn't have much articles in the reading list. So, I wanted to know the reason, nothing else. [16:50:29] kaartic: ah, well the thinking was that if, for example, a reader was viewing the orange article and opened their reading list to compare it to the apple article they saved, they probably don't want to lose the orange article they were previously viewing [16:56:13] niedzielski: i guess I'm finding this a bit odd for the same reason that i found the workflow of the home page odd in https://phabricator.wikimedia.org/T155245 [16:59:22] niedzielski: I've created an issue for the article toolbar. It could be found at https://phabricator.wikimedia.org/T158077 [17:01:08] The issue of not disabling the article toolbar went to an extent more than just trivial. [17:03:43] kaartic: the issue you first linked to, for the second point, i think we're just seeing that a new tab is made where none had been. the ticket is well written but is there something specific in it you find at odds? [17:04:41] thanks for making that toolbar task! [17:06:19] niedzielski: no problem. as said before, please don't thank me for these things. it's just a little help from my part. [17:07:23] regarding your previous question, have you seen the separate tasks i have created for each point? You could find them in one of my comments. [17:14:22] kaartic: regarding T156801, does homepage refer to wikipedia.org or .wikipedia.org? [17:14:22] T156801: Home page could be displayed whenever a new tab is created - https://phabricator.wikimedia.org/T156801 [17:16:26] kaartic: er, i'll follow up in the ticket to keep the dialog there :] [17:17:36] niedzielski: Sorry for not being clear. I actually meant the app's home page. [17:17:54] ah [17:18:57] Also, shouldn't title descriptions be displayed in lowercase? [17:19:15] I guess i should retitle the task. Could you suggest a suitable title? [17:20:17] kaartic: so when a new tab is opened you want to see the explore feed inside the tab initially? [17:22:51] niedzielski: yup! [17:26:58] kaartic: hm, i personally thinking that showing the explore feed inside a tab that lives on top of the explore feed would be a little confusing [17:30:40] niedzielski: i actually think a little different about it by considering the Explore feed as just another tab (not technically) and displaying it whenever a new tab is created. Not inside the tab just showing the explore feed would suffice. I might likely miss a few things. Please correct me know if i'm wrong anywhere. [17:32:27] kaartic: hm, so you think of the app as kind a collection of tabs and no view pager screen (explore feed, reading lists, history, nearby)? [17:34:19] niedzielski: sort of. I consider it somewhat like a enhanced Wikipedia browser and as a result try to correlate it with other browsers. I guess that's what i have mentioned in https://phabricator.wikimedia.org/T156799 [17:36:55] kaartic: would T156799 be resolved if the show tabs button was always visible? [17:36:56] T156799: Wikipedia app could avoid "Zero tabbed state" - https://phabricator.wikimedia.org/T156799 [17:39:21] niedzielski: I guess. If it doesn't lead to any problems then that's the obvious solution, sir. [17:40:33] kaartic: so if we the "show tabs" button is always visible and the user has no tabs, do we create a new tab when they press it? if so, what does the content of that tab show? .wikipedia.org? [17:43:34] I actually thought of single solution for the three tasks which could be summarized as : 1) Show the "Explore feed" whenever a new tab is created 2)Remove the "close tab" icon (as it wouldn't be of much use anymore) 3)Show the show tabs icon always [17:44:26] As the "Explore feed" is shown every time a tab is created the issue of no tabs is avoided (as far as I could think of) [17:44:51] kaartic: if you can create new tabs, how do you destroy them? [17:45:37] niedzielski: obviously, by closing them from the "Show tabs" view just as in a browser. [17:46:47] kaartic: i think i understand now (processing) :] [17:47:35] If the explore feed is shown whenever a new tab is created the "no tabs" state is avoided. If the user closes all the tabs, create a tab and show the explore feed. [17:50:11] niedzielski: I'm not sure if i'm suggesting something good, sir. My thought was it would be nice if the app would be more similar to the user if it had more similarities with the browser. [17:50:45] kaartic: i think what i might like about that experience is it would make the pages and the current home screen (feed, nearby, history, reading lists) feel like they're at the same level and the same kind of content. what would be confusing to me is having a tab that has four sub tabs embedded in it (feed, nearby, history, reading lists) [17:51:32] the home screen as it's currently designed feels like a launch pad. one idea mentioned was embedded the reading experience in a tab like nearby or history is [17:53:29] niedzielski: Have you used the Firefox browser, sir? [17:54:10] It has it's home page something like this. [17:56:13] kaartic: ah, i see. so it's impossible to close the last tab [17:56:50] niedzielski: yes, sir. I guess that won't be an issue. [17:58:08] further you could note that the bookmarks, history and top sites tabs in every newly created tab in the firefox browser. [17:58:47] It's somewhat similar to the explore view, history, my lists and nearby in the Wikipedia app. [17:58:49] kaartic: ok i recommend consolidating these thoughts in a ticket that uses the firefox app as an example. this will definitely need design input. i think the app's tab overview could be better integrated with the rest of the app either as firefox does or perhaps slightly differently [17:59:03] kaartic: the firefox app really helped me to understand the proposal, thanks for that! [18:00:39] no problem, sir. I could create that ticket, if there isn't any problem, sir. [18:03:38] niedzielski: One more thing i wanted to add about the oddity of the current implementation is, if a user leaves the app with a tab open in the foreground and if he returns back to the app after quite sometime he would be shown the Explore feed instead of the tab which is hidden behind the explore feed. I guess the user wouldn't be aware of it by any chance. [18:06:52] olliv: no standup? [18:08:37] phuedx: no standup? [18:09:07] nzr: sorry, the engineers have a meeting w/ dr0ptp4kt [18:09:26] oh okay.. jeez thanks for RSVP on the event [18:10:08] nzr: this is that thing i emailed about yesterday. all good? [18:10:21] haha jk jk it's all good [18:10:46] i got punked by nirzar. do i get a badge? [18:18:21] niedzielski: could I create that ticket, if there isn't any problem, sir. [18:22:47] dr0ptp4kt: it's a well designed barnstar [18:30:05] kaartic: o/ sorry was in a meeting [18:30:23] kaartic: yes, that was actually intentional [18:31:31] kaartic: the idea was that if a user had been recently reading, they probably wanted to continue reading. if it had been a while, they probably wanted to read something new [19:19:14] wuuttt github changed their header! [19:19:58] nzr: ya i got that change last week! crazy [19:31:39] nzr mdholloway: some discussion here :] https://news.ycombinator.com/item?id=13619406 [19:32:51] niedzielski: god people just need to chill [19:33:22] :] [21:32:27] zomg stackoverflow changed its header!!!! [21:32:52] * mdholloway faints