[BlueOnyx:15374] Re: demo.blueonyx.it updated

[Michael Stauber]

Hi Jim,

> Looking at the current UI in BlueOnyx 
> it uses a frame approach which removes the need for refreshing much of the 
> page and provides a reasonable experience. I would like to see the new UI 
> either use an asynchronous JavaScript approach or cheat and use the frameset 
> approach otherwise.
> 
> Might be too late in the game to make this type of change but I wanted to 
> provide you the feedback.

Hehehe ... it is a bit late for that now, considering that the work is
more or less done. :-)

But yeah: Speed is a concern and reloading the entire page and not just
parts of it is slower than the old GUI. I looked at both the frameset
approach and the AJAX approach early on.

As you can see in the demo: There are parts where the content area is an
IFrame. For example for phpMyAdmin or "System Settings" / "Hardware
Information". But also in a few other parts like installing / removing
PKGs or deleting Sites and Users. This is a bit of cheating, but speeds
up the handling experience.

As for AJAX: Very early on I worked on a "proof of concept" demonstrator
that was using AJAX to update the content area. It didn't take care of
the menus yet, which would have been another problem.

The demonstrator handled basic stuff very well and made it clear that I
can use AJAX to push certain elements into the content area. But a lot
of what we use in the content area uses jQuery and some of that needs to
be in the page's headers or needs to be initialized via
DocumentReadyFunction() during initial loading of the page. Especially
for the getScrollList() stuff, which uses DataTables. That then quite
limits the number of useful elements that can be pushed via AJAX.

The menus would have been another problem. Sure, you can push menus via
AJAX as well. But our case with the menus is a bit special. Our toplevel
menu has seven branches. Each of which have up to three levels of
sub-branches. However, Access Control Rights need to be figured in. Only
"admin" users can see the entire menu. There is a complex logic going on
in the background that checks each leaf on the branch if the user in
question has privileges to see this. If not, the leaf is removed. If a
branch therefore ends up without any leaves left, it will be removed as
well. That is done entirely in PHP and the results of that could be
pushed via AJAX, too. But alone and by itself that wouldn't speed up
things one millisecond, as the problem is rather the content area.

But all in all there is some heavy duty scripting going on to make
things as dynamic as sensible. Aside from the core of the GUI that's
written in PHP we rely very heavily on jQuery now, with a bit of
JavaScript sprinkled in wherever it can't be avoided.

There are also usage cases where the new GUI is a lot faster and more
usable. Just the other day I was on a box under support contract.
Supposedly the auto-responder for the user with the email alias
user at box.net wasn't working. So I went to the (old) GUI on that box.
Went to "Site Management". Great, 200 sites. So I used the search box to
search for www.box.net. No results. Searched for mail.box.net. Ah, there
we go. Clicked on the edit icon. Great, 176 users! Entered the alias
part into the search box. No results. Ended up clicking through the
pulldown menu for "show next 20 results" a few times, wasting precious
minutes locating the user.

In the new GUI this would have taken 10 seconds max. 5 seconds locating
the Vsite, another 5 for the User. Page loads already figured in.
Because the ScrollList tables have all the data already in it and
paginate them to just 10 results. But the search field works without
page reloads and starts limiting the shown results even after typing the
first character into the search field. That is a great help and saves
oodles of time in day to day operations.

Still: I am concerned about page load times and am looking into ways to
improve that further. As is the demo isn't yet optimized. We carry some
jQuery baggage around that we don't need on every page and I'm currently
in the process of trimming down on that.

> I would like to offer my help any way I can but would need some hand 
> holding likely, but willing if you are. I have built a few web
> based applications using .NET MVC and UI interaction
> with libraries like jQuery and have gotten reasonably good at writing 
> JavaScript.

That jQuery experience would indeed be useful. Here is a particular
jQuery related problem that I still need a solution for.

Example: http://demo.blueonyx.it:444/vsite/vsiteAdd

There are certain fields (marked by the red star in the right upper
corner) that *need* input. In that page here it's things like IP, host
name, domain name and a few others.

Input is validated in two occasions: While you type into a field and
when you hit the save button. Try to change the filled in IP address to
"hello kitty" and see how it complains "Please fix this field" below it.
If you hit save and have missing data in a field that requires input,
it'll show a similar red marker under the field in question saying "This
field requires input."

When you look at the HTML source code of the GUI page, you can see that
it's done here via the jQuery Validation Plugin:

<!-- Start: Overrides for Adminica functions:-->
<script src="/gui/validation?update"></script>
<!-- End: Overrides for Adminica functions:-->	

I'm just using a slightly customized version of it to show the error
messages in the language the user has chosen. And our modified version
has oodles of additional data types it validates for.

That validation itself works perfectly. No problem there.

But ... I broke one part of it which needs fixing:

Some page save transaction take a bit longer due to all the things that
need to be stuffed into CODB and the handlers that then run may take a
few seconds. Think of creating a Vsite, for example. When you hit Save
on that form (and it wouldn't be in demo-mode), it would take 8-12
seconds for the site creation to finish. On which you'd get redirected
to the Virtual Site List again.

To prevent people from aborting this transaction I added an overlay
image that shows up in the middle of the screen when the save button is
clicked. That's there to encourage the user to wait for the transaction
to finish.

For that I use this code near the top of the page:

<!-- Start: Wait overlay -->
<script>
	$(document).ready(function() {
	  $('#fade_overlay').popup({
		  	blur: false
	  	});
	});
</script>
<!-- End: Wait overlay -->
<!-- Start: Wait overlay -->
<div id="fade_overlay" class="display_none">
	<img src="/.adm/images/wait/loading_bar.gif" id="loading_image"
height="75" width="450">
</div>
<!-- End: Wait overlay -->


An this here neear the bottom of the page:

    <!-- Start: Wait overlay -->
    <script>
        $('button.waiter').click(function() {
            $('#fade_overlay').removeClass("display_none");
            $('#fade_overlay').popup('show');
        });
    </script>
    <!-- End: Wait overlay -->

The problem: If there are fields that are missing their required input,
the valiadation plugin does deactivate the save button. That still works
fine. But the wait overlay still starts showing merrily, although the
form is NOT saving.

Ideally the error raised by the validation plugin should also prevent
the wait overlay from initializing.

Any idea how to fiddle that one in?

The relevant section in http://ng.blueonyx.it:444/gui/validation?update
starts at line 14 and goes to line 97, or 212 to 279.

-- 
With best regards

Michael Stauber