By Vasken

The case against gratuitous Lorem Ipsum text

Caslon-schriftmusterblatt

My Lorem Ipsum tattoo on CheckOutMyInk.com

Let me preface this article by clearly stating that I’m not a designer. My background is solidly in the implementation side of things, which might be why I’m approaching this issue from what seems like a very biased viewpoint. If you are a designer, and you feel I’ve made some sort of horrible mistake, please don’t hesitate to let me know in the comments. Also, most of what I’m discussing here applies specifically to WordPress sites, which tend to be heavily publisher-focused and therefore contain user-generated content that the designer and engineer cannot control.

We’ve all seen the perils of using Lorem Ipsum or generic placeholder text to build static Photoshop mockups. Things like “Sample Title” never seem to work out right when translated to the web. A real headline, like, for example “The case against gratuitous Lorem Ipsum text” is a heck of a lot longer than the example, and forces the developer or web engineer to deal with the fallout.

The reason for this fallout, of course, is that the original design doesn’t account for flexible title lengths, and requires whoever implements it into the dynamic environment of the web to “guess” as to how the title element should flex to accommodate real-world content. In other words, by using generic text, the idea that the static mockup is just that–static–is reinforced to the client and even to the designer who created it.

Of course, as web design moves solidly away from static mockups and towards in-browser design, there’s a tendency to assume that the issue of design being too static is automatically eliminated. I’d argue this couldn’t be further from the truth. If an in-browser design uses generic titles and Lorem Ipsum content, anything can happen.

I’ve seen markup created that relied on a fixed-height title element. This created a huge problem when editors wanted to write an article with a title over 30 or so characters. I’ve also seen elements that relied on minimum content length that the generic copy provided. Once that markup intersected with real-world (sometimes very short) content, the sidebar collapsed underneath it. These are just a couple of examples–there are many more out there, and I’m sure everyone has their own stories about problematic user-generated content.

All of these problems end up being discovered during the implementation process, well into the process of designing and building a website. As a subscriber to Kevin Hoffman’s “iterate early” methodology, this late-round revision of markup and (maybe) design strikes me as highly inefficient and a major risk to on-time, on-budget project delivery.

So what’s the solution? Well, if you’re redesigning an existing site and have access to content, it’s probably best to use several examples of that content to test your in-browser design. It also helps (and this is admittedly difficult without trial and error) to think through possible content outliers and how they can affect design. While there are some seriously esoteric CSS bugs that will inevitably surface when a design is implemented into a dynamic website, testing a few common things can really help with most publishing-style sites:

  • A really short headline, e.g. “49ers Win
  • A really long headline, e.g. “Local residents up in arms over county officials’ stated desire to begin eradicating local mongoose population
  • Content that spans length from a few hundred characters up to several lengthy paragraphs
  • Enough navigation links in various nav bars to represent the actual number of options that will be on the site
  • A photo that is wider than it is tall; a photo that is taller than it is wide.

The good news here is that all of these things can be tested easily in your in-browser designs using some simple JavaScript. For example, by setting the text of the article title to several different lengths, you can easily test whether your design can handle flexible titles.

Similarly, if you’re unable to obtain actual short and long content examples (e.g. if you’re building an entirely new site), creating a small paragraph of sample text that you can then clone to create longer and longer articles is a handy trick for testing how your design handles different article content. I’ll be posting a couple of examples of these JS snippets in a follow-up to this article.

If you’re looking for some additional tips, this article provides a great walkthrough of how to overcome the Lorem Ipsum “crutch.”

Image source: http://www.checkoutmyink.com/tattoos/marquin23/my-lorem-ipsum-tattoo

Display Admin Notices in custom locations in the WordPress Dashboard

If you’ve used WordPress for a while, you’re probably familiar with the nice-looking notices (warnings and errors) that appear at the top of various admin pages:

Screen Shot 2013-02-05 at 2.46.59 PM

These notices are great for posting generic information relevant to a particular page up near the top, where they’ll be easily seen. But what if you want to use the .updated and .error classes to create messaging in other parts of the page? If you just add markup, it will move up to the heading of the page, because of the following JS that runs in wp-admin/js/common.js:

// Move .updated and .error alert boxes. Don't move boxes designed to be inline.
$('div.wrap h2:first').nextAll('div.updated, div.error').addClass('below-h2');
$('div.updated, div.error').not('.below-h2, .inline').insertAfter( $('div.wrap h2:first') );

This explains why messages get pushed to the top of the window regardless of where they are actually placed in the server-side markup. Also, it proveds a really easy way to put the message where you want it: just add a class of .inline and your message will stay where you want it.

Fixing Wi-Fi upload issues with a Sonic.net ZXV10 W300 modem/router

logo-white-half

I have Sonic.net for my ISP here in Oakland, and I’ve been pretty happy with the speed and consistency of the DSL service they provide. After returning from my latest visit to the East Coast, however, I discovered I had little to no upload bandwidth on my MacBook Pro. Trying various test sites yielded download speeds in the 12-14Mbps range, but the upload timed out on all of them. I was unable to send a test email from Apple Mail. If I plugged my MBP directly into the ZXV10 W300 modem/router combo that Sonic.net uses, everything worked fine, including standard upload speeds of 1Mbps (that’s why I’m only pretty happy with Sonic.net, by the way–I could really go for a slightly faster upload speed). I also noticed that in the Status menu of the router configuration page, there were a lot of Rx and Tx errors under the Wireless tab, which just didn’t seem good.

A few different things I tried didn’t help:

  • Checked and re-configured the modem according to the Sonic.net wiki (I changed the ‘Bridged’ setting to ‘Enabled’ as it was ‘Disabled’, no effect)
  • Restarted the modem
  • Restarted the MBP
  • Changed the channel on the WLAN from ‘Auto’ to 7, 8, and 11 in case someone had a router hard-coded to channel 1 (my auto-selected channel)
  • Put the MBP really, really close to the router

Here’s what did work:

  1. Log in to the router config page (type 192.168.1.1 into your browser URL bar, default username/password are both admin)
  2. Go to Interface Setup -> Wireless
  3. In the Multiple SSIDs Settings section, Authentication Type was set to WPA-PSK/WPA2-PSK
  4. The menu item directly below that, Encryption, was set to TKIP. When I pulled that menu down, the options available were TKIP and AES.
  5. I switched the Authentication Type to Disabled. NB: don’t leave your router set this way, unless you’re in the middle of the woods somewhere
  6. After re-testing the connection, I was able to upload normally.
  7. When I went to re-enable authentication, I re-chose WPA-PSK/WPA2-PSK.
  8. To my surprise, the Encryption pull-down now included the TKIP/AES option, which wasn’t there before. When I chose this option, my connection worked perfectly.

So, what could have caused this? I suspect that somehow the modem configuration got corrupted, or alternately TKIP-only encryption was working fine for a while, but stopped working with my MBP after a recent OS X 10.8 software update (I applied one while out of town). Either way, I don’t really care what broke, as long as I know how to fix it. If it happens again, that’ll point to the router as the culprit for sure, though.

Solving ‘org.apache.httpd: Already loaded’ error on Mac OS X Snow Leopard

I recently ran into a problem where my local Apache instance wasn’t responding to requests. Trying to restart or start it with sudo apachectl restart yielded an error message like this:

org.apache.httpd: Already loaded

Checking running processes, I noticed that apache wasn’t actually running, which seemed a bit strange. Luckily, apachectl offers a helpful command for checking your config syntax, apachectl configtest. Sure enough, it turned out I’d modified the httpd.conf a couple of weeks ago, but never rebooted Apache. Commenting out the offending line and starting Apache fixed the problem and I’m back up and running.

Mesquite-Smoked Cornish Game Hen

Following my successful foray into meat smoking with salmon, I decided to try some Cornish hen. Since the smoker I have doesn’t have anything near an accurate thermometer, I ordered the Maverick ET-73 Dual Probe remote model from Amazon, which made me feel a lot safer cooking poultry.

I brined the hens for a day in saltwater, cleaned them, and then rubbed them in dill. I tried to keep the smoker temp around 250 degrees, and it took the hens about 3 hours to come up to 160 degrees internally. Throughout I basted the birds with an apple barbeque sauce. For wood I used mesquite, because I haven’t gotten around to harvesting the nearest apple tree yet. Unfortunately, near the end with outside temps dropping and the charcoal starting to die, I wasn’t able to get the internal temp up to 165+, which is what I’d read was appropriate for Cornish hen. Sadly, I had to finish them in the oven for about 15 minutes to get them to the point where I felt they were ok to eat.

We ended up having the meat on sandwiches with olive oil mayo and onions. It was a bit dry because of the oven, but still pretty tasty.

image