Implemented  hover over topic title shows part of the first post

This suggestion has been implemented. Votes are no longer accepted.
...

Also, I'm not sure if this is something that's finally resolved in all browsers, but title attributes have traditionally had issues with line breaks.
I can't say for all browsers, but I'm sure the major ones have fixed their "title" implementation. Maybe lynx still has a problem displaying them, I just don't know.
 
From a quick test using Firebug, Firefox still seems to be broken here (it ignores them). Maybe it was just a Firebug oddity.
 
(and I've yet need to read the other comments after your post also).
Did that and...

I like the above-the-title approach, but unfortunately that is virtually impossible to achieve due to the fact that the tooltip is positioned with top/left coordinates, which would have to change as the content is loaded and animated into place.

Here are a few alternatives I've been playing with:

Tooltip shifted right by 50px:
View attachment 1301

Shifted right and 10% transparency added to body:
View attachment 1302

Positioned over metadata area:
View attachment 1303

I'm not too keen on the idea of having the tooltip directly attached to the right of the title, I think that opens up all sort of possibilities for the tooltip to disappear off the edge of the screen etc., but I might be able to be convinced.

My feedback is already voiced by this remark from EQnoble:

what happens if the thread title is as long as the field it's filling , wouldn't making the placement of the overlay relative to the end of the title have erroneous behaviors for people running at low resolutions and placing it over the metadata makes people like me running at 1920 x 1080 look completely on the other side of the page which makes me look away from my mouse pointers location so the time I saved by not covering thread, is wasted looking to the overlay , finding my pointer and looking at the next title to do the same.. if your reading a preview of one thread i don't get why you need to see the one below it until you are done reading the preview
( unless you can read from two points at once and then you have my complete attention forever )

Basic points:

- I my opinion the tooltip should be there where the focus of your eyes already is (another example here shamelessly pointing to another issue I posted myself). So every suggestion to put it way over the right of the screen (like the 3rd example to put it over the metadata) doesn't quite work, for several reasons stated in this discussion,
- Body transparency is not needed, because it seems a workaround attempt for the real problem and at the same time it creates an unpleasant reading experience inside the tooltip. There is no need to read thread titles underneath that Body, in fact the faded threadtitles aren't even recognizable/readable in the first place,
- The real problem is the fact that the tooltip covers up the thread titles below it, resulting in a bit of difficulties browsing the thread list. So, I am all for Freddies idea to put the tooltip above the current thread title indeed. I believe this solves every single issues people might experience with the current implementation indeed.
 
From a quick test using Firebug, Firefox still seems to be broken here (it ignores them). Maybe it was just a Firebug oddity.
Yes, my bad. I have an extension installed that is responsible for handling line breaks in the tooltips.
Nevertheless, I still like browser tooltips more than the fancy popups :)
 
Is there a way to get rid of the delay of display the tooltip? For example when you have already loaded the first posts content in the tooltip then going back to it to view it again, it still takes a while to show up when the data has already been loaded up. Possibly if it could load the tooltip quickly and fetch then data whilst you get other ones to be fetched, then when you hover back, it would have finished loading and will look spontanteous?

The only thing I don't currently like about it is the speed. I would much rather view a plain text version of the first post than the post loaded with all its bb code and extra information that I can extract from clicking on the thread instead, if it does indeed interest me (as is the case with vB's implementation). In this case speed beats functionality and aesethetics as it is meant to, after all, save you time being wasted on a thread that doesn't interest you.
 
I really like the way this is implemented; it adds a nice touch of flair while still keeping design standards. Very nice!
 
Would this be a good idea? Could it solve the desire for fast vs slow preview?
  1. Long initial wait time for the casual users
  2. Once that wait time is met the preview pops up
  3. Then it is in a 'quick preview' mode where there is no wait time when going between threads to see the other previews.
  4. Then it would require a full 1-2 seconds without showing a preview to go back to #1

?
 
Would this be a good idea? Could it solve the desire for fast vs slow preview?
  1. Long initial wait time for the casual users
  2. Once that wait time is met the preview pops up
  3. Then it is in a 'quick preview' mode where there is no wait time when going between threads to see the other previews.
  4. Then it would require a full 1-2 seconds without showing a preview to go back to #1
?

Seems kind of complicated and I think the behavior might just confuse people. :)
I should qualify my previous statement - although there are major technical challenges involved with placing the tooltip above the title, that is by far my preferred way of doing it. Mike and I have just been discussing a relatively major change to the approach in the code that might make this possible. I'll let you know.
Sorry, but this doesn't seem that hard to me at all.
  1. Append pop-up div to body like you've already done.
  2. Get height of div using .outerHeight().
  3. Get location of thread title/link using .offset() (I assume this is what you already do).
  4. Do the math. Its vertical location is the y coordinate given by offset() minus the height of the div given by outerHeight().
Theoretical working example:
Code:
$("div.title-link").click(function() {
    // code to fetch data and append div to body
    position = $(this).offset();
    $("div.preview#uniqueid").offset(function() {
        return {
            top: position.top - $(this).outerHeight(),
            left: position.left
        };
    });
}
 
I should qualify my previous statement - although there are major technical challenges involved with placing the tooltip above the title, that is by far my preferred way of doing it. Mike and I have just been discussing a relatively major change to the approach in the code that might make this possible. I'll let you know.

if you put the tooltip above the Title, then when hovering over the very first title in the list, it would cover the Forum-Title and the page-navigation......
 
if you put the tooltip above the Title, then when hovering over the very first title in the list, it would cover the Forum-Title and the page-navigation......
That's something that would rarely happen and is not nearly as big of a problem as covering the other thread titles. :)
 
if you put the tooltip above the Title, then when hovering over the very first title in the list, it would cover the Forum-Title and the page-navigation......

Uhh.... so what? :) I mean, you already know in what Forum you are, because you selected it to get to the threadlist in the first place! So what if you don't see the page-nav? You are in the threadlist hovering over the titles to see what the threads are all about... why does this interfere with page navigation?
 
On the contrary, this implementation penalizes the users with the slow connection as displaying each popup requires a separate request back to the server. My connection is unfortunately isn't that fast so I have to wait about a second for the content to appear in a popup.

From that reply, the main point seems to be:
But it works for vBulletin, doesn't it? Since it seems to be the gist of your reasoning, I went and checked the real performance impact of enabling the thread previews in vBulletin. Here are the durations of the relevant query (lowest values after a dozen of runs), for the page size of 25 threads:
0.00251 seconds with thread preview
0.00203 seconds without thread preview
+1

I totally agree to this, so, maybe it is possible to change this ?

Except this, i like:
- feature, generally
- preview above thread title (cause everything above you've seen/read already)
- style

gtx. juergen
 
First there was a problem that the last order description took off the screen down. Now the description opens up. Now the problem may arise in the first order. Maybe once you can do to automatically determine the top surface or bottom depending on which part of the screen is at present subject
 
I like that they are now animating to the top instead of the bottom. It not only looks better, but keeps the threads below visible too. Better UI over the whole line.
 
I like that they are now animating to the top instead of the bottom. It not only looks better, but keeps the threads below visible too. Better UI over the whole line.

I will not argue with you. I just suggest that float up or down depending on the position of the screen. That is, if closer to the top of a pop-up window down. And if closer to the bottom of a pop-up windows up. On my way is more convenient it would be
 
Top Bottom