Fluid web forms using AJAX

Sometimes you want a web form that changes based on the input. The web form can give the user feedback while filling it in: We often see web forms put green check-marks behind (server side) validated fields. Some fields may turn red after you filled them in wrong. This validation can either be done client side (in JavaScript) or server side (using AJAX).

I’ve created a small application (available on Github) that looks like this:

fluid_form

When you fill in a field and it loses focus, the entire web form is submitted and updated. This includes field validation on all fields and marking them red when validation fails. Note that only after you submitted the form you want validate that the required fields are filled in. So you need to differentiate between validation before and after submit. The form has a hidden “submitted” field to facilitate that.

This demo is using the following components:

  1. Bootstrap 3 (requires jQuery)
  2. jQuery-populate (plugin by Dave Stewart)

All validation and calculation is done server side.

Why? Well, some validation can simply not be done client side. Promo codes in your web shop’s shopping cart is a good example (for security reasons). Another reason may be that sending all your validation data in a JSON object may in some cases overload your client. For instance, when you have hundreds of products with lots of product specific options. This may lead to slow rendering, due to excessive JavaScript usage. This may be especially problematic on less powerful clients, like mobile phones.

There is a downside: In order to allow for real-time server side validation you need to be able to sustain way more page loads. If the form is submitted after every changed input field, you need the web form handling to be light-weight. I managed to get the initial page load and the submit and validate to be 1 (one!) millisecond in vanilla PHP on my local machine (see screenshot). I guess that if your page loads are this cheap, you may consider using a little more server side technology. ūüôā

Play with it, feel it!

git clone https://github.com/mevdschee/bootstrap-fluid-form.git
cd bootstrap-fluid-form
php -S localhost:8888

Point your browser to http://localhost:8888 and test the application. Pay special attention to the speed and the usability. Does your application resemble this? If not, then you should ask yourself… why not?

Share

Please stop using pop-up windows in web applications

In the Nineties, we were writing desktop applications with pop-ups. These desktop applications consisted of multiple windows that popped up. I was programming Delphi back in these days, where windows were called forms. The naming probably came from their main purpose: data entry into the bundled Paradox database. This is comparable with the forms that we see today on the web and they were equally abused for other purposes.

The purpose of forms in a database driven application is to facilitate CRUD (Create, Read, Update, Delete) operations. That is why you need the List, Add, Edit and Delete forms. Maybe the Delete form is not needed and this can be just a conformation dialog. To simplify the application flow, it used to be possible to make pop-up windows “modal”. This meant that you could not ignore them and had to click them away before you could continue. This is typically something you would want when you want the user to confirm an action or acknowledge a critical error.

JavaScript (like Delphi back in the day) has simplified making modal pop-ups by offering us the functions “alert()” and “confirm()”. But let’s take an example of a typical company database application. Such an application may have an overview showing a listing of customers. Maybe you can search in this list. If you click on a specific customer you may be able to see a list of their¬†orders. In the Delphi days, we would have a window with customers and when you clicked on the “view orders” button, it would open up a new window with this information.

lightbox_popup
Figure 1: Example of a jQuery lightbox styled pop-up in WordPress

On the web, we first tried to copy this model by opening new browser windows in web applications. Then came the era of pop-up ads and ad blockers, and people started moving away from the multiple browser window strategy. This move was stimulated even more when browsers started having tabs. Then we saw that developers started making jQuery lightbox styled pop-ups on top of other pages. These are still used a lot, but I feel they lead to horrible user experiences wherever they are used.

In the end, most of the developers saw the light (fortunately). They probably realized that you do not need a stack of windows since the web browser already allows you to go back (and forward by opening new pages) in this stack using the back button and the links you can click. Also, the browser creators¬†acknowledged that in order to make users use the “alert()” and “confirm()” functions, they had to make sure these pop-ups rendered in much prettier way. Until then, they resembled the JavaScript error pop-ups from the Nineties.

So today, when I stumble across an HTML anchor tag with an TARGET property, I cringe. It hurts even more when I see people use jQuery lightbox styled pop-ups. Not only because they are almost always a pain to close, but also because they do not work properly on different screen sizes (like phones). However, the worst thing about this form of pop-up, is the wrong expectation that people have about the underlying page. What should happen when the pop-up is closed? Should it be reloaded, so it is updated? Or can it have old data? I don’t know, can you tell me?

To add something constructive to this rant, I will also propose some new rules for pop-up lovers that have a hard time forgetting the Nineties:

  1. Everything is a page, and your application can most probably be represented by a tree (with some jumps back).
  2. Use clickable breadcrumbs to show the current path in the tree structure of your application.
  3. The back button should work everywhere and warn when needed (about reposts or expired pages).
  4. Make sure all your pages have a single, structured, short, but descriptive URL.
  5. For confirmation, rely on the JavaScript “confirm()” function.
  6. Use top of page colored flash messages to show success or failure.

Are you in the business of making web applications that mainly do CRUD operations on a database? Have you still not sworn off pop-ups? Do you think I am wrong? Please use the comments to discuss.

Share