Bingo!!

[Michael Morris]

Well, as you suggest, that argument works for technology, for things that provide a function, like the menu bar. However, that argument is pretty darned weak when applied to the cosmetic things like colors and logos. There is no functional need to change them. We don't fall "behind the times" if the logo doesn't change. And black and charcoal are not going to become obsolete and cease to be supported on Windows systems any time soon.

Umbran, if we left the colors exactly as they came with the program the body would be purple, the text black and the background white & light purple. VBulletin doesn't give a rat's tail what the colors are when it renders the page, and the number of color sets have no bearing WHATSOEVER on the speed of the server or the render of the page.

The controlling script for the menus, mm_menu.js, is used successfully on some thousands of websites, corporate and otherwise, with no problem.

I was running mm_menu.js as it's own file, but for nearly TWO MONTHS the mm_menu.js script was piggy backing with vbulletin_global.js - I simply tacked it into that file, while I was running code tests to try to find a way to implement the code. In that entire time NOONE complained of a slowdown.

This morning I put mm_menu.js back into vbulletin_global.js to see if it would affect the rendering speed of the pages on my system. I tested it on Opera, NS 7 and IE 6 and it did speed up the rendering by about 2 seconds (Note there is a BIG difference between a loading time and a rendering time). Yes, even I noticed a slightly slower rendering from the start, but I feel that if the whole page switch is done in under 5 seconds that's acceptable. Maybe I'm too patient, I dunno.

 

[LightPhoenix]

Yayhoo!!!

Good work Michael! I'm glad that's solved.

As for the change issue, there's no need for change because people have choices, which is the whole point of style sheets. If you choose to use the original style, great! If not, well you have several themes that you can use. This way a majority of people are happy.

 

[Psionicist]

This can be solved by putting the whole document header (not technically speaking) such as the ENW-logo, the dropdown menu and all the buttons (user cp, settings etc..) and the banners inside an IFRAME with a width of 100% and a fixed height of about 300 pixels (also, for cosmetics, an invisible black border).

The iframe content is cacheable.

Edit:: "height" not "size".

 

[the Jester]

Hey Michael, I just wanted to chime in here and let you know that your hard work is appreciated. I suspect that everyone will eventually come around, at least once the slowdown is gone for them, with the possible exception of 'Old Skool' diaglo.

 

[Umbran]

Umbran, if we left the colors exactly as they came with the program the body would be purple, the text black and the background white & light purple. VBulletin doesn't give a rat's tail what the colors are when it renders the page, and the number of color sets have no bearing WHATSOEVER on the speed of the server or the render of the page.

I know that. Sorry, but you're conflating two separate lines of discussion.

You yourself partly mention it here - VBulletin doesn't care what the colors are, or what the logos look like. There is no technical reason to change them. Back when you suggested new default colors and logo, you got resistance. The analogy DM Magic made to technological advancement as a defense of that sort of change doesn't hold, because there's no technological difference between blue and black.

Simply put - the issues of color and logo are matters of taste only. There is no accounting for taste, meaning that there's no objective argument that one is better than another. So, you'll meet resistance, and you'll have no objective and substantive defense for the change. Moreso when the current colors have been in place for so long that they are certainly part of the "look and feel" of the place.

That's all completely separate from the menu-bar/slowdown issues.

This morning I put mm_menu.js back into vbulletin_global.js to see if it would affect the rendering speed of the pages on my system. I tested it on Opera, NS 7 and IE 6 and it did speed up the rendering by about 2 seconds (Note there is a BIG difference between a loading time and a rendering time). Yes, even I noticed a slightly slower rendering from the start, but I feel that if the whole page switch is done in under 5 seconds that's acceptable. Maybe I'm too patient, I dunno.

Interesting. You're noting a couple seconds difference in rendering speed, separate from any download speed issues? Alone, that's not much, however, do you get something more when you add in the extra download time because the script wasn't cached and the extra server load (on a server that seems to have been somehow taxed already) from all the requests for the script? You imply such above. If that starts reaching into an extra 5 seconds per page, people will notice.

And the users are humans. If they see anything that inconveniences them, even for 5 seconds, then they'll gripe.

 

[Umbran]

OH YEAH?! Well... uh... YOUR MOMMA!

So, you think you're big enough for that, hm?

Well maybe you should prove it.

Maybe you should come over here and... lick this freezing cold metal pole.

I dare you. I double dog dare you.



(edit: hoping the reference doesn't get this kicked over into the Movies & TV forum)

 

[Michael Morris]

This can be solved by putting the whole document header (not technically speaking) such as the ENW-logo, the dropdown menu and all the buttons (user cp, settings etc..) and the banners inside an IFRAME with a width of 100% and a fixed height of about 300 pixels (also, for cosmetics, an invisible black border).

The iframe content is cacheable.

Edit:: "height" not "size".

Won't work. Tried that awhile ago.