Selecting Real-Time UI Messages

Displaying notifications in the user interface is an essential feedback mechanism. They inform the user that something of interest has happened. A virtual machine that belongs to them, and one of the disks is no longer accessible. The user might want to know about something like this as it could pose a serious threat to their business. Imagine this type of thing happening and we get notified by the guest operating system when we try to write to the missing disk. Better to let the user know as soon as something like this happens, using appropriate messages, perhaps even guiding their next course of action. The problem with this type of notification is that the user didn't trigger it. It was triggered triggered by the autonomous background behavior of the system. And so, displaying these types of notifications indiscriminately could pose a problem. The UI needs to select which messages to display.

User Interfaces and Logging

The browser history takes on a new reputation in light of modern web application development. It seems that the browser history — the navigation capability of web browsers used to traverse web 1.0 — can either help, or just get in the way. The browser history might get in the way if you're striving for the complete desktop experience in your UI. This is where the back button is viewed as a hindrance, something antiquated that our code must be prepared to handle but offers no practical usability. On the other hand, the browser history is something that the web grew up with. It's as natural as HTTP or HTML in a web application. The web is supposed to be stateless. The URI a user visits inside an application shouldn't care about order. Regardless of what patterns your web application follows, the user interface needs to communicate and change state. With modern Javascript toolkits, the state of the user interface itself is becoming more and more detached from the state of the server-side resource.

Encoding Context In Links

A page in a web application shows formatted objects, menus, or things that pertain directly to the application domain. Like lists of objects from the database, or a single object, selected from the database and presented to the user. Lists of objects, or a single object, are part of the link the user has clicked, or pasted into the browser address bar. No matter actually, it's the notion uniform resource identification — the mechanism realizing this idea is secondary. The goal is that the link text identifies a resource within the application. But is that the extent of the information encoded into a single URI? Or do applications, as they become more sophisticated from a user interface perspective, need to provide context to the pages that render these URIs?

What Users Don't Know About Layout

Does it sometimes feel as though you're playing with a Rubik's cube when interacting with certain interfaces? At times, it can feel as though I can do more harm than good with the ten thousand layout-tweaking controls presented to me. Sometimes, these layout tools are in fact widgets themselves, occupying a seemingly small portion of the application space. They're not hidden away under the cover of the "advanced, break in case of emergency" section of the settings page. But I don't understand the layout of your application, so how would I even begin to go about fixing it? And does it even need fixing? Maybe it only matters if the application has gone out of its way to provide the ultimate in customization.

Navigation and Object URIs

How do we go about designing a web application that does well with both the navigational structure presented to the user, and the URI format used to traverse the application? They really are distinct problems, are they not? If so, I find that I've artificially blended the two concepts together. Maybe that's because, as a user, I've unintentionally joined the two ideas. After all, they both play a role in the same job. They take the user from one place to another. One from presents a graphical layout to the user, often with styled elements using some kind of grid layout. The other, is just a string destined for the browser address bar. An action in the navigational menu often means a change in the URI. The change is triggered from the user interface, and I would think that this is the expected pattern of behavior, as opposed to the user constantly typing in the desired location — unless the menu is really that bad.

Critical Input Error

Is there such thing as degree of incorrectness when it comes to user-supplied data? As in, you forgot your email address...we kinda need that. Is that a critical error? Is it an every day occurrence that we can expect as user interface developers? Perhaps, we need to design into the experience, and into the data ultimately consumed by the software, the fact that we'll get it wrong. Often. But how do you deal with the paradox of missing data? You can only provide so many friendly messages and so much hand-holding before your software languishes due to data starvation.

There's A Web Page For that

Yep, there's a web page for that, a ton of them. The one thing you need, a currency calculator, a CSS generator, there are probably five different web pages fit for the job. How useful are these web pages on mobile devices? It seems that applications native to the mobile hardware replace the browser entirely. These apps don't work everywhere - you don't see the same code running on iPad, Android, and BlackBerry. Each application that runs on a phone, if you can still get away with calling it a phone, is tailored to the hardware. Is this really a big deal to the user? Is the device-specific experience really that much better than something running in the browser? Currently, yes. Web stuff for mobile doesn't quite make the grade comparatively. No, there isn't always a mobile web page for that. But there will be.

What are web pages for? Information, of course. Well, I'd say the vast majority of web pages are about sending a message to an audience. However, plenty of web sites are currently transforming their content - or at least thinking about it - into something that's more like the desktop application experience. This is what users want, and so us software creators must have a pretty good reason to not deliver.

Why the change? Our websites never used to have trouble engaging with users. Why all the fuss over user admonition? The short answer is because we can. If a company selling widgets has an opportunity to hear the assessments of current and prospective customers, they'll take it. In fact, they're going to encourage users to submit any feedback. There is no such thing as a customer giving bad information to a company about their product. I mean, yes, there will be the odd loudmouth who does nothing but criticize, but this is nothing new. We've got to deal with those types even if we don't operate on the web.

We've got a bidirectional channel for businesses – much more effective than television. Rather than pushing out information, hoping people are watching, it's always available your clients seek it. If you want immediate feedback, provide your consumers with the appropriate tools.

Applications that don't utilize the web as a data repository aren't modern in any sense. We need applications that access the web, otherwise, users can't provide their feedback. We'd be crazy not to, right? If an online store, selling say, music, isn't hearing about each customer's unique experience, why might that be? Maybe they simply don't feel enticed to respond, probably because it takes more effort than it's worth. The question is, how to we make these feedback tools seamless to the point of being irresistible to the viewer? This is interesting to think about, especially in a mobile context where things suddenly aren't so straightforward.

Web pages aren't universal. Not anymore. We're really good at building just about any kind of application for the web, just as long as you build it for desktop and laptop browsers. Even some tablets do a decent enough job of displaying your retro backwardness that is 1.0. The rest of your users don't have the luxury of a larger display. To them, viewing pages on your site is like trying to plot a route on a map while looking through a magnifying glass pressed against it. It's a little unpleasant.

How do these web pages become a little more tolerable for the mobile audience? After all, we want to capture everything they're willing to tell us – we've got to make this as simple as possible. The answer in the mobile domain is apps. Users love their devices, and filling them with software amends their utility. What good is a smart phone without hundreds of applications installed? It isn't actually easier for users to interact with your mobile application, relative to your mobile web page that does the same thing. The application, once installed, feels like part of the device. That might seem too obvious, all software controls the hardware. This is no different from software installed on our desktop computers – new software extends the capabilities of the hardware. And since its installed locally, we've just expanded the capability of our hardware. There is something about the intuitiveness of desktop software. This is where mobile applications have an edge – they truly become one with the device for which they're built.

Why can't web applications do the same? Why can't they mesh well with the hardware they're delivered to? They can, and do. The trouble is that there simply isn't enough of them. There is a strong argument for developers to build web user interfaces for mobile users. Its the same argument for building web applications for desktop users – supporting several platforms is a major headache. Supporting multiple desktop platforms and multiple mobile platforms is simply out of the question for most folks. We've got to overcome the obstacle of unfamiliarity. Users want to install things, they want a level of assurance, knowing the tool will reliably get the job done.

The question is, can we give users this same level of comfort, the intuitive feeling that the web user interface is somehow part of the device. I think so. As long as they're able to launch it as they would any other native application. A little icon, part of a start-up menu, whatever the environment dictates, it just needs to mesh well.

Over time, I'd say over the next few years, we'll see web user interfaces become the standard. Apps won't go away entirely, there will always be a need for something specialized that no browser can support. However, the roles will shift – the browser will become the default user interface environment, desktop software the fallback. So yes, it's important that users feel comfortable using their software no matter the device. Software that's intuitive always comes out on top. As little as five years ago, web applications for the desktop weren't anywhere close to native desktop applications. All that's changed now – there is still a need for specialized desktop applications, but browser-based user interfaces are the first choice for a lot of developers now. I think this same transformation will happen with the mobile market sooner rather than later.

Stateless User Interfaces

Is there such a thing as a user interface with no states? Normally, they have dozens of states, several of which may be active at any given moment. Envisage launching a program. You, the user, are given a starting point. This is the initial state of the user interface. From here onward, the changes in state are triggered by user input. Large programs, with many user interface elements, have numerous potential states while smaller programs might only have a handful. Desktop GUI applications are fundamentally different from web applications, including how different states are maintained. Is one ideal more complex than the other?

The visual elements of a user interface are called widgets. Widgets are the basic building blocks - larger widgets are composed of smaller ones. For example, a button is a widget. So is an input field. Both can be in one state or another. A text input widget can be in a focused state. This is what happens when the user clicks inside the widget. It changes state. Prior to being in a focused state, the text input must have been in another state. Probably a normal state. Another distinctive state found in the text input is when the user is actively typing. This puts the widget into a composite state since it must also be focused in order to type in it. The state of any user interface is the sum of all the widget states. This is a complex configuration.

Can a user interface exist without being in one state or another? An HTML page is an example of a stateless user interface. This is counterintuitive given that they contain widgets. Consider an input field. Does this widget have have any states in an HTML page? HTML widgets do have states but they are of no concern to the application. Only the browser. In a desktop application, widgets are created with a programming language. HTML is a markup language. Widgets created using a programming language have much greater control over the potential states of a widget.

For example, a desktop application might create an input widget. In addition to the basic construction parameters, id, default value, and so forth, an event handler might be set. The event handler is executed when the widget enters some state, like a hover state. Events are often triggered by changes in state. The event handler can do whatever the programmer deems appropriate. This flexibility exists in programming languages, not in markup languages.

If Javascript is considered a programming language, can widgets in an HTML page have states? Indeed, this is the intent of Javascript - when a widget changes state, a function can execute. Javascript libraries provide their own widgets that build on those found in HTML. These abstract widgets also have states. The goal of these custom widgets, and Javascript in general, is to make web pages look and feel more like desktop applications. So why is it that desktop applications feel better in comparison to HTML pages? CSS can add styles to a page that captivate the user. They can also destroy the whole user experience. Web pages with HTML and CSS that are done right can surpass the feel of some desktop applications.

A desktop application uses a single programming language and widget library. The developer has to consciously separate the logic from the presentation. A web application also uses a single programming language but places the presentation in a markup language. Here, the developer also needs to consciously separate the presentation from logic. But HTML is naturally separated from the application logic because it is a presentation language. A web application that uses a programming language for logic and a markup language for presentation is easy to understand because of this. Adding Javascript on top of the presentation means adding state to the page and isn't so easy to understand.

Stateless user interfaces aren't necessarily better than user interfaces with states. They have less complexity. The challenge, is to create something that looks good and is maintainable. Javascript, especially asynchronous HTTP stuff, lowers maintainability. Desktop applications are meant to have different user interface states that the programmer can use and react to. Javascript adds state to something that is supposed to be static. If the level of user interactivity is important, if you need to handle complex user interface state configurations, consider building a desktop application instead.

jQueryUI Hovering

The jQueryUI user interface library offers developers building interactive web applications not only a set of widgets to use, but also, a set of effects. An effect, in this context, can be thought of as a transition from one state to another by a user interface component. As an example, imagine you have a button element that is in a hidden state. Showing that button would be considered an effect, albeit, a very basic one. A jQueryUI effect adds some appeal to these transitions. In essence, jQueryUI effects can be thought of as user interface component state transitions that enhance the overall user experience.

Another nice feature in the jQueryUI repertoire is the CSS framework used for changing the look and feel of the widget set. This framework allows developers to choose an existing theme or to build their own. CSS classes within the framework are flexible enough that they aren't restricted to the jQueryUI widgets. Your user interface isn't going to be composed entirely of widgets. You can use these CSS classes to help give the non-widget elements of your application more of a theme.

An example use of applying the jQueryUI CSS framework to a non-widget element would be using the ui-state-hover class. Lets say we have a list of li elements. The idea is to add the ui-state-hover CSS class to each li element when the user hovers over it. This is fairly straightforward to do with the jQuery addClass() and removeClass() methods. You call these methods inside a hover in and a hover out callback respectively. Example callback functions are shown below.

function hoverin(element){
 jQuery(element).addClass("ui-state-hover");
}

function hoverout(element){
 jQuery(element).removeClass("ui-state-hover");
}

jQueryUI allows us to add an interaction to the addClass() and removeClass() methods. Typically, we would only want to add an effect to the addClass() for hover in events. Otherwise, the user interface tends to look too busy. Here is the same example modified to introduce an effect when adding the class. The the visual changes made to the element as a result of adding the class will take place over a duration of 150 milliseconds rather than instantaneously.

function hoverin(element){
  jQuery(element).addClass("ui-state-hover", 150);
}

function hoverout(element){
  jQuery(element).removeClass("ui-state-hover");
}

There is, however, one problem with this approach. There is a chance that the ui-state-hover class will not be removed from the element by hoverout(). This is because the user can, and most definitely will at some point, hover out of the element during the 150 millisecond effect duration. Keep in mind, the element doesn't actually have the ui-state-hover class until the 150 millisecond effect duration is up. When hoverout() is called during the effect, no class is removed because it hasn't been added yet. Below is a work-around for this issue that involves using a secondary state class.

function hoverin(element){
   jQuery(element).addClass("app-state-hover");
   jQuery(element).addClass("ui-state-hover", 150, function(){
       if(!jQuery(element).hasClass("app-state-hover")){
           jQuery(element).removeClass("ui-state-hover");
       }
       jQuery(query).removeClass("app-state-hover");
   });
}

function hoverout(element){
   jQuery(element).removeClass("ui-state-hover app-state-hover");
}

Here we introduce a new class called app-hover-state. This class will be used to track the hover state of the element since we are now using an effect. The hoverin() function will now add this class to the element before starting the visual effect. The hoverout() function will now remove both the ui-state-hover and the app-state-hover classes. This is important because even if the effect hasn't yet finished when the user hovers out of the element, the app-state-hover class will be removed from the element. The visual effect in hoverin() now has a callback function that is executed when the duration of the effect has completed. This callback will remove the ui-state-hover class if the app-state-hover class has been removed. In this case, if app-state-hover has been removed can only mean one thing; a hoverout() call was made during the duration of the effect and the ui-state-hover class should also be removed.

jQueryUI Dev Tool

The jQueryUI library is a themable user interface library. As such, all themes are CSS based and can be interchanged within the same application. The jQueryUI dev tool is a simple bookmark you can use to develop your own themes or to see how your application will look with an already existing theme. There are plenty to choose from. What makes this to interesting is that this tool works well even for production systems.

Flash And HTML

Is there really a war between Flash and HTML? Not according to John Dowdell. He claims that Adobe is all about enabling creativity by providing the platforms in which to do so.

War or no war (there really isn't one), Flash is here to stay for the time being. I for one try to avoid it when building web applications. But that stems back to when you might actually have to install Flash on a browser in order for your user interface to even work. These days, you are less likely to find a browser that doesn't have Flash installed on it.

Don't get over excited about the future of whether or not the web browser experience is going to belong to Adobe. The fact is that they already own a big chunk of it. Just keep that thought on the back-burner.

jQuery Custom Events

One of the more powerful features of the jQuery javascript toolkit is the ability to create custom event types. In addition to the built-in events that are triggered by standard DOM elements, developers have the ability to create custom events. These events that are defined by developers using jQuery are not all that different from the standard DOM events. The main difference being that the developers can have control over the event data and when they are triggered.

The custom jQuery events can be created using the jQuery.Event() function. The one required parameter of this function is the event name. The instance of the custom event is returned. Another parameter that might be passed to the function is an object that contains the event data. However, an event instance created by jQuery.Event() can also have attributes set on it directly. Either way, these values will be passed along with the event once it has been triggered.

Event driven programming is a very useful model. Especially when the application is user interface centric. Here, the application consists almost exclusively of events. The user does something, some event is fired and some handler acts accordingly. With javascript applications, there is also the prospect of triggering events when data arrives from some API request. In fact, without an event to notify the application that the data has arrived, the application would be considered synchronous and would not respond well to user interaction.

Custom javascript events created by developers can be broadcast across the entire application or sent as a signal to a specific DOM element. The more useful method is to broadcast the event because it allows any application component to subscribe to the event. This offers flexibility and reduces the amount of code needed to accomplish a specific task.

Busy User Interfaces

There are good user interfaces and there are bad user interfaces. It is hard for users to explain what they like about the good user interfaces. They are just good. Designers who create these user interfaces often know when they've built something that is, just, good.

It is easier to talk about what makes bad user interfaces bad. Some, are just plain ugly. There are zero visually appealing aesthetics about it. This is becoming a less frequently encountered issue though because CSS makes theming applications much easier. The colors and shapes and general layout can start off right, and be made into something bad.

User interfaces transform from something good into something bad usually because of over population. It simply looks too busy. The naturalness of the interface is overshadowed be features. And many of these features probably aren't even needed.

However, eliminating features simply isn't practical, or even possible, in most cases. So all the user interface designer can do in these circumstances is migrate the overpopulated visual elements somewhere else. The current page, the one that is too busy, can often benefit from containers. It is an easy way to hide things that add to the current chaos.

A popular container type is a tab. They are a very intuitive construct for the end user and are easy for the designer to make look good. One still must be careful when using tabs though because they can also be overpopulated. The last thing anyone wants to see are two dozen horizontal tabs across the screen. Another thing to watch out for are sub-tabs, tabs within tabs. Try to avoid these wherever possible as they are hard to get right.

There is a balance between the total number of container elements and the total number of elements within the container. Too many of either will most definitely yield a bad user interface. But if the designer can strike the best balance possible while maintaining the visual appeal, that is when it is time to start talking about removing unneeded features.

Django Form Fields

The Django Python web application framework comes with almost every component that one might need to construct a full-featured application. One common component of web applications are widgets. Widgets are similarly defined in most desktop GUI libraries. A widget is simply a smaller part of the GUI whole. Widgets typically have a tightly defined concept and purpose. For example, a button widget is meant to be clicked. Also, a button widget is also meant to be visually striking enough that it is obvious that it is meant to be clicked. Django comes with a set of widgets that are featured in almost every web application in one way or another.

Web applications generally contain forms. Nobody has gotten away with using the web without having to fill out a form at some point. The pieces of these forms are often referred to as fields. This is from a data or domain perspective. When talking about a field, you are generally talking about what data that field contains, how that data is validated and so on. When talking about widgets in a form, you are generally talking about the visual aspect, like what can this widget do and how does it look when it does it.

Django provides abstractions within the framework for both of these concepts. The two concepts are closely related and thus tightly coupled. In this particular situation, tight coupling is absolutely necessary. You can't have a field without a widget and vice-versa. The alternative would be to implement all the field functionality inside the widget abstraction which would give us something bloated and hard to understand. Modularity is a good thing even when tight coupling is necessary. The two classes representing these concepts are Widget and Field. The two classes and how they are related to one another are illustrated below.

Open Source Quality

In an interesting entry over at PC world, they mention a study that shows an overall decrease in defective open source software. Over the past three years, defects in open source software are down. This is great news, even if not entirely accurate, because I doubt the study is so flawed that there are more defects in open source software today. Every day, new open source projects poof into existence. How can all the complexities of the open source ecosystem be reliably measured? The truth is that they cannot. But some larger open source projects are much more popular than others and have been deployed in production environments. These are the interesting projects to monitor for defects because chances are, when a defect is fixed in one large project, that same defect will be fixed in countless others due to the dependency.

What I find interesting is the willingness to study and publish the results of code quality. To most users, even some developers, the code quality isn't that high on the requirement list for using the software. They don't see the code. Even most developers only see the API, and, arguably, that is all they should have to see. The code quality does effect more than just maintainability.

This brings up another question. Does the improved code quality improve the perceived used experience? Not likely, in most cases. But in some, yes. Even if it isn't obvious to the developers who fix a bug that wouldn't have any apparent effect on usability. Looking at these subtle usability enhancements in the aggregate might be interesting.

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.

Release Early, Release Often, Break The Interface

Release early, release often. The credo of open source software development in most cases. This didn't become the case simply because open source developers enjoy the task of doing project releases. In fact, this task is often burdensome, especially for projects with many components. This open source development philosophy became so common because it works. The idea behind releasing early and releasing often is to generate early feedback from the user community. This feedback is invaluable to developers and user interface designers alike. But why does it matter if the feedback is early? Does the feedback lose something if it comes much later after the software has been released? I think it certainly does. Although feedback regarding any open source project is valuable at any time during the development life cycle, the earlier this feedback is received, the lesser the likelihood of the concerns being pushed back. That is, if a given open source software project is released one week and users of this software express their concerns the following week, it is likely that these concerns will be addressed in the following release.

This entry raises an interesting usability problem with open source software projects. That is, users of sloppy, or, disorganized user interfaces get used to it. They simply accept the fact that this is the way the user interface is and is unlikely to change. The entry is slightly dated, although, unfortunately, the problem persists in many modern day open source software projects. So the glaringly obvious question is, how is something like this fixed? Aren't there countless usability experts out there that can design beautiful user interfaces? Surely some of these experts are willing to work on some of these open source projects that lack in the usability arena? The answer would be yes, there exists extraordinary usability talent in the open source community but as the entry suggests, there are different pressures face in open source projects than in the proprietary counterparts.

So what do these projects do with the user interfaces that lack in usability? They leave it up to the end user to figure out how they want the user interface to look by adding an endless stream of user preferences. These preferences allow the users to turn off undesired behavior. I say this is an endless stream because once one user interface preference is added, it is hard not to add more preferences of other user interface components. Additionally, this leads to a recursive user interface design problem because of the need to maintain these preferences. Again, as the entry suggests, this can become quite the mess to maintain because users of the software can quite easily grow accustomed to these "patch" type settings.

So what is the solution to this problem? Unfortunately, I do not have a solid answer as I'm no usability expert. However, reducing the number of moving parts on any user interface is always a good idea. I find the "less is more" principle invaluable in regards to user interface design. When it comes to user interface preferences that have been put in place for the end user to customize the "look and feel", they are most likely to hide components that clutter the user interface. Developers shouldn't take the decision to add new preference or configuration values lightly. Once added, new configuration options should be there to stay. When adding a new preference that allows end users to hide a given user interface component, think long and hard about the necessity of the component in question.

User interface testing

Although there are several tools available today that enable the automation us user interface unit testing, they are not ready to use as the only testing procedure of any given application.

There are several issues that these tools fail to catch. Mainly, the work flow errors. Your application could pass the GUI testing framework with flying colors and yet, once your application is human-accessible, it fails colossally. This is because the slightest misinterpretation by the testing framework as to what the work flow should look like (work flow in this context is the sequence of user interface actions, not application logic). This is not to say that the user interface testing frameworks are not capable of fully automating the interface testing, it is a question of effort involved. A simple user interface validation test done by a human may take an hour to perform where designing a test may take much longer.

In the long run is it worth it? Maybe. If your application is user interface centric (some would argue that all applications be designed using the interface as a starting point), it might make sense. In this case, the user interface designers will most likely be designated to this task. They will not likely care about application work flow.

What if you are in a situation where the user interface takes a "back seat" to other "more important" tasks? Well, this is bound to happen. After all, a user interface with no application behind it isn't terribly useful. Perhaps what is needed here is two sets of use cases. One for the application, which is independent of how external actors interact with the system. And, one for the user interface that describes the interface cases in much detail while keeping the application cases vague.