Apple.com (Not Really) Updated to HTML5

Apple has released a revamped version of its web site today, ostensibly in HTML5. Except it doesn't use anything from HTML5.

That Apple wants to move to the platform that it touts as the Flash-killer is not surprising. Apple refuses to allow Adobe Flash on its mobile devices and claims everything Flash does can be done in HTML5. While not totally accurate, it's certainly part of Apple's motivation along with its long-standing claims to support standards. I followed this for a while until it became just senseless bickering:

• Adobe vs. Apple or Flash vs. HTML5, April 12, 2010.


• Adobe to Drop iPhone Support, Target Android, April 21, 2010.


• More Salvos from Apple and Adobe, to No One in Particular, May 13, 2010.

A few very pro-Apple sites have already carried the news about Apple's new move to HTML5, citing the new look, one even offering a screen shot of the first four lines of the HTML as proof that it's HTML5.

Except when you look past the first few lines of the code, or really past the DTD which identifies the page using the new minimalist HTML5 DTD, all similarities to HTML5 cease. I'm going to go after the low-hanging fruit here, mostly because I am writing this on a self-imposed deadline. When I opened the source code, I looked for some telltale HTML5 elements, specifically nav, header, footer or canvas (that last one is supposed to be the Flash killer). I found none of them.

Instead I see the standard tag-soup of divs being jammed into roles now replaced with the new semantic and structural elements of HTML5. As an example, this screen shot shows the HTML that drives the footer, all wrapped in nested divs. These could be replaced with the HTML5 footer element.

I understand that browser support is probably the driving concern here. Apple may not want to implement elements that don't have support in many current browsers. But this half-baked approach, which may be copied by Apple die-hards and HTML5 n00bs alike, does more damage to HTML5 than just leaving the site in HTML4. No, this is a case where prioritizing the marketing message along with ongoing battles with Adobe and now Google are causing Apple's web development team to fail to implement the specification as it is intended (or will be, when it is final). Which calls into question just how well they will implement any aspect of it, including its attempts to supplant Flash.

But this roll-out wasn't done with a mountain of HTML5 fanfare. It is possible that I am being too critical, that Apple's updated site is the first practical step toward future and ongoing implementation of the unique HTML5 elements as the browsers catch up. In that scenario Apple can be forgiven. Except I am not quite so willing to let Apple off that easily given how hard it pushed its HTML5 Showcase back in June. The showcase wasn't really as much about HTML5 as it was about Safari, and then what CSS3 and JavaScript can do. HTML5 itself didn't have much of a role in that showcase. It was just a great way to get people to download and use Safari, given that the content was riddled with Safari- and Webkit-specific features. I'm not the only one who takes Apple to task for it (for example, Apple's HTML5 Showcase Less About Web Standards, More About Apple at Webmonkey). Given Apple's prior behavior regarding HTML5 (pushing primarily CSS3 and JavaScript) and its motivations (Flash foil, Safari pusher), I'm not so sure Apple is taking the right approach with the new site.

Apple isn't the only one making this HTML5-but-not-really mistake:

• HTML5 and CSS3 Confusion


• Google, Arcade Fire Confused on HTML5


• Google Doodle: Bouncy Balls Aren't HTML5

Sadly, we are at a point in time where people are implementing HTML5 the way they implemented HTML4 (as in, poorly). It's like we just invented the screwdriver but everyone is using it to pound nails.

Read More

More on the HTML5 Logo

There is so much buzz now and in the past week that it's hard to pick out only a few items to address. I still have an opinion on just about everything going on with the spec, W3C, WHATWG, additional specs, the "pundits," and many other things that could lead to endless ranty posts. But for now I am going to give some more detail on the logo "controversy."

I am physically air-quoting controversy because the logo itself isn't really the source of the issue, but the process and supporting documentation around it has caused a lot of discussion and a fight among at least a handful who have some say or influence on the specs themselves.

Tantek Çelik is a name most web developers will (or at least should) recognize, though if you don't I suggest you look him up. He wrote up a blog post citing how he, Jeremy Keith and Bruce Lawson were rather critical of the HTML5 logo FAQ from the W3C (let's forget that I may have scooped at least one of them, which just shows you how big I let me ego get) for claiming that the HTML5 logo represents more than just HTML5. While the W3C went ahead and fixed the FAQ based on the (rather valid) feedback from them and so very many others, Tantek still has more feedback for W3C. In particular he called out Offline & Storage, Device Access, Performance & Integration and The Movement. What is so much of a relief to many of us is to see that the W3C has made those changes today, showing that as an organization it is being responsive to the feedback from the people who are actually using and evangelizing HTML5. You can read Tantek's comments in detail at W3C Updates HTML5 Logo Messaging FAQ, Open To More Suggestions.

Doug Schepers had a hand in the new HTML5 logo and takes some time to address all the criticism that has been levied at the W3C as a result of the logo and accompanying language. The title of his post gives away his perspective before you need to dive in too far: HTML5 Logorrhea, or Use Your Inside Voice. He recounts some of the decision making process that went into developing the logo, which was surprisingly secretive for a body providing open standards. And then Jeremy Keith jumped in with comments, taking what was almost a plea for people to calm down and turning it into a well-mannered brawl. But a brawl that I think needed to happen for both sides to get all the items on the table. Of course, with a comment system you get other people tossing in their two cents (including someone who felt the logo and support icons are clearly based on military markings and far too violent a theme for a spec). In the end, the fight in the comments comes down to the process the W3C went through to generate the logo.

Given the W3C's attempts to abandon HTML for the semantically pure but practically infeasible XHTML2 specification, which demonstrated just how out of touch the working groups were with day-to-day web development and causing the formation of WHATWG, it's no surprise to see people recoil at the notion that the W3C is again doing some tinkering behind closed doors.

There has been plenty already said about the logo, some of which I am re-linking below, and there have been plenty of parodies, which I also link below. One thing is clear — the process and language around the logo have certainly generated far more interest and activity in HTML5 from those not involved in the W3C or authors on these topics than you could hope to get from a plain old press release.

Related Links

Logo/Process/Language Commentary

• HTML5 Gains Logo, Loses Meaning at Webmonkey.


• Two cheers for the W3C's HTML5 logo at HTML5 Doctor.


• W3C's new logo promotes HTML5--and more at cnet News.


• HTML5 Super Friends Assemble! at CSSquirrel.


• HTML5 logo: be proud, but don’t muddy the waters! at The Web Standards Project.


• W3C tackles HTML5 confusion with, um, more confusion at The Register.

Logo Variations (fun stuff)

• A collection of parodies of the HTML5 logo.


• The HTML4 logo, as envisioned at The Oatmeal and based on the shiny new HTML5 logo (scroll way down, and scroll further for the Cheetah version of the HTML5 logo).


• A lovely ironical (that's my word) Flash version of the HTML5 logo.


• The HTML5 logo using the canvas HTML5 element (best viewed in Chrome or Opera).


• The Tardis in the style of the HTML5 logo over at Reddit.


• The HTML5 logo as if it were a Netscape Now! badge.


• The HTML5 logo in H.264 video.

Read More

Chrome and Mozilla Announce Tracking Blockers

Last month Microsoft announced that Internet Explorer will be adding a "tracking protection" feature to its browser, allowing users to prevent advertising sites from tracking their activity on the web (ad targeting, really). This move was partly to stay ahead of an FTC push to mandate that browser makers add that feature. If you spent that few days between Christmas and New Year's hiding from computers and family, then perhaps you missed my post, Browsers to Add Tracking Blockers.

In that post I mentioned how Firefox had started the work, pulled it, and then brought it back. Well now it's official. You can read up on how it works at the Mozilla Wiki, where they were kind enough to put together a DoNotTrack FAQ. The FAQ helps readers understand that this is not the solution that will ultimately be implemented, since it relies on an HTTP header.

Google is relying on a cookie-based approach via a browser add-on. The only real difference from the voluntary Network Advertising Initiative that allows users to opt-out, which relies on cookies, is that the Chrome add-on won't blow away those cookies when a user clears all other cookies on his/her browser. You can read up on the confusingly-named Keep My Opt-Outs on one of the Google blogs (there are so darn many).

I suggest that if you plan on using these new features, which are not enabled by default and require some level of configuration to be useful, that you take a few minutes to read up on them:

• Mozilla, Google take different approaches to ad tracking opt-out at ars technica.


• Mozilla & Google Announce Browser "Do Not Track" Features at Mashable.


• Firefox and Chrome Add "Do Not Track" Tools To Their Browsers at ReadWriteWeb.


• Web Tool On Firefox To Deter Tracking at Wall Street Journal.




• Protecting Consumer Privacy in an Era of Rapid Change, preliminary FTC staff report (PDF).


• Self-Regulatory Program for Online Behavioral Advertising


• Network Advertising Initiative




• chrome-opt-out-extension at Google code blog.


• Keep My Opt-Outs from the Chrome web store.


• More Choice and Control Over Online Tracking from the personal blog of the Global Privacy and Public Policy Leader at Mozilla.


• Thoughts on Do-Not-Track from Michael Hanson, Mozilla Labs.

Updates

• Big browsers hop aboard the 'Do Not Track' train at New Scientist, Jan. 27, 2011.

Read More

W3C Clarifies HTML5 Logo Is for HTML Only

The W3C has rolled back its definition of what the new HTML5 logo represents:

This logo represents HTML5, the cornerstone for modern Web applications.

In case that isn't clear, which it might not be, the FAQ gets far more specific on the inclusion of CSS3 in the logo definition (emphasis added):

Is W3C saying that CSS3 is part of the HTML5 specification?

No. However, many HTML5 Web sites and applications do take advantage of CSS3 for styling and presentation.

If you saw my post on Tuesday, HTML5 Finally Gets... a Logo?, then you know that I and many others were frustrated at the further confusion the W3C introduced by declaring that the logo for a particular W3C specification actually includes a handful of other specifications. This needlessly confuses the definition for so many, and worse, muddies the waters on expectations between users, vendors, clients, customers, browser makers, developers, and so on.

The W3C heard the message and just a few hours ago posted an explanation and clarification:

The most unified criticism has centered around the FAQ's original statement that the logo means "a broad set of open web technologies", which some believe "muddies the waters" of the open web platform. Since the main logo was intended to represent HTML5, the cornerstone of modern Web applications, I have updated the FAQ to state this more clearly. I trust that the updated language better aligns with community expectations.

The release also addresses the concern that the logo is not yet official, mostly by clarifying the intent of the launch.

It's still relatively early and the news is still somewhat new, but already there have been blog posts grateful for the clarification, such as Jeremy Keith's post Clarity. He echoes what many of us feel, that the W3C version of HTML5 is a technical specification and not a collection of other specifications that may or may not be included in any project.

This news also means I have to go back and edit a post I was working on about the status of HTML5 as a buzzword and not a specification.

Read More

W3C Moves WAI-ARIA 1.0 to Candidate Recommendation

The W3C is on a roll this week. It's the post-holiday rush, I think, which is at least making some stuff move forward. I just hope that all these new developments don't get lost among each other.

W3C has just published Accessible Rich Internet Applications (WAI-ARIA) 1.0 as a Candidate Recommendation (see the email alert or the blog post). WAI-ARIA is a spec that defines methods to make web pages (content, applications, etc.) more accessible to people with disabilities. Beyond just hooks in HTML for accessibility, it's also intended to help with implementations of JavaScript (such as AJAX). Ideally WAI-ARIA is supposed to provide techniques for implementing Web Content Accessibility Guidelines (WCAG) 2.0. If the spec is too dense to read, you can get an overview of WAI-ARIA instead.

The W3C's Protocols and Formats Working Group (PFWG) has already received about 350 comments on WAI-ARIA and is now looking for implementation testing to see how practical the specification is for real-world use. The PFWG wants to see at least two implementations of each feature from the specification and so the call is out to developers to help. For those who want to help, the deadline is February 25, 2011 (just over a month away) and the W3C has posted instructions.

Along with the WAI-ARIA announcement, the W3C has also announced that the Role Attribute has published its Last Call Working Draft and will be accepting comments through February 25, 2011. The Role Attribute is intended to allow authors to annotate markup with semantic information about an element's purpose. In addition to uses for device adaptation, server-side processing, and complex data description, it also has a role in accessibility by supporting WAI-ARIA. Which may explain the matching close-of-comments date.

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.

If this is confusing, then bear this in mind: CSS 2.1 is a Candidate Recommendation. CSS 2 is a full W3C Recommendation, but the 2.1 revision is still at the second step (see this tongue-in-cheek coverage).

Read More

HTML5 Finally Gets... a Logo?

Start Rant

With all the debate about elements, attributes, semantic meaning and who really owns HTML5, it's thrilling to see that the W3C has risen above all the chaos to release something which should truly unify HTML5 and foster its widespread adoption (as soon as it is finished) across the web — a logo.

The announcement came this morning on the W3C site, just four days after its announcement of eight HTML5 drafts being updated (Which I foolishly covered when I should have been waiting for this cherry of a story). The press release gives a little context on how you can use it:

Now there is a logo for those who have taken up parts of HTML5 into their sites, and for anyone who wishes to tell the world they are using or referring to HTML5, CSS, SVG, WOFF, and other technologies used to build modern Web applications.

If you think I am being grumpy about this, you're right. But I'm really caught up on one main issue — HTML5 and CSS are different specs. If you've read me long enough, you've seen that this really gets under my skin:

• HTML5 and CSS3 Confusion


• Google, Arcade Fire Confused on HTML5


• Google Doodle: Bouncy Balls Aren't HTML5

My rant isn't the only one. In fact, there's a lovely video rant by Bruce Lawson that he's re-linked in his post today, On the HTML5 logo.

It isn't completely unjustified. As different specs, they are managed by different groups, different timelines, different test suites, etc. So when the Badge Builder 5000 on the W3C HTML5 logo page lets you build a logo that states what technologies your site uses and CSS3 is a pre-selected option, it gets my dander up. And without hair to hold it in place, it's a mess. The same page even has the audacity to show the Arcade Fire / Google project as an example, which I think I already proved wasn't true (see above, or this other neat site).

Let's be clear on something — it is perfectly legal to build an HTML5 page with CSS2.1, or an HTML 4.01 page with CSS3.

By the way, if you think this is the official W3C logo for HTML5, you should read this in the FAQ (emphasis added):

Is this W3C's "official" logo for HTML5?

Not yet. W3C introduced this logo in January 2011 with the goal of building community support. W3C has not yet taken it up in any official capacity. If, as W3C hopes, the community embraces the logo, W3C will adopt it as its own official logo for HTML5 in the first quarter of 2011.

It seems like they are a little nervous, unwilling even, to make this official if people don't like it. I think they may have the fear of the GAP logo debacle within them.

Tip: If you want to see if a page is actually HTML5, use Opera and install this handy HTML5-powered extension, freshly updated with the HTML5 badge.

End Rant, Start Real Review

The W3C has announced the release of a logo for HTML5 today. The logo has been released under a Creative Commons 3.0 By license, which means you are free to modify it provided you include an attribution.

The W3C has created an HTML5 logo page where you can download the logo, have one generated for use on your site, see samples, order a t-shirt, and even send away for some free stickers. There is also a Frequently Asked Questions page for the logo should you still need some answers you couldn't find on the logo page.

The W3C blog has an interview with the creative director from the firm who designed the HTML5 logo.

Tip: If you do plan to use the logo, the files available for download are square, so they have quite a bit of space built into them on the left and the right. The 256-pixel-wide logo is actually 182 pixels when you crop it to fit (see above).

Update (Jan 20, 2011)

• A lovely ironical (that's my word) Flash version of the HTML5 logo.


• The HTML5 logo using the canvas HTML5 element (best viewed in Chrome or Opera).


• The Tardis in the style of the HTML5 logo over at Reddit.

Update (Jan 21, 2011)

• The HTML5 logo as if it were a Netscape Now! badge.


• Dunno how I missed Bruce Lawson's post, Two cheers for the W3C's HTML5 logo.

Read More

W3C and WHATWG Provide HTML5 Updates

W3C

The W3C is pretty good about posting news when new HTML/CSS-related documents undergo updates, status changes, or generally move forward. On Friday the W3C HTML Working Group announced the publication of eight new documents. The brief release provides an even briefer overview of each, or you can see the same list, with the ability to file a bug, at the HTML Working Group home page. The eight documents (all dated January 13, 2011):

1. Working Draft of the HTML5 specification.


2. An updated draft of the helpful HTML5 differences from HTML4.


3. The accompanying non-normative HTML: The Markup Language Reference, which is worth reading through if only to look at the items marked changed.


4. HTML+RDFa 1.1, which outlines support for RDFa in both HTML4 and HTML5.


5. HTML Microdata, discussing support for machine-readable data in HTML, ideally in an easty-to-write manner.


6. HTML Canvas 2D Context, which, I think obviously, defines the API for use with the canvas element.


7. HTML5: Techniques for providing useful text alternatives, a handy document for how to use the alt attribute and other related features (except longdesc).


8. Polyglot Markup: HTML-Compatible XHTML Documents, intended to offer developers guidelines for creating HTML documents that validate as both HTML and XML. It's worth a read just to understand the premise.

For those of you more interested in the progress of accessibility in HTML, you can always drop in to see the weekly W3C Accessibility Task Force (a11ytf) bugs which are just hanging out, waiting to be closed, verified, or sent along to the HTML Tracker. Laura Carlson (of the [webdev] Web Design Update newsletter) sends out a weekly email update with a link to the report, Pre-Last Call "A11ytf" Keyword Bugs Awaiting Task Force Action (these links are both from January 15, 2011).

WHATWG

WHATWG is trying something new — a summary. As the author writes, If this works out you might see another one. There is a chance, then, that you might not see another. At least the document posted on January 16 gives us some updates for now. Read it at Base64, model trains, Web Workers & the DOM, captions, …

Unlike the W3C status update, this one is more casual. It links to emails flying around between the members, allowing you as the user to dive right into a thread and follow it along. It is not scrubbed or converted to non-technical language, so it provides a nice behind the scenes look. For example, there is a link to an email, [whatwg] Google Feedback on the HTML5 media a11y specifications, that provides feedback from Google on the HTML5 media accessibility specifications. As the folks who run YouTube, Google's feedback is important to the success of video on the web, and so Google's rep discusses things like the track element and the caption text file format. Don't expect to see any references to codecs (like the Chrome/H.264 dust-up).

Bonus

Since reading this may have gotten you all excited over the specs and all things related to it, take a few minutes to read this post about a "Shadow Dom:" What the Heck is Shadow DOM? If you play at all with JavaScript (libraries or otherwise), you may be interested to read up on examples such as the new slider input element and how you can access the element within the input — but not via standard HTML/CSS selectors, only via script. After all, if you are implementing it, you will need script to make it do something, so leaving that to the client-side script makes sense as a developer.

There, now you have enough to keep you busy on what might otherwise be a slow Monday at work.

Read More

H.264 Getting Dropped from Chrome

If you pay any attention to the plodding chaos that is the development of HTML5, then you've probably seen the discussions around the video element and how best to encode videos. Over a year and half ago Ian Hickson gutted the video and audio portions of the HTML5 specification to remove all references to codecs, disconnecting the two competing standards, H.264 and Ogg Theora, from the next HTML standard. He did this in an email announcement to the WHATWG list, explaining the issues with licensing and browser support for both options.

At the time Safari refused to implement support for Ogg Theora, Opera and Mozilla refused to support H.264, Internet Explorer was silent, and only Google Chrome implemented both (though Google said it could not provide the H.264 codec license to Chromium third-party distributors).

A year and half later and Google has dropped support for H.264 from Chrome as of two days ago. While Google has hung its argument on the hook of license restrictions, it's probable that Google is really just pushing its own WebM format.

The licensing argument is simple — the compression parts of H.264 are patented by MPEG-LA. While MPEG-LA has opened up the H.264 license for the web (after originally saying it wouldn't collect royalties until 2016), it's conceivable that move was intended to get the web hooked on it. And then it's fair to assume the patent trolling might begin (history indicates the odds are good).

This announcement and the logic behind it has started off a mini-firestorm among developers on the leading edge of HTML5.

Ars Technica wrote up a pretty scathing review of Google's move in the article Google's dropping H.264 from Chrome a step backward for openness, suggesting Google's real issue is about control over its own WebM format. The article goes into more detail about Google acquisition of the company responsible for developing what is now WebM and compares and contrasts the licenses of these and other standards.

Haavard Moen, who works for Opera, takes some time to disassemble the argument made by Ars Technica in his post Is the removal of H.264 from Chrome a step backward for openness? He breaks it up into 11 points, corrects or contextualizes them, and then suggests that the bulk of the points aren't even relevant to the discussion at hand.

The chart below (and its comments) were unabashedly stolen and marked up from a graphic by Bruce Lawson (of Opera Software fame). He uses it to outline which browsers support which codec. I have added a column to list Ogg Theora.

Browser	Ogg Theora	Native webM Support	H.264 Support	Member of MPEG-LA H.264 Licensing Pool
Opera	Yes	Yes	No	No
Firefox	Yes	Yes	No	No
Chrome	Yes	Yes	No	No
Internet Explorer 9	No	No	Yes	Yes
Safari	No	No	Yes	Yes

The two browsers that only support h264 video are Internet Explorer 9 and Apple Safari, the vendors of which have a financial stake in the codec:
www.mpegla.com/main/programs/AVC/Pages/Licensors.aspx

The column in the chart asking about the MPEG-LA licensing pool is intended to show that the only browsers still supporting H.264 are those with a financial stake. Bruce updated his post with a link from a site visitor that claims that Microsoft gets far less from its financial commitment to H.264 than it pays in.

An argument that keeps popping up is that Google should drop support for Flash, given that it is not an open standard. I have dismissed this immediately on the argument that Flash has been here for a very long time, and it's not practical to drop support for a technology that is already driving millions of sites, at least not without the myopic world view that Apple lugs around.

That argument, however, made it into the post from John Gruber's blog, Daring Fireball, titled Simple Questions for Google Regarding Chrome’s Dropping of H.264. Remy Sharp was quick to respond on his own blog with My take on Google dropping H.264.

While Flash is only a part of that debate, it's further insight into the arguments we're hear from both sides. Some of the arguments will lean on a perceived double standard, as we see with the Flash example; some will lean on license debate, as we see with the constant references to MPEG-LA versus WebM and its background; some will lean on the quality of the video, which I intentionally left out of this post; and some will lean on who wants to be the next big monopoly for the burgeoning growth of video on the web.

For the average developer, it might be best to wait until the dust settles. You'll still be making decisions based on browser support in the end anyway.

Related

• Google Chrome drops H.264 support to focus purely on open technologies like WebM


• Google nixes direct H.264 support in Chrome


• The backlash over Google's HTML5 video bet from C|NET.


• Google reveals plan to remove H.264 support from Chrome from ars technica.


• An Open Letter from the President of the United States of Google from MSDN.


• Microsoft mocks Google's Web video decision from C|NET.


• GIF, H.264, and Patents from John Gruber

UPDATE: More Links from around the Innertubes

These links came rolling out this past weekend (January 14-16) and offer more arguments for and against H.264 and Google's decision.

• More about the Chrome HTML Video Codec Change from the Chromium blog.


• Why the Future of Online Video Is in Serious Trouble [OP-ED] from Mashable.


• VIDEO debate, cutting to the chase by John Dowdell from Adobe.


• John Gruber responds with Adobe's John Dowdell on Chrome Dropping H.264 at Daring Fireball (instead of responding right on the blog, where two men can have an open debate).


• Why the Web needs WebM by Anne van Kesteren, who works at Opera.

Update (January 21, 2011)

• A Simple Explanation Of The Huge WebM Versus H.264 Debate

Read More

Time to Update Your Web Site Copyright Date

I wrote this up for the support forum for our web content management system, QuantumCMS, and thought it worth repeating here. The writing style is a little different considering the different audience. Think of this as a reminder to all of you who include a date on your web site in any way — I absolutely judge whether your site is relevant by how out of date the copyright year is in the footer. I also look at any other timestamps I can see (blog post dates, comment dates, etc.) for clues to the age of content.

The original post:

It's that time of the year where you should take a few minutes to log in to QuantumCMS and update the copyright date on your web site. If you don't remember where it is, for most of our clients it's a Site Property that you can edit. If you don't remember how to edit that property or don't have your documentation handy, this tutorial can help: Adding a Site Property (it also works if you just want to edit the existing property).

Why is it on your site?

Perhaps you only have a copyright statement on your site because we included it in our design, perhaps you have it because your legal counsel suggested it, perhaps you only have it because you've seen it everywhere else. Since I am not a lawyer, doling out legal advice isn't in the scope of this post. You can ask your own legal counsel about how declaring a copyright protects your content.

I am writing this from the perspective of U.S. companies, although I know some of you reading this are not U.S. companies. In that case, I suggest you check your own country's laws on copyright.

If you are more inclined to track this information down on your own, you may want to take a look at the U.S. government Copyright.gov site, specifically the page "What Does Copyright Protect?" which links to a PDF file ("What Works Are Protected?") containing the following statement:

No publication or registration or other action in the Copyright Office is required to secure copyright.

If you are adamant about registering your web site with the U.S. Copyright Office you should grab a copy of "Copyright Registration for Online Works" (provided as a PDF file).

How else is the copyright date used?

I'm glad you asked.

Many web site users see the copyright date as a quick cue to how fresh the content is, even telling them if the site is stale. If you are visiting a site with a date of 2009 (and it is now 2011) in the footer, you might think that nobody has touched the site in two years. And you might be right.

Many sites use the copyright with a year span (1998-2011, for example) to demonstrate how long a site or organization has been in existence. This may not impart any added benefit if you are pursuing somebody who has stolen your content, but it does at least indicate to users that you have been around for a while, are current, and probably know a good attorney.

Don't wait too long to update copyright date on your site. If your site claims to be from 2010 then it is at least over a year old, and at most only a couple weeks old. Remove that confusion by taking a few minutes to update it.

As always, if you need any help just give us a call or send us a note.

Read More

Twitter As Passive-Aggressive Enabler

There was once a time that if you wanted to lodge a complaint with a company or organization, you could rely on writing a strongly-worded letter. You might get a response in 6-8 weeks. Then came a point when you could call a support line and speak to a human being and, for questions beyond a missing item from an order, your issue might have to go up the chain and you'd hear back in a week or two. Then email came about and a customer issue could be sent up the chain with a simple press of the "forward" button, reducing turnaround times to a day or two. Now there is Twitter, where a complaint directed at an organization's Twitter account, if not answered within a couple hours, is considered terrible customer service.

Forgetting all the companies that do it incorrectly (creating a Twitter account that only broadcasts, doesn't engage, and doesn't have a human personality behind it), there are organizations that have employed people to monitor social media (Facebook, blogs, etc.) to look for mentions of a company and, when negative, to proactively reach out to soothe the offended party.

My Own Recent Experience, Which You May Skip

I had my own experience lately where, after a painfully awful ecommerce experience, in my rage I tweeted how terrible it was and included the offender's Twitter handle. To the offender's credit, response was relatively swift for a Saturday afternoon. And then I realized that I had used Twitter to become a passive-aggressive whiner. The response from the offender only enabled that.

In an attempt to offset my poor behavior, I wrote up a very detailed email explaining the issues I encountered and sent it along to the offender's email address (I had already informed the offender it was coming). I asked for nothing in return — no free tickets, no special consideration. I followed up the email with a phone call a day for three days, never getting through to the offender's contact and never receiving a return call. What the offender did do, after my third call, is send me an email thanking me for my feedback and assurance that I would be taken care of. In addition, I received a friend request from this person on Facebook. A week later I received a voucher in the mail for two sets of free tickets, something I did not expect, and which even made me feel a bit guilty.

To the offender's credit, the response was swift and reparations were made that far outweighed the balance of my anger. But I never did get a human on the phone. I was relegated to an email-only exchange. Given the Facebook friend request, I couldn't understand why I was invited to connect with the representative personally when we had never exchanged words on the phone or face to face.

Anecdote Over, Now Back to the Meat

This entire experience got me thinking. I spent some time researching customer service in the context of Twitter. Comcast's own efforts have been a de facto standard for a couple years now, so it's easiest to explain the process through the lens of how Comcast started the ball rolling. Essentially, a very frustrated user complained about his Comcast connection on Twitter, and within twenty minutes received a call from an executive on the other side of the country. The guy who complained wrote up the story for TechCrunch and it became sort of a call-to-arms for companies who are playing social media and want to stand apart. You can read the full story in the post Comcast, Twitter And The Chicken (trust me, I have a point). Shortly after that article, ReadWriteWeb posted the article How to Get Customer Service via Twitter, which outlines how companies can and should monitor social media and how customers can leverage the platform.

This has enabled people to not reach out to a customer service phone number, a store manager, or make some other concerted effort, but instead to complain to the ether in the hopes someone is monitoring for such gripes. Often the complaint doesn't even warrant a response (is it really necessary to complain about the color of chairs?), but because it's so easy to do, the complaint comes out. Sometimes it's the equivalent to complaining that the steak was overdone, but only after you ate the entire thing (not just a tribute to Waiting, I have seen this in real life over and over). Organizations are rewarding these miniature rants by trying to soothe and ultimately offering something in return. And that rewards the people who gripe in this passive fashion, but not necessarily those who take more direct channels. It also means companies who are not monitoring social media may be unfairly judged as dismissive (does my local hardware store really need to be on Twitter?).

There will be times when the stewardess is a jerk. I don't expect the airline to give me free tickets as a result. Sometimes the waiter is in a bad mood, but I don't think I deserve a free dinner. My barista put too much foam on my latte? I'm so lazy I paid to have someone who is not me make it. The tech support rep doesn't have an electrical engineering degree and couldn't guess that a solder melted on my machine? Oh well, he can't peer across the phone lines into the hardware and see such things. I suck it up and recognize that these are real people with real lives, not mechanical protrusions of some corporate machine.

And yet too many of us feel entitled to being kept happy without reason. I'm not saying that life needs to be nasty, brutish and short, but it certainly can't be all rainbows and lollipops simply because we expect others to provide. Customer service (over)reaction on Twitter feeds this. People demand satisfaction quickly and out of balance with the issue. And when they get it, they talk about what a great experience they had, teaching others to use the same bad behavior to get their way.

Unfortunately, this builds on and reinforces behaviors that are already extant in our population. People pull out their cell phone cameras before calling 911 when they see a car accident. They take and post photos of their friends in compromising situations (which are usually nothing more than passing moments of poor timing and good photo framing). Couples engage in fights over text messages and forward responses to their friends. People maintain multiple Twitter accounts so they say what they really think about bosses/ex-lovers/family from a "stealth" account without fear of reprisal, or rather, fear of being honest and direct. These are all examples of how people give up their responsibility as a good neighbor to instead be the one to scoop the news, embarrass their friends, or win a pointless squabble. Unfortunately for so many who are not socially savvy, who rely only on examples of what the broad populace does, these cases only promote passive behavior — often passive aggressive behavior.

Perhaps if you are someone responsible for setting a policy of responding to complaints from Twitter you should consider getting the complainer on the phone. Usually, if it's worth complaining about, it should be worth spending a few minutes on the phone with a customer service rep. Those who resist are probably nothing more than whiners anyway. Sure, there is a risk that someone will complain publicly (blog, review site, etc), but you can demonstrate that you tried to reach out and were rebuffed. Maybe those aren't the customers you want anyway.

And if you find people engaging in other passive behaviors that involve you, perhaps the best thing you can do to ensure real and honest interaction down the road is to insist in face-to-face meetings or at least phone calls. When 44% of U.S. respondents to Opera's survey about mobile web use say they have asked someone out on a date via text message, it doesn't take much imagination to guess how those conversations go (lots of insincere "lol"s and other acronyms designed to give the asker a way out if the answer is a "no"). Perhaps instead of allowing people to text/Tweet you on a whim to get together, you should expect them to commit to it by making plans (gasp) a day or more in advance. Now you can take some comfort in the knowledge that you aren't getting the invite only after everyone else has declined.

Whether professionally or personally, don't be lured to the ease that Twitter (Facebook, et al) allows you to snipe. Make the effort to be direct and approach the subject of your ire. If you are on the other end addressing complaints, then don't fire back in the same medium. Reach out in the real world, showing that you care enough about the person or issue to make an effort. For both sides, don't hide behind the keyboard.

Related

• How Twitter will corrupt contact


• Social Media Responsibility

Read More

Year-End Cliché

I can't turn on the TV, surf the web, or peer into my Twitter feed without stumbling into another year-end wrap-up of 2010. These dime-a-dozen contrivances abound like the proverbial lemming to the cliff (lemmings don't really do that, it's also a contrivance). However, there have been enough of some quality that I think they bear mentioning. So here's my own trite year-end cliché.

Jeffrey Zeldman collects many of his articles in a list below a narrative full of links to outside sources. His focus is on, predictably, web standards and manages to hit the salient points without a wandering review full of self-congratulatory hullabaloo. Read his post 2010: The Year in Web Standards.

Media Access Australia, a member of the W3C WAI and Australia's media accessibility not-for-profit, has an article running through everything the WAI and its groups have accomplished this year with some information on what might be in the works for 2011. Personally, I was hoping for some more detail on the WAI-ARIA progress, something causing those trying to implement it with HTML5 some headache. Given that the Australian government is mandating WCAG AA compliance over the next few years, they are kind enough to include a link to their own article on the topic. Read the scoop at The W3C web accessibility initiative — 2010 year in review.

The Yahoo! Accessibility blog doesn't take a look back at accessibility, but instead talks about resolutions to make for the new year. Among those resolutions it suggests we should all make in order to create a more accessible web are: adding captions to videos, creating structure for your web pages (hooray for proper heading nesting!), account for keyboard users, and learn to use a screen reader. It's only been a day, but the post is sadly lacking in feedback. You can, of course, add your own by visiting the post: What are Your Resolutions for an Accessible 2011?.

If you like your web accessibility tips with some curious intro music & audio quality, without all that troublesome reading, you can grab the WebAxe podcast reviewing the year in accessibility. If you are willing to sit through 32 minutes of audio (skip the first four minutes, or jump to eleven minutes for the year in review), there are some juicy nuggets in there. Even better, just follow the links on the post and read through the transcript. There are some good bits about alt text, the longdesc attribute, colorblindness, HTML5, and other bedtime reading for the kids. Grab the podcast, transcript and, most importantly, the links at Podcast #87: Web Axe 2010 Year in Review.

Two sets of predictions for the coming year come from Mashable and ReadWriteWeb. Mashable's is more of a list of prediction lists and ReadWriteWeb has its staff give predictions for the coming year. Why Mashable gives its number as 95+ and not just 96 makes me wonder if they got lazy with counting. At least ReadWriteWeb mentions what its team got wrong last year (along with a link).

• 95+ Predictions for the Web in 2011


• 2011 Staff Predictions

If you saw my recent kvetching over the demise of Brightkite, which caused me some stress as I worked to extract over 4,000 posts and images, then you hopefully wondered the same about your own presence on the web. In a not-quite-thorough-but-at-least-well-timed post from Mashable you will find some tips for archiving your data from some of the more popular services (Twitter, Facebook, WordPress, etc): HOW TO: Back Up Your Social Media Presence Before the Ball Drops.

While reading through lists of the year, I found one that got some references from good sources, but really left me unimpressed. I figure I might as well start of the new year with a little friendly disagreement, so I'll review. The 5 Biggest Interface Screw ups of 2010 seemed to be stuck in a time warp, hitting items that are actually quite old (as in, from the 1990s). Its list:

1. Splash Screens: I wrote about this in 1999 (also at my site), and I was already late to the party. This is not unique to 2010,


2. "Click here" links: In 1996 Jakob Nielsen recommended against that practice, echoed later by the W3C WCAG in 1999.


3. Unclear dia­logue boxes: I found some of my first examples of this, and diatribes against it, in Bruce Tognazzini's 1992 book, Tog on Interface.


4. Fanci­ness over usefulness: His example is a computer desktop interface based in a real-world metaphor. It may be the worst example in 2010, but it's a repeat of the 1995 Microsoft BOB interface of confusion targeted at neophyte users.


5. Poor but­ton placement: The author's point is really about mobile UIs, which is at least recent simply because consumer-oriented touch interfaces are relatively new. I'll allow this one, even though it's clearly based on the failure to apply Fitts's law, which dates back to 1954.

Now that I've satisfied my ego by taking shots at an easy target, I wrap this up with a contribution from the old man of pointing out the terrible, Web Pages That Suck: Worst Websites of 2010: The Contenders and Worst Websites of 2010: Group 2 Contenders.

Happy new year.

Read More