Umbrella Today, which is a beautifully crafted site (CSS parallax effect!) that tells you whether or not you should bring an umbrella outside, does not work for me. See, it asks for a zip code—presumably limited to the United States only. But I don’t live there.
Now, I know, there are countless websites that exclude a certain demographic in every imaginable way, not just by geography. After all, on the Internet you’re free to do anything you want. But if you don’t like how something is working (or isn’t working), you’re free to blog about it as well.
Go local, be successful, then branch out
To all the developers out there: going local is a good strategy, but if you can help it, try to make your nifty little web app more accessible than just for your neighborhood.
And I’m not just talking about the one-person startups but also the bigger fish in the pond. I wonder how long it will take for Google Maps to completely and accurately cover the planet. (I don’t know if we should be excited when it does, either, but that’s a different story.)
True usability and accessibility
When we mention the term usability in terms of web development, we look at how comfortable users are in using and interacting with the interfaces that are created. Closely associated with usability is accessibility, which champions the idea of never leaving any differently-abled user out.
Doesn’t true usability and accessibility cover my dilemma with Umbrella Today, since I’m left out of its target userbase?
I do hope the makers of Umbrella Today and other people like them stop discriminating by zip code and start reaching out to other parts of the world.
Again, this is if they can help it. Because if there’s one medium that can make it possible, it should be the Web.
I know rattling off websites in blog posts are a dime a dozen these days and may not be your cup of tea. But you might want to read and bookmark these sites—you’ll definitely keep coming back to them.
It’s a very short list, so you won’t tire easily reading this, and the sites are more like Position is Everything than Smashing Magazine. (No offense intended; I know that SM does a wide variety of blog posts, not just lists and freebies. I just mean they’re more references than resources, okay?)
Web Design+
Web Design+ contains the solutions to common web standards problems. From choosing a DOCTYPE to implementing CSS hacks, this is a great one-stop-shop for the best practices in web design out there. There are a ton of HTML and CSS cheatsheets out there, but reading them shouldn’t stop there. Refine your markup and stylesheets with the help of this site, free!
When Can I Use…
When can I use… compares support for several web design features according to browser version, from HTML to CSS to SVG to other technologies.
For example: thinking of using CSS3′s rounded corners (border-radius)? It’s not even available on IE8 and Opera 10 yet. Of course, you don’t have to avoid using them just because the conclusion says “not ready”. It’s still a very useful page for recalling which browser version can support what.
On Having Layout
On having layout demystifies the concept of Internet Explorer’s hasLayout property. A lot of the IE-related CSS problems that web designers run into are related to hasLayout, so understanding how it works is essential.
The Ultimate Website Launch Checklist
The Ultimate Website Launch Checklist helps one go over key aspects of a website once it goes live. It’s more for the designer-webmaster hybrid, but regardless of your role in the process it’s a good view of what needs to be done.
I’ve noticed this trend to screenshot tweets instead of copy-pasting their texts in blockquotes for some time now. On web design and technology blogs, no less. You’d think these sites who constantly write articles about HTML, CSS, web standards, usability, semantics would actually listen to their own advice.
What do people get out of doing it, though? Is Twitter really that much of a game-changer that you can now break the conventions of quoting people in articles on websites? Is it really that big of a deal to debate on how you should add tweets to articles—which is so obviously linkbait?
Are tweet pages designed so much prettier than your default blockquote designs that you feel compelled to use them instead (that’s definitely an “unsuccessful designer trend” isn’t it)? Though, consider the construction: large text, a clear indication of who said the tweet, and a fuzzy timestamp. Maybe that’s what blockquotes should aspire to be?
Are tweets such special data forms that you need specialized plugins and scripts like WP Quote, Twickie, QuoteURL to display them? Or do those exist to up one’s geek cred and feed the third-party Twitter apps machine?
Still, those aren’t as bad as web apps like tweetshots. Want to share a tweet on Tumblr? Use the Quote post type. WordPress is getting custom post types in its next major release too. But publishing platform or no publishing platform, that’s what the HTML tag <blockquote> is for.
Let me channel Steve Ballmer and say: Blockquotes, blockquotes, blockquotes, blockquotes, blockquotes. They’re not that hard to use, certainly not more than taking a screenshot and uploading it.
I understand why on some occasions using images instead of text and other data formats is preferred. They’re usually more portable when passed around in email, forums, social networks, and other communication platforms. More people know how to deal with images than URLs too. But for the purpose of quoting tweeple on websites, I see no excuse for displaying text as images.
I’ll spell it out for you in <strong> and <em>: display text as text, not as images, damn it!
Sure, screencapping tweets may not be as grave a sin as using tables for layouts, but back when that was the dominant method of creating websites, it was a pragmatic choice to make do with the technology available. The choice to use images for text is illogical today. It is confusing behavior that is inexplicably linked to Twitter’s success.
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 brought back the 80s arcade game Pac Man to celebrate its 30th anniversary last May 22nd in the form of a fully-working Google Doodle on its homepage (it’s been since moved to a dedicated page where people can still play it). The “I’m feeling lucky” button gets replaced by “Insert coin” and clicking on it lets you play. Click on it a second time and Ms. Pac Man joins in the fun.
Apart from hearing collective 8-bit cheers of delight upon discovering what could be Google’s most viral web toy yet, the Pac Man doodle was another display of its massive influence, both the good and the bad. more
Tumblr is no longer just the home of reblogged pictures, quotes, music, videos, and journal entries of friends you follow; it’s also gaining favor with the more discerning content creators in the design and technology circles, turning it into a truly professional publishing platform. This phenomenon is thanks to its relatively easy customization while keeping its interface decidedly simple.
My question is, if Tumblr’s audience is becoming more mature, should it shift from its dead-simple appeal and grow up too? David Yeiser prefers its current approach:
What’s neat about Tumblr is it’s not only a great publishing platform but a great tool for content consumption. [...] as self-publishing has changed to shorter forms and varied media the traditional feed reader has become obsolete. I shouldn’t have to click a title of a post to read a quote. [...] I think the way Tumblr aggregates and displays blog posts is the future of feed readers. Though I’m not aware of any standalone readers that take this approach.
Personally, I disagree. I follow a lot of people (and non-people) on Tumblr, producing remarkably varied content genres (e.g. XKCD Explained, 53 Weeks of UX, Sweet Home Style) with no way of filtering which ones I’d like to view at a time. Infinite scrolling in the dashboard can only take you so far in browsing ease.
Unwieldy content consumption is a familiar problem experienced on Twitter and Facebook, and by people who want more options, more control. Except there are now methods of dealing them on those sites. It’s even a big business for third party companies. On Tumblr, that remains to be seen.
Dashboard filtering options would be a welcome addition to the site. The reason is that “following” is a one-size-fits-all option when the truth is we need many.
And there lies the rub with a hosted platform, as well as platform that caters to simplicity first and foremost. Notice that as the concept of feed reading, trackbacking, and commenting are abstracted, if not replaced with Tumblr’s own conventions of dashboard reading, reblogging, liking, answering, one is forced to adhere to a closed set of standards inside its community. For a community that’s got such a wealth of content, consuming and sharing and communicating through that content but with limiting, non-standard methods is a turn off. If I link to a Tumblr post from a non-Tumblr site, will the owner of that tumblelog even know that I did?
Again, all of this wouldn’t be so bad if there were more options available, even as premium features. Right now, there aren’t.
What should Tumblr do? Should it go the WordPress.org and Identi.ca route and provide an open, self-hosted platform? Should it take some notes from the old-but-still-strong LiveJournal? (In some ways their user bases are the same.) Should it push its API more aggressively? Should we just wait and see what they’re up to, or accept that it’s really just a different culture from what we’re accustomed to?
As someone who’s enjoyed a lot of great content on Tumblr and is tempted to migrate her personal blog over there, there are a glaring number of things holding me back.
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.
Blackbird Pie is Twitter’s very own tool for embedding tweets on webpages without the cumbersome, semantics-killing screenshot method. It still lacks the dead-simple interface Twitter is notorious for, since you have to enter the URL of the tweet to grab the embed code and it’s not even built into the system yet, but that’s because it’s a rough prototype at this point.
Since Twitter is an ecosystem of early adopters, it didn’t take long before a bookmarklet surfaced, which sports only a minor difference with the original code in the date format, and seems to display better on this site.
Note that this method inherits your websites styles, which means you may or may not have to tweak your CSS to accommodate it. Unfortunately it still looks bad in feed readers.
Has progress been achieved here?
I’m not sure this is any better than a screenshot. Putting aside the long-winded user flow of grabbing the code since that can be remedied once it’s built into the Twitter system, there’s an overflowing amount of inline CSS to copy and paste. The advantage to this static code, however, instead of a JavaScript embed is that the text is preserved even when the tweet is deleted.
The question remains: should people go through all this trouble to use tweets as quotes? Is there really that much more to be gained by preserving the tweet “format” over a simple blockquote? I still don’t think so.
Check out the more colorful, animated visualization of browser support for the latest HTML5 and CSS3 features based on data from When can I use… Inspired by a General Dynamics postcard and an infographic on America’s wealthiest religions, this single-serving site is quite literally a rainbow that’s painting optimism for the future of web standards.
Each ray represents a feature, and the different bands of color represent the leading browsers, IE6 excluded (finally). More under the hood details here, praising the virtues of Sass and Photoshop-less, in-browser design. Kudos to Paul Irish (again!) and Divya Manian.
As much as I wish we’d move on and get Apple off our radar, its decisions have a rippling effect in the industry and the future of various technologies. The next issue on the list? The Web versus App debate. This can be framed more specifically as a Mobile Web vs. Objective-C Web debate in the context of Apple’s mobile landscape, but as early discussions arise, it’s transforming into an interoperability vs. superior user experience debate. Cameron Moll, author of Mobile Web Design, writes:
At one point in time, J2ME (now Java ME) and WAP were the starting points for a discussion on mobile strategy and the web. Then, for a brief period of time, you talked about HTML/CSS. Now, for a growing majority of mobile strategies that don’t require a global presence on widely varying devices, the discussion begins with iPhone. Smart client is now iPhone app, and in many cases, the app is primary to the experience, not secondary to the browser. And iPad app may soon replace iPhone app as the starting point.
Frankly, as the adoption rate of iPhone increases and if iPad follows suit, it will become increasingly difficult to argue in favor of a starting point other than iPhone OS. The NPR iPad app, for one, provides a much more pleasant user experience than NPR.org.
Peter-Paul Koch steps in and plants himself firmly on the interoperability front, maintaining allegiance to the Web:
This is a total no-brainer when we’re talking about games and other entertainment apps. When it comes to complex, graphic games, vendors will opt for superior UX, and once you’ve done that, starting on iPhone OS makes excellent sense.
But if you build an integrated social media client, is superior UX still so important that you can afford to ignore non-iPhones? I don’t think so. I think creators of such apps would do better to create one in web standards so that it runs on all (well, many) devices. There’s stiff competition out there, and the wider your reach, the better chance you have of prevailing.
Meanwhile, Faruk Ates goes the complete opposite: rooting for UX, lamenting the existence of multiple browsers, and emphasizing the need to make a buck. The debate expands further and we see clashing ideologies of democracy vs. walled gardens, free vs. paid business models, and so on. All these further reinforce how Apple’s philosophies go against those of the Web.
With all its new moves, Apple has been targeting all sorts of corporate entities for its own gain: Adobe, Google, the whole porn industry…but now is it also hurting developers? consumers? the Web? itself?
Hostility towards competitors is, I suppose, all part of the game. But this action is also hugely hostile towards developers themselves. The banned development environments offer things that Apple’s Xcode doesn’t. Sometimes it’s just a different choice of language, one that a particular deveoper might feel more comfortable in. But often the advantage is simplification—the use of higher-level programming languages (like Lua, or JavaScript, or C#) and frameworks that take out a lot of the grunt-work of software development (like writing a 3D engine). In turn, developers get quicker development cycles, easier development, fewer bugs, and overall, superior applications. Banning these tools doesn’t just hurt competitors. It hurts developers on Apple’s platform, and in turn hurts the platform itself.
Apple’s done a lot of things to stir the pot, and while such stringent practices have been known to yield revolutionary results, its actions continue to seem awfully ruthless. Choosing a more favorable approach to mobile development could very well be tainted by the company’s values.
*/
