Re: How to make a link, using cgi.pm, that opens a new window
by tcf22 (Priest) on Aug 20, 2003 at 19:50 UTC
|
use CGI;
my $cgi = new CGI;
print $cgi->a({href => 'http://www.google.com', target => '_blank'}, '
+Google');
| [reply] [d/l] |
|
|
| [reply] |
OT Rant Re: How to make a link, using cgi.pm, that opens a new window
by ajdelore (Pilgrim) on Aug 20, 2003 at 21:52 UTC
|
Why do you want to open something in a new window? This is by far the most annoying behaviour that I experience on websites, mainly because it is the only one I can't shut off in the browser.
This is #1 and #2 on Jakob Nielsen's Top Ten New Mistakes of Web Design (1999):
The Back button is the lifeline of the Web user and the second-most used navigation feature (after following hypertext links). Users happily know that they can try anything on the Web and always be saved by a click or two on Back to return them to familiar territory.
Designers open new browser windows on the theory that it keeps users on their site. But even disregarding the user-hostile message implied in taking over the user's machine, the strategy is self-defeating since it disables the Back button which is the normal way users return to previous sites. Users often don't notice that a new window has opened, especially if they are using a small monitor where the windows are maximized to fill up the screen. So a user who tries to return to the origin will be confused by a grayed out Back button.
That whole thing about "keeping people at your site" is cutting-edge 1995 web design theory. I found your site in the first place, if I want to go back there I will. Open a new window, and you can be sure that I won't.
</ajdelore>
| [reply] |
|
|
While forcing the user to open a new browser window when s/he expects a link is amazingly annoying and a pet peeve of mine, there are at least two legitimate reasons for creating a new window. Both apply primarily to web applications: popup windows which act as dialogs (usually javascript instead of _target), and new windows the user expects, e.g. screens for printing that lack navigation elements, like printable reports (especially if they can take a long time to run). Web applications are a special case where the use of the back button can lead to user confusion and error, since the previous screens probably have out of date information on them. For this reason, users of web applications (especially when money is involved) should be trained/told not to use the back button - so if a screen doesn't have navigation, it has to be separate. The web application programmers often compound this problem by forcing a reload of the page - it only makes things worse because then hitting the back button can perform actions.
Here's an example - your're doing online banking, and you transfer money from one account to another. Then you click a link to show a printable screen of your account history, or maybe a receipt. That screen should be a new window, because you should never click the back button in the banking application (notice how they always have warnings about not using the back button after your perform a transaction?). If you did click the back button you could end up transfering the money again. That wouldn't happen if it were programmed correctly, but would you put money on those odds? The programmers probably did the forced reload thing so that you couldn't hit the back button twice and think the money hadn't been transferred. Or maybe it's just tradition, since IIRC that used to be (is?) the default for CGIs...
| [reply] |
|
|
it is the only one I can't shutt off in the browser.
Just to nit-pick, some browsers (such as Mozilla, Firebird, prolly Opera and Camino) do let you shut it off.
| [reply] |
|
|
Mozilla and all let you dissallow random html attributes? Never knew they could do that.
| [reply] |
|
|
|
|
Although this should be left to user discretion most of the time, there are some applications where it is necessary. For instance, to open an explanatory message which should be visible alongside the original page.
| [reply] |
|
|
I'm confused about that. you mean a pop-up window? A small window which explains the larger window, which it now partially obscures?
If the explanation is small enough, it should go on the page it's explaining. If it's too large, it should be on a page of its own, and let the user read it and go back.
Or of course you could redesign the first page so that it needed less explanation.
Every time someone argues for usability guidelines like "don't mess with the user's browser", someone else says "Except in my special case, that's right. But I can ignore that rule because..."
($_='kkvvttuubbooppuuiiffssqqffssmmiibbddllffss')
=~y~b-v~a-z~s; print
| [reply] [d/l] |
|
|