Food For Thought #8
You should consider spending less time talking, and more time prototyping, especially if you're not very good at talking or PowerPoint. Your code can be a very persuasive argument.
You should consider spending less time talking, and more time prototyping, especially if you're not very good at talking or PowerPoint. Your code can be a very persuasive argument.
I'm a big fan of music. I'd like nothing more than to make a living developing websites for bands and helping them cultivate their online presence. Only one thing stands in my way: bands don't normally have a lot of money. If most local bands spend more than a couple thousand dollars on a website, it's just not going to be cost effective for them. Since the budgets are normally tight in comparison to the work involved, it's usually best to think creatively. With a little ingenuity, content management for band websites could be run completely off a few third-party services. The three services I've been looking at are Virb, Muxtape and Reverbnation.
Virb just launched a new version of their website, after an 18-month overhaul. Of the three, Virb seems to be the current, best option for the design conscious. As expected, you can manage news, tour dates and upload music. Additionally, Virb offers unlimited audio uploads, an RSS feed for news and a highly customizable, clean audio player, however no RSS or iCal feed for tour dates. While the social networking aspects are currently in place, using Virb as a band CMS is still not completely there. However, a Virb API and Virb Push service are in development, which could provide direct access to content on Virb band profiles.
Muxtape recently relaunched after completely switching gears. It's currently a public beta and invitation only, but there are seemingly big things going on behind the scenes. As hinted at on the Muxtape website and a blog post from lead developer, Luke Crawford, Muxtape is vying to become a one-stop shop for bands. It could potentially handle everything a band could require, but that capability has yet to materialize.
As it stands, Reverbnation is the most complete resource. In addition to providing the basics, the service provides FanReach mailing list management, distributed media tracking, street teams and digital distribution. They provide RSS feeds for news and tour dates. However, the provided widgets and embeds are not customizable and, frankly, pretty ugly. It's not so much that they're the most hideous widgets out there, but that they can't be integrated nicely into a design.
I realize there are many other things to consider for bands, but I'm looking at these services stricly from the standpoint of providing basic content management. To make this type of thing work, you essentially just need RSS feeds or an API. The overall idea is to update one place and have that information distributed to the various endpoints through some kind of syndication and custom widgets. It would be greate to have everything in one place as well as have some control visually, which is why I will probably wait on Virb or Muxtape to get a little further along.
One caveat is the management of photos and video. I always recommend utilizing Flickr and Vimeo (or YouTube), because I like the services and they are completely open. Virb already supports feeding in photos and video from said services. I'm sure Muxtape will follow suit. Reverbnation, however, is pretty closed, as they want to be a turnkey operation for bands. That makes Reverbnation a turnoff, in my opinion. I think bands should use every venue to promote themselves. If a photo on Flickr or a video on Vimeo leads someone to buy an album, I think it's worth managing those types of media separately. Especially, if everything is feeding into your website anyway.
Most of us are aware of how to specify media types to serve different stylesheets; the two types most used being 'print' and 'screen'. However, it wasn't until I researched a way to specify stylesheets by device that I stumbled across Media Queries.
Media Queries is currently a working W3C draft and part of the CSS3 effort, even though it was originally submitted in 2001.
A media query consists of a media type and zero or more expressions to limit the scope of style sheets. Among the media features that can be used in media queries are 'width', 'height', and 'color'. By using media queries, presentations can be tailored to a specific range of output devices without changing the content itself.
An example of how to write a media query:
<link rel="stylesheet" media="screen and (color)" href="example.css" />
Since this is a CSS3 feature, most browsers aren't going to support it yet. However, it works with Safari and should fail gracefully elsewhere. If you need to serve an iPhone-only stylesheet just set media to:
only screen and (max-device-width: 480px)
In December, I followed along as 24 Ways published their web geek advent calendar. It was one of the more helpful sets of "tips n' tricks" articles regarding web development and I recommend checking it out if you have not.
One article that was particularly interesting to me was Sitewide Search On A Shoe String by Christian Heilmann. Heilmann essentially explained how to build a sitewide search utilizing Yahoo! BOSS (Build Your Own Search Service). However, I am not a Yahoo! fan and more interested in getting something like this working with Google Search.
The idea was forgotten until I searched for something on Serious Eats, one of the better foodie blogs around. Serious Eats uses the Google Custom Search API and integrates the search results directly into their own page style. Exactly what I was after.
I hope to rework the search functionality on Silent Uproar this year. There are tens of thousands of items posted on Silent Uproar and this type of solution suits the content perfectly. With over 50% of our traffic coming from Google Search, it just makes the most sense; Google clearly has the best search service, so it benefits me to utilize their technology. I realize this isn't the best solution for every website, but it's better than not including search services in a project—especially if you have a lot of static pages.
On a related note, I was reading back through Jeff Atwood's The Importance of Sitemaps from last year. In the post, Atwood discusses how Google drives over 50% of the traffic to Stack Overflow, which parellels Silent Uproar quite well. He then goes on to talk about how sitemaps can help boost that traffic further. Putting two and two together: since Google Custom Search utilizes Google's index to display results, it would seem that creating sitemaps would give Custom Search a leg up. Low and behold, a quick Google search later and we have Sitemaps offer better coverage for your Custom Search Engine from Google's Webmaster Central Blog.
You still have to put the work into implementing Google Custom Search. However, do it once and you can use it over and over. If anything, it makes creating a sitewide search seem a lot less daunting.
Order and complexity, however, cannot exist without each other. Complexity without order produces confusion—order without complexity produces boredom.
Using custom fonts on the web, other than the dozen or so standards faces, has been "the next big thing" for the past several years. We've been teased with the proposed ability to embed custom fonts into web pages since the CSS2 specification submitted in 1998. However, until a major font foundry or company (like Adobe or Microsoft) decides to release a new set of fonts for public use, we're probably out of luck.
sIFR, the brainchild of Shaun Inman, has filled the void. Mike Davidson and Mark Wubben have picked up the torch and run with the technology. sIFR 3.0 is currently in the works and addresses a bevy of issues, like consistent font tuning across platforms. However, sIFR is both a blessing and a curse. Since each instance of sIFR becomes an embedded Flash movie, excessive use of sIFR slows down page load. Basically, if you try to use sIFR for more than headlines, then it starts to become more of a problem. While everything is best in moderation, body copy could use a little love, too.
Most folks are waiting on the CSS3 @font-face module to gain traction, but it's wrought with the same issues as the CSS2 spec. Jon Tan covers the topic more thoroughly than I ever will on this blog, so I recommend reading his blog post Making Web Fonts Work. Essentially, it's come down to a Microsoft vs. Everyone Else issue again, with IE supporting .eot (Embedded Open Types) files and other browsers supporting .otf (OpenType Font) files.
The latest buzz has been around Cufón. As its github page describes, it provides "fast text replacement with canvas and VML." The Cufón method requires converting fonts into "a proprietary format" and then utilizing a JavaScript rendering engine to display the font in a browser. I've only tested it in Firefox, but I already prefer it's implementation to sIFR, despite the fact that the text is not selectable. Apparently, it already works well cross-browser, with some known issues.
Lastly, sIFR Lite, Facelift and Typeface.js are some other contenders. sIFR Lite is essentially just a reworking of sIFR, but object-oriented and only 3.7kb uncompressed. Sadly, each have their problems, but I'm keeping my eye on them.
It's possible we may see some kind of resolution with CSS3's @font-face in the next wave of browser updates, but it really all comes down to licensing. Until a standard is settled upon, we'll continue to bootstrap custom fonts onto the web.
Related: Read the Increase Your Font Stacks With Font Matrix article on 24 Ways and learn how to construct a "font stack."
Last week, Google introduced a format to publicly specify the preferred URL for a page. You simply add this link tag to any page:
<link rel="canonical" href="http://www.example.com/page/" />
The "canonical" attribute tells the Googlebot which URL is the preferred address for any given page. This is perfect for me with a site like Silent Uproar. We've changed our URLs several times over the 8+ years the site has been running and Google has cached 2-3 different URLs for a lot of our archived content (i.e., some with a PHP extension, query strings and/or mod_rewrite URLs).
Not everyone is going to be able to utilize this update, but Google has already fielded a lot of questions for the people that will implement it. It's definitely a nice thing to have for sites with a bit of history and duplicate content issues.
One of my biggest pet peeves are "click here" links. It's the lowest common denominator method for placing links in content. I never really liked them, but I vowed to never use them and rally against the practice starting about four years ago.
Zach Dunn over at Built Internet! apparently hates them as much as I do and wrote an article to that effect. He makes the argument that "click here" links don't really mean anything in context and that if "the links are clear enough, a user should not have to be instructed where to click." Not to mention, "click here" does nothing towards improving search engine rank.
It's such a small issue, but something that's very easy to remedy. Take a few minutes to rewrite a sentence next time you find yourself linking with "click here." Think of it as providing the user with a brief description of what it is they're about to see.
Content precedes design. Design in the absence of content is not design, it's decoration.
I've done some basic work with the Google Maps API before, but last year I helped Nice Outfit with some advanced map work on the York County Visitors Bureau website.
We built an interactive map to mark locations based on category. The map needed to toggle sets of locations on and off through checkbox controls. I knew how to mark a single location, but was a little unsure about adding, tracking and removing multiple markers. As well, the functionality needed to scale as the bureau added partners.
Luckily, Google provided a link to the open source MarkerManager, since their GMarkerManager is deprecated. The tool is part of the GMaps Utility Library project, which provides quite a few nice extensions to Google's functionality. As you'd imagine, the MarkerManager class allows for management of hundreds of map markers.
While this is not the most exciting topic, I'd suggest bookmarking the library for when you need to do a little bit more with a Google Map than the built-in API offers. There's even an AS3 library for Flash developers.