With the addition of Blivit-GUI, we now have ( ) Automatic ( ) Custom ( ) Advanced Custom (Blivit-GUI) I know that long ago research showed that when an "Advanced" option is presented, people tend to choose it even if it's not really right for their needs. And I'm afraid there's going to be a lot of "What's a Blivit???" questions. Could we get Design/UX involved for these labels (maybe not in time for F26 but for F27)? I'm thinking something like: ( ) Automatic ( ) Guided (Goal-Oriented) ( ) Custom (Build from Blocks) but I will definitely defer to design.
Can we get this looked at for F28?
(In reply to Matthew Miller from comment #1) > Can we get this looked at for F28? We haven't got any negative user feedback about this so far, so I wonder if anything needs to be done about it. Alternatively we can maybe ask UX people or even the community for suggestions ?
I would love to see some user studies on this; my assumption at this point is that we're not hearing about it because users are either: 1. Already-in-deep Fedora users who know what Blivit is, 2. Users who assume it's just some more random Linux jargon and ignore it, just reading "Advanced Custom", or 3. Users who see the jargon and are scared off of choosing that option. Except for case #1, this is unlikely to get users quickly on the path they want to be on. And while the case 1 users are important, I don't think having this better would _hurt_ the, either.
https://pagure.io/design/issue/559
3 options is too much. Why are there three options?
Well, the three options are: * automatic * semi-automatic (top-down approach) * manual (bottom-up approach) I don't think we should remove automatic, and the decision was made to add the manual option, so that leaves the options of 1. Revisit that decision and drop the blivit-based manual partitioning 2. Drop the semi-automatic tool 3. Figure out some way to present the three options that helps guide people to the right one. For #3, I still like my suggestion from comment #0
I think a better approach, if the approach has to be minimalistic at this point, would be add another layer. The point of automatic is that it's automatic. You should just get automatic by default and opt out of it. Do you have a screenshot of the screen? I really hope there isn't a three option radio list somewhere now :( Because you lose the point of automatic - users who don't know or don't care are confronted by a 3 item radio button list that they many times won't know how to answer. Anyway instead of doing: Hey user do you want: * automatic * semi-automatic (top-down approach) * manual (bottom-up approach) Instead do: * Automatic by default * Custom (opt-in, not an either/or choice) Then once in custom, you can have a screen that explains each and asks what you want, e.g. * Guided file-system centric partitioning * Traditional Storage-centric partitioning (using blivet) <= only include "using blivet" if it's a tech preview kind of thing we want people to look for by the word 'blivet' if not just drop the () )
Created attachment 1360416 [details] screenshot of the installation destination screen in f27 Yes, there is currently a three-option radio button list, followed by a checkbox. See attached.
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
Can we please revisit the prioritization of this? I helped two very smart young people install Fedora for the first time at the LISA systems administration conference, and both were confused by this part. Partitioning is already by far the most confusing part of the installation process, and this adds another layer.
(In reply to Matthew Miller from comment #10) > Can we please revisit the prioritization of this? I helped two very smart > young people install Fedora for the first time at the LISA systems > administration conference, and both were confused by this part. Partitioning > is already by far the most confusing part of the installation process, and > this adds another layer. Looking at the suggested options, the method suggested by Mairin in comment 7 seems the best to me at the moment - eq. having just two options by default and only showing the additional ones once the custom option is selected. We will try to implement that. :)
This bug appears to have been reported against 'rawhide' during the Fedora 30 development cycle. Changing version to '30.
Hey Martin, if your team needs any help with the layout, icons, text, etc. let me know, I am happy to help and can do mockups if those would be useful.
Some prototyping to be seen at: https://github.com/rhinstaller/anaconda/pull/2162 including actual screenshots. Labels are placeholders for now. I suspect it's a somewhat too literal interpretation. Máirín, how do you feel about that? Personally I'm not happy about this first try for multiple reasons. It would be best to figure out a solution that keeps this on a single screen, with no additional modal dialogs. Another option we discussed with Martin was to have a 2 radiobutton group that goes automatic-manual (custom?) and somehow flips a pane underneath, where if on automatic it shows the checkboxes for freeing up space and encryption, and if on manual, shows choice between the anaconda partitioning and blivet. It could entirely hide the controls, or only gray out,... I'm also somewhat unclear if the "explanation" mentioned above needs just really great labels for the controls, or an actual long-form text (sentences) visible somewhere.
Jakub, do you know someone who could help us with this bug?
I have consulted a UX designer and prepared a new pull request based on their input. Screenshots are available there. https://github.com/rhinstaller/anaconda/pull/2242 I'd like to add that this is limited in scope: Here's one piecemeal fix for what was identified as a particularly bad spot in the current GUI. The maintainer team cannot commit to a larger scope of work at this point. Please take this into consideration when providing feedback.
*** Bug 1781262 has been marked as a duplicate of this bug. ***
This looks like a big improvement. I would still try harder to discourage inexperienced users from entering the custom partitioning. Perhaps we could rename it from Custom to Expert. Or "Custom (for experts)". Something like that.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I don't think this actually landed. I'd love to see it for F33!
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I see this is still open upstream.
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle. Changing version to 36.
Hi everyone, this issue is still on our aim but it's not a priority. If you look on the existing PR in detail the changes there are not really helpful and the PR has to be created from the scratch. Because that we will not get this to the F36.
Hi everyone, we decided to focus on a Web UI and do this properly there. Given that and also because this is not a blocking issue we decided to close this bug.