Re: anaconda design mockups

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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, 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.


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 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. ☺


Anaconda-devel-list mailing list

[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux