See what I did there, David?

And what were they smoking?

Today I posted the following on Twitter without thinking much about it:

“There is no Mobile Web. There is only The Web, which we view in different ways. There is also no Desktop Web. Or Tablet Web. Thank you.”

I certainly didn’t expect the enormous amount of retweets, which hopefully means that most people understood what I meant. But some didn’t, or didn’t agree with me. Which is a good thing, but only if my point is clear. So allow me to explain.

Most sites on the web are not built with specific mobile use-cases in mind. However, millions of people access these sites every day through mobile devices. They access a “normal” (whatever that means) website through their “mobile” device. In these cases, the presentation of the content on mobile devices is potentially important. As are the intrinsic characteristics of this content on the mobile platform; take image size as an example. Manufacturers cater to the users of “non-mobile” websites on mobile devices via things like zoom, which although inconsistent across devices, makes viewing most websites on a smartphone bearable. Developers can do their part by adjusting the served content or the presentation.

That said, simply adjusting the presentation of content or pieces of content on a website does not, in my opinion, constitute a “mobile website”. It’s a website for which the developers have considered the users of mobile devices and adjusted certain things accordingly.

As the venerable Thomas Fuchs points out, there are specific mobile use cases and thus mobile-specific websites or web apps. I agree. By the same token, there are websites and web apps which were designed with solely the desktop in mind (and oftentimes with a certain browser in mind). Yet we don’t speak of the “Desktop Web” when referring to these apps. Ironically, that’s exactly what we do with mobile.

To be honest, I can think of a few, but not many use cases of web sites or apps which are or should be exclusively mobile. It seems like the Mobile Web allows us to revisit all of the talk of inclusion, progressive enhancement and accessibility from years ago.

Much of this is semantics, I’m sure. I use the word “mobile” in my own job title, which obviously borders on hypocrisy. Why? Because if people understand the term this way, it’s easier for them to understand that part of my job is to consider users of mobile devices when doing design consulting for clients. So I use the term the way they understand it. It’s just not in line with how I see the Web personally.

Many developers also consider desktop browsers. And text browsers. And screen readers. And possibly print. Or e-books. Or whatever. Because the Web is about universally accessible structured content. Which data you get and use and in what form will depend on your device and your circumstances. Your context, if you are so inclined. And that will constantly be changing.

So maybe it’s a semantic distinction and I’m simply exaggerating like the American I am. But as long as there are developers selling and building completely separate mobile websites or iPhone websites or iPad websites where well-designed universal websites would suffice, it’s not only a semantic distinction.

One web.

But that’s the thing: we’re talking about bookmarks, the loss of which will hardly leave you living out of a cardboard box. And what happens when bad things happen to Flickr? GMail? Evernote? That site you do all your finances on? Project management and invoicing? Time tracking?

You may back up all your data, which makes the downfall of any of these services less painful. Unless you just keep your original photos on your own computer, but all of your photo metadata was entered on Flickr and you have no backup of that. Poof! But we all know Flickr’s not going anywhere, right? Too many users. Actively developed. Very popular. Cough. It’s the same reason we can depend on YQL (which I still find absolutely brilliant BTW). Yahoo! will give us all at least six months notice if they decide to pull the plug on YQL, which gives us the time to change all of the client work we made utilizing it. And of course our clients will have six months to get a budget to hire us to make the necessary changes.

But what are we complaining about? It’s all free. Having to move our bookmarks is not really a huge problem, but we all seem appalled that large companies care about money. Since when is this an anomaly? Company sees something cool, hopes to make money, buys it, doesn’t make enough money, poof. Here’s a truth for you: most companies only care about your data insofar as this data can help them make money. They have this site and you fill it. You fill it.

A couple of years ago I was on the fence about this. No longer. For a while we’ve posted our data all over the internet on all types of services. These services provide APIs so we can access the data we put into them, so that we can do things with that data. Read that again.

Richard Stallman, in his usual come-out-swinging way, has commented on this before. And I believe he has a point. Our data is our own, and it’s up to us to look after it. But how?

What if we flipped this all on its head? What if we hosted our own data, and provided APIs for all these webapps so that they can use our data? I can imagine that to be a substantially cool use of RDFa/Microformats and whatever metadata/semantic web technologies you prefer. Isn’t one of the points of the semantic web to make decentralized information meaningful, retrievable and mixable?

So instead of having our own websites aggregate our own data from other people’s websites, we’ll let other people use the data from our own websites. Photos, meaningfully tagged, can be pulled in by Flickr via our own personal API, if you will. We provide the structured data, Flickr provides the functionality. The sharing. The social. Why not?

Personal publishing platforms like WordPress, Drupal, [your favorite here] could be extended to make use of microformatting, RDF, etc. and provide tools for syndication, as we now do with simple blogposts. Services don’t need to host our data. They only need to do cool things with it. So when I quit service X, or service Y falls the Way of GeoCities, I don’t need to do anything but cancel my account. Or leave it and forget about it. If I change my information, it’s automatically changed on all the services using it. Storage space is up to me. Privacy settings? Totally up to me.

Awesome, providing the host doesn’t go *poof*.

Let’s get to it.

[Disclaimer: As some services die, some of the above links will rot. Make of that what you will.]

[UPDATE: Please also read Jeremy Keith's related post from 2008.]

Fronteers 2010 in Amsterdam was definitely the best Fronteers yet. I was honored to have been invited to speak for the third year in a row. As Chris Heilmann points out, the two of us share that privilege, and a privilege it is; the Fronteers team has put the conference on the map as one of the top front-end design and development conferences around today.

Aside from speaking, Fronteers was a great opportunity to see some friends again and meet new people, and to see some of my favorite web talents speak as well:

Day one

Day one kicked off with Jeremy Keith on HTML5. Jeremy is one of the best thinkers in front-end development and a *fantastic* speaker. He presented a clear overview of past, present and future HTML5. I also finally got to meet him in person after reading so much of his work through the years. And, he built Huffduffer, which you should try.

Robert Nyman. What a character. A very informative presentation peppered with images of celebrities, which misdirected the audience from the fact that Robert has cloned himself several times in order to keep up with all his work.

I’m a big fan of SVG, so I thoroughly enjoyed Brad Neuberg’s presentation, which could have easily been called “show off and make your friends jealous with SVG“. A well-rounded look at this vector graphics format.

Håkon Wium Lie shared stories and images about the beginning of the Web and the history of CSS. Especially enlightening was seeing a picture of the world’s first web server. He finished up by sharing some of his ideas about the future of the Web. Since he is CTO of Opera Software, I do of course expect him to get CSS3 Template Layout implemented soon. To this end, I had to have a little chat with him during the break.

I loved Stoyan Stefanov‘s session on performance. Lots of little tricks in this presentation and some things I didn’t know, but can apply today. Good stuff, and a super-nice guy.

I’ve admired Jina Bolton‘s work for a few years. She’s done a lot of work educating people about and promoting CSS, and it’s easy to see why. While her subject matter was tried and true, it served as a good confirmation of some best practices, especially within teams.

Jake Archibald‘s presentation on design principles for building APIs was insane. Jake’s presentation style is a flurry of insight and humor. There was plenty to learn and lots to laugh about. Absolutely awesome presentation.

Day two

I kicked off day two, basically discussing progressive enhancement all over again in light of the current obsession with media queries. The slides were minimalist, but I found using SVG quite flexible. (Some people have asked about the slides, so I will post the SVG file very soon, with an explanation of how I made the slides).

Moving on…

Paul Irish… what can I say? The Web is his little plaything, and does pretty much whatever he wants it to.

Meagan Fisher‘s slides were gorgeous. She walked us through the subtle use of texture, rgba() and text-shadow and box-shadow to turn a bland, wireframe-like page into something delicious.

I didn’t get to see Nicholas Zakas’ presentation on High Performance JavaScript, as I was drafted by Andy Clarke and Dan Rubin to take part in their talkshow session which took place in a second room. It was a fun session, and should have lasted at least another half-hour, as not all questions could be answered in time. As far as Nicholas goes, I can’t wait to see the video of his presentation.

Steve Faulkner and Hans Hillen talked about HTML5 accessibility, and the message was pretty much that it’s not ready yet. But they did give some valuable tips for introducing some WAI-ARIA into your HTML. Christian and I especially loved the slides.

As a big fan of Robert Hodgin‘s work, it was great to see Cameron Adams talk about animation on the Web. Cameron’s presentation also challenged the Flash-bashers, certainly causing me—and probably many others—to stop and think about which technologies are better suited to which goals. Cameron is also a great guy to have a beer with.

As far as I’m concerned, the star of the show was Chris Heilmann, with his inspirational and hilarious presentation designed to motivate us to Go Forth and Make Cool Stuff. Being the web developer’s answer to Anthony Robbins is no easy task, and Chris pulls it off beautifully.

All in all, I had a fantastic time. My compliments go out to the Fronteers team; they really did a superb job putting this conference together. I think we can expect great things for next year!

Ten years ago, I left my career as art director in print design and joined the company that—two years later— would evolve into Cinnamon. I had been learning about and creating websites since 1995 and I welcomed the opportunity to work full-time on the Web.

As many baby-faced entrepreneurs, I knew nothing about running a business, and less about “doing” business. Hungry as I was for new opportunities, I didn’t stop to think about what running a business meant; I was on board to lead creation of the product.

Cough.

After some management Musical Chairs, I found myself in the position of having to get clients, keep those clients, and lead our team. Not to mention the usual financial responsibilities. I was schooled as a fine artist and graphic designer. The first time I sat across from a potential client, knowing I needed to get the business, was terrifying. I didn’t know this stuff, I just learned as I went.

It was hard at first, but I began to get the hang of it. We built a pretty stable team and decent focus. The main team has been, with one exception, the same since 2006. It’s kind of like family, and that makes it hard to step out and move on. So why?

I love the Web. I love what we do. I can imagine no better job for a creative person who always craves New Stuff. Making the Web means parsing information, giving it meaning, making it accessible, making it usable and (in my opinion) making it beautiful. There are new challenges every day, and with those challenges come new ways to meet them. And if those methods don’t suit you, you can come up with your own. There are rules, yet there are none. The Web, for me, is where my main interests—art and technology—meet, flirt and make babies.

When I started this adventure, I did it because I wanted to make cool stuff. Pretty stuff. Useful stuff. Through the years I ended up selling stuff and managing the People Who Make the Stuff (while periodically sneaking some art direction, design and production work in for myself). And we did do cool stuff. Cinnamon was one of the first companies to combine professional design with web accessibility. Lots of firms do that now, but in 2002, accessible almost always seemed to mean “looks better to blind people”.

But now it’s time for me to get back to why I got in the game. It’s time to focus by removing operational distractions. It’s time for me to create a more balanced work-world, which can allow me freedom to do what I love to do and enjoy my personal life as much as I can. I’ve learned a lot about clients, and as an independent contractor, I want to help them stop being their own worst enemy. I want to help developers do the same. I want to spend more time with the technologies which will allow designers to do more with the web (yes, that includes CSS3 layout). I want to focus on helping clients with what we now call the Mobile Web, which I believe will catalyze some new, platform-agnostic thinking about information, what we can do with it, where and how. And I’m always so full of ideas… it’s time to write and speak about these things more frequently.

I wish my colleagues at Cinnamon all the best. They’re all great and talented people and they’ve been incredible, and they will continue doing great work for some really exceptional clients. And they’re not rid of me completely; there are at least a few projects we’ll be doing together (do I hear profanity?). And next time we go for beers, I’ll be their peer and not their boss.

I’m pretty nervous about it, to be honest. It’s like bungee-jumping—I’ve never done that either. It’s too easy to look down and imagine what it will sound like when the cord snaps. But I’ve done a lot of good work. I’ve helped other people do good work. And I’m looking forward to doing that in the future—of my own design.

• Writing, coding: vim (usually MacVim, to my credit as a visual person, thank you)
• E-mail: mutt (I know. But really, my skin has a healthy glow and I do go outside and enjoy the sun)
• IRC: irssi
• RSS: canto
• Twitter: twitvim
• Written documents: LaTeX
• Drupal: drush (Drush rocks.)
• Task management: Taskwarrior

It seems weird, but for me, these types of activities don’t need eye candy, but effectiveness and speed. And these apps provide that. They are also all free to use and work on several platforms.
I’m especially happy with mutt and canto. Mail and feeds, in the amounts I consume them, usually take up huge amounts of time. With these apps, I can zip through them relatively quickly.

I’ve been increasingly biting in my reactions to many admittedly fun but practically useless “demos”, “experiments” and other assorted HTML5 and CSS3 nonsense like CSS3 icons. I always get flack for this, and I probably will now.

While these experiments are easily defended—“just wanted to see what was possible”—they are generally non-complex (though they can be tedious; take one look at a CSS3 icon or font). They are, put bluntly, simply a way to show off. And as long as that works, it will continue. But what are these experiments helping, aside from the reputations of those who make them(!)?

Please note that many of these experiments utilize a technique that I and many other art directors and designers have used for ages, which greatly enhances product appeal. It involves simply combining two things you wouldn’t ordinarily expect to be together: CSS and fonts. CSS and icons. HTML and games. Peanut butter and chocolate—Hershey/Reese’s Peanut Butter Cups have used this to their advantage for years. And so forth. The first person to build real beer from Javascript will be speaking at conferences for years to come.

I could say more, but Chris Heilmann said it so well, there is no need:

Right now, we are happily thinking we innovate and push the envelope where in reality we are making each other go “Oooohhhh” while a large chunk of the audience that could benefit from our knowledge is stuck with really poor experiences on the web.

If you haven’t, please take a moment to read his article.

You should read the post. Then form an opinion. Mine is that vendor prefixes are no fun and quite annoying, but a necessary evil. At least for now. There’s no need for me to go into why, as Jonathan Snook makes the point well.

My biggest problem with vendor prefixes is the repetition (read: not the amount of typing), and the fact that I’ll one day need (okay, want) to go back and clean prefixed rules up once they’re no longer necessary or when the implementations change, which they can. I just want a clean style sheet.

A few workarounds, or deal-withs, were mentioned in the comments of the aforementioned posts:

1. A single “beta” prefix
2. CSS preprocessors
3. A separate style sheet

I like the last option the most, hat tip to Bridget Stewart for beating me to it. A separate style sheet fits my current practice of giving each element of design language its own file (I know about the performance implications, but there are plenty of solutions to that). So a generic group of style sheets for a given website might look like this:

• layout.css
• type.css
• color-img.css
• vendor.css
• ie[x].css

This is clean. Non-prefixed properties are entered into the normal style sheets, and will (hopefully) be ignored by browsers which don’t understand them. Prefixed properties are placed in vendor.css. And what I would really love is for CSS3, Please! to generate vendor.css for me (That was a hint, guys). Sure, there’s the risk of the spec changing, so it’s up to the designer/developer to be wise in deciding which things should be specified without prefix in the normal style sheets.

Why not the other two?

To be honest, something like -beta- might not be a bad idea, but as of yet, the fact that vendor prefixes are browser-specific is the only useful thing about them. A universal prefix is just that, universal, which could potentially introduce the same problems we would have with no prefixes at all.

I’m not a big fan of CSS preprocessors, or at least I haven’t seen one I’ve liked. We’re talking about CSS; it’s not all that hard to deal with. My problem is not with typing things out three or four times. And I don’t need a preprocessor to do that for me, as prefixes and things like rgba fallbacks are easily accomplished in any decent editor through snippets or scripting. And for those without a decent editor, just use something like CSS3, Please!.

How do you cope?

You only need to subscribe to www-style for about a week before realizing it’s going to take more than three people calling “-beta- prefix!” to get browsers to do it. When you dig down deep enough, there are some very, very smart people who have thought a lot about certain things (and admittedly less about others). It would be a good practice to research or ask why something is as it is, and perhaps participating in www-style and submitting ideas.

You could also try vendor.css. If you hate prefixes, at least you’ve gathered them all together in their own little prefix hell.

How do you deal with vendor prefixes?