Mdi Screens In Web Browsers

Does anyone have any tips on making MDI-style screens in web browsers, especially now that tabbed browsing makes sizing windows nearly impossible without screwy vendor/version-dependent DOM tricks?

For example, suppose I wanted a custom little prompt window to pop up that has 3 items. I don't want to open up an entire window; that looks dumb and makes it hard to see the background window in case we want to copy something from it. It seems GUI's went 2 decades backward.

  -----------------------
  Name: [____________]
  Rank: [____________]
  Serial No: [_______]
  [*OK*] [*Cancel*]
  -----------------------

Seems like MDI is falling out of favor:

http://blogs.adobe.com/acrobat/2008/09/mdi_vs_sdi_in_acrobat.html

However, the ability to somehow display smaller sub-windows from a web app is still desirable.

Wait ... tell me again why a tabbed interface isn't an instance of the MDI concept? OK, my browser won't let me detach a tab to become a self-contained window, but I know both Chrome and Opera do. Certainly, the limitations of a single application (in my case, Firefox) cannot doom the technology to ultimate classification as "not MDI"?

As far as resizing windows goes, well, as far as I'm concerned, your software has zero right to resize any of my browser windows. It's a blanket policy I've developed after watching entirely too many websites use this capability to resize the main browser window to impossibly large dimensions (such that I cannot even drag the window around the screen, since the dragbar is off the screen!), impossibly small dimensions (such that I can't even find it amidst other icons on the display; obviously exploiting a bug in your windowing environment's window manager), or to a geometry fundamentally incompatible with my font settings, such that I cannot even read what the author intends me to read in the first place. Worse still are those sites that insist on resizing the damn web browser window every time it receives a focus-in event. Thankfully, the latter kinds of sites are largely gone now; otherwise, that'd be cause for, umm.., "clarifying" the laws against murder.

You've had your chance, you've abused the technology, and now it's being taken away from you. No whining -- you brought it on yourselves!

Re: "as far as I'm concerned, your software has zero right to resize any of my browser windows."

Do you want browser-sized Yes/No boxes? How about a message that says, "This particular application (or website) prefers re-sizable windows. Do you want to grant it that right? At least let it ask, and you can then refuse and get your browser-sized yes/no prompts.

No. I wouldn't mind a single checkbox allowing that feature in the browser's control panel. But, I will not accept even the opportunity for it to ask.

But most users wouldn't know that they are seeing gimungous dialog boxes because of the settings. And, it's still possible to make such a box via DOM+JS, it's just lots more programming and version risk.

You might consider using inline prompts (like reddit.com or del.icio.us do when deleting a bookmark or performing some action requiring confirmation) in place of modal dialog boxes like the above where you can.

JS libraries like JQuery have plugins to make popup and modal dialog boxes (as scripted divs) relatively easy, and handle the version risk for you.

How can they handle version/vendor risk without predicting the future? DOM/JS interfaces are often risky, crashy, and screwy. It's not a mature technology yet (and MS will further cripple it if it competes with their proprietary crap). GUI idioms that were solid in the mid-90's should be built into the fricken browser by now. Why are we stuck in the mud?

EmbraceAndExtend is why we are stuck in the mud. If you want a page for the argument you're starting, please consider ProgrammingLanguageNeutralGui.

As far as handling version/vendor risk without predicting the future? Well, 'recognizing' the risk is the only act that requires "predicting the future", and there are many ways to "handle" risk. One may avoid it, accept and account for it in one's design, delegate it, or even ignore it (which isn't always a bad strategy). Using a JS library with plugins is (from the user's perspective) a mechanism to delegate risk. You make keeping the plugins up-to-date with any browsers 'someone else's problem'.

First, making one's app depend on a plugin that often needs updating reflects badly on the original designer. It's not fair to "dump" the problem onto somebody else's lap. In many shops installations are locked-down such that people cannot install plugins on their own. They have to call the help desk. Further, updating a plugin may break some existing feature of an app. It's still usually better to stick to regular HTML and live with its annoyances. Or, go with Java or Flash and tell the browser to take a hike.

Then make one's app depend on a plugin that does not "often need updating". Problem solved. Anyhow, you aren't doing anything differently by suggesting Java and Flash. For example, if you use Java, you've simply moved the version/vendor risk to the maintainers of JavaAwt or JavaSwing. This is not fundamentally different from moving the risk to the maintainers of a JavaScript library, though I'll agree you might trust the JavaSwing/JavaAwt guys a bit more than you trust the JQuery guys.

This is one of the myriad problems arising from using a document markup language to create user interfaces. Unfortunately, people want applications accessible from practically any location or device without having to install anything and web apps are currently the best way to provide that. Until we have a widely installed XwindowSystem/NetworkExtensibleWindowSystem for the internet we'll be stuck writing "applications" in HTML & JavaScript, which is about as crazy as writing them in MicrosoftWord & VisualBasicForApplications in my opinion. -- AnonymousDonor

Fully concur; X11 proves impractical, however, because I find it has entirely too much latency over even a fast network connection. NeWS (IIRC) allowed application-specific logic to be downloaded to the display server, assuming the same role as JavaScript code in browsers today. Perhaps it's time to revisit, and perhaps modernize, NeWS.

A tabbed interface using current 'browsers' tabs isn't an MDI, an MDI is something as demonstrated here: www.youtube.com/webrenovators - This is a true MDI written in JavaScript and it is very easy to do. In fact, I have even written a mini version of the framework I wrote for that product in a few hours taking up a few KB only using nothing more than plain jQuery (just because I like the selectors). The particular application does use PHP as a bootstrap and it does have a server component which are webservice based, but the GUI is 100% separate component to that of the server - the server could easily be rewritten in C# or Java with zero impact to the MDI client. And yes, it works on iPhones, iPads and Android devices - in fact the full product works fantastically even installed on Android. I do admit thought that some mobile devices have lower processing power and for that we have the ability to fall back to SDI mode for those devices (just configuration). The framework also handles multiple separate pages as well as single page and it has multi-monitor support too as well as printing from mobile devices. If you put your mind to it, you can do anything, and thinking out of the box doesn't make it hard always.

CategoryWebDesign