Tag: design

Posted on
by

Forget Ashton Kutcher and Oprah, forget #unfollowfriday, forget 25 Random Evil Things about Twitter — the key problems with the social media / microblogging / broadcast IM / whatever you want to call it service boil down to two problems:

  1. It asks the wrong question
  2. It was designed around limitations of cell phone text messaging

The Wrong Question

Twitter’s prompt is not something general like “What’s on your mind?” It’s “What are you doing?” That encourages people to post things like “I’m eating lunch” or “Just got into work,” or “Posting on Twitter.” Presumably what they mean is “What are you doing that you think people would find interesting?” but of course that’s too long a prompt from a usability standpoint.

The thing is, there’s no reason to broadcast the mundane to the world. Don’t tell me “I’m eating soup.” Tell me, “Just learned that gazpacho soup is best served cold. I wonder if they eat it in space?”

Unfortunately, that means the signal-to-noise ratio can get pretty bad at times.

Outgrowing its Limitations

Twitter posts are limited to 140 characters of plain text so that the your name and comments can fit in a standard SMS message. Now, this is great if you use Twitter via text messages on your mobile phone. It’s not so great if you use Twitter on the web, or through a smartphone app like Twitterific on iPhone or Twidroid on Android, or through any of the zillions of desktop apps.

I don’t have a problem with the 140-character limit itself (it can actually be liberating in a way), though it would be nice to have some formatting options beyond all-caps and *asterisk bolding*.

The real problem is that links have to share that limit. URL-shortening services have exploded lately as people try to squeeze links into the tiniest space possible to save room for their precious text. Even if you use something as short as is.gd, just including one link means you’re down to 122 characters.

Plus URL shorteners come with a host of problems, in particular the fact that they hide the destination. That’s no big deal if the target matches the description, or if it’s a harmless prank like a Rick Roll, but it’s all too easy to disguise something malicious.

Seriously, if you got an email that said something like this:

Look at this! http://example.com/asdjh

Would you click on that link? Even if it appeared to be from someone you know? That’s just asking to get your computer infected by a virus, trojan horse or other piece of malware. Or to see something you wish you could unsee.

Better Link Sharing: Facebook

I hesitate to bring up Facebook as a good example of anything, and I know the current layout is largely reviled by its users, but they really got posting links right.

When you want to post a link to your Facebook profile, you paste in the full URL. Facebook reads the page and extracts the title, a short summary, and possible thumbnail images. Then you have the normal amount of space to write your comment. Continue reading →

Posted on
by

Overly-cute fox with puppy-dog eyes, captioned: Please don’t hurt the web. Use open standardsThe Mozilla Developer Center has just posted some desktop wallpaper promoting open standards, (and the MDC itself) with the theme, “Please don’t hurt the web. Use open standards.”

Apparently the design was a big hit as a poster at SXSW.

For those who haven’t seen it, the MDC is a great developer resource for web developers, describing lots of standards along with Mozilla-specific information.

(via Rhian @ SFX, who notes that the image is available for use under the terms of the Creative Commons Attribution-NonCommercial license. These wallpapers are also covered by the Mozilla Trademark Policy.)

Posted on
by

When web designers switch from focusing on a single browser (usually Internet Explorer) to developing cross-browser sites (usually adding Firefox, sometimes Opera or Safari, ideally all three), they often find that things don’t work as expected in the “new” browser. This can be for a number of reasons, including:

  • Bugs or “missing” features in the new browser (whether incomplete support in the new browser, or proprietary features in the familiar browser).
  • Broken code on the website being handled differently.
  • Different defaults where behavior isn’t well-defined in the specifications.

A big problem is that when you get into the code, a lot of pages aren’t as specific as the authors think they are. When you write code and test it on one browser, you’re not testing that the code is correct, you’re testing that that browser makes the same assumptions you do.

It’s like ordering pizza.

No, really. Let’s say Internet Explorer specializes in Chicago-style pizza, with a thick, chewy crust. And let’s say Firefox specializes in New York-style pizza, with a thin crust. But each can make the other style of pizza on request.

So you call up Internet Explorer and ask for pizza. They deliver you Chicago pizza, and if that’s what you wanted, you figure your order is fine. If you actually wanted New York style, you make sure that next time, you tell them you want that style of pizza.

But let’s say you like Chicago pizza. You get used to calling up IE and just asking for “pizza,” until one day you’re busy, and ask your roommate to order it. He likes to get his pizza from Firefox, so he calls them up, asks for “pizza,” and you get New York style. That’s not what you wanted. Obviously, Firefox pizza is inferior, because they got the order wrong! Well, no, it’s not, and no, they didn’t. They delivered what they were asked for. If you’d told your roommate to ask for Chicago style, Firefox would have been perfectly happy to deliver that style of pizza.

The moral of the story: always be specific with your code. Make sure it’s asking for what you think it’s asking for (validation helps here). And if something doesn’t do what you expect, make sure you didn’t leave that expectation out of your order.

See also: No, Internet Explorer did not handle it properly

(Expanded from a comment I posted at Mozillazine.)

Posted on
by

I just read an interesting post from Microsoft’s Internet Explorer team on The IE7 User-Agent String. This statement in particular illustrates a problem not unfamiliar to Opera users:

There are a few remaining sites which fail to recognize IE7 because they are performing exact string matches to look for specific IE version strings. Those checks will need to be removed or updated to accommodate IE7.

Yes, you read that correctly: there are websites out there using bad browser sniffing code which will send the wrong code to Internet Explorer 7. In fact, they go on to say that they’ve released a tool which will let IE7 pretend to be IE6!

To enable you to workaround any remaining sites that block access to Internet Explorer 7, we developed the User Agent String Utility. The utility comes in the form of a small executable that opens an IE7 instance that sends the IE6 user agent string. It also provides a mechanism for you to report problem web sites to Microsoft so that we can follow up with the affected site owners.

I’ll admit to a certain amount of schadenfreude, but it also points up just how bad a strategy browser sniffing can be when done thoughtlessly: It effectively builds an expiration date into your website after which even the browser you designed it for will run into problems.

*This post originally appeared on Confessions of a Web Developer, my blog at the My Opera community.