8

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?

Improve this question
9
  • 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 '14 at 3:11
  • 2
    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 '14 at 4:00
  • 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 '14 at 4:36
  • 1
    @DA01 - Many enterprise apps support business functions that are data-intensive and repetitious by nature. I have seen users refuse to use the "prettiest" ones because it took them twice as long to get their work done. If I was going to invest in a dedicated UX person for an enterprise app I would make damn sure they had experience in that specific niche, because I have seen the results otherwise. – Stephen Jan 5 '15 at 21:35
  • 1
    @Stephen we're not talking about 'pretty' but general usability and UX. If it takes them twice as long to do something, that would not be a UX improvement obviously. If we're talking about products like PeopleSoft, however, that's just plain sloppy UI in general. – DA01 Jan 5 '15 at 22:03
2

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

Improve this answer
2
  • 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? – Graham Herrli Oct 7 '14 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 '14 at 22:15
0

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.

Improve this answer
2
  • 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 '14 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 '14 at 22:41
0

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

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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