Implemented  hover over topic title shows part of the first post

This suggestion has been implemented. Votes are no longer accepted.
Hmm, I find that this method is a lot slow than vB's method.. I find it actually faster to middle click all the threads and read the first post in a new table rather than wait for the first post to load up partly the way its implemented currently.

The whole point of this feature is to save a user having to load a thread up to see if hes even interested in the thread but the way its currently implemented, it doesn't save any time at all..

Anyone else feel like that? May just be me..
I made the point yesterday almost immediately.

I find it quicker to open the thread and click back.

Yes the feature is cool but it's not that useful to me.
 
But the fade time to not show the overlay dissipates the instant you move the mouse off the title and it takes almost 2.2 seconds for overlay to be displayed (at least for me) so I guess I'm not seeing how it slows down browsing.
Also I think keeping it near your mouse pointer makes sense as thats where your field of vision is focused, I probably notice this as my pc monitors are 40",40" and 24.5 respectively and on the first two it makes a big difference but even on the 24.5 I don't see the issue... however

I wouldn't knock aligning it right as long as all the overlays display with conformity as the whole nature of this software as I understand it is based on nice clean and simple.
 
it could have the right edge lined up with the start of the replies/views column and make the preview box a fixed width if it isnt already
That would cause problems for those with low screen resolutions/fixed width unless the pop up was very narrow.
 
But the fade time to not show the overlay dissipates the instant you move the mouse off the title and it takes almost 2.2 seconds for overlay to be displayed (at least for me) so I guess I'm not seeing how it slows down browsing.
Also I think keeping it near your mouse pointer makes sense as thats where your field of vision is focused, I probably notice this as my pc monitors are 40",40" and 24.5 respectively and on the first two it makes a big difference but even on the 24.5 I don't see the issue... however

I wouldn't knock aligning it right as long as all the overlays display with conformity as the whole nature of this software as I understand it is based on nice clean and simple.
Aligning it right takes it -further- out of your field of vision in most cases. Longer threads especially, you'll have to move your eyesight further away from the title.

Aligning above the title works best, as you've usually read the previous titles in most cases. It is also just above your field of vision, meaning you really only need to glance up. 
 
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:
Shift right by 50px.webp

Shifted right and 10% transparency added to body:
Shift right and add transparency.webp

Positioned over metadata area:
Position right.webp

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.
 
I think the issue with your last option Kier is for those who use the fluid style and have wide monitors, the pop up will be a long way away from the thread title so will be disassociated.
 
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.
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.
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 )
maybe upon release a little snippit about where to change what to display the overlay how you see fit with a few examples of what they would change it to and everyone is happy.
 
I like the transparency one, but could the 50px offset be increased a little? 100px or so would probably be perfect (My mouse will usually hover closer to the middle of a topic).
 
Or maybe even adding in user prefrences a display section where user can pick all display options including which of three overlay orientations they would like use and all guests get the default one or none.

such as:
Display overlay preview [yes][no]
Use title relation ()
Use meta relation ()
Use page relation ()
 
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.
 
I like the transparency one, but could the 50px offset be increased a little? 100px or so would probably be perfect (My mouse will usually hover closer to the middle of a topic).
I was thinking that too. 100px would be preferable then it is a big enough gap for easy movement at the left but not too far that you cant see what is going on.
 
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.
:up: :up: (2 thumbs up)
yes, above and to the right (50-100px) would be the best choice
 
This is what I think it should look like:

View attachment 1292

With the pop-up off to the side it doesn't interfere with browsing other threads. The avatar is nice-looking but the date is redundant, so I removed it. What do you guys think? :)

Took me forever to do in Firebug. Those damn CSS "border triangles" are hard to work with. :p

Love it. I also believe that the date/time is redundant. What purpose does it serve if the exact same information can be found just a few centimeters above? But thinking again about it... maybe if you browse the threadlist thread by thread using the great new tooltip, your eyes are focussed more on the tooltips then on the info that can be found under the threadtitle and so you want that info in the tooltip. Not sure.

But putting it on the right instead of underneath the threadtitle seems to solve the issue of covering up the threads that are below the actual thread indeed. But also, it will make the position of the tooltip different on every thread. I need to play around it a little more to see how it all works out for me in practice now (and I've yet need to read the other comments after your post also).
 
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 its not possible (After trying what you have in mind), don't waste more time trying to adjust to it; as long as the margin is wide enough, people will be fine with it, or get use to it.

So far, I love the implementation, I just don't really need it myself, so it tends to get in the way. I just need enough room where I can speed-click topics to open them, and be on my way ;)
 
@kmike i feel what your saying and ultimately you have to think of all users too , a lot of people have painfully slow connections and i would have to assume that yours is quick. A user with less than a meg for connection will greatly value this change the way it is ... as a whole page load for them can take the time you can read it in. :)
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:
If first post snippets are to be fetched along with the list of threads, it requires joining the post table to the thread table in the SQL query that grabs the list of threads. This has a major performance penalty and we decided not to do it for the sake of thread previews that are often not going to be seen.
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
But in reality, the spread in query run times makes them almost equal. As you see, the difference is in fraction of millisecond.
The only real issue here would be the infamous table locking. But from the experience, this query was never a problematic one in vBulletin. The members' posting activity must be through the roof for this query to cause the post table locking.

I made the point yesterday almost immediately.

I find it quicker to open the thread and click back.

Yes the feature is cool but it's not that useful to me.
Ditto. But I don't think anything will be changed at this point as it looks like the majority of the members here prefers this implementation (simplicity always loses to a visual bling).
 
Top Bottom