Break My Design: a Call for Web Site Testers
The new design for Little Elegy is finished, and I’m looking for a few good testers to help me squash the last bugs. I can’t afford a “real” usability test, so I’m enlisting you, my readers.
Please visit the temporary test site I’ve established, browse around, read some stories, and print a few pages. If something breaks, doesn’t work the way you think it should, or looks screwy please let me know in the comments. If you find the site’s layout or navigation confusing, tell me how you think it’s broken and how you’d fix it. I can’t promise that all your suggestions will make it onto the final site, but I can promise that I’ll consider them all. In the end, Colleen has final say over the site since it’s for her zine. The site is (finally) live. Feel free to drop in.
If you have the time, I’d also be interested in hearing your thoughts about the new site compared to the current one old one.
So, what’s new here?
- The site is now compliant with the latest in web standards and technology, and should be equally accessible to desktop browsers, hand-held computer users, cell phones, and visually impaired folks who use screen readers. It’s not just a nice thing to do, it’s the law.
- The titles of the site’s child pages are done in a font called “A Yummy Apology,” which not many people have. I’d previously used a type of font embedding that only worked for Internet Explorer on Windows, so that at least someone could see it. Everyone else got the default page font. This time I used sIFR, which only requires JavaScript and the Flash plugin and should work for about 90–95% of web users.
- Layout has undergone some subtle changes to make the site both more attractive and easier to read.
- Miscellaneous behind-the-scenes stuff that makes the site easier to maintain
Here are the known problems with the new site:
The search results page looks different than the rest of the site, and all the links lead you back to the current site instead of the new one. This is because the Atomz search service that we’re currently using hasn’t yet been replaced with a better alternative. With the test site sharing a results template with the “real” site, the results are going to have to be consistent with the older site for now.(Fixed — Sorta. Still no new search engine, but Atomz account has been terminated. Site search currently offline.)The sIFR-replaced heading text doesn’t look quite right in Opera web browsers. This is because Opera doesn’t support Flash transparency. I’ve made the fall-back background color as close as possible to the page’s background image, and I can’t really tell the difference unless I look very closely. I’d be interested in hearing how it looks on differently-calibrated monitors. This problem may also exist in some versions of Apple’s Safari browser.(Fixed — Not a problem in Opera 8.0 and up; status unknown in latest Safari.)The pages are automagically printer-friendly thanks to the magic of CSS. However, an Internet Explorer bug causes page titles to appear on a separate line from the Little Elegy logo when child pages are printed. I haven’t figured out how to correct this minor problem.(Skipped — Problem appears unfixable due to IE bug; too minor to tear hair out over.)NEW: There seems to be a problem with sIFR text on Mac browsers. One person has reported that he sees a plain font instead of sIFR using both Firefox and Safari on a Mac. iCapture shows no page headings at all except for the search page (and/or the first page of the site visited, still trying to clarify that), where it properly shows the script fond that I’ve added with sIFR. I can’t replicate either problem in Konqueror for Linux, which uses the same rendering engine as Safari. Can anyone else confirm this problem and describe it in more detail?(Fixed)NEW: Background image doesn’t tile properly in Safari or Linux Konqueror.(Fixed — The cause was a problem with my CSS that the W3C validator didn’t catch.)
To learn how to report bugs effectively, you may wish to read Simon Tatham’s primer on bug reporting. Screenshots would be appreciated when reporting layout-related problems or visual bugs, but are not required.
Thanks in advance for your help.


Looks good in both Firefox/Mac and Safari. However, I’m not seeing sIFR at all in either browsers; rather, the headings all appear to be plain Georgia. Other than that, it appears to be quite functional.
Comment by Chris Vincent — January 13, 2005 @ 3:21 pm
That’s odd. I’ve got this in the head:
<script type="text/javascript" src="assets/sifr/sifr.js"></script>and this just before
</body>:<script language="javascript" type="text/javascript"><!--if(typeof sIFR == "function"){sIFR.replaceElement("h1", "<?php echo $abspath; ?>assets/sifr/a_yummy_apology.swf", "#003300", null, null,"#f8f8f8", 0, 0, 0, 0, "offsetTop=2&offsetLeft=2", null,"transparent");//named({sColor : "#003300", sBgColor : "f8f8f8", sFlashVars :"offsetLeft=2&offsetTop=2", sWmode : "transparent"}));};--></script>Where
$abspath == "http://www.adammessinger.com/littleelegy/"(which will change later).Does past experience with sIFR give you any clue where that might’ve gone wrong?
Thanks to your mention of the page rendering in Georgia, I’ve beefed up my fallback fonts in the CSS. You should no longer see Georgia so long as you have one of the following fonts installed: Berling Antiqua, Berling, Book Antiqua, or Garamond.
I like Georgia for a lot of things, but it’s not right for this web site.
Thanks for your input!
Comment by Adam M. — January 13, 2005 @ 7:16 pm
I posted a comment to Mike Davidson’s sIFR 2.0 RC3 announcement post, asking for more input from Mac users and some help determining the cause of sIFR problems. So far, word is that the sIFR works fine on Macs.
Chris, if you’re watching comments on this post can you give me more details on your setup?
Comment by Adam M. — February 1, 2005 @ 10:59 am