19:03:50 <mikeperry> #startmeeting app-dev
19:03:50 <MeetBot> Meeting started Tue Jan  5 19:03:50 2016 UTC.  The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:03:50 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:04:43 <mikeperry> ok, so welcome to the first applications team meeting of the new year!
19:05:28 <mikeperry> how is everyone doing? who all do we have today?
19:05:59 * mcs is here with brade
19:06:03 * boklm is here
19:07:11 <mikeperry> hurray. small, but non-zero crowd. I realized I forgot to announce the date/time at the state of the onion talk :/
19:07:27 * GeKo appears
19:07:34 * kernelcorn is here but doesn't have anything to report
19:08:26 * dcf1 listening too.
19:09:21 <mikeperry> aha. a dcf1. how goes your censorship usability study work? when is the next stage of it?
19:10:16 <dcf1> I think the next stage is to implement a working mockup of a revised interface,
19:10:46 <dcf1> and then run a test to compare it to what we've tested already.
19:11:14 <dcf1> So it is hacking and then working out some recruiting.
19:11:31 <dcf1> One dream I have is to give the participants an instrumented Tor Launcher
19:11:52 <dcf1> that logs timestamps whenever they click something, so that we can build a graph of transitions between wizard panels
19:12:11 <dcf1> and learn things like how often people backtrack, how long they stay on certain screens, etc.
19:12:21 <dcf1> That's obvs just for the user study, not for merging into Tor Browser.
19:12:40 <dcf1> I'm not sure if Ganesh shared a link to the latest prototype visualization, let me find it.
19:13:35 <mcs> How many participants will there be?
19:13:52 <dcf1> I think we're aiming for a few dozen.
19:13:57 <mcs> thanks
19:13:58 <dcf1> I'm not sure of the logistics for all that.
19:14:13 <dcf1> https://marvelapp.com/15a2294
19:14:20 <dcf1> This is the most recent mockup I believe.
19:14:54 <dcf1> That's by Ganesh, a design student we're working with.
19:15:31 <dcf1> Also I know recently there was a ticket that proposed making the changes in Tor Launcher that don't require a large redesign, like adding or revising text.
19:15:46 <dcf1> I wonder if there's a way to test how much that helps in isolation...
19:16:46 <dcf1> We're not going to be able to get together in person until next week.
19:17:06 <dcf1> I'm trying to get us to track these design iterations on a wiki page or something.
19:17:53 <GeKo> dcf1: what are your plans regarding your "dream". do you have anybody to make these code changes?
19:18:22 <mcs> It would be great to get feedback on the changes proposed in #11773
19:18:30 <dcf1> GeKo: I was just going to do it myself.
19:18:35 <GeKo> ok
19:18:42 <mcs> But we may go ahead with them either way ;)
19:19:03 <mcs> (that decision is a team one of course)
19:19:09 <mcs> (TB team)
19:19:13 <dcf1> mcs: that's the ticket I was thinking of, thanks.
19:19:37 <mcs> I wonder if general XUL instrumenting code exists somewhere?
19:19:58 <mcs> It shouldn’t be too hard to hack something together.
19:20:07 <dcf1> I looked into it a bit; nothing really obvious jumped out. I did a little prototype where I just called a log function inside all the relevant callbacks.
19:22:55 <mikeperry> I like this mockup btw
19:24:24 <mikeperry> if we do auto bridge discovery using domain fronting to bridgedb, I wonder if the "no bridge (default)" could be "Test Bridges for me automatically" or something? but then we'd probably want a short string that explains that this is risky and should be done from a cafe or something
19:26:01 <dcf1> So the default is to use a discovered bridge, not use vanilla Tor?
19:27:30 <dcf1> Part of the idea in these screens (which I like) is to put the yes/no decision on whether you need to use a bridge or proxy on the same screen as the one where you configure the bridge or proxy.
19:27:45 <dcf1> If you don't need either, you can still "next next" through the screen.
19:27:46 <mikeperry> well, there are two risky decision points that we need to make sure we properly communicate: the "Connect" vs "Configure" one, and the "autoprobe for bridges" vs "pick/enter a specific bridge that you know works"
19:28:13 <dcf1> We saw some people click "Yes" just to see what they would be offered, then back out.
19:28:38 <dcf1> Ganesh's logic was just to fold the "Yes/No" bridge decision into the combobox, with "No" being an entry in the list.
19:29:02 <dcf1> Okay. I think this design doesn't take into account autoprobing for bridges.
19:29:13 <mcs> Kathy says there was a reason why the Yes/No step was separate, but she does not remember why.
19:29:32 <dcf1> However I think we agreed that we would change it to simulate automatic proxy detection, and just assume that there's a technical way to make that work.
19:29:33 <mcs> I think it was just a “keep complexity low” decision but I do not remember either.
19:30:18 <dcf1> mcs: that makes sense, I can understand that reasoning. Like, don't show a bunch of "HTTP, SOCKS" or whatever, if the user said they don't need a proxy or are unsure.
19:30:52 <dcf1> Hopefully we can largely clear out that minefield with automatic proxy detection (plus manual override if necessary).
19:31:29 <mcs> The mockup avoids yes/no for bridges by folding the “no” choice into the dropdown (seems good to me). Proxy still has yes/no, effectively.
19:31:38 <dcf1> I think a big improvement could come just from a reassuring message like "according to our tests, you do not need to configure a proxy" where we just inspect the registry or other browsers or something.
19:32:52 <dcf1> I.e., detection of proxy non-necessity.
19:33:46 <dcf1> The other thing that might not come across in the visualization is that you get a summary of what you have configured while you look at the progress bar
19:34:42 <mcs> I really like the summary of settings as well as the Step 1 / Step 2 / Step 3 design. I don’t know if users will like it, but I think they will and it will help avoid confusion.
19:34:58 <isis> someone on twitter pointed us at a potential grant we might apply for in the UK: https://twitter.com/STFC_Matters/status/684342940383211520 https://twitter.com/yawnbox/status/684434215442616320
19:35:27 <isis> i'm not exactly sure who should know about that… maybe shari?  or katina?
19:35:44 <dcf1> We'll try it and see :) I am accustomed to being surprised by users by now.
19:36:28 <dcf1> There's a recommendation about trying a different transport if the connection fails (https://marvelapp.com/15a2294#9199010) which #11773 has also (https://trac.torproject.org/projects/tor/attachment/ticket/11773/7-RemoveSettingsPrompt.png).
19:40:35 <mikeperry> yeah, I want an option that runs through the different built-in bridges one at a time, and one that tries to get more from bridgedb and does the same. I am not sure exactly how those two should be combined, because it could be a lot of waiting, or needless decision points
19:42:59 <dcf1> Roger suggested something like that too, like an ooni-probe-lite built into Tor Launcher. I know mrphs was really excited about the idea.
19:43:38 <dcf1> To me, it seemed like a separate diagnostic function; i.e., not something that would be part of the usual flow, but a "tell me what works" button.
19:44:18 <mikeperry> ah, yeah, that makes sense. then that path can warn the user that such a step is risky
19:44:21 <dcf1> Maybe a knowledgeable user could run it on behalf of a friend, or maybe you yourself are in an unfamiliar restricted network and want to see what works.
19:44:49 <dcf1> Although my mental picture of how it would look is probably different from others'.
19:45:18 <mcs> In situations where probing is OK, a “Just Do Whatever It Takes To Connect” button would be nice to have if it could do its work quickly (no guarantee of that though).
19:45:30 <igna> "according to our tests" would need a link to support trust.
19:45:49 <igna> To the tests.
19:46:32 <igna> So maybe not so valuable since it would break the flow.
19:47:07 <dcf1> mcs: I think it could be a good opportunity for education and outreach if you do it right. Like, I think such a button should not only get you connected, but should also display a little summary of what worked, so you get some understanding and can maybe do it yourself next time.
19:47:23 <mcs> mcs: Make sense.
19:47:30 <mcs> dcf1: ^
19:48:55 <mcs> I think it is also important that the UI design and testing work be done with implementation in mind (so we get results that can be implemented fairly soon). But that goal is from the Tor Browser engineering team side and may not be aligned with academic goals, etc.
19:49:58 <dcf1> I think we were at least going to make a running XUL prototype, not sure.
19:50:13 <dcf1> We need something running for people to use in the study.
19:50:30 <dcf1> Some of the functional code (like proxy detection), we will probably just fake.
19:50:58 <mcs> OK. But if “probe for proxy” or “determine which bridge will work” are hard to do but needed for the new UI, the feedback will be less useful in the medium term.
19:51:13 <mcs> (I do not know how hard those things are)
19:51:24 <dcf1> Sure, understood.
19:51:37 <igna> Is there a real time constraint on the study?
19:52:04 <dcf1> I don't know either but I have been working under the gut feeling that proxy detection is not very hard and automatic bridge testing is probably a pain in the ass.
19:52:23 <dcf1> Because it might need e.g. some kind of richer control port feedback or changes in tor.
19:53:19 <dcf1> igna: no hard constraint, but probably will be in the next couple of months.
19:53:34 <mcs> dcf1: Makes sense. Definitely a “the pain is in the details” kind of thing.
19:54:52 <igna> Regarding impimentation, it could easily become a crippling bottleneck.
19:55:06 <igna> Thanks for the eta.
19:55:28 <igna> *implimentation
19:56:22 * Phoul is here
19:57:45 <Phoul> (sorry for being late, apparently I did not adjust for TZ properly, reading backchat)
19:59:11 <mikeperry> I think we're at the hour mark now, probably actually time to wrap it up unless people have anything urgent/specific
20:02:26 <mikeperry> ok, I'm going to call it. thanks everyone. see you next month!
20:02:32 <mikeperry> #endmeeting *baf*