Hello!
tjr asked during our last meeting whether we would consider testing Letterboxing[1] in Tor Browser even if it still were on ESR60. Here are a bunch of questions he had and we can think about in this thread:
Q: If it was ready in a 60-based Alpha would you ship it then or would you want to wait until 68?
I think we could easily test it in 9.x alphas being still on ESR60. This might in fact be a good idea as we got quite some pushback last time when we tried to fix #14429 (which, admittedly, has been a couple if years ago). One thing to worry about is how complicated the backport would be. If not really that problematic, then bonus points for that plan from my side at least.
Q: What is the minimal viable product user experience wise? Q: Does the margin needed different color or watermark?
I don't think so.
Q: Do you need a button to disable it globally or after an individual resize?
I'd be fine with a preference being exposed.
Q: Do you need it to work on mobile?
No.
Q: For very low resolution - under 100 pixels in a dimension - does it need to do something intelligent or just not do any margins at all?
I am not sure I understand the question, could you elaborate?
Q: Does it need a user walkthrough explainer? (Probably I think... maybe you can start thinking of how that would look?)
I think that sounds like a good idea. It could be another example for the general task of how to introduce new features (tracked in #29768). One idea could be that we want to have different strategies depending on how invasive a feature is: there might be features that are okay getting introduced with our onboarding and others that might need a different treatment. There are probably cons to this idea, though, like we would start training users to look at different places for getting to know whether there are new features or not. But on the other hand, we probably don't want to put everything into the onboarding either...
Georg
Thanks for this!
On Wed, 13 Mar 2019 at 14:38, Georg Koppen gk@torproject.org wrote:
Q: Do you need a button to disable it globally or after an individual resize?
I'd be fine with a preference being exposed.
So a pref that would disable it globally; but there's no way to disable it otherwise?
I realize I didn't unpack the 'individual resize' part. I had had the idea that perhaps a user is very picky about their browser, and they put it in a particular place and damn it, they don't want it letterboxed. We could show a button that disables letterboxing *until* you resize the window again, at which point you're again letterboxed and you would have to click the button again.
I would be happy to not build that ever - even more happy to not build it for the MVP.
Q: For very low resolution - under 100 pixels in a dimension - does it need to do something intelligent or just not do any margins at all?
I am not sure I understand the question, could you elaborate?
Let's say we letterbox to multiples of 100px. That means if your resolution is 150x150px, you get letterboxed to 100px x 100px.
What if your resolution is 50px x 50px? Or 50px x 175px? Currently, we don't letterbox you and your resolution is whatever you have it set to, and you're fingerprintable.
Should we do something else? I don't like the idea of locking the browser to a large size the user cannot make smaller.
Q: Does it need a user walkthrough explainer? (Probably I think... maybe you can start thinking of how that would look?)
I think that sounds like a good idea.
Me too. Can I ask antonela to put this on her plate? I can brainstorm with her an initial idea of how I envisioned it looking, and just let her take over from there? Depending on how complicated this is, and how far it differs from code I can copy-and-modify, I may not be able to complete this development task though...
-tom
Tom Ritter:
Thanks for this!
On Wed, 13 Mar 2019 at 14:38, Georg Koppen gk@torproject.org wrote:
Q: Do you need a button to disable it globally or after an individual resize?
I'd be fine with a preference being exposed.
So a pref that would disable it globally; but there's no way to disable it otherwise?
Well, I'd be fine if we had like a toolbar button expressing the option to disable that feature. But I'd be fine to test alphas without that.
I realize I didn't unpack the 'individual resize' part. I had had the idea that perhaps a user is very picky about their browser, and they put it in a particular place and damn it, they don't want it letterboxed. We could show a button that disables letterboxing *until* you resize the window again, at which point you're again letterboxed and you would have to click the button again.
I would be happy to not build that ever - even more happy to not build it for the MVP.
Then let's not start with that. :) I think that's too complicated if we aim to ship that feature with individual resizing as you explained above. Or put differently: if users are too annoyed by letterboxing then we should come up with a different solution instead of the individual resizing idea. Right now, I'd just start with letterboxing globally on/off as options and see how that goes.
Q: For very low resolution - under 100 pixels in a dimension - does it need to do something intelligent or just not do any margins at all?
I am not sure I understand the question, could you elaborate?
Let's say we letterbox to multiples of 100px. That means if your resolution is 150x150px, you get letterboxed to 100px x 100px.
What if your resolution is 50px x 50px? Or 50px x 175px? Currently, we don't letterbox you and your resolution is whatever you have it set to, and you're fingerprintable.
Should we do something else? I don't like the idea of locking the browser to a large size the user cannot make smaller.
I would not be worried about that case for a first round of testing as I'd expect the amount of devices that would be affected by that goes to 0. I mean even if we took our current resizing strategy (multiples of 200px x 100px) I doubt there are many computers/phones affected out there. So, not letterboxing for that case right now seems okay to me.
Q: Does it need a user walkthrough explainer? (Probably I think... maybe you can start thinking of how that would look?)
I think that sounds like a good idea.
Me too. Can I ask antonela to put this on her plate? I can brainstorm with her an initial idea of how I envisioned it looking, and just let her take over from there? Depending on how complicated this is, and how far it differs from code I can copy-and-modify, I may not be able to complete this development task though...
Works for me (even though I have not much of a say in antonela's time allocation :) ).
Georg
-
Georg Koppen -
Tom Ritter