The TH Design Blog!

Just one of those things intrepid designers come across unexpectedly and have to spend several hours trying to resolve. A new site design used a large background image for the homepage and variation of it for the inside pages. Everything was looking great on my mac and pc in IE, FF, Chrome, and Safari. Then I opened the site on my iPad 2 and had one of those moments. The site looked screwy, and it took a minute to figure out what was going wrong. It was the background images – they were being “shrunk”. An image that was 1800px wide by 1200px tall (only the central part of which would be visible through a smaller viewport like an iPad or laptop) was appearing on the page in it’s entirety, appearing to be about 500px wide and correspondingly short.

I had never run into this problem before – I’ve used large background tiles extensively and they all appeared just fine in the iPad. Even beginning to try to troubleshoot was a challenge as there’s not a lot of material out there on the web yet as compared to, say, Internet Explorer Bugs. I did all the usual things: checked my CSS and HTML at W3C—no help. Reviewed material on using background tiles—no help. There was nothing unusual about what I was doing that I could discern.

Next step was to post the problem on a couple of forums—two didn’t respond at all and the third responded but had no answer.

The third phase was to search in Google using one variation after another of the search phrase, trying to get some relevant results. And finally, after posing the tenth or eleventh variation of the question I hit paydirt.

These articles saved the day:
http://www.teknocat.org/blog/web-dev…-scaling-quirk

which linked to:

http://www.defusion.org.uk/archives/…iphone-safari/

The problem? The size of the background tiles. Basically the width times the height (1800 x 1200) could not exceed 2,000,000. If it did, Safari would shrink it (which is what it was doing). My home page tile was 2,160,000 and the inside tile even larger. Apparently it doesn’t matter what the combination of height & width are, as long as they don’t, when multiplied together, exceed 2,000,000. (The writers of the articles listed above discovered this quirk when working on iPhone designs and discovered it occurred on iPads as well.)

Back to Photoshop, various adjustments to deal with rough edges, tiles reduced and all was well.

You learn something new everyday!

One variation that I like re: navigation bar styling is to put bullets, “•” (or &8226;) between entries, a la: Home • Page 1 • Page 2 • Page 3

Easy to do when you can directly control the HTML, but making that work in WordPress was a puzzle. I didn’t want to simply label the Home entry as “Home •” because I apply color changes to page names on hovers and I don’t want the bullet to change color along with the page title. So they have to be entered separately.

Fortunately some good folks in the WordPress.org forums explained that you can use the Custom Links fields in the menu builder for this purpose. You enter a “#” in the URL field and “•” in the label field and then drag the custom link over between entries in the menu building pane, then rinse and repeat for however many bullets you need. The downside is that the bullet acts like a live link when you hover directly over it, i.e. it changes the cursor and shows an anchor link to nowhere. Some folks in the forums recommended deleting the # once the custom field has been moved over though there is the risk that future WP updates might render that a problem. 3.3 doesn’t seem to object, however so I’m going to remove the #’s.

The site using the bullets needed some additional adjusting, though. When I removed the # the bullet stopped being subject to the navbar links css styles and they would wobble when hovered over. Looking at the page through Firebug, custom links with # are designated as

<a href="#">•</a>

while the custom link with the # removed becomes

<a>•</a>

So I added an additional style for “#navbar a”, which resolved the wobble. (The new #navbar a style is just a repeat of the #navbar a:link style.)

You can use the Custom fields for creating placeholder labels too. For example, when a section is going to have drop-downs or flyouts but the label doesn’t really represent a page with content then you want the label to appear but not act like a link. Once again, you enter a # in the Url field, add your label to the label field, move it into the menu and remove the # from the Url field.

NOTE: In the case of placeholder labels, it turns out that if they don’t have the anchor link functioning, the associated dropdowns/flyouts won’t work on iPads or other devices that don’t recognize hover states. So don’t remove the #’s in those cases.

One of the great features of WordPress is that there are literally thousands of plugins that have been designed and coded to work in conjunction with WordPress Themes. You can find a plugin to do almost anything, at least to some degree.

Finding plugins is straightforward. Getting plugins to work, in contrast, can range from drop-dead easy to hair-pullingly challenging. This is partly because the plugins themselves may perform very simple functions, or very complex functions, and partly because the plugin developer may provide clear, simple instructions, or less-clear instructions, or no instructions. Developers also operate from very different vantage points in terms of their assumptions re: what you bring to the table. Most assume you’re well-versed in HTML and CSS at minimum; many assume you know PHP and still others assume you’re a whiz at all things AJAX, etc.

But, assuming for the sake of this post, that you’ve gotten the plugin to work, the next hurdle that sometimes manifests is how to style the plugin. Once again, sometimes it’s quite simple—the developer provides a user-friendly interface that offers everything you need—I’ve experienced that on at least 30% of the plugins I’ve used! Unfortunately, more often, figuring out where and how to make style changes turns into it’s own little project. Follows are some things to try when things aren’t easy or intuitive.

First, Check the Obvious

After plugins are activated they may generate an entire new section in your Dashboard Menu, or they may show up as a link buried in your Settings or Tools sections. You have to find the links and see what they have to offer. Unfortunately I’ve come across several plugins that provide plenty of options that you can set, none of which affect how the thing looks. In those cases you have to dig deeper.

Try the Readme.txt

Go to the Plugins Editor page, select the specific plugin, and take a look at all the associated files. You’re looking for the readme.txt file. Most of the time the readme.txt simply repeats the descriptions and instructions you already saw when you found the plugin, but sometimes there’s additional helpful information. Once in awhile the readme.txt will directly address the question of styling.

Some will say that you can duplicate the css file that comes with the plugin, place it in your theme directory and change the styles from there. (Keep the same name for the file. The copy in the Theme Directory will override the copy in the plugin’s directory.)

Some will indicate that you can make changes directly to the plugin’s css file. I always comment out the original style so that I can easily locate places I’ve made changes and see what the original styles were. Then I make a copy and save it to my computer so that if/when the plugin updates, I can reconfigure the new CSS file quickly.

Some will say that no styling has been provided and you can write your own! That means you have to look at the source code in your browser and figure out the relevant divs, ID’s and classes to create styles for. (Don’t be surprised to see long and compound names for ID’s and classes.)

Some, alas, will have nothing at all. At that point you can go directly to the CSS file that came with the plugin and see what you think. You might be able to go ahead and make a copy of it or make changes in it, as noted above. (Always add a comment containing the original style, and make a copy of the original file to your computer, just in case. That way if you screw something up you can fix it quickly.)

Create some CSS Around the Plugin

Sometimes the CSS file is so baffling that you can’t figure out what to style. Sometimes styles have been applied to groups, only one item of which you want to change. Once in awhile there’s no css file at all. In these cases you can often create a new div to place the plugin within, and then create styles for that div’s headers or paragraphs or margins or lists, etc.

Check the Developer’s Website For Help

Most plugin developers provide links to their websites. Support ranges from non-existent to “send me an email” to support forums. (I have run into 2 plugins recently that I liked but ultimately didn’t use because there was no contact mechanism to the developer at all. I don’t want to use something to solve a particular problem or create a particular effect, then have it stop working when WordPress upgrades. I fear that if the developer can’t be contacted, he or she may no longer be supporting the plugin.) Most developers offer some degree of support and will answer questions if they can, either directly or through a forum. Like everything else, their ability to help depends a lot on how close or far-removed their skill set is from yours. But it’s worth a try and I’ve had some great experiences with helpful developers.

Little Things Can Make Big Differences

Sometimes small style adjustments can make all the difference in blending a plugin into the feel and style of your theme. Plugins don’t always make that easy to do, but it’s always worth trying. You’ll find it gets easier after you’ve done it a few times!

Few things are more likely to ruin the day for a graphics professional than to have a client say something like “we’ve created a layout in Publisher and we’d like you to…” or “I’m sending you a PowerPoint file and can you…” or “I’ve set the brochure up in Word and I want to…”

Why all the consternation and dread? Word, Publisher and PowerPoint are perfectly fine applications geared to creating files that can be output on an office inkjet/laser printer or viewed on a monitor screen. However, for graphics professionals, Word, Publisher and PowerPoint lack the sophisticated tools necessary to create documents intended to be printed by a professional printer. In fact, many commercial print shops will not accept Word, Publisher or PowerPoint files and those that do more often than not will add a substantial surcharge to their bill to cover the cost of file conversion/re-creation.

I recently had the “pleasure” of converting/modifying  a couple of Publisher files for a local commercial printer. The task required several hours of finagling and experimentation to get the files into a usable format and while I was happy to bill for those hours, I would have much preferred to have spent the time doing something a little less taxing on my sanity.

Recently two individuals told me they had purchased a copy of Adobe’s Dreamweaver with the intentions of using it to build websites for their respective non-profit organizations. They were lured, they explained, by the promise of a WYSIWYG (what you see is what you get) interface that would enable them to build state-of-the-art websites without needing to know the underlying code. To their dismay, they were discovering that actually mastering Dreamweaver itself was turning into a massive effort. What they were expecting was a program that would be intuitively easy to use and what they got was an extremely deep program with a bewilderingly complex interface.

Ted wrote about how computers are marketed (in his post Easy & Simple—Not!) and software marketing is equally misleading. Dreamweaver, in particular, is a professional level tool that is marketed as being accessible to non-professionals. In the world of the web “professional” and “non-professional” are both elastic terms and there are certainly areas of overlap. But, by and large, most people confronted with Dreamweaver soon realize that using it requires a significant investment of time and effort, the fruits of which will still be disappointing. It’s one thing to create a set of web pages and it’s another thing entirely to create pages that work in multiple browsers, are search-engine friendly, are usable by a wide range of potential visitors, are visually pleasing, engender various forms of interactivity, etc. Like all software, GIGO (garbage in, garbage out) is the rule.

In point of fact, I think Dreamweaver is a great product. I just don’t think it’s a great product for non-professionals.