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