Re: anaconda design mockups

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

_______________________________________________
Anaconda-devel-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/anaconda-devel-list