So this code isn't perfect, but I can't get anyone to look at it and improve it and I wouldn't know how to make it better either. At the same time, I think this is a necessary feature and needs to be added to 4.0, which is why I'm marking this as ready for review now. I'd rather merge this imperfect code, than to have the mess we have so far.

How can we test it. As far as I can recall no one was previously able to setup an environment where the ftp install would be triggered. Did you find a way?

sorry wrong issue

@brianteeman ?
I would appreciate your comment on this issue as well. ?

@Hackwar I am looking

it works, its an improvement, it is fugly which for a first impression of joomla is not good.

The main problems are that it is completely inaccessible (suggestions coming) and that the popup closes before I have the time to read it.

Can you not use the joomla-alert in the same way that you did in the sample data installer? That immediately solves a lot of issues.

Not going to comment further for now as those comments would be made irrelevant if you use joomla-alert

it works, its an improvement, it is fugly which for a first impression of joomla is not good.

I'm open for improvements. I've been asking around a bit in the last months and people frankly have let me down. I'm not exactly creative enough to make it look nicer. For example the progress icon in front of the lists are hidden by setting them to white. I know that is a really ugly way, but I'm a backend dev mainly...

The main problems are that it is completely inaccessible (suggestions coming) and that the popup closes before I have the time to read it.

The popup is not really meant for people like you with a quick database/server, but for those with slow systems to give them an indication of progress. I had a misconfiguration on my system some time ago and that resulted in the database population step taking several minutes. A time in which you have no idea what is happening, where it is failing, etc.

Can you not use the joomla-alert in the same way that you did in the sample data installer? That immediately solves a lot of issues.

I think that would not be the best approach. First of all, the content has to show up above that spinner/loader/whatever thing and thus I would expect a modal. We also need a way to block the interaction with the previous form, so the overlay of the spinner and modal are good. At the same time I don't want the steps to show up one after the other, but to have them visible all at the same time, so that you can see how much still has to happen...

joomla -alert is the way to go - it solves your real problems

I've checked joomla-alert and it definitely is not the way to go. It is the wrong UI element for this task. However I've looked over my implementation and improved it a bit and hopefully this https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions is correct and thus this should now be more accessible.

This does contain one issue and that is it is only looking for mysql custom SQL files and not postgres. Do we want to catch that case as well or do we put the burden for that on the one adding one of those custom SQL files?

On my phone so can't check right now but the aria live element must be in the page before the message is created. Usually you would achieve that in the html not the js. See https://bitsofco.de/using-aria-live/

Confirmed my suspicion from last night.

Changed.

Would you sign off on this this way? Then we could move forward with this whole thing.

its an improvement. not perfect but can be improved in another pr.
not for me to approve anything

The main question was, if you would sign off on the accessible part of this PR. Thanks for your support.

Hi,

nice progressbar, sorry for no feedback didn't see the pr in june

Found a small problem in case of an error

and could you fix the cs errors please

The check marks may could have a lighter green but I don't know if this is our default green.

The main question was, if you would sign off on the accessible part of this PR. Thanks for your support.

Still not for me to do that. That would be the role of the accessibility team

CS errors are not from this PR, but currently part of the 4.0-dev branch. Fix is here #31879

The check mark is the default color that we use.

I'll fix the error handling.

All changes incorporated. Please test and lets see if we can merge this quickly.

I still don't understand why this is a modal

Then tell me how else you would display this information. With all steps-to-be-processed visible from the start, returnable to the previous screen, updating the existing data, etc.

I think this feature would be a nice addition, but I have to agree, it shouldn't be a modal.

I think this should me incooperated into a bigger improvement project for the installer (there are many flaws which should be fixed) and at the end a solution could be, that we hide (not just gray out via overlay) the installation form and show only the installation progress (+ valid return when failed, not just the whole form).

To not forget about this idea, I set it to draft.

This pull request has automatically rebased to 4.2-dev.

Can we maybe get some space between the progressbar and the checkbox list?
Rest looks great.

Can we maybe get some space between the progressbar and the checkbox list? Rest looks great.

Done.

Does it really still need the joomla spinner at the end?

This completely fails accessibility. Nothing is announced at all. There is just complete silence and a user would not know that anything is happening

Does it really still need the joomla spinner at the end?

I don't need it. However I would leave the review of stuff like this to someone else.

This completely fails accessibility. Nothing is announced at all. There is just complete silence and a user would not know that anything is happening

Unfortunately I don't know enough about accessibility to get this right. I would need your help and the help from @chmst and @drmenzelit. I'm open for what needs to be done to get this right.

I refactored the whole PR to not use a modal, but to show an additional step in the normal installation process. Please review this PR again, so that we hopefully can add this to Joomla 4.3.

You will probably need to use aria-live

https://cccaccessibility.org/web-1/web-developer-tutorials/using-aria-live

needs to be checked by the JAT @chmst

needs to be checked by the JAT @chmst

we are on it

We made a few tests and the result is:

The progress bar is a nice enhancement and is accessible as all the update - progress bars in com_installer.
The indication of percentage seems to be not correct, maybe due to rounding errors. Steps could be a better solution.

The display of steps as text however is not accessible, neither for sighted nor for blind users and should be hidden.
Joomla provides a very fast installation and no reader can read all the information in a few seconds.

On the other hand, it is useful to see where the process stopped, if there is an issue.
Maybe the texts can be hidden and only if there is no progress for 10or 20 seconds, the texts of performed steps are made visilbe.

The display of steps as text however is not accessible, neither for sighted nor for blind users and should be hidden.
Joomla provides a very fast installation and no reader can read all the information in a few seconds.

If you do that then currently there is no way to know that anything is happeninbg

Joomla provides a very fast installation and no reader can read all the information in a few seconds.

Instead of going to the next page automatically you can provide a next button. This allows everyone, sighted or not, to read the text

I personally don't want to know what's happening if an installation runs, but am glad to start and to see nothing than the "congratulations" message. I like the progress bar in the updater. Only if something goes wrong, I want fo know where and why.

It would be great if we could get a progress bar in 4.3. The bar in the updater seems to be globally accepted. Then as @bembelimen wrote, a new concept could be made for future.

You will probably need to use aria-live

https://cccaccessibility.org/web-1/web-developer-tutorials/using-aria-live

It specifically states that it should not be used in this case

Section three-- avoid misuse.

The aria-live attribute should not be used for dynamic content that's not critical. This just adds noise, literally, for assistive technologies.`

By your interpretation of that then this entire PR should be rejected

Thats for JAT @chmst to decide not me.

For me, this looks good to go ?
Also the aria-live="polite" is from my understanding correct.
@brianteeman do you have the capability to check with a screen reader if the behaviour is the expected one? If yes I would reactivate this PR for testers.

@brianteeman do you have the capability to check with a screen reader if the behaviour is the expected one? If yes I would reactivate this PR for testers.

yes - of course - and so does every windows and mac user as they have a screen reader with their os.

However this is something that you should be asking the JAT and not me. @chmst as leader of the JAT think its better to have a long period of silence while the instllation takes place. JAT should be the ones making decisions on ccessibility not me

... and as this PR has the a11y tag it must be approved by the JAT and so far they mistakenly do not approve

I have not enough experience using screen readers, so my results are maybe not 100% correct. First thing I notified: using NVDA I get different results in Chrome and Firefox (Chrome seems to be more verbose). What I tested:

• removed aria-live=polite from the <div> and role=status from the <ul>, added aria-live=polite to each <li>
• removed aria-live=polite from the <div> and role=status from the <ul>, added role=status to each <li>
• rewrote the code to use readonly checkboxes instead of a list, ticked each checkbox using Javascript after the step is completed, tried aria-live and change of focus...

Conclusion: the installation is too fast and the screen reader is not able to announce the steps correctly (too fast, too verbose). The advantage of checkboxes is that the user can tab though them and get the information, but here is also the problem that the process is too fast, before you get tabbed through the steps, the installation is finished and you get the next screen.

I think the steps should stay hidden (visually and for screen readers), so that they can be used for the automated tests Hannes is working on. In case of an error an alert should be visible and audible, so the user knows what went wrong. It would be nice to get an announcement at the end that the installation is complete.

Other ideas are most welcome.

The container with aria-live must exist on the page load. It cannot be added by the message.

It is not for a non-screen reader to determine if the information is too fast. Regular users know far more about using and controlling the screen reader.

If you consider it too fast for a screen
reader then it should also be removed visibly. You can not have one without the other.

The code in this pr is technically correct and should be accepted

The container with aria-live must exist on the page load. It cannot be added by the message.

As it is now, it was ok in my test with NVDA and Firefox, in Chrome NVDA started reading from the first step again and again

It is not for a non-screen reader to determine if the information is too fast. Regular users know far more about using and controlling the screen reader.

Yes, and that is why it is not so easy to test, we need a real screen reader user...

If you consider it too fast for a screen reader then it should also be removed visibly. You can not have one without the other.

That is our suggestion too

The code in this pr is technically correct and should be accepted

Yes, it is technically correct, but we have to make sure that the user experience of screen reader users is good.

Another thing I noticed is that the progress bar was completely ignored by NVDA. Using a screen reader add-on in Chrome the percentage was announced, but at the end was more than 100% ?

Grrrh. The JAT should be enhancing accessibility not diminishing it.

Grrrh. The JAT should be enhancing accessibility not diminishing it.

That is not fair. We are trying to improve the code to offer the best possible user experience. Which of our comments let you to the conclusion we are diminishing accessibility?

Screen readers have the ability to change the speed at which text is read. Most programs can vary the speed between 60 to 400 words per minute

In English, the typical read speed ranges between 120 to 150 words per minute, where advanced and fast screen reader users can understand content being read at a speed of even 450 words per minute. Even if most screen reader users don’t require such high speed, it is still common for them to use higher rates than that of typical spoken language. It is important to keep in mind that the first impression that long-to-read content slows down the user can be deceptive as when set at high reading speed rates, it is being read blazingly fast. Remember, don’t worry too much about long descriptions.

Basing your decision as a non experienced user to remove both visual and auditory feedback is degrading the accessibility. Clicking a button and then not getting any feedback for 10-20 seconds is not acceptable.

It is not the read speed of a screen reader, but the speed of the installation... the screen reader says: checking data.. (interrupted, because the next step is already finished), and the next step the same, and depending on your system maybe starting with reading the first step again... maybe an experienced screen reader user can sort that kind of issue, but I don't see what the improvement in user experience should be...

Your words:

If you consider it too fast for a screen reader then it should also be removed visibly. You can not have one without the other.

And I don't know how we are diminishing accessibility on something we don't had all the years before...

I give up trying to explain - you're clearly not listening and as the JAT knows best I will finish.

Sorry @brianteeman first you asked for the @joomla/joomla-accessibility-team-jat and now you're complaining if they give feedback, that is kindergarden.

After reading the explanation, I still think in theory, that aria-live is a possible solution here but in real world just outputting everything from the progress is not reasonable (and like @drmenzelit wrote, the installation process is too fast to cover the full text). The steps itself (when they're successful) do not give any benefit when announced, the only thing which is really important is the message if the installation was successful (we could discuss this, too) or if it failed.

You dont get it. Let me try one last time without the personal comments which are beneath you.

The purpose of this PR is to add a feedback of the completion of each stage of the installation. If that is to be accepted then it must be done in such a way that it is accessible to everyone. Just like every other piece of code.

Rejecting the addition of aria-live because a non-screen reader user says that they cannot hear all the text being read is not a good reason. As I already pointed out, a regular screen reader user will almost certainly have the text speed greatly increased etc. and there are other assistive technologies that make use of the aria-live messages which are not influenced by speed at all.

If it is determined that the display of the texts is of zero value then they should be removed from this PR. Personally I find them a useful addition and similar to a lot of other software.

The suggestion that 10 - 20 seconds of silence is acceptable really is not and shouldnt even be considered as a serious comment which sadly is true with the current installation process

It would be nice if we could make all content equally accessible to all people. Unfortunately, that doesn't always work out.
From a technical point of view, this improvement is certainly useful for developers. They can see where there might be problems with the installation.
But usually the installation goes smoothly. Most people, even sighted ones, will pay less attention to the messages as long as everything runs well.
They don't need to look if they don't care. Screenreader users don't have that choice when we are working with a live region. You are certainly right when you say that most screen reader users run their speech output at a pace where we can't understand anything. But still, there are beginners there too.

Besides, we have checkpoint 2.2 in the WCAG, automatic output without prompting is not an option. https://www.w3.org/TR/WCAG22/#enough-time

Splitting the installation into individual steps that are continued by clicking a button would be the only accessible solution. But I think this is nonsense. @brianteeman If you have a solution that works for everyone, we would be really happy.

Well as you have brought up https://www.w3.org/TR/WCAG22/#enough-time then this PR will have to be adjusted to remove all off the progress messages

can you please test this: http://der-auftritt.de/tests/progress.html

The purpose of this PR is to add a feedback of the completion of each stage of the installation. If that is to be accepted then it must be done in such a way that it is accessible to everyone. Just like every other piece of code.

Not every piece of code is accessible to users - all the debuginformation is not accessible. If the purpose of the PR is providing information for tests, then no user must see or hear an information. If the information is hidden for everyone then everyone has the same information, only the testing machine has more.

Question @brianteeman - you know the progress bars in update screens. I personally like them. They also run fast and I never had a situation where such a bar stopped. No clue what happens in such a case. Are these progressbars accessible in your opinion?

can you please test this: http://der-auftritt.de/tests/progress.html

The demo was updated and tested with NVDA and VoiceOver. Angie uses here the native html progress element, it has to be tested if the Bootstrap progress bar also works as expected adding aria-label to it.
The list of steps can be hidden (to avoid flashing text and no enough time to interact with - as Angie already posted), but in case of an error an alert has to be visible and audible.

Thanks for creating that @angieradtke. This has the same issues that were objected to with @Hackwar code in this pr. But for different reasons. This code uses assertive instead of polite. Assertive means that it always interupts whatever the screenreader is doing. So as the screenreader tries to read out the text messages it is interupted with the content fo the assertive statement from the progress bar.

Not sure at all what you meant by testing it with nvda and narrator

Not every piece of code is accessible to users - all the debuginformation is not accessible.

True but it should be if we can make it. Also this is one of the very first things a user is presented with and if we say J is accessible and one of the very first screens is not then it doesnt create a good impression.

This is not the final solution yet. There are some general problem issues. But we are on the right track. I am glad that blind experts are helping us right now. The issue of "polite" is secondary for the moment. However, I think assertive is still right here. The problem is rather the inconsistent of of screen reader handling. Jaws on Firefox remains mute. At the moment we don't know why. Jaws on Chrome works. NVDA and voiceover work as well.

Don't waste time on the Firefox issue as screen readers do not work consistently across all browsers.

We need a bulletproof solution working as a blueprint for other apps as well

We need a bulletproof solution working as a blueprint for other apps as well

there is no such thing - sadly

https://www.powermapper.com/tests/screen-readers/

here are no tests width progress:
https://www.powermapper.com/tests/screen-readers/ua/ua-jaws-ff/

So we should test. I hope we can find a solution.

My point in sharing that link was to show the evidence to support my statement that screen readers do not work consistently across all browsers.

Forgive me for trying to stop you wasting your time chasing the pot of the gold at the end of the rainbow.

So it works with:

• Narrator in Edge.
• Jaws and Chrome
• NVDA in Chrome and Firefox.
• Voiceover

Leonie told me to stay with assertive.

There is only the jaws in Firefox issue.

@brianteeman You know, curiosity is one of my bad qualities.

@brianteeman changed the code to pure HTML http://der-auftritt.de/tests/progress2.html;
Please retest

First of all big thanks to the Joomla Accessibility Team. Numerous (disabled) people have tested this PR and given feedback and the overall consensus was, that the text below the progressbar was just clutter and not helpfull. My initial motivation was to have some output for debugging purposes and with the text that went a bit to far. The progressbar would already be enough for that purpose and at the same time it would provide a usefull response to endusers - with and without disabilities.

One feedback was to use a proper progressbar element. Another feedback from a blind user was to use the progressbar from the joomla updater. Since my code used that already, I didn't change that now.

Would that now be acceptable to be merged?

Not at all. Last checks are needed . We have to talk about the persentations of errors as well.
The displayed steps and ariavaluenow does not fit to each other.
At the end you have ariavaluenow="7" but your code says you have $steps = 6;
This is a small issue with great impact.

I built a summary for screenreader-tests here:
https://der-auftritt.de/tests/progress.html

If we have Feedback from Julian we can go forward.

Which of @angieradtke versions is this using. /me confused

@brianteeman the first one is closest to Hannes
Native Version 1 is the cleanest

so why isnt it using native version 1 - if your tests said that was the best?

similar example with full documentation from deque
https://dequeuniversity.com/library/aria/progress-bar-bounded

Because two equally qualified experts told me 2 differing solutions. One said to use the native progressbar, the other to use the one from bootstrap.

Both solutions seem to work - with differences which don't affect the function as a whole. I suggest to use the same everywhere in Joomla. This makes maintenace easier and the user sees and hears always the same.

similar example with full documentation from deque
https://dequeuniversity.com/library/aria/progress-bar-bounded

similar, but here a native progress bar also gets Aria attributes. This is kind of duplicative.
I suspect this code is from times when the native element was not well supported.
I hope the native element will pass the sceenreader tests, that's my favorite because it's native and thus robust.
But let's wait and see what Julian says. If the screenreader support is not there, the nice code won't help us either.

Dear Hannes , dear Team,

sorry, it took a while, but here you can find the best practise example, including error messages.

https://der-auftritt.de/tests/final.htm

Leather we are not finished yet. We want to use this example as a component, so we can use it everywhere. ( Finder index/update)

So we should rewrite the used javascript @dgrammatiko into a generic working variant ( including variable messages)
and place it where it has to go.

The CSS has to be added at the appropriate place using the color variables as well

@angieradtke that rocks!!

I've adapted the proposal from @angieradtke as good as possible. Please have a look and test if this is correct now.

Hi Hannes, found some issues:

1. The text of the label should be only "Installation" before the installation starts.
And only when the installation is really running it should be changed to "Installation running".

In the screenshot you can see that the displayed information can't be true.

change language string to echo Text::_('INSTL');

 <label class="progresslabel text-center">
                    <progress class="progressbar" id="progressbar" value="0" max="8"></progress>
	                <span id="progress-text" role="status"><?php echo Text::_('INSTL'); ?></span>
                </label>

2. How Many steps has the installation?
At the end you have the code as follows:

<label class="progresslabel text-center">
                    <progress class="progressbar" id="progressbar" value="7" max="8"></progress>
                    <span id="progress-text" role="status">Installation running</span>
                </label>

I'm not really sure. After the installation there is a fast redirect , so that I don't get the the information "Installation finished"
It would be better to set a timeout of a few seconds, so the user know that everthing is fine.

3. I took a look at the js-files. I didn't get all the way through it because things related to the progressbar are spread across both JS files. I couldn't find a loop where " installation running" per step is ejected.
It almost looks to me like this is only set at the beginning and the end. Maybe I just haven't found that either or I did not understand the code.

4. How can I simulate an error in the middle of the installation progress?
   I do not know that, so I could not see if everything is correct with the JS Error handling.

Hannes , maybe helpful: https://der-auftritt.de/en/insights/progress-en.html

@angieradtke

1. Fixed this.
2. I added a delay of 2 seconds at the end. The bar actually goes to 8 out of 8, but afterwards immediately does a redirect. This has been fixed as well.
3. I indeed only set that once. I'm now setting it after each step.
4. To generate an error, you can go to /installation/src/Model/DatabaseModel.php and in line 422 insert throw new Exception('404', 'Error'); to generate an error upon installation.

I have tested this PR and i suggest to add a message below a possible error what to do next:
Something like: "Please refresh this page to start over"

@MacJoom That message would not be correct - depending on when the error occurred

In my case this message is not wrong but misleading - the database was created before but the database name entered was wrong. So this case should be mentioned too - "the database name is wrong"

@MacJoom That message would not be correct - depending on when the error occurred
I understand - but i think we need to help the user in a way or another - best would be a button...

I see that is not easy to understand.

We have two issues :

• The JS is not working correct we need a loop and an error function
• The language strings should be well translated to make sence

You are free to improve the error handling of the installation and be my guest when it comes to refactoring the installation, however that is outside of the scope of this PR. I will not start refactoring the whole installation on a PR with already 3 years of work on it. This already is a gigantic improvement, since users now at least get the feedback that there was an error, compared to before, where they had an eternal "loading" screen.

@MacJoom thank you for testing.
As others wrote already, changes in messages or in the installation process are out of scope on this PR. This PR has a long and interesting a11y story - worth to be published outside github.

Improving messages could go to another issue or PR.

Yes I see that this PR is a huge improvement to the installation routine. And i really would like to see this merged for 4.3 Messages can be adapted later...

I have tested this item ✅ successfully on 2e7fbe2

4.3-dev/PHP 8.1

I have tested this item ✅ successfully on 2e7fbe2

Great improvement! Thanks @Hackwar!

RTC

When I enter a wrong DB information, I just see the following screen:

There is no way for me to renter the database credentials again. The back button is not working.

The requested changes from @laoneo have been made.

Back to pending

@jwaisner @MacJoom could you test this again?

I have tested this item ✅ successfully on 2e7fbe2

Tested successfully - all sorts of wrong input on database credentials tested. Back button works to retry

I have tested this item ✅ successfully on 2e7fbe2

Maybe unrelated but I wasn't able to install any additional language.

There is still no way to get back for me when an error happens:

@MacJoom how could you go back?

There is still no way to get back for me when an error happens:

@MacJoom how could you go back?

Back Button worked for me (Firefox 108, Windows 10)

When I open directly the installation screen, then the back button in the browser is greyed out. I guess we have to wait for the suggestion from @dgrammatiko.

@laoneo can you try this: #29376 (comment)

I now did some tests with the latest j4installimprove, npm ci done - and now the back button does not work anymore (i was sure it worked before)
However the reload button works...

I have tested this item ✅ successfully on 2e7fbe2

Now the progress bar is not appearing at all anymore. After I entered the credentials, the whole form is displayed and then comes the spinning wheel.

Same with me ... - if i enter wrong db credentials the error message comes in the alert area on the top of the window but the user is at the bottom of the page so he usually doesn't see the message and thinks that nothing happened until he eventually scrolls up. On correct credentials the progress is not shown anymore, just the joomla logo for a short time and the end message.

After I entered the credentials, the whole form is displayed and then comes the spinning wheel.

That shouldn't happen, I'll have a look later today

Hello together,

maybe it is helpful to read again what was important to us ( A11y-Team) :
https://der-auftritt.de/en/insights/progress-en.html

I think I had already written somewhere that it would be better to add the installation steps not hardcoded. Using an Array would be better. (I can't find that anymore.) Then we have control over the error messages in one place/ function . This makes the code less and easier to maintain and debug.

Wouldn't that be possible? @dgrammatiko

I reverted the changes from @dgrammatiko and did some more fixes... Regarding @angieradtke, we discussed that and solved the topic.

Please check again. It should now work as expected.

Looks ok now, guess we have to wait for another test

Tested OK now - but i got the same problem as Harald within "Installing Additional Language" the "install selected language" button does not work and throws template.js?2866e0b7fb3eead87f64538845ad119e:206 Uncaught TypeError: Cannot read properties of null (reading 'setAttribute') at onSuccess (template.js?2866e0b7fb3eead87f64538845ad119e:206:18) at n.onreadystatechange (core.min.js?2866e0b7fb3eead87f64538845ad119e:1:6213)

I tried with a fresh checkout of 4.3-dev (jinstall done) - and did not have this problem

Indeed, @MacJoom & @HLeithner there was an issue with language installation. I fixed the code. So we need yet another round of tests. sigh

@Hackwar - Thank you for your work! - Tested "better" now - the "install selected language" button works now, but there is delay for a few seconds after clicking the "install selected language" button where it seems that nothing happens - i guess the installation is done in this time - then the joomla logo overlay comes up for a very short time - and then the installation is complete. It's a detail and i hope it's an easy fix.
crosschecked with 4.3-dev: the joomla logo overlay comes right after clicking the button and stays during installation.

Can you please rebase this on 5.0, I know it's annoying, but better have it better tested in a major release then less tested in a minor...

On my other wish list for the installer would be that the error handling needs to be much better/userfriendly :-(

Its working, but when there was an error message before, it appears for a second above the progress bar. Like documented in my video. Would be nice if its not visible, because at first I thought the installation would progress despite the error.

Ok I forgot to build js and css, but even after that the error still appears. The progress bar is just prettier.

did you used the prebuilt zip files? @fancyFranci

@fancyFranci can't replicate your issue

I have tested this item ✅ successfully on 2e7fbe2

still works

I can try again, but maybe that helps for replicating the issue: First I wrote a wrong database username like "rootz" and tried to install. Normal error message appears. I go back, fix it to "root" and install again. Then I have the behavirour like in my video.

Tested it successfully with the download, in web and cli incl. language installation. I think we will get more tests with beta1

thanks hannes