Bumbling highlights square.

Go into your control panel and in Edit Options there's an option to "disable tooltips".

I went ahead and changed the way it works so it doesn't follow your mouse around anymore, and you have to pause over a link before it appears. Better?

But I need them for other things (and they appear after a delay there). I just don't want them appearing constantly on the topic titles (which started happening today).

When you disable them in your control panel they appear the way they did up to today (generated by your web browser instead of via JavaScript).

I went ahead and changed the way it works so it doesn't follow your mouse around anymore, and you have to pause over a link before it appears. Better?

A little. It still appears instantly as soon as I stop the mouse, and the text still spills out of the square if a url is in the first few lines.

And sometimes I get two squares, one on top of the other, with different text, when I hover over one of the icons.

It's back!
And it is very annoying!

OK, I turned off tooltips, and it works right. But why do you have such an annoying feature?

Because I love it. I had to put it back b/c I missed it too much, and when it didn't follow the mouse around, it was nearly identical to having it disabled and using the browser's tooltips.

It's as annoying as the moving ads.

I turned it off.

That's why the option is there. Disabling it in your CP simply puts the same information into a browser tooltip (which appears when you hover over a link for a few seconds). The tooltip feature is just a more instantaneous way of displaying the same information.

For people like me, it's nice because it lets me quickly scan a list of threads to see what interests me without having to stop over each link for 5 seconds.

That stupid thing is back! And the selection to remove it is GONE!

Please remember that you put the ability to disable it there because it drives some people's visual systems nuts.

Actually that's not true. We were having a problem with some of the JavaScript features on the page causing problems like people's browsers hanging and freezing up, and taking a ridicoulously long amount of time to load. Since I knew it was a JavaScript problem, but didn't know exactly WHICH JavaScript was the cause, I provided the option to disable each of the JS features I thought was the culprit one at a time, so the problem could be debugged systematically (excluding one at a time for a large group of members, since everyone seemed to be experiencing different problems depending on their system). It turned out that the problem was related to the rounding corners script for everyone, and so that has now been removed.

...but now, by reading the latest feedback on the issue, you realize that the annoyance of the hover previews is unrelated to speed, and that the all-or-nothing option of disabling all client-side JavaScript does not address the issue. Also, removing control over an aspect of the site that was previously optional is in hindsight, perhaps, not wise. I respectfully request, as an interested reader/user of the site, that you make this optional again. It dramatically, negatively, affects the usability and enjoyment of the site.

About an hour ago I made a change where the hover tooltips no longer follow the mouse cursor. They also now wait for you to pause over the link before they go into effect. This is the behaviour they have been at for the past 2 years complaint-free. The complaints around them started coming in a few months ago when I changed the behaviour to follow the mouse, hence being like "bumbling bees" following you around.

Tack my name onto the list of people who prefer separate JavaScript disablement options.

I can understand those who have been complaining about the way the hovers have been following the mouse cursor around as of a couple of months ago. But now it's back to the way it's been for the last 2+ years with no complaints?

It's not a huge deal for me, I simply said I preferred separate options. Basically I still want AJAX, but I want to disable some of the other stuff (like floating popup windows) which slows down the site.

Floating popup windows??

Dani, your "no complaints" argument is your standard flawed reasoning. The only feedback that matters is the feedback you've been given. You can make no assumptions about this nebulous "non-feedback / non-complaint" crowd. Hey, George Bush hasn't complained anywhere about Daniweb - he must endorse it!

There is no downside to making these things optional. Those who don't complain and like all the defaults will leave things alone. Those who want to disable certain options, can. Where's the issue?

I love the tool tips too, some people are disabled and just can't write proper subject lines. The java mouse overs are far quicker than opening the link and waiting for the thread to load only to find nothing of interest.

You know you can get anyone to do anything if you ask in the right way.

Dani, your site is truely awsome, and just a couple of months back there were these totaly cool options in the control panel that let me configure the javascript at a very granular level. Those options blew me away I was in options heaven, is it possible in your busy diary to bring them back please?

Floating popup windows??

Bumbling highlights square. Thread preview window. Whatever you want to call it.

Well they don't bumble anymore :)

Yay! The bees are bee-ten.

Now fix the smileys so we can tell what we are getting. We now see the code instead of the smiley.

And people would use code blocks more if they had the button available in the quick reply box.

You're seeing a stripped down WYSIWYG editor because you have JavaScript features disabled. Because the bumble-bee tooltips are gone, you can now safely return to reenabling JavaScript features. The ability to disable all of the JS features is really reserved for people with very slow computers or dial-up connections, so they can still have an enjoyable DaniWeb experience even though it may be lacking in some of the more elaborate (and less necessary) bells and whistles.

As mentioned in a previous post, the vBulletin editor has rather messy code, and I was unable to find an easy way to add additional buttons to the Quickreply box. The next version of vBulletin is going to be migrating to the Yahoo! JavaScript API which means the QuickReply box will be rewritten for the most part. So I'll take a look at it when that happens. In the meantime, I'm not going to waste hours of time trying to figure out h ow to add a button to code that is so messy that the developers have already acknowledged it's being rewritten in the next version.

It seems to be working now. I was getting a different editor I hadn't seen before at times. It had dropdown menus for text color, smileys, and attachments. But instead of visible smileys in the dropdown, I saw the codes for the smileys. And the editor selector was missing

As you can see from the earlier post, I switched the scripting back on.

I still see the code for the smileys in the text, but not in the dripdown menu. And the spellchecker says the smiley is spelled wrong.

I had to start over again on this post, because I got "Database error" when I tried to go advanced to get the stupid smiley. When I hit back from the error message, the text I wrote was gone.

Messy code? Maybe they used the Cuisinart I mentioned in another thread. :icon_mrgreen:

The systems I don't have trouble are done by IPB.

Dani, your "no complaints" argument is your standard flawed reasoning. The only feedback that matters is the feedback you've been given.

No, you're standing on flawed reasoning. Feedback is not a scientific poll.

Indeed. Otherwise if 197,421 members said nothing and one said they wanted every message to start with Dear Doctor, this message would have started with Dear Doctor. :)

No, you're standing on flawed reasoning. Feedback is not a scientific poll.

Wait a minute, back up the bus. No one claimed that feedback was a scientific poll. I'm saying, the only feedback you have is feedback given. That's all. If you are using feedback to make decisions about the site, scientific or not, then those are your parameters.

You can make no assumptions whatsoever about feedback not given. The vast majority of site users float in and out without perhaps ever noticing a certain aspect of the site. Dani assumes that since they didn't complain, they must be in favor. That's an unwarranted assumption and is not a sound basis for making decisions.

Feedback may not be either, but that's the system in place. So when 6 or so users complain about something, you can't balance that against the 97,000 who don't, assume that's 97,000 in FAVOR, and ignore the 6 who care enough to give feedback because they are the minority. Flawed reasoning.

You take those 6 votes, ask for more feedback, ("Is anyone in FAVOR of the way things are...?) and make a decision on that feedback. While not scientific, it's better than giving "opinions in my favor" to people who've expressed no opinion at all.

While all feedback is always appreciated and always taken into consideration, decisions which affect the grand scheme of things are never made exclusively based on feedback or polls from community members posting in this forum. It would be impractical to make a business decision which affects millions based on a tally of pro and con comments posted by 5 or 10 or even 20 people.

Decisions are typically made behind the scenes, using a wide variety of resources such as working with advisors, varoius in-person focus groups, and by data mining statistics such as tracking browsing habits throughout DaniWeb.

For example (a completely arbitrary and theoretical example, mind you), suppose 15 people say they love the navigation drop down menu and 1 person complains about it saying it's terrible. Navigational statistics might prove that only 15% of DaniWeb's audience uses the navigation menu while the remaining 85% go out of their way in their browsing habits to avoid it. In such a case, tracking the patterns of millions upon millions of visitors tells a better tale than 16 comments posted.

Public feedback from members is very important because it adds real voices to the numbers. For example, in the scenerio above, it's clear from the data collected that the navigation menu isn't working and so first instinct might be to remove it because it's doing damage when so many people alter their browsing habits just to avoid it. However, even though 15 people posted that loved the menu, the one person who didn't like it might have posted what he didn't like about it. That one post of feedback might influence a change to be made to the navigation menu to where the majority of website visitors now use it regularly. Had I not been paying close attention to statistics, and simply relied on public feedback first and foremost, I would have thought that the navigation menu was working just fine and just one person wasn't crazy about it. In that way, statistical data and public feedback work together to influence decisions.