GNOME Bugzilla – Bug 755292
Preferences GUI refresh
Last modified: 2018-08-03 20:33:53 UTC
Tracking bug to changes that (will) need an update in the Preferences GUI.
Created attachment 311686 [details] Preferences GUI mockup v1
Thanks, this is helpful. :) I think the open files automatically option is pretty dumb, but maybe other developers have a reason to favor keeping it, not sure. We should get rid of the enable plugins option. Plugins aren't supported in Wayland, and you shouldn't install plugins unless you want them to be enabled. We should get rid of the default encoding option. If you set it to UTF-8, or anything other than latin1, you will break a bunch of websites and fix almost none, so it's a bad idea to have that setting. If you need to change encoding, you should do so from the hamburger menu, which lets you change it on a per-page basis without breaking the entire Internet. There are a few tricky dependencies between some of these preferences. The Protect My Privacy option seems nice, but it prevents you from blocking website data storage in your mockup. I think the dialog would work just as well without that option, and with the other options sensitive always. We can also merge the do not track setting with the block bad connections setting; there's no point in keeping them separate. (Also, there is a third functionality -- stripping query parameters known to be used for tracking -- that is currently tied to the do not track setting, which doesn't make sense as the setting is currently worded, so merging them solves that too.) Saved passwords shouldn't be on this page, although they currently are, since that has nothing to do with privacy. I'm not sure if we should even offer the ability to turn this off, since you can't possibly be using secure passwords unless you're using the password manager. Lastly, we need to think about how to handle website storage. At first I thought treating all types of storage the same as cookies was a great idea (and surely that is what we should do for the cookies dialog), but we shouldn't block access to website storage unless a major browser has chosen to do so first, so we can't really treat them the same on this part of the preferences dialog. The next hard question is what to do with the adblock settings. I like your mockup but there is one complication: the "block connections known for disrespecting my privacy" setting is not going to be useful without adblock enabled. We can't display that dependency if they are shown on different tabs. One option would be to remove references to the adblocker and just treat all ads as "connections known for disrespecting my privacy." Then we could have a Manage Filters button next to that option, like the Manage Cookies and Manage Passwords buttons we have now. But, that suggestion conflicts with my next suggestion below. Lastly, I think the Data tab should be pulled out of the preferences dialog, since it has nothing to do with your preferences. We used to have a Personal Data dialog that could be opened from the app menu. It would be good to go that route again. It probably doesn't need to include History, either, since that's important enough to be accessible separately. But if we do that, then we would follow your mockup in removing the Manage Cookies, Manage Passwords, and Clear Personal Data options, and then the Manage Filters option I suggest above would be out of place.
By the way, you could talk to #gnome-design about where to find their Inkscape templates if you want to make the mockups look more realistic.
(In reply to Michael Catanzaro from comment #2) > I think the open files automatically option is pretty dumb, but maybe other > developers have a reason to favor keeping it, not sure. It is also unnecessary, since there is already a download bar. And it's also very dangerous, since GNOME Web doesn't have a "confirmation dialog" like Firefox, so, websites could, on its own, download AND execute malicious files. > We should get rid of the enable plugins option. Plugins aren't supported in > Wayland, and you shouldn't install plugins unless you want them to be > enabled. Agreed. And, since Wayland is almost there, I vote for disabling plugin support in X too. Reasons: plugins are obsolete, dangerous, mostly closed-source and almost useless. This can also avoid bugs and/or reduce work/trouble of the maintainers, I think. > We should get rid of the default encoding option. If you set it to UTF-8, or > anything other than latin1, you will break a bunch of websites and fix > almost none, so it's a bad idea to have that setting. If you need to change > encoding, you should do so from the hamburger menu, which lets you change it > on a per-page basis without breaking the entire Internet. Excellent. > There are a few tricky dependencies between some of these preferences. The > Protect My Privacy option seems nice, but it prevents you from blocking > website data storage in your mockup. This made me think: - We want to allow the user to disable Cookies/WebStorage/IndexedDB/WebSQL and "break the internet"? > I think the dialog would work just as > well without that option, and with the other options sensitive always. We > can also merge the do not track setting with the block bad connections > setting; there's no point in keeping them separate. (Also, there is a third > functionality -- stripping query parameters known to be used for tracking -- > that is currently tied to the do not track setting, which doesn't make sense > as the setting is currently worded, so merging them solves that too.) How about this: - When "Protect my privacy" is ON: - DNT header is sent. - Tracking connections are blocked (EasyPrivacy, etc). - Tracking query parameters are stripped? (is this reliable?). - Third-party cookies are blocked? (is this still useful with EasyPrivacy?). - When "Protect my privacy" is ON: - DNT header is NOT sent. - Tracking connections are NOT blocked. - Tracking query parameters are NOT stripped. - Third-party cookies are NOT blocked. And that is it. No fine-tune. Per-domain switch maybe. > Saved > passwords shouldn't be on this page, although they currently are, since that > has nothing to do with privacy. I'm not sure if we should even offer the > ability to turn this off, since you can't possibly be using secure passwords > unless you're using the password manager. I'm not sure what to think about this one. But since user can always deny, looks fine to me. > Lastly, we need to think about how > to handle website storage. At first I thought treating all types of storage > the same as cookies was a great idea (and surely that is what we should do > for the cookies dialog), but we shouldn't block access to website storage > unless a major browser has chosen to do so first, so we can't really treat > them the same on this part of the preferences dialog. Yeah, me too. Since the specs don't define clear mechanisms for disabling/denying this techs, I'm thinking that we should give up on Bug 755290 and focus on Bug 755188. It is probably wiser to share this kind of work (and is probably more efficient to block the connections). > The next hard question is what to do with the adblock settings. I like your > mockup but there is one complication: the "block connections known for > disrespecting my privacy" setting is not going to be useful without adblock > enabled. We can't display that dependency if they are shown on different > tabs. I was treating this like: - GNOME Web has a "Blocking Engine" (BE), that uses filters. - When "Block Ads" is ON: BE uses the "Ad list(s)". - When "Protect Privacy" is ON: BE uses the "privacy list(s)". - When both are ON: BE uses both sets of lists. - When both are OFF: BE is OFF. > Lastly, I think the Data tab should be pulled out of the preferences dialog, > since it has nothing to do with your preferences. We used to have a Personal > Data dialog that could be opened from the app menu. It would be good to go > that route again. I agree. > It probably doesn't need to include History, either, since > that's important enough to be accessible separately. But if we do that, then > we would follow your mockup in removing the Manage Cookies, Manage > Passwords, and Clear Personal Data options, and then the Manage Filters > option I suggest above would be out of place. I will try something. (In reply to Michael Catanzaro from comment #3) > By the way, you could talk to #gnome-design about where to find their > Inkscape templates if you want to make the mockups look more realistic. Ok, thanks.
Created attachment 311728 [details] Preferences GUI mockup v2
(In reply to Diogo Campos from comment #4) > It is also unnecessary, since there is already a download bar. And it's also > very dangerous, since GNOME Web doesn't have a "confirmation dialog" like > Firefox, so, websites could, on its own, download AND execute malicious > files. I think it goes through the MIME type sniffer and the list of safe MIME types, so it's not completely Wild West. > Agreed. And, since Wayland is almost there, I vote for disabling plugin > support in X too. Reasons: plugins are obsolete, dangerous, mostly > closed-source and almost useless. This can also avoid bugs and/or reduce > work/trouble of the maintainers, I think. Agreed on all counts, except we will lose users if we disable Flash. :( Best put it off until Wayland comes, I'd say.... > This made me think: > > - We want to allow the user to disable Cookies/WebStorage/IndexedDB/WebSQL > and "break the internet"? Arguably, you should be using a private browsing session if that's what you want. We could replace the disable cookies setting with an option to always open a private session? > How about this: > > - When "Protect my privacy" is ON: > - DNT header is sent. > - Tracking connections are blocked (EasyPrivacy, etc). > - Tracking query parameters are stripped? (is this reliable?). > - Third-party cookies are blocked? (is this still useful with > EasyPrivacy?). > > - When "Protect my privacy" is ON: > - DNT header is NOT sent. > - Tracking connections are NOT blocked. > - Tracking query parameters are NOT stripped. > - Third-party cookies are NOT blocked. > > And that is it. No fine-tune. Per-domain switch maybe. Fine by me. > I was treating this like: > > - GNOME Web has a "Blocking Engine" (BE), that uses filters. > > - When "Block Ads" is ON: BE uses the "Ad list(s)". > - When "Protect Privacy" is ON: BE uses the "privacy list(s)". > - When both are ON: BE uses both sets of lists. > - When both are OFF: BE is OFF. It's just a matter of coming up with UI that conveys this clearly. I like the new mockup. I don't think that Privacy needs an entire tab for just one option, though; maybe that could be merged into the first tab? Also, the last tab could be called "Filters" instead of "Ads" since we can filter more than just ads (and this is what EasyPrivacy does).
(In reply to Michael Catanzaro from comment #6) > I think it goes through the MIME type sniffer and the list of safe MIME > types, so it's not completely Wild West. Ah, ok. > Agreed on all counts, except we will lose users if we disable Flash. :( Best > put it off until Wayland comes, I'd say.... Sad. > > - We want to allow the user to disable Cookies/WebStorage/IndexedDB/WebSQL > > and "break the internet"? > > Arguably, you should be using a private browsing session if that's what you > want. We could replace the disable cookies setting with an option to always > open a private session? If that is easy to implement, fine by me... ...however, the Private Mode also deals with cache and history, so, it would not be a direct equivalent. ----- A separate thing: the Private Mode currently deals only with local privacy (and may even be called "Temporary Mode"). So, would be interesting to make it forcibly turn ON all the privacy measures offered? > > - When "Protect my privacy" is ON: > > - When "Protect my privacy" is ON: Just a correction: I mean ON above and OFF below. > I like the new mockup. I don't think that Privacy needs an entire tab for > just one option, though; maybe that could be merged into the first tab? > Also, the last tab could be called "Filters" instead of "Ads" since we can > filter more than just ads (and this is what EasyPrivacy does). Nice.
Created attachment 311806 [details] Preferences GUI mockup v3
I like mockup v3. Thank you! > If that is easy to implement, fine by me... > > ...however, the Private Mode also deals with cache and history, so, it would > not be a direct equivalent. Good point. > A separate thing: the Private Mode currently deals only with local privacy > (and may even be called "Temporary Mode"). So, would be interesting to make > it forcibly turn ON all the privacy measures offered? I think so.
Created attachment 311815 [details] Preferences GUI mockup v4 Changelog: Reworked 'blocker' tab to include whitelist status and management. ( Bug 685379 ) Changed 'download folder' option text. Changed 'search with' option text. Changed 'popup' option text. Changed 'spell checking' option text.
(In reply to Diogo Campos from comment #10) > Created attachment 311815 [details] ... Hey Diogo, nice mockups! I like the layout. Here's a bunch of general advice you might find useful: * Combobox labels shouldn't run into the combobox itself - this makes it difficult for translators. They generally don't use verbs. For example: "Downloads folder" could be used instead of "Put downloads in the folder". * Switch labels should generally refer to the function itself - imagine it's a physical switch. You don't need extra verbs, like in "Use custom fonts" - "Custom Fonts" is sufficient there. See the HIG [1] for more on this. * We don't tend to use frames. Differentiating groups of controls or text with padding is just as clear, and is less distracting. I'd also recommend checking out the HIG section on writing style [2] - pay particular attention to the capitalisation rules. [1] https://developer.gnome.org/hig/stable/switches.html.en [1] https://developer.gnome.org/hig/stable/writing-style.html.en
(In reply to Allan Day from comment #11) > Hey Diogo, nice mockups! I like the layout. Here's a bunch of general advice > you might find useful: Thank you in advance :) > * Combobox labels shouldn't run into the combobox itself - this makes it > difficult for translators. They generally don't use verbs. For example: > "Downloads folder" could be used instead of "Put downloads in the folder". > * Switch labels should generally refer to the function itself - imagine > it's a physical switch. You don't need extra verbs, like in "Use custom > fonts" - "Custom Fonts" is sufficient there. See the HIG [1] for more on > this. Hmm, ok. > * We don't tend to use frames. Differentiating groups of controls or text > with padding is just as clear, and is less distracting. Nice. > I'd also recommend checking out the HIG section on writing style [2] - pay > particular attention to the capitalisation rules. > [1] https://developer.gnome.org/hig/stable/switches.html.en > [1] https://developer.gnome.org/hig/stable/writing-style.html.en I will check. However, I should note, English is hard for me (especially writing). Because of this (and my lack of experience in general) all my mockups ('draft mockups' to be fair) will definitely need a professional review before being implemented.
Created attachment 311979 [details] Preferences GUI mockup v5 Changelog: Changed words. Removed frames. Standardized vertical padding.
(In reply to Diogo Campos from comment #13) > Created attachment 311979 [details] > Preferences GUI mockup v5 > > Changelog: > > Changed words. > Removed frames. > Standardized vertical padding. Nice. There are still some capitalisation issues to look at - buttons should use header capitalisation, for example. One thing I don't quite understand is the "Blocker" section. The title seems a bit generic. Is it an Ad Blocker? Some people won't know what that is: you might need to add some description text.
It's hard to name that tab properly. My best suggestion is "Filters" but even that isn't clear. Technically it is an ad blocker, but we use it to block non-ad things (like scripts that violate your privacy) so that's not a good name for the tab....
Created attachment 312087 [details] Preferences GUI mockup v6 Changelog: Fixed more capitalizations (thanks Allan). Fixed wrong (massive) use of Switches. Removed Menus references (it's in a separated bug now). Changed layout a bit of the Languages Tab, and of the Stored Data Window. Uniformized the paddings.
Looks good to me in general, I have only a few comments/questions. - Why removing the remember passwords? I don't want the infobar to show up every time I enter a password. - Regarding plugins. The fact that they won't be supported in wayland doesn't mean we shouldn't care about them while we still support X11. If ever bring back the windows support in WebKit2, ephy could be used in windows too. So, I don't think we should design ephy based on something that still under development and most of the user don't use yet. I plan to add new API in WebKit to improve handling of plugins, allowing to block plugins individually or per website. I agree most popular plugins like flash suck, but that doesn't mean we should disable all plugins. The gnome-shell plugin to handle extensions or the evince browser plugin are examples of NPAPI plugins that we want to support (at least in X11, of course). So, instead of removing the plugins option, I would add a plugins tab in the preferences to handle the plugin policies, similar to what safari does. See https://support.apple.com/en-us/HT202819 - Website data: I would open a different bug for that, since it will not be part of the preferences dialog. I plan to add API to WebKit to allow handling all website data, we could probably discuss also what we needs from WebKit there.
(In reply to Carlos Garcia Campos from comment #17) > - Why removing the remember passwords? I don't want the infobar to show up > every time I enter a password. Yeah, I was going to raise this subject again. Because: even if implemented a 'Never ask me again' and/or 'Never ask me again for this site', the user could regret the decision and not have ways to fix. > - Regarding plugins. The fact that they won't be supported in wayland > doesn't mean we shouldn't care about them while we still support X11. If > ever bring back the windows support in WebKit2, ephy could be used in > windows too. So, I don't think we should design ephy based on something that > still under development and most of the user don't use yet. I plan to add > new API in WebKit to improve handling of plugins, allowing to block plugins > individually or per website. I agree most popular plugins like flash suck, > but that doesn't mean we should disable all plugins. The gnome-shell plugin > to handle extensions or the evince browser plugin are examples of NPAPI > plugins that we want to support (at least in X11, of course). So, instead of > removing the plugins option, I would add a plugins tab in the preferences to > handle the plugin policies, similar to what safari does. See > https://support.apple.com/en-us/HT202819 Just a correction: for now, the idea is to always ENABLE plugins on X. > - Website data: I would open a different bug for that, since it will not be > part of the preferences dialog. Yes, I will (probably) do. > I plan to add API to WebKit to allow > handling all website data, we could probably discuss also what we needs from > WebKit there. Cool. Sure.
(In reply to Diogo Campos from comment #16) > Created attachment 312087 [details] > Preferences GUI mockup v6 > > Changelog: > > Fixed more capitalizations (thanks Allan). > Fixed wrong (massive) use of Switches. I'm not sure I understand this change. What are the X marks in boxes - checkboxes? Why was the previous use of switches wrong? I still think that the blocker tab needs an explanation, and I like Michael's suggestion of calling it "Filters". You could have something like: "Filters remove advertisements from websites and block scripts that violate your privacy."
(In reply to Allan Day from comment #19) > I'm not sure I understand this change. What are the X marks in boxes - > checkboxes? Why was the previous use of switches wrong? Yes, they are (ugly) checkboxes. I changed because the HIG says that "Switches should be used for controlling services or hardware that have a clear on/off logic" etc, etc, etc... So, I ended up believing I was using wrong. What do you think? > I still think that the blocker tab needs an explanation, and I like > Michael's suggestion of calling it "Filters". You could have something like: > > "Filters remove advertisements from websites and block scripts that violate > your privacy." Ok.
Created attachment 312254 [details] Preferences GUI mockup v7 Changelog: New look, similar to Control Center (System Settings). New 'Sync' tab. Corrected font family. Sizes and paddings similar to real life. Prettified elements. Reintroduced 'ask to save password' option (see comment #17). ---------- I'm still not sure if the capitalizations are right...
(In reply to Diogo Campos from comment #20) > (In reply to Allan Day from comment #19) > > I'm not sure I understand this change. What are the X marks in boxes - > > checkboxes? Why was the previous use of switches wrong? > > Yes, they are (ugly) checkboxes. OK. If you're using a check box, the label should always come after the box itself. > I changed because the HIG says that "Switches should be used for controlling > services or hardware that have a clear on/off logic" etc, etc, etc... > > So, I ended up believing I was using wrong. What do you think? I think that it's tricky. :) There are certainly places where I've broken the rule you just cited from the HIG, largely in order to allow a nicer layout. I think this is one of those fuzzy rules where you have to decide based on the context.
Hhhhm, I am not sure that I like version 7 more than version 6... the list boxes actually make it feel less organized... I wonder what Allan thinks.
(In reply to Allan Day from comment #22) > OK. If you're using a check box, the label should always come after the box > itself. But, but, Files is breaking this rule (View Popover) :P > I think that it's tricky. :) There are certainly places where I've broken > the rule you just cited from the HIG, largely in order to allow a nicer > layout. I think this is one of those fuzzy rules where you have to decide > based on the context. Ok, I will feel free to reintroduce them, if needed, then. (In reply to Michael Catanzaro from comment #23) > Hhhhm, I am not sure that I like version 7 more than version 6... :/ > the list > boxes actually make it feel less organized... Really? To be honest, I changed also because I was considering that previous layout was getting awful and messy. And, as mentioned, this is consistent with the recent panels of the System Settings. But, sure, can be changed back. > I wonder what Allan thinks. Me too.
(In reply to Diogo Campos from comment #24) > Really? To be honest, I changed also because I was considering that previous > layout was getting awful and messy. > > And, as mentioned, this is consistent with the recent panels of the System > Settings. Ah, and the "2+ lines of text right aligned" of the v6 were also difficult to read. Maybe even an accessibility/internationalization sin :P
(In reply to Diogo Campos from comment #24) ... > > the list > > boxes actually make it feel less organized... > > Really? To be honest, I changed also because I was considering that previous > layout was getting awful and messy. > > And, as mentioned, this is consistent with the recent panels of the System > Settings. ... We use lists like that in the control centre because the window is often wider than the groups of settings: the list acts as a way to bound the controls. It's also useful when you have a lot of diverse controls together, such as in the power settings. We haven't particularly used lists like that for application settings, since they tend to be bounded within a window that is sized to the controls.
Just wondering: Where is the homepage option in your mockups?
We added the homepage option more recently, after these mockups were created.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/epiphany/issues/269.