Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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?

share|improve this question
    
Maybe when you've dealt with the various popup blocker issues associated with opening new browser windows with JS, you might not be quite so eager to base a lot of your UI on opening new windows. –  jfriend00 May 21 at 3:11
    
Sounds like you're talking about enterprise software along the lines of PeopleSoft and the like. The reality is that these are products that make a lot of money without having to care about UX. As such, they pretty much don't care about UX. –  DA01 May 21 at 4:00
    
@DA01 - yes exactly, their business model is not sensitive to usability, however I believe they would aim for better usability if the data was there. jfriend00 - no, this is nothing to do with popup blockers, or with a UI that proactively opens windows. Bookmarking has nothing to do with popup, and "open in a new window" is a user option, not something forced on you. –  AgilePro May 21 at 4:24
1  
I don't know that they would. They are essentially monopolies and if they're making money despite the UX, there is sadly no strong incentive for them to care about the UX. The problem is that the people that buy these huge software products are rarely the people that actually have to use, maintain, or develop on them. –  DA01 May 21 at 4:36
    
OK, maybe there is no saving the monopolies -- but I see lots of small development and custom applications taking the same approach. Also had experience with a Indian development team that insisted on taking this approach because it was considered to be a proper GUI approach. They had learned GUI guidelines in Visual Basic, and wanted to implement the same thing on the web. Only ... it does not really work as well there. What studies have been done that support this with evidence? –  AgilePro May 21 at 22:47

2 Answers 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.

share|improve this answer
    
When JavaScript pop-up windows are used to display transnational information, they prevent you from view multiple transactions at the same time, from going back to lists of transactions (i.e. break the master detail pattern). They can be used for sign-in, however, even that can be done within the current window/tab in a separate page which returns the user back to the previous page. –  Danny Varod May 21 at 9:52
    
That is what I am thinking: JS windows should follow design rules appropriate for pop-up dialog boxes: the page is context for the work, and sometimes you need to interact with the user without losing the context. e.g. inserting a hyperlink into a document might involve a dialog box for getting the address. However, I am talking about examples that go far beyond pop-up dialog rules: they allow opening multiple document windows, moving, resizing, overlapping, in some cases minimize/restore capability. These look like MDA paradigm ... in a browser. Is there any study of how this is bad idea? –  AgilePro May 21 at 22:41

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. =)

share|improve this answer
    
It's a little hard to tell (because your post is a bit of a rant), but I don't think you're addressing the OPs question. The OP asks whether smaller windows should be displayed within a browser whereas your post appears mainly to be about "using the browser as a client for our applications." The OP's question is about an interface element, while your answer appears to be about the much larger issue of what it's appropriate to display in browsers. Have I misinterpreted something? –  3nafish Oct 7 at 15:51
    
3nafish is right. I am assuming "cloud software" which is fairly well at home on the web in general, but focus on the UI/UX decision to make little JS windows inside the browser, as opposed to simply spawning windows/tabs. GMail and Google Maps are good examples: no little JS windows, I can link to anything I see, and I can have as many instance windows open as I want. Some designers choose to do this in JS windows ... and I personally find it far less effective with the exact same functionality. –  AgilePro Oct 8 at 22:15

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.