Tags:
create new tag
, view all tags

New Window Per Topic

Instead of implementing PopupPageIndexForEditing, JohnAltstadt changed the edit and create links to open up a new window, thus leaving the original window free for further browsing. He said:

I don't have the source available to me right now, but I think there are only three places where this needs to be done.

I did this at the request of people at my workplace, and they seem happy with the tradeoff of multitudes of windows when doing extensive edits.

-- JohnAltstadt - 06 May 2001


It would be good to have John's NewWindowPerTopic method available. If you could post the diffs perhaps we can make this an optional feature?

-- MartinCleaver - 10 May 2001

Finally I had the time to sit down with TWiki20010901 and do this up right. I don't know the first thing about Perl, but I managed to hack in my changes and still have it run. Wow! smile

First off, my original changes (described elsewhere) were twiki wide and not configurable. I have now changed this so that users can turn it on or off at will (I hope).

After these changes, if configured as such by the user, selecting any create or edit link will pop up a new window. This lets the user continue to browse around in the original window to gather information for the edit session.

The files changed to implement this are:

  • bin/view
  • lib/TWiki.pm
  • data/TWiki/TWikiPreferences.txt
  • data/TWiki/WebTopicViewTemplate.txt

I have attached context diffs.

-- JohnAltstadt - 22 Nov 2001

One thing to check with this feature: it's possible that this may cause BackFromPreviewLosesText when using IE5.x or 6.x (can happen when a new IE window is created).

-- RichardDonkin - 11 Jan 2002

Argh... no, I Don't Want This.

When I'm surfing, I want to be in control. Sometimes I want a new window to open, sometimes I won't (and this can change depending on how full my screen is).

When I'm using Mozilla, I often want to open the window in a new tab. (I think Opera has a similar feature.)

WWW is about letting the user be in control. TWiki even more. Please let's stick with that.

The value of a tool can be measured not only in what it allows writers to specify, it's also in what it can guarantee for the readers.

-- JoachimDurchholz - 12 Jan 2002

In IE, if you click on the link while holding SHIFT, link will open in new window (I just did it for this one). I do not know this easy shortcut for Netscape/Win, but on right-click on link you have a menu with option to open link in new window.

Can we just train users to do that at will, instead of setting it hard in configuration or user preferencies?

-- PeterMasiar - 12 Jan 2002

From Top-10 New Mistakes of Web Design (Alertbox May 1999)

2. Opening New Browser Windows

Opening up new browser windows is like a vacuum cleaner sales person who starts a visit by emptying an ash tray on the customer's carpet. Don't pollute my screen with any more windows, thanks (particularly since current operating systems have miserable window management). If I want a new window, I will open it myself! 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.
http://www.useit.com/alertbox/990530.html Erm. Yes. Citing Nielsen is a bad habit of mine wink
-- PeterKlausner - 14 Jan 2002

Citing Nielsen is a good habit, and something that TWiki could benefit from IMO smile

-- RichardDonkin - 15 Jan 2002

Also from Top-10 New Mistakes of Web Design (Alertbox May 1999)

6. Moving Pages to New URLs

Anytime a page moves, you break any incoming links from other sites. Why hurt the people who send you free customer referrals?

Therefore we should never allow RenameTopic.

Further on he states in item 10:

... I don't want to ban pop-ups completely since they can sometimes be a productive part of an interface, but I advise making sure that there is an alternative way of using the site for users who never see the pop-ups.

Item 3 says in part:

Consistency is one of the most powerful usability principles: when things always behave the same, users don't have to worry about what will happen. ...

Since 99.99% of the web cannot be edited by the users, then none of it should be and we should all pack up TWiki and go home because we are misguided fools.

Please realize that Nielsen's guidelines apply to normal web pages, and TWiki is anything but a normal web page. As someone I worked with a long time ago was fond of saying: Too much rigor breeds rigor mortis.

Now that I have the sillies out of my system, I will address the real points above.

My original reason for opening up a new window for each edit was due solely to USER DEMAND. This is particularly funny when you find out that:

  • 100% of the TWiki users at my location are using Netscape
  • 95% of the TWiki users at my location are using it under Solaris
  • the middle mouse button for Netscape running under any Unix opens a new window

In other words, a new window can be opened as easily as shifting one finger over slightly when clicking. Still, the users demanded a new window when clicking on an edit link.

Further, have you ever watched people using the web? How many people have you seen ever click the Back button on the browser? After many years in my office helping people out with web issues and, more recently, showing people how to use TWiki, I have come to the conclusion that I am an atypical web user. I use the Back button almost pathalogically. I even use it on windows that I know I am about to close. Most people I have observed will either hit the Home button, type a new address into the Location box, or select a bookmark/favorite link. If the Back button was removed from the next version of their browser (assuming that they even cared enough to upgrade), most users wouldn't even notice for a month or two.

These real world observations caused me to come up with the file edit scheme that is attached to the BetterFileLocking page. Unfortunately, it requires the use of that horrid JavaScript and it apparently doesn't work with many browsers. (Oddly enough, it works fine with all that I have tried.)

If it didn't require JavaScript, I would even go further to remove all the buttons and menubars from the newly created windows to force people to not use the Back button. That would render the window near useless for anything other than editing the page the user selected. This would ensure that the user would close the new window soon afterwards. Unfortunately disabling Back buttons is another item forbidden by Nielsen.

All these items considered, I made sure that the patch attached below defaults to not opening a new window. I.e. it is up to the individual user to enable it. The status quo is maintained and Nielsen is happy because there is an alternative way to use TWiki without pop-ups.

Perhaps you could try a survey of your users to find out if they would like this feature added. Perhaps the near universal demand of 150 people in my office is atypical of the general public. I do know that I cannot remove this feature from our TWiki installation without expecting torches and pitchforks outside my cubicle soon afterwards. I, on the other hand, am capable of moving my finger over 3/4 of an inch (2 cm) to click on the middle mouse button, so I could feel good about my physical prowess until my co-workers hacked me to bits.

By the way, I automatically opened a new window (using the middle mouse button) to edit this page so that I could continue to surf on the TWiki site. Try editing any TWiki page using citations from other web pages without any other browser windows open. The patches just make it easier for people to do what they would do naturally.

-- JohnAltstadt - 16 Jan 2002

John,

your user base must be atypical since we all know that Linux is the OS of choice wink
Seriously, Solaris is indeed atypical, so your statistical sample is definitely skewed.

You're right that rules like Nielsen's should not be adhered to mindlessly. On the other side, if you wish to deviate from them, you should be able to give a good reason; just saying that TWiki is atypical is not enough IMHO. The site editing facilities of TWiki do indeed violate one of Nielsen's rules, but here we do have a reason (besides, it's not soo atypical as one might think: the typical newbie site guestbook is a toy TWiki if you will).

BTW renaming in TWiki indeed carries the same problems as in a typical site. Links within a TWiki are automatically corrected (if I understand the docs correctly), but links from the outside will dangle. I'm going into the details on RedirectToRenamedPage.

I'd indeed like it if the Edit link opened a new windows.
No, wait, that's not true. I switched over to Mozilla recently, and now I want the new edit window to open in a new tab. (If I were an Opera user, I'd probably want a new child window within the main window instead of having a new main window.)
See what I mean?
It's really a problem of missing protocol. We'd like to express that we open a new window that's related to a standard window, but HTTP just doesn't allow us to specify that. If HTTP had a facility, then IE/NS could implement it by opening a new window, Mozilly by opening a new tab, and Opera by opening a new child window, the entire facility might be user-configurable, and everybody would be happy. Since that's not the case, the question is whether we should hack a workaround or not. IMHO it's not worth the trouble, in particular since I'm not aware of any browser with an Open in Same Window entry in the context menu.

What did your users say when you told them that they could already open a new window by using the middle button resp. the context menu? If they agree it's a good idea, there's no reason to pursue the issue further.

-- JoachimDurchholz - 17 Jan 2002

Comment: I'd personally loathe such a feature, as I suspect many people who use my TWikis, but having an edit box open up a new window doesn't need any code changes really, and can be done with a skin, and a tiny plugin.

If you set in TWikiPreferences:

    • Set LOCALEDITTOPIC = <a href="%SCRIPTURLPATH%/edit%SCRIPTSUFFIX%/%WEB%/%TOPIC%" target="%.RANDOMISER%"> Edit </a>
Change the view.tmpl such that:
This Becomes This
%EDITTOPIC% %LOCALEDITTOPIC%

And add the following line to one of the functions (probably outsidePREHandler):

    $_[0] =~ s/%RANDOMISER%/int(rand(100000000))/geo;

Users can override this with in local preferences:

    • Set LOCALEDITTOPIC = <a href="%SCRIPTURLPATH%/edit%SCRIPTSUFFIX%/%WEB%/%TOPIC%"> Edit </a>

So that they don't get the popup that way.

This is untested, but you get the gist...

-- TWikiGuest - 17 Jan 2002

  • I agree completely that the OS used in my work environment is atypical, but I doubt that the people are. They go home to Linux and Windows boxes and use whatever browser they have handy. Some of them <shudder> don't even have computers at home.
  • Very few people use Mozilla or Opera. We are an atypical group on twiki.org because we do. Directly supporting 95%-99% of the user community is pretty good odds. If TWiki checked which browser was being used, and the oddball^H^H^H^H^H^H^H lower market share browsers supported it, we might even be able to let the user customize the behaviour to open the edit session in a tab or whatever.
  • Everybody at work knows that they can open up new windows by using the middle mouse button. They just don't want to. It might have something to do with atrophied lateral motion muscles in their fingers. Or it might just be that people don't want to have to remember that they need to use the middle button every time they want to edit a page. Hitting the back button (assuming that you know that there is a back button (see above)) so that you can get another shot at it can be a bit tiresome.
  • There is an easy way to avoid things that one loathes: don't use them.
    I loathe cigarette smoking. I deal with it by not buying cigarettes, not putting them in my mouth, and not lighting them. This patch is U SER CON FIG UR A BLE and is off by default. You have to go out of your way to buy these cigarettes, put them in your mouth, and light them. The fact that they are on the shelf at the local store does not force you to use them. They will not fly off the shelf, light in mid air, and home in on your mouth. If it was implemented on twiki.org tomorrow, you wouldn't even know about it. Even if you do choose to use these cigarettes, they won't cause cancer (just another window or two).
  • There are all sorts of configurable items in TWiki. I doubt that you went through and changed them all from their defaults. You can leave this one in its default as well. It's real easy to do.
  • If this feature is only available in skins, then every skin will have to be edited to make it available. Changing the code once reduces the work worldwide.

Finally, and I don't think I can stress this enough, this suggestion is based on a case study of real people in the real world. Sitting in a board room and theorizing with a bunch of like minded geeks about what is best for the users does not fit anywhere in my work ethic. I do not work for Microsoft. The commercial software I write is based on well understood customer requirements and international standards, not on anybody's idea of what we can shove down the customers' throats. The personal software I write is based on similar motives, but the customer base may be extremely small.

-- JohnAltstadt - 17 Jan 2002

"I doubt that the people are atypical."

According to Nielsen, they are. Nielsen states that the Back button is the second-mostly-used feature of browsers, while your users obviously don't follow this pattern. (Unfortunately, he doesn't say anything about the statistical user base.)

"Very few people use Mozilla or Opera."

My point was not that TWiki should be made especially suitable for Mozilla or Opera. What I meant to say was that these features could become mainstream as soon as Microsoft or Netscape decide to clone them for their browsers. (In the case of Netscape, this is actually something to be expected. Netscape is based on Mozilla, it's just a few versions back.)
More generally, web sites don't know how browsers will evolve. Better ways may become available. Choosing a mechanism with known drawbacks will make it more difficult to use better mechanisms (because users will object to changes in the UI, no matter how badly designed the UI is).

"There is an easy way to avoid things that one loathes: __don't use them.__"

Um... this isn't really an option in the IT world. I have witnessed too many instances where I was forced to use things that I loathe (such as DOS, Windows, Javascript, or software that transmits personal information without my consent).
I just fear that this is what's happening again.
It may be selfish, because I want to restrict other peoples for my personal convenience. I'm not really sure... there's also something to say in favor of educating people. (Microsoft does it all day, consciousl and unconsciously.) A neutral discussion on how to improve the edit process would be more helpful than insisting that your patch is the thing to install.

"Sitting in a board room and theorizing with a bunch of like minded geeks about what is best for the users does not fit anywhere in my work ethic. I do not work for Microsoft."

Please deescalate. I don't work for Microsoft myself, and I find it ... unfriendly ... to be accused of thinking in a Microsoftish way.

That said, customers often want nonsense that doesn't really help them. They are all too eager to trade long-term benefits for short-term advantages.
Of course, it's all too easy to go overboard and brush real demands aside since they don't fit into our geek mindframes.

The main argument that I have heard is that users want it. Fine... I don't want it, and several others don't want it, not even as an option. With reasons.
Let's sort out the reasons and reach a conclusion. Flamewars (even low-profile ones as in the above) won't help us with that.

Thanks for your attention.

-- JoachimDurchholz - 18 Jan 2002

I would still argue that the best approach here is to approach this with a plugin. If the hooks in twiki aren't there yet to make this practical for you, then we should modify the twiki plugin api to specifically allow for the various changes you'd like here simple to do. The reasoning I have here is simple - the majority of people I work with would not like this feature to be on by default. If that's the case it makes a good argument (from my perspective) for abstracting the code out into a plugin. That way you end up having a lean mean TWiki core, with lots of cool addons. (I've installed a wide variety of the existing plugins onto our 3 twiki production servers servicing around 100-200 people now - all using a variety of OS's as well as the test bed systems)

That said, just because a majority want something it doesn't say that the minority must suffer, hence the plugin suggestion.

Other benefits of having a plugin hook for action urls (eg edit, attach, save, etc) is that you suddenly gain extra ability to hook deeper into other systems - which adds extra value in a large number of situations for many setups. For example it potentially allows for the extension of opening up new tabs and so on in your browser. It opens up the way for instant notification of changes. It opens the means of online mirrored distributed servers mirroring content almost instantaneously and so on. It also in the immediate term makes the changes you'd like low impact for everyone else....

Final comment, please let me echo Joachim's request - please don't flame, I'm not interested and I'm not gonna bite, if I want a flame war I'll go somewhere else. If you do wish to flame, please do so at my email address, this is on my personal page on this twiki. Just because I don't agree with you doesn't make me right. I haven't said we shouldn't have this functionality available - you know people who want it - that's sufficient. I am simply disagreeing with the way the functionality should be made available - nothing more - with an eye going "how can we provide this is the most generic way possible that decreases the chance of core code changes in future".

Finally if you're gonna open multiple windows, this opens up whole vistas of new possibilities with regard to potential new style user interfaces - and get closer potentially to the model of double clicking on a file opens uo a file in notepad, an MSVC project in MSVC, a 3D scene in Truespace etc... Having a generic hook to allow this could be massively better than a quick simple modification in the long term.

-- TWikiGuest - 18 Jan 2002

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatdiff TWiki.pm.diff r1 manage 2.6 K 2001-11-23 - 04:22 JohnAltstadt context diff
Unknown file formatdiff TWikiPreferences.txt.diff r1 manage 2.0 K 2001-11-23 - 04:22 JohnAltstadt context diff
Unknown file formatdiff WebTopicViewTemplate.txt.diff r1 manage 1.0 K 2001-11-23 - 04:22 JohnAltstadt context diff
Unknown file formatdiff view.diff r1 manage 1.3 K 2001-11-23 - 04:23 JohnAltstadt context diff
Edit | Attach | Watch | Print version | History: r18 < r17 < r16 < r15 < r14 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r18 - 2006-04-29 - SamHasler
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.