Stories from my Life as a Technologist
I think the hardest part of moving the website into WordPress is recoding the site, not only for WordPress, but also into HTML5 and CSS3 standards, which involves making someone else’s code work and playing with a ColdFusion template as well. So, here’s my summary of the week represented by a KawaiiNot comic.
UPDATE: I posted a newer analysis in June 2012.
A lot harder than I thought, I can tell you that.
I did have a few requirements:
Preferred options include:
I tested a lot of plugins (at least a dozen), many of which didn’t work. My guess is that many are dependent on its own version of jQuery and other js files that conflicted with the built-in WordPress one or incompatible with the newest WordPress in some other way.
Many of the plugins are based on the jQuery Nivo Slider, which is free. Why not just use that? Well, we want our users to be able to add images themselves, and not rely on our team. The Nivo Slider developers offer a WordPress version, but it’s paid. It’s a fairly small amount though so I might recommend purchasing it instead of having to customize existing plugins, especially if it’s a one-time payment.
As a beginner coder, I generally assume that if something goes wrong it’s my code. While it’s true that a website needs to be coded in such a way that it’s interoperable, sometimes the problem originates in the browser. This may seem obvious to any web programmer, but it wasn’t to me, mostly because the assumption really is, “I’m not an expert, so the mistake must be something in my code.”
In my case, I was having issues with font sizes, and this is such a basic part of CSS that it never occurred to me that it was a browser issue. Lo and behold, it turns out the current version of Chrome (17.0.963.79) rounds font-sizes to the nearest whole number, and I was doing calculations based on Chrome. Because of this bug, the site I was formatting looked very different.
For example, say I have:
h2 { font-size: 1.2em; }
h3 { font-size: 1.17em; }Firefox: h2 = 19.2px , h3 = 18.7167px
IE9: h2 = 19.2px, h3 = 18.68(?)px
but Chrome: h2 and h3 = 19pxSee jsFiddle example.
While these differences are so small you can barely tell in the example, you can imagine that on an entire website, it has a pretty big effect especially if it’s a base font size. In the end, I filed a Chrome bug report and it’s being looked at.
In our website’s book banner, there is a little styling trick in order to make it look nicer. What really got me was that it was using absolute positioning (which generally I avoid). However, if you make it relative, it no longer does what it’s supposed to.
Have something like this in the CSS:
span {
position: absolute;
top: 1em;
left: 1em;
border: 10px solid transparent;
border-right: 10px solid blue;
}
span+span {
position: relative;
left: 2em;
}
the HTML should then have an empty block: <span></span><span></span>Result:
If you want to play with it, it’s on jsfiddle
So far, I haven’t found an answer, so I’ve simply recoded it to make it work in the new layout. Now the strange thing is that it works on MAC, but breaks using the same browsers on Windows.
This week, I started creating a WordPress theme for our website, and in doing so, spent a lot of time reading on making a website accessible for persons with disabilities. While we do have legislation stating that all university websites need to be accessible by next year (?) (Accessibility for Ontarians with Disabilities Act (AODA)), our university and library take pride in being accessible. For some reason though, our website is not all that accessible.
Now on version 2.0, most government and public organizations are being held accountable in being compliant with the Web Content Accessibility Guidelines (WCAG). The guidelines divides up the requirements into three levels: A, AA, AAA. While the guidelines themselves are a little hard to decipher, w3 provides a customizable quick reference to break the guidelines down into a more readable document.
When it comes to the general design of the website, it’s actually fairly simple.
The bottom line: your website should work (and make sense) even without JavaScript and CSS, and in text-only mode.
I don’t think a lot of people realize that designing a website to be accessible is not the hard part. The hard part in an organization is making sure that the content posted on the website is accessible. In particular, audio/visual elements should have text alternatives, whether that be closed captions, alt text or transcripts.
In order to ensure that content is also accessible, web developers need to work with other staff whether inside their own department or in the greater institution to educate staff who are creating content, because even something as simple as images need text alternatives.
At a college or university, best to contact the accessibility centre/unit on campus to work with them. They might already have the tools or know-how to make a/v content accessible.
So, why reinvent the wheel? That’s what I thought anyway, but there are some issues with using an existing theme and modifying it. I wanted one that was in HTML5/CSS3, and then I later discovered that it should also be using the WordPress Settings API (which was difficult because it was only added in 2.7 so not everyone is using it).
Long story short, I didn’t find any, but then in looking through the files, it turns out the built-in/sample WordPress theme TwentyEleven fits all of these requirements! They do not tout that the theme is accessible, but many of the elements are present in the theme.
I will be posting more once the theme is done (or mostly done anyway) with more details on any changes I will have to make, but I’m thinking they will be very few if any.
You can find a rather extensive list of tools for evaluating accessibility on the w3c website, but one of the most useful I found was: WAVE, which provides different views of a webpage with alerts and errors (there is also a browser plugin version). There are also a number of good colour contrast checkers browser plugins.
With Google’s new policy in effect, there is currently no shortage of news articles and blog posts about how to protect your information from Google. I think it’s great that people are becoming more aware of the effects of how one big company can track you, but this has been going on for many years, just never in one nice neat package as Google is talking about now. [Too long? Skip to the Summary at the bottom]
While zdnet.com and many others focus specifically on Google, but just recently in the news, Target figure out a teenage girl was pregnant before her father, and NYTimes did a piece on how it’s not just Target, but any and every corporation you shop with. Mind you, if you shop at various stores for various people, it might be harder for one single company to track you, but online is a whole other world.
Online is different, because you can be tracked from one website to another. Particularly when you’re signed in, every search you do is put into your history. Even when you’re not signed in, you’ll be tracked by IP address (but on the up side, rarely does anyone have a truly static IP at home or at work). Your search results will be skewed based personalized data, not just ads, but search results as well. dontbubble.us provides a nicely illustrated explanation of how it works and why it’s important.
Online is also different because it’s not just Google tracking you, trackers are built into sites that follow you on the web to build a profile on your behaviour (and very few sites do not have this). Check out donttrack.us for another illustrated explanation, but if you really want to see how insidious behavioural trackers are, take a look at Collusion, which will give you a demo on a short journey on the web from IMDB to news sites.
So how do we protect ourselves from all of this? Live in a cave. No really, practically speaking, there is no way to prevent being tracked and having personal information stored some way or another. It’s no secret that every app and every site that has access will keep information on you and many will sell it to advertisers.
Nevertheless, while it’s virtually impossible to prevent tracking altogether, you can prevent advertisers from building a profile about you to a larger or lesser degree.
Just about everyone has covered this, and zdnet.com provides a nice summary with lots of links, but here are some direct links:
You could also of course, delete your Google account completely and not use any Google products. (Just saying.)
Plugins are nothing knew as a way to help manage privacy and security in browsers. At the bottom of donttrack.us, there is a list of browser plugins you can consider. Some of these are only supported by one or two browsers, but similar plugins are available for other browsers. In particular, I use:
For greater anonymity, add HTTPS Everywhere and Tor. Not on the donttrack list is: TrackerBlock for Firefox, and Internet Explorer.
Changing some of your security and privacy settings in your browser will also help. The farther down the list, the more extreme you get, but they’re there to consider.
Opera actually has a great guide to security and privacy covering a lot of Opera settings on one handy page.
Admittedly, I find it hard to do without using any Google products having a gmail account including googletalk, and Google Reader (if someone has suggestions on an alternative that is just as good, I’d love to hear it). Nevertheless, at work, I will log into Google with one browser while using a different browser for everything else. At home, googletalk pops up email in my default browser, so I make sure to log out when I’m done.
On the more extreme side of things, you can set up your work flow such that nothing is stored locally, check out a blog post on microcosm about browsing privately.
While some of these options are great for those who are tech-savvy enough, many of these options will create barriers for those who would prefer some protection but with the same experience as before. In those cases, I recommend:
Of course, it’s all about the individual. If they can handle NoScript (which is fairly easy to use once you’re taught), that’s great. The problem is always if the user encounters an error or some functionality that isn’t working properly because it’s being blocked. It’s great if they’re willing to call you and you can talk them through it on the phone, but otherwise, we all know how frustrating it can be for something to not work like we think it should.
Some key takeaways if you thought that was a bit long to read through.
