#211 Installer session design
Closed: Fixed 3 years ago by aday. Opened 3 years ago by aday.

For a while now, I've been planning on having a conversation with the Anaconda team about integration with the desktop session. Three main topics there:

  1. Have Anaconda offer language selection as the first thing the user sees, in order to provide a UI that is translated in a language the user understands [1]
  2. Using a locked down session similar to the one that gnome-initial-setup runs in, in order to:
    • Reduce the chances of users doing Something Bad™ mid-install
    • Enable Anaconda not to run full-screen, which will fix a bunch of UI issues
  3. Have Anaconda reboot the system after installation itself (after a user confirms), rather than quitting the installer and leaving the user to figure out what to do next

Regarding point 1, the way I was imagining it working was:

  • Live media boots
    • Installer session starts (session is limited - no overview, no app launching or switching, etc)
      • Installer autolaunches
        • First installer page - language selection. Switching the language here only affects the installer.
        • Second installer page - do you want to install or try?
          • If install is selected - the installer runs in the usual way
          • If try is selected - the install quits and a new full live session is started, using the language selected previously

The motivation for offering language selection through Anaconda is:

  • Anaconda already has language selection, so we don't have to orchestrate which component offers it
  • While only Anaconda would be affected by the language selection choice (the rest of the system would be unaffected), the session will be restricted, so the occasions when someone sees untranslated text will be relatively low
  • If we used a separate component to do language selection and pose the try/install question, it would have to run in its own session, which implies an additional transition for the user. To me that felt somewhat disruptive for such a small step in the process, and an additional burden in the installer experience (bringing the number of sessions up to 4 - welcome → installer → initial setup → user session).

Clearly this approach isn't perfect: someone could get a notification during installation, in a language they don't understand. It would be good to hear other ideas.

@ngompa and @catanzaro


This is almost exactly what I had been hoping for. I'd request that we do early keyboard layout selection as well. Language first -> keyboard layout second -> do you want to install or try live third. Language and keyboard layout are the two steps without which the live system is not usable. (Currently if you use, say, Azerty, the only way to change that in the live session is to navigate Settings -> Region & Language and then find Input Sources. But this is too difficult for new users.)

I don't think this necessarily has to be done by anaconda specifically: it could be handled by gnome-initial-setup or even by a third new component, as long as it runs in its own separate session before the user is able to start any other apps. anaconda sounds perfectly fine to me, though.

I'd request that we do early keyboard layout selection as well. Language first -> keyboard layout second -> do you want to install or try live third.

I'm uncertain about including keyboard layout in the initial live session configuration. Reasons:

  1. It goes against the goal of getting the system display language set as quickly as possible, if that is indeed what we want to do
  2. I suspect that the default layout is generally sufficient for system install, so leaving it as an optional step in Anaconda could be appropriate.

I don't think this necessarily has to be done by anaconda specifically: it could be handled by gnome-initial-setup or even by a third new component, as long as it runs in its own separate session before the user is able to start any other apps.

One of my concerns about using a separate session was how disruptive it would be - you'd click through language, maybe keyboard, then "install", and then you'd have a transition to a new session. However, I just checked on the existing transition between initial setup and the user session, and it seems reasonably quick/smooth, so maybe it's not so bad.

The other question I think we need to answer here is the extent to which we expect users to see and interact with the system during installation:

  • Is making the installer accessible important, for example? If it is, then we might want to show the accessibility menu.
  • Is it important to show system status, and can that just be icons or does it need the system status menu too?
  • Is it important to be able to show notifications?

If we say yes to any of these, then that would indeed point towards setting the language for the installer desktop session, rather than just in Anaconda.

Note that this approach would need some adjustment on Anaconda's part. In addition to hiding the language selection page, we would also need to avoid users being dumped at the "installation summary" page when the installer session starts. It could just be enough for Anaconda to show an extra heading and explanatory text, but it would need something adding as well as removing.

I'd request that we do early keyboard layout selection as well. Language first -> keyboard layout second -> do you want to install or try live third.

I'm uncertain about including keyboard layout in the initial live session configuration. Reasons:

  1. It goes against the goal of getting the system display language set as quickly as possible, if that is indeed what we want to do

I don't think so. Applications can update their own locale immediately, so the keyboard layout selection page will be displayed in the selected locale.

  1. I suspect that the default layout is generally sufficient for system install, so leaving it as an optional step in Anaconda could be appropriate.

I disagree, because unless you use a qwerty keyboard, the system is totally unusable until you figure out how to change keyboard layout. Locale and keyboard layout should be kept together. Imagine a Japanese user boots Fedora and is pleased to find it is localized in Japanese, then discovers there is no way to type anything except English. Or imagine you are in France have azerty instead of qwerty, you're going to be pretty disappointed if you type A and wind up with Q. Etc.

One of my concerns about using a separate session was how disruptive it would be - you'd click through language, maybe keyboard, then "install", and then you'd have a transition to a new session. However, I just checked on the existing transition between initial setup and the user session, and it seems reasonably quick/smooth, so maybe it's not so bad.

I'm pretty confused. Your own proposal calls for a separate installer session before starting the live session. It's the same thing regardless of what application we run in it: we need the isolated initial session in order to ensure nothing else gets launched until locale has been selected, since locale cannot be changed after a session is launched. That's why I don't have any strong preference between doing this in anaconda vs. gnome-initial-setup: whatever you think looks better will accomplish the technical goal.

But I guess anaconda might be best if the user does NOT choose to enter the live session, since then you can do the entire install in anaconda.

The other question I think we need to answer here is the extent to which we expect users to see and interact with the system during installation:

  • Is making the installer accessible important, for example? If it is, then we might want to show the accessibility menu.

I would say yes, since otherwise users who need accessibility features cannot install it.

That said, currently anaconda is not accessible at all. But the design should assume that will be fixed eventually.

  • Is it important to show system status, and can that just be icons or does it need the system status menu too?

In the installer session: I think these would just be unnecessary distractions. If the installer is going to run in a separate isolated session instead of the live session, then none of this is needed.

  • Is it important to be able to show notifications?

In the installer session: no, because if anaconda wants to display a notification, it can do that itself. It doesn't need notification support from the desktop.

If we say yes to any of these, then that would indeed point towards setting the language for the installer desktop session, rather than just in Anaconda.

I wouldn't make any changes to the existing live session other than to offer language and keyboard layout selection before launching it. It seems to work perfectly well, it's a good trial experience to give uncertain users more confidence in Fedora, and there's no technical reason to limit its capabilities. Removing the system status menu or system notifications doesn't remove the need to set language anyway.

I'm uncertain about including keyboard layout in the initial live session configuration.

To be clear, I'm not dead against including keyboard layout selection in the initial greeter

Reasons:

  1. It goes against the goal of getting the system display language set as quickly as possible, if that is indeed what we want to do

I don't think so. Applications can update their own locale immediately, so the keyboard layout selection page will be displayed in the selected locale.

Sure. I was thinking about system-provided features (a11y, system status, notifications, etc) that won't be available in the user's language until after a session switch.

  1. I suspect that the default layout is generally sufficient for system install, so leaving it as an optional step in Anaconda could be appropriate.

I disagree, because unless you use a qwerty keyboard, the system is totally unusable

Do you mean that the live system is totally unusable? (I'm not sure I understand your point here.) For the live session yes, in many cases someone will need to configure the keyboard from Settings. That's obviously more of an inconvenience rather than it being rendered unusable.

Regarding the installer, the point I was making is that a) Anaconda does have keyboard layout config and b) you often don't need to type as part of installation. The main issue I see with this is actually that you can end up not configuring your keyboard and then run into problems further down the line, in initial setup (as a result of keyboard layout selection bing an optional step in Anaconda).

All this is to say that I'm not opposed to presenting keyboard layout selection as part of an initial welcome session, or whatever we want to call it, but it's somewhat sub-optimal, given that a) both the live session and Anaconda already have keyboard configuration in some form already and b) it likely won't make sense to have things like a11y features available during keyboard layout selection.

One of my concerns about using a separate session was how disruptive it would be - you'd click through language, maybe keyboard, then "install", and then you'd have a transition to a new session. However, I just checked on the existing transition between initial setup and the user session, and it seems reasonably quick/smooth, so maybe it's not so bad.

I'm pretty confused. Your own proposal calls for a separate installer session before starting the live session.

My idea was to avoid the session transition where possible (if you're doing a straight install). In some cases it can't be avoided (ie. the live session). That said, as mentioned I'm not so concerned about the session transition at this point.

...

But I guess anaconda might be best if the user does NOT choose to enter the live session, since then you can do the entire install in anaconda.

Right, that was the original idea. For the installer you can potentially avoid setting the system language. The same isn't true for the live session, so you inevitably need to switch sessions in that case.

The other question I think we need to answer here is the extent to which we expect users to see and interact with the system during installation:

  • Is making the installer accessible important, for example? If it is, then we might want to show the accessibility menu.

I would say yes, since otherwise users who need accessibility features cannot install it.

That said, currently anaconda is not accessible at all. But the design should assume that will be fixed eventually.

Presumably system-provided a11y features can be used with Anaconda, like zoom and the screen keyboard.

  • Is it important to show system status, and can that just be icons or does it need the system status menu too?

In the installer session: I think these would just be unnecessary distractions. If the installer is going to run in a separate isolated session instead of the live session, then none of this is needed.

The main thing I can think of there is the battery level. Theoretically this shouldn't be needed because Anaconda should prevent users from installing on low power, but I'm not sure what the reality is.

  • Is it important to be able to show notifications?

In the installer session: no, because if anaconda wants to display a notification, it can do that itself. It doesn't need notification support from the desktop.

I was thinking more of system notifications we might want to show - your disk is bad, your battery is out of juice, something just crashed, etc

If we say yes to any of these, then that would indeed point towards setting the language for the installer desktop session, rather than just in Anaconda.

I wouldn't make any changes to the existing live session other than to offer language and keyboard layout selection before launching it. It seems to work perfectly well, it's a good trial experience to give uncertain users more confidence in Fedora, and there's no technical reason to limit its capabilities. Removing the system status menu or system notifications doesn't remove the need to set language anyway.

There might have been some miscommunication here. I wasn't suggesting changes to the live "try before you buy" session. The point was rather, if we want these system features to be available during installation, then that indicates that we need to set the system display language for the session that the installer runs in.

  • Is making the installer accessible important, for example? If it is, then we might want to show the accessibility menu.

I would say yes, since otherwise users who need accessibility features cannot install it.

That said, currently anaconda is not accessible at all. But the design should assume that will be fixed eventually.

Presumably system-provided a11y features can be used with Anaconda, like zoom and the screen keyboard.

It definitely is important for users - see https://github.com/fedora-silverblue/issue-tracker/issues/5 (Silverblue bug, but doesn't matter).

I disagree, because unless you use a qwerty keyboard, the system is totally unusable

Do you mean that the live system is totally unusable? (I'm not sure I understand your point here.) For the live session yes, in many cases someone will need to configure the keyboard from Settings. That's obviously more of an inconvenience rather than it being rendered unusable.

I wrote: "unless you use a qwerty keyboard, the system is totally unusable until you figure out how to change keyboard layout." Which is true. Showing one quick extra screen to ensure our users can type is a lot nicer than expecting them to hunt around in System Settings for the keyboard layout settings. I'm pretty confident that most users will give up on Fedora before they find the Region & Language panel.

All this is to say that I'm not opposed to presenting keyboard layout selection as part of an initial welcome session, or whatever we want to call it, but it's somewhat sub-optimal, given that a) both the live session and Anaconda already have keyboard configuration in some form already and b) it likely won't make sense to have things like a11y features available during keyboard layout selection.

If we do locale and keyboard layout selection before starting the live session, we would then hide those spokes from anaconda when it is started to do the real install. We should not show them twice.

b) it likely won't make sense to have things like a11y features available during keyboard layout selection.

Why? If a11y features are not available during keyboard layout selection, then users who require a11y features will not be able to select their keyboard layout and will not be able to install Fedora. a11y should always be available, right?

But I guess anaconda might be best if the user does NOT choose to enter the live session, since then you can do the entire install in anaconda.

Right, that was the original idea. For the installer you can potentially avoid setting the system language. The same isn't true for the live session, so you inevitably need to switch sessions in that case.

Allan, I am very confused. You can never avoid setting the system language. If you don't have language selection as the very first step, users who don't know English will not be able to proceed with any further steps. Right?

The main thing I can think of there is the battery level. Theoretically this shouldn't be needed because Anaconda should prevent users from installing on low power, but I'm not sure what the reality is.

Hm, good point. I think that could be better handled directly in anaconda than by exposing the system status menu, but the technical details would need to be worked out. E.g. we would might need to have upowerd running for anaconda to be able to do anything with it.

I was thinking more of system notifications we might want to show - your disk is bad, your battery is out of juice, something just crashed, etc

I would make anaconda responsible for everything that needs to be handled in the installer session. Remember that non-anaconda processes will use the wrong locale unless we stop anaconda, start a new Unix session, and then launch anaconda again after a new locale is selected, so our ability to handle anything outside anaconda is very limited.

There might have been some miscommunication here. I wasn't suggesting changes to the live "try before you buy" session. The point was rather, if we want these system features to be available during installation, then that indicates that we need to set the system display language for the session that the installer runs in.

Well, yes, that's right. I don't think these features need to be available during the installer session, but if they are, then locale selection indeed has to happen first in a separate session.

Michael and I discussed this yesterday. We agreed that we're both happy to consider the two main options being discussed (anaconda running first, or having a separate gnome-initial-setup session to run through initial questions).

However, if we don't run Anaconda first then that leaves an outstanding question around express install in Boxes.

Either approach will require adjustments on the Anaconda side, so the final decision needs to be taken in conversation with them. I agreed to do mockups of both approaches.

Metadata Update from @aday:
- Issue tagged with: pending-action

3 years ago

Action: Allan to prepare mockups.

Metadata Update from @aday:
- Issue assigned to aday

3 years ago

Metadata Update from @aday:
- Issue untagged with: pending-action

3 years ago

The input method selection is only explicitly shown in the second path "try before installing," but since it's presented before the user chooses between try/install it has to be displayed either way. Anyway, looks nice.

Either approach looks good to me.

I'm slightly confused. In the "double session" option, does that mean the installer can be invoked from the desktop still? If so, it's unclear that is the case.

Also, are we bundling a new Anaconda frontend to go with this? This UI looks different than what we have today...

The input method selection is only explicitly shown in the second path "try before installing," but since it's presented before the user chooses between try/install it has to be displayed either way. Anyway, looks nice.

That could potentially be split out of the hub. The reason I didn't do that in the mockups is that I'm trying to require as few changes on the Anaconda side as possible.

I'm slightly confused. In the "double session" option, does that mean the installer can be invoked from the desktop still? If so, it's unclear that is the case.

I haven't figured out a good way to present that in the UI and thought we could probably do without it to begin with. I think it should be possible though.

Also, are we bundling a new Anaconda frontend to go with this? This UI looks different than what we have today...

Apologies, I suspected the different UI might muddy the waters. The only UI change I'd really be looking for would be for the window to run non-maximized rather than fullscreen like now. I've updated the mockups to be closer to the existing UI.

fedora-install-session-double-2.png

fedora-install-session-triple-2.png

The input method selection is only explicitly shown in the second path "try before installing," but since it's presented before the user chooses between try/install it has to be displayed either way. Anyway, looks nice.

That could potentially be split out of the hub. The reason I didn't do that in the mockups is that I'm trying to require as few changes on the Anaconda side as possible.

I'm slightly confused. In the "double session" option, does that mean the installer can be invoked from the desktop still? If so, it's unclear that is the case.

I haven't figured out a good way to present that in the UI and thought we could probably do without it to begin with. I think it should be possible though.

I think the simple dash icon to launch Anaconda is enough for now. I think the "double session" style is sufficient. It also mimics what I've seen from Mageia and Ubuntu on this, so I know it should work for all the various spins/editions too.

Also, are we bundling a new Anaconda frontend to go with this? This UI looks different than what we have today...

Apologies, I suspected the different UI might muddy the waters. The only UI change I'd really be looking for would be for the window to run non-maximized rather than fullscreen like now. I've updated the mockups to be closer to the existing UI.

Okay, that makes sense. Thanks for clarifying it!

The input method selection is only explicitly shown in the second path "try before installing," but since it's presented before the user chooses between try/install it has to be displayed either way. Anyway, looks nice.

That could potentially be split out of the hub. The reason I didn't do that in the mockups is that I'm trying to require as few changes on the Anaconda side as possible.

Something is wrong, you have two paths:

Installer path: language selection -> try/install selection, user selects install -> select keyboard layout later

Live session: language selection -> keyboard layout selection -> try/install selection, user selects try -> live desktop

It can't be both ways... everything leading up to the try/install choice has to be the same both ways, because the user has not selected try/install yet. If you want keyboard layout selection to go after the choice of try/install, then it needs to move in the second path as well.

(FWIW, hiding anaconda spokes is slightly easier if we show the same spokes on both paths. We probably don't want to show keyboard layout in anaconda if you already set keyboard layout before entering the live session, since we don't want to prompt the user to configure the same thing twice, so IMO it's slightly nicer to have keyboard layout handled by GNOME rather than by anaconda.)

The input method selection is only explicitly shown in the second path "try before installing," but since it's presented before the user chooses between try/install it has to be displayed either way. Anyway, looks nice.

That could potentially be split out of the hub. The reason I didn't do that in the mockups is that I'm trying to require as few changes on the Anaconda side as possible.

Something is wrong, you have two paths:

Ah yes, my mistake.

We seem happy enough with the designs for now. Let's conclude this step of the process and move the rest of the discussion to #221.

Metadata Update from @aday:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

3 years ago

Commenting long after the fact:

I don't think so. Applications can update their own locale immediately, so the keyboard layout selection page will be displayed in the selected locale.

They generally can't

Log in to comment on this ticket.

Metadata