Liquid Change

CSS for the ::selection pseudo-element

liquid06 — Wed, 22 Jun 2011 05:01:47 +0000

Selecting an element that has a text-shadow applied can make the text look less readable. I wanted to include some detailed selection styles to remove the text shadow and add a background color that matches the colors throughout the rest of the site, so I added this to my stylesheet:

::-moz-selection, ::selection { text-shadow: none; background: #4F74C5; color: #FFF; }

I wrote that after reading these notes from Mozilla’s documentation, and I thought it would cover all browsers, but I wasn’t seeing the change applied in Firefox. After clearing the browser cache, refreshing a bunch of times, clearing the Drupal site cache and refreshing a bunch more times, I tried changing my CSS file like this:

::-moz-selection { text-shadow: none; background: #4F74C5; color: #FFF; } ::selection { text-shadow: none; background: #4F74C5; color: #FFF; }

And then it was applied in all browsers. Hm. Redundant, but OK. Why?

Because while unknown properties are ignored individually (rgba, -moz and -webkit,) selectors are ignored as a group. So if there is one selector in the comma-separated list that the browser didn’t understand it would ignore the whole group.

Ubuntu 10.10 uses an amazing font by default

liquid06 — Mon, 20 Dec 2010 05:26:13 +0000

When you’re making something that other people are going to use to make things, helping them make something beautiful by default means that they’ll make more things and enjoy your product more.

I installed Ubuntu 10.10 out of necessity. It hadn’t been that long since I upgraded to 10.04, but I have a Dell Inspiron 1545 and the screen flicker problem that persists in 10.04 was too annoying for me. I can’t get anything done if I keep getting distracted by the bottom half of my display suddenly becoming red horizontal lines like some strange flash on the screen in a movie when they’re trying to portray the main character losing their grip on sanity.

Anyway, I am so impressed by 10.10 because of the ubuntu font family. With the Chrome extension that displays all web pages in the new typeface, everything is suddenly important and beautiful. It feels light and airy, and I don’t feel like I am worthy of writing this post. My words are not beautiful, true, or important enough to be expressed by these letterforms.

OK, maybe that’s a little melodramatic. But I’m really happy about it!

Pet peeve: Referring to your layout in your copy

liquid06 — Sun, 19 Dec 2010 05:17:52 +0000

Copywriting for the web is not easy – that’s why there are smart and talented people who get paid to take care of this important and delicate aspect of communication. But not every design/development shop/department is staffed with these sorts of people. I’m no professional when it comes to any kind of writing, but I think one of my pet peeves from the perspective of a user can serve as good advice for do-it-yourself copywriters.

Here’s my non-professional advice

Don’t include the visual location of elements of your layout in your copy text.

If someone can’t find the button you want them to click, then that’s a usability problem. As a general rule of thumb: if you feel you need to add instructions, maybe you should re-think the design. Users want to feel powerful – like they know what to do. They want to feel smart – when you walk them though every step, that does not make them feel smart. But that’s beside the point. Back to referring to layout in your copy.

One of the main reasons that you should avoid referring to your layout in your copy is that the layout won’t stay the same forever. Hopefully there are people managing the website who want to continue making it better – if they’re making it better, there’s a chance that they’re going to change the layout. If you’ve got instructions that refer to the old layout, then the user experience for those that need the instructions can be rather annoying and sometimes confusing. You could update the directions to refer to the new layout, but do you want to do that every time? Why not make it so easy that you don’t need any instructions at all?

Example 1 – a personal blog

I saw one example on a personal blog. I can’t find the link at the moment, but the text read something like “To see the blogs that I like, check out the blogroll in the right sidebar.”

Problems

the site had been redesigned since that had been written, and the blogroll was actually on the left.
I’m not sure that the body of the page is the best place to describe what your blogroll is. If you don’t think your audience is going to know what “blogroll” means, then maybe you could instead
- Include that statement in the same area as the links to other blogs (proximity)
- Change the label “blogroll” to something else that’s more easy to understand.

Example 2 – a calendar on a computer training website

This website sells training in programming-related topics. Since I’m seeking training for work, and the site was recommended by a colleague, my expectation was that the site would be really professional. This bit of copy really didn’t make a very good impression on me. (I had intended to go get a screengrab to demonstrate the layout, but when I tried the link today it had an error 500 and I couldn’t access it!) Anyway, the copy went like this:

“We also provide course calendar information in the form of an RSS feed. This feed allows you to create a bookmark in some browsers, that is dynamically updated with our latest course calendar. If you are using a browser, such as Firefox, that supports this feature, click on the RSS button at the bottom of your browser window to add a “live” bookmark to our calendar.”

— http://www.otg-nc.com/training-course-calendar/

Problems

Browsers change. The most recent version of Firefox actually displays the RSS icon in the address bar, and Opera displays an icon there but doesn’t offer live bookmarks. Chrome doesn’t offer this feature, and I refuse to open IE to see what it does.
It seems rather noble to provide such instructions – you’re educating them! But it also hints that live bookmarks are the only way or the best way to use an RSS feed – we’re not getting the whole story here.
It doesn’t seem like the target customers of the site will actually need these instructions.

Example 3 – Dryad data

I was curious about this dryad site – I followed a link from somewhere else so I was clicking around in the informational pages. Including explicit instructions here seemed appropriate, but the text read:

“The best way to find data in Dryad is to search, using the search box at the top left of the page.”

– http://www.datadryad.org/using

Hmmm. I see a search box in the top right of the page. I think this could have been communicated just as clearly without referring to the visual location of the search box.

What if I don’t have a top-left corner on my page?

I’m a sighted user, but I know not all users are. How does referring to the visual location of an element in your instructional copy further confuse and waste the time of a user browsing the web using a screen reader, or using an alternate layout to zoom the text?

My two cents

Don’t refer to areas of your layout in your site copy. If you feel like you have to include instructions (especially for end-users), there’s probably a larger problem that you’re trying to band-aid. You should fix the problem instead of covering it over with words. Referring to the visual location of something leaves you with copy that’s out of date if you ever change the layout, and it doesn’t work if your users are browsing with a screenreader or another method that displays your page differently than you see it.

Multisite Drupal installation in a subdirectory

liquid06 — Sat, 11 Dec 2010 15:44:42 +0000

I’ve forgotten the little details of this so often…hey, maybe I should write it down!
liquid06@ocelot:/var/www$ drush dl drupal Project drupal (6.19) downloaded to /var/www/drupal-6.19/. [success] liquid06@ocelot:/var/www$ mv drupal-6.19 coolsite liquid06@ocelot:/var/www$ cd coolsite/sites/default liquid06@ocelot:/var/www/coolsite/sites/default$ cp default.settings.php settings.php liquid06@ocelot:/var/www/coolsite/sites/default$ cd ../ liquid06@ocelot:/var/www/coolsite/sites$ cp -R default localhost.coolsite.subsite liquid06@ocelot:/var/www/coolsite/sites$ sudo chown -R liquid06.www-data * liquid06@ocelot:/var/www/coolsite/sites$ sudo chmod -R 775 * liquid06@ocelot:/var/www/coolsite/sites$ cd ../ liquid06@ocelot:/var/www/coolsite$ ln -s . subsite liquid06@ocelot:/var/www/coolsite$ mysql -u root -p mysql> create database coolsite; Query OK, 1 row affected (0.03 sec)


mysql> create database coolsite_subsite;

Query OK, 1 row affected (0.00 sec)
mysql> grant all on coolsite.* to cooluser@localhost identified by 'password';

Query OK, 0 rows affected (0.05 sec)

mysql> grant all on coolsite_subsite.* to subsiteuser@localhost identified by 'password'; Query OK, 0 rows affected (0.00 sec)

Next, open up a web browser, visit localhost/coolsite and run the install script. Then visit localhost/coolsite/subsite and run the install script there.

Recovering From Bad Block Code

liquid06 — Sat, 04 Dec 2010 13:00:57 +0000

So, I’m a newb – I don’t know how to write PHP code properly. I get error messages frequently and they give me hints as to where I’ve screwed up. But I’m not totally new to Drupal. I know that custom blocks with PHP code are possible, and I’ve had quite a few that worked just fine. Most of that code was terribly simple – printing the base path and the path to the theme to get the src for an image. It seemed so innocent! But when I made one little typo, I learned that any PHP blocks, no matter how simple, might not be a good idea. From terribly simple to simply terrible.

White screen of death on the entire site! Fantastic!

Helpful drupal.org node number 166556 gave me a hint – oh, I just need to disable the problem block in the blocks table. Of course! From selecting around in the blocks table, I figured out my problem block’s ID number, but the status column was already set to zero. Ah, right. That’s because I’m too cool for admin/build/block since I learned about context. I guess I expected the content of my block to be stored in the blocks table, well, just because of the name, but as it turns out the block body isn’t kept there.

Context keeps its stuff in a table, but I soon read through the serialized array far enough to see that the status of the block I was interested in was already set to '0'. I could delete the block from the blocks table, but what would happen to that context record? What a mess.

It seemed like the easiest thing to would be to correct the typo in the actual body of the block code…If I could just find it.

I probably picked the most awkward way to figure out which table I was looking for: I made a mysqldump and searched for a string that I knew was part of the bad block code. Well, it worked! I finally figured out that the body of a custom block gets stored in the boxes table. Huh, I guess I didn’t see it because of all those content_field_* tables crowding up the show tables listing.

OK, I’ve learned something though: Block content is stored in the boxes table. Once I knew that, I updated the ‘body’ field for the problem block and was able to regain control of my site.

But now I understand one of the reasons why PHP code in blocks really isn’t a good idea!