-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make initial setup window whitelisting less confusing #15
Comments
Comments by email from Vitorio Okio (thanks Vito!): ...
Please, note that I called them Complementary Default Whitelists to make a distinction between any of the lists selected in Initial Setup window and future created/defined User Whitelist. The names surely could be shorten to Default Whitelists vs. Personal Whitelist. There are additional questions that this window raises:
Suggestions (IMHO): a) It would be not a bad idea to make Initial Setup window a tabbed window. The main/general tab would provide the user with concise introduction of the idea behind Complementary Default Whitelists, how and why to use them, and short explanation of the difference between Complementary Default Whitelists and the User Defined Whitelist, etc. Each of available new Complementary Default Whitelists then would be presented by its own tab, all similar to what the user sees now. Thus selecting a check box on a particular tab the user would see in a text box below only items that belong to this particular list. b) It would be good to give some more control to the user on each of these lists as well. E.g. "Remove item" button for each list. c) !RequestPolicy Preference window according with the suggestions above should make a clear distinction between User Defined Whitelist and Complementary Default Whitelists by either providing 2 different tabs or by providing a tab to the User Defined Whitelist only and either a link to Initial Setup Window, or a suggestion on how to access/review Complementary Default Whitelists, or both. Here I'm not clear on the best solution, since quite a number of options are available. E.g. the existing Whitelist button can launch a new tabbed window with the access to Users Defined Whitelist as well as Complementary Default Whitelists. d) Currently whitelist contains 2 fields "Origin" and "Destination" and sorted by "Origin". It would be very helpful to be able to re-sort by "Destination" as well, if need arises. 2.2. There currently 6 whitelists presented for a user's choice.
Or "Europe and Russia"... While politically Russia does not participate in ES, geographically however it is Part of European continent. One may say that most of the Russian territory is located in Asia. Well, while it is true, it is also true that: When selecting a criteria base for whitelist categories, it seems better to stick either to Country names (a crazy choice IMHO) or to Part of the World names (way better and logical choice IMHO):
In case in the future you would deiced to add more granularity this gives actually quite a bit of flexibility. E.g. you can always split Asia to Middle East and Asia. Or you can always split Central and South America to 2 separate entities, etc. |
Youssef O. has pointed out that it is confusing that when one opens the initial setup window later on, the boxes that are checked don't reflect what is already in one's whitelist or what one has previously added to the whitelist through the intial setup window. He comments, "when I disable 'international' and then go back to the preferences I see that 'international' has been enabled. Do we have to allow at least one selection?" |
obsolete. |
Thursday Dec 22, 2011 at 18:46 GMT
Originally opened as RequestPolicy/requestpolicy#15
The initial setup window can be confusing by prompting users to choose regions that have corresponding pre-defined origin-to-destination whitelist items. It needs to be clearer to understand the impact that selecting regions has (sometimes it doesn't appear to change the box showing the items to be whitelisted), as well as which ones a user should select. An entirely new approach is not a bad idea.
The text was updated successfully, but these errors were encountered: