Revamping the installer's UX: an idea

So I have an idea on how to improve the installer's UX significantly. Instead of asking questions throughout the installation, why don't we ask for it all at the start and store it in memory, reading the values when necessary?

This would get rid of all your previous issues you had when considering revamping the UI:

  1. Cannot write the installer in non-zsh, and GUIs suck in shell scripting
    In this case, the configuration window could be done in a non-scripting language without disrupting most of the installer
  2. You can't, e.g., run the user configurator before it's installed
    Simply store the user's requested values in memory while installing, and pass them to the user configurator

I'd love to start work on this, but before I do, any thoughts @Thanatermesis ?

Before you respond.

Yes, I KNOW that some of the popups are superfluous.
I KNOW that you can get rid of some of the larger offenders.
But this is a MAJOR UX issue and reducing popups is a band-aid solution. My idea is to ask for everything at the start and only use popups as a last resort, for things that can't be predicted before the installation. For example, IO errors.

You can still use Zenity progress bars. Whatever floats your boat. I just think it's an AWFUL idea to prevent the user from leaving in the middle of the install, or risking them being in the middle of typing something and accidentally closing an important popup in the installer.

1 Like

I hope you realize what you're signing up for there. That really is a heap of work and lots of hidden dragons. :thinking:

I know, but I can always try :stuck_out_tongue:

I'm also really bored lately so it'd be nice to have something to do.

Unfortunately this is not possible, I think I already explained why this before but let me do it again:

  1. Bash is the best language for it, because: an installation is mostly administrative tasks (install things, remove, configure, modify configurations, change files, and mostly running commands), moving it to another language will be a potential growth in unneeded code, increased complexity and unreadability, for example:
dpkg-reconfigure lightdm


import subprocess["dpkg-reconfigure", "lightdm"], stdout=subprocess.PIPE) 
  1. This will also require to move all the code complexity like managing standard output, input, errors, traps, variables, migrating all elive-functions codes, flags, and I cannot imagine how much more things...

  2. We are talking about 15400 lines of code, trying to do so will lead to not only a waste of time but a guaranteed unsuccess, where even if was reached, it will lead to many new bugs difficult to solve.

  3. I will never engage myself in such investing of time of every aspect that will require (explaining what / why's of the code, trying to make things working, losing time in discovered bugs, etc)

  4. I will be totally unable to maintain the installer anymore, and this is very important because it requires lots of changes, fixes and improvements, for almost every change in the distro

  5. Elive will eventually die, due to the effort required of the previous point, frustration and time lost on it, reducing entirely the time invested for other more important development

Considering the installer is only run once for a short period of time (which means: is not a commonly-used application which needs to be nice and friendly) rewriting it is not a good idea, and I don't see the reason to do it

Now, you have a point about the UX, and what is possible to do, which is always better than do rewrites of software, is to improve the actual UX, this can be done using the same widgets (yad/zenity) in an improved way or even using a different one (like the old attempts of shellementary or enity), and we did it many times in the past shrinking multiple popups in a single one, for example in user creation it was like 5 or 6 popups for only the user (user, pass, repeat pass, etc etc) which are moved to a single widget (user creation) including also other added features like the sudo options

In the end, being in bash is not a bad thing, it is in fact a good and needed thing, the UI is independent of bash, so as mentioned before the UX can be improved without requiring to rewrite it which is an unreachable idea

How to proceed with that? in the most simple way: the first thing is to find an "annoying step" where too much popups showed or similar, brainstorm a better alternative, and propose a better code (hopefuly that will not conflict with the rest of the installer steps)

Talking about using a different UI, this has a very important requirement: it needs to be extremely light in RAM consumption (yad/zenity is), this is crucial since the installer is an essential step in every person that wants to install Elive on their computer, so even the most low-resources computer should be able to run it, otherwise is a direct loss of new users

Now let's answer some questions about the post itself:

There's many steps that requires to be run in different moments, for example:

  • the creation of the user will reciclate (pre-fill) the same password you inserted for "your computer" (and so root), so first before to run the user creation you need to have added this password in order to improve the UX by not asking it twice and also avoid possible typos which leads to people reporting "my password is not working"
  • in the same way, the email is also pre-filled if the user inserted it before
  • in the same way, the user-creation step is not shown if the installer detects that you are in the migration mode (and all the configurations are correctly fetch)
  • the configuration of lightdm needs to be run after the user-creation step, because it needs to know the username you used to add the autologin configuration (if wanted), in the same way you needed to define before if you wanted this autologin configuration
  • the user-creation step needs to be made after all the system is dumped / installed, so that if it fails creating it, it will show the error and eventually the steps to fix it, like "your password has an invalid character, try a different one" or some other thing

In short, this is a small example of why steps needs to be run in different moments, of course not all of them are needed or dependent of other steps, this will require a deep reading of the source code to make sure there's no dependencies in the steps order, for example we may think the hostname is irrelevant on the step but it is required to configure also the hosts file, which is required to be configured before to install new packages or do system's configurations, etc

Could be somewhat in the theory, but check the previous details and you will see that is not an easy thing at all, big cost and lowest benefit

Yes, it has been improved many times to do that, so as I said before what will be needed to do is to "find" a specific case, brainstorm if is possible to do it before, and then improve that part

More or less, the installation is pretty fast, installing other distros are much slower most of them, Elive takes like let's say 15 minutes. About the "typing accidentally" this doesn't happens on E17 because of a special code that disables the "new windows always receive focus" during the installation process, but thanks to point this issue out, I just added a feature on the installer to make this feature working on E16 too :applause:

Are you serious?

I specifically said that this update would keep the existing installer code. It would ONLY change 'when' the settings are entered.

This would NOT be a rewrite. You would need to change only the parts that currently run yad, and make them read from the configuration in memory instead.

I also suggested working on something similar to shellementary on Asana and you shut that down too.

I dont understand what you mean by this. Do you mean the encryption password?

Which is doable with an installer configurator that runs beforehand.

Which is doable with a tiny bit of extra code with an installer configurator that runs beforehand. We could make it skip those parts in upgrade mode, I don't really care.

But your choices could be stored in memory.

I already addressed this:

Simply store the user's requested values in memory while installing, and pass them to the user configurator

I also addressed this in my post:

Yes, I KNOW that some of the popups are superfluous.
I KNOW that you can get rid of some of the larger offenders.

I think either you're ignoring the content of my post or we have a massive communication barrier here. It's impossible to make suggestions or bug reports right now because we're not at all understanding what the other is saying.

I don,t know what the solution is - maybe IRC? voice call? But we do need to fix the communication here. This is a common theme.

Ok, I give a good list of reasons of why the rewrite of the installer is not a good idea (which can be used in a FAQ maybe) but I also answered you these points

As said before, let's talk then specifically about "what must be changed, to what" and we will see if is possible, for example I give you a few examples of the user creation widget required steps

Shellementary is not an usable tool at the moment, its incomplete and with bugs

To remove confusion to the users (which reported a lot this issue in the past) it is the same password all over (which means, root and encryption), it is also used as pre-fill for the user password too (which, the user can change if wants to). So my point means that before the user creation is made, it needs to know already some data, like the hostname of the machine (I think), the desired password, or if comes from migration or normal

Can be, as said, needs to be studied if possible (for each specific thing we would want to change)

No, I described important details of the installer and I was not against the idea of improving some parts of the installer

There's a lot of elements here which I didn't doubt would come up.
I think @TheTechRobo needs to be clearer as to what he exactly has in mind for the primary GUI, i.e what renderer and what language (code wise). I'd love to find out.
So IMO show a mock-up GUI, with maybe some psuedo-code, to clarify the Ux benefits as well as (hopefully) easier maintenance.

As for 'yad/zenity': I think there are options there like having "notebook" or "paned" mode to keep a widget in the foreground whilst changing the contents or tabs inside it. Meaning no risk of it getting lost in consecutive pop-ups.

Frankly, the installer clearly does its job quite well ....... it's only the (seemingly unrelated) pop-ups that make the whole interaction feel unhinged ..... so IMO that's where the actual challenge lies. :thinking:

1 Like

Yes the installer does its job very good, even if has not the most beautiful gui, and in the last 1-2 years has improved a lot in many aspects, I sometimes say that is the most advaced installer existing in linux (totally specific to the OS itself) but this is clearly not easy to see from the frontend :joy:

And yes like mentioned before, improvements are welcome, it all depends on how "better" and possible the idea is (and, the cost to develop it), we just needs to find points to improve and that's all

I don't doubt that, but I did offer to write my own version. Your response boiled down to basically "it's been tried before, don't do it".

Sorry, I got confused since the first half of your response is talking about why a rewrite is a bad idea.

Was planning on using python-efl for this. I'd do C, but I'm not terribly familiar with it.

Rough mockup (excuse the messy writing, this marker is awful - if you need clarification let me know):

The "see footnote": when you click on an option that requires more clarification (e.g. "Manual" requires you to tell it whether you'd like gparted or gnome-disks) the remaining options should slide down when you select that radio button.

Does that look at least somewhat decent?

That would also work but it might be best to do it in EFLs.

Yeah the installer's great! I just think the UI probably turns people off and makes it seem rudimentary.

The python-EFL has some maintenance issues, especially in relation to python3 (where python itself is yet another extra layer) so I'd be careful there. I personally find it hard to get full control of the widget in all the aspects....but maybe you're lucky.

I get the idea, I think . That kind of GUI can (I hope) also be achieved using "notebook mode" in 'yad' with the steps underneath in tabs. Practically 'yad' has gtk3 built-in so a direct call is also an option.

I've had a look at the code and get the impression it's going to be hard putting all the GUI entries together without messing up the step-by-step setup it has. That setup has apparently grown rather organically over the years and maybe could use a clearer new more methodical modular approach.

But that would leave us with the "fix it till it breaks" opposed to "Leave well enough alone" as option dilemma. :shocked:
So, if at all: Development parallel to the original until proven viable.

Unrelated to this thread, I saw that "entrance" got some attention from rasterman on github and ironed out a persistent bug. I think we're the only distro that actually has "entrance" available as a package so, once it proves to be stable enough ...... use that as a login manager. :thinking:

Problems I see with using yad/gtk are:

  1. I really don't like GTK
  2. If we want to use EFLs in the future it's more difficult