Notes on the 2008 Redesign: User Feedback
First of all, thank you to everyone who provided screenshots, feedback, and ideas for the new design. Your help is highly valued and greatly appreciated. From what I am hearing, the redesign seems to have been well-received, with many readers and visitors taking the time to leave a comment, send a screenshot, or email a message. As hoped, people seem to enjoy the vibrant colors, the translucent panels, and the fancy sliding menus.
Other people have pointed out the site’s oversize width. On screens that are 1024 pixels (or less) in width, the design triggers the hideous horizontal scrollbar. Using a 1024-pixel width was a conscious decision based on sound statistical information and a desire to maximize screen area. Based on my statistics, approximately 85% of visitors view the site through a monitor that is greater than 1024 pixels in width:
Another point of concern is the relative opacity of the rounded-corner background panels. Unfortunately, transparency/opacity varies greatly across browsers, operating systems, platforms, monitors, ambient lighting, psychological disposition, and many other external factors. Apparently, Mac screens tend to display brighter and more vividly than others, thereby reducing the effective opacity of the background panels and thus affecting content readability. So, depending on the set brightness of your monitor (along with many other factors), the colorful background image may interfere with your viewing experience and thus decrease overall site usability.
Viewing the site through my 22-inch HP widescreen monitor, everything appears exactly as intended:
Relative design opacity as seen on my personal monitor [full view]
Moving on, a less-critical concern addresses the relative widths of the two central columns. As you can see, the difference in width between the main column and the side column is minimal. This similarity in column widths is awkward for some viewers, especially those with a keen eye for compositional balance and proportional harmony. After all, the vast majority of sidebars are significantly less wide than primary content areas. In fact, many designs feature sidebars that are narrowed further with two or more subdivisions.
After much contemplation concerning the ideal sidebar strategy, I decided to centralize site navigation by maximizing sidebar real-estate. At first, the design featured two columns of equivalent widths; however, even with the extra-wide, 1024-pixel
<body> width, the primary column would have been too narrow to accommodate existing post content. This design constraint was essentially set with the previous design, which boasts an ultra-narrow, singular-column width of 500 pixels. Thus, for the new design, the main column requires at least 500 pixels, leaving slightly less for the sidebar.
Beyond these three concerns — screen width, panel width, panel opacity — there are many other great suggestions for improving and enhancing the new design. Here are a few of the more useful ideas:
- Decrease the height of the header area to display more content
- Decrease the contrast of the body text to improve readability
- Add a jump menu similar to the one used in the previous theme
- Add Gravatar support to comment area and recent comments panel
- Add quicktags, threaded comments, and quick-reply to comments
- Allow the background image to scroll or fade it out sooner
- Eliminate some items from the sidebar (e.g., Tumblr feed)
- Integrate show/hide toggling of individual comments
- Add some large social media buttons after each post
- Improve font selection for main paragraph text
All of these are good ideas, and I intend to implement many of them, but for now I need a break from doing any more work on the new design in order to prevent burnout. Frankly, I almost reached that point the night before releasing the theme, but fortunately the thrill of the launch pulled me through. It’s like, you can only stare at a design for so long before it either stops making sense or begins to making you sick. Needless to say, after four weeks and a few hundred hours working on the new “Quintessential” design, I need to break away and work on other projects for awhile. Eventually and most likely gradually, many of these suggestions will be implemented as opportunities arise. You know how it goes: setup a new theme, use it for awhile, make a few changes here and there, more use, more tweaks — wash, rinse, repeat.
For now, I feel comfortable with the design “as-is.” As I use the design, changes are inevitable, although I can’t say to what extent. Obviously, structural changes involving increasing
<body> and column widths require more work than presentational changes involving opacity and contrast adjustments. Chances are that my next redesign will be a comprehensive “realignment” of this new design, much like the “Optimized” and “Lithium” themes were re-workings of the original “Jupiter” design. Realignments are an excellent way to improve your site without sacrificing brand recognition. In any case, I am planning on tweaking the site during the next few days, so if you happen to notice any of the changes, drop a comment and let me know if they are for better or worse.
Well, if you want it to be more FF and CPU-friendly, you should remove the transparency for when you present code. It doesn’t matter how transparent the tables are; what matters is how many levels of transparency you do. With some of your tables, you have a transparent table on top of a transparent table, and that makes the lag on FF.
There is also the possibility that it’s the image map mixed with the transparency doing it.
I doubt it, but it’s a possibility. It’s such a large image that it is possible it slows FF to render it, especially since ‘technically’ it’s rendering it many many times, but in different positions.
From doing Myspace layouts many years ago I learned the hard way that you should only use one level of transparency and never ever have it overlapping. Transparency is a form of post-processing for a website and when you add a trans on top of a trans (could be small or large area), you end up with many times the normal CPU power required. When you do a second level of transparency is makes the CPU work 4-fold. Firefox is smart in that it doesn’t allow itself to use up more CPU then it should.
About the borders, yes I mean the ‘glowing’ borders around the tables. Which may be the biggest reason for the rendering problem in FF. Not sure though, you’d have to test it.
Also, if your looking for better cross-browser compatibility, then try using PHP to change the css and other things based on the browser. I’ve been doing that and it works flawlessly. The only reason it wouldn’t work is if it’s some obscure or really old browser, but even then I have a fail-safe that makes any browser not detected by the simple script use a default css.
Like you I’m obsessed about looks and optimization at once.
Oops, I meant to include this in the previous comment, my bad:
May I ask how large your HTaccess is? Like in Kb. I’m wondering because I have this superstition to not let it go around 10Kb or more or else it’ll slow my website down. Currently it’s around 6Kb.
I’m sure I once read somewhere that IE and various other browsers will use the GPU for dealing with transparency and such (maybe related to DirectX), whereas Firefox dumps it all on the CPU.
I personally haven’t noticed any lag, but then I’m browsing on an overclocked Core 2 quad – perhaps it’s simply masking it. I’ve opened the site and scrolled around in both IE7 and Firefox and there’s practically no discernible performance difference.
@Cooltad: interesting points about Firefox transparency rendering. I will definitely be working on the re-styling of the preformatted text areas. I think the same general appearance is possible without relying on transparency. This will also help with readability, because as it is now, the currently displayed text color is the brightest it can be given the current transparency level. Hopefully, I will find time for it later today..
As for the glowing borders, they are positioned as background images in a cascading arrangement of layout
divs. No tables or image maps are used anywhere on the site. Further, the background images that comprise the glowing borders are employed via two sets of image sprites, with one containing (among other things) both the top and bottom portions of the entire panel (including the borders), and the other sprite containing (among other things) the central, repeating panel background image.
I recently had a discussion concerning the use of browser-detection scripts. Without opening that can of worms again, suffice it to say that I would be interested in checking out new scripts, but as of yet have not been found success in terms of foolproof detection. There always seems to be some browser or device, proxy, or greasemonkey script, etc. that seems to prevent any of the scripts I have tried from working “flawlessly.” Of course, that’s not to say that a “perfect” script doesn’t exist, only that I have yet to discover it.
About htaccess file size, currently the root htaccess file for this site weighs in at around 5.82KB. Keep in mind that when it comes to htaccess and performance, size is of less importance than the directives you are using. I don’t buy the 10KB (or whatever) myth, but there is certainly a correlation between file size and performance. It may not be linear, but it certainly exists.
@Ryan: yes, that would certainly explain it.. I have also noticed that on my (newer, faster) Macbook, Firefox renders everything with virtually no lag whatsoever. For this same reason, Safari is quickly becoming one of my favorite browsers :P
Either way, it is great to hear that your machine is rendering even the heavily formatted, double-transparent
<pre>content with nary a hitch. (I think I am experiencing a bit of “processor envy”!:)
Btw, what kind of Internet connection are you using (just out of curiosity)?
I’m on ADSL2. My line is rated at 24mb/s, but in reality I pull a maximum of about 2300kB/s.
@Cooltad: as suggested, I would be interested in checking out that detection script of yours, assuming you are willing to share it! ;)
@Ryan: Nice! :)
Actually, to me an image map is where you make a large image that contains all of the images for the website and then position the image in different ways. A good method for lowering the number of http requests.
The script I use for browser detection is simple, but it covers all of the bases, and even has an [/else] for just in case some strange browser or script allows the user to pass by the script. In that [/else] scenario, I supply the normal css, without any fixes for any browser differences.
I don’t allow detection of the Chrome browser and custom css for that yet, but if you use Chrome on my site you’ll still get a nice css because of the [/else]. (for kicks i have an html comment near the top of the source telling the person what browser they’re using)
@ cooltad, link to your site and a sneak at teh script would be great :D
Actually I’m embarrassed to show my website, as it is not done yet. But I will when I’m finished the banner for it. It’s going to be an interactive banner where things happen etc when you hover over parts of it. The great thing about it is it’ll be done with only css and html.
My website is actually for my clan in games. You can look at the previous revision of the website, back when it was on a crappy free-forum here:
Keeping in mind though that website is very old and my skills multiplied greatly since then.
Well, definitely share it when you get it done.. the CSS/HTML interactivity sounds interesting. When do you expect to have it finished?
That t3clan site looked pretty cool, although I was redirected two or three times before finally settling on a page :p Are you using that detection script you mentioned there on that site? If so, it seems to be working! ;)
Not on the T3 clan one, I have it meta-redirect to the newer site for my clan. In the site it redirects you to, look at the source and see the magic.