jQuery UI: Maximizing Dialogs

The dialog widget can be resized by the user, as well as programatically, using the API. Dialogs can also be dragged around on the screen if the draggable option is left on — the default. Sometimes, just like a real desktop window, you may want to maximize the dialog to occupy the full browser window. Blot out all the other distractions, so to speak.

Retaining Scroll Position With Dialogs

If you set the height of a jQuery UI dialog widget, the content will scroll vertically. This is the expected result — the .ui-dialog-content div sets the overflow CSS property to auto. However, issues take place when you have multiple dialogs, and content that scrolls inside each. Because of the way focusing works, the vertical scroll bar moves back to the top, whenever the dialog loses focus. Ideally, the user would expect the scroll bar to retain it's position, no matter which dialog has the focus.

Adding Buttons To The Dialog Titlebar

The titlebar of the dialog widget contains, surprisingly, the dialog title. But it also contains the close button. This is a useful component of the dialog that's mostly closed off to the developer, at least as for as the widget API is concerned. The best you can do is set the title text, or respond to the close event when the close button is clicked. Depending on your dialog content, the title bar may be the appropriate place to add new dialog buttons. The buttons option lets the developer add larger text buttons to the bottom of the dialog. But again, maybe that's not what you're after. You can extend the dialog widget and add a new option that allows developers to add new icon buttons to the titlebar.

Displaying a Dialog Loading Message

Oftentimes, displaying a dialog widget requires loading remote data, used to populate the dialog content. This presents a usability issue — the user has to wait for the data to load, and so there should be some visual indication that the data is loading. One solution to this problem might be to open the dialog, and rather than displaying the actual dialog content (you don't have the actual content yet), display a simple loading message. Once the real content arrives, this temporary loading message is replaced. This approach works fine. The challenge, however, is that it's tough to make a loading message look good in a dialog. The other issue is the resizing of the dialog, once the content is formatted and inserted.

Advanced Dialog Effects

The jQuery UI dialog widget has a show, and a hide option — each of which are used to specify effect options for their respective actions. The show option is applied any time the dialog is opened, while the hide option is applied when the dialog is closed. They're one of those options that tries to be flexible, and at times this is misleading. For example, you're free to pass in a string, a boolean, a number, or an object with several effect properties. Everything other than the object type are intended to simplify the option. If you only want to enable the show/hide effect, you pass a boolean. If you want to specify the duration you pass a number while a string specifies the effect name to run.

Remove Dialog Close Button Focus

When a jQuery UI dialog widget is first opened, it gains the focus of the page. This makes sense, given that most of the time, the dialog opening is the result of the user performing some action, such as clicking a button. The idea is that the dialog probably has some other element in it that needs the attention of the user, like, a text input. It's nice when the user is able to just open the dialog, then continue typing. But perhaps you don't want this behavior.

Default Widget Options

Each jQuery UI widget comes with a set of default options. These options also come with default values. If they didn't, you would have to specify a value for every available option each time you create a widget, since the widget relies on options being populated. But the default set of options that a given widget uses may not suit a particular application well. Signs of this being the case are lot's of the same option values being used all over the place. This is easy to fix by creating a custom widget that extends the options object with the defaults you would like to use, while leaving the other default option values intact.

Responding To Dialog Open and Close Events

The jQuery UI dialog widget, just like every other widget, triggers events to reflect changes in state. For example, when a dialog is opened, it enters an "open" state, and the dialogopen event is how this change is communicated to the outside world. This means that any element can listen to these events, including the body element. Listening for dialog events after they've bubbled up the DOM is handy for implementing generic behavior.

jQuery UI: Dialog Close Button Text

By default, the jQuery UI dialog widget places a close button on the right-hand side of the title bar. In past versions, this has just been a strewn-together mess of elements and events. Now it uses the button widget, which for obvious reasons, makes things a little easier to handle. Like when you only want text displayed, and not the close icon.

jQuery UI: Dialogs and URLs

The jQuery UI dialog widget will display itself automatically when created. That is, unless you set the autoOpen option to false. Developers can choose the approach to take in how dialogs are created, and subsequently opened. For example, the default mode let's us work with short-lived dialog widgets. They're displayed when instantiated, destroyed when closed. This life-cycle works fine for the most part and is very resource-friendly. The alternative is to created your dialog widgets upfront, and simply call the open() and close() methods. What's common to both approaches is that they're reacting to some using event. It could be something has finished loading, or the more common case, the user has clicked something can in response, we want a dialog displayed. What about responding to URL changes?

Position Dialog Based On Click Events

With the jQuery UI dialog component, you can specify where you would like it positioned, when opened. For example, in the call to create the dialog instance, you might pass the position option. By default, the dialog opens automatically, and so if you need the default position changed, you have to specify the custom position when the widget is first instantiated.

jQuery UI: Quick and Dirty Dailog Bar

A task bar in traditional Windows environments are where inactive widgets go. It's a good idea, if you have several dialogs used by your application, and no consistent place to put them all, to have just such a task bar in place. This is where the inactive windows go — all in one place, and easy for the user to find. Enterprise-grade JavaScript widget kits offer such task bar components, but they're not found in jQuery UI. So, let's extend the base widget and implement a quick and dirty dialog bar.

jQuery UI: Parameters in Dialog Callbacks

The dialog buttons object allows you to configure action buttons to be displayed in the bottom pane. It's a simple configuration, as it's just an object. The key is the button label and the value is the callback function for click events. We can create as many of these buttons as we like. Typically, we pass the dialog button configuration object to the widget when it's being created. However, we can pass in the button configuration at a later time, after the dialog has been created. Possibly after it's already being displayed for the user. This configuration is handy, but not without it's limitations. Chief among them, configuring the callback functions themselves.

When To Use Dialog Widgets

Dialog widgets are handy, but only to dig you out of a whole in terms of available space. What they're not so good for is displaying resources. That is, the a given web application is probably made up of hundreds, or thousands, or hundreds of thousands of resources. We definitely don't want the default mode of interaction with the user to be through a dialog widget. Why? They're not designed for such a purpose. This is why we already have a browser window, for each one of the resources in your application. A resource has a URI, or it should anyway, and the user presses a button, clicks a link, or triggers some other event that changes this URI. This is fundamental web behavior, and the dialog widget, when misused, disrupts that behavior.

Disabling jQuery UI Dialogs

jQuery UI dialogs aid in gathering input from the user.  Dialogs jump out from page, usually in response to some user-triggered event such as a button click.  When a dialog is displayed, the page layout — that is, the way the page looked before the dialog was displayed — remains unchanged.  It's almost like a secondary browser window, harmonized with the rest of the user interface thanks to the theme framework.

The dialog widget isn't a perfect fit for everyone — some might prefer the approach of displaying forms in-line on the page as opposed to having the form jump out at them.  But aside from individual user preferences, there are a few implementation issues with displaying data in dialog widgets.  Some major API redesign is lined up for the 1.9 version of the dialog widget, aimed at solving some of these imperfections.

One issue I'm interested in seeing worked out is proper disabling of the dialog widget.  Subtle cases, where not having the dialog entirely disabled, cause some weird side-effects.  And then there are not so subtle breakages where we need to fetch remote data.

Forms and remote data
Forms wouldn't be vary useful in the context of web applications if they didn't somehow interact with the server.  For example, submitting a forms often means dispatching a POST HTTP request from the browser to the application server, resulting in a new resource.  Sending data to the server is one avenue to interacting with remote data — but the user who submitted the form will need feedback — how else will they know if the action succeeded or not?

The response generated from the form submission should be presented to the user.  More often than not, the user will have made an error in one or more fields, so the user interface will need to convey this.  The error message — or error messages — typically go beside the errant field.

Dialog widgets that display forms to users have another potential use for remote application data and that is the form itself.  Imagine a user clicks a registration button, located on the homepage, which then displays the form in a dialog widget.  Now, imagine that this website has several other public informational pages that do not require a login, but nonetheless, we still to display the registration button on these pages.  The registration form is the same on all pages.

So where does the dialog widget get the actual markup for this form?  The jQuery UI dialog widget uses a div element as it's template — whatever is inside the div is displayed when the dialog is opened.  This means that we'll have to insert the form markup on every page where the registration button is present.  A solution to avoid duplicate registration forms is to make an Ajax call when the button is clicked.  Instead of just opening the dialog, we'll populate the div with remote data first — this way we're only duplicating the URI pointing to the form on each page instead of the form itself.

Three methods in which the form displayed inside a jQuery UI dialog can communicate with the application server — through submitting data, through receiving responses, and through loading the initial form.  On their own, the methods aren't difficult to comprehend and implement, but latency and usability are always a concern.  An Ajax-based form can take on several states when presented inside a dialog, some of which require the form be disabled.

Disabling form elements
There comes a point, during the communication from the form to the application server, where it'll need to be disabled.  Disabling means giving the user a visual cue that the element is temporarily paralyzed.  Also, disabled widgets shouldn't respond to user events.

For example, let's say the user has just opened up a registration form inside a dialog widget.  Before it can be displayed, we need to retrieve the actual form HTML and insert it into the dialog.  In the mean time, while the HTTP request is happening in the background, there isn't anything for the user to see — there is nothing to display in the dialog yet.  If we defer displaying the dialog until the form is ready, it appears to the user as though nothing has happened yet — sluggish responses are discouraging.

Display the dialog in a disabled state while the form loads.

What about when the user has actually submitted form data and is awaiting the result?  We could hide the dialog entirely while the Ajax response churns.  But this is clumsy as there is high probability of having to display the form again for the user to correct errors.  It seems the logical solution is to keep the dialog visible, but disabled, just while processing happens.  This is a friendly way, a responsive way, to indicate that stuff is happening.

Simple solution to a difficult problem
There are scenarios when using jQuery UI dialog widgets where it makes sense to disable it.  Especially when dealing with forms as mentioned above.  Sending and receiving remote data while the dialog is open means users can interact with it — unless it's properly disabled.  However, while data is being transferred — from the browser to the server — or vice versa — there is a short latency duration.

Ajax-style applications cannot avoid latency during HTTP requests that take place in the background.  Or, at least they cannot work under the assumption that the network response time will be faster than user actions.  Preventing the user from performing certain actions is easy — it becomes difficult when we take into account the perceived responsiveness of the user interface.  There is a delicate balance between ensuring correct behavior while remaining intuitive.

The solution to this problem, as we'll see in the 1.9 release of the jQuery UI dialog widget is to place a div element over top of the dialog, preventing the user from making changes during background processing.  The best part about this enhancement, however, is that there is now a simple API for the dialog widget that'll make it disabled.  This greatly simplifies many usage scenarios where we're waiting on the application server — we can simply disable the dialog and re-enable it instead of stringing together a boisterous solution.

jQuery UI Dialog Buttons

The jQuery UI javascript toolkit provides UI developers with a nice dialog widget. The dialog widget inside web application user interfaces is a great way to achieve optimal use of the space provided. These dialog widgets can be configured with dialog action buttons. These are automatically-generated buttons that are placed at the footer of the dialog when it is displayed. This is the preferred method of displaying buttons in the jQuery UI dialogs as they look more like part of the dialog than something that was placed inside the dialog.

The button configuration for the jQuery UI dialog widget is specified as a javascript object containing all the buttons to be displayed in the dialog. Each attribute of the object maps to the text displayed inside each dialog button. The value of these attributes are the callbacks that are executed when the button is clicked.

However, there are a few problems to this approach. Firstly, the text of these buttons is difficult to update without replacing the entire button set. This is not only computationally expensive, but is also not an ideal way to couple code since the same operation has two responsibilities. Updating the dialog button text of a particular button and replacing all buttons entirely should be two distinct operations. Secondly, this also relates to the first problem, the dialog buttons cannot be uniquely identified easily.

A better configuration format might be to specify a DOM ID for each button in the main button configuration object. So the button would then have a unique handle. Underneath each DOM button ID would be another object specifying the button label and the button callback event.