Hi all,
It was great to meet many of you while visiting the Brno office earlier this month!
Also, hi to all of you also that I didn't see this month, including some of you I already know from a long, long time ago. (:
For those who don't know me, short bio (feel free to skip): I'm a designer in the free software world (since 1996 — time flies!), and I like to work with others to help improve software interaction and aesthetics. I have a strong computer background (CS in Uni; local computer expert well before that) and have done a bunch of stuff in the community for the past few decades. You most likely know/use a few projects I started and have been involved with and might even use a photograph I snapped as wallpaper too… but anyway, back to the real subject…
Here's a link to the mockup I have been working on: https://people.redhat.com/glesage/project/anaconda/anaconda-redesign-2016-ga... (Most browsers will force you to click to zoom. Alternatively, you can wget/curl/save-as the file and open it in an image viewer and pan around at 1:1 for better viewing.)
I refined it a few times with input from several people, including Máirín. (Her comments are in the mockup in a pinkish-purple color, as we're having a discussion in the mockup itself, to try to figure out how to possibly best do certain things.)
The main purpose behind the mockup is to optimize Anaconda for both the Workstation and Server "flavors" of Fedora (and RHEL and CentOS). The mockup itself is focusing mainly on Workstation first, so not everything you see will apply to Server, and some server-specific things are deliberately omitted from Workstation. (The already-ongoing modularization efforts should really help with the differentiation between Workstation and Server too, of course.)
Naturally, this is just the start — the mockups are not meant to be concrete nor are they final — and they're missing a lot of details (mainly in screens not pictured yet and also in implied interactions based on the widgets). I'm looking forward to working with you all so that we can solidify the design and get the details defined together.
So, what do you think?
BTW: Source for the file is at https://github.com/fedoradesign/anaconda/tree/master/Visual%20Redesign%20201... in SVG (made with Inkscape). Warning: The repo is a bit messy, as it's a WIP design exploration ground. 😉
Cheers, Garrett
On 02/24/2016 05:14 AM, Garrett LeSage wrote:
So, what do you think?
Some first impressions:
Having a case to go to the storage resize screen directly after the welcome screen feels to me like a return to the linear model. I get that Workstation wants to get rid of custom partitioning, but what about drive selection? Say a user has two hard drives and wants to install Fedora to one of them. I feel like this approach to storage simplifies things a step too far.
Turning spokes into dialogs does seem to fix the problem of not knowing where the Done button is (and I do like the idea of a Cancel button even if it'll be a pain to implement), but at the loss of a good bit of screen real estate. I don't want anaconda to go down the road of having completely different widget sets for workstation and server, and no matter how much we simplify storage for workstation, server is still going to have to configure iSCSI and multipath and split it all up into 47 different partitions, all at 800x600.
Do you think that the animations between screens helps any with the confusion of how to get out of any particular screen? They're new in F22 and not shown in live VMs for annoying technical reasons.
I don't think the comparisons with gnome-control-center are exactly fair. Anaconda has used the suggested-action button class since F21 to make the button more visible. That it now gets hidden as blue-on-blue is a misfortune of themeing that could be changed (as in the button color could be the changed, not necessarily the Fedora blue background). gnome-control-center does not set the style class on its back button and it's hidden up in the header bar, which has a bunch of other stuff going on.
The last screen with all the ad banners seems really crowded with ads. It makes me think of https://www.linux-noob.com/forums/uploads/post-1-1159903128.jpg
Hi David I think that anaconda does require more smarts in the drive/selection area.I can't understand why we can't flip the role of the software for customization.Here is an example, building the /etc/fstab Directory [location] [format] [/ ] [/dev/sb3 ] [ext4 ] «-- user provides this [/root ] [/dev/sdc2] [format] «-- user provides this[/opt ] [ ] [format] «-- user provides this [/swap ] [ ] [format] «-- user provides this[/home ] [ ] [format] «-- user provides this[/boot ] [ ] [format] «-- user provides this[biosboot] [ ] [format] «-- user provides this [add +] (for /usr, /var /private additional /swaps and files, system and end-user)
Regards Leslie Mr. Leslie Satenstein Montréal Québec, Canada
From: David Shea dshea@redhat.com To: anaconda-devel-list@redhat.com Sent: Wednesday, February 24, 2016 9:46 AM Subject: Re: anaconda design mockups
On 02/24/2016 05:14 AM, Garrett LeSage wrote:
So, what do you think?
Some first impressions:
Having a case to go to the storage resize screen directly after the welcome screen feels to me like a return to the linear model. I get that Workstation wants to get rid of custom partitioning, but what about drive selection? Say a user has two hard drives and wants to install Fedora to one of them. I feel like this approach to storage simplifies things a step too far.
Turning spokes into dialogs does seem to fix the problem of not knowing where the Done button is (and I do like the idea of a Cancel button even if it'll be a pain to implement), but at the loss of a good bit of screen real estate. I don't want anaconda to go down the road of having completely different widget sets for workstation and server, and no matter how much we simplify storage for workstation, server is still going to have to configure iSCSI and multipath and split it all up into 47 different partitions, all at 800x600.
Do you think that the animations between screens helps any with the confusion of how to get out of any particular screen? They're new in F22 and not shown in live VMs for annoying technical reasons.
I don't think the comparisons with gnome-control-center are exactly fair. Anaconda has used the suggested-action button class since F21 to make the button more visible. That it now gets hidden as blue-on-blue is a misfortune of themeing that could be changed (as in the button color could be the changed, not necessarily the Fedora blue background). gnome-control-center does not set the style class on its back button and it's hidden up in the header bar, which has a bunch of other stuff going on.
The last screen with all the ad banners seems really crowded with ads. It makes me think of https://www.linux-noob.com/forums/uploads/post-1-1159903128.jpg
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Wed, Feb 24, 2016 at 11:14:24AM +0100, Garrett LeSage wrote:
Here's a link to the mockup I have been working on: https://people.redhat.com/glesage/project/anaconda/anaconda-redesign-2016-ga... (Most browsers will force you to click to zoom. Alternatively, you can wget/curl/save-as the file and open it in an image viewer and pan around at 1:1 for better viewing.)
I don't think we need to go this far. What we have is pretty good, and moderately flexible. I think that by being more flexible in how spokes are displayed we can make the various product variations happy(ish).
1. No more wizard style spokes. Throwing the user right into making a partition/resize decision isn't very friendly.
2. We have the UI config spec now, we need to implement it and teach the products how to use it to customize what's show:
https://github.com/rhinstaller/anaconda/blob/master/docs/user-interaction-co...
3. Dialogs instead of full screen spokes are just going to clutter up the display and make life difficult on smaller vertical height screens.
4. Changing the summary to a single column could be helpful, if we use that extra space for better information about spoke status/errors. Otherwise it's just wasting more screen space.
5. We should probably re-think the spoke category ordering and move them around a bit (eg. the oscap addon inserted a new category in the middle and really belongs at the bottom, IMO).
6. Why add another popup for confirmation? They already clicked the big 'Begin Installation' button which is clear enough.
7. We can't predict how long an installation will take.
8. Yeah, I like numbered lists :)
In short, I'm all for refinements of what we have (and implementing the UI config spec) but not large changes in how it operates.
Hi Brian, in case it's not clear in the mockup - the partition/resize decision popup should only happen if the installation is just not possible otherwise. The idea here is we don't want people spending say 20 minutes going through every other spoke and customizing it how they like, only to have to throw that work away because they dont have enough space for the install and there is really no possible way they can have the space. (You know, kind of like telling your kid they can pick a toy at the toy store so they carefully decide which one they want and bring it to the counter, but then oops! I forgot my wallet! No toy for you!)
I think right now we may actually throw a dialog up in the exact same spot, but that's only if the capacity of the disks detected (whether used or not) isn't enough for a minimum install. I may be wrong about that though, but I know we talked about it in the original design.
(I'm still out for this week and next but trying to catch up on email a little bit :) )
~m
----- Original Message ----- 1. No more wizard style spokes. Throwing the user right into making a partition/resize decision isn't very friendly.
Máirín,
What to do if we have two disks with adequate space, each one able to hold a full Fedora installation?For that reason, Customization is desired. I have multiple disks. I have / on one disk, /home on a second and /swap on a third for my personal development system.
Your suggestion would work if the computer was a one disk system, or if there was only free space on one disk. Regards Leslie Mr. Leslie Satenstein Montréal Québec, Canada
From: Máirín Duffy duffy@redhat.com To: Discussion of Development and Customization of the Red Hat Linux Installer anaconda-devel-list@redhat.com Sent: Wednesday, February 24, 2016 1:03 PM Subject: Re: anaconda design mockups
Hi Brian, in case it's not clear in the mockup - the partition/resize decision popup should only happen if the installation is just not possible otherwise. The idea here is we don't want people spending say 20 minutes going through every other spoke and customizing it how they like, only to have to throw that work away because they dont have enough space for the install and there is really no possible way they can have the space. (You know, kind of like telling your kid they can pick a toy at the toy store so they carefully decide which one they want and bring it to the counter, but then oops! I forgot my wallet! No toy for you!)
I think right now we may actually throw a dialog up in the exact same spot, but that's only if the capacity of the disks detected (whether used or not) isn't enough for a minimum install. I may be wrong about that though, but I know we talked about it in the original design.
(I'm still out for this week and next but trying to catch up on email a little bit :) )
~m
----- Original Message ----- 1. No more wizard style spokes. Throwing the user right into making a partition/resize decision isn't very friendly.
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Wed, Feb 24, 2016 at 11:14:24AM +0100, Garrett LeSage wrote:
So, what do you think?
Lots of good ideas. One note in specific... you mention that server will only be installed onto systems with no OS. This isn't necessarily the case. In some situations, the disk may be preloaded with some OS that should be overwritten. The other case is re-installation, which I think is going to be fairly common in any shop where people are installing servers one-by-one with Anaconda as one-offs. (In this case, reformatting / and preserving /home and /srv will be common.)
On Wed, 2016-02-24 at 16:34 -0500, Matthew Miller wrote:
On Wed, Feb 24, 2016 at 11:14:24AM +0100, Garrett LeSage wrote:
So, what do you think?
Lots of good ideas. One note in specific... you mention that server will only be installed onto systems with no OS. This isn't necessarily the case. In some situations, the disk may be preloaded with some OS that should be overwritten. The other case is re-installation, which I think is going to be fairly common in any shop where people are installing servers one-by-one with Anaconda as one-offs. (In this case, reformatting / and preserving /home and /srv will be common.)
Right. Just about any time you make an assumption to significantly simplify storage you're going to be wrong. Sad but true.
David
On 25/02/16 16:06, David Lehman wrote:
Right. Just about any time you make an assumption to significantly simplify storage you're going to be wrong. Sad but true.
Yeah, it's not possible to cover every case all the time and do so in an easily understandable manner for most things... but especially something as complicated as storage.
With regard to Workstation partitioning, however, I'm confident that we can make life nicer for at least 80% - 90% of the people using Anaconda. That's one of the goals of this effort, at least.
For the other 10 - 20% of people installing Workstation who really do want to specify everything, they will still have a similar/familiar advanced interface to do so. The difference is that we won't drive everyone into the advanced partitioner (and force them to even understand partitioning or complicate storage things they *could* possibly do).
There are three main cases for Workstation installs: 1. Empty disk(s). It's obvious what to do here... Have a predefined recommended partition layout and use that. Advanced partitioning spoke can, of course, still be selected from the Hub screen for fine-tuning or completely different layouts. 2. Disk(s) with data, with more than enough room for Fedora. Same as #1, except existing data will not be wiped out. 3. Disk(s) with data, but not enough room. This is where the simple partitioning screen shows up. There's a path through the advanced paritioning tool as an action on this screen (and you can also get back from the Hub screen).
So: 1 & 2 (enough space due to empty disk or pre-partitioned disk) will be pre-configured by default. 3 will show the resize screen (which has options to go to the advanced installer or erase and use the entire disk, in addition to resizing).
It does get a little more complicated when there are multiple (non-USB / non-SDcard) storage devices on the system; I have some ideas and will work on mockups to handle that soon.
Partitioning on a Server install is a different beast, of course. We're not there yet; the first step is mainly simplifying Workstation. I'm not sure how much simplification (if any) can happen on a Server install.
Cheers, Garrett
On Thu, 2016-02-25 at 18:14 +0100, Garrett LeSage wrote:
On 25/02/16 16:06, David Lehman wrote:
Right. Just about any time you make an assumption to significantly simplify storage you're going to be wrong. Sad but true.
Yeah, it's not possible to cover every case all the time and do so in an easily understandable manner for most things... but especially something as complicated as storage.
With regard to Workstation partitioning, however, I'm confident that we can make life nicer for at least 80% - 90% of the people using Anaconda. That's one of the goals of this effort, at least.
I can appreciate that, provided it retains some basic flexibility.
For the other 10 - 20% of people installing Workstation who really do want to specify everything, they will still have a similar/familiar advanced interface to do so. The difference is that we won't drive everyone into the advanced partitioner (and force them to even understand partitioning or complicate storage things they *could* possibly do).
People seem to resist this, but it would be really great IMO if we could stop calling it "partitioning" and start calling it "storage configuration" since partitioning is only a fraction of what goes on.
There are three main cases for Workstation installs:
- Empty disk(s). It's obvious what to do here... Have a predefined
recommended partition layout and use that. Advanced partitioning spoke can, of course, still be selected from the Hub screen for fine-tuning or completely different layouts. 2. Disk(s) with data, with more than enough room for Fedora. Same as #1, except existing data will not be wiped out.
We did that in F18 or F19 and several users (including me) didn't like that you don't even have the option of making more space in this case.
Also, thanks for working on this.
David
- Disk(s) with data, but not enough room. This is where the simple
partitioning screen shows up. There's a path through the advanced paritioning tool as an action on this screen (and you can also get back from the Hub screen).
So: 1 & 2 (enough space due to empty disk or pre-partitioned disk) will be pre-configured by default. 3 will show the resize screen (which has options to go to the advanced installer or erase and use the entire disk, in addition to resizing).
It does get a little more complicated when there are multiple (non- USB / non-SDcard) storage devices on the system; I have some ideas and will work on mockups to handle that soon.
Partitioning on a Server install is a different beast, of course. We're not there yet; the first step is mainly simplifying Workstation. I'm not sure how much simplification (if any) can happen on a Server install.
Cheers, Garrett
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Thu, 2016-02-25 at 12:22 -0500, David Lehman wrote:
On Thu, 2016-02-25 at 18:14 +0100, Garrett LeSage wrote:
On 25/02/16 16:06, David Lehman wrote:
Right. Just about any time you make an assumption to significantly simplify storage you're going to be wrong. Sad but true.
Yeah, it's not possible to cover every case all the time and do so in an easily understandable manner for most things... but especially something as complicated as storage.
With regard to Workstation partitioning, however, I'm confident that we can make life nicer for at least 80% - 90% of the people using Anaconda. That's one of the goals of this effort, at least.
I can appreciate that, provided it retains some basic flexibility.
For the other 10 - 20% of people installing Workstation who really do want to specify everything, they will still have a similar/familiar advanced interface to do so. The difference is that we won't drive everyone into the advanced partitioner (and force them to even understand partitioning or complicate storage things they *could* possibly do).
People seem to resist this, but it would be really great IMO if we could stop calling it "partitioning" and start calling it "storage configuration" since partitioning is only a fraction of what goes on.
There are three main cases for Workstation installs:
- Empty disk(s). It's obvious what to do here... Have a
predefined recommended partition layout and use that. Advanced partitioning spoke can, of course, still be selected from the Hub screen for fine- tuning or completely different layouts. 2. Disk(s) with data, with more than enough room for Fedora. Same as #1, except existing data will not be wiped out.
We did that in F18 or F19 and several users (including me) didn't like that you don't even have the option of making more space in this case.
Also I wonder how frequent this case would actually be - how would you actually get a disk that is partially used, but has significant unallocated space ?
Completely empty disk I can imagine (fresh from the factory) as well as completely allocated one (pre-installed Windows, some Linux distro install, etc.) but how would a normal user get a disk that is not either empty or fully allocated to something ?
I can only think of people creating such a layout themselves to use/try multiple Linux distros or other operating systems. I'm not sure if there would be very many of those & if they would need a simplified partitioning screen given their apparent ability to create custom storage layouts.
Also, thanks for working on this.
David
- Disk(s) with data, but not enough room. This is where the
simple partitioning screen shows up. There's a path through the advanced paritioning tool as an action on this screen (and you can also get back from the Hub screen).
So: 1 & 2 (enough space due to empty disk or pre-partitioned disk) will be pre-configured by default. 3 will show the resize screen (which has options to go to the advanced installer or erase and use the entire disk, in addition to resizing).
It does get a little more complicated when there are multiple (non- USB / non-SDcard) storage devices on the system; I have some ideas and will work on mockups to handle that soon.
Partitioning on a Server install is a different beast, of course. We're not there yet; the first step is mainly simplifying Workstation. I'm not sure how much simplification (if any) can happen on a Server install.
Cheers, Garrett
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On 26/02/16 19:56, Martin Kolman wrote:
Also I wonder how frequent this case would actually be - how would you actually get a disk that is partially used, but has significant unallocated space ?
Those with partially allocated disks, before starting Anaconda, would have most likely already used:
- GParted from a Fedora Live boot (IIRC, it needs to be dnf installed over the network, but still works) - a special boot-into utility like a GParted boot live disk, Partition Magic, or OS X rescue before booting Fedora
Using one of the tools above, the person would have previously adjusted partitions to make space for Fedora. (All of these tools allows for someone to resize and remove partitions — such as old Linux installs, unused data directories, etc.)
It certainly wouldn't be something as common as a full drive — or probably not even as likely as a completely empty disk (from the factory or after upgrading to larger+faster disk/SSD), but it's a common enough workflow.
Last time I tried installing Fedora on an old Mac, I seem to remember having to resize in the OS X rescue partition — IIRC, Anaconda didn't support resizing OS X at the time. This might have changed since, but I'm uncertain if it has. So, I certainly did have to go the route of using an external (to Fedora) tool to resize partitions to make space.
I can only think of people creating such a layout themselves to use/try multiple Linux distros or other operating systems. I'm not sure if there would be very many of those & if they would need a simplified partitioning screen given their apparent ability to create custom storage layouts.
Not everyone installing Linux necessarily has an ability to understand storage layouts. (In fact, I'd suggest that most do not — and some might just know enough to install. Sure, some learn by necessity, but knowing all about disks, partitions, storage pools, and such should not stop someone from using Linux.)
Cheers, Garrett
On Fri, 2016-02-26 at 19:56 +0100, Martin Kolman wrote:
On Thu, 2016-02-25 at 12:22 -0500, David Lehman wrote:
On Thu, 2016-02-25 at 18:14 +0100, Garrett LeSage wrote:
On 25/02/16 16:06, David Lehman wrote:
Right. Just about any time you make an assumption to significantly simplify storage you're going to be wrong. Sad but true.
Yeah, it's not possible to cover every case all the time and do so in an easily understandable manner for most things... but especially something as complicated as storage.
With regard to Workstation partitioning, however, I'm confident that we can make life nicer for at least 80% - 90% of the people using Anaconda. That's one of the goals of this effort, at least.
I can appreciate that, provided it retains some basic flexibility.
For the other 10 - 20% of people installing Workstation who really do want to specify everything, they will still have a similar/familiar advanced interface to do so. The difference is that we won't drive everyone into the advanced partitioner (and force them to even understand partitioning or complicate storage things they *could* possibly do).
People seem to resist this, but it would be really great IMO if we could stop calling it "partitioning" and start calling it "storage configuration" since partitioning is only a fraction of what goes on.
There are three main cases for Workstation installs:
- Empty disk(s). It's obvious what to do here... Have a
predefined recommended partition layout and use that. Advanced partitioning spoke can, of course, still be selected from the Hub screen for fine- tuning or completely different layouts. 2. Disk(s) with data, with more than enough room for Fedora. Same as #1, except existing data will not be wiped out.
We did that in F18 or F19 and several users (including me) didn't like that you don't even have the option of making more space in this case.
Also I wonder how frequent this case would actually be - how would you actually get a disk that is partially used, but has significant unallocated space ?
At that point it meant you did not even get the option to make a custom layout, so I'd say one user is too many for that behavior.
David
Completely empty disk I can imagine (fresh from the factory) as well as completely allocated one (pre-installed Windows, some Linux distro install, etc.) but how would a normal user get a disk that is not either empty or fully allocated to something ?
I can only think of people creating such a layout themselves to use/try multiple Linux distros or other operating systems. I'm not sure if there would be very many of those & if they would need a simplified partitioning screen given their apparent ability to create custom storage layouts.
Also, thanks for working on this.
David
- Disk(s) with data, but not enough room. This is where the
simple partitioning screen shows up. There's a path through the advanced paritioning tool as an action on this screen (and you can also get back from the Hub screen).
So: 1 & 2 (enough space due to empty disk or pre-partitioned disk) will be pre-configured by default. 3 will show the resize screen (which has options to go to the advanced installer or erase and use the entire disk, in addition to resizing).
It does get a little more complicated when there are multiple (non- USB / non-SDcard) storage devices on the system; I have some ideas and will work on mockups to handle that soon.
Partitioning on a Server install is a different beast, of course. We're not there yet; the first step is mainly simplifying Workstation. I'm not sure how much simplification (if any) can happen on a Server install.
Cheers, Garrett
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Hi all!
Thanks for all your feedback so far! It's been great. Instead of replying to each email individually, I've compiled a summarized list of points from the different emails and have replied to each below.
Apologies in advance for a super-long email. Feel free to skip to the parts you'd like to see responses for or to the quick summary (at the very end). I've made the questions in Markdown-like / ATX-style headings (look for the two hash signs "##").
## Storage screen == linear? and Wizard vs. Hub-and-spokes
Right now, Anaconda *already* is a hybrid between hub-and-spokes and a wizard. There's a welcome and language screen before you see the spoke settings, and there's an installation progress screen after. If it were purely hub-and-spokes, then you'd only have the hub screen and everything else would be a spoke.
The idea in the design mockups pushes the critical question of "where should this go?" when it needs to be asked. Right now, we're hoping that someone knows that they need to go into the partitioner, then understand what they're doing, and finally jump back out to continue onward. I've found that's often not the case, in a little bit of semi-informal research I've conducted (in my free time) in the past year.
One kind of funny example I encountered: A quite-technical co-worker who routinely installs Fedora for work told me that he originally thought his hard drive was "bad". He eventually even bought a new hard drive — and after thinking that one was marked as being bad too. Of course, after a little bit of questioning, it turned out that it's just how Anaconda flags a necessary step — even when it should not be necessary (as in the case of a blank drive). Consider that he's a technical person, who has been using Linux for well over a decade now and that other people with less knowledge and experience are running into the same thing.
Anaconda currently forces everyone into the partitioner. It would be nice to make that an optional place to visit to ensure that people are much more likely to install and use Fedora under normal circumstances. (How many people tried to install Fedora and gave up when they saw that their "disk had an error" or when they were confused while trying to figure out even what partitions are?)
Breaking out that mostly-mandatory (it should be skippable when there's a blank drive) partitioning step into a separate, simplified screen solves this — and a few other — problems. It formalizes this critical step instead of pretending that it's just-another spoke setting. In the designs I've linked, it's still there as a spoke (although not pictured yet; only mentioned). In the mockups, there's an attempt for partitioning to be pre-configured based on the system's state (if there's enough space). The super-simple partitioner in the mockups (note: advanced partitioner not yet displayed in the mockups) only appears when it's absolutely needed (which, of course, would be pretty common for Workstation installs).
## What happens with two drives?
Good question. There's space in the super-simple paritioner mockup. I should mock up the case(s) where there are two drives.
A few quick notes: 1. Both drives must be internal. This is for a tower/desktop machine with actual "permanent" drives, not for USB drives. 2. What if one of the drives is completely empty? Open question that needs more consideration. 3. Most people would probably have an OS drive and a data drive. 4. In some cases, people might have LVM and/or RAID and/or BTRFS on a pre-existing system. (It's really unwise to extend a partition across disks, unless there's redundancy, however — Anaconda probably shouldn't *actively* promote this bad practice.)
Thankfully there's quite a bit of space that could be used to handle multiple drives in the super-simple partitioner. For advanced stuff (like in #4), it's probably fine to expect people to have to dive into more advanced partitioning.
Summary: Excellent point. Design not available yet; TBD.
## Screen real estate vs. dialogs
It's not a problem for most of the dialogs... so the question is, can this work for the partitioner too? I think the answer is yes (probably with a quite-large dialog — either with minimal spacing on the edges, or one that goes flush to the edges), but I'll work more on it. I have some super-rough starts of an advanced partitioner UI in a subdirectory that explore this and other ideas, but I shelved it for now, as... well, probably everyone here knows ☺... a flexible partitioner UI is, by necessity, kind of messy and involved and takes quite some time and effort to get right. If I'm going to work on some updates to Anaconda's full paritioner, I need to work with you all to make sure it's done well.
## 800x600?
Is this a *real* requirement in 2016? Most people installing on a server with an inadequate graphics chip are using a kickstart file anyway, right? And is at least 1024×768 or 1280x1024 really too much to ask for? 1024×768 is in both 8514 and SVGA from 1987 and in the VESA spec from 1994.
## Animations in F22+: Do they help?
Firstly, the animations do not work in VMs, so it needs to be visibly apparent in a different way. Animations cannot be relied upon within Anaconda, but they can definitely help when used tastefully. It's a good idea to think about how best to display them without going too over the top. (Some people use so many animations in slide decks during presentations that it makes the audience mostion sick. Used sparingly and effectively, however, animations definitely can help illustrate.)
Sorry for the almost non-answer. ☺
Simple answer: Yes. ☺
## Button styling
Yes, it's unfortunate that the blue button is on a blue background.
As for GNOME's control center (mentioned in context of the button styling): In addition to location (being at the top-left), it also uses change (the button appears in the top left) and animation (the button and content area both cross-fade into view quickly) to highlight the back button. Also, the absence of other elements directly nearby help to highlight it (that is: intentionally uncluttered). In the next version of GNOME and GTK+, buttons are slightly darker, which makes things like buttons in the headerbars even more prominent.
But, back to Anaconda: Yes, it should be style, positioned, and labeled, and possibly even animated (in a subtle way) to be obvious.
## Screen with ad banners: Crowded with ads
I agree; that's why it's my opinion that there shouldn't be ads. I added the ad idea with 3-up as a solution to a few problems (mentioned in the mockup as well as in an issue on the repo's issue list).
It's ironic that there are ads in a free software distro that highlights freedom. There's also the problem that all the current ads require people to remember everything until the system has rebooted and is back at the desktop — and the content is out-of-date and does not highlight the best of Fedora anyway. That's why I strongly believe the correct place for ransom-notes (installer ads) is not the installer, but start.fedoraproject.org, which is what shows up in everyone's browser after a fresh install.
Also, the continued prevalence of ads in the installer is sort of my fault in a way, and I apologize. Back when I worked for Red Hat in 2002 - 2004, I made tons of popular ransom notes / installer ads including things like the fortune cookies and even gave a certain famous dancing hotdog a spotlight during installation time. The ads have stuck around since, even though installer time has gotten much, much quicker... and the quality of the installer ads has gone down. Oops. 😉
I do think there is a use in self-promotion, but it's probably not in the installer (but should be in the start page).
## Why a confirmation dialog?
It doesn't show up when the drive is blank. It is only displayed when there's possible data loss.
## We can't predict how long an installation will take
Sure we can! It's possible to time it on different hardware setups and see the current progress and make a best effort estimation. Display a tuned time estimate only after you get a bit of IO on the disk. I've personally built time estimations before, for exactly this same scenario (installation, including custom selected packages, when working on SUSE Studio a few years back), so I know it's possible.
It doesn't matter if the estimation isn't *completely* accurate. Seconds don't really matter, in other words. People want to know if they should get a coffee from a machine in the kitchen, brew a specialty cuppa themselves, or can sneak out for a lunch break with their coffee. (2 minutes is different from 7, which is different from 32, etc.)
The progress bar should be smoothly animated in a smart way. I know that there isn't a way to know exactly what is going on in many stages when it is happening, but the transition *can* be smoothly animated based on heuristics based on timing data (includes controlled trial-runs as well as system-specific information). This isn't hand-wavy; Again: I've actually worked on this exact problem in the past, so I know it's 100% achievable.
## Servers with existing OS
Good point. Severs will often have no OS, but for reasons you state, they will often also have an OS — usually with a pre-existing installation that should be overwritten. While the mockups right now primarily focus on Workstation, the notes inside (which do mention Server in a few places) should definitely be updated, and this should be a priority acknowledgment when it's time to concentrate a bit more on the Server-specific flavor of Anaconda.
## SUMMARY
Super-quick summary of all the above:
1. Still mostly hub-and-spokes overall, but Anaconda is *already* hybrid right now. 2. Two drives needs to be considered more; design TBD (to be done). 3. Screen real estate will be considered; dialogs would work for everything, with a possible slight special casing for partitioning (but we will see). 4. 800×600 seems awfully small; 1024×768 was already commonplace starting _in 1987_. See open question below. 5. Animations can definitely be useful, but should be used carefully. 6. Making critical buttons obvious enough is important. Styling plays a part, along with many other factors. 7. Ads: I don't like 'em myself and believe start.fedoraproject.org is the proper place for content like this. 8. Confirmation dialog: Design (and implementations) should strive to minimize data loss overall. When the task is to remove data (without the possibility to undo), it's important to help ensure people know for a fact what's about to happen. 9. There are definitely ways to predict how long an installation will take (speaking from experience from working on OS installation estimations with a progress bar). It doesn't need to (and arguably should not) be accurate. 10. Servers with existing OS: You're right… and the notes need to be updated.
## Open questions
- What's the minimum (and modern) *realistic* resolution that needs to be supported in Workstation installs? and in Server installs? (It might be different.)
Hopefully this all helps! Also, I'm often hanging out in #anaconda on both internal and Freenode IRC (Monday - Thursday, in European time) in case you'd like to chat in closer-to-real-time too. ☺
Garrett
On Thu, Feb 25, 2016 at 05:46:11PM +0100, Garrett LeSage wrote:
I agree; that's why it's my opinion that there shouldn't be ads. I added the ad idea with 3-up as a solution to a few problems (mentioned in the mockup as well as in an issue on the repo's issue list). It's ironic that there are ads in a free software distro that highlights freedom. There's also the problem that all the current
I don't see that as particularly ironic. They're not revenue-based ads, they're just information-sharing.
But I don't think they really serve that purpose very well, in any case. I think their main function is to give you sometihng interesting / pretty to look at while the installer is doing slow, boring things. Sometimes, you're stuck in a server room waiting for that to go by.
I suppose this is less of an issue now that all of the sysadmins / operators have smartphones they can check social media on while the install goes. :)
and does not highlight the best of Fedora anyway. That's why I strongly believe the correct place for ransom-notes (installer ads) is not the installer, but start.fedoraproject.org, which is what shows up in everyone's browser after a fresh install.
start.fpo does do that, but as a separate design project, it'd be nice to imaging a world where it doesn't. I know Allan Day wanted to go to the blank new tabs display as more logical for the browser. And it might be the case that in the future, we're shipping an umodified upstream xdg-app Firefox without such local modifications. I certainly don't think Anaconda is the place for it (so, sorry for the off-topic aside here), but it'd be nice to figure out some _other_ way to connect Fedora desktop users into project news and activity.
On Thu, Feb 25, 2016 at 05:46:11PM +0100, Garrett LeSage wrote:
- What's the minimum (and modern) *realistic* resolution that needs
to be supported in Workstation installs? and in Server installs? (It might be different.)
FWIW, Virt Manager installs default to 1024x768. For server, I'm pretty sure 1024x768 should be universally supported, and where I'm wrong, there's kickstart and cmdline mode. The one case I can think of for lower resolution is marginally faster remote desktop when installing via DRAC/ILOM, but that seems like a minor concern.
On 02/25/2016 11:46 AM, Garrett LeSage wrote:
Is this a *real* requirement in 2016?
Yes. ppc64le uses a VNC interface with a 800x600 display. Even ignoring that case, the X1 carbon has 2560x1440 pixel screen which, when scaled to adjust for the high dpi, has an effective resolution of 1280x720. This caused trouble on screens that expected 768 vertical pixels.
On Thu, Feb 25, 2016 at 01:13:40PM -0500, David Shea wrote:
On 02/25/2016 11:46 AM, Garrett LeSage wrote:
Is this a *real* requirement in 2016?
Yes. ppc64le uses a VNC interface with a 800x600 display. Even
That might go towards different default for Server and Workstation, though, right? Or are people running PPC-LE as desktops?
ignoring that case, the X1 carbon has 2560x1440 pixel screen which, when scaled to adjust for the high dpi, has an effective resolution of 1280x720. This caused trouble on screens that expected 768 vertical pixels.
:( That's probably a common enough case for other laptops, too.
On Thu, Feb 25, 2016 at 01:28:42PM -0500, Matthew Miller wrote:
On Thu, Feb 25, 2016 at 01:13:40PM -0500, David Shea wrote:
On 02/25/2016 11:46 AM, Garrett LeSage wrote:
Is this a *real* requirement in 2016?
Yes. ppc64le uses a VNC interface with a 800x600 display. Even
That might go towards different default for Server and Workstation, though, right? Or are people running PPC-LE as desktops?
There's no ppc64le desktop userbase that I know of, but the concern is worth discussion. We're talking about customizing the UX of each variant of Fedora, but how far do we take that? If we make them diverge too far, we can't necessarily reuse the interface components in different ways among the variants. Not saying that's the case here, just a generalization about why it is useful to keep the other use cases in mind.
ignoring that case, the X1 carbon has 2560x1440 pixel screen which, when scaled to adjust for the high dpi, has an effective resolution of 1280x720. This caused trouble on screens that expected 768 vertical pixels.
:( That's probably a common enough case for other laptops, too.
Likely. And I've been wondering if ARM laptops will take off anymore than they already are. If so, that could likely mean smaller everything...including screens.
On Thu, Feb 25, 2016 at 01:57:32PM -0500, David Cantrell wrote:
ignoring that case, the X1 carbon has 2560x1440 pixel screen which, when scaled to adjust for the high dpi, has an effective resolution of 1280x720. This caused trouble on screens that expected 768 vertical pixels.
:( That's probably a common enough case for other laptops, too.
Likely. And I've been wondering if ARM laptops will take off anymore than they already are. If so, that could likely mean smaller everything...including screens.
Hmmm, and maybe cheap 720p HD LCD panels. I doubt they're likely to go smaller than that — it's just so miserable in *any* OS these days. *
How much of a pain would it be to have two layouts, one for 1280×720 16:9 and the other for 1024×768 4:3?
* I could be wrong. *sigh*. But, honestly, I think it's okay to say "yeah, below this limit, we've got a lovely text mode".
On Thu, 2016-02-25 at 13:57 -0500, David Cantrell wrote:
On Thu, Feb 25, 2016 at 01:28:42PM -0500, Matthew Miller wrote:
On Thu, Feb 25, 2016 at 01:13:40PM -0500, David Shea wrote:
On 02/25/2016 11:46 AM, Garrett LeSage wrote:
Is this a *real* requirement in 2016?
Yes. ppc64le uses a VNC interface with a 800x600 display. Even
That might go towards different default for Server and Workstation, though, right? Or are people running PPC-LE as desktops?
There's no ppc64le desktop userbase that I know of, but the concern is worth discussion. We're talking about customizing the UX of each variant of Fedora, but how far do we take that?
Did we get any feedback from the Server working group about the need to customize/change the current GUI ? As far as I can tell they seem to be OK with the current design - of course they might not be using it that much, possibly preferring kickstart installs/TUI. But even in that case no new server custom GUI is needed.
So do we really need to think about about redesigning the server GUI ? We could just use what we have on Server and only do a simplified/streamlined GUI variant for the Workstation.
That should be overal easier.
If we make them diverge too far, we can't necessarily reuse the interface components in different ways among the variants. Not saying that's the case here, just a generalization about why it is useful to keep the other use cases in mind.
ignoring that case, the X1 carbon has 2560x1440 pixel screen which, when scaled to adjust for the high dpi, has an effective resolution of 1280x720. This caused trouble on screens that expected 768 vertical pixels.
:( That's probably a common enough case for other laptops, too.
Likely. And I've been wondering if ARM laptops will take off anymore than they already are. If so, that could likely mean smaller everything...including screens.
On Fri, Feb 26, 2016 at 01:56:59PM +0100, Martin Kolman wrote:
So do we really need to think about about redesigning the server GUI ? We could just use what we have on Server and only do a simplified/streamlined GUI variant for the Workstation.
There is some interest in hubs supporting Role configuration, I believe. But that doesn't require a redesign.
From feedback I've seen, the big concern is storage configuration. A
lot of Server users are interested, for better or worse, in the old-school approach of building up storage to a final configuration from bottom-up building blocks, rather than the end-goal-work-back UI Anaconda provides.
I'm sympathetic to the argument that it's pretty crazy to have parallel GUIs for both of these approaches. And beyond that, making a GUI for the build-up approach where all possibilities actually _work_ is a combinatorial nightmare. But, I wonder if we could make the possibility of pre-configuring storage a) more discoverable and b) easier in any way?
See http://unix.stackexchange.com/questions/263721/manual-setup-install-method-f... for just one example.
On Fri, 2016-02-26 at 11:26 -0500, Matthew Miller wrote:
On Fri, Feb 26, 2016 at 01:56:59PM +0100, Martin Kolman wrote:
So do we really need to think about about redesigning the server GUI ? We could just use what we have on Server and only do a simplified/streamlined GUI variant for the Workstation.
There is some interest in hubs supporting Role configuration, I believe. But that doesn't require a redesign.
From feedback I've seen, the big concern is storage configuration. A
lot of Server users are interested, for better or worse, in the old-school approach of building up storage to a final configuration from bottom-up building blocks, rather than the end-goal-work-back UI Anaconda provides.
I'm sympathetic to the argument that it's pretty crazy to have parallel GUIs for both of these approaches. And beyond that, making a GUI for the build-up approach where all possibilities actually _work_ is a combinatorial nightmare.
Well, Vojta is doing just that and it seems to be working fine: https://fedoramagazine.org/manage-your-partitions-like-in-anaconda-with -blivet-gui/ http://blog.vojtechtrefny.cz/blivet-gui http://blog.vojtechtrefny.cz/new-blivet-gui-fedora-22
I't (of course) Blivet based & written in Python and could quite easily be run a an Anaconda spoke - we already did some preliminary experiments with this.
So maybe Blivet-GUI-spoke could be the perfect default partitioning UI for the Fedora Server variant ? :)
But, I wonder if we could make the possibility of pre-configuring storage a) more discoverable and b) easier in any way?
See http://unix.stackexchange.com/questions/263721/manual-setup-install-m ethod-for-fedora for just one example.
On Thu, Feb 25, 2016 at 05:46:11PM +0100, Garrett LeSage wrote:
Hi all!
Thanks for all your feedback so far! It's been great. Instead of replying to each email individually, I've compiled a summarized list of points from the different emails and have replied to each below.
Apologies in advance for a super-long email. Feel free to skip to the parts you'd like to see responses for or to the quick summary (at the very end). I've made the questions in Markdown-like / ATX-style headings (look for the two hash signs "##").
## Storage screen == linear? and Wizard vs. Hub-and-spokes
Right now, Anaconda *already* is a hybrid between hub-and-spokes and a wizard. There's a welcome and language screen before you see the spoke settings, and there's an installation progress screen after. If it were purely hub-and-spokes, then you'd only have the hub screen and everything else would be a spoke.
The idea in the design mockups pushes the critical question of "where should this go?" when it needs to be asked. Right now, we're hoping that someone knows that they need to go into the partitioner, then understand what they're doing, and finally jump back out to continue onward. I've found that's often not the case, in a little bit of semi-informal research I've conducted (in my free time) in the past year.
One kind of funny example I encountered: A quite-technical co-worker who routinely installs Fedora for work told me that he originally thought his hard drive was "bad". He eventually even bought a new hard drive — and after thinking that one was marked as being bad too. Of course, after a little bit of questioning, it turned out that it's just how Anaconda flags a necessary step — even when it should not be necessary (as in the case of a blank drive). Consider that he's a technical person, who has been using Linux for well over a decade now and that other people with less knowledge and experience are running into the same thing.
Anaconda currently forces everyone into the partitioner. It would be nice to make that an optional place to visit to ensure that people are much more likely to install and use Fedora under normal circumstances. (How many people tried to install Fedora and gave up when they saw that their "disk had an error" or when they were confused while trying to figure out even what partitions are?)
Breaking out that mostly-mandatory (it should be skippable when there's a blank drive) partitioning step into a separate, simplified screen solves this — and a few other — problems. It formalizes this critical step instead of pretending that it's just-another spoke setting. In the designs I've linked, it's still there as a spoke (although not pictured yet; only mentioned). In the mockups, there's an attempt for partitioning to be pre-configured based on the system's state (if there's enough space). The super-simple partitioner in the mockups (note: advanced partitioner not yet displayed in the mockups) only appears when it's absolutely needed (which, of course, would be pretty common for Workstation installs).
## What happens with two drives?
Good question. There's space in the super-simple paritioner mockup. I should mock up the case(s) where there are two drives.
What about even more drives? I know this is the Workstation variant, and not everything will apply to Server -- so maybe I'm veering off topic here -- but I feel I should mention that on s390x (IBM mainframe) for example, it's the norm rather than the exception to install to tens of disks.
Even on the Installation Summary screen at the top, in the "Install to" it looks fine with one disk, and it'll look fine with two as well, but it might not scale as neatly when the number of disks goes up by an order of magnitude (or two).
Samantha
A few quick notes:
- Both drives must be internal. This is for a tower/desktop machine with
actual "permanent" drives, not for USB drives. 2. What if one of the drives is completely empty? Open question that needs more consideration. 3. Most people would probably have an OS drive and a data drive. 4. In some cases, people might have LVM and/or RAID and/or BTRFS on a pre-existing system. (It's really unwise to extend a partition across disks, unless there's redundancy, however — Anaconda probably shouldn't *actively* promote this bad practice.)
Thankfully there's quite a bit of space that could be used to handle multiple drives in the super-simple partitioner. For advanced stuff (like in #4), it's probably fine to expect people to have to dive into more advanced partitioning.
Summary: Excellent point. Design not available yet; TBD.
## Screen real estate vs. dialogs
It's not a problem for most of the dialogs... so the question is, can this work for the partitioner too? I think the answer is yes (probably with a quite-large dialog — either with minimal spacing on the edges, or one that goes flush to the edges), but I'll work more on it. I have some super-rough starts of an advanced partitioner UI in a subdirectory that explore this and other ideas, but I shelved it for now, as... well, probably everyone here knows ☺... a flexible partitioner UI is, by necessity, kind of messy and involved and takes quite some time and effort to get right. If I'm going to work on some updates to Anaconda's full paritioner, I need to work with you all to make sure it's done well.
## 800x600?
Is this a *real* requirement in 2016? Most people installing on a server with an inadequate graphics chip are using a kickstart file anyway, right? And is at least 1024×768 or 1280x1024 really too much to ask for? 1024×768 is in both 8514 and SVGA from 1987 and in the VESA spec from 1994.
## Animations in F22+: Do they help?
Firstly, the animations do not work in VMs, so it needs to be visibly apparent in a different way. Animations cannot be relied upon within Anaconda, but they can definitely help when used tastefully. It's a good idea to think about how best to display them without going too over the top. (Some people use so many animations in slide decks during presentations that it makes the audience mostion sick. Used sparingly and effectively, however, animations definitely can help illustrate.)
Sorry for the almost non-answer. ☺
Simple answer: Yes. ☺
## Button styling
Yes, it's unfortunate that the blue button is on a blue background.
As for GNOME's control center (mentioned in context of the button styling): In addition to location (being at the top-left), it also uses change (the button appears in the top left) and animation (the button and content area both cross-fade into view quickly) to highlight the back button. Also, the absence of other elements directly nearby help to highlight it (that is: intentionally uncluttered). In the next version of GNOME and GTK+, buttons are slightly darker, which makes things like buttons in the headerbars even more prominent.
But, back to Anaconda: Yes, it should be style, positioned, and labeled, and possibly even animated (in a subtle way) to be obvious.
## Screen with ad banners: Crowded with ads
I agree; that's why it's my opinion that there shouldn't be ads. I added the ad idea with 3-up as a solution to a few problems (mentioned in the mockup as well as in an issue on the repo's issue list).
It's ironic that there are ads in a free software distro that highlights freedom. There's also the problem that all the current ads require people to remember everything until the system has rebooted and is back at the desktop — and the content is out-of-date and does not highlight the best of Fedora anyway. That's why I strongly believe the correct place for ransom-notes (installer ads) is not the installer, but start.fedoraproject.org, which is what shows up in everyone's browser after a fresh install.
Also, the continued prevalence of ads in the installer is sort of my fault in a way, and I apologize. Back when I worked for Red Hat in 2002 - 2004, I made tons of popular ransom notes / installer ads including things like the fortune cookies and even gave a certain famous dancing hotdog a spotlight during installation time. The ads have stuck around since, even though installer time has gotten much, much quicker... and the quality of the installer ads has gone down. Oops. 😉
I do think there is a use in self-promotion, but it's probably not in the installer (but should be in the start page).
## Why a confirmation dialog?
It doesn't show up when the drive is blank. It is only displayed when there's possible data loss.
## We can't predict how long an installation will take
Sure we can! It's possible to time it on different hardware setups and see the current progress and make a best effort estimation. Display a tuned time estimate only after you get a bit of IO on the disk. I've personally built time estimations before, for exactly this same scenario (installation, including custom selected packages, when working on SUSE Studio a few years back), so I know it's possible.
It doesn't matter if the estimation isn't *completely* accurate. Seconds don't really matter, in other words. People want to know if they should get a coffee from a machine in the kitchen, brew a specialty cuppa themselves, or can sneak out for a lunch break with their coffee. (2 minutes is different from 7, which is different from 32, etc.)
The progress bar should be smoothly animated in a smart way. I know that there isn't a way to know exactly what is going on in many stages when it is happening, but the transition *can* be smoothly animated based on heuristics based on timing data (includes controlled trial-runs as well as system-specific information). This isn't hand-wavy; Again: I've actually worked on this exact problem in the past, so I know it's 100% achievable.
## Servers with existing OS
Good point. Severs will often have no OS, but for reasons you state, they will often also have an OS — usually with a pre-existing installation that should be overwritten. While the mockups right now primarily focus on Workstation, the notes inside (which do mention Server in a few places) should definitely be updated, and this should be a priority acknowledgment when it's time to concentrate a bit more on the Server-specific flavor of Anaconda.
## SUMMARY
Super-quick summary of all the above:
- Still mostly hub-and-spokes overall, but Anaconda is *already* hybrid
right now. 2. Two drives needs to be considered more; design TBD (to be done). 3. Screen real estate will be considered; dialogs would work for everything, with a possible slight special casing for partitioning (but we will see). 4. 800×600 seems awfully small; 1024×768 was already commonplace starting _in 1987_. See open question below. 5. Animations can definitely be useful, but should be used carefully. 6. Making critical buttons obvious enough is important. Styling plays a part, along with many other factors. 7. Ads: I don't like 'em myself and believe start.fedoraproject.org is the proper place for content like this. 8. Confirmation dialog: Design (and implementations) should strive to minimize data loss overall. When the task is to remove data (without the possibility to undo), it's important to help ensure people know for a fact what's about to happen. 9. There are definitely ways to predict how long an installation will take (speaking from experience from working on OS installation estimations with a progress bar). It doesn't need to (and arguably should not) be accurate. 10. Servers with existing OS: You're right… and the notes need to be updated.
## Open questions
- What's the minimum (and modern) *realistic* resolution that needs to be
supported in Workstation installs? and in Server installs? (It might be different.)
Hopefully this all helps! Also, I'm often hanging out in #anaconda on both internal and Freenode IRC (Monday - Thursday, in European time) in case you'd like to chat in closer-to-real-time too. ☺
Garrett
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Hi all,
A few people on the list were wondering what might happen if there were more than one internal disk on a system when installing the Workstation edition.
I went back to the mockups to adjust the simple partition resizer to accommodate 2+ disks and made this: http://people.redhat.com/glesage/project/anaconda/anaconda-simple_partition-...
As a couple of things changed, I modified the original one-disk screen slightly too: http://people.redhat.com/glesage/project/anaconda/anaconda-simple_partition-...
Cheers, Garrett
On Thu, 2016-02-25 at 17:46 +0100, Garrett LeSage wrote:
One kind of funny example I encountered: A quite-technical co-worker who routinely installs Fedora for work told me that he originally thought his hard drive was "bad". He eventually even bought a new hard drive — and after thinking that one was marked as being bad too. Of course, after a little bit of questioning, it turned out that it's just how Anaconda flags a necessary step — even when it should not be necessary (as in the case of a blank drive).
IIRC, in the initial iterations of the current anaconda (i.e. in F18), INSTALLATION DESTINATION was not mandatory and would auto-configure itself when possible. We explicitly chose to move away from that and require the user to at least visit it and confirm the defaults. I don't entirely recall why, but presumably we had a reason.
anaconda-devel@lists.stg.fedoraproject.org