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: > 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 > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/anaconda-devel-list _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
