Friday, July 30, 2010

Trying Google Font Previewer

Screen shot of Google Font Previewer

I'm going to make the assumption that if you are reading this you have at least a passing interest in typography on the web and have heard about Google's new font preview tool. There are already plenty of articles talking about how easy it is, how Google hosts the typefaces, how licensing isn't an issue, and so on. Some of them are linked at the end of this article, so go read up. As such, let me just dive right into the piece I find most interesting — the implementation.

I started to play around with Google Font Previewer by dropping code samples onto my development site. I tried to see how many typefaces I could embed, how I could mesh the code into my site, how easy it would be, and how it would look in different browsers. The screen shot below (from Google Chrome) shows my site with three of the typefaces in place: Molengo for the overall copy, IM Fell DW Pica SC for the headlines, and Reenie Beanie for the banner text with my name. You won't see this on my live site because this is, after all, only a test and I am not writing a ransom note.

Screen shot of my (development) site with font styles.

In order to use these typefaces I needed to drop three references to the Google typefaces into the head of my document (one for each typeface):

<link href="//" rel="stylesheet" type="text/css">
<link href="//" rel="stylesheet" type="text/css">
<link href="//" rel="stylesheet" type="text/css">

From there I simply found the appropriate selectors in my CSS file and added the following styles (you'll note that I edited them heavily from what the tool provides):

body {
  font-family: 'Molengo', Trebuchet, sans-serif;
  font-size: .82em;
  font-weight: 400;
  word-spacing: -0.1em;
  line-height: 1.6em; }

h1 {
  font-family: 'IM Fell DW Pica SC', serif;
  font-size: 25px;
  text-shadow: 2px 2px 2px #333;
  line-height: 1em; }

#Banner p#Title {
  font-family: 'Reenie Beanie', serif;
  font-size: 100px;
  font-weight: 600;
  text-shadow: 4px 4px 4px #333;
  line-height: 1em; }

You can see that I played around with font sizes (switching between using ems and pixels), font weight, drop shadows, and even adding an alternate font in case the user cannot see the selected typeface. I then loaded up my most current browsers on my Windows machine (my Mac and Ubuntu machines are hiding) and ran the site through each, comparing and contrasting. The image below shows a representative slice of the page with all three typefaces loaded in each browser. Click the image (or use whatever input device you prefer, such as your meatstick) to see the full-size screen shot. Browsers used in the test:

  • Internet Explorer 8
  • Chrome 5.0.375.99
  • Safari 5.0 (7533.16)
  • Firefox 3.6.7
  • Opera 10.6

Screen shot of my (development) site with font styles as seen by different browsers.

I noticed the browsers were generally consistent on the font scaling and weight, with minor differences in anti-aliasing and line-height. Shadows showed greater variance among the browsers. Opera seemed to have a whole different idea of font weight, size, and anti-aliasing, but wasn't so far out of the park that it was unusable. Most interesting was how punctuation was treated. Note how only Internet Explorer and Opera show the commas in the tag-line under my name, or after the word "project" in the first sentence. Chrome, Safari, and Firefox each lost the commas altogether. While I am comfortable with the other display differences, losing punctuation is a deal killer for me.

Overall, the Google Font Previewer is a great way to quickly select and style type, drop it into your pages, and get it done quickly enough to go get an ice cream before your Dallas reruns. However, take some time to clean up the CSS it provides so that it matches your site coding style and isn't full of unnecessary declarations (do you really need to define word-spacing if you aren't changing the browser defaults?). Consider adding other, standard typefaces into the list as back-ups. Once you've done that, make sure you fire up your newly-typographized page in a few different browsers and are comfortable with the results. Those punctuation marks can be a killer, so check those. Don't limit yourself to your own browsers, either. Go find some variety and give the page a spin in alternative browsers, older browsers, and even mobile devices. You just might find that you added a style that works well with current browsers, but blows up the version of Netscape 4.x sitting on your grandmama's old Centris 610.


Tuesday, July 27, 2010

Unicorn Validator

The W3C has today announced its brand new validator, named Unicorn for reasons they do not explain. The new validator combines four other validators into one:

Unicorn combines a number of popular tools in a single, easy interface, including the Markup validator, CSS validator, mobileOk checker, and Feed validator, which remain available as individual services as well.

W3C is inviting developers to submit their own modules for the validator to continue to expand its capabilities. So far Unicorn has been translated (localized) into 21 languages, and is hoping users can contribute more.

Unicorn's CSS profile validation includes the ability to choose warning levels to report and to choose a medium (all, braille, handheld, print, screen, etc.). The "Custom Task" allows users to choose among (X)HTML, CSS, MobileOK, and RSS/Atom. With this custom option, users can also choose a level of CSS (Level 1, 2, 2.1, or 3) in addition to other profiles (SVG, mobile, TV, etc.) and then again from a CSS user medium.

The report page has a much nicer way to display all the issues than previous validators, allowing users to collapse an entire section and showing icons and numbers corresponding to the count of specific error types within a section (2 errors, 3 warnings, for example). Each message also shows the specific line number and (if appropriate) character number of the error (warning, info alert) along with the corresponding message. Each section and message even has an anchor on it so you can link directly to any item for sharing issues with a team. Now if W3C could add a background color to the page (white would be ideal), then I wouldn't have to squint to see the results.

Give Unicorn a try and see what you think.

Sunday, July 25, 2010

This, the F**k, Is Social Media Now

Yes, it's a tired title already. But it's based on the third installment of the popular What the F**k is Social Media NOW? slide show that's been recycling around the web again for the last couple weeks. As such, not including it here almost makes me seem like I'm clueless. Scroll down to see it embedded.

Back in October I linked the Social Media Revolution video from this blog after I spoke to a few hundred people about that very topic (social media, not videos). I made the poor assumption they had all seen it. Of course the video has been updated too, so I've embedded the May 2010 version below.

These both demonstrate to those not familiar with social media or its impact (or those who haven't been dragged kicking and screaming into it yet) just how far-reaching and influential it is as an overall medium.

In June, Read Write Web posted a story, Social Media Era Set to Peak in 2012, that I have heard social media naysayers and detractors reference completely out of context. First of all, nobody set social media to start its insane climb to ubiquity, and nobody can set it to peak, fall off, or get me a cup of coffee. It's a constantly moving target that is fed by the masses, not pundits and think tanks. The chart used in the article really speaks about the rise of terms more than anything. For example, "web 2.0" peaked back in 2007 on the chart. Which as a term, it did. As the core concept that spawned that term, it's more alive today than it ever was in 2007 — just look at the typical web site today to see how interactive and responsive it has become.

If anything peaks in 2012, it's the hype about social media, not the actual practice. You may no longer be forced to look at Twitter logos on drink boxes and Foursquare badges on shower stalls, but social media as a concept has already infiltrated the web and our society and isn't going away. It will simply become expected as a part of everyday life.

The article does eventually state that social media adoption may peak. I think it misses the point, getting mired down in the current technical implementations and forgetting that once everyone is using it, there will be no more need for adoption. It will be everywhere.

Ok, enough of my ramblings, check out the eye candy...

Now go tweet how awesome this post is. Srsly.

Friday, July 23, 2010

Opera Rep Provides HTML5 Overview

HTML5, CSS3Patrick H. Lauke is the Web Evangelist at Opera Software and ran the Accessibility Task Force for the Web Standards Project (WaSP). Last week (July 13) he gave a talk to the Institutional Web Management Workshop on HTML5. He lead viewers on a general history of HTML5, through an overview of the specification, and then plans for the future.

Slides from his presentation have been posted, along with a video of the entire presentation. Sadly, watching just the slides means you miss out on his narrative, and watching just the video means you miss out on the slides. That's why I've embedded both here. Because I had to scale them to fit in this layout, you may want to see the originals of each and view them side by side (links below).

His slides include code samples and URLs to check some of them out on your own. Even if you can't get the video to work, spend some time perusing the slides (especially slide #4, from Bruce Lawson, which shows what HTML5 is not). If you can see the video, stick around for questions at the end.

The video is about 45 minutes and is peppered with lots of good insight. For example, he frames HTML5 as an extension of HTML4, providing more options and features. He points out that valid HTML4 or XHTML1 sites don't need to be re-coded, something that many web novices worry about and web jerks may try to trick clients into doing. He even discusses his own opinions on new elements and features, such as article and video path obfuscation (to keep people from bypassing YouTube-style overlay ads).


Tuesday, July 20, 2010

W3C Cheat Sheet Now Includes HTML5

W3C Cheatsheet screen shotBack in November, the W3C released a handy tool aimed at helping developers quickly access information from various W3C specifications (W3C Cheatsheet for developers). The features were pretty straightforward:

This cheatsheet aims at providing in a very compact and mobile-friendly format a compilation of useful knowledge extracted from W3C specifications — at this time, CSS, HTML, SVG and XPath —, completed by summaries of guidelines developed at W3C, in particular the WCAG2 accessibility guidelines, the Mobile Web Best Practices, and a number of internationalization tips.

The author has had many requests to add information about all the new, changed, obsolete and removed elements and attributes in HTML5 by highlighting them (and including the new ones) throughout the application. Today he has released the updated version of the application (HTML5 in W3C Cheatsheet) with those changes.

Now when you look up an HTML element or attribute, the results will indicate if the element is different in some way in HTML5 than it has been in the past. Optimized for mobile use, the slim interface makes for a pretty lightweight quick reference tool should you have any questions and find the W3C specs a little heavy to read through.

The cheat sheet also includes sections for mobile web best practices, accessibility (WCAG 2.0), internationalization tips, and even a small section covering common character codes. Most of the content includes links to the relevant W3C specification for further reading. All the data comes from HTML: The Markup Language Reference. Try it out and see what you think:

Monday, July 19, 2010

Working Around CSS3 Hacks

HTML5, CSS3Until CSS3 is a final specification, we can expect to see browser makers attempting to implement some of the ideas on their own, sometimes with a nod to the forthcoming spec and sometimes without a clear correlation. Given the pressure for browser makers to claim support for a CSS3 feature as soon as possible (Does Your Browser Really Support HTML5 and CSS3? and HTML5 and CSS3 Confusion), these implementations aren't always complete or terribly close to what the final specification will require. If you're the kind of developer who just cannot wait for the W3C to wrap things up (and they still haven't finished CSS 2.1: CSS 2.1 Still Not Final), then you probably want to try your hand at using these new features, at least implemented by the browser makers. Take some time to read up on some best-practices articles that can save you a lot of time down the road as you have to re-factor your code.

In late June the article Stop Forking with CSS3 showed up on A List Apart and promoted the use of a JavaScript library over browser-specific prefixes (vendor prefixes). The author felt that the pre-pended CSS styles (such as -moz, -webkit, -o, and -khtml) were just the modern form of CSS hacks we've been using as patches through a decade of shoddy support from browsers. I am not a fan of using client-side script to make my CSS (or HTML) coding easier — I don't like to put the processing burden on every end user instead of simply writing more code. Others agreed, as this sample comment (from Bruce Lawson) highlights: vendor prefixes are a feature, not a bug

Bruce Lawson proposed his own approach in early June, Writing cross-browser, future-proof CSS 3. He argues that developers need to learn the standards in the specification and include them in the code, regardless of browser support. Then a developer can add the browser-specific hacks on top of that. This way when support for the standard emerges, no code changes are necessary. As browsers start to drop support for their browser-specific hacks, still no code changes are necessary. This is valuable for contract work when your client pays you to develop and deploy a site and months later the rules change. Now you don't get a panicked phone call about changes to the site appearance and you don't have to incur expense (yours or the clients) to fix your code. Some of the comments on the post discuss ways to separate and format the browser specific styles for later removal.

Earlier this month Eric Meyer weighs in at A List Apart with Prefix or Posthack. Here he suggests that browser-specific prefixes are the best way for browser makers to introduce new support. As the specification and/or the support is/are finalized, then browser makers should drop the prefixes. As developers, these prefixes are clues that things are still in a state of flux. At the very least, if implementations differ dramatically, it's far easier to include a prefix to specifically target each browser than to look for hacks or write browser-sniffing scripts.

Loathe though I am to write any browser-specific code, I endorse the approach outlined by Eric Meyer. Add in some of Bruse Lawson's suggestions (such as ordering the prefixes in alphabetical order) and you should have future-friendly CSS that doesn't exist solely at the whim of browser makers, but still allows you to play with these new CSS toys.

Thursday, July 15, 2010

CSS 2.1 Still Not Final

W3CWe all know that CSS3 is not final, nor is HTML5. What you may not know is that the CSS 2.1 specification is also not final.

CSS2 became a W3C recommendation on May 12, 1998, over 12 years ago. Since then the CSS Working Group has been developing CSS Level 2 Revision 1 (CSS 2.1) to correct errors and omissions from the original CSS2 specification. In fact, the CSS2 specification directs people to the CSS 2.1 specification as the de facto current version. CSS 2.1 is a Candidate Recommendation, and has September 8, 2009 referenced as the date of the specification.

The W3C has a slightly confusing progression of a specification before it is considered a "standard." There are essentially four steps:

  1. Working Draft (WD): This is the first time a proposed specification is shown to the public and open for comment.
  2. Candidate Recommendation (CR): Significant features are mostly locked and feedback is requested in how to implement the standard.
  3. Proposed Recommendation (PR): The specification has been submitted to the W3C Advisory Council for approval. Changes at this point are rare.
  4. W3C Recommendation (REC): The specification is final and endorsed by the W3C. This is what the general public considers a final standard.

To clarify, the CSS 2.1 specification is in the second of four stages. For context, the HTML 4 specification was approved on April 24, 1998. The HTML 4.01 specification was approved on December 24, 1999. Between those two versions, little more than a year and a half passed. To give another example, CSS3 is an amalgam of many different modules, some of which are still working drafts, while one (Selectors Level 3) is already a proposed recommendation (third of four steps). What this means is that some aspects of the next level of CSS are already moving along regardless of the status of CSS 2.1

When you look at the names of the editors working on CSS 2.1 (Bert Bos, Tantek Çelik, Ian Hickson, Håkon Wium Lie) and compare them to the names on the CSS Selectors Level 3 proposed recommendation (Tantek Çelik, Elika J. Etemad, Daniel Glazman, Ian Hickson, Peter Linss, John Williams), you'll see some crossover. You may even recognize one of those names (Ian Hickson) as prominent in the WHATWG, working on HTML5.

The CSS Working Group recently (June 30) posted an update on CSS 2.1. Here are some of the salient points:

[G]iven the recent changes in the spec - we resolved a lot of issues some of them pretty complicated - we may have to go back to Last Call Working Draft and then back to [Candidate Recommendation] again. That's not a problem and can be relatively fast.

From that statement, the 2.1 specification may have to slide back a step before it can advance.

The W3C relies on a functional Test Suite before it can submit a specification to the next step, this is their expectation on the timing as a result:

[T]he Test Suite and the [Candidate Recommendation] should be available at same time and that time should be, as planned by the WG, after the summer. That should leave us enough time to reach Proposed Recommendation before the end of the year, as expected.

The Working Group does acknowledge that future CSS specifications hinge on what they are doing here:

[CSS] 2.1 must be released as a Web Standard because that's one of the current cornerstones of the architecture of the World Wide Web. We cannot make the next steps, CSS 3 even module by module, happen without 2.1 before.

I read that as a timeline on the soonest that CSS3 can move ahead as well, which is essentially no sooner than the end of 2010.

Update: October 8, 2010

I have been called out! HTML5 guru and all around odd bird has "referenced" me in his latest blog post:

CSS 2.1 “not ready for use” says journalist

Update: June 7, 2011

13 years on and CSS 2.1 is now an official recommendation. Read what I wrote when that decision cam down: CSS 2.1 is Finally Final

Another Update: October 14, 2011

Alexander Ovsov of Web Geek Science offered to translate this post to Romanian, and my ego could not resist. Go learn Romanian and read his translation:

CSS 2.1 nu este încă definitivă.

Tuesday, July 13, 2010

Methods to Select an HTML5 Element

Sectioning Elements

The Amazing HTML5 Doctor Easily Confused HTML Element Flowchart of Enlightenment

Right at the end of June, the HTML5 Doctor web site celebrated its first birthday (Happy 1st Birthday us). As part of that birthday celebration they have given us a gift: The Amazing HTML5 Doctor Easily Confused HTML Element Flowchart of Enlightenment (320kb PDF).

Inspired by an original version sent in by Piotr (one of our readers) and developed by Oli the chart helps guide you through those tricky differences between header, footer, aside, section, article, figure and yes, div. It's available in either pdf or png format.

Given the ingoing confusion over some of the new elements (both by the general public and seemingly within WHATWG itself), this chart should make it much easier to at least struggle through these decisions. As someone who expects everyone on his team to be able to justify every element on the page, I expect that if HTML5 ever wraps up and/or we start to utilize it on client projects, this will prove to be very helpful to us.

Inline Elements

W3CThe chart may only deal with sectioning elements, but there are many more elements to consider. Some elements that I feel should have been deprecated have been re-cast in HTML5 with new purpose, and this may cause yet more confusion. In particular, the b and i elements now require a primer from the W3C to make sense to the seasoned developer: Using b and i elements

W3C provides the following background:

The HTML5 specification redefines b and i elements to have some semantic function, rather than being purely presentational. However, the simple fact that the tag names are 'b' for bold and 'i' for italic means that people are likely to continue using them as a quick presentational fix.

The W3C then provides an answer, a tiny chunk of which says this:

You should not use b and i tags if there is a more descriptive and relevant tag available. If you do use them, it is usually better to add class attributes that describe the intended meaning of the markup, so that you can distinguish one use from another.

The article goes on to describe challenges with internationalization:

Just because an English document may use italicisation for emphasis, document titles and idiomatic phrases in a foreign language, it doesn't hold that a Japanese translation of the document will use a single presentational convention for all three types of content. Japanese authors may want to avoid both italicization and bolding, since their characters are too complicated to look good in small sizes with these effects.

And yet, after all this, they still provide a recommended usage:

In the HTML5 specification 4.6 Text-level semantics lists other elements that can be used to describe inline text semantically, such as dfn, cite, var, samp, kbd, etc. [...] It may help to think of b or i elements as essentially a span element with an automatic fallback styling. Just like a span element, these elements usually benefit from class names if they are to be useful.

Since I don't allow use of b or i in our HTML4 documents (because they impart no structural or semantic meaning, only visual style), I don't see any reason to use them even given their revised role in the HTML5 spec. This W3C article has more caveats to their use than solid reasons, and retraining staff to support an element that is still mired in confusion isn't the right way to go.

We don't need a chart to say "No" for this one.

Monday, July 12, 2010

Does Your Browser Really Support HTML5 and CSS3?

HTML5, CSS3I like reading rants. And by rants, I mean well-thought, researched, articulate arguments that are the result of a festering pool of frustration finally shooting out and being channeled into something constructive. Not the rants you might find on bathroom stalls.

Thanks to the Twitters I came across a blog with a two-part rant about HTML5 and browsers. It echoes rants I've read or written 10 years ago, the result of chafing against browser makers and developers buying into standards too soon, chastising each other based on unfounded data, and blind faith in one option over another despite overwhelming data to the contrary.

I watched people say HotJava would save us from Mosaic, Netscape would save us from HotJava, NetShark from Netscape, Internet Explorer from the internet, Mozilla from Internet Explorer, Opera from everyone, Firefox from Mozilla, Safari from ourselves, Chrome from whatever is left, and so on. It's been done, we're looping back through. Examples other than browsers? HTML 3 from HTML 2, HTML 4 from HTML 3, ISO HTML from something, XHTML 1 from HTML 4; JSSS from font tags, CSS from font tags, CSS 2 from CSS 1, CSS 3 from communists; PNG from UNISYS; MNG from animated GIF; Flash from Shockwave, Silverlight from Flash, HTML5 (and CSS3 and JavaScript) from Flash; VRML from boring pages; Quicktime from AVI, Windows Media from Quicktime, YouTube from Windows Media, Ogg Theora from YouTube, H.264 from Theora, VP8 (WebM) from H.264. And on...

The point of all that comes down to the fact that things change. Quickly. Especially on the web. Relying on an unfinished spec (HTML5) to build your browser support and/or code your pages is full of risk, risk that is passed on to end users and clients. There is a tangible cost to go back and fix things that short-sighted developers implemented, whether by making corporate Help Desks do company-wide upgrades (or making the poor kid down the street do it for smaller companies) or by making clients pay to fix something on their sites that should never have been implemented to begin with.

Cue the rant. Lars Gunther has written a piece that breaks down actual browser support versus marketing statements of browser support, taking Webkit in particular to task (No browser supports HTML5 yet. Part 1. The rant.). His points ring true (even though he also discusses CSS3), especially if you have been in the web world long enough to witness the browser wars from the 90s. Some key statements:

...[O]nce someone has started to claim support for a feature, even though that support is half baked and incomplete, everyone else has to answer in kind, and claim support even when their implementations are equally half-baked. Or even worse, rush out such half baked implementations to the market to show everyone that they are also a leader.

We've seen this in the half-baked support for PNG images in Internet Explorer for years. We've already experienced this abrupt deployment of incomplete features for a decade, and now Apple happens to be the company doing this via Webkit. It was terrible when Microsoft did it, but somehow it's not raising any hackles this time out.

...[W]e tend to put up demos of new cool technologies that are not really examples of best practice, e.g. even though transformations and transitions work in the latest versions of Firefox and Opera, many demos use the webkit prefix only.

Given how many young and/or inexperienced developers still get by with the thieving of source code, add in some prior experience with IE-specific hacks, and we are running the risk of developers implementing features incorrectly, even when other browsers may have supported a spec for years.

In part 2 of the rant (No browser supports HTML5 yet. Part 2. Technology.), the author proceeds to back up his points with some data. He pulls out three aspects of HTML5 that Safari and Chrome (as examples) both claim to support but really do not.

The world of HTML forms has opened up a lot in HTML5, allowing many different types of input elements, for example. In addition, accessibility is built into the spec for these elements from the start:

At the moment neither Webkit nor Gecko (nor Opera) is nowhere near having a complete HTML5 web forms support. They all lack some features and they all lack accessibility.

Sectioning elements, such as the oft-confused section and article elements, need to be accessible via the DOM to more than just styling:

...[S]ectioning elements affect document outline and that should in turn be exposed to seeing users through varying sizes on the headings and to non-sighted users through their assistive technologies. [...] Being able to style a sectioning element is actually a bullshit claim. HTML5 mandates that one should be able to style any unknown element. That is, a browser vendor could claim that they support the , and elements, since according to HTML5, they should!

The hgroup and nav elements were designed to hide subtitles from the DOM outline and to provide greater accessibility for accessing navigation, respectively. Their functions are pretty clearly laid out in the specification.

There is no browser on the market that supports these behaviors. Indeed, to my knowledge, no browser even has begun working in earnest on this.

These are each examples that one or another browser vendor claims it supports, when it really does not.

As I have done for prior specifications over many years, all I can do is remind people not to get caught up in the marketing hype and the gee-whiz factor of the technology. Understanding your users, their available browser features, and the business cases for implementing a particular technology are the better methods for guiding how you should build for the web. If you want to play with the cool new gadgets and features, do it on your own time, don't make your users or clients pay for it.

Friday, July 2, 2010

UX Challenges in Touch Interfaces (at

iPad in use with a meatstick.As mobile devices have been taking over the place of the mobile or home computer for basic apps and web access, developers are struggling with letting go of the mouse as the primary interface device.

I just wrote up an article for titled UX Challenges in Touch Interfaces that outlines some of these issues, such as the lack of a hover state, fat fingers instead of mouse cursors, and general lack of experience on the part of web developers on planning for touch interfaces. It may not be the most exciting read of the year, but I do come off a bit smarmy, so that's got to count for something.

The article even includes this swell photo of a meatstick in use on an iPad trying to use scroll bars and expando/collapso boxes. In the interest of not being compelled to make some terrible jokes, I'll just stop now.

Thursday, July 1, 2010

Social Media Day in Buffalo #smdayBUF


Back in early June, the web site Mashable, known for reporting on all sorts of things related to social media among its other topics, posted an idea for creating a worldwide social media day (Join Mashable in Celebrating Social Media Day). They quickly mobilized some major cities for an event, and for smaller markets supported them with a Mashable-sponsored Meetup site (Meetup is the platform used to organize all sorts of real-life meetings based around random ideas).

Over here in Buffalo, a group of people mobilized about halfway through the month to start planning an event here in town. In record time, they got a Meetup page built, created a Twitter hashtag for the event, secured a venue, hired a DJ, and managed to trick social-media-savvy businesses into donating goods for an auction. All of this was managed using Twitter and the Meetup Buffalo page. @veganjesus (Norm Boyer) even set up a Foursquare venue just for the event (sadly, not everyone knew, so no swarm badge unlock). While my plan was to just enjoy the evening, I got pressed into service trying to make a Twitter wall, and simply cheated and used a Brighkite wall instead (yes, that was my sole contribution).

The Brightkite wall.

With only 50 RSVPs, one media outlet reported 140+ guests, and it seemed like far more than that cycling through the night. Scheduled for only two hours, the event went past midnight and turned out to be a huge success as people, many of whom had never met face to face but knew each other online, ended up getting along quite well, sometimes with surprising results.

Awkward tweet.

You can surf the tweets that kept popping up all night with the local hashtag #smdayBUF.

In case you haven't figured it out by now, this post is really just a quick recap of the night and a great way to link to all the people who contributed something to the event. Catch all those links below, after you watch this Skunkpost video with some interesting interviews:

I suggest you jump to 2:26 and look for the burning question I posted a couple times over the course of the night. If the embed didn't work for you, watch the video on the Skunkpost site.

The event organizers: @skunkworks716 (Keith Stephen), @KatieKraw (Katie Krawczyk), @BlockClub (Patrick Finan), @Wingalls (Will Ingalls), @Djlopro (DJ LoPro), @TonyCityLove (Tony Maggiotto, Jr.), and @arampino (Amber Rampino). There were many others who helped out, lent support, provided gear, took photos, ate the food, stole some prizes, made the AV work, danced, and so on. In all, it truly was a community effort.

If you were there and you left early (say, before midnight), then you missed a good breakdance battle.

Related links:

Update: Read all about #smdayBUF 2.0, held on Tuesday, July 27 at Templeton Landing, as covered in the post Event Profile: #smdayBUF & #smdayBUF 2.0 by @TonyCityLove (Tony Maggiotto, Jr.). It even has a couple of my photos from the event.