On Mar 22, 2014, at 12:10 AM, Ranjan Maitra maitra.mbox.ignored@inbox.com wrote:
The problem is that we don't reinstall (or install F) every few weeks or months so it is very easy to forget what/how this was done every six months.
I think it'd be really helpful for users who care about the install experience, but don't use the installer often, contribute their experience. These users definitely have an insight that users more familiar with the installer don't have.
And I also think any application that irritates/frustrates is a bad UX and a legitimate gripe. So just because ultimately you can contort yourself to get the installer to do what you want, if that contortion annoyed you, there's a legitimate bug (or flawed design) somewhere. Good software shouldn't actively piss users off.
But a useful bug report still articulates why annoyance happened: usually a betrayal happened. User expects X, but software produced Y. So I'd write the bug in those terms. It's a UX bug.
A new behavior in Rawhide that's taken a lot of work is much better consistency in handling units. However as a side effect of using MiB and GiB, if you specify mb you get a conversion. If I create /boot with size 500 or 500m, it's created as 500 MiB. However if I specify size 500mb, it's created as size 476 MiB. Oh dear. That's technical correct, it's exactly what I asked for. But I think in storage the distinction of 2% between M and Mi, G and Gi is not helpful. The ship sailed a long time ago that base 1000 is used for storage, and base 1024 for memory. And then the next mind bender is when I do an autolayout and swap is 819.19 MiB on the left UI, but if I click that mount point, the detail right side UI Desired Capacity reports 819.1999998092651367/ and is then cut off, but if I scroll within that field to the right the full value is 819.19999980926513671875 MiB. In other words, it is actually possible to specify fractions of bytes in the storage UI. *sigh*
I'd like to see MB rounded to integers and GB rounded to one decimal place except in the lower left Available Space and Total Space fields, which should also be integers.
Yes, we can take notes, but recall that this is a time when making notes on the machine itself is not that easy because we are at the installation phase. Also, many things have to be discovered and in particular getting to the manual paritioning setup to me was completely hard to follow: you hit Done or something like that and then you get to the installer.
Oh right. The first Done button is what Liam was probably referring to, not the second Done button. Two Done buttons in the same spoke = UI failure. Ostensibly the UI's this is modeled after never ever do this. When their "upper left master button" element, the user is always always always returned to the hub. Here, Anaconda turns into a Which Way Book ((a.k.a. choose your own adventure book).
First, the spoke is titled Installation Destination. The first window upon entering that spoke is titled Installation Destination. The Done button very clearly indicates clicking it will return the user to the hub. But it never does. Huge betrayal of the UI. Instead you get a floating dialog, from which you choose from myriad options and either get another floating dialog or a whole separate page, wizard style, which also contains a Done button. Where the F am I? OK am I really Done now this time? Or are you just going to tease me again? OH I see this time we really are in fact Done.
(Just like the betrayals in Which Way Books. Except worse because there's no back button, like sticking your finger on the most recent choice page so that if you die you can go back and make a new choice, YES CHEATING. If I wish for a cheat finger in a UI, it has failed.)
In Rawhide this is a whole lot better in that you clearly, up front, choose two paths: automatically vs i will configure (which still confusing ends up being called Manual Partitioning it's technically no longer customize!). You still have the Done button that doesn't take you to the hub, therefore by definition it's actually a Next button wrongly named. (No, there's no pass for suggesting this Done button means "done with this page" because that's not how this type of UI is ever used anywhere else, even in Anaconda. It's supposed to be done with this spoke return to hub, but see I'm in a wizard UI now and wasn't properly informed.)
Anyway, it's better in Rawhide. It still has problems. There isn't a great way out of this problem. OK I've thought about it enough I filed a bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1079655
Months later, I have figured out that there are buttons to set the time according to a desired network provided. It is all hidden, and I accidentally found it by looking and wondering why this option should not have been included in the install options.
I don't know what this refers to. Buttons to set time per desired network?
I guess some of us are trying to say that the installer has become quite opaque. Some of us can scrape away the opacity easily sometimes, some can do it rarely, while some can do it all the time. The question that I wonder about is: was this at all necessary.
I don't know what you mean by this. The installer rewrite? The installer UI big picture design? Specific UI elements? Obviously the installer team felt like a rewrite was needed to be more flexible in handling upcoming storage technologies like bcache, btrfs, and LVM thinp. As it turns out it's also more flexible being customized for Fedora products too, which wouldn't have been easy or maybe impossible with the previous installer.
Personally, I like letting stable functional things stay, and think that it would have been better to rebuild on the old installer.
This is a very old argument that has been soundly rejected. If you don't actively work on the installer you get no say because that's how OSS works, simply put. And the people who actively work on it said this massive work was needed because "rebuilding on the old installer" was not possible. Why? Go read the archives, they discussed in exhausting detail why it needed a rewrite, what it couldn't do that they felt it should be able to do. And why it wasn't just a matter of fixing some parts of it. At the core it wasn't easily customizable and had no concept of basic things that enable teaching it about new storage technologies like Btrfs, LVM thinp, and bcache. You're asking for an old car to be turned into a hybrid after market. Well that's more work and more money with worse results than just buying a new car that is already a hybrid.
However, the new installer is far too removed in process from the old one, and the least that could be done could be to include a manual and an FAQ (question bank) with the installer.
Have you read any of the Fedora 18, 19 or 20 documentation on the new installer? If it was inadequate or confused you did you file bugs against Fedora documentation?
This could be searchable (and included with the installer, because, again note that the machines functionality is not that high at the time of the install). Of course, this takes effort and time which volunteer developers may not have or wish to put into.
There is a Help button, it's the fifth button, in Manual Partitioning that contains some minimal documentation, that actually is pretty useful in understanding the paradigm shift involved. If you accept that information, then the manual partitioner makes a lot more sense. If that text is confusing or inadequate, file a bug against anaconda with suggested improvements, or even questions that you don't have answers to that you think this help section should answer.
It really can't be exhaustive, there isn't enough space for it, although in a Live Desktop install you can have the installer and Firefox running at the same time.
Btw, the new installer is uglier in terms of looks than the old, too, but that is a matter of personal like!
It's an unqualified statement that doesn't at all convey a path to fixing a problem.
My rambling is all to say that while I eventually got my stuff the way I wanted, I am not sure if it should have taken all that while. I had installs happening in 3-4 minutes with the old installer (now the time taken is exponentially higher). So, while I appreciate all the hard work done by the developers, I can not but wonder if their hard work has been in vain (to an extent) in the sense that many of us old and loyal F users are unable to fully appreciate all their contributions in this regard.
This is a nascent UX bug description. It just needs to be made much more specific about what your expectations are, at a particular step, and how the installer betrayed your expectation, or confused you. If you can't articulate this with some better detail in a bug report it really has much less likelihood of getting better.
One area I know that's still considered weak is the installer's handling of existing installations. It doesn't make it easy to e.g. wipe a prior Fedora or Linux installation while keeping its /home for use with the new install. The expectation was that most users would do this with fedup upgrades rather than cleanly installing a new OS and keeping home.
Chris Murphy