Vratislav Podzimek (vpodz...@redhat.com) 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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
