No, this is not about plagiarism.
Imagine my surprise when Jeffrey Zeldman blogged about a list of 60 WordPress themes. A few minutes before that, I found Douglas Bowman bookmarking another list, also from Smashing Magazine. It’s like my feed reader was trying to tell me something: yes, a list article can bring an interesting discussion if you’ll just let it.
Back to Zeldman’s post, which started a discussion on whether you should use existing themes for your own design:
…Even if you are a designer, you may ask yourself if you really need to perform that next site redesign from scratch.
Every once in a while I get clients that specifically want existing themes to be customized instead of starting from scratch, so clearly there is a demand for the practice. If clients have enough initiative to choose it as a solution, then why not? Does it take more effort to find and customize than start from scratch? Depends on how comfortable you are with someone else’s code, how much you trust the other designer’s expertise, and how much you need to customize.
The bulk of the debate will probably lie mostly in this situation, but to me it boils down to don’t reinvent the wheel, but don’t get complacent either. While it is a shortcut for building a website, it is not a shortcut for conceptualizing the website.
So the other situation is this: Sometimes I envy all the beautiful themes and templates out there because I don’t really get an opportunity to use them for myself. Does choosing to use someone else’s work for a web designer’s own website make sense? It seems counterintuitive but a real problem: sometimes we barely have time to dedicate to our own projects. Sometimes we just want to use something ready-made and have fun with it.
Although there are frameworks for practically level of development these days, from CSS to JS to PHP to whole themes, they are created specifically as tools for designers; they aren’t really products for designers as consumers. What I’m talking about are the real themes that are smart enough, beautifully-designed enough to meet your discerning needs. It could be as stark as Cutline or as detailed as WordFolio: compare this and this. (Now that would be good idea for a list article: websites that are highly customized versions of existing themes. Not to mention a good source of inspiration. A niche gallery, even!)
We could probably exclude portfolio sites since web designers would prefer to show off their skills on them—but even that argument can be ruled out if the customization is custom enough. Take blogs, tumblelogs, and other secondary sites that still belong to a web designer but don’t necessarily need a design from scratch. The issues with the client scenario website still apply, but there’s the added pressure of being your own worst critic.
Would you be confident enough to use one, or would you lose sleep at night without customizing at least some bit of it to keep your design cred intact? It doesn’t have to be a bad thing; it could be a different type of challenge.
Jon Tangerine, David DeSandro, Trent Walton have all come up with ingenious ways to create image-free logotypes by pushing the limits of CSS (Sean Martell made a mouth-watering CSS-based logo too, but doesn’t contain text) that one has to wonder: is this the next step in online branding and identity?
The simplest argument against this could be that a logo must be constant. In the absence of CSS styling, possibly even helper JavaScript, an image will not suddenly morph into a default browser style and render a brand generic. See the image above for how the CSS-based Opera logo degrades in different browsers.
Now that excludes the scenario where images are turned off, and where text—styled text—can come in. Instead of simple image replacement techniques, we now have @font-face embedding and other advanced effects to bring the text as close as possible to the original design.
Text is great because you can read it, as can search engines. Another thing text based logos have going for them is they’re easier to make bigger; that’ll win over a lot of clients.
But there’s a great deal of extra markup required to achieve the necessary look. Does this make sense for the notion of a logo, which is inherently more portable with an image than with a bunch of divs, spans, classes and IDs? Should logos always be images and nothing but, or can they be both text and images? Which should come first, designing the logo in the browser or in a graphics program? Or should all of this experimentation remain just that: experiments?
Me, I just love we could be on the brink of shattering print conventions, yet again.
Google is throwing its own hat into the web fonts ring with the Google Font Directory and the Google Font API. While it appears it doesn’t have any partnerships with the big names in typography like TypeKit does, just a handful of open fonts, it does have a partnership with TypeKit itself (as you’ll see below).
How the Google Font API works
Once you pick a font, you can embed it on a webpage by grabbing code that looks like this:
<link href='http://fonts.googleapis.com/css?family=Josefin+Sans+Std+Light' rel='stylesheet' type='text/css'>
And use it in your stylesheet like this:
h1 { font-family: 'Josefin Sans Std Light', arial, serif; }
You can also use other fonts using the WebFont Loader, which is a JavaScript library developed by Google and TypeKit.
Bane or Boon?
Although I won’t be ditching Font Squirrel anytime soon, one great thing about this new development is that the fonts are hosted on the most reliable servers in the world, just like the different JavaScript libraries are. The even greater thing is that this is Google, one of the strongest forces on the Web, is placing a stake another aspect of web standards.
Of course those things are scary at the same time. Google can just pick any endeavor under the sun, spend resources on it, and possibly dominate, if not dictate the market in no time. It may not get the purist designer types on board, since Google doesn’t exactly have the best reputation for great design, and its presentation has a bit of a developer slant, but it knows its web design technologies well. And in the case of web standards, where new practices are being adopted and old browsers are being discarded at a snail’s pace, Google’s massive resources and influence can only do well to speed things up.
Remember my complaint about all the CSS3 syntaxes differing from one browser to another? It’s now addressed with CSS3 Please, a jQuery-based, in-browser editor that replaces multiple attribute values of the more complicated CSS3 syntaxes (from border-radius to rgba to @font-face) all at the same time, so you don’t have to.
In addition to syncing and normalizing changes across the necessary properties, it also sneaks in IE support for a few features via IE filters. Right now it helps you write the rules for: border-radius, box-shadow, linear-gradients, rotation and @font-face. A few more transforms like skew and scale are on their way, stay tuned.
You can preview your code on the box at the right side by toggling it on and off. When you’re done, click on the clipboard icon to copy the code.
This is a smart solution to a growing problem. However, even though I’m thoroughly grateful for this tool, I still want to axe the real problem, which is the inconsistent browser syntax. It’s unreasonable for a programming language to have redundant code, and while CSS isn’t really one, it’s still code. We’re still supposed to pride ourselves with efficiency, conciseness, and standards with any kind of code. We like to kick IE for constantly breaking standards; should we tolerate the same thing for other browsers just because they’re implementing cutting edge features?
According to Ajaxian, the beloved tradition of learning by peeking at someone else’s source code is on the brink of extinction. Because Google is rewarding websites that load faster, people will stop at nothing to look good in the big G’s eyes, including code compression and more notably, obfuscation. This renders View Source useless.
While I feel it’s too early to call doomsday on View Source because of such speculation, like many I feel protective over it. It’s no surprise then that the Save View Source movement has been formed this early. The discussion is sparse, but Alex Russell elegantly explains why View Source matters, also reminding me why I love developing on the Web:
View-source provides a powerful catalyst to creating a culture of shared learning and learning-by-doing, which in turn helps formulate a mental model of the relationship between input and output faster. Web developers get started by taking some code, pasting it into a file, saving, loading it in a browser and hitting ctrl-r. Web developers switch between editor and browser between even the most minor changes. This is a stark contrast with technologies that impose a compilation step where the process of seeing what was done requires an intermediate step. In other words, immediacy of output helps build an understanding of how the system will behave, and ctrl-r becomes a seductive and productive way for developers to accelerate their learning in the copy-paste-tweak loop.
Even in compiling languages people learn better by looking at example code, but the culture of open learning can be felt strongest on the Web. Ajaxian posts a follow-up, in which I couldn’t agree more with this:
I personally feel like the ability to view source fit in perfectly with the culture of the Web, and was especially important early on. I am willing to bet that we have all learned from the notion of view source.
The freedom of access to tons of information on the Web is what it all boils down to. View Source is a sturdy consequence of that. It seems wrong to compare performance versus learning, but between those two, learning should prevail.
Then again, who can stand in the way of site owners desperate to turn up traffic and profit? Sounds like standards versus SEO all over again. What do you think—is the Save View Source movement an overreaction or a preemptive strike?
*/
