Do good UX guidelines exist against little JS windows inside the browser

Question

I encounter a lot of web applications that essentially implement a small windowing system inside the browser. On you web page there exist a number of little boxes that look like windows, which can be moved, re-sized, closed, etc. In almost every situation I have seen, this is a very bad idea which violates many of the design principles talked about on this site. For example:

• You can open a little window on some information, but you can't bookmark it to return later
• It usually violates the "don't break my back button" rule.
• You can't use standard browser tabs with these applications. Open in new window/tab never works.
• You can't open different parts of the application on different monitors. It all needs to exist in a single rectangular area which might be stretched to be bigger than all the monitors, but this is a huge inconvenience.
• These little windows never work as well as browser tabs, and don't mix well with other applications

This is just a sample list -- I have not done any in-depth study of the problem. Are there serious guidelines that make it clear that this sort of thing is a really bad idea? Or am I mistaken, and there really are good reasons for doing things this way?

The problem as I see it, is that this sort of UI looks very good to the people who purchase applications for companies to use. Use of Flash or HTML5 to make little windows that can be moved around that page gives the superficial feeling that it is a good GUI. There usually nice graphics, and it has a polished look. But ... the usability sucks when you actually have to use it.

I think it would be far better to implement with a REST approach that uses real browser windows/tabs instead of the little JavaScript imitation windows. One the applications uses a flash based UI that displays the working form as a pop-up windowlet on top of other information which is no longer relevant to using this form. Most of the time in the application is spent in a pop-up form. And there is no way to bookmark or refer anyone to it ... you always have to enter the root of the application and browse your way back to that particular document. Is there a good resource for explaining to people the problems with this kind of user experience?

Answer 1

As a writer of money making, monopolistic, don't care about the UX, enterprise software ;-) I have to say that AgilePro asks some valid questions here.

In my view, there are limited cases where creating a js windowing system could give the user a better experience. But some background first.

When we choose the browser as client for our applications, we are in many respects stretching the limits for what the browser is designed for. In many ways still a one-process-at-the-time experience, and as such, the browser is doing a very good job indeed. However, as an application framework, it stinks.

The one-page-app with multiple smaller js windows inside, can work well for small apps, but for "larger", monopolistic, money making, I-got-the-users-by-their-balls applications, it does not :D . The user feels trapped.

There has also been quite a few projects for "building the new OS on the web" which have tried this approach. I liked the idea at first, before trying, but I think most have gone away by now.

If you use the browser "for what it was designed to do", your enterprise application UX will most likely be well behaved, back-button compatible, single process, have no errors, and will drive your users absolutely crazy. Why? because you get no overview, no multiple windows, no multi-processes, no modal dialogs (that work), and you cannot start a new process for something related, or unrelated, without the risk of loosing state in previous window(s).

A professional user has to accomplish many tasks AT THE SAME TIME, clearly this is not the forte of modern browser design. But, am I whining? I hope not. We choose the browser as client because it solves two major problems for us, cost and distribution. Basically they are free and everywhere. The downside, they are not designed for what we are trying to do with them.

Conclusion:

• limited one-page-apps can work great, but only for smaller applications
• for larger applications, if you can afford it, if you want full control, if you are totally crazy, write your own client.
• in all other cases use the browser and prepare for being frustrated and realize that whatever you design now, will absolutely not work on a browser a couple of years forward

Hope this does not throw you off, after all, if it was easy, we would not have our jobs. =)

Answer 2

The JS windows that are triggered should be used only for transactional items like Single-Sign-On or getting approval from the user. It should be used to display information or knowledge share as a transactional state. REST based approach can be adopted but it greatly depends on the amount that the project plans to invest. Such dependent factors also affect UX - designing with technical constraints. Also this is not just limited to explicit JS windows, rather JS modal box implementation too.

Answer 3

Luckily not! or why would recommend not to make use of well established ui elements like tabs or floating windows? You can't really use bad implementations as reference to roll such guide-lines.

Because if you would prevent tabs or floating windows, you are just adding much more inconvenience for your users. And opening real browser tabs? Really?

So finally; don't work against such things; just wait developers could catch up with all the neat old-school in web-2.

Please also don't forget; browsers make it actually pretty hard for this kind of applications. Classic keyboard strokes (changing tabs) for instances are often not overridable.

ps: I am developing web based IDEs since years now and I must admit its really a big challenge to restore a user's last state (window layout, positions) but nevertheless, all those problems I could solve over a long time(including all your points). As reward I could even manage to overcome weaknesses of web-based technologies and improve them over their 'native' counterpart, reaching also the ultimate status-quo on web-ux.

g