Opinions - MIX Online

Rethinking the Traditional Convention Booth at MIX10

Thomas Lewis — Wed, 17 Mar 2010 18:15:23 GMT

At our MIX10 conference for web developers and designers, the MIX Online community team (us) was given an opportunity to display a booth in The Commons. At first, we politely declined.

The Unbearable Lameness of Convention Booths

There were a few reasons why I was uninspired about having a booth.

I find the traditional pipe and drape booth layout rather boring.
We will have teams from Microsoft and sponsors who attendees will be super excited about and will eclipse what would be our little, humble booth.
We are not resourced on my team to “work” the booth and find “rent-a-booth-babes” insulting.
I would want a place that was a unique experience and I could hang out in with our amazing attendees vs. promote, promote, promote.

Then I realized…that’s exactly what I wanted: a unique experience where attendees and the team could hang out together.

Introducing the MIX Online Lounge

Instead of having a booth, why not have a lounge instead? But what about all the issues I had just alluded to having a problem with?

Well, I began putting on the designer hat and tackled the constraints one-by-one. By creating a lounge, I had just solved the “manning of the booth problem” since a lounge does not require constant feeding. We created an area that folks can sit down (more on this later) with plenty of seating space, power strips to plug in those hungry laptops and tables to put their feet up or show off something they are working on (a.k.a. networking). Now this does not mean that we won’t be there, in fact when someone on the team is not involved in other activities (i.e. presenting sessions, keynote dry runs, live streaming setup and maintenance, customer meetings, firedrills, etc.) we will be hanging out talking to folks.

How a Mushroom gets Attention in a Field of Flowers

Now our little lounge has some stiff competition for attention since we will be announcing some amazing thinks in the keynote. So how do you get attention when there are so many choices?

Do the unusual.

First, we decided to hand out commemorative posters for the event, not us. That’s right; we didn’t market our own community site, but instead decided to provide something to attendees that they would appreciate. Our URL is on them, but very understated. We also made sure that attendees didn’t have to worry about figuring out how to keep from damaging their poster (the paper stock is awesome that we used) by figuring out which tube roll to use (sort of like prototyping). We found a tube that was small enough for a suitcase but large enough not to crease them.

Second, our banner is not the traditional Microsoft banner. We even decided to deviate a bit from our MIX Online style guide and really vie for the eyeballs. This is not your father’s Microsoft banner. It plays off of our mascots, the mushroom man and lavender frog and is very noticeable at 25’x15’.

Finally, we decided to really go out of our way to create a unique experience. The amazing folks at ThinkAlt who worked with us to design this experience mentioned in one of our meetings:

“Hey, we know a designer who creates mythical creatures out of common furniture. Would you be interested?”

ABSOLUTELY.

So we decided instead of the traditional convention center standard-issue chairs and couches, wouldn’t you prefer to sit on a caterpillar couch or a 7-foot alien chair? Yes, yes we did.

Stop…mushroom men, lavender frogs, 7 foot aliens? Are you insane? Maybe; but we think that it will create excitement, buzz and adhere to the MIX conference ethos of “Unexpected”. Also, how would you like to hang out talking about web design while sitting on mythical creatures? We are looking forward to attendees hanging out, doing podcast and video casts from our lounge (note: if you want to interview someone from the MIX Online community site team, please e-mail us), and most importantly engaging in great conversation and fun with us.

To Be Continued…

As you can imagine, we are excited. Come back during the MIX10 conference for pictures of the lounge and some of the fun stories that came from it. If you are attending, be sure to come by and pick up your commemorative posters and stickers. Also, check your swag bag because the MIX Online community team put a little something lo-fi in there for you. Be sure to follow @mixonline and me on Twitter to keep up on what is happening at the lounge in real-time.

Update: The MIX10 conference is now over and I guess we could say that the MIX Online Lounge was a success. My worries that folks would see it as an “art piece” was unfounded. Attendees would catch up on e-mail, have power meetings and take pictures of the lounge and of themselves enjoying the lounge too.

Bass-ackwards

Tim Aidlin — Tue, 09 Mar 2010 20:50:24 GMT

I recently had a conversation with a random developer I hadn’t met before. Within a minute of our introduction, he had launched into an enthusiastic, but very misguided, demo of a new technology he was excited about.

Why misguided? The technology in question was meant to solve a problem no one had.

When he asked me what kind of application or site I thought could use this technology, my first thought was, “Again, finding a problem for a solution. Exactly the opposite way I generally try to work on projects.” But instead of saying that, I asked:

“What problem does it solve?”

“What do you mean? You could move around data, put it here or there and connect it—all sorts of things.”

I said to him, “I guess I work a little differently. I try to think about the problem I’m trying to solve, and don’t think about the technology we’ll use until much further in the process of designing the spec.”

“But this technology could really be used in all sorts of applications,” he said.

“Totally. It’s super-cool, and I’ll think about it when I’m specing out my next project.”

“Maybe you can build a project around this technology.”

“Building a product around a particular technology sometimes works, but we find our most successful projects start from trying to solve a problem first, and applying technology to it second. It’s kinda like showing engineer a carburetor and telling him to build something around it."

This conversation struck me as a fairly extreme rendering of a common design snag: building for technology, not to solve problems. You see this all the time, and not just in software or Web site design. I’ve seen it in landscape design, city hall, and the day care, too. What are your favorite examples of solutions without problems? Leave a message in the comments below.

Cheers to Saying No

Tim Aidlin — Mon, 22 Feb 2010 23:03:59 GMT

The other day I was out having a pint with a web-designer friend of mine, and she relayed a conversation with a client she'd had that day. I had to chuckle a little.

“So, Client X called me today, and she’d like to do a whole branding and website campaign,” she said.

I had heard about troubles working with Client X in the past. “Client X, huh? What’d you tell her?”

“Well, I gave her a standard ballpark figure, but told her I wouldn’t be able to get on it until the end of next month.”

“And of course she needs all of this done now.”

“Of course. So she suggests that she have one of her friends build the website while I work on the branding, and we might be able to get it out on schedule.”

“But you can’t start on this until the end of next month,” I said.

“Oh, but if someone else is building the website, then I should be able to do it now. According to her, of course.”

“Ah, yes. And this web designer is going to build the site without any branding or content, I’m assuming.”

“And Client X wants me to go ahead and ‘take the reigns’ on working with the web developer and just include her on the meetings as necessary.”

“Ah. So, project management, too. I see. And will you be writing content?” I asked.

“No, but she’d love me to help edit it.”

“Hmmm.”

“Oh, and if I could add a shopping cart, and some cool animation, that’d be great, too, but that might require more work with the web developer. Is that hard to implement?”

“Wow,” I said.

“Yeah,” she responded. “So, no, I’m not taking on the client.”

“Thank you,” I sighed. “I don’t know if either one of us would be able to stand having beers and talking about this for months and months and months. Because you *know* this would change 4 times.”

“Cheers to saying no.”

“Cheers.”

Where do *you* draw the line with projects? When do you push back on a feature, request, or even the project itself? Let us know by leaving a comment below and be sure to follow us @mixonline.

Springing Out of Nowhere

Hans Hugli — Fri, 12 Feb 2010 19:46:50 GMT

When did you become aware of the great sites that exist on the web now? Were they there for a long time, but you just didn’t notice? Have you come across new sites you now can’t live without? What is that makes a new, amazing site so amazing?

Once You See It, You Can’t Stop.

Let’s talk about the last time you might’ve purchased a car. After you bought it, did you all of a sudden see other people driving your car, maybe even in the same color, everywhere? You probably wouldn’t have noticed those cars driving around if you hadn’t just bought your own. But they were there. This situation is a lot like a psychological phenomenon that Carl Jung referred to as “Synchronicity”: the occurrence of two or more events that are causally unrelated, but that occur together in a meaningful manner.

I’ve found that “synchronicity” often describes people’s experience of the web. Have you noticed that since social networking sites have become popular, you tend to see their icons canvassing the web? Do you now see signups for tweets everywhere—on billboards, ads, television, the web? Now that you know about Twitter, are you unable to get away from it?

The ubiquity of sites I know about makes me wonder: what’s out there that I’m not seeing?

You Don’t Know What You Don’t Know.

Charles H. Duell, Commissioner of the US Patent Office, said this in 1899: “Everything that can be invented has already been invented.” Poor Charles probably took his misquote to the grave.

Time has proven that innumerable inventions and opportunities had not been discovered in 1899—since then we’ve discovered (or created) everything from the Ziplock bag to the Internet. Even in 2010, it’s arrogant and narrow-minded to believe that we’ve already thought up everything there is to think up.

All the Low Hanging Fruit Is Gone. Guess We’d Better Get a Ladder.

Sure, all the simple stuff has been done. But aren’t we all astounded when that new something pops up out of nowhere and enriches our lives? Sometimes it takes intense research or vast amounts of money to create the next big thing; other times all that’s required is a clever twist—making something that already existed immensely more useful or aesthetically pleasing. Take the iPhone or Facebook, for example: they’ve both hit a resonant chord with the masses by improving upon a good thing (the cell phone & social networking).

Keep Trying. Things Will Happen.

My sister once explained that in her art class, she was instructed to visually represent an object (I think it was a chair) in 100 different ways. The medium did not matter. She said that the first 8 or 9 chairs turned out okay, but that the next 20 to 50 were boring and lifeless—just the same thing over and over again. She said that she grew frustrated and angry about the assignment and considered giving up, until she reached a point where she was forced to really think differently, and break out from her usual mold. After that, she finally started to come up with good, wild ideas. In the end, she created some fantastic works that she didn’t think she was capable of.

Drawing a chair a hundred ways turned out to be an incredibly empowering exercise that gave my sister the confidence and fortitude she needed to continue her career. She went on to become a successful Graphic Designer.

The lesson? When designing or thinking up something new, don’t just go with the first idea out of your head. You’ve surely not reached your potential.

Open the Mind.

I have found that there is much more available on the web than I had previously thought. Discounting things we do not understand is something that we tend to do to protect ourselves from an overwhelming flood of information, valid or not. As a result though, we will likely miss something invaluable. I find it easy to become complacent and only visit sites that I already know, but I’m always amazed that when I really start looking for new things; I find them everywhere. Try to allocate some time to simply looking around the web for something new; something might just spring up, and it might just be a gem. It’s probably already there.

Have you found a web site that you can’t live without? How did you become aware of it? What about it do you really love? Let us know. Leave a comment or if you tweet, follow us on Twitter to learn about new content, opinions and articles.

Design for tables

Tim Aidlin — Mon, 08 Feb 2010 23:34:21 GMT

Years ago, around the time of MIX06, I had a great conversation with a friend who was working on a design for the Microsoft Surface. He said he had to basically re-learn user interface design during the process, since Surface’s screen presented a totally new user experience: a horizontal interface that multiple users (and objects, for that matter) could approach from any direction — a far bigger challenge than a regular computer screen presents. In his office, he showed me a giant sheet of paper with arrows pointing inward from all directions. He said this reminded him just how different the Surface’s user experience was.

Now it’s about four years later, and Apple is poised to release the iPad, a quintessential “casual computing” device that has the potential to change the UI game for touch interfaces. If I’m not overstating the point, the iPad is likely to win where tablet computers (which have been commercially available for years) have failed: the design of its applications.

Just like the iPhone, the iPad will introduce significant, new design paradigms to an enthusiastic group of mobile software users. We can assume that software running on the iPad will be specifically designed for the iPad — not a Macbook or iMac. The software will also take fingers on the screen and the limited needs of a user looking for a very specific experience into account. Buttons will be big. Menus will flick and spin. We’ll pinch and spread. Eventually, the applications will evolve from just giant, modified iPhone apps.

While the iPad’s apps will advance from a mobile platform, current tablet PC apps often advance from the desktop experience. Tablet PCs are also full, robust computers when they might not necessarily have to be, and their user interfaces are designed for mouses (or touchpads at best). Fingers as input devices, simple mobile and social applications, geolocation, or the like are often overlooked. Of course there are exceptions, but still.

Digital designers have been designing for immobile screens that users can only interact with through artificial means, such as a mouse or pen, for too long. Now, however, we Windows developers should assume the users we’re designing for are internet-connected, mobile, and often a member of one or more social-networks. We can collect data and use open APIs to create connections. With the growing popularity of multi-touch enabled applications, our users can individually and collaboratively create like never before.

Additionally, as mobile devices, tablet PCs, gaming systems, and even television interfaces become more connected and available, the community will adopt new standards and metaphors. There is tremendous opportunity at this stage to absolutely re-imagine user interface and standard design patterns. Of course, we don’t have to throw everything out the window, but we *could* — and that’s very exciting.

As iPads, slates, and touch-screen-enabled mobile devices become more ubiquitous, I wonder if we’ll end up with many individual device-dependent interfaces, or if UI will begin adopting universal standards across multiple devices, just as the web coalesced around standards independent of browser, platform, or screen-size. Will platform/browser/screen user interface and user-experience standards fracture even more than they currently have? (See the HTML5 video debate, CSS3 browser-compatibility problem, or even standard forms, for example.) Or will user-interface and experience professionals develop a new vocabulary and metaphors that will span the current and next-generation methodologies of user-interaction?

There are some products — like the HP Touchsmart line of computers — that are building strong experiences, but this is just the beginning. And with the merging of the web, applications, and data in the cloud, it’s a very interesting time to be a designer or developer.

Are you using touch-enabled applications more these days? Do you develop them? What challenges have you faced migrating your skills? Have you seen something that’s changed the way you think about interaction? Drop us a note below, and be sure to follow us at @mixonline.

I Can Haz Data Visualization?

Thomas Lewis — Thu, 04 Feb 2010 16:24:59 GMT

Everybody loves good data visualization. The New York Times has been especially good at using data visualization to demonstrate the power of information visualization as a communication tool. We thought the topic was intriguing enough to create a lab about it.

As you may know, we have a sister conference called MIX where we will be hanging out at in March. We want one of you to be there with us (actually, we want all of you there). So we want to take our love of data visualization and our love of giving you something free to give you a chance to win a free ticket to MIX10. We also will be including our limited edition notebook (only 200 produced) to the winner.

What do I have to do to get a golden ticket Willy Wonka?

Simple, three steps.

Follow our Twitter account.
Create a brutally awesome data visualization of our content on MIX Online (writings, labs, about, our Tweets, etc.). It can created with whatever, displayed however you desire as long as it can be hosted on the web, so no visualizations made of marshmallows and pencils!
By Wednesday, February 10^th, 3pm Pacific time, tweet this: Hey @mixonline, I want a free ticket, check out my data visualization at (insert a link to your visualization here). #MIX10

We will then take the most brutally awesome one, do an Opinion post about it and why we thought it was so brutal (ummm, realize we are not “experts”, but are avid consumers, so we may be a little subjective). Then we will send you your free ticket to MIX10 and one of our amazing notebooks.

We probably won’t stop here, so you better follow our Twitter account for other fun ways we get you a golden ticket. Also, feel free to follow me for my crazy adventures at MIX10.

Ninja Coders and Despot Designers: Game Over

Joshua Allen — Mon, 01 Feb 2010 21:58:34 GMT

Our industry has just been changed forever. Many have predicted that this day would come, and it finally has -- design has irreversibly supplanted development as the center of gravity in software projects.

OK, so maybe that's a bit dramatic. The revolution has taken longer than a day, and will continue for some time. But I believe we can safely say that we're past the turning point. Design has won.

This is a topic that Nishant and I have discussed many times, but the "eureka!" moment for me happened when I was building a Web application to handle MIX Open Call voting. It was a simple application that needed only 4 or 5 page types and was only going to be in production for a week or two -- so it wasn't worth hassling a designer over. Since I did the design myself, I didn't create any comps and I decided to use the base CSS that comes with ASP.NET MVC. In other words, I sketched out the IA and wireframes on paper and iterated a few times before creating the markup.

Despite this severely truncated "design" process which involved no Photoshop or CSS work, the design phase took longer than coding and testing the application. I'll repeat: it took longer to do a simple IA and wireframes than it took to code the application. I was honestly surprised. My expectations had been violated. Coding the application shouldn't have been easier than creating the wireframes.

My code needed to implement data models from three different types of stores (XML, Cookies, and SQL Server). It also had to support search functionality and permalinks.

But it was simpler to implement. I'd like to say that it's because I'm such an awesome coder, but that wouldn't be true. It had nothing to do with my awesomeness. I believe that anyone who set out to build the voting application would have experienced the same thing.

Ninja Coders

Fred Brooks' influential book, "The Mythical Man Month" has left a concrete impression on our profession ever since it was published in 1975. In the book, Brooks makes the famous argument that development costs dwarf all other costs on a project, and that superstar developers are tremendously more productive than “average” developers. Therefore, the best way to control software cost is to hire superstar developers and get rid of the average developers. Brooks' insight has informed hiring practices at Microsoft and elsewhere and contributed to Zen-master Ninja Complexes among good developers.

However, things aren't so clear-cut today. Developer productivity has been improving by leaps and bounds every year. The tools and frameworks we use today seem like magic compared to what we used in the past. A developer using ASP.NET MVC and LINQ, or frameworks like RoR and Django, can crank out code that we wouldn't have even dared to try 10 years ago. And things are getting more reliable. When was the last time you had to debug a null reference exception or a performance issue caused by excessive use of the heap? We may all be ninja coders today, but it’s only because we have magic weapons.

By contrast, the design process is limited by human factors, especially in the early stages. The early design phase is about discovery and building shared context with your client or customer. This is the phase where you decide exactly what you want to build, so there is a lot of iteration and interpersonal communication involved. You could optimize this process by hiring UX folks who are expert hypnotists, but even this wouldn't be enough to outpace the productivity gains developer tools and frameworks are making.

A Lesson from History

I first began noticing cracks in Brooks' development thesis seven years ago, when I was working on the SQL Server team. At the time, the CLR was fairly new. We were in a unique position to compare native code versus managed code development, since we were simultaneously shipping XML APIs built entirely in C++, and XML APIs built entirely in managed CLR code. The functionality of both was similar, and used the same team of people.

In those days, most test teams were roughly the same size as the development team. But when it came time to allocate headcount for our managed code software, many of us were shocked when the test manager was asking for nearly twice as many people as the development manager. It violated our expectations. Was the test manager trying to build an empire? Was managed code so buggy that it needed extra testing? What was the deal?

It was just simple math. The developers could code up the functionality twice as fast as before, but all of the functionality still needed to be tested. You can't skimp on test coverage just because the developers are more efficient. More productive development means that you spend a larger percentage of your overall budget on test. Simple math, but it opened my eyes.

The Rise of Design

Of course, the past seven years haven't seen development teams being replaced entirely by testers. Instead, TDD has incorporated testing more directly into the development process, so developers spend more of their time testing. And testing has become more efficient.

It's pretty easy to see where this is going. If development and testing are taking less time, the design phase will eat a proportionally larger chunk of the overall budget. We can certainly imagine productivity improvements to some of the design tools, but design will always have a big bottleneck: clients and their psychology.

Yes, there are plenty of other reasons that design is more important now than ever, but simple math is sufficient to make the point.

What Does it Mean?

Does this mean that designers will soon outnumber developers and testers on projects? I don't think so. Brooks also demonstrated that you can't necessarily speed up software development by throwing more developers at a problem -- the same is true of designers. Think of the last project you worked on where you were the sole designer, or where you worked with a single designer. Do you think it would have been completed in a sixth of the time if you had put six designers on it? Ha!

This suggests that we will simply see smaller teams, with a small number of designers, working with a small number of testers and developers. Our challenge will be to scope projects to stay within the capabilities of a smaller team size, or else pay the price in diminishing returns.

Does this mean, instead, that designers will be corrupted by this newfound power and despotically wield control over the developers? Again, I think that’s the wrong way to look at it. The customer always has the ultimate power, and that power is mediated through the designer. This is how the world should be, and I’m sure the designers will still let us wear ninja costumes to work. Besides, Norbert Wiener, who published the tremendously influential book “Cybernetics” in 1948, showed that the most flexible component of any complex system will exert the most control over the entire system. Becoming more productive and adaptable is always a good thing. It's only when designers and developers work in harmony that the true potential of both is realized.

Your Turn

Does the “simple math” presented here agree with your own experiences? How do you see these trends playing out over the next seven years? Leave a comment below.

Kindle vs. iPad vs. Weimaraner

Nishant Kothary — Fri, 29 Jan 2010 19:39:41 GMT

As I suspected, my RSS reader was flooded with the inevitable "Kindle vs. iPad: Which one will triumph?" posts yesterday. I read a handful of posts from the usual suspects like CNET, Mashable, and even the NY Times, and I'm done. Journalism may be dead, but in the last 24 hours we've demonstrated that we're going to assassinate its apparent savior—blogging—using the same militaristic tactics.

It's a nice molotov cocktail: a couple shots of "Relativity" (a concept from Predictably Irrational's first chapter, which holds that humans are deeply evolutionarily wired such that they can't evaluate the world without making comparisons) and a couple shots of deliberate controversy, all topped off with a blatant attempt to squeeze juice out of ad revenue on web sites.

I'm sure there's a decent article or two out there about the Kindle vs. iPad question, but I'm just too cranky to sift through the shrapnel to find them at the moment.

But hey. If we're going to compare an iPad to a Kindle, I think it's completely fair to compare it with the most magical dog breed of all: the Weimaraner. Heck, let's do a quick analysis right now. Right here. It's so on.

The $64,000 question: Will the iPad obliterate adoption of this perfectly engineered breed of canine?

The Weimaraner—lovingly referred to as the "velcro-dog"—is a very trusty and dependable companion. Its UI is characterized by a sleek frame, covered with a fast-drying, microfiber-like, eco-friendly coat. Its gait is graceful and awe-inspiring, and it has communicative eyes that people get lost in. It responds not only to voice-commands, but can be easily trained to read hand gestures and even facial expressions! Basically, its technology is beyond our imagination. And, battery life? Psshtt! Unlimited. If it ever gets low (and that's a big IF), it takes nothing more than a 15 min nap to fully recharge.

But. Will this marvelous product, borne of decades of meticulous German engineering, survive Apple's magical new iPad? Let's analyze this.

First of all, the iPad's UI is just as sexy as the Weimaraner’s, if not more. Heck, the bookshelf spins around to reveal an entire store of books, for crying out loud! Can the Weimaraner do that? Didn't think so. And the iPad weighs a mere 1.5lbs. What about the Weimaraner? 80 lbs? Fatty! Can't carry that in my messenger bag, can I? I can change the orientation of the iPad and it adapts perfectly. But turn the Weimaraner upside-down and you get a perfectly useless, goofy-looking, bat-like creature with a mirror-shattering grin (see actual screenshot, below). Endearing, but it doesn't help me send email now, does it?

No email. No music. No apps. WTF, Weimaraner? And let's be honest: while I can't really cuddle its sleek, hard chasis, the iPad doesn't shed or have "that dog smell".

Having said that, the Weimaraner is definitely a perfect companion—something the iPad will never be. So, while some of us will buy iPads, let’s not write off the Weimaraner just yet.

Now that I think of it, maybe the iPad will actually encourage adoption of Weimaraners! Insert two shots of controversial speculation. (Thank you for visiting. Please deposit your comments below. [Mission accomplished])

*Rolling eyes for dramatic effect*

The point is this: You can't compare the Kindle and the iPad! Period. Yes, they share some features (3G, ebook reading experience, etc.). They are both "tablets". They both allow you to read ebooks. They let you listen to music.

But they are in entirely different categories.

The Kindle's attempt to be a multi-purpose everyday tablet—let’s be honest, the Kindle did attempt to be more than just a Trojan horse for eBooks despite what some pundits seem to forgivingly suggest—is obviously and entirely half-baked. Our failure to see this clearly is driven by our love for the trusty Amazon brand; it's the same reason that even well-respected UX professionals insist that Amazon sets the bar for e-commerce user experiences. Complete madness. Anyhow, I digress.

Bottom line: The iPad is a well thought-out end-to-end experience for consuming all types of media. The Kindle is a niche device optimized for reading certain types of books. They are different.

A fair comparison between the two companies and their core businesses, if there is in fact one, is between the iPad and Amazon.com itself. And there, one could argue that Apple has a position that grows stronger everyday despite its currently weaker areas, namely, pricing and selection of content. If history repeats itself, then prices for content will normalize and both companies will carry a similar repertoire eventually. This leaves only one differentiator: experience. But I better stop now for I’m starting to delve into punditry here.

I suppose I should cut the pundits some slack for putting iPads and Kindles into the same bucket (and by extension, myself for adding Weimaraners to the mix). After all, some of us will continue to buy Kindles, much like some of us will continue to seek the companionship of Weimaraners. But my hunch is that by Christmas many, many of us will buy an iPad despite its trivial and inconsequential shortcomings that the punditry and naysayers are currently echoing. Why? Because it respectably and pragmatically brings to life a category of devices that we've hungrily imagined for decades.

Thank you for visiting. Please deposit your comments below. ;-)

Transparency Yields Better Results

Tim Aidlin — Wed, 27 Jan 2010 22:23:44 GMT

At MIX Online, we’re able to be very open about our development process—we talk about new projects as we build them, for example, and try to get our work into users' hands as early as possible. We make concerted efforts to be transparent, because we find it makes our projects and products stronger in the end.

Of course, not all teams can be as open—but they can take baby steps in the right direction. Here are few suggestions for becoming more transparent about the development of your projects:

Blog and Use Social Networking

Set up a site and blog

It's so easy to register a domain and set up a site, there’s almost no excuse not to. Set up a site for your upcoming project, complete with details of what the world can expect when you launch. Allow users to leave comments and sign up for updates and user-testing. This is a great way to ensure that you have people ready to help test.

Twitter

Set up a Twitter account and follow people in your project's realm of influence. Tell people what you’re doing and ask them for feedback and ideas. You'll likely get input that will help you scope and generate interest for your project, even before you've released it.

Post images

Words are great, but sometimes images of wireframes, comps, explorations, etc. are better. Let people *see* what you’re doing. Even static images posted to Flickr can be helpful.

Engage your potential audience

Request detailed feedback and converse with people who provide it. Be sure to monitor comments on your blog and Twitter—and then be sure to respond. There’s nothing worse than taking time to write a thoughtful comment and have it just disappear into the ether.

Publish early and often

Get software into your users' hands as early as you can. This might mean getting a few people involved at first and widening the circle as the project progresses. Regardless, early brainstorming and testing will ensure that your project is actually useable. It’s easy for software creators to navigate a complicated system that they, themselves have created—not necessarily so for the actual user.

Publishing early also means doing shorter sprints and scoping your project down into manageable bits. This gives you more flexibility to add or remove features, change UX/UI, and make other adjustments as you receive real-world feedback.

Take advantage of systems like ClickOnce, which let you update your software as you roll out new features—so one buggy, unnecessary feature won't hold up a whole publication schedule. Save that buggy feature for later and update the software when the problem is solved.

Open-source

At Mix, we're able to post all our code to Codeplex and invite community involvement in our software development projects. Time and time again, we've found that releasing our projects to talented developers outside Microsoft and getting feedback from the community helps us develop a better product.

Of course, it’s hard to open-source every project, especially those that need monetization. If this is the case, you might be able to open-source *parts* of the project or open your code to a restricted set of developers and users.

Can’t do it all? Maybe you can do some …

If intellectual property is a concern, I realize it may be hard to follow the suggestions above. But for those who can afford to speak openly about their projects and who can get a small group of users to help test the application in the "real world," the project is destined to be better. We’ve all heard of “groupthink .” If N.A.S.A. can succumb to it at times, I think we can, too.

How do you get feedback on your projects? Do you do exhaustive user-testing before releasing a project to market, or trust your gut that you know you’ve made the right decisions? How does fear of losing your I.P. influence your decisions? Let us know by leaving a comment and be sure to follow us on Twitter @mixonline.

HTML5 Video: You'll Shoot Your Eye Out!

Joshua Allen — Mon, 25 Jan 2010 22:26:27 GMT

A few months ago, we shipped our cross-browser, cross-platform implementation of the HTML5 video tag, using the H.264 codec. In the past week, YouTube and Vimeo announced their support for HTML5 video tag, also using H.264. All good deeds, but unfortunately no good deed goes unpunished. Now we see certain bloggers clucking in disapproval, in essence saying, "H.264 video? You'll shoot your eye out!"

The most detailed entry of this genus is Chris Blizzard's post from yesterday. He starts out by raising the alarm (emphasis added):

The players from Google and Vimeo do present a pretty serious problem, though. Each of these require a proprietary H.264 codec to be able to view them. These codecs aren’t compatible with the royalty-free web standards that the rest of the web is built on. ... most people don’t understand that something very dangerous is taking place behind the scenes.

He then goes on to assert that the Web grew because of royalty-free, and suggests that permitting HTML5 video to play H.264 will compromise this historical position and lead to a slippery slope.

Let me start by saying that I have nothing against royalty-free codecs; we've even published content on this site in Theora (unfortunately nobody played the content, but that's a different story). But regardless of how idealistic you are about royalty-free codecs, the above line of reasoning has several problems.

Misleading Premises

For starters, it's very misleading to say "These codecs aren’t compatible with the royalty-free Web standards that the rest of the Web is built on" or, as Blizzard says elsewhere, "The Web exploded on royalty-free". The implication is that the existence of H.264 codecs is somehow corrupting and endangering the earlier "royalty-free" purity that made the Web grow so quickly.

This assertion is simply untrue. The Web grew from nothing to nearly a billion people, and never used a royalty-free video codec. Never ever. In fact, the existence of all of that proprietary video content is largely to credit for the popularity of the Web.

Again, royalty-free is fantastic, and may even be important for the next wave of growth on the Web. But let’s not mislead people about the role that royalty-free video played in the growth of the Web.

Slippery Slippery Slopes

Next, I think the danger is overstated. It's far too easy to invent "slippery slope" arguments to support any position, so such arguments should be used with caution. In the case of Ralphie's "Red Ryder carbine-action, two hundred shot Range Model air rifle with a compass in the stock and a thing which tells time", the warning of "You'll shoot your eye out!" may have been reasonable. But in the case of H.264 video, I think the "slippery slope" argument goes too far. Chris compares H.264 to the debacle with the GIF image format, but he appears to make the link largely for rhetorical purposes, and ignores the dissimilarities between the two situations.

The Web has depended on proprietary video formats for 15 years, and hasn't yet been held hostage; it’s not in anyone's best interest to try. Besides, the last time someone tried to hold the Web hostage, we routed around the situation pretty quickly. We all know how that movie ends, and nobody wants to watch it again.

Bottom line: The Web is now much bigger, with a far more competitive and diverse vendor ecosystem. The idea that someone would try holding it hostage now, let alone stand a chance of succeeding, seems ludicrous to me.

Lose the Battle to Lose the War

Finally, it's difficult for me to see how refusing to support H.264 in the player will help spread royalty-free content on the Web. Content providers seem perfectly capable of publishing content that uses proprietary codecs, and getting users to install plugins to play that content. I don't see how any browser vendor can stop this. So this discussion must be limited to codecs supported by the HTML5 video tag.

Apart from the fact that the ship has already sailed, it's difficult for me to imagine how we would change publisher behavior simply by crippling the HTML5 video tag. In exchange for dumping the H.264 codec, what would the content provider get for switching to the video tag? An HTML tag that’s one character shorter than the object tag? A video player that requires users to install a new web browser instead of a plugin? There seems to be a bit of hubris in the idea that we can control content publisher behavior in this way.

Indeed, if we really believed in such rhetoric, we would boycott media players such as iPods, because they support formats like MP3 and AAC. We can do without music for a few years, while we wait for someone to build a royalty-free replacement codec. After all, it's for the sake of the ecosystem!

There are many ways to encourage content providers to publish using royalty-free codecs. I'll even go so far as to predict that content providers will publish more content using royalty-free codecs in the future. But it won't be because the HTML5 video tag was deliberately crippled, or because people wrote "slippery slope" blog posts.

What’s So Great About Contrarians, Anyway?

Joshua Allen — Wed, 20 Jan 2010 18:49:55 GMT

I'll admit it: I'm a sucker for contrarians. It's great to have a bunch of knowledge, but it's always the stuff you don't know, the stuff that contradicts your common sense, that kills you. That’s what contrarians are great for—drawing out the "unknown unknowns" that wreak havoc on life.

Finding Black Swans

Unknown unknowns work like this: you're sitting there putting money in your 401k, thinking, "This capitalism thing is pretty swell," and then BAM! It's gone!

Nassim Nicholas Taleb calls these unknowns "Black Swans," because people used to think there was no such thing as a black swan—until the first black swan was found. You can bet that people took notice when the first black swan was discovered, because it overturned hundreds of years of common knowledge (and might have even posed a threat!).

Our brains are wired to pick out things that don't fit the pattern. Brainteasers that ask you to find one item that doesn't fit are much easier than puzzles that ask you to find a handful of related items, for example. It's like seeing the venomous snake in an otherwise soothing line of trees.

Linguists have even speculated that this is why we have accents and dialects. People in a village or town often help one another freely, knowing that the favors will be returned eventually. But when an outsider arrives asking for help, his accent will immediately mark him as a potential freeloader who is unlikely to return favors.

Silly Rabbit, Contrary's for Kids!

With our innate desire to spot the contrary, you can see why Sesame Street regularly played a song called "one of these things is not like the other ones" or its variant, "3 of these things." (It would have been great if the non-matching item always turned out to be poisonous or explosive or "stranger danger," but I suppose we can cut them some slack.)

It's common sense that counterintuitive blog posts get more page views. So, why am I even talking about such an obvious topic?

The truth is, I've been intending to talk about it ever since Paul Krugman published an article excoriating the SuperFreaknonomics authors for being (you guessed it) too contrarian. In it, Krugman argued that Levitt and Dubner had “fallen into the trap of counterintuitiveness…[trying to] distinguish themselves by shocking the bourgeoisie.” By attacking contrarians, he was mostly just pandering for pageviews, but people still took him seriously.

At that point, I decided to stick up for the status quo. What would the world be like if we silenced the contrarians? A lot less interesting and a lot more dangerous, if you ask me!

Killing a Black Swan

That said, maybe there’s a right way to be contra-contrarian. Check out how Larry David does it. Black swans can get you in big trouble if you don't see them coming; Larry proves you can get into bigger trouble if you see one coming and accidentally kill it.

So what do you think? Should we silence the contrarians among us? Or even better, have you seen any really good counterintuitive news lately?

Vendor-led Conferences: Marketing in Sheep’s Clothing?

Thomas Lewis — Mon, 18 Jan 2010 19:46:46 GMT

Lately, I’ve been lurking around the Twitterverse, listening in on some conversations about conferences.

To my surprise, there seems to be a general mistrust about vendor-led conferences such as MIX, which tend to elicit statements like this:

Why should I pay $X to hear a sales pitch?
They are only telling their spin.
The sessions are not based in any reality I live in.
M$FT sux and their conferencez r full o fail.

I can understand why people try to avoid dog and pony shows for products—but some conferences are more than just dog and pony shows. I believe MIX10 is one such conference.

I have been part of the MIX Conference (Mix Online’s sister event) since its inception in 2006. Before we launched the conference, we spent a lot of time internally convincing Microsoft that this conference should be different than anything we’d done before.

We came up with philosophy and brand elements for the conference that still exist today:

Open

The first thing we did was to open up the conference to non-Microsoft speakers, including our competitors. Our idea was to provide a way for attendees to see things from different perspectives—the web is made up of many different people and technologies, after all. This year we introduced Open Call, which lets our audience choose a handful of the sessions themselves.

Unexpected

Each year, we try to do something unexpected. It might be a DJ or Johnny Cash-inspired music guest, or having our executive speakers hang out and answer questions in a common area. Last year we had a keynoter who talked about how design helps save lives. Doing something unexpected every year is probably one of my favorite brand elements of the conference (just wait until this year’s event).

Innovative

When I say innovative, I’m not talking about invention; I’m talking about “extracting value from the creative understanding of what is already known.” (Thanks Bill Buxton!) One of the innovative things we’ve always done is to make all session content, keynotes, etc. freely available after the event. People were afraid that free content would cannibalize our attendance at first, but it turned out to be a lot like a football game—could you just stay home and watch the game? Of course, but it’s not the same as being there.

Conversational

From giving attendees opportunities to interact closely with speakers and keynoters, to having Guy Kawasaki interview Steve Ballmer—we’ve always tried to keep things conversational (and yes, Guy Kawasaki had his Mac with him on stage). I’m astounded by how much interaction I have with attendees via Twitter, too. I get everything from site feedback to info about meetups with some that I’d only recognize from their avatars.

Practical

Finally, we try to make sure conference content is practical, approachable and appropriate for developers AND designers. We focus the content on how you can “do” things, rather than just an API crawl. And it’s not about product pitches; it’s about speakers outside of Microsoft discussing things from web site redesign to web content.

Conclusion

So I think that vendor conferences can be more than just marketing events—as long as vendors take the time to figure out what makes their conference unique. This is why I look forward to working on the MIX conference every year.

What do you think vendors should do to make their conferences more beneficial to attendees? Do you think the MIX conference embodies the brand elements I’ve discussed or do you think we’re falling below the bar? Leave a comment with your opinion. Hope to see you at MIX10.

Also, you can follow my crazy adventures at MIX10 on Twitter and make sure you follow MIX Online too.

2009: The Year the Web Coalesced?

Hans Hugli — Sun, 17 Jan 2010 01:57:37 GMT

First off, Happy New Year!

Every January, I try to take inventory and reflect on what’s happened over the course of the past year. The new year is the time to take a look at the good, bad and ugly—to examine what needs to change and what to continue doing.

The web has its flaws and shortcomings, and it’s easy to rant and mumble about all that’s wrong. But here, I’m going resist the urge to scrutinize and instead reflect on all the good things the webosphere has brought us in the recent past.

While great web technologies have been around for many years, a growing number of web sites and web developers started to realize the real potential of the web in this past year. They built robust, practical, intelligent applications that are useful across browsers. I saw far fewer sites using gratuitous tricks to get users’ attention, and far more integrated and highly designed user experiences.

I also recall a time when the services I needed to build applications that accessed and tied together disparate information were simply not available. Today this is no longer the norm.

Us + Them

While I know that web sites are still fiercely competitive, last year I saw them learning to work together amicably and respecting that customers want to interact with other web sites—even potentially competitive ones. They’re not locking site data away in a database somewhere as often happens in product price comparisons. This burgeoning “shopping mall effect” helps everyone, and I find that fantastic.

What Was Good?

Social Media Sites – While there is disenchantment with Social Media sites among some influencers, the numbers don’t really reflect that (yet). I’ve found at least a dozen lost friends on Facebook that I thought I’d never hear from again. I have access and contribute to a greater consciousness on sites like Twitter and Digg and Delicious. All these sites expose services that allow web developers to consume, combine, contribute and share information, making social media far more useful.

Browsers – Technologies that enable rich experiences in our browsers have been available for a while, but they’ve become more popular with time. It’s wonderful to see web developers consistently using technologies such as AJAX and jQuery + backend services to build rich, beautiful and productive cross-browser user experiences. In my opinion, 2009 was the year that the greater web realized it was feasible to use web clients as powerful applications.

News & Information – Blogs, Microblogs, RSS Feeds and my favorite, Wikipedia, have replaced paper publications as my primary source for news and information. RSS readers and tools such as FriendFeed aggregate information and let us efficiently sift through large amounts of information. New tools that make it easier to get to content that matters are cropping up all the time. Without RSS feeds, web services, and an overriding ethos of sharing information on the web, none of this would be possible.

Web Services (XML/JSON) – REST services have become the key to accessing those once impenetrable silos of information. I was involved with web services very early on, but I never anticipated how popular they would become (they were a hard sell early on). MySpace recently announced new developer API's, for instance, which is very exciting. Web services are the magic ingredient in what advanced web sites are doing today and will enhance their capabilities more with time.

The Year the Web Coalesced

Overall, I think the web really started to come together in 2009. Clear lines were drawn between useful, robust, user-focused, and sharing web apps and the self-serving, archaic, hoarding ones of the past. These changes benefit the entire ecosystem: businesses, web developers and end users alike. It seems that a new API is being launched every week and that each one opens up vast new possibilities—especially when combined in new and unexpected ways. It’ll be very exciting to see what 2010 brings us!

What Great Things Did You Notice?!

Have you noticed a difference in the way sites share information recently? What has the web brought you that you never thought it could or would? What did you see on the web in the last year that surprised or excited you? Leave a comment or if you tweet, follow us on Twitter to learn about new content, opinions and articles.

Government 2.0: Activist Paradise, or Treading on the Poor?

Joshua Allen — Mon, 11 Jan 2010 19:21:36 GMT

I love stories like this: "Craigslist founder uses iPhone to snap a picture of a crowded streetcar, sends it to city hall, and the problem gets fixed." It's so heartwarming and optimistic.

In today's connected, mobile society, we're going to see more and more stories about citizens taking advantage of technology to participate in local government, with a bit of "wisdom of the crowds", "social networking", and other favorite topics sprinkled in.

This growing crescendo of optimism about a “technology-enabled citizenry” and the idea that “the people cry out, and the mighty government/corporation hears their groans and gives them relief” has me feeling uneasy. I don't think it's as innocuous as people want to believe, and I see a couple problems down the road.

All the stories tend to reassure you that you need only to send a 140-character rant into the ether of Twitter, and the mighty Comcast (Frank, aka @comcastcares) will hear your plea and make things right. You need only send a quick text message about a pothole, and the mighty city hall will hear your pleas. The Internet becomes a magic conduit who answers all your prayers. It's a trope as old as time, and it's what people want to hear.

No doubt, there are valid reasons for these stories’ popularity. Local governments are rapidly adopting geolocation and social networking technologies, after all. At An Event Apart and Web Directions last year, I was surprised to learn how many of the attendees worked for local government agencies, and how sophisticated their use of these technologies is.

The Cost of Instant Gratification

For starters, the stories pander to people's twin desires to both play the hero and be as lazy as possible. Here in Seattle, for example, the carpool lanes even used to be plastered with the phone number 764-HERO, which motorists could call to report carpool cheats. The implication? Be a hero by making a call to tattle on your neighbors. The number is now defunct, but the idea lives on in many of these "Government 2.0" sites.

The true costs are hidden from the citizens. It costs a citizen just a few seconds to report the issue, but there is a big cost on the back end to monitor, filter, and respond to the citizen input.

Corporations are investing heavily in tools that allow them to collect customer feedback and passively monitor quality, as well as new ways to "listen" on channels like Twitter. After all, if you’re out to make a profit, it's great to make feedback frictionless for customers. We played on this idea with the recent "Windows 7 Was my Idea" campaign. Our television ads show various "real world" folks claiming that someone from the Windows team heard their feature suggestion and implemented it in Windows 7. The ads are tongue-in-cheek, but they hint at how the Windows team processed an unprecedented amount of customer feedback collected over many different feedback channels to design the product.

In contrast to corporations, though, local government is different. Governments are non-profit monopolies, so it's silly for them to ape competitive corporate tactics. More importantly, government is supposed to be "for the people, and by the people." If we train the citizenry to feel that the cost of government participation is free and borne magically on the back end, we’re establishing the wrong precedent. Sending an iPhone snapshot is not participating – it's copping out. We need citizens who will do the legwork to organize their neighbors, get some shovels, and fill in the potholes. Governance "by the people" is about rolling up your sleeves and interacting with your neighbors, not playing a video game on your cell phone.

Unequal Access

More disturbing, though, is the precedent this sets in establishing privileged access to government for elites. Are we really comfortable with a system that gives privileged treatment to people who can afford data plans and GPS-enabled devices? Have we become so isolated from real people, that we gullibly accept that Craig Newmark represents the common man?

Once again, it’s fruitless to look to for-profit corporate practices for guidance here. Comcast monitors Twitter because they know that elite Twitter users represent a higher portion of profits than non-users. Playing favorites with rich folks is part and parcel of being a for-profit corporation. It has no place in government.

A favorite argument about the drawbacks of a non-profit government is to talk about how inefficient the US Postal Service is. Companies like Federal Express and UPS, it is claimed, prove that free-market competition is more efficient than non-profit government services. But this only serves to underscore my argument.

The Postal Service was created to provide equal access for all citizens, regardless of whether you lived on a remote farm or in a plush penthouse in the city. It was not optimized for profit. We citizens considered it unacceptable to charge poor, rural citizens more for service, even if it was more expensive to deliver that service. This foresight has paid off, as states like Washington switch to Vote By Mail. At first glance, Vote By Mail is another instance of "instant gratification", but unlike Craig Newmark's iPhone, it’s based squarely on a foundation of equal access. Everyone has equal access to the mail system.

Likewise, the government has always required that access to essential utilities like electricity and telephone service be equally extended. But in recent decades, we've seen an erosion of equal access, particularly with respect to telecommunication services. In the case of our data plans, the inequality is downright scandalous. People with unlimited data plans can pay less than 1/100th of the price per megabyte that the majority of less well-to-do subscribers pay. It seems unacceptable that the average person would have to pay 100 times more than I do, simply to report a pothole.

As we get swept up in our enthusiasm for the "Government 2.0" initiatives and play the hero in our little echo chambers, I hope we don't lose sight of these critical characteristics of good governance: meaningful citizen participation, and universal access.

Dear Twitter

Nishant Kothary — Fri, 08 Jan 2010 20:37:12 GMT

Dear Twitter,

First off, I'm sorry I'm writing you a letter and not talking to you directly. It's just, I express myself better in writing (in no small thanks to you, of course). Where do I begin?

Over the holidays, I thought a lot about us. Where our relationship is headed, what we've been doing these past few years, all that. I guess I just totally “unplugged" on vacation and it felt really, really good.

To be honest, I feel like it's just not working out between us.

We both know I’ve said these words before. And we also know I keep coming back. I mean, you’re so good to me. You let me be myself: brutally honest or wicked hilarious. You make me feel popular, like thousands of people hang on my every word. When I’m bored, sad or lonely, you’re just… there. Part of me will always love you, Twitter.

Talking to my therapist over Christmas, though, I had this huge realization: we're completely emotionally fused. I see codependency around the corner. It's not just your fault—it's mine too.

You know I'm not as differentiated as I should be. I find my sense of self through what others think about me. My therapist calls this “other-validation”. He says it’s not my fault; I just developed that way.

And you don't make it easy. In fact, you encourage seeking validation from others. You even reward it! Witty one-liners, passive aggression, hate mongering, emphatic endorsements, and showing off get me the sweet gift of a RT, an @ reply, # tags and more followers.

It’s a vicious and regressive cycle, Twitter! I've stopped using my neocortex. My reptilian brain has taken over and I feel like one of Pavlov’s dogs, making snap judgments and salivating all over the place. Now I'm even obsessing over you in my downtime, like when I run.

The running thing is the last straw. I'm getting scared. So let’s nip this in the bud.

Starting now, I’m going to do all those healthy things that turn me into mammal whose neocortical brain is in charge. Things like reading. Hanging out with my wife. And friends. Playing my guitar. Listening to music. Indulging my Netflix habit. Having conversations without character limits.

Yes, I know what you’re going to say—that I already do all these things. And you’re right. I do, kinda. But going forward, I think it’s best that you don’t join me when I do them. Please don’t make yourself a part of those experiences without my conscious permission.

But let’s not get carried away. This is not the end. I’ll still come hang out every now and then. I value your spirit, and what you’ve tried to do for me, and some of things you brought to my life. I’ve met wonderful people because of you. You’ve created opportunities for me. Our relationship has helped me understand myself better and inspired a new and healthy level of introspection.

Will you be alright? After all, you do have Ashton, Oprah, Seacrest, Britney and Shaq. Even Barack.

Yes, I think you’ll be fine.

#Friends?

So Long, Farewell, Auf Wiedersehen, Goodbye,
A Recovering Twitterer

p.s. feel free to share this with your other friends, Twitter. Maybe they’ve gone through the same emotions? Maybe they’ve dealt with it in a different way? I’d love to hear their thoughts below.
p.p.s Feel free to follow us on... Twitter :-)

The Vanity of Vanity URLs

Karsten Januszewski — Wed, 06 Jan 2010 17:59:34 GMT

Wikipedia defines vanity URLs as follows:

"a URL or domain name, created to point to something to which it is related and indicated in the name of the URL. In many cases this is done by a company to point to a specific product or advertising campaign microsite. In theory, vanity URLs are creatively linked to something, making them easier to remember than a more random link."

The article goes on to point out one of the most common implementations of vanity URLs: social networking sites, where your username becomes the vanity URL.

Social Media and Vanity URLs

These days, a social networking site that doesn’t support Vanity URLs is considered out of the loop. Can you imagine your Twitter URL being http://twitter.com?userid=2035? Um, no.

You have to give props to MySpace on the vanity URL front: they were the vanguard in this arena and really established the idea before anyone else.

Facebook is an interesting one, because unlike the other top social networking sites (MySpace, Twitter, YouTube), creating a Facebook profile doesn’t generate a vanity URL by default; you have to claim it.

Taking Control of Your Brand

How aware are you of the various social networking sites where your vanity URL appears, whether it's your company’s brand or perhaps just your own “personal” brand? Have you done a proper land grab on Facebook, MySpace, YouTube, and Twitter?

If not, it turns out that Incarnate, a new MIX Online lab, allows you to quickly see how pervasive and consistent your username is across these sites. Incarnate uses microformats to pull avatars from profile pages based on usernames that are keyed off of vanity URLs. So you can research your brand to make sure you’ve claimed the available real estate and see who's camping out with your username if you haven't. In watching people use Incarnate, it is interesting to see the reaction of people as they type in their handle and discover someone else’s profile picture appearing.

An entrepreneurial person could use Incarnate to research and claim vanity URLs that haven’t been taken (just like in the days of URL land grabs), and even sell them. It's not unheard of for a company to pay to acquire a vanity URL on a social networking site. Never let it be said that MIX Online labs don’t offer money making opportunities!

What are your thoughts on vanity URLs? Do you claim them for yourself or for your company? Would you pay to get a vanity URL that someone else has camped out on? How important are vanity URLs to a brand?

MIX Online Brings Holiday Gifts Early

Thomas Lewis — Tue, 15 Dec 2009 05:00:00 GMT

How it all began

MIX Online started as a companion to our yearly, Vegas-based MIX conference for designers and developers. A little over a year ago, we decided to expand from a video and text blog to a community site with a voice. Instead of having a traditional Microsoft site (product-driven, editorial, visual, etc.), we built a site that we would want to visit.

First, we added articles from influential, interesting web professionals speaking in their own voice about relevant, current scenarios. For the most part, we focused these articles on scenarios or stories, rather than technology.

Second, we went beyond talking about the web, to actually building stuff. We started to create freely downloadable, open source, and immediately useable prototypes based on scenarios like Microformats, data visualization, and web standards. These are now tools, services, and clients you can use in your own projects.

Third, we began writing Opinions on everything from Twitter and Facebook to HTML5. These are fun to write and give us a chance to hear your thoughts. Sometimes we get it right and sometimes we get it wrong, but the interaction with you is what we really like.

Enough with the history, bring on the gifts

Today we are announcing three new things:

MIX Online Redesign – In typical designer fashion, we have redesigned the site—but it wasn’t just designer folly. We took feedback from you on readability, updated the IA to reflect our commitment to writings, made our event interactions more prominent, and finally said goodbye to our weird uncle, IE6. Nishant has written up a very eloquent summary of all the changes. I highly recommend you check it out.
Incarnate Lab – Our new lab is called Incarnate, a service that lets you choose your avatar (e.g. the picture you use when you add a comment to a blog, etc.) from a variety of publically available social sources such as XBOX, YouTube, Twitter, and others by simply typing in your e-mail or handle.
MIX10K Contest – As most web developers and designers know, projects are full of constraints. So we came up with a contest to see how creative folks could get with a 10-kilobyte Silverlight application. We’re now kicking off the MIX10K contest for this year’s conference. But this time, we’re including Web Standards-based and Gestalt-based apps in addition to Silverlight-based apps. We’re also planning to make the contest year-round and based on new technologies—from Microsoft, outside Microsoft (like jQuery), and MIX Online labs.

Moving ahead

The last 3 months have been very busy for us, as we’ve worked to bring you a community you think is brutally awesome. We encourage you to write articles or work on our open-sourced labs. Drop us a line if you’re interested. And if you like, follow our Twitter account. More importantly, leave us a comment below. We hope to see you at the MIX conference.

Say Hello to MIX Online 2.0

Nishant Kothary — Tue, 15 Dec 2009 04:59:00 GMT

As an industry, the Web is still struggling to find a comfortable place for design. Those who’ve made it a deliberate part of the web development process are few and far apart.

Unlike any other medium, the Web is actually alive. It's a representation of our collective consciousness—some of it frozen in time, some in real-time, and some ahead of its time. A few enlightened individuals daresay that the Web is actually synonymous with culture. Is it any surprise that we’re finding it difficult to design for it, much less articulate its value and tie it back to the bottom-line?

Uncertainty is always nearby in any field that's in its infancy. While this Web thing raises our eyebrows from time to time, one certainty that defies all collective uncertainties is that the Web is the future, and good design is destined to be at the center of that future. We can’t prove it, but those of us who’re a part of it sure can feel it.

So, that’s what we’re doing today. We’re indulging our faith in that feeling. A little over a year after turning the MIX Online page to its next chapter and writing about it in great detail, we’ve redesigned our site again to reflect our brand, our business and our values. We’re ecstatic to introduce you to the future of our community.

A Quick Refresher

Some of you may remember when we announced we were going to embark on a redesign, a few months ago. The old design suffered from a few cosmetic dysfunctions, most notably color contrast issues and readability problems. But those problems are easily fixed through CSS, without a major overhaul.

Information architecture (IA), on the other hand—the kind of information represented across the site and how it is laid out—isn’t easily changed. IA on the Web is synonymous with the business model, especially when you’re in the content business. Changing business models overnight isn’t easy or even possible. Over the last year, we realized that our content is as important to our business as our labs, but the site we released last year wasn’t designed with that in mind. Among other things, this redesign brings our writings—expert articles, heartfelt opinions and our new lab notes—into the foreground. We figured that while we were in there, we'd just fix all the other little problems, too.

The 5-minute Tour

So, what’s new?

Information Architecture

The IA now reflects our business priorities, without compromising customer experience. Articles and Opinions are now all neatly arranged on the Writings bookshelf. We’ve also added a new column called Lab Notes, to let our designers and developers disseminate technical experiences and shenanigans. The writings section is now a one-stop shop for content.

We also added an Events section to the site. This should end the confusion about whether MIX is an event or a community. It’s both. In the events section, you’ll find our calendar of events and virtual events (like our MIX 10K Challenges) that we run year-round.

We've also improved layouts for the home and about sections—they prioritize the right information and are more usable.

Visual Design

While you can still sense the same colorful and bold spirit of 1.0, the visual design of the site has changed drastically. I like to think of it as a more mature, grown-up version of the dark, edgy MIX Online that we introduced last year. MIX Online now looks on the outside as it feels on the inside.

Thanks to your great feedback, we were able to refine the typography to work on most platforms—we went with Georgia because it was the safest bet and most malleable across platforms.

The light, textured background puts the focus on content, and makes reading for long periods of time easy. Copy, which is deeply integrated into the layout, is treated as a visual design element that gives the site a "magazine-y" feeling.

The graphic design style is modern, yet classic.

Interaction Design

We kissed the interaction design: simple hover states, large hotspots, SEO-friendly URLs, sensible use of page refreshes vs. AJAX, progressive enhancement with jQuery, and other goodness that gives you the warm fuzzy feeling of being at home on the Web.

The site gives you an occasional nudge when needed, but mostly gets out of your way. Don’t take our word for it, though. Click around and decide for yourself. A good place to start is the finger-licking, preloaded, self-scrolling listing of writings.

Code & Performance

The front-end code is marked up from scratch, and a delight to maintain. The CSS is lean, at 500-ish lines for the entire site. The markup is pragmatic, semantic, and forward compatible with an HTML5 migration—the id names match the new structural tags. We’ve also rewritten the logic for various pages, which should make it easier to find content.

We’re still running our trusty ol’ version of Oxite in a highly customized form.

And then some

Apart from the above highlights, there are a few other features you should check out:

Incarnate

We’re releasing Incarnate, a unified avatar fetching service, today. Think Gravatar, but for a bunch of services like Facebook, Twitter and so on. Of course, our comment forms have been incarnated. Try one out.

Goodbye IE6

Yep, we’re no longer going to guarantee parity for IE6 users. As much as we’d like to satiate everyone, the cost of supporting our tiny IE6 population is simply too high.

Most features will still work in IE6, but if you see a paragraph floating in space, it might be time to upgrade. Contact us and we’ll even help you do it.

RSS Galore

If you like to consume your content on an RSS reader, you’ll find that we’ve enabled a wide permutation of feeds. But we recommend the master feed.

You say Goodbye, I say Hello

There’s always much to be learned from an honestly articulated case study, and that’s what we plan on doing: the creative team that worked on MIX Online 2.0 will be contributing articles explaining the process they used at a later date.

But to quickly summarize: Matt, Tiff, Evan and I used a unique process that balanced collaboration and feedback with subject-matter expertise to ensure that the redesign project never fell apart.

It would be irrational for us to think that the site is now perfect—that we’re done. Design—especially software design—is rarely ever done. Our design evolution will continue. And for that, we’re extremely excited, as it indicates that we’ve hit a major milestone.

So, in closing, thank you. For being open to and participating in this change, for being a part of the MIX Online community, and for contributing to it. Bear with us as we iron out the inevitable kinks introduced by such a major redesign (we encourage bug report emails).

Happy holidays and see you in 2010!

Credit Roll

This redesign was the result of an incredible team effort, and I had the pleasure of working with some of the most talented and smartest folks I’ve known in my career. Apart from the MIX Online team, we had the support of a very strong virtual team:

Matt Brown from ThingsThatAreBrown is the graphical genius behind the front-end. He took the wireframes and turned them into a design that’s a pleasure to look at and interact with. We’ve invited Matt to share his secrets at MIX10. Be sure to check out his session.
Tiffani Jones from Second and Park has been quietly working as the MIX Online editor for a few months now, and is behind the magical copywriting across the site. She has the rare and uncanny talent of being able to trick users into reading and understanding your business through meticulously designed strings of characters. She’ll be presenting at MIX10, too.
Evan Sharp from HeaderFooter put on his front-end code ninja hat for us. He took Matt’s comps, sliced them up, and turned them into some of the best and most accurate HTML/CSS templates I’ve ever seen. I highly recommend right-click > view source. Best. Learning. Tool. Ever.
Big thanks to Michael Duggan, a typographer on the Microsoft team who is responsible for introducing Verdana, Georgia and other fonts to the world, for his insightful advice during our typography design phase. A cognitive psychologist on his team team, Kevin Larson, will be presenting a fascinating session at MIX10.
Hans Hugli, Joshua Allen & Karsten Januszewski did most of the heavy back-end lifting. Together, we were able to take the site from front-end to back-end in a record 3 weeks!

Pictures or it Didn't Happen

Joshua Allen — Wed, 09 Dec 2009 04:59:23 GMT

You've probably seen this meme on Twitter or Facebook. Your friend posts a juicy status message like, "I just saw Tiger Woods flirting with Richard Simmons at LAX!", and someone quickly replies, "Pictures, or it didn't happen!". I love this meme, because it functions on multiple levels, and has a sort of ironic postmodern twist.

Allow me to explain: All my life, I've been fascinated with the concept of photography. We humans, as a species, haven't had photographs for much more than 100 years—which is a drop in the bucket, evolutionarily speaking. Human nature has co-evolved with story and narrative, but the snapshot is completely foreign to our endowed nature.

In fact, the sort of snapshot we're talking about here has been with us for less than 20 years! Not long enough for human culture to adapt, let alone human nature. Twenty years ago, many people had cameras, but 35mm film was expensive and slow to develop. Today, digital cameras allow us to take as many snapshots as we like, as often as we like. Kids today grow up posing for cameras more frequently than any other generation of humanity ever did. This could have all sorts of interesting consequences.

For example, we know from research in mirror neurons that people don't smile because they feel happy; they feel happy because they smile. The neurological process of activating the muscles to smile is what makes us feel happy, an evolutionary adaptation tied closely to our capacity for mimicry and empathy. When you condition a child through thousands of repetitions from a very young age to "smile for the camera", you're conditioning a new happiness pathway that is very different from our innate pathways.

More than the potential behavioral conditioning, though, we learn to associate our personal identity with the collection of snapshots that capture our poses. Is it any wonder that the generation who grew up posing for snapshots is so comfortable projecting a personal identity in short status messages on Twitter and Facebook? There was something numinously prescient in the savage's fear that the camera would steal his soul.

Long before we had the snapshot, Shakespeare observed that "All the world's a stage, And all the men and women merely players." And Stanislavski's adaptations of this insight continue to enrich both psychology and theater to this day. But it's important to remember that both were talking about a performance within the context of a larger narrative or story. It is only in the digital age that the "performance" has become the "pose".

This is what I find so deliciously ironic about the "pictures or it didn't happen" meme. When you're admonishing someone to provide snapshot documentation for a salacious or dramatic twitter post, you're doing two things at once: You're affirming that twitter posts should be authentic, and not just exaggerated titillating performances for an audience; and you're simultaneously (and unabashedly) asking for some additional photographic documentation to add to your titillation. The irony of the latter point is obvious, but it's the former that I find most intriguing.

Think about it. When you're composing a Twitter or Facebook status message, you're already doing it for an audience. And when your primary motivation is for an audience, how "authentic" can it be? You're already posing or performing, by definition. Even if Tiger's infatuation with Richard Simmons is totally spontaneous (and, if you believe in fairy tales, intended to be kept secret), your decision to tweet the fact is certainly calculated with an audience in mind. What sense does it make to demand authenticity in this situation? When hearing about a performance of Shakespeare's "Midsummer Night's Dream", wherein Puck entraps a mortal in an embarrassing romantic entanglement, does anyone say, "Pictures, or it didn't happen!"? Of course not! It's a performance, for heaven's sake, so anyone demanding proof of authenticity would be considered an oddball indeed. Let's face it: Twitter isn’y journalism, and you're not tweeting about Tiger to make the world a better place.

This is exactly why the meme in question is so funny and appropriate. It perfectly encapsulates the paradox of the Web. The Web was born during the rise of postmodernism, lauded by idealists and futurists who saw its potential to transform human society. We wrote missives about how the "semiotics of hypertext" would empower us to deconstruct, disintermediate and discombobulate the centers of power and lead to a democratization of information. We wanted to believe that we were making the world a better place, and religiously affirmed that bloggers would have more integrity than old school journalists. Dan Rather might fabricate stories, but the blogosphere would exude integrity simply by virtue of being on the Web.

Such idealistic screeds were typically penned while listening to pirated music (unabashedly) from ftp.funet.fi, and an uncomfortable sense of hypocrisy was never far away. Every now and then, a courageous soul would break the illusion and say something like, "Let's face it, we're not changing the world. We're [helping people broadcast titillating snapshots]". We could always secretly appreciate this brutal honestly, but it wasn't the sort of "journalistic integrity" we imagined when we imagined that the Web would change everything.

Like the Web itself, the genius of "pictures or it didn't happen" is in the simultaneous embodiment of two contradictory motives. For the idealistic reader, it affirms the idea that Twitter is about authentic voices, “disintermediating the power dynamic of the interpretive middleman”. For the more cynical reader, it's a request for salacious snapshots to entertain our baser appetites. If you can hold to both of these without having your brain explode, I daresay you're starting to grasp what this whole Web thing is all about.

Gestalt Grows Up

Joshua Allen — Fri, 20 Nov 2009 19:34:06 GMT

Last week, we discussed the fact that Microsoft invests heavily in both HTML5 and Silverlight, two technologies that other companies would have you believe are mortally opposed. Our commitment to both was underscored this week by our announcements about IE9 and Silverlight 4.

When we launched Gestalt beta less than 4 months ago, our goal was to demonstrate a really simple idea: that a proprietary plugin like Silverlight complements and advances the standards-based web. With today’s launch of Gestalt 1.0 and the first few widgets in the Gestalt Widgets Pack, I’d like to drill deeper into this underlying philosophy of Gestalt.

Gestalt: More than the Sum of the Parts

The word “gestalt” is a German word that roughly means “the whole is more than the sum of the parts”. The web, being a combination of lowest common denominator web standards (whether “open”, “de facto” or “de jure”) and speculative proprietary extensions whose backers hope will one day attain “web standard” status, has always been a “gestalt” of sorts.

As new ideas are tested out in the world of proprietary extensions, some will graduate and be implemented by a majority of browser vendors and/or standardized as part of a W3C specification. The ubiquitous browser search box, 2d drawing APIs, and vector graphics, for example, all proved themselves as part of vendor-specific browser plugins before wending their way toward standardization.

Besides acting as a proving grounds for new concepts, proprietary plugins can work with, rather than against the open web in a few other ways.

The Friendly Trojan Horse

It takes awhile for all browser vendors to implement a new open specification. But we can often accelerate the process by building implementations of open specifications on top of proprietary plugins that already run in all browsers. In this case, we use the proprietary plugin as a “friendly Trojan Horse” – a stop-gap implementation until all browsers implement the functionality.

A perfect example of this strategy is the way that Gestalt enables Ruby and Python in web browsers. Both languages are open source and open standards, and other browser vendors have explored integration. But browser vendors have not prioritized this work, so Gestalt’s solution provides a cross-browser stop-gap.

This strategy has a long history on the web. Brad Neuberg used Flash to bootstrap Dojo’s offline functionality (later part of Google Gears), and more recently to bootstrap SVG atop Flash. Perhaps the first widespread example was IEFrame, a plugin for Firefox that enabled enterprise Firefox users to run applications built on IE’s XML+XSLT standards support. If you look hard enough, you can usually find implementations of any prospective web standard built on either Silverlight or Flash.

Included in this category are our sample video and audio widgets, which come with the Gestalt widgets pack. By adding a <script> tag to the top of your HTML file, you can automatically enable use of HTML5-compatible video and audio tag syntax:

<html>  
  <head>    
    <script type="text/javascript" 
      src="/dlr/dlr.js"></script>    
    <script type="text/javascript" 
      src="/dlr/dlrmedia.js"></script>  
  </head>  
  <body>    
    <audio autoplay="false">
      <source src="foo.mp3" 
        type="audio/mp3"></source>
    </audio>  
  </body>
</html>

Our implementation is by no means the only way to get HTML5 video and audio in Internet Explorer and other browsers. But we had fun exploring the idea of an interim implementation on Gestalt. Our video and audio players are implemented in Python (with an optional Ruby implementation available); you can skin them by adding a skin=”skin.xaml” attribute. We support the same video and audio codecs that Silverlight does. Note that it would be relatively trivial to add support for Flash video and audio as well; but that was not a priority for us.

You can learn more about these widgets here, or download the source for yourself.

Progressive Enhancement

Enabling progressive enhancement is another way that plugins can contribute to the Web’s “gestalt”.

The functionality available in plugins will always be a superset of the functionality provided by default in the browsers. When this functionality is purely additive, and not meant as a stop-gap for existing standards, it’s best to use it such that the page can still be used without the plugin, but “lights up” when the plugin is available.

This, too, is a common technique on the web, and is the idea behind our coverflow widget. You can use the popular lightbox technique to showcase lists of images in your web pages; if Silverlight is available, the lightbox UI is enhanced to take advantage of the powerful coverflow animations enabled by Silverlight.

View Source Has a Posse

Besides demonstrating the potential for stop-gap standards implementation and progressive enhancement, we had a more important goal for Gestalt: to investigate ways that leading-edge technology embedded in Silverlight could be seamlessly folded into the familiar paradigms of the standards-based web.

Historically, RIA plugins like Flash have been black boxes that smugly sit within web pages, refusing to interact with their surroundings. RIA plugins have much to offer HTML and CSS, yet they often just compete for attention and real estate within web pages, much to the dismay of users.

This dissonance makes life complicated for web developers, too. When building web pages, you want to just fire up your favorite text editor, write some markup and script, and then hit “refresh” in your web browser. There is no separate build or compile step and no deployment packages or manifests to deal with. Proprietary “black box” plugins often require developers to code using entirely different conventions from those used in front-end web development. Chris Messina wrote an article discussing some of the drawbacks of the “black box” approach.

The Gestalt Approach

Like jQuery, Gestalt doesn't compete with the page. It enhances it. Gestalt gives you islands of enhanced functionality within your web pages without the snobbishness we have grown accustomed to in such scenarios.

Both Silverlight and Microsoft’s Python and Ruby implementations were originally designed with this model in mind, so it wasn’t a huge stretch for Gestalt to adapt both technologies. Gestalt seamlessly integrates with the way you already build web pages, adding language=”python” and language=”ruby” to your choices for HTML <script> tags, and enabling XAML to embed directly in HTML. No need to install any IDE or perform build/compile steps – you just write your markup and hit “refresh” in the browser. You can use “view source” and your favorite text editor to view, adapt, and embed any of the Gestalt widgets.

Conclusion

When you combine lowest common-denominator web standards with cutting-edge proprietary functionality, it is possible for the whole to be more than the sum of the parts. Although Gestalt uses Silverlight, we think that the same three principles should apply to any cutting-edge plugin that wants to be a good citizen of the web:

Seamlessly support the “view source”, markup-oriented development model of the web.
Enable bootstrapping of new web standards by being a flexible host.
Expose leading-edge functionality in a way that supports progressive enhancement.

What do you think? Go ahead and comment below, or talk to us on Twitter. Don’t forget to tag your Gestalt-related posts with #gestalt.

Introducing Gestalt 1.0 and the Gestalt Widget Pack

Hans Hugli — Fri, 20 Nov 2009 19:04:24 GMT

A few months ago, we released Gestalt beta as a MIX Online lab. Gestalt began as an exploration—a way to bring Ruby and Python to the web browser. Today, we’re delighted to announce that Gestalt has been updated to version 1.0. It's now part of IronRuby 1.0 and IronPython.

The IronRuby team has made a number of much-needed improvements to Gestalt. In addition these changes, we’re releasing a handful of widgets that we built using Gestalt.

Learn more about them, here.

What is Gestalt?

Gestalt allows you to write web applications in Ruby or Python + XAML in your HTML pages. There's no need for a compiler. You can use your favorite text editor to create DLR Gestalt applications from a Mac or PC. Gestalt applications run cross-browser, so it’s a "write once, run anywhere" client solution for writing Rich Internet Applications (RIA.)

Learn more about the philosophy behind Gestalt in Joshua’s post, or find out more about Gestalt here.

What’s new in Gestalt 1.0? Gestalt Beta -- plus more!

Supports bundling of Ruby and Python files using each language’s convention. You can now (for example) package and run Rails on your client!
Allows you to dynamically load assemblies (only downloads what you need)
Integrated with the Dynamic Language Runtime
Simplified and streamlined model for creating Gestalt apps. No jQuery dependency.
Support for remote references to Gestalt
Visual Studio debugging support
A browser console for debugging and manipulating Gestalt
Rich error reporting
Built-in support for loading external assemblies and content - Support for running multiple instances of Gestalt on the same page

Screenshot of the Gestalt Video Widget

How do I get started? Let’s write a simple app

The syntax behind Gestalt has changed slightly to increase its flexibility. Here is the most basic application one could write with Gestalt—it would simply pop an alert.

<html>

   <head>

   <script src="http://mschnlnine.vo.llnwd.net/d1/dlr-20091120.js"
 
      type="text/javascript"></script>

   </head>

   <body>

   <script type="text/python">

      window.Alert("Hello world")

   </script>

   </body>

</html>

If you would like to add UI, simply add some XAML in a <script> tag marked with an “id” that has the same name as the “class” of the Python or Ruby script you want associated with it. This application will present a 70px x 50px canvas with the words “hello world” written on it.

<html>

   <head>

   <script src="http://mschnlnine.vo.llnwd.net/d1/dlr-20091120.js"

      type="text/javascript"></script>

   </head>

   <body>

   <script type="text/python" class="canvas1">

      me.textBlock1.Text = "Hello World"

   </script>

   <script type="application/xml+xaml"

      id="canvas1" width="70" height="50">

      <Canvas x:Name="canvas1"
 
      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

      Background="Red" Width="70" Height="50">

         <TextBlock x:Name="textBlock1"/>

      </Canvas>

   </script>

   </body>

</html>

(Note that the permanent URL to the DLR.js will change to a friendlier name. Follow us on Twitter to hear about changes as they happen.)

You have to run both these samples off a web server, but you don't need to download any files to your web server. When working with more complex files that depend on external XAML files, you should have a local copy of the DLR binaries on your server. But for simple apps that don't have any external dependencies, this method is sufficient.

And there you have it. Visit http://visitmix.com/labs/gestalt to download the latest version of the DLR and Widgets. We hope you'll be impressed and give Gestalt a spin.

If you create a Widget, let us know—we'll link to it or place it in our Library. And if you find Gestalt useful on your site, shout it out and we will add a link. Let us know what you think by leaving a comment. If you tweet, follow us on Twitter to learn about new content, opinions and articles.

JSON-P: An Elegant Hack (And Another Hack: Creating a JSON-P Service with the WCF REST Starter Kit!)

Karsten Januszewski — Mon, 16 Nov 2009 21:30:28 GMT

I'm working on some prototyping for an upcoming Mix Online prototype (a bit recursive, no?). My prototype provides a service with a REST interface, which has a few methods that send data via JSON and XML.

I'm using the WCF REST Starter Kit (http://www.asp.net/downloads/starter-kits/wcf-rest/) to get a REST service up and running quickly, and using the UriTemplate syntax to make my REST service nice and Web 2.0-like. It's working out wonderfully. Check out the Starter Kit and its excellent supporting documentation here: http://msdn.microsoft.com/en-us/library/ee391967.aspx.

The Cross Domain Scripting Problem

The service I'm prototyping will be consumed by other websites via javascript. At first, my architecture required the user to put a reference to my javascript in his or her page, to get around the cross domain scripting problem. This is pretty standard operating procedure, but it isn't ideal—someone who wants to use my script has to load a third-party script from a different server, and take a dependency on me.

In cases where the service provides more than data (say a mapping service like Virtual Earth), there's no way to get around requiring someone using the service to embed the script in their page. But in cases like mine, where the service is just providing data, it's best to allow the client to get at the data without referencing a script. But how? Browsers don’t allow cross domain calls from javascript.

As it turns out, there is a solution: JSON-P. The use of JSON-P allows my service to be called cross-domain without requiring an explicit embedding of a third party script.

What's JSON-P?

JSON-P is a Javascript Object Notation with Padding. What does that mean? Pretty simple, really: When a provider returns its data formatted as JSON-P, the JSON is wrapped with a callback specified by the client.

So, this JSON:

     { ‘name’: ‘Karsten’ }

becomes this JSON-P:

     myCallback( { ‘name’: ‘Karsten’ } );

myCallback gets called by the client when it is passed to the service. What's the point? Well, instead of referencing the third party script at design-time, the client can call the service just as they would call an AJAX service from the existing domain. The result? The client can get at data from a service that is cross domain.

Most javascript libraries support JSON-P, so you don't have to manually do anything—it "just works". With jQuery, you don't even have to provide the callback; you can just add a question mark to the end of the service call, like so:

     callback=?

The callback gets auto-generated and you simply embed your logic in the call, like this:

   $.getJSON("http://example.com/service?callback=?",        
       function(data) { 

        //do something with the data                
      });

Safety Issues

Some folks worry about security holes with JSON-P, but I wonder—is the JSON-P solution really that much different than embedding a script from another URL in your page?

I think not. In fact, you might argue that JSON-P is (marginally) more secure than embedding a third party script in your page, because usually JSON-P is just returning data.

I say marginally because there's nothing stopping the service that's returning the JSON-P from returning malicious code instead of data. So you'd better trust the service, just as you'd better trust any third party script that you embed in your page.

An Elegant Hack?

JSON-P might just be a cross site scripting hack—but it's a very elegant hack that means my service can be called cross domain. And it is becoming increasing popular. Services such as Twitter, YouTube, Digg and a host of other big name services out there offer their data up as JSON-P.

Supporting JSON-P

This all leads me to my prototype, in which I want to support JSON-P. JSON-P isn't supported by default in WCF until .NET 4. But, it turns out there is a very nice sample which supports JSON-P in WCF. Download it here: http://msdn.microsoft.com/en-us/library/cc716898.aspx.

JSON-P and the REST Starter Kit

It turns out that you can use JSON-P in combination with the REST Starter Kit. Here's the signature of a method that combines URITemplate features of the REST Starter Kit with the JSONPBehavior attribute, provided by the WCF JSON-P sample:

    [WebGet(ResponseFormat = WebMessageFormat.Json, 
            UriTemplate = "{userName}?cb={callbackName}")]   
    [OperationContract]
    [JSONPBehavior(callback = "callbackName")]
    public string GetDataJSONCallback(string userName, 
           string callbackName) 

    { 

        return userName + “: I was called by WCF!”; 

    }

What’s going on here? Well, the first attribute, WebGet, specifies that we want to 1) return JSON and 2) that our URITemplate has a path which includes the name of the callback. (Note: Don’t be distracted by the userName parameter; I included that to show how the REST path syntax works.)

The crux is that the variable name of the callback name, in this case callbackName, needs to match between the WebGet attribute, the JSONPBehavior attribute and the signature of the method call itself. If this is the case and all three are the same, magic happens: the service will return its data wrapped in JSONP with the name of the callback specified by the client. Thanks, WCF!

The Trade-off

When you use the JSONPBehavior attribute, you intercept the request and override the WCF MessageEncoder. This means you bypass some of the glue in the REST Starter Kit, so things like caching will no longer work. This is the only "gotcha" with combining the REST Starter Kit and the JSONPBehavior attribute. But for me, the tradeoff is worth it.

To make life more encapsulated, I went ahead and took the four classes from the JSON-P sample (JSONPBehavior.cs, JSONPBindingElement.cs, JSONPBindingExtension.cs and JSONPEncoderFactory.cs) and compiled them into a single .dll which I then referenced in my WCF Service. Hat's off to whoever wrote such a well-encapsulated sample.

Meetings Suck

Nishant Kothary — Thu, 12 Nov 2009 19:29:33 GMT

Is it just me, or has the culture around meetings in the workplace spun out of control? Meetings are like a plague at large companies like Microsoft, and I've just about had it. I'm constantly holding back my twitching index finger from clicking "Decline" when someone turns an ongoing email thread into a meeting invite.

Cornering people in a room in front of a whiteboard isn't going to solve the problem. That’s because meetings don't solve problems — people do. And they all do it differently.

Solution vs. Consensus

A meeting is supposed to facilitate a solution. Maybe even the "best" solution. Sometimes this process takes a few minds, but let’s not kid ourselves. How often do you think to yourself on your way to a meeting, "This meeting is definitely going to help us arrive at an awesome solution"? Probably not very often.

In fact, most people I know sigh in resignation on their way to meetings. This is because meetings seem to have devolved into a consensus-building and CYA tactics charade, with several participants who aren't invested in the quality of the solution.

One Size Doesn't Fit All

There is no generic template for problem-solving. Take design problems, for instance. Your best bet is to articulate the problem to an experienced designer and let him/her solve it on his/her own terms.

I know loads of folks who come up with the best solution iteratively over time. And given the often very technical nature of design problems, they’re best best solved "on paper". This is why Basecamp messages are often more effective than in-person conversations.

Point is: meetings are not silver-bullets for solving any ol' problem.

Your Time Starts Now

The meeting template incorrectly presupposes a fixed schedule for problem-solving. I'm constantly in meetings where two problems with completely different complexity levels are scheduled for an hour each. Depending on the crowd, some of these end with a signed-off, sub-standard solution. In others, we punt on an important problem because the group can’t agree on how to fix it. And then there are those that end with a follow-up meeting, because we "didn't have enough time".

Get up. Run. Hit brick wall. Repeat.

On That Note

Meetings are useful when they emerge from a natural need; sometimes people really do need to be in a room together to solve a problem. But these types of meetings have become as rare as a hen’s tooth.

In the meantime, we have succumbed to a recurring exercise in futility, accepting meaningless meetings as a necessary evil of our professional existence. I'd love for us to go back to our roots: schedule conversations to solve problems, rather than perpetuate them.

And now, if you'd excuse me, I have a meeting to attend. Sigh.

Meet me in the comments if you have something to say. Or, follow us on Twitter if that's your thing.

HTML5 vs. Silverlight: Which Will Win?

Joshua Allen — Tue, 10 Nov 2009 19:26:32 GMT

Every now and then, someone asks me, "Which technology will win: HTML5 or Silverlight?", or "What is Silverlight's strategy to compete with HTML5?".

I always have to take a deep breath before responding, because these questions presuppose something that doesn't make any sense to me. It's like asking a tool store owner, "Which will win, hammers or screwdrivers?", or "How will you prevent hammers from making screwdrivers obsolete?"

Black-and-white Thinking

Some important folks in the industry have argued that HTML5 is a Silverlight-killer, or that Silverlight exists to prevent HTML from advancing. These are dramatic claims that only heighten conflict in an industry afflicted by fictionalized Zarathustrian "black versus white" stories.

The Right Tool for the Job

Microsoft ships the world's most popular HTML client. Despite the HTML5 specification being a work in progress, we implemented several HTML5 features in our most recent browser. Microsoft has co-chaired the HTML5 working group in W3C since its inception, and we remain active participants. And our browser will continue to be the dominant HTML standards implementation for the foreseeable future.

Likewise, we continue to invest heavily in Silverlight development and deployment. If Silverlight and HTML are mortally opposed, as the story goes, we must be crazy to invest so heavily in both, right? Wrong.

The truth is, Microsoft is a developer company, and there is no one-size-fits-all, perfect tool for every development job. Can anyone seriously criticize us for investing in C#, JavaScript, and Ruby and Python (among other languages)? No! Our customers should be able to use the right tool for the job at hand.

As with development languages, there is no single development platform for every job. HTML5 will be fantastic for some scenarios, while Silverlight will be great for others. Besides Internet Explorer and Silverlight, we ship a bunch of other platforms, including XNA and DirectX for game developers, WPF and .NET, Win32, and others. We have the depth and breadth to be best in class, no matter what platform developers want to use.

Opportunism vs. Reality

So, why do certain people propagate this myth? Do they really want a monoculture world where there is only one platform for every job? Or are they truly arguing from an idealistic or religious viewpoint, as some of their arguments would suggest?

In my opinion, it's a lot simpler than all of that: those who argue that HTML5 will supplant everything else tend to be companies who have nothing else. If you only sell hammers, you might as well try to convince people that there are no such things as screws. And you can drive awareness for your newly-incorporated hammer store by telling tales of intrigue and conflict between hammers and screwdrivers. But the fact that these arguments are often couched in conspiracy theories or ideology, suggests that they are primarily opportunistic marketing ploys, and not motivated by pragmatic technical reality.

What do you think? Leave a comment below, or hit us up on twitter.

When Projects Fall Apart

Thomas Lewis — Fri, 06 Nov 2009 22:20:43 GMT

It’s rare to find an organization that has not had a project stall, flail, or completely fall apart. By the time you find your project in this position (and are willing to accept it), you’re typically already “in the weeds” or “bailing water out of the boat with a bucket”. I’ll admit that this has happened to me. It happens to all of us.

When you find yourself in this position, what should you do? Or, more importantly, what shouldn’t you do?

Don’t Yank the Steering Wheel

Don’t go into extreme course correction mode. If you had a plan, believe in the plan. It’s easy to scrap what you were thinking of doing and just “wing it”. But most of the time, this reactionary thinking only makes matters worse and takes you farther away from your goals.

Review Your Goals

It’s often the insignificant details that derail your project. For example, if the goal of your site is to sell concert tickets, is it really necessary to spend inordinate amounts of time getting the Twitter widget working? Be sure that the goals and features of your project align; if they don’t, adjust your feature list accordingly. There’s always version 2.

More Cooks, Worse Meal

This is probably a no-brainer, but resist the urge to throw more resources at the problem. 80 hour work weeks, feature creep, and more meetings will only make things worse.

A better strategy might be to reduce your feature set and give your team breathing room. After all, how often have you stared blankly into your computer screen boggled that you can’t figure out a problem, only to solve it while in the shower the next morning? Creativity cannot always be scheduled.

Sometimes You Have to Say Goodbye

Most web development and design projects are not life and death matters. If the schedule has to slip, so be it. Might ruffle people’s feathers, but in the end no one will remember that you slipped a few days (exception: Spouse’s Birthday), especially if it means producing better work in the long run.

And when all else fails—when you’ve whittled the features down into an anemic product, for instance—kill the project. Take time, reflect and move on.

Have you had a project that was on a bad trajectory? What did you do to get it back on its feet? What would you have done differently? Let us know in the comments. Also, you can follow us on Twitter, or worse follow me.

Calculating Risk

Hans Hugli — Fri, 06 Nov 2009 17:58:54 GMT

Over the course of the past year, the MIX Online team has taken some great risks designing and developing our labs. Each lab requires months of effort, and we occasionally have to placate our legal department or internal influencers to do things that some consider controversial.

Not all of our labs pan out. I’ve personally worked on two labs that never saw the light of the day. It's truly frustrating when this happens, when the risk does not pay off. Back to the drawing board.

On the other hand, it's extremely rewarding when we successfully launch a new lab. Our biggest challenge is gauging whether our efforts will be worth the risk.

Are the risks worth taking?

What's the potential return for our risk? Is the potential return worth the effort? We try to mitigate high risks and envision all possible outcomes and issues that might derail a project before we start.

The S.W.O.T. analysis is a simple, useful tool we use to evaluate risk and form a good project strategy. It's basic questions are:

What are the strengths of project X? What new ideas or innovations does it bring? How can it improve a user’s experience? How does it improve upon existing technologies, applications or things?
What are the weaknesses of project X? What is it lacking in this project? Will it do more damage than good? How fragile is it? Is it compelling enough? Is the concept good, but the user interface poor?
What opportunities does project X provide? Does this new project open up doors to new relationships and communities? Does it provide users and developers with something that can empower them? Is it something that will be picked up and incorporated into a product?
What threats exist to project X? What development or design issues might bring this project down? Are we taking on too much in too short a timeframe? Are we overextending ourselves? Again, is this something that will be picked up and incorporated into a product?

Innovate or Die

We’ve all heard the cliché adages: No pain, no gain. No risk, no reward. I think it's imperative to research, invest, and take controlled risks—whether we're talking about Mix Online or everyday life. Either that, or stagnate. No one wants to see something everyone's already seen. We need to take calculated risks and raise the bar.

Are you or your business taking great risks? Have you experienced appropriate rewards when you have taken risks? How do you minimize risk while still being innovative? Or do you believe it's more rewarding to discover a new niche market and pwn it? Let us know by leaving a comment. And if you tweet, follow us on Twitter to learn about new content, opinions and articles.

Who gives a “gosh-darn”?

Tim Aidlin — Tue, 03 Nov 2009 18:00:30 GMT

Being able to see, collect, and analyze a wide spectrum of data concerning your brand, event, or website is very useful. Increasingly, social media tools such as Facebook, Twitter, & Channel 9 make gathering this information—and keeping in touch with our audience in general—easy.

These same tools make it extremely easy for our audience to keep in touch with us. At conferences, for example, we can stream live content that shows what other attendees are thinking & doing back to the audience. News stations do this all the time, displaying live Twitter feeds of certain words marked with keywords, such as "#election".

Broadcasting an audience's live, unfiltered feedback is compelling and useful, but it also presents some challenges, most of which revolve around profanity, search results, and spam:

Profanity
How do we deal with bad words & cursing? Just being a jerk for being a jerk’s sake? What about “rated X” avatars? Do we want profanity displayed to our conference audiences?
Search Results
What happens when your Twitter search or “hashtag” produces unexpected results? Searching for "#election" in New York, after all, will probably produce "#election" results for all kinds of elections—not just those in New York. If we can't register hashtags (which would be a nightmare to maintain and control), how do we deal with irrelevant search results?
Spam
Tweet spammers tend to piggyback spam messages onto “trending topics”, which are the most searched-for keywords at any given point (i.e., @britneyspears, #healthcare, #keyword). How do we arrange our hashtags so this doesn't happen?

Censorship

The easiest solution is to simply apply a filter that knocks out bad words and items with multiple subjects/search-terms. But this presents a whole new problem: censorship.

It's clear that heavy censorship defeats the purpose of live, community-generated content—to give an open and honest glimpse into your audience's thoughts. Still, there's definitely a need to filter for obvious, extreme instances irrelevant or pornographic content; otherwise, people will stop reading the feeds.

But what about less obvious instances of profanity? How can we be mindful of our audience's sensitivities, when everyone's sensitivities are different? How can we filter, but not censor, content? And where do we draw the line?

Who Cares?

One solution is to just let the community work this problem out itself. After all, who really cares about "inappropriate content"? The answer is unclear.

If you are a person who cares (or doesn't) about inappropriate content, I'd love to hear from you. What content is in bad taste? What is offensive? Do you hate cursing? Where should we draw the line? Let us know by leaving a comment below. Feel free to curse if you really want to be a jerk.

To Minify or Not To Minify

Karsten Januszewski — Fri, 30 Oct 2009 18:11:45 GMT

Back when we were about to ship Oomph2, I found myself ranting about having to minify the oomph.js script.

Minifying was this annoying, non-automated step in the build process, and it caused me grief—just when we thought we were ready to ship and I'd minified what I thought was the final build, a bug would pop up. I'd have to start all over.

Additionally irksome was the fact that it was impossible to debug or step through bugs that manifested in the minified script (sidenote: I’m a very happy user of the IE 8 Javascript debugging tools, as well as the Visual Studio Javascript debugger). Of course, I'd have to change the script tag back to the un-minified script for debugging.

The 32KB Difference

It was during one of these rants that Joshua, who sits next to me and is often subject to my rants during development, noted that my minification was shrinking a 62KB script into a 30 KB script—a negligible difference. This led to a discussion about whether that 32KB really made any difference. I did the minification because it seemed like a best practice. I wanted to show that we “got it"—that yes, squeezing every bit of performance out of the download was the way to go.

But was it? And were 32KB's worth all the trouble? Maybe not.

Minification is Anti View Source

In addition to everything above, there’s another downside to minification that's worth mentioning. Let’s say someone comes across a page and wants to view source, to find out how something on said page works. Minified javascripts defeat that purpose because, in doing the minification, the scripts are obfuscated and cannot be “read” by a human.

Even if there exists somewhere a non-minified version of that same script, it's likely that, right at that moment when you are browsing a page and think “Oh that’s cool; I wonder how they did that,” you won’t actually go off and find the unminified version of the script. And even if you did manage to find it, you'll likely be stuck with a script removed from the context of the page in which you discovered the script in the first place.

In other words, minification is anti view source.

But It Does Make Sense

All this said, minification—especially if you have a mondo-huge javascript—does make sense. In the era of smart phones, smaller size increments do matter. Additionally, one must always remember that not all of the world is on broadband. It ostensibly seems like a best practice.

The Verdict?

I’m not sure where I land on minification. I haven’t formulated a position quite yet.

I do know this: When I was minifying Oomph, I used a very cool, Microsoft internal-only minification tool. With the most recent release of the Microsoft AJAX toolkit, this tool has been made available to the world.

The Microsoft Ajax Minifier download includes the following components:

ajaxmin.exe – a command-line tool for minifying JavaScript files

ajaxmintask.dll – a MSBuild task for minifying JavaScript files in a Visual Studio project

ajaxmin.dll – a component that you can use in your C# or VB.NET applications to minify JavaScript files

You also have the option of adding the Microsoft Ajax Minifier as a custom MSBuild task to Visual Studio. Adding the Microsoft Ajax Minifier MSBuild task to your Visual Studio project file allows you to automatically minify all of the JavaScript files in your project whenever you perform a build, and enables you to perform minification in an automated way. This is very cool and would have come in handy during Oomph development. I will definitely incorporate this into our build/release process moving forward, if in fact I keep minifying.

To read more about the minifier, check out Scott Guthrie’s excellent blog post, which talks about how the minifier works, and provides comparisons (based on compression rates) with other minifiers out there.

I’m curious about other folks' thoughts on this topic: to minify or not to minify?

Take Me To Your Leader

Nishant Kothary — Wed, 28 Oct 2009 23:51:09 GMT

It seems like some projects are just destined to fail. No matter what we try — add more budget, assign more people, call more meetings, work longer days — it's simply impossible to steer these troubled projects down the right path. Why? In my experience, the root cause is something that we frequently discount: strong leadership.

Less is More

Ironically, projects always seem to fail for variety good reasons: biting off more than can be chewed, not enough time to execute, incorrect prioritization of business goals, and so on.

Despite their unique origins, failing projects share one thing in common: they all need someone to take action quickly. I’ve seen Microsoft teams grow from ten to hundreds of people, when putting the right people in charge would have solved the problem just as well. Vista vs. Windows 7 is a classic example.

The Elephant in the Room

If you privately ask a person to explain why his or her team's project is failing, most of them will tell you exactly why (and most of the time they will be right!). But, get those same people in a room to discuss and solve the problem, and the reasons they pinpointed earlier all collectively morph into a big, fat elephant in the room. Maybe the reason for this is optimism bias setting in. Or, maybe people find it difficult to step into a room and say, “Well, this project is failing because of X”, where “X” is one of numerous very harsh options like, “bad leadership”, “a terrible designer”, “an arrogant developer”, and so on.

Whatever the case may be, what’s really needed is one individual who has the ability and accountability to truly course correct.

The Wisdom of Crowds

It may seem like I’m advocating for a dictatorship or thoroughly discarding the wisdom of James Surowiecki’s insightful book. I’m not. To the contrary, diversity, independence of opinion and decentralization are key to innovation and success.

Still, when you’re running a business or even a team at a corporation, there’s no substitute for an experienced driver with a good internal compass. You have to be prepared to make sharp turns constantly and quickly. That’s where strong and direct leadership come in.

Decision by consensus is a theoretical luxury that most of us will never experience in the real world. Good leaders either drive or find someone trustworthy to take the wheel.

Decision by consensus is a theoretical luxury that most of us will never experience in the real world. Good leaders either drive or find someone trustworthy to take the wheel.

A Final Word

I've worked on both terrible and fantastic teams. There’s usually a stark contrast between the environments created by both at almost every level: employee morale, speed of innovation, individual performance, trust among team members, and much more. Needless to say, all of these suck on a terrible team. Unfortunately, our tendency as humans is to solve these “symptoms” where the root cause may be the incompetent guy or gal who’s making the big bucks. The sooner you realize this, the sooner you’ll take control of your professional destiny.

What have you learned about dysfunctional work environments? Share your thoughts in the comments or send us a message on twitter.

Happy Birthday Mix Online!

Thomas Lewis — Fri, 23 Oct 2009 18:21:42 GMT

MIX Online, our community for designers and developers who build the web, is now 1 year old.

We took the cover off the new site last year on October 22nd, with a fresh (some would say "non-Microsoft") aesthetic and our first lab, Oomph.

Our goal? Build a site that we would want to be a part of.

We created a place where folks can read insightful articles from our friends, hear our opinions (we are an opinionated bunch), and download free, open source labs that help you build and do things. No marketing speak or 3-letter acronyms.

We also wanted to promote our MIX conference, where we all get together and learn stuff.

Thanks to you, our community of friends, we're still going strong one year later. Your kind words and suggestions have given us confidence and urged us to grow.

For our one year birthday, we're making some big changes to Mix Online and MIX10 conference site, as well as creating new labs. We think you're going to like it.

With your support, MIX Online will stay brutal. Thank you!

Let us know what you like, don’t like, and would like to see in the comments below. Follow us on Twitter at @mixonline or me at @tommylee.

Oomph and Microformats Activity

Karsten Januszewski — Fri, 16 Oct 2009 17:56:49 GMT

There's a lot going on these days with Oomph (our microformats toolkit) and microformats in general. Here's the latest:

Oomph-land

Oomph2 is now in the IE Add-ons gallery. As you might suspect, you can find nifty add-ons for Internet Explorer there. If you're looking to submit something and having trouble, let us know—we now know all about the process.

Oomph is now also part of http://twtmycard.com, a website that takes advantage of Twitter's support for hCard. If you're curious: the developer of the app, Kevin Marshall, writes about the Oomph integration here.

Microformats-ville

There's always a lot going on with microformats. On the adoption front, it's great to see MySpace incorporating hCard in its Profile 2.0 work. With MySpace joining the party, the latest count of hCards out there numbers 1.45 billion, according to Yahoo's Search Monkey.

The Food Network has also started using microformats, adopting the hRecipe spec in its pages. (This could be a very interesting extension to Oomph.)

There's also stuff happening with applications that consume microformats. The most interesting project to emerge of late is Glenn Jones' Ident Engine, a javascript library that uses YQL, Google's Social Graph API and Glenn's own ufxtract Microformats parser (written in .NET!) to find and aggregate profiles across the web. There a number of cool demos that show the power of what Glenn's built up at http://identengine.com. Pretty amazing stuff.

And on the design front, there are some nicely formatted hCards out right now, some of which were called out recently on the microformats blog:

Tim Van Damme

Rogie King

Jared Hanson

Go microformats!

How to Identify a Web Designer

Nishant Kothary — Wed, 14 Oct 2009 21:06:37 GMT

A couple years ago, Microsoft hired me as a User Experience Evangelist. Since then, I've worked with amazing designers, artists, and thinkers from some of the best agencies in the world—and learned a lot about recognizing a great web designer when I see one.

If you're in the market for a web designer or agency, here are a few things to keep in mind.

Not Just UX.

These days, it seems like every other person I come across has "UX" in his title. Somehow, the term has come to imply that you are an expert at designing anything and everything—especially web sites. But web design is not just UX.

Web design relies on a unique set of cross-disciplinary and specialized skills that require a "renaissance person" attitude to master. If you don't believe me, go spend some time at A List Apart or 24 Ways.

In other words, being good at web design means being good at a lot. You have to understand browsers and markup languages. You have to grasp the basics of several cross-disciplinary fields, like content strategy and graphic design. All this, while staying firmly grounded in the reality of how everyday users browse the Web.

Take any one of the above qualities out, and you're left with someone who's not a web designer. Not worth their salt, anyway.

I-Shaped People

In a recent article, Bill Buxton argued that innovation calls for I-Shaped People: thinkers who have their feet firmly planted in the practical world, but who can also stretch their heads to the clouds-and simultaneously span all of the space in between.

In other words, you need people who are comfortable with both practice and theory. I've found that "I-shaped" web designers are best kind.

What To Look For

Most people don't know someone who can identify a good web design agency for them. If you're DIY-ing, are here the most important questions to ask in your evaluation:

Do they have an impressive portfolio of HTML/CSS web sites? A couple of good examples: BlueFlavor & thingsthatarebrown. This is the most important question.
Do they advertise their information architecture services?
Are they passionate about developing standards-compliant web sites?
Do they specialize in building web sites?

If you answered "no" to any of these questions, I suggest you keep looking.

What's my point?

If you are a small business, product team within a corporation or even a freelance professional who’s in need of a web site, you need to carefully consider two things: 1) what you need built and 2) who is qualified to build it for you.

Chances are, you need a good, clean, standards-compliant web site built using XHTML/CSS. Unfortunately, not everyone with the words "UX" or "design" in his title could build you a good one. In fact, most couldn't. Take heed and do your research before hiring any 'ole UX guru.

We welcome you to leave a comment or continue this conversation on twitter.

Iz Puttin' Namespaces in Ur HTML5

Joshua Allen — Mon, 12 Oct 2009 22:56:34 GMT

A few weeks after I wrote about "The HTML5 Semantics Debate", the Internet Explorer team sparked an exciting discussion with a proposal for extensibility in HTML5. IE’s proposal seems to have been inspired by Sam Ruby's proposal from 2007, and suggests a few different ways to make HTML5 extensible.

The proposal was welcomed by some, while others were not so charitable:

[01:49] * tantek is resisting the temptation to write a massive "bitch-slap" (technical term) email to public-html in response to the proposal. (Microsoft people ought to know better)

It's an absolutely fascinating discussion, and worth reading all of the posts. Opinions are all over the map on this one.

When I wrote about this issue last month, I felt that formal specification would be a waste of time, arguing that people could simply continue using one of the existing "hacks" for extensibility. But this recent discussion has highlighted some inconsistencies in browser behavior which will probably never be fixed unless formally specified. If I've concluded anything from this conversation, it is that the W3C really ought to formalize a mechanism for extensibility. It really doesn't matter whether the ultimate solution uses namespaces or not, as long as a method is specified.

We struggled with this exact issue when developing Gestalt. Gestalt enables XAML embedded directly in HTML, and XAML is an XML vocabulary. When Firefox or Chrome parse a document containing XML fragments, the browser automatically converts all tag names to lowercase and improperly nests tags with trailing slashes. Since XML is case-sensitive, and since nesting is important to XML, this ruins the XML. To protect your XML from being molested, you need to either use XHTML or else overload the <script> tag semantics by burying the XML there.

It's easy to imagine why the Firefox and WebKit (Chrome) developers chose to do this. It makes things more convenient for browser implementers. But it's not at all what a page author expects, and is really unfortunate, IMO. As long as the spec leaves details like this up to the implementers, we can expect these inconsistencies to continue. A solid specification for distributed extensibility would make a big difference.

Of course, some have argued that HTML5 should not be extensible, and might argue that browser bugs like the above are good, because they dissuade people from adding "proprietary" junk to HTML. But I'm becoming convinced that Sam Ruby is correct on this point:

I am of the belief that attempts to legislate morality in the long run will be as successful as the 18th amendment to the US Constitution was. I also happen to believe that we can't standardize everything at once, so at whatever point in time we happen to want to take a snapshot for HTML5, there will always be new elements and features (e.g. datagrid) which will not yet be standardized, and planning for evolution is the responsible path forward.

Risk, Reward, and the Strategic Plan.

Hans Hugli — Wed, 07 Oct 2009 18:15:10 GMT

Many years ago, a friend and colleague of mine mentioned that I was a "leaf on the wind." Initially I did not internalize what he meant, since I was successful at my job. I interpreted his observation as: I could adapt easily and “go with the flow.”

It took me years to realize what my friend meant: I was taking the “safe” route, being directed by external influences. That although people thought of me as a hard and reliable worker, I never took a stand on anything. That I had lost my identity in the chaos.

Well, that’s no good…

The Identity Dilemma

The Windows Mobile story is a great metaphor of this "identity issue" applied to a product. Since the beginning, Windows Mobile tried to be everything to everyone. Even though its devices were focused on business use cases, Windows Mobile tried to be a full, standalone Windows OS—but with a phone bolted onto it. It didn't fully address the needs of consumers, and was a dismal user experience.

While their efforts may have been noble, the Windows Mobile team just hadn’t rolled out their product, or addressed consumers, in a strategic way. As a result, Windows Mobile lost its identity. Nobody notices it.

Enter stage right: iPhone.

No Risk, No Reward

Most the time, losing identity—whether we're talking people or products—results from not having a plan. From not creating a strategy, being assertive, or taking a risk.

We always hear: “With no risk there is no reward.” Sure this is an oversimplified cliché, but there is a ring of truth to it. Thinking strategically can help us take intelligent risks, and create and execute a plan. Being strategic also improves the odds of a positive outcome.

If Windows Mobile had chosen to target a specific niche (such as business or consumer) and thought through the user experience, maybe they would have been more successful. But that would have meant taking the risk of reducing purchases or alienating one audience.

Think Strategically

I just finished reading Learning to Think Strategically, by Julia Sloan. It was a very informative and enlightening read.

Sloan’s advice is to employ an iterative process in three stages: preparation, experience, and evaluation. Then, repeat the process to refine to the plan. The book provides tools, guidelines and cites real world examples that neatly exemplify her writing.

Strategize Yourself

What does thinking and planning strategically mean for me? It means having a purpose by need or desire. It means defining the problem or goal and studying, focusing, accepting and coping with the unknowns. It means coming up with a plan to navigate and bring order to chaos. It means taking risks. It means validating my plan through dialogue with others: inviting criticism and feedback from peers and external influencers who can help me improve.

And by the way: I'm happy to say that just today (10/06/09), Windows Mobile announced the release of Windows 6.5. This release consciously targets consumer needs and is a huge step toward addressing their identity dilemma. It seems that they now have a good working strategy in place. Congratulations guys.

Have you felt as though you were powerless over the chaos in your world or domain? Have you found an effective and successful way to engage and address it? Let us know by leaving a comment. And if you tweet, follow us on Twitter to learn about new content, opinions and articles.

A Beginning Glossary for the Web Designer or Developer

Tim Aidlin — Wed, 07 Oct 2009 03:41:00 GMT

In MIX Online Opinions, we try to speak to a wide variety of designers and developers for the web. There are, however, myriad levels of expertise within those groups: developers and designers who have been working for years, those just breaking into the industry, those who strictly work in comps, those who only write code, and those who do both. Sometimes we even speak to someone from the client-side, looking to learn more. It can be challenging to “target” our writing properly.

I'm reminded of this in a blog-post, Aidlin Lost Me at CMS systems….., by Ryan (I couldn't find a last name), about an article I wrote earlier this year. Ryan says:

I felt like a “fish out of water” reading Aidlin’s 'How We Work (and sometimes skip some steps)'. ... I found myself looking up the meaning of many of the acronyms that Aidlin uses in his article. The first read of this article was difficult for me, it was like trying to eat a bowl of alphabet soup with a knife…I just could not get a handle on what CMS, CSS, TFS and XAML meant.

First of all, Ryan's similie is awesome: "like trying to eat a bowl of alphabet soup with a knife." Kudos for that.

Rather than only go back and provide in situ links, I thought it would be beneficial to provide a glossary of the terms and acronyms I gloss over my previous post. Additionally, I'm hoping you, fair reader, will leave comments with additional terms and acronyms you commonly use, and would benefit the community. Let's begin:

Assets

When we talk about assets, we're usually referring to the discrete files which are required for deployment of the site or project. As a designer, I generally work with "creative assets," specifically meaning the individual images and stylesheets which are deployed in the project. For example, a wireframe would not necessarily be considered an "asset," which the individual .jpg logo that goes in the header of the site would.

CMS: Content Management Systems

"A content management system (CMS) ... is a computer application used to manage work flow needed to collaboratively create, edit, review, index, search, publish and archive various kinds of digital media and electronic text." - Wikipedia

One difficulty in maintaining a site, especially a large site with multiple contributors, is content-management: how to change your content, get new images online, switch out links, etc. There are many types of systems, ranging from great paid versions like ExpressionEngine to customizable and free open-source software like RadiantCMS.

Comps / Composites

Comps are generally static images that represent a site or application in different states. Where wireframes present the general outline and structure of the site, comps usually feature aesthetic choices such as colors, fonts, logos, and the like. Often comps are delivered to the client with a set of redlines, which help explain specifics of the designs.

CSS: Cascading Style Sheets

"CSS is designed primarily to enable the separation of ... HTML ... from document presentation, including elements such as the colors, fonts, and layout." -- Wikipedia

CSS enables a web-designer or developer to build a site using HTML and attach a separate file that makes the HTML look a certain way. This means (generally) that the actual content and structure of the site are separate from how the site looks. Using CSS makes web-development and design a lot more fluid and flexible, makes your pages load better, and makes them more accessible to users with disabilities.

body{
background-color:#333;
font-family:Arial, Helvetica, sans-serif;
font-size:1em;
color:#fff;
}

HTML

"HTML, which stands for Hyper Text Markup Language, is the predominant markup language for web pages. It provides a means to create structured documents by denoting structural semantics for text such as headings, paragraphs, lists etc as well as for links, quotes, and other items." - Wikipedia

At the most basic, HTML makes web-pages.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type" />
<title>Untitled 1</title>
</head>
<body>
Your content goes here
</body>
</html>

Layered Comps - .psd / .ai / .eps files

Designers often use Adobe Photoshop or Illustrator to design the comps for their projects. When creating these designs, they'll make use of layers and layer-sets to build their images. These "broken-out" images are of particular use to developers when coding a site or application, as it gives them access to absolutely all potential assets they might need, without having to rely on communicating with the designer for each particular piece they might need. Layered files can get preety large, though, so are often simply "handed over the fence" to development toward the end of the design phase.

Redlines

Because developers are often having to translate layered and static comps into working, functional sites and apps, there is often a disconnect between what the designer envisioned in his or her comps, and what the developer sees as important to completing the project.

To help with this translation, redlines are often used to call out specific aspects of the user-interface design and interactivity. Details such as spacing, fonts, colors, actions, and the like may be called out to ensure the developer coding the design takes the designer's concerns into consideration.

Silverlight

"Silverlight helps you create rich web applications that run on Mac OS, Windows, and Linux. Welcome to a new level of engaging, rich, safe, secure, and scalable cross-platform experience." -- MSDN

Silverlight is an excellent technology for creating rich, interactive web and stand-alone applications. Silverlight uses XAML, and User-Interfaces can be created either in Microsoft Expression Design or Blend. For more, detailed information on Silverlight, I'd check the Silverlight.net site for great demos and articles.

Source-control and project-management software

When building a site or application, often multiple members of the team will want to work on the same file or files at once, or need collaborate on other aspects of the project such as manage timelines and deliverables, and communicate with the team that's involved in building your site. There are various systems you can use such as Microsoft SharePoint, Basecamp from 37 Signals, Microsoft Team Foundation Server, and the like.

For small agencies and freelancers, the "CMS of choice" generally is just keeping following a file-nameing convention for your documents and images so you can find them and don't copy over old work. In short, being super-careful and backing up their files regularly.

Styleguides

Styleguides are something totally different than "stylesheets" / CSS, mentioned above. A styleguide is a general guide (usually a mult-page Adobe Acrobat document (.pdf) or Microsoft PowerPoint document (.pptx)) that everyone involved with production on a project refers to. It includes specific details about fonts, colors, logos, aesthetic elements, and other important information such as messaging and tone for content, and personas.

TFS: Team Foundation Server

"Microsoft Visual Studio Team System 2008 Team Foundation Server (TFS) is a team collaboration platform that combines team portal, version control, work-item tracking, build management, process guidance, and business intelligence into a unified server." - MSDN

At MIX Online,, we use TFS to create, track, and maintain source-control for all of our projects. Whether it's code for one of our labs, or the source HTML and CSS for our sites, the files are all "checked-in" to TFS. This means if I want to make a change to an image on the site, I use TFS source-control to check the file out, lock it so no one else can modify it while I'm making the change, and then check it back in with notes on the modifications.

If we ever need to roll back to a previous version of a file, we have a history changes and can always restore to a previous state.

TFS = security and workflow = awesome.

Wireframes

Wireframes are generally static images that present the general structure of major elements to a site or application. Often this work is done by an Information Architect (I.A.) and created in a piece of software such as Visio, OmniGraffle, Adobe Illustrator, or PhotoShop. Wireframes often show the structure of the project and include flowcharts and diagrams that mapp user-flows and interactions.

WPF

MSDN describes WPF as follows:

"Windows Presentation Foundation (WPF) provides developers with a unified programming model for building rich Windows smart client user experiences that incorporate UI, media, and documents."

More simply, WPF is a Microsoft technology that allows for easy creation of Windows-based applications. As an example, MIX Online's The Archivist and Flotzam are both WPF applictions, designed and built using Microsoft Expression Blend and Microsoft Visual Studio

XAML: Extensible Application Markup Language

"XAML simplifies creating a UI for the .NET Framework programming model. You can create visible UI elements in the declarative XAML markup, and then separate the UI definition from the run-time logic by using code-behind files, joined to the markup through partial class definitions." -- MSDN

XAML is one of the languages that Silverlight and WPF applications are written with. Essentially, XAML used in much of the same way as HTML, CSS, and JavaScript are used -- to define the look, feel, and top-level functionality of the site or application.

Microsoft Expression Design can natively generate XAML, which can then be used in Microsoft Expression Blend, a tool that helps you build robust experiences in Silverlight or WPF.

This list is far from exhaustive, but I hope it gets us all on the same page about the basics. What words, acronyms, or technology-related phrases have you come across that you have yet to find a good definition for? Do you use a technology that should be added to the list above? Be sure to leave a comment, and follow us on Twitter at @MIXOnline for the latest Opinions, Articles, and free, downloadable, open-source prototype software.

Away from the screen

Tim Aidlin — Thu, 01 Oct 2009 21:03:00 GMT

A few weeks ago I wrote an Opinion called “From Web, to Real World,” in which I discussed how content is flowing from the Web into more familiar objects such as books, posters, and even pillows.

One example of this comes from icanhazcheezburger.com, an internet startup who has begun to expand outside the web with books such as I Can Has Cheezburger?: A LOLcat Colleckshun.

Recently, I went to one of their book-release parties where I exchanged cards, talked web-nerdiness, and had a really good time with other geeks and fans. This experience got me thinking about another way that the web is creeping out into the real world, into "meatspace" (aka, actual face-to-face interactions)—and how important this face-time is to a developing designer.

Getting away from our screens and actually meeting people is critical to learning and growing.

Conferences

Conferences are a great way to learn about new ideas and emerging technologies. Notably, a lot of the best learning happens off-stage and outside the conference room, when you meet other attendees.

Depending on the size, scope, and focus of the conference, you might meet people from around the world, across the country, or even your own backyard. These interactions lead to a more global and “holistic” understanding of the conference—as well collaborations and, sometimes, good friends.

The benefits of such “schmoozing” are long-lasting and important, to both you and your team or company. I can't count the helpful blogs I subscribe to simply because I saw an inspiring speaker at a conference such as An Event Apart, The Future of Web Design, or MIX; or the smart, inspiring people I've met.

Meetups and User-groups

In addition to conferences, I try to regularly attend “Meetups” and user-groups around the city. These are usually put together by designers and developers who want to foster community around a particular topic (such as web design or social media), technology (such as Silverlight or Flash), or even company (such as Adobe or Microsoft).

Even though attendees' backgrounds vary greatly, everyone shares a common interest—so it’s easy to get a good discussion going. I like the sense of camaraderie and general openness to new ideas, ways of approaching problems, and insights into emerging trends.

Beers

Finally, we get to beer. Or martinis. Or whatever. The point is this: it's often the most casual conversations that spark something new.

For instance, a while back I was talking with a designer I knew only professionally up to that point, when he happened to mention a favorite restaurant here in Seattle that I, too, enjoyed. We decided to go there for a quick happy hour after our last meeting. By letting down our guard in this way, we were able to work out some issues we'd been having with a project, as well as become better friends.

Putting Yourself Out There

We all have different personalities and quirks, and it can be hard to “put yourself out there.” Still, it seems so worth it to extend your hand and take the risk of making a connection, learning something new … growing. What have you found that forces you to learn and grow with others? School? Online communities? Social-networks? Let us know by leaving a comment below, or follow us via Twitter at @Mixonline.

Picking Type for Web

Nishant Kothary — Wed, 30 Sep 2009 22:05:47 GMT

Please note that this study is now complete. We ended up picking Georgia for reasons that I explain in the comments below and in this post. Thanks to everyone who wrote in and participated!

As a part of the visual design process for MIX Online's upcoming redesign, I've been experimenting with typography. The task of finding a typeface that's both aesthetically pleasing and legible, however, is a tricky one.

The Problem With Type

Part of the problem is that typefaces vary across mediums. The text changes from browser to browser. It looks different on a Mac than on a PC. Finding typography that works for the web is a game of broken telephone.

Say No To Photoshop?

Even our tools conspire against us. It's customary for web designers to start the process of rendering type in Photoshop, because Photoshop seems like the best tool for making pixel-perfect comps. But can you really create a pixel-perfect comp in a tool designed to deal with bitmap graphics? It's not a trick question. The answer is no.

I think there's merit to Mr. Fried's ever-controversial rant about skipping Photoshop in the design process, especially when it comes to typography. Getting into the real rendering environment — the browser — is better than starting in Photoshop. When you're designing type for the web, you don't want to settle for an approximation of what your users will see. That's all Photoshop is going to give you — a very optimistic approximation.

More Than Just Fonts

So how do we select the right font-stack? The first step is to realize that picking type for web is about more than the properties of the actual fonts. It's about web analytics. Fine-tuning font properties in CSS. Considering how a font degrades across browsers and operating systems.

This is why many designers, like Jina Bolton, are gravitating toward font-stacks like this one:

font-family: "Hoefler Text", Baskerville, Garamond, 
"Palatino Linotype", Georgia, "Times New Roman", serif;

This is a great way of picking your font stack because it optimizes the experience for your majority audience. In her case, I'm willing to bet most of visitors are Mac users and a good number of them have Adobe's Creative Suite installed. In other words, most of her users will see one of the first three fonts in that stack providing her users a fresher and richer experience. A few years ago, using anything but Verdana, Arial, Georgia and a couple of other fonts would have been faux pas. Things are starting to change.

Help Us Pick Our Font

In an effort to help us pick a font-stack for the Mix Online redesign, I've devised a very quick readability study. Open the following links in separate tabs (hold down the ctrl key on Windows or Command key on Mac as you click the link, and it'll open in a new tab).

Spend some time looking at and reading the text in each of the tabs. Then submit a comment with the following information:

1. What OS are you using? If you can test on both Mac and Windows, even better.
2. Top 3 choices. Judge legibility and aesthetic quality.
3. Any other comments

The first 20 respondents (excluding my fellow co-workers, sorry) will receive good karma and a copy of "A Website Named Desire", the gorgeous infographic poster we created a few months ago. Here are a few pictures of it and if you want to explore it online, check out our Descry visualization.

What do you think?

Are you a web designer? How do you pick type for the Web? Are you a user? What are the sites that do a good job of presenting content such that it's readable as well as beautiful? I'd love to hear some opinions.

Follow us on twitter if you want us to keep you posted on our redesign process, or you simply enjoy our content.

When Closed to Open Sucks

Joshua Allen — Mon, 28 Sep 2009 21:50:12 GMT

A recent presentation by Ian Bicking got me thinking about closed versus open source software. Does software transformed from closed to open source suck? How do Mix Online's products, which are designed to be open source from the very beginning, fit into the picture? Is it possible to make great closed to open source software?

Here's the quote from Ian's recent DjangoCon keynote (via Simon):

There was this clamour in the past to get companies to open source their products. This has stopped, because all the software that got open source sucked. It’s just not very interesting to have a closed source program get open sourced. It doesn’t help anyone, because the way closed source software is created in a very different way than open source software. The result is a software base that just does not engage people in a way to make it a valid piece of software for further development.

In one way, Ian is right: our team creates open source software differently than we would if we were targeting closed source. But does this mean transforming software from closed to open source is doomed to failure?

When Closed to Open Rules

I think that Ian may be overstating the case. We all can easily think of closed source projects which would make great open source projects.

Take 37signals Basecamp, for example. Although it is closed source, Basecamp's source likely meets or exceeds open source standards for code organization and quality. And community developers find projects like Basecamp engaging.

Another example is the engine that runs stackoverflow.com. Like Basecamp, stackoverflow has attracted open source clones, a good indicator that folks find it compelling.

When Closed to Open Sucks

On the flip side, many closed source projects fail as open source. For most, this is not simply because they were "created in a very different way", as Ian says above. Rather, many closed to open source projects fail because the software isn't even compelling to the people who created it.

We call these projects "abandonware". Abandonware happens when a company decides to open source a dead project because they don't feel like supporting it anymore. No wonder the community tends not to rally around these projects.

Really, if a software scenario isn't engaging enough to attract open source interest, it's probably not very interesting as closed source. And if the code isn't maintainable by the community, it's probably too expensive for your closed source programmers to maintain as well.

What Do You Think?

Why do people choose one model over the other, and does it really make a big difference? Does your team build or use open source software? Leave a comment below, or follow us on Twitter.

The Ugliness of Real

Thomas Lewis — Sat, 26 Sep 2009 00:18:57 GMT

It always starts out as a friendly conversation. Developers or designers are discussing the language or tool of the week, when someone pulls out the “real programmers/designers use x” talk. The mood shifts. What was once a friendly little chat has become a chess game of defending the position.

Perspective

I see this attitude a lot when the discussion revolves around scripting languages—especially our good friend JavaScript. Apparently you are a 'real' programmer only when compiling from a language. In my opinion, it doesn't matter whether you're working with JavaScript, C++, Assembly, or whatever—even if you're scripting, you're a real programmer. Period.

The 'real' issue also rears its head whenever people discuss problem solving and workflow tools. There's an attitude that the more “to the metal” you are, the better. We've all heard someone say, “I don’t like to use x because I want to handcraft all my code.” Ugh.

Clients Are 'Real'

I don’t like the 'real' talk because it hinges on what tool you decide is best—not on what tool is best for the job. If a technology fits your needs but isn’t 'hardcore', so what? At the end of the day, what matters is whether the people you created your product or application for are satisfied. They don't care what you used to get there. This is what's 'real'.

Stop the Insanity

How about we stop bogarting love in our industry by helping and encouraging each other instead of pounding chests pontificating why X is better than Y? Or bickering over who is more real? And while we're at it, let’s stop adding to the link-bait madness and quit clicking on links to articles that promote rivalries that don’t really matter (and are actually unsubstantiated by the article anyway). Do we really need another “Technology Company Y Announces a Company Z’s product killer”?

What do you think? Is there a need to differentiate a real designer or real developer from others? In what ways we bogart love and spread negativity? Let me know in the comments below. Also, follow us on Twitter (or me, if you are a 'real' Twit).

My Top 3 Favorite Tools

Hans Hugli — Thu, 24 Sep 2009 01:54:15 GMT

Why do we use the tools we use? Most often, our choices are not simply based on how slick & perfect the tool in question is. Rather, we tend to choose tools based on how well they 1) enhance our productivity and 2) fit the specific technologies and projects we work with. Our concerns are practical. We want the right tool for the right job.

Track It.

Recently, a colleague showed me a tool (ManicTime) that lets you calculate your application and tool usage in a visual, analytic way. I used it to create a progress report that shows how I spend my time. Turns out that my top three applications are: 1) Visual Studio, 2) an email client, and 3) the browsers—in that order. I email more in the mornings use the browsers and VS toward the evenings.

Use ManicTime to track your usage patterns. What do you find? Which tools are you using most often, and when?

Tools That Fit.

Based on my test results, it looks like my top 3, favorite tools are:

* Visual Studio

* Outlook 2007

* Live Mesh (a service that allows you to manage and synch your files across a set of machines)

Why? These tools help me get stuff done. I am a dev, so I need my tools optimized for that. Outlook 2007 and Live Mesh allow me to get things done, without a fuss. They help me do my job better.

And as for Visual Studio: I work primarily with .NET for the majority of my career, and I need a tool—Visual Studio—that suits this platform. It's been indispensable (though virtually useless with Gestalt, which allows us to write Silverlight apps that do not need to be compiled by an IDE). Still, VS has become one of my most invaluable tools over the years.

What About You?

What are your top 3 favorite tools? Are they slick? Old-skool? I’d be interested whether you are a developer or a designer, or whatever your walk of life. Does your preferred tool provide productivity enhancements that make it indispensible? How are your tools suited to your job?

Do you have any tools that you can recommend to develop/design web content? Let us know by leaving a comment. And if you tweet, follow us on Twitter to learn about new content, opinions and articles.

Styleguides for web vs. events

Tim Aidlin — Mon, 21 Sep 2009 23:27:43 GMT

If you've ever created a styleguide that has to work for both web and print, you probably know how challenging it can be—print and web are very different mediums, with very different restrictions. When you create a styleguide that works for both, you do double duty.

Take the styleguide we created for PDC09. It had to work for online audiences who learn about the event via the website and had to take into account the posters, banners, registration booth, PowerPoint slides, and even the colors of the carpet in the “big room” where we host exhibitors at the site.

This made even basic choices difficult. Our designs had to account for the restrictions of the web: users’ operating systems, browsers, screen-resolutions, plug-ins, and bandwidth. But they also had to account for the restrictions of print: fonts had to be available to conference attendees and vendors who produce the material, not just for online audiences. Color palettes had to work in the corporeal world, not just online.

I'm curious whether you think there are huge differences in creating styleguides for web work versus print work. If so, what do you think those differences are? How do you get around the restrictions of the two mediums? Let us know below! And be sure to follow on Twitter at @mixonline to keep up-to-date with our latest opinions, labs, and experiments.

Design, Usability and Security Dilemmas With User Generated Content

Karsten Januszewski — Fri, 18 Sep 2009 17:32:29 GMT

Allowing users to add their content—feedback, reviews, expertise, etc.—to a web page is ubiquitous these days. Whether we're talking about comments on a blog post or wiki articles, user generated content is everywhere.

The mechanisms for dealing with this type of content, however, are hardly standardized. There are usually three approaches. Users can either:

Enter text, but not format
Add HTML directly to the comments
Use an alternative mark-up syntax

Each of these approaches has pros & cons. Here are just a few:

Approach #1—Text Only

Pro: Nobody can pollute the comments with awful images, formatting, or links.

Con: Nobody can enhance the comments with great images, formatting, or links. You can get around the hyperlink problem fairly easily (by converting http:// references into hyperlinks as the data exits the system), but this doesn't fix the formatting or images issue.

Approach #2—HTML

Pro: Users get a lot of power. They can customize pages, profiles, the whole bit. MySpace is an example of this. Some would argue that the success of MySpace is a result of their allowance of this behavior.

Con: First, there is a usability risk: you have to assume that users know HTML, or teach it to them on the fly. And then there's the design problem: allowing HTML means that users can do all kinds of crazy things—embedding images, adding Flash or Silverlight objects, inserting styles, running the banner tag. MySpace is an example of user-added HTML gone wild and, some would argue it is the “problem” with MySpace.

Another option is to allow a narrow subset of HTML. Just the <a> and the <strong> tag? Or more?

Allowing HTML as user generated comments opens up big security issues – read on for an in-depth discussion of this.

Approach #3—Alternative Mark-up Syntax (Aka the wiki way)

Pro: Wikis, which use their own syntax for formatting, are a perfect example. And, there are other syntaxes out there. The nice part of using one of these syntaxes is that you avoid some of the problems with HTML, as far as security and license to do ill.

Con: Users are forced to learn a new language. And there are lots of languages out there: Textile, Markdown, Markdown with Smarty Pants, Multimarkdown, etc. Heck, Mix Online supports comments written with the Textile syntax and implemented through the by using a library from Codeplex called Textile.NET, though we never tell you in the comment form. (Maybe that’s coming in version 2 – ask Nishant.) In fact, try adding a comment to Mix Online and use the Textile format – you’ll see it works.

It's All a Security Problem

No matter which approach you take, there is one big Universal Con to opening your doors to user generated content: security. User generated content makes all kinds of attacks possible—from SQL Injection to cross site scripting to who knows what.

Some of the worry goes away with ASP.NET, because it has an attribute (validateRequest) that can prevent someone from inserting malicious content. But, if you want allow HTML, you’ll have to turn validateRequest off, which is turned on by default. That means you have to write your own validation as data enters the system.

With validateRequest or your own home rolled solution, we are talking about checking data as it enters the system. What if something does slip through?

A more thorough procedure for the paranoid among us is to sanitize the data as it leaves the system as well. You can do this manually by encoding all output (HTMLEncode(), UrlEncode(), etc.). Or, in ASP.NET, you can pass all data through the Anti-Cross Site Scripting library (originally from the Microsoft Patterns and Practices group). Implementing this library is easy and I highly recommend it. You’ll notice the recent version of Oxite does just this.

What Do You Think?

I leave you on an inconclusive note. All three approaches have pros/cons, and none is necessarily right. So I’m curious: which approaches do you take as web developers? Which do you prefer as users? Let us know in the comments – formatted with Textile if you’d like -- or on Twitter.

Screen Savers Are (Still) Cool

Karsten Januszewski — Fri, 18 Sep 2009 00:11:00 GMT

I have, do and always will love screen savers. They are, to me, an essential part of the PC experience. The basic idea of having your PC “do” something when it isn’t in use makes total sense. What other appliance in your house/office actually does something when you aren’t actively using it? Most machines just sit idle, waiting to be used. Not a PC: it can actually do something while not “being used.”

The classic example of sharing your idle CPU cycles is SETI@home. I believe they were the first to tap into massive distributed compute power to try to solve a problem. Since then, there have been numerous other examples that use this technique.

But screen savers haven’t always been and still aren’t always so “noble.” Take for example the classic After Dark Flying Toaster screen saver. Don’t remember that one? YouTube to the rescue:

And also who could forget the aquarium screen saver?

Or for the sci fi folks, there was (is) the Matrix screen saver.

Probably the most common screen savers nowadays are very Web 2.0: screen savers of your own photos. And why not? What better use for the hundreds of digital photos that normally lie as dormant as the drawer full of photo albums? Or, to be really Web 2.0, use this Flickr screensaver from Codeplex and pull photos from the web.

Personally, I run a screen saver called Cellular Automata for Electric Power simulation (CAPOW) by one of my heroes, Rudy Rucker. (If you aren’t familiar with Rudy Rucker, he’s worth checking out – brilliant mathematician, computer scientist and science fiction writer. And his blog rules.) You can read all about cellular automata but know this: they look really cool! You can download the application, source code and screensaver here. People are always walking by my office and asking where I got my screen saver. Here’s some screenshots:

One final thought on screen savers: why not build your own? This project up on codeproject is quite good for getting started. This WPF one is good too and has a Visual Studio template to get you started, which you could then open in Blend.

Is Irrational the New Rational?

Nishant Kothary — Wed, 16 Sep 2009 00:49:09 GMT

The idea that people make consistently logical choices has always befuddled me. Because honestly, it seems that evidence to the contrary is all around us.

Ori and Rom Brafman's book Sway: The Irresistible Pull of Irrational Behavior, which I picked up a few weeks ago, confirms my thinking. By the time I reached the book's halfway point, I had startling insights into previously unexplainable aspects of my personal and professional life: why some coworkers are so "emotional," why a certain manager is illogical about one particular thing, why so many people hate Microsoft, & why my mother won't ever take my advice about her diet.

Dan Ariely's Predictably Irrational, which I am currently reading, is a meat & potatoes version of Sway. Ariely, a behavioral economist, gives insights into human nature that promise to change how you build products and behave within your organization.

Case studies and lab studies in both books reveal ways in which irrational behavior is, in fact, quite typical.

Groupthink

In one case, individual X was invited to participate in a study and taken into a room filled with other participants. What participant X didn't know was that his fellow participants were paid actors.

The study began with a simple task: the lab instructor asked X to pick out the longest of three straight lines on a piece of paper (one line was unquestionably longer, so the answer was obvious). One by one, the paid actors answered out loud. And every time, much to X's growing disdain and confusion, the actors picked the wrong line.

So what do you think X picked? Yep, you guessed it: he picked the same wrong answer that the actors gave. Despite knowing better.

Relative Thinking

In Predictably Irrational, Ariely talks about how humans tend to think relatively. He shows that we generally don't know the intrinsic value of something; we only know its value in relation to something else. An example is purchasing a house. Choosing between a colonial and a craftsman, for instance, is very difficult because we have no basis for comparison. However, throw in a second colonial that's slightly better than the first one (called the "decoy") and we generally perceive the second colonial as superior not only to the first one, but also the craftsman.

Predicting Irrationality

Sounds crazy, but is it really so unusual? Haven't we all been in a room where the vocal minority ends up swaying a vote at the last minute? Haven't we all bought something we didn't really want because we perceived the alternatives as inferior in comparison?

Natural marketers, salesmen and even pick-up artists have instinctually capitalized on our predictably irrational nature. Using a "decoy," for example, is a classic tactic that many a lady friend of mine has confessed to using: when single women go out with the intention of meeting a guy in a pub, for example, they sometimes invite along another woman ("decoy") who is comparable but slightly inferior to them in terms of attractiveness. Why? It helps convince potential mates of the "better" pick.

The New Emotional Design

The insights of behavioral economics are supremely important to most anyone who works with human beings, and especially those of us who work in fields with a "subjective" element (like design). These insights equip you with the background you need to understand and combat situations where smart people exhibit irrational behavior in a predictable manner (e.g. knee-jerk reactions in design review meetings from one or a set of individuals).

Predictably Irrational is a bible for any designer who works as a part of a bigger organization. I can comfortably say it's the best "book on design" I've read in the past few years. Donald Norman's got nothing on Dan Ariely. OK, maybe I'm being hyperbolic, but seriously, go get the book. If it doesn't change your thinking, I'll buy you a drink.

Have you faced situations where you cock your head to the side wondering why everyone around you is acting slightly crazy? Have you read about behavioral economics? Is it your trade? We'd love to hear your thoughts on the topic. Feel free to follow us on twitter if you liked this post, and we'll notify you of future ones.

Web Tribal Wars

Joshua Allen — Mon, 14 Sep 2009 18:34:26 GMT

People have used conflict as a storytelling device since the beginning of time. Many world religions describe the history of the cosmos as an ongoing conflict between two forces, for example. And in our personal lives, we often frame situations in terms of opposing forces. Joining a political party, cultural movement, or taking sides in an industry debate makes us feel that we are participants in a larger drama. It gives us motivation and meaning—especially if the conflict is ongoing and not easily settled.

As web developers and designers, we have plenty of stories to choose from. It seems that some debates will never die, and masses of web professionals join the battles with gusto. Here are a handful of my favorites:

Grid vs. Organic Layout – Few people today remember that HTML tables were originally intended to be a layout mechanism (sacrilege!). For most of recent history, web developers have instead preferred flow or positional layout designs, while print developers have used grids. No longer! Grid designs for web design are here to stay, and have articulate and talented defenders.
Robust vs. Draconian Error Handling – This is one of my favorites. Should tools like web browsers and web servers accept malformed content (Postel’s Robustness Principle)? Or should they fail miserably on the first error (Draconian Error Handling)? HTML settled on one strategy, XML the other. Both camps will convince you that the opposing system is a slippery slope to world collapse, and I think they both may be right.
XML vs. JSON – It’s the year 2009, but people still get sensitive about their data serialization formats.
Push vs. Pull – The Web is essentially a “pull” architecture, where you have to send a request to the server every time you want a web page. But that doesn’t stop people from resurrecting the “push” idea every couple of years. “Push” is like instant messaging, where the message gets pushed to you whether you asked for it or not. My first memory of this was when Pointcast launched in 1996, and the press became convinced that it would replace the Web. Neither pure push nor pull is ideal, so the topic keeps coming up. On the Web, we have Comet, as well as the recent discussion around “fat ping”.
Functional vs. Imperative – This is a programming geek’s debate, but invades the Web space periodically. Functional programming treats programs like math problems, while imperative programming treats programs like recipes. Since programs are rarely math problems, most code is imperative – but many people like the “elegance” of the functional style. XSLT was designed for functional thinkers, and JavaScript gained new credibility when people like Doug Crockford showed that JavaScript is more functional than imperative.
Red Bull vs. Mountain Dew – Even when it comes to wearing out our adrenal glands, we like to take sides.

Now it’s your turn. Which key battles am I missing? What are your favorites? Share your thoughts here, and make sure to follow us on twitter.

20 Things That Annoy Me

Thomas Lewis — Fri, 11 Sep 2009 20:15:36 GMT

I don't want to go on a rant, but hey—here's the shortlist of things that still annoy me about the Web:

Filler. That white space is there for a reason.
Having to click 40 times to view an entire article, just so someone can fill ad inventory.
Social media insanity. No, social media does not solve every problem. It won't clean your room or make you dinner.
Pop-under windows. They are never good. I repeat: never good.
Blog posts that showcase “945 tools you can use to build X”.
Fold obsession. Stop telling me everything needs to be above the fold.
New technology worship. Your technology is not better just because it's new. Show me amazing things I can build.
Siren Twitterers. No, I won’t follow you on Twitter just because you follow over 5,000 people and your avatar is seductive.
Choice-a-holics. I prefer 3 choices, not 100.
That guy who keeps spilling coffee all over the kitchen. I'm on to you.
Spammers. If you spam me, I'll be glad to meet you at my local Fight Club.
Partypoopers. Here's some advice: If you're at a party with normal people (i.e. not techies), don’t mention “in the cloud” or name-drop "social media experts”.
App-a-holics. No, there is not an app for that.
Soothsayers. Stop telling me that “x is dead"! I really like x!
People who ask me for a time estimate when they already have a due date in mind.
Tweet-hating. If you say to me, “I don’t get Twitter! Why do I care what someone had for lunch?!” then you are right. You don’t get Twitter.
Apps imitating life. I don’t want to simulate real life in an app! I have a real life for that.
People who ask, “Hey, can your designers make my PowerPoint presentation sexy?” Don't ask me that. My designers will eat your face.
No snacks. If you have to complain about something on the site, can you at least bring me an Orange Crush or Moon Pie?
Lists that go on way too long…

So what about the Web annoys you? Clients? Bloggers? Social Media? Commenters? Blog posts that are just a bunch of complaints? Share your grievances in the comments below. Also, follow us on Twitter or me for more of my rants.

Where's My Web Form Content?!

Hans Hugli — Wed, 09 Sep 2009 18:21:36 GMT

You know the deal. You compose a letter in a browser. Your hand slips. You accidentally hit the backspace key or move to a new page. An error occurs, or your browser crashes. Your brilliant letter is lost forever.

IE and Chrome have built-in support to prevent this scenario, but you can still lose your content, depending on what site you visit. Take Basecamp and Facebook. I did a quick test and found that Basecamp worked with IE and Chrome, but Facebook worked only with Chrome.

Judging from the above, one might jump to the conclusion that IE is inferior. Or perhaps the Facebook application was simply not tested thoroughly in IE. Or maybe the page load event fires off some javascript that creates textboxes and adds them to the DOM on the fly, overwriting any pre-existing textboxes residing in the DOM. Who knows.

The bottom line? We're not doing a great job testing apps—especially email and web form web-apps—across browsers. This leads to a poor user experience, diminished productivity, and general frustration.

Developers: I'd like to call on you to fix this all-too-common problem. Here's a quick way to test your app:

Visit any website
Browse to a page with a textbox or web form.
Type something there.
Click the back arrow on the browser chrome or press the backspace key.
Navigate back to the page with the textbox by clicking the forward arrow on the browser chrome.
Does the text that you originally typed remain? It should. If it doesn't, there is work to do.

Testing across browsers might be tedious, but it's well worth the effort.

Do you have a "lost web form content" horror story? Have you learned to accept this situation as "the way of the web"? Let us know by leaving a comment. And if you tweet, follow us on Twitter to learn about new content, opinions and articles.

From Web, to Real World

Tim Aidlin — Tue, 08 Sep 2009 20:47:56 GMT

Real World Meets Web.

Back in college, when I cut my teeth doing graphic design for a literary magazine, the web was just emerging. With the boom right around the corner, everyone started talking about bringing their physical presence "online." When I took to migrating the magazine from print to web, it seemed obvious that "web design" was the obvious next step.

It was also an exciting new frontier. Gone were the restrictions and hassles of print: the permanence, the cost, the stupid 3 AM press checks where my only role was to say, “increase the cyan by 15% and correct the registration on the varnish.”

I could do whatever I wanted when building a website, and for the low price of web hosting and an internet connection at home. I could make pages really long, or really wide. And if I found a misspelling, I could go back and change it.

Web Meets Real World.

These days, though, I find “online” creeping back into the print and physical world. Fray.com, for example, has started a print version of its long-standing website, making the content available in book form. They've done a great job with their first edition, Busted, which delivers fresh stuff that compliments their web presence without directly replicating it.

MIX Online’s A Website Named Desire poster is another example of this trend. It utilizes 1980’s-style 8-bit pixel art to show the inner workings of an agency that builds websites. What's even more meta? We built a Deep Zoom web-experience of the poster for people to enjoy online.

We also recently commissioned a design agency to re-envision the MIX Online site as a notebook. We surprised a few of our friends and contributors with a copy and received some very flattering comments in return.

A few final, cozy examples of the web spilling into the real world are the super-cute, ultra-nerdy pillows you can find on websites such as Etsy.com.

There are lots of other examples out there, I know — graffiti, art, all sorts of stuff. Have you stumbled across anything where the web and real world converge? Was it awesome or ridiculous? Tell us about things you stumble upon by leaving a comment below, or following us on Twitter at @mixonline.

We're Redesigning MIX Online, By Design

Nishant Kothary — Wed, 02 Sep 2009 22:06:35 GMT

When we launched MIX Online a year ago, we didn't expect that the initial design would be around forever. Our main goals were to test the site's market viability and discover what worked and what didn't — we knew we'd be ready for a redesign within the first year.

We've learned much about our community and business since launch, and we're excited to present MIX Online in a very different way going forward.

So, what changes should you expect? Glad you asked.

A Better Information Architecture

As it stands, MIX Online is designed around the notion of "issues" (similar to magazine issues). Each issue involves a scenario such as Microformats or Data Visualization, and consists of an open-sourced lab and two articles written by industry experts. We're moving away from this approach.

In the new design, we'll let articles and opinions flow freely and give them adequate real estate. We'll also clarify the relationship between our site and the annual MIX Conference web site (they're different!), which has been confusing to some readers. You'll see a better overall grid, a more flexible layout for articles, organization of the lab section, common chrome, and more.

The short story? Better IA across the board.

Colors that Play Well Together

The color of the current design is its most applauded, and most criticized, element. Some people love the color schemes; others point out that the site is difficult to read — either because our colors don't downgrade well in low battery situations or on older displays, or because of general contrast issues.

Nailing color harmony across the site to maximize readability and viewing pleasure is one of our topmost goals for the redesign.

Easy-to-Read Typography

While color plays a big part in making content readable, the key to excelling in this area is the application of sound typographic principles; some even say that Web Design is 95% Typography.

The current design uses strong typographic grids, adequate leading, variances in level headings, and so on — but there's always room for improvement. With the redesign, we'll adhere strictly to a predictable vertical rhythm and aim for larger type, better contrast, appropriate use of different typefaces, better font stacks, and possibly sIFR.

Maintainable & Extensible Code

We built the site on a shoestring budget last year, and one of the unfortunate side effects was a shaky transition from design to code. As I've mentioned in a few presentations (skip to 42m45s), the markup and CSS delivered to us by the agency we hired was pretty bad.

The ultimate success of a web site relies on the quality, maintainability and extensibility of its markup and CSS. Good code makes updating the site and introducing new features — something that is very tedious now — natural and easy.

With the new release, we hope to get a codebase that finally puts redundant and overly-specific classes, divitis, gratuitous use of non-semantic markup, and other gag-inducing markup faux pas to rest, once and for all.

What Would You Like to See?

So, that's the gist of what we're planning right now. Keep in mind that these are preliminary thoughts that will likely evolve as we get deeper into the redesign process. We'll keep you posted on how things go, but in the meantime, what are your thoughts? Are we targeting the right areas? Got any features/suggestions that you want to share? Feel free to give us your feedback through twitter, too.

The HTML5 Semantics Debate

Joshua Allen — Mon, 31 Aug 2009 18:46:42 GMT

If you've been following the development of the new HTML5 specification, you're probably familiar with the demo-friendly new features like Canvas, Drag-Drop, and the Video tag. But unless you're a microformats or semantic web geek like we are, you may have missed the new "semantic" tags in HTML5.

Last I looked, the HTML5 draft proposed 24 new HTML tags, ranging from <nav> and <footer> to <article> and <time>. As you can guess, these new tags are used to mark up things like navigation links, footers, articles, and units of time. In HTML5, you would use one of these new tags, instead of the traditional technique of class="nav", and apply your CSS styles to the new elements. Other than your markup looking a little different (with fewer class attributes), everything works the same as before.

Boring, right? Still, these new tags have prompted a healthy debate. I’ll summarize the common positions in the debate, and then offer my own opinion. The common concerns fall broadly into three categories:

Tags are Too Final

Some suggest that the new tags were poorly researched. No formal field research, ethnographic interviews, or anything else you might expect. In essence, someone queried a few Google indexes for common web developer practices, and decided to invent new tags for what people were already doing. Yes, that’s pretty much how it happened.

An HTML tag is the most fundamental unit of the language. A tag is about as solid and final as it gets. Should these new semantics be codified as top-level HTML tags? Or would it be smarter to use a mechanism which could adapt to the way people use the web in the future?

John Allsopp articulates this position and offers some alternative approaches in his article on HTML5 semantics.

Extensibility is Ideal

Most people are willing to compromise on the existence of new top-level tags. I mean, HTML already contains a bunch of tags we routinely ignore, so what’s a few more? However, many still argue that extensibility is ideal, or even a must-have.

What do we do when common web development practice changes, and doesn’t exactly match the patterns that the HTML5 drafting committee supposed? Do we need to spin up a completely new standards process, or will there be an easy extensibility mechanism that doesn’t involve hacks and “convention”?

Jeffrey Zeldman approximates this “middle of the road” position, especially in the comments thread here.

Do Tags Right

Finally, there are those who think the overall approach is just fine, and simply want to make sure that the new tags are defined properly. They may disagree about which tags should be added, and vary in their assessments of the spec ambiguities, but they think that inventing new tags is a good idea in general. And they are reasonably confident that the spec can be versioned in the future, when practices change. They argue that the best strategy is to get involved in the process, to specify tags in a clear and useful way.

Jeremy Keith approximates this position in his post from today.

My Opinion

Out of the three broad categories we’ve discussed, which one makes the most sense to me? As fascinating as this discussion has been, I’m afraid that I have to cop-out by saying “none of them”, and “all of them”.

The purist in me sympathizes with the “tags are too final” assessment. But the web is nothing but a huge, glorious collection of hacks anyway. This place is harsh to perfectionists.

On the other hand, the web’s chaotic nature is no excuse for sloppy, haphazard design. It would certainly be nice to see more effort here.

And ultimately, what happens in the spec may matter a lot less than we currently think. As John’s article points out, there are three “extensibility” mechanisms already supported by existing web browsers today: authors can use the class attribute (as microformats do), invent new attributes, or even invent new top-level tags. We already ignore the <address> tag in favor of a microformats class convention -- and HTML5 can’t fix this anyway. My prediction is that web developers will continue to use a mix of techniques to express semantics.

More importantly, semantics are only important when they’re understood and used by specialized user agents or search tools. Do we imagine that calendar import of embedded <time> tags will suddenly become a killer feature of user agents, when microformats have been available for years? Will browsers resurrect the old and abandoned in-chrome site-tree features, and tie them only to <nav> tags, encouraging web developers to abandon their existing techniques en masse? We’ll see. Once again, I predict that the techniques for expressing semantics will become more diverse, not simpler.

So what do you think? Join the discussion below, or send us a comment on Twitter.