Vratislav Podzimek (vpodzime@xxxxxxxxxx) said: > Thanks for your feedback, it definitely is constructive! I've recorded a > video preview demostrating the feature's functionality. Hope that > answers at least some of your and others' questions. > > https://vimeo.com/89243587 So, having watched the video, I think I'm pretty clearly against this from a interactive install standpoint, given what is presented. Here's what I see in that video. I'm not a UI/UX professional, so additional review from someone more along those lines would be great (and info on where I'm barking up the wrong tree - can always learn more.) INTEGRATION =========== Current toplevel is localization, software, and system. 'Security policy' doesn't fit as a toplevel along with that. If we wanted it as an additional item under 'System', des that mean it can't be done as an addon? INITIAL SCREEN ============== - You've got three active items: 1 - 'Change content' (button) 2 - 'Apply security policy' (toggle) 3 - 'Select profile' (button) If someone isn't familar with the specific terminology in use here, you're using three separate nouns here which all can be similar in meaning (policy, profile, content). If the user isn't familiar with all three terms, all three of these items could be seen as doing the same thing! That's not good. If I were to whiteboard some proposed improvements of the screen you have (note: not saying this is the way to go vs. a full rework), it would be something like: Apply a security policy [ YES | NO ] (1) ------------------------------------------------------------------------ ------------------------------------------------------------------------ Policy 1 | (if we want details on the selected description 1 | policy, they go here on selection) | Policy 2 | description 2 | ... | ------------------------------------------------------------------------- [ Choose another policy source ... ] (2) (1) If 'no' is selected, rest of screen is inactive (2) If this is still desired There would be no 'select profile' button - it would be selected by just selecting the profile, similar to other anaconda actions. URL SCREEN ========== - Why is 'Use SCAP Security Guide' (presumably a predefined URL) a selection, if it is not the normal source of the choices in the initial screen? If we're shipping with predefined content sources, it should be reflected on the initial screen; if we're not using that predefined data, I'm not sure why it's an option here. - 'Enter data stream content or archive URL here'. Again, too jargon-y. Is there a reason 'Enter URL to security policy' isn't good enough? (Or whatever terminology is used in the software spoke.) PROFILE DETAILS =============== It's best when describing details (if we want to do so) that we don't use different terminology or concepts than what is used in the rest of the installer, if at all possible. In your example, we have: - 'logical volume' This only shows up in custom partitioning, and even then not very foregrounded (unless I'm missing something). - 'mount options' Not used anywhere. - 'package', 'list of installed packages', 'list of excluded packages' Packages are not exposed in the installer UI as user-interactable objects - the only place they show up (outside of error messages) is as part of the installation progress bar. Above and beyond that: - We should not be showing things as warnings. If the policy says a password must meet certain parameters, and we let the user later set it up in a way that violates that without additional warnings or automatic remediation, that's a bug. - The error situation is even worse. It's really bad form to show them an error in spoke A *that they inherently have to know how to fix in spoke B*. Otherwise, you're giving them an easy way to break their system that they won't know how to get out of, with no indication of where they have to go to fix it. Selecting the error should take them to the screen where they can fix it, and it should be a 'normal' installer screen that they've seen and can get documentation on, not something 5 layers deep in a custom workflow that they wouldn't know how to get to again. ... Given that, I think the interactive UI could use some significant rework before we put it in Fedora's installation images by default. Bill -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
