[Experimental] Implement the dual-pane window view.

[Pauan]

Originally reported on Google Code with ID 97

What steps will reproduce the problem?
1. Open a tab with a long title.
2. Open Tab Organizer.

What is the expected output? What do you see instead?
Try to read the full title. Should be easy, instead you need to hover the mouse over
the tab for a couple seconds.

Please provide any additional information below.
RVBER BACCHVS:
I only have one problem, which is in fact common to all extensions. Why isn't there
an option for magnifying the tab tables? Making them full-screen even? More often than
not, large titles are truncated ... I have installed 7 or 8 tab managers and there
isn't one in which I can easily figure out the page titles.

Reported by pcxunlimited on 2010-11-11 12:31:27

[Pauan]

With reference to your question, I use many windows, each of them with many tabs open.
My screen is 1920 x 1200, 17 inch-wide. I now see that you use a separate table for
each window, which somehow limits how wide they can get. I don't think it's a good
approach though by the time you get to say 12 windows. I'd much prefer a 2-column full
screen, with windows listed in order one under another ad infinitum and separated by
thick delimiters. Windows should be nameable (e.g. PERSONAL, WORK, etc.) Both columns
should be identical, and then one could transfer tabs between them easily, always one
way from the left column to the right. Of course the columns will be scrollable so
that you can get Windows 2 side-by-side with Windows 7 e.g. Another thing I'd like
to see is exporting and importing tabs to a file or clipboard with fully clickable
URL's and respective identifying icons. Thanks for the hovering tip, it helps a bit
but it doesn't feel fully satisfactory.  

Reported by flaviuadrian on 2010-11-15 16:17:32

[Pauan]

Windows are already nameable. It's also pretty dang easy to transfer tabs between windows
by dragging them or using the "Move selected to..." submenu.

Interesting idea about having windows scroll vertically rather than horizontally. I'll
try to get a mock-up, to see if I understand your suggestion correctly.

Because screens have finite space, there are essentially 3 ways to handle overflow:

1) Clip it. The excess is simply not shown. This is what Tab Organizer does right now.

2) Wrap it. Rather than having tab titles on one line, it would wrap to multiple lines.
Note: this is basically replacing horizontal overflow with vertical overflow. In the
case of Tab Organizer, we're already using vertical scrollbars, so that doesn't matter.

3) Provide a horizontal scrollbar.

I decided on the 1st, due to a combination of simplicity, usability, aesthetics, and
consistency. The only downside is that you can't view the excess content.

Import/export to a file could be rather tricky, but it's being tracked at Issue 101.

Reported by pcxunlimited on 2010-11-16 05:57:14

[Pauan]

One other question: what's your font size? For me, quite a few tabs don't overflow,
even with the 400px restriction. On the other hand, if you have a larger fontsize,
I can see how most (or all) tabs would be cut off. That could be solved by specifying
the width relative to the font, rather than using pixels.

Reported by pcxunlimited on 2010-11-16 06:49:52

[Pauan]

Cool, I look forward to seeing the mock-up. I think the best way forward is to combine
the solution I propose with overflow solution 2 (wrapping, vertical overflow) and with
what "anonymous" suggested on the other board (suspended tabs). With the important
note that in my variant you would hardly ever need the overflow anyway, because half-screen
must be enough for the full display of most tab titles.

I thought more about it and I refined the idea a bit. I think you could move tabs and
windows around with great flexibility in the 2-column full-screen variant. In addition
to clicking-&-dragging, you could also employ a 2-click solution as follows.

In the second column you click an insertion point, which is either a window delimiter,
a tab delimiter, a first tab in a window or a last tab in a window. In the first column,
you click either a tab or a window. You must be able to do these clicks in whichever
order feels more convenient at the time. There will be eight combinations possible
between your 2 clicks in the 2 columns:
(1) window + window delimiter ===> window gets inserted between two windows
(2) window + tab delimiter ===> window's tabs get inserted between two tabs
(3) window + first tab in window ===> window's tabs get inserted before first tab in
window
(4) window + last tab in window ===> window's tabs get inserted after last tab in window
(5) tab + window delimiter ===> tab becomes window and is inserted between two windows
(6) tab + tab delimiter ===> tab is inserted between two tabs
(7) tab + first tab in window ===> tab is inserted before first tab in window
(8) tab + last tab in window ===> tab in inserted after last tab in window

Now this gives you great flexibility with just 2 clicks, performed in whichever order
feels right. Sometimes one thinks first of where they'd like to move stuff, sometimes
of what they would like to move. 

To be sure you are covered against all possible situations, you may want to move an
arbitrary selection of windows and tabs to a certain insertion point of the 4 kinds
described above. This would require a selection in the first column and a click in
the second with four combinations again:

(1) arbitrary selection of windows and tabs + window delimiter ===> windows in the
selection remain windows, selected tabs belonging to one window form a window; everything
gets inserted in order between two windows
(2) arbitrary selection of windows and tabs + tab delimiter ===> all tabs in the selection,
regardless of window, get inserted in order between two tabs
(3) arbitrary selection of windows and tabs + first tab in window ===> as in (2) but
insertion before the first tab in window
(4) arbitrary selection of windows and tabs + last tab in window ===> as in (2) but
insertion after the last tab in window.

Hope this helps! Yours is one of the more intuitive tab organizers I found and I think
with such improvements we could make it great. I am really excited at the prospect.

Reported by flaviuadrian on 2010-11-16 12:07:09

[Pauan]

Regarding your font size question, I use the default font assigned by Google Chrome.
However, due to high resolution of the screen, I often magnify using Ctrl+.

Reported by flaviuadrian on 2010-11-16 12:11:21

[Pauan]

One more suggestion to complete the above concept. In column 2, window delimiters and
tab delimiters should toggle. Thus, when one selects a window or tab delimiter in column
2, Tab Organizer will expect either a click on a window or tab in column 1 whereupon
treating the delimiter in column 2 as an insertion point for the selected window or
tab in column 1 as described; or, one could next hit Enter instead and then a tab delimiter
will change to a window delimiter and viceversa, in effect either splitting a window
or joining two contiguous windows, respectively. 

Reported by flaviuadrian on 2010-11-16 15:37:15

[Pauan]

Alright, I got a quick mock-up. This doesn't implement the stuff you talked about, with
the two-click idea, etc. All it does is rearrange the windows into a 2x* grid. I want
to see whether I have the right idea or not, before I commit too much to this.

Note, that with this view, you can only see ~2 windows at once. With the current layout,
you can see 7.5! Thus, even though the current layout does clip tab titles to a certain
width, it is also very space-conservative.

Having said that, I've been interested in showing tabs in different views, so I may
implement your idea as an optional... well, option. Anyways, here's the file:

http://paaru.pbworks.com/f/Tab%20Organizer.crx

Reported by pcxunlimited on 2010-11-19 03:41:15

[Pauan]

Thanks for the file. Can you tell me how I execute Chrome's install extension command
on it? When I click on it, it attempts to download the file rather than install it.

Reported by flaviuadrian on 2010-11-19 09:03:21

[Pauan]

Drag/Drop it from your file manager on Chrome window after downloading.

Reported by temp01irc on 2010-11-19 09:31:58

[Pauan]

I like the spacey look; but on my screen, I could easily fit one more window there.
Maybe you can add a 'number of columns/windows' option and default to 'dynamic/auto'
(the way it does now). If it's set to a fixed amount, wrap; Otherwise, do what it does
now - overlap.

Reported by temp01irc on 2010-11-19 09:34:19

[Pauan]

Sorry, it's not working. It says it failed to copy to temporary directory.

Reported by flaviuadrian on 2010-11-19 10:07:17

[Pauan]

Well, you could try following the directions on this wiki page:

http://code.google.com/p/tab-organizer/wiki/LatestVersion

Alternatively, try the beta/dev channel of Chrome.

Reported by pcxunlimited on 2010-11-19 11:47:18

[Pauan]

I followed the instructions on the above page, folder tab-organizer does not contain
any extension list of any kind.

Reported by flaviuadrian on 2010-11-19 13:02:11

[Pauan]

"the extensions list" refers to the chrome://extensions page within Chrome. I'll update
it to be more clear.

Reported by pcxunlimited on 2010-11-19 13:08:04

[Pauan]

I have finally been able to see the mock-up. I have two windows open, the first appears
on the left, the second on the right. This is not exactly what I was suggesting. I
was suggesting two *identical* columns, each of them containing all the windows listed
vertically one under another. So column 1 should show windows 1 and 2, and similarly
column 2 should show those same windows. You should think of it more like a spreadsheet
with an infinite number of rows and two columns. Each tab corresponds to a row. So
yes, the mock-up succeeds in giving an impression of the spacey and clean look this
would afford for the tabs, but the columns should not be confused with the windows.

Reported by flaviuadrian on 2010-11-19 13:25:08

[Pauan]

Ah, I see. I do like the idea of presenting the standard windows in a different order
(as per temp01irc's suggestion), but your idea is certainly unique.

In any case, this is precisely why I made the quick mockup: to figure out if I had
the right idea or not.

Implementing a mockup of your suggestion will be more difficult; not impossible, but
not something I can just whip together in 5 minutes.

Your idea will also change the semantics of the windows so significantly to require
a mode switch, which is something I've been working on (for unrelated reasons).

Reported by pcxunlimited on 2010-11-19 13:32:23

[Pauan]

What you do basically is give up trying to fit all windows on screen and allow them
to run vertically to the infinite, in a way a spreadsheet does. To compensate for the
loss of perspective this entails, you employ the second, identical but independently-scrollable,
column. You do your management of the windows and tabs by scrolling the two columns
independently, enabling you to bring side-to-side any two windows on screen, however
far apart they are. 

Reported by flaviuadrian on 2010-11-19 13:35:32

[Pauan]

P.S. Before inventing Tab Organizer, I had experimented with an extension that showed
all the windows in a flat 1D list, as you suggest. I decided that TO was a better way
to manage windows and tabs. Funny how things have come full circle, in that sense.

P.P.S. A vertical 1D list of tabs is similar to Tree Style Tabs for Firefox (which
I have used, and like). Of course, Tree Style Tabs also groups related tabs in a 2D
tree view, so it's not entirely the same.

Personally, I think if a Tree Style Tabs extension could be created for Chrome, then
Tab Organizer would become mostly useless, as Tree Style Tabs is already so good at
showing many tabs and groups at a glance.

Reported by pcxunlimited on 2010-11-19 13:38:32

[Pauan]

Yes, I understand the concept. It's simply that the infrastructure of TO has been designed
from the start for a horizontal list of overlapping windows.

Implementing your suggestion would be quite easy if I were starting from scratch; the
hard part is integrating it into the infrastructure I have already built up with Tab
Organizer.

Reported by pcxunlimited on 2010-11-19 13:40:30

[Pauan]

If I had time, I would have liked to help but it probably requires some pretty substantial
time expense upfront just to get up to speed with what's already there. In my opinion,
Chrome itself will have to deal with these matters in a more fundamental way at some
stage. There is no reason really for separating History, Bookmarks and Tabs in three
distinct categories to be managed independently. It's more a reflection of legacy conceptual
thinking. I think they should be unified in a clever way, but about this another time.

Reported by flaviuadrian on 2010-11-19 13:50:07

[Pauan]

I'd suggest it would be good before you decide your implementation strategy to reread
the other stuff about clicks and delimiters from my previous comments to see what else
would need to be changed to accommodate them. Delimiters are quite important for the
smooth functioning of the concept I propose. Two other suggestions with respect to
scrolling of the columns. First, make the scrolling circular, so that the last window
is followed by the first window again. Second, put the scroll bars on the left and
right of the screen to allow for maximum visibility.

Reported by flaviuadrian on 2010-11-19 14:25:46

[Pauan]

I am curious: since we have finite scrollbars, how would I implement a circular view?

I don't think I can change where the scrollbars are displayed, so they'll probably
have to be on the right side of the element. I can look into it, though.

Reported by pcxunlimited on 2010-11-20 04:55:57

[Pauan]

P.S. I could implement custom scrollbars using the DOM, but that is incredibly hacky
and I would rather not go that route... better to use the OS's scrollbars, I think.

Reported by pcxunlimited on 2010-11-20 04:57:45

[Pauan]

Finite scrollbars doesn't bode well for my layout. Circularity is not essential but
scrollbars should be at least indefinitely long. The whole idea is based on one's being
able to scroll, in principle, to infinity. I think it is worth investing the time in
getting the scrolling right. I have in the past seen some PDF readers implement circular
scrolling, although I don't seem to recall which. When the scrollbars get longish,
it certainly helps. 

Reported by flaviuadrian on 2010-11-20 10:58:24

[Pauan]

I'd be interested in seeing circular scrolling implemented, though I'm not sure it's
possible with the technologies I have to work with (HTML, CSS, JS). The only way I
can think of is to dynamically shift windows around when you get close to the end,
which could have some problems and be confusing.

Native scrollbars do support a theoretically infinite amount of data, though it would
obviously take a while to scroll from one end to the other. In any case, I'll try to
get a mockup, and we can build it up from there.

Reported by pcxunlimited on 2010-11-20 14:57:08

[Pauan]

You could implement google wave style custom scrollbar - one that always stays in 'middle'.

Reported by temp01irc on 2010-11-20 15:07:18

[Pauan]

Adobe Reader 9 has an option to "loop after last page" under Edit/Preferences/Full Screen.
For some reason, that same is not available when you just scroll normally through your
document (full screen does not have actually scroll bars). So maybe they are dynamically
shifting the windows as you say, but for me circular scrolling is a much more interesting
proposition. 

Reported by flaviuadrian on 2010-11-20 15:13:53

[Pauan]

Yeah, I'd probably need to use a custom scrollbar like Wave (thanks for the tip, I didn't
realize their scrollbars behaved differently, as I hadn't used Wave before).

...Of course the reaction to the custom scrollbars has been rather poor. Which is understandable
given how they look like normal scrollbars, but behave differently.

If I can create an interface that looks different from normal scrollbars (so as not
to confuse users), then I might be okay with going that route.

Question: when you say circular scrolling, are you referring to a gesture used on a
touchpad, or simply the concept of a 1D list that loops over itself? The latter would
almost certainly need to be implemented by dynamically shifting the positions of the
windows (though to a user it would look like a single infinite list).

The alternative would be to create a copy of the window on the fly... which would be
basically the same, but consume more memory.

Reported by pcxunlimited on 2010-11-20 17:03:31

[Pauan]

I mean the latter, a list in a loop, nothing fancy. A user might in such a scenario
be able to see the lower half of Window 1 at the top of the screen, while the upper
half comes round at the bottom of the screen while scrolling (with say Windows 2 and
3 in between). Of course, if there are many windows in between, such splitting would
not occur.

I don't know about Wave, I am not a user so cannot say anything about their scrollbars.

Reported by flaviuadrian on 2010-11-20 17:14:58

[Pauan]

I'm tentatively calling this view "dual-pane", and will thus hijack this bug to refer
to it, rather than truncated titles in general.

Reported by pcxunlimited on 2010-11-21 18:56:43

• Labels added: Type-Feature, Experimental, View-DualPane
• Labels removed: Type-Bug, OS-All, Component-UI

[Pauan]

I would call it Flav's Strange Loop View, inspired by this:
http://en.wikipedia.org/wiki/Strange_loop

Reported by flaviuadrian on 2010-11-22 11:44:47

[Pauan]

Okay, I have a mockup now. It is *extremely* hacky, and very very broken, in major ways,
but it's a start.

You'll need to manually update the Unpacked version of Tab Organizer, then switch to
Dual-Pane in the Experimental category of the Options page.

You'll note that I have (very bad looking, but functional) scrollbars on the left and
right sides. Also, right now the max height is the same as the default height for the
popup. Obviously the final release will stretch properly to any size.

I'm still not sure how this way is better than the current layout.

Reported by pcxunlimited on 2010-11-22 19:26:46

[Pauan]

How do I manually update the Unpacked version? Last time you sent me a .crx file. This
time? By Options page you mean which page exactly?

Reported by flaviuadrian on 2010-11-22 19:46:42

[Pauan]

Follow the directions here:

http://code.google.com/p/tab-organizer/wiki/LatestVersion

And I was referring to the Options page of Tab Organizer, which has an Experimental
category at the bottom.

Reported by pcxunlimited on 2010-11-22 20:18:45

[Pauan]

(P.S. the manual update steps are near the bottom of the LatestVersion wiki page)

Reported by pcxunlimited on 2010-11-22 20:20:32

[Pauan]

I have downloaded it now but there is no option to switch to dual-pane view under Experimental
(there are two options there that refer to middle click and escape key but no dual-pane).
The TO does however list windows in two columns but all it does is to list Window 1
on the left, Window 2 on the right, then Window 3 under Window 1, Window 4 under Window
2, etc. This is not the layout I was suggesting. To achieve that, you have to list
all windows in both columns as if one column was a perfect mirror of the other.

Also, can you change the version number with each iteration you send to me for review
or otherwise it's very easy to get confused. 

Reported by flaviuadrian on 2010-11-22 20:50:25

[Pauan]

Are you sure you reloaded the extension? Unfortunately, Chrome doesn't automatically
reload it, so you'll have to do so in the Extensions page.

Reported by pcxunlimited on 2010-11-22 20:55:46

[Pauan]

I followed all the instructions on the wiki page, even deleted the folder Tab Organizer
as a precautionary measure before I downloaded again. The timestamps indicate that
the new folder was created now and inside I can see a dual-pane.css. But the version
bears the same number as before, 3.3. Did you change the version number?

Reported by flaviuadrian on 2010-11-22 21:00:55

[Pauan]

No, I didn't, but it's not enough to download the new file. You have to go to Wrench
-> Tools -> Extensions, then click the "Reload" link underneath the Unpacked Tab Organizer.

It's a pain, but Chrome doesn't automatically reload Unpacked extensions when they
change.

Reported by pcxunlimited on 2010-11-22 21:04:06

[Pauan]

OK, deleted everything and reinstalled anew. Now I see something different and much
better. Still I see Windows 1,3,5,7,9,11 on the right and 2,4,6,8,10,12 on the left.
Same observation as before. Left and right scrolls are getting close to what I imagined
but for some reason the lower half of the screen is blank, only the upper half gets
used.

Reported by flaviuadrian on 2010-11-22 21:12:12

[Pauan]

Yes, as I already mentioned, it is broken and missing major functionality. It is intended
as a mockup to show the idea, not a final production. I already mentioned the size
limitation, which will be removed in the final version.

The window *names* are sequential, but the window contents are as you described: both
columns contain the same windows and tabs. I assume the mockup is close to what you
were thinking, excluding circular scrolling and the two-click method?

Reported by pcxunlimited on 2010-11-22 21:17:52

[Pauan]

Ah, I see. The windows started with the same contents but as I moved tabs around they
came to differ --- did not update to be more precise. In the final version, after you
permute content everything should update automatically so that once again everything
has the same contents in both columns.

Yes, good job, it's getting closer to what I wanted. Something that is non-essential,
but you may want to think about is actually recovering the space in between the columns.
I sort of imagined everything like a table with two independently scrollable columns
vertically and tab/window delimiters horizontally. The columns would be separated by
a thick vertical delimiter but no more. So you have to think of it more like a table.

Reported by flaviuadrian on 2010-11-22 21:35:18

[Pauan]

I am playing with the scrollbars and for some reason I find annoying the fact that they
pop back in the middle. I think they shouldn't actually, because their being on different
levels on the screen would give one a cue about the relative position of the columns.

Reported by flaviuadrian on 2010-11-22 21:41:03

[Pauan]

I thought more about what you said, whether my layout is better than the current one.
I think it's mostly a subjective call to make, but there is an objective edge nevertheless.
The point is, for most user scenarios, which I suppose tend to be small-scale, any
tab organizer would do just as fine. Yours was the best according to my taste, fairly
intuitive, aesthetically pleasing, but truncated titles and lacked scalability. For
when you move to large-scale, heavy-duty scenarios, such as tens of windows open with
hundreds of tabs each, there is just no way any tab organizer currently available would
cope (what I really mean is, the user would not cope). Of course, life gets more difficult
for any solution, the more windows and tabs you open, but the difference is -- I hope
-- that with the dual-column layout you could still maintain some sort of functionality
and management, whereas current solutions just would not scale up. We shall see.

Reported by flaviuadrian on 2010-11-23 00:12:47

[Pauan]

The reason it snaps back to the center is precisely because you want it to be circular:
you are either scrolling up or down, relative to your current position... If you wanted
reference points, I would use a normal scrollbar. There's a reason Adobe offers "loop
after last page" only in fullscreen.

Imagine that you're scrolling down, and nearing the end of the window list. But you
want it to wrap around, so after the last window, it'll show the first window again.
Imagine how disorienting it would be to have the scrollbar suddenly jump from the bottom
to the top, even though you're scrolling down.

I currently have 873 tabs in 39 windows, and the normal layout works just fine for
me. I created TO specifically because I (ab)use tabs heavily, so I designed it to be
as easy as I could to manage many many tabs.

What I'm curious about is why the current layout doesn't work for you (aside from truncating
tab titles).

When using the mockup, it was more difficult for me to find a window, because the amount
you needed to scroll was much greater, and scrolling was relative. With the current
layout, windows overlap and the scrollbar provides absolute points, making it easy
to say... jump to the first window, or the last window. And because every window is
the same size, you can gauge which window is which by their relative positioning to
each other.

I think you're confusing size scalability with quantity scalability. If I make the
windows bigger (as in your suggestion), then it scales worse with multiple windows.
If I compact the windows together by making them smaller (the current design), it allows
it to scale better to many windows.

UI design is a series of tradeoffs... You are saying "I want windows to be big, so
I can see the full title!" which is fine, but in exchange for that, you can't show
as many windows on screen at once, so you end up needing to scroll more, and it's harder
to see many tabs/windows at a glance.

What I'm saying is "I want to give the user as much information as I can in an intuitive
way", which means the windows are laid out horizontally and overlap... this leads to
some major benefits:

1) You can show many windows on screen at the same time. This is achieved by overlapping
the windows... why not overlap them vertically? Because...

2) I try to show the most important information. You can generally tell tabs apart
just by looking at the favicon and the first 10 letters of the title. By overlapping
them horizontally, I show exactly that. This lets me pack a huge amount of information
into a very small space, which helps TO to scale gracefully up to many windows.

Also... I'm not sure if you realize, but the search box is persistent, and you can
use powerful queries to show/hide exactly the tabs you want. Let me give an example:

Let's say you have.. 20 windows, divided by subject. Right now, you're researching
for a school project, so you only really need to see 1-2 windows, with the rest being
filled with personal stuff.

Assuming that the window's title is "Research", you could use this query to show only
that window: `window:research`

What if you want to show the "Research" window and the "Programming" window? No problem:
`window:research,programming`

Now, even though you have 20 windows open, you only see the Research and Programming
windows, helping you to focus on your task. If you close the popup and reopen it, it
remembers your previous query, so you don't need to retype it all the time.

You can do even more advanced stuff. Let's say you were learning Python. You could
use this query to show only the Python stuff: `python` You could also be more specific,
say you wanted to show the Python tabs that involved optparse: `python optparse`

Or you could show all the Python tabs in the Research window, but not tabs that involve
snakes: `window:research python -snake`

I use the search box a lot, and designed it to be very powerful, because it helps show
you only the tabs/windows that you're interested in, so you don't get swamped down
in hundreds of tabs.

You can read more about special queries and advanced syntax in the Help/FAQ page:
http://documentation.tab-organizer.googlecode.com/hg/Tab%20Organizer%20FAQ.html

Reported by pcxunlimited on 2010-11-23 11:36:12

[Pauan]

By the way, I can solve your original complaint (tab titles being truncated) much easier
than implementing dual-pane, so I forked that request into issue 111.

Reported by pcxunlimited on 2010-12-13 01:13:29

[Pauan]

Version 3.5 (just released) added in a grid-based window layout. It's not the same as
dual-pane, but since it was discussed earlier in this bug report, I thought you might
want to know.

Reported by pcxunlimited on 2011-01-06 20:27:25

[Pauan]

I seem to have ceased receiving notifications from this thread around 22 Nov 2010, which
is why I reply late. I am not sure why this is the case.

In any event, I meant to ask whether you still will be developing the dual-pane view.

Reported by flaviuadrian on 2011-01-30 21:57:15

[Pauan]

I'm debating it. On the one hand, I like giving users more options and ways to do things.
On the other hand, I don't want to bloat things up. Regardless of what I decide, it'll
require some infrastructure plumbing, which I've been putting off.

As per comment #47, I would like to know what you dislike about the current window
layout (aside from truncating tab titles), and also if grid view resolves those complaints.

Reported by pcxunlimited on 2011-01-31 11:17:18

[Pauan]

Unfortunately I don't have much time now for doing further testing of the different
layouts. I don't feel that it's worth debating their relative merits, because it's
clear to me from your comment 47 that you are understandably defending your design
while I have equally warm feelings about mine. It may be that different things work
best for different people. That said, it would probably be a waste of everyone's time
so far if you decide not to implement.

Reported by flaviuadrian on 2011-01-31 12:50:05