On Sun, 2014-03-16 at 22:05 -0400, Bill Nottingham wrote: > 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? I can be part of the System category. It hasn't been from the beginning because there was no System category when this project was started. > > 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. Choosing SSG doesn't result in using a predefined URL, it results in using content that is a part of the compose, setting various parameters. > > - '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.) Good point. However, we would need at least a tooltip on which security policy "formats" are supported. > > 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. I take all those terms as "commonly known" or, in case of logical volume, something that can be simply ignored if not understood. > > 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. I agree, but before this is fixed (a change in the anaconda installer needed), displaying a warning is better than nothing to me. > > - 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. This is not implementable with the Anaconda's architecture and addon API. > ... > > Given that, I think the interactive UI could use some significant rework > before we put it in Fedora's installation images by default. Thanks for your feedback. I must say I agree with a majority of your points. Some of them can be implemented, some of them cannot due to the architecture of the Anaconda installer and it's addon API/support. However, I think we are still quite a long time ahead before all these things need to settle down so the UI user-friendliness can be significantly improved in the meantime. But for that to happen, the addon and the whole feature needs quite a lot of attention and user feedback. The project is a year old now, but to be honest, this is the first big UI feedback it has ever gotten. And to sum it up a bit -- I think this feature doesn't complicate things for users who want to ignore it or who don't understand it. If you think it does, please tell me about it and I'll do my best to fix it. On the other hand, if somebody wants to care about security policies, they have an easy and comfortable choice. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
