[08:03:42] morning! [08:12:51] morning joakino [08:13:16] joakino: gimme a few minutes and i'll be in tracy [08:13:41] 👍 [08:20:13] joakino: i'm in tracy [10:24:35] lol joakino [17:04:26] joakino: olliv standup, if yer around [17:04:36] sure [17:04:52] jdlrobson: you too if not vacationing :) [18:47:28] niedzielski: hi, have some minutes to chat ? [18:48:07] matanya: sure, what's up [18:48:24] niedzielski: doing well, thanks, hope the same on your end [18:48:42] matanya: yep, going well here too. thanks [18:48:48] wanted to point out some stuff i suspect are bugos on the new alpha [18:49:29] I like the fact sidebar was moved below the explore feed [18:49:41] matanya: sure, the alpha is kind of in a transitional phase right now as we move from the hamburger menu design to a tab bar [18:49:54] matanya: i'm glad you like it! we're excited about it too [18:50:03] but i can't use it when on articles [18:50:07] since it is not there [18:50:47] matanya: ah, so you want the tab bar to appear when viewing article? [18:50:54] yes [18:51:13] also the "random" was removed so no more random browsing, unless clicking on the random article link in the explore feed [18:51:38] matanya: that was a design decision to have a more focused reading experience. i think the intent is to leave the article (by pressing the back arrow at the top-- this isn't quite working right yet) when you're ready to explore new ones. [18:51:56] which i can't get to when i am reading an article, cause no why to go the the expolre feed when reading an article [18:52:16] unless many back clicks on the arrow [18:52:21] matanya: yeah, i think we had some discussion about putting random in the article toolbar but we're really struggling to keep that tight and focused [18:52:47] well, that was my flow :) [18:52:51] matanya: so the back arrow thing is a bug afaik. we just need to fix that so it uncoditionally goes back to the explore feed [18:53:05] ok, i'll dile that [18:53:08] *file [18:53:34] next is the tab counter [18:53:56] matanya: thanks. if you feel strongly that random should be part of the article viewing experience, i recommend filing a ticket about that. i personally think it's valuable but i'm not sure it's of the same worth as other buttons in the article toolbar [18:54:12] (so i would keep it out) [18:54:31] it doesn't work when in explore feed [18:57:13] matanya: ok i can repro that. i think the same thing is true of the in the news articles. we don't have those wired into the new design just yet [18:57:43] yes, you can't click on the news items [18:59:34] matanya: those will get fixed as move closer to release time. moving from the old design to the new actually involved a lot of code refactor and some of the interfaces between components are defined but currently empty [18:59:58] matanya: we have todo notes in the code for a lot of them. sorry the alpha is a bit buggy right now [19:00:44] next, when closing the app (i.e. going to home screen) you are always getting back to explore feed when resuming the app [19:00:46] no worries [19:02:07] matanya: i think that one isintentional. i'll have to check with po and design on that [19:02:47] matanya: er, let me correct myself [19:03:10] it is counter-intuitive on the notification-based we live in :) [19:03:16] matanya: if you have an article open, press home, and then relaunch the app, i think that shoudl show the article you read [19:03:34] matanya: if you press home with the feed shown, then that should show the feed when you reopen the app [19:03:59] you expect that is you checked a notification in other app and get back to the wiki app you will be at the exact place you left [19:04:39] matanya: ok, i think i see your point and that it is a bug [19:05:09] repro: read an article, press home scree, open app, be in explore instead of article [19:05:17] matanya: got it [19:05:32] will report that too [19:06:02] matanya: thanks [19:06:51] next: in history - you could long-click and article and have a sub menu - which will allow you to open an article in a new tab [19:06:58] that is gone now [19:10:02] matanya: i don't *think* we had that functionality before. are you sure? [19:10:19] no, maybe that was woshful thinking [19:10:21] sorry [19:10:25] matanya: for instance, if i open the prod app, long pressing allows me to delete items [19:10:28] a feature request [19:10:33] matanya: yeah, that's something we always wanted to do but never got around to it [19:10:45] matanya: kind of inconsistent with the rest of the app [19:11:07] i'll request that, unless it already requested [19:11:35] matanya: maybe T126925 [19:11:35] T126925: As a user I want to open pages from the history or saved pages list in a new tab - https://phabricator.wikimedia.org/T126925 [19:11:47] yes, indeed [19:12:43] matanya: on a positive but unrelated note, you might be interested to know that we've started adding some more RTL testing to our presentation logic. we should be able to detect regressions in this area more easily [19:13:00] yay! thanks :) [19:13:49] matanya: we're trying and definitely appreciate the feedback on rtl bugs especially [19:14:47] one more incosonsistency niedzielski [19:15:09] the search icons and behaviors [19:17:08] matanya: so i think there's a bug where you rotate the device and the search pops open [19:17:43] I am talking about the UI and what happens when you press the search on the top and on the bar [19:19:51] matanya: you mean that pressing the clear query button closes search? [19:20:54] if i understand correctly, the lower search is "search in page" and the upper is "search the wiki" [19:22:20] if you press the X when searching in page - it goes back to the search, if you close the search in searching the wiki, you are taken back to the article [19:22:42] matanya: sorry, that's right [19:22:56] matanya: top is search wiki and bottom is search page [19:23:25] so having two searches that mean to different things in one UI is a bit confusing [19:23:50] but having them act differently is even more confusing [19:24:47] niedzielski: more over, the search in oage in present in the dotted menu on the top too [19:25:14] but there is it a written text, and not an icon [19:25:37] matanya: i agree having two is confusing but i don't have a suggested alternative. the overflow dot menu is a bug (we're transitioning these to the article bar). i'm not sure i'm following you on the different search behaviors though [19:26:11] matanya: i'm personally pushing to add text to the article toolbar at least in landscape mode [19:26:34] matanya: are designs currently just use icons due to space constraints but i think landscape should be ok [19:26:37] our* [19:26:54] I am saying that you agreed that the top search is search in wiki [19:26:57] Am i correct ? [19:27:47] matanya: correct [19:28:10] niedzielski: and when clicking the search in the article bar - what happens ? [19:28:45] matanya: the toolbar is converted to a query field. is that's what's confusing? [19:29:12] niedzielski: which is now "search page" query field as the text days [19:29:16] *says [19:29:30] but we just agreed the top bar is for *wiki search* [19:30:21] matanya: ok i think i see your point and agree that it is confusing. i'm not sure where we should put that field though since the software keyboard covers the bottom toolbar [19:30:24] niedzielski: this means - we list the search wiki - in favor of page search - against the expected convension [19:30:38] *we lost [19:31:12] matanya: when a user is searching within a page, i think the expectation is that they should abandon that action before searching elsewhere [19:31:13] niedzielski: I think we should change the UI of the wiki search [19:31:43] matanya: for instance, you can't search in page (directly) from the wiki search either [19:32:09] niedzielski: i don't know if you have metrics for which search is more common, but i have a sense wiki search is [19:32:27] matanya: i totally agree that wiki search is way more important [19:32:33] data is needed [19:32:57] niedzielski: but i am sure we should favor wiki search over page search, and preferablly unify them [19:33:12] similar to the desktop experiance [19:34:53] matanya: maybe. i don't think we'd want to hide the article when searching in page by going to another screen. maybe we could convert the search to be a drop down list of results for wiki and the current highlight behavior otherwise. this will need some work by our design folks [19:35:45] niedzielski: yes, that would be an interesting approach [19:37:05] niedzielski: similar to the history thing, would be nice to have that from explore [19:38:01] niedzielski: also i thinked the overflow dot menu in explore is useless, as it only has hide, which is the same as swiping [19:38:02] matanya: you want to be able to find in page from explore? [19:38:25] niedzielski: No, i want to open a new tab when long-pressing [19:38:50] matanya: i felt the same way about the overflow dot menu in explore and mentioned it but i think we're planning to add more options there [19:39:05] matanya: ah i see [19:39:24] matanya: so instead of a million little overflow menus, just long press to get the options? [19:39:31] yes [19:39:41] matanya: yeah, that'd be awesome! [19:39:43] like in article reading [19:40:00] matanya: understood. yeah, i think the million little menu buttons isn't very good [19:40:19] niedzielski: sorry for so many design suggestions :) [19:40:55] matanya: that one in particular bothers me a lot. glad i'm not the only one. i'll raise it again with your long press suggestion as an alternative [19:41:31] niedzielski: in the nearby feature, when navigation services are off, clicking blue target icon does nothing [19:42:28] niedzielski: In addition, why clicking three times on the compass dismisses it ? (and why is it useful anyway?) [19:42:57] matanya: i think that's T142023. i had opened it but closed it once i saw you had made all those other issues. i'll reopen it [19:42:58] T142023: Tapping the my location button in Nearby with location services disabled should inform the user - https://phabricator.wikimedia.org/T142023 [19:43:24] thanks [19:44:54] matanya: i think that's probably mapbox sdk default behavior and didn't have a wikimedia design spec [19:45:16] niedzielski: now this is interesting, my reading list disappreas from time to time, but i don't know how to repro [19:45:28] only close the app and open it again gets it back [19:46:32] matanya: i think the compass hiding doesn't seem especially useful or harmful to me. i actually didn't even know it could be hidden by quickly tapping :] [19:46:50] every day a new discovery [19:47:28] matanya: i haven't observed the reading list bug you mentioned but will keep my eyes peeled [19:48:49] niedzielski: i think that is all for today, thanks for your time, and i'll report the ones defined as bugs [19:49:06] as for the others, i'll open tickets, but not sure in what state [19:51:17] matanya: we triage pretty regularly so just opening tickets is fine. we try to follow up there with any insights from design or other devs. of course, you're welcome to raise points and counterpoints there too. thank you so much for your evaluations. the alpha version is kind of loose right now but will tighten up before the next release [19:51:22] niedzielski: i am able to repro the reading list issue [19:51:36] matanya: ! [19:51:47] steps: [19:52:44] go to your reading list, swipe one article to delete it [19:53:02] click on history or nearby or expolre [19:53:10] and then go back to your reading list [19:53:51] niedzielski: can you repro that ? [19:54:52] (niedzielski :and your article is not removed from the list at the end) [19:56:04] matanya: ah yes. took me two times for some reason. had better luck by clicking nearby [19:56:07] matanya: great find! [19:56:23] will report that [19:57:05] ok, i'm off. thanks for your time and see you niedzielski [19:57:17] matanya: thank you!!