Message boxes and Inline messages Pt1

Mar 7, 02:42 AM

When was the last time you clicked on an alert-box or message box’s ok button? When did you last click on a yes button on a confirm-box? Long time ago, at least for me. What’s good about inline-messaging in the markup? How does it improve the user experience if it does at all, and more are subjects of this article.

Dialogue-Box Models

Dialogue boxes or message/input/confirm boxes are part of the basic webbrowser-user interaction framework. Every webbrowser has it’s own native boxes, icons and colors are different in every browser, however they all do the same thing and are invoked using the same particular function in Javascript.

Diealoges are all Window object methods in Javascript wich result in modal boxes that await input(click, keypress, or value insertion) from the user. We’re talking about the ol’ alert(), confirm(), and prompt() functions.

What happened is, they’re rarely used nowadays with the existense of many other ways of implementing the same interaction with less user abuse and smoother attantion capturing methods such as inline-messaging and smooth/animated modal dialoge boxes(lightbox-gone-wild as an example)

New day, new way: new web

It’s not so new. It’s been there for a long long while, but, it’s time to embrace it to the max; AJaX and DOM are supported more than ever on the major browsers, so that’s why.

On the hype of Web2.0 or the AJaX and weekly project beta pop-ups this new way of interacting with users along with the new ways of gathering data, validating, and data views have somehow evolved and are now fresher, quicker, and most importantly all inline.

Inline, as in next to your error, below the empty form-field, on top of the whole page deeming the rest of the content, and even beside you mouse pointer. All this along with nice little stylings for erroneos elements and messaging elements that make it easier to distinguish.

All this appeals and works for the user because it is done on the same page, most of the people dislike the built-in dialogues and many think there are erros of the page they are on. On the flip side the inline model lacks the beep sound which in most cases will cause users to wait and wait but not hear the beep/ding sound. On a regular desktop application there are APIs specific to every OS that could invoke the beep/ding sound to grab user’s attention, but not with inline messaging on web—no OS APIs available on the browser side.

So which one are you going to use next time developing a web app? Browser based dialoges or your own custom inline messaging solution? Well, that’s up to you. But here’s my take on the decision.

• Use inline-messaging for empty-field errors
  It’s annoying to get a ding/beep with a floating message box telling you that you actualy forgot that it is to be filled
• Inline messaging is good for checking something’s availablity or duplicate check such as domain names or usernames
• Use browser dialoges for Authentication errors and notifications since that kind of information is important to the user, so no one would mind being disturbed for something important
• Credit card validation should never use an inline messaging for confirmation or erroneos notifications, nor for authorization and not even for validation or type checking. Cautions and warnings in general should be shown on browser dialogues showing the seriousness(ugliness) of the situations.

As we end this introductory and breif portion of this argument we will review some of the new techniques used for messaging in some high profile applications and then compare it to the good ol’ browsers dialoges in details. Until then, digest this and let me know what’s your take on it.