Question Your Best Practices
Starting at Viget a little over a month ago inspired me to take stock of the best practices that I’d developed over the years. From whole workflows to the smallest code snippet, I decided it was time to upend everything that I thought was perfect and bomb–proof to see what still made sense. The result was that I uncovered a few IE6 cockroaches hiding in the corners as well as a few other things that I had lazily relied on, without question, for years.
What did I find?
I discovered one surprising, and embarrassing, theme: forward–compatibility can make us, as front–end developers, complacent.
Tried and true techniques that worked in IE6 will, not surprisingly, still work in IE9 (and every other modern browser) — and that’s not necessarily a good thing. As browser development marches on and we stop supporting older versions we also need to re–evaluate the techniques we had been using to support those browsers.
Dropping support shouldn’t just mean not firing it up in a virtual machine to see how things look and work. It gives us the opportunity to clear out the cruft and move forward.
For Example
Look at the good old Suckerfish dropdown menu technique. I’ve been thoughtlessly, but successfully, using JavaScript to aid dropdown navigation and other hover interactions for years. Why? Because IE6 didn’t recognize the :hover pseudo class on elements other than links and JavaScript intervention was necessary. When you take IE6 out of the equation (and we all should) things get much simpler and you can use pure CSS.
So why was I still using this antiquated technique? Because browsers happily run whatever error–free code we give them — even when it could be better, or more modern. Quite simply: it worked. It has always worked and always will work and no browser is ever going to complain about it. Talk about a smooth–running bomber technique — and a perfect example of something that had to go.
We’ve all done it
By now you’re thinking “duh, Jeremy, I haven’t used JavaScript in my dropdowns for years”. Good for you! But I bet you’ve got something else hiding in the attic. Care to share one?
Moving Forward
So where’s the impetus to change when there’s virtually no friction? Refactoring code and removing unnecessary parts makes it simpler, smaller, more easily maintainable and less error prone. I think we can all agree that those are good things.
But there’s something more — it’s about being actively engaged in our craft. The speed of progress can cause us to hide behind best practices like a shelter from the storm of blog posts touting the newest thing. The key is finding a balance between stability and progression — or maybe you just need to upend everything once in a while.
Think about your favorite code snippet. If you had to rebuild it today, wouldn’t it be better? What’s your technique for keeping things current while still maintaining standards that speed up your day–to–day work?
CSS Strategy Square-off
It’s an exciting time for CSS. On top of the advances being made both in what to write (CSS3) and what to write with (SASS+Compass, Less), CSS is enjoying a spate of serious discussion over how it should be written.
This might come as a suprise to some (and did to me). After all, CSS seems pretty straightforward — without many of the complexities of programming, CSS has long been seen as something you just write. After all, it’s not particularly hard to write good CSS and markup; so long as your definition of “good” means “looks right, seems consistent, has semantic value”, you’ve generally gotten a pass.
The question recently posed is: is this definition of good, originating from the dark ages of table layouts, good enough to deal with the problems CSS encounters in 2011?
The answer might depend on a few things: first, whether you observe such problems, and second, whether you see them as sufficiently difficult to work with. As I see them:
Misinterpreting Minimalism
As of late, I've noticed there are quite a few websites popping up that are designed in a minimalist aesthetic. I believe designing in this style requires more attention to typography and grid systems to be effective. Unfortunately, this is not the case with many examples I've seen. I find there are too many concepts, ideas and products in this world that would benefit from a stronger visual aesthetic. With poorly executed minimalism, designers lose the chance of communicating a visual message. My concern is similar to a post of Owen's a little while back and how some people are overly inspired by visual trends, which leads to the demise of content and creativity.
Designers: Are You Asking Questions About UX?
A few weeks ago I posted a tweet to designers saying, "If you're not asking questions about the UX that gets handed to you, you're not doing your job." Responses varied from general agreement to my favorite sarcastic remark, "If you're not asking questions about the UX handed 2 u, you're not doing your job MY BEST FRIEND" (by UXer @malhinha)," and "If you get handed UX at all, you're luckier than most designers" (by @simonmeek).
The Case for UX
If you don't have wireframes and other UX deliverables to work with, I empathize with you, because I've been in your shoes. It's not fun! It's time-consuming and limits your ability to do your best work. Many designers are often left wearing the UX hat because UX is the new design...anybody can do it, right? I was guilty of thinking this until I started working with great UXers who are incredibly skilled at their craft. We don't treat our UX team as a luxury, but rather as a necessity. The value that they provide to project teams and clients can be measured in time, money, conversion rates, innovation ... The list goes on.
Continue reading "Designers: Are You Asking Questions About UX?"
7 Simple Photoshop Typography Tips You’re Already Doing, Right?
Just because you can do something in Photoshop doesn't mean you should do it, especially if you're designing web sites in Photoshop. This is most definitely true of how you handle typography in Photoshop. It's always frustrating to painstakingly craft your type, just to find out it's impossible or impractical to use it the way you envisioned in the finished product. Here's a list of little things you can do to ensure that the design you create in Photoshop will and can be perfectly translated into a built-out site. They're mostly common sense, but I know I've been guilty of just about all of them at some point, so hopefully this is a helpful refresher.
Continue reading "7 Simple Photoshop Typography Tips You’re Already Doing, Right?"
Mood Boards: Dressing For Different Occasions
For designers at Viget, Mood Boards are consistently among our favorite topics to discuss and deliverables to create. I wanted to shed a little more light on the subject to talk about some variations of the practice and how we look at them at Viget. Essentially, mood boards aren't a one-size-fits-all kind of thing and we have different approaches to them. Ultimately, we always have the same goal in mind – to start broad in efforts to get early feedback that will allow us to narrow our focus as we begin to work on the details of a design. I originally approached this subject back in 2008 looking at two variations of mood boards. Since then, our two variations have morphed into three. Here are some examples that illustrate what we mean.
Continue reading "Mood Boards: Dressing For Different Occasions"
Notes From Our Default ExpressionEngine Build
This post is intended to build off of Doug’s Post: ExpressionEngine on Multiple Machines. So if you haven’t read that, I’ll wait for you.
All caught up? Ok, let’s go.
I’ve been lucky enough to build 3 EE sites in the past few months, so it’s given me time to look at our setup, make changes, and even to build some add-ons. I was hoping to share more about our default build, and maybe there are a few tips and tricks you might find useful.
Continue reading "Notes From Our Default ExpressionEngine Build"
2011