19:02:11 #startmeeting tor browser - ux team sync 19:02:11 Meeting started Wed May 9 19:02:11 2018 UTC. The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:02:11 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:02:17 thanks! 19:02:17 i can but so can you :) 19:02:27 can you teach me later? 19:02:35 yep 19:02:40 thanks! 19:02:44 so, hi all :) 19:02:52 we have for today #25694 19:03:46 i read all the related tickets and came up with a proposal and then mcs suggested to use FF60 by default with some considerations 19:04:11 which seems the most sensate option for now 19:04:31 antonela: before we start could we do a current sync about the timeline for all the tickets we have 19:04:40 like what should be done first etc.? 19:04:45 oh yes sure 19:04:57 Hello 19:05:25 https://oniongit.eu/groups/ux/-/boards 19:05:25 antonela: what's your current plan in this regard? 19:05:51 do you want to review your spreadsheet or the board is ok? 19:06:11 the board is empty in my tor browser 19:06:27 :/ 19:06:49 lets go with the spreadsheet so 19:07:06 https://docs.google.com/spreadsheets/d/1joFGDiHaqlorGeXhytKakiSnWY9TqTDv5XqmbT3FkX8/edit#gid=0 19:07:45 so, one thing we basically have ready is #24309 19:07:56 GeKo: same thing for me :( 19:08:06 however we can't ship it until we have a solution for #24918 19:08:13 yes, and also android versions for tablets and android are done too 19:08:21 tablets and phones sorry 19:08:28 that's not so important right now 19:08:54 so, iirc #24918 dependend on #25695 19:08:57 #24918 is contemplated at #25695 19:09:01 yes 19:09:02 yes 19:09:14 using a default FF60 user flow 19:10:04 then we need #25693 and #25702 for esr60 as well 19:10:24 yes, i didnt touch them yet 19:10:27 and #25694 19:10:54 well, i'm designing all this tasks with Photon UI styleguide 19:11:01 so the first alpha based on esr60 is supposed to get out in 7 weeks 19:11:21 how much of our work will be there? 19:11:26 how do you think we should structure the remaining ux work for that? 19:12:09 remaining UX work is : #25658 is security settings -> i believe that last week we signed to test the shield icon version 19:13:11 yes, however that's not esr60 specific 19:13:25 so, i am inclined to give that slightly less prio right now 19:13:45 and focus on getting all the esr60 must-haves done before the first alpha 19:14:04 okey, so esr60 specific are: FF60 UI + new onboarding + new circuit display + new app icon 19:14:13 just to give them the max amount of testing we can give them before 8.0 gets out 19:14:19 yes 19:14:47 and the update experience 19:15:02 aka #25694 and friends 19:15:04 when do you think we could have it in a build for testing? If it is so hard, we can test with paper prototypes tho 19:15:22 you mean before the alpha? 19:15:32 a nightly maybe? 19:15:41 (i dont know, just wondering) 19:15:45 macOS and windows might take longer 19:15:51 linux works 19:16:02 in 2 latest 3 weeks i guess 19:16:53 great! it gives me time to prepare the documentation for testing and then we can have 2 weeks for testing and 2 weeks for iterate, what do you think? 19:17:06 before the alpha, yes 19:17:23 but i am more than fine having the while alpha cycle for testing and iterating as i said 19:17:34 which is about two more months 19:17:43 oh, thats sounds good 19:17:54 i would like to run user testing during our visit to Uganda 19:18:04 when's that? 19:18:06 which will happen in two weeks 19:18:13 so, sounds like the stars are aligned :) 19:18:22 okay, we try to make that happen 19:18:49 cool, so I'll focus 1) on document research for it 2) make sure that you have attached on tickets all the assets you need from me 19:19:12 sounds good? 19:19:34 yes 19:19:49 cool, we have a plan :) 19:19:54 yep 19:19:59 now to the actual meet 19:20:04 *meat 19:20:14 * GeKo hands the mic to antonela 19:20:22 :) 19:20:37 yes, Update Tor is the ticket we are reviewing today 19:20:54 as i said, i read all the related tickets and came up with a proposal and then mcs suggested to use FF60 by default with some considerations 19:21:15 which seems the most sensate option for now 19:21:54 even, when our users tasks are not in the same context 19:22:13 something i would like to review is if this FF60 flow contemplates all the tickets that were mentioned there 19:22:21 If we use FF60 as a starting point, there are still some things we need (e.g., an “out of date” warning on about:tor, something that shows the browser has been updated) 19:22:29 there as #25694 19:22:37 mcs yes! 19:23:08 so next step for me is thinking about those 2 things initially and check if we are missing anything from the other tickets with this flow 19:23:40 what i would like to define now is, all good with going with FF60 defaults? 19:24:09 can we continue working over their UX? 19:25:02 if yes, anything critical we should consider than they don't? besides the 2 mentioned items 19:25:06 i think so 19:25:24 s/than/that 19:25:43 we should patch a bunch of things, though, i guess 19:25:52 i think so 19:26:45 GeKo: What do you mean by “a bunch of things?” 19:27:36 e.g. the text shown to the user (abuot restoring things) 19:27:50 Ah, yes, agreed. 19:28:16 and maybe we want to have a more agressive "an update is available"-icon as you mentioned 19:28:25 yes 19:28:43 and i think a ui for the download progress is a good idea, too 19:29:07 I also think Firefox lacks feedback while an update is downloading. That could be improved too. 19:29:14 :) 19:29:17 :) 19:29:30 indeed :) 19:30:11 but generally i agree with the reasoning in comment:7 in #25694 19:30:30 do you think we could have something running with the doorhanger opened? or will the download icon do their default job? 19:30:54 re downloading progress ^ 19:31:22 For download progress, we could put a message in the hamburger menu and also shown it in the doorhanger when it is open. 19:31:30 great 19:31:40 But I am not sure how difficult that will be… should be possible. 19:32:25 i wonder how hard an icon on the toolbar would be counting the seconds/minutes down 19:32:33 which are still remaining 19:32:52 yep 19:32:56 but maybe that would confuse users dunno 19:33:05 is a normal download icon behaviour? 19:33:13 like "wtf why is this icon suddenly popping up?" 19:33:17 yes 19:33:24 It seems like that info is available since they show something like it in about:preferences (but I think it is just percentage complete, not a time estimate). 19:33:33 but usually it's the users that's starting a particular download 19:33:45 *user 19:33:49 mcs: yes 19:34:04 and thus they'd expect such a progress icon on the toolbar 19:34:05 Hmm. Might be confusing. That’s why I thought to hide the details in the hamburger menu. 19:34:12 yep 19:34:25 we can definitely start with that one 19:34:38 https://trac.torproject.org/projects/tor/attachment/ticket/25694/FF60%20Updater.png 19:34:42 and think about some more fancier later on 19:34:47 *something 19:35:30 at the bottom left we have a ↑ icon, if we are downloading we could have a ↓ icon 19:35:54 There is also a Firefox/toolkit bug about switching the updater to use the same download code as user-initiated downloads, but I think it was fixed and backed out. 19:36:05 That might make it easier to get time estimates, etc. 19:36:11 i can mockup it, but then the download button is what is tracking all the downloads happening at the browser 19:36:20 anw, i can mockup both 19:38:02 what happens if the user clicks in the not now button? (does the tor button icon change saying the browser is not up to date?) 19:39:32 good question, i'd like to encourage [not now] users to change this setting in some way 19:40:11 as a [not now] kind of user, i find extremely useful when the UI bother me with updating things 19:40:12 igt0: It could. I think we change the about:tor page today (all open about:tor pages) when the browser notices it is out-of-date. 19:40:32 i like it mcs 19:40:37 We should also think about whether we need to keep the two update check mechanisms that we currently have. 19:41:05 what do you think about the red about:tor warning page in that case? 19:41:31 I think the red warning will not be missed if someone has about:tor open :) 19:42:07 Is there value in allowing users to disable automatic updates? I wonder if we should require auto updates. 19:42:35 mcs :) 19:43:19 As long as it doesn't delete my bookmarks/bookmark toolbar, automatic updates would be great :) 19:43:21 arthur seems like the main problem is not the download update step, the main problem is the restart 19:44:08 antonela: That's mode A in your image, right? So I'm wondering if we don't even need mode B. 19:44:14 looks like nobody wants to restart with all the tabs opened and no-booksmarks 19:44:14 arthuredelstein: no, we should not require it. but disabling auto updates is already pretty hard 19:44:37 arthuredelstein: yes i got it 19:44:46 (as frustrated users on the blog are over and over again reporting) 19:45:10 and we should not optimize for that mode 19:45:34 I don't mean forcing users to restart immediately, I just mean having the update downloaded and ready for the next restart doesn't need to be optional (I think) 19:45:49 At least I'm not sure I can think of a good use case 19:47:43 I just mean having the update downloaded and ready for the next restart doesn't need to be optional -> I might agree 19:48:00 Sometimes it is useful to keep old versions around and not ever have them update… but that is more of a developer issue. 19:48:06 In a sense, the downloading of the update is an implementation detail 19:48:24 yes, but we should tell users that the downloading is happening in some way 19:48:24 We could remove the about:preferences UI and keep it as a hidden pref 19:48:31 mcs: true, there is a developer use case 19:49:04 there is the other issue that we copy the whole user profile dir on windows and linux when updating 19:49:36 which is trouble for folks having little disk space left but a huge profile dir 19:49:58 GeKo: Mozilla disabled staged updates a little while ago, so that kind of copying will no longer occur. 19:50:13 aha, good 19:50:29 Mozilla has too many weird bugs with staged updates. Windows fell first, then macOS and Linux :) 19:50:42 heh 19:51:15 i am fine hiding the prefs and ui for making it harder 19:51:28 but i would not rip out the option generally 19:52:33 yeah, I agree it probably makes sense as a hidden option 19:52:45 at least for developer uses 19:52:50 I agree as well 19:53:12 should probably document it in the wiki (browser Hacking page) 19:53:58 nah 19:54:42 antonela: okay, are we good for today? 19:54:49 we are close to the hour :) 19:54:52 yes, i think so 19:55:23 I'll update Update Tor ticket this week with all what we talked about 19:55:28 and move forward with research docs 19:55:33 sounds good 19:55:39 thanks for sorting it GeKo :) 19:55:44 sure 19:55:55 thanks everyone o/ 19:56:00 #endmeeting