13153115113

Posts tagged writing

Cars

Posted January 10, 2012 @ 9:37 am

Listening to NPR on the way to work this morning, two auto-industry guys were talking about the car-related tech being unveiled at CES. More access to social networks. Entertainment. Connectivity. These are the things that are going to, as one of them put it, turn cars into smart cars in the same way that mobile phones transitioned to smart phones.

Bullshit.

Cars are for transportation, and transportation is inherently unsafe. Human error coupled with 2,000 lbs. of metal and plastic moving with a tremendous amount of momentum is dangerous enough that I can hardly believe people find it an acceptable risk. But for some reason, these hurtling, oversized pinballs need Facebook and apps and TV screens?

The only sea-change in automotive technology will occur when the car ceases to be necessary. Until then, adding Twitter to someone’s dashboard is going to do nothing but cause more accidents. It’s bad enough to distract drivers with useless navel gazing, but when you couple that with the traditional UX anti-patterns that most car designers follow, you’re entering a world of pain.

The solution to traffic and the awfulness of being locked inside a vehicle while commuting can’t and shouldn’t be solved by finding myriad ways to distract ourselves from the fact that we’re wasting hours of our lives staring at tail lights while being subjected to the dangerous, often angry, selfish behavior of others. Traffic, as a problem, should be solved by eliminating traffic. Strike at the head, three more grow back; strike at the heart, and you’ve got a chance at killing the beast.

Cars need to die. They—like the dumb phones that came before the iPhone—need to be done away with in favor of something so superior that no one can imagine going back to what we had before. That’s not an electric car. It’s not a car with three televisions in it. It may not even be a car that drives itself from place to place.

To be clear: the iPhone and phones that have followed in its footsteps are not phones—they’re full-blown computers. It’s a total rethinking of how we approach mobile communication. In the same way, the thing that up-ends the car industry won’t be a car with more features. It’ll be something completely different.

1 month ago  ∞  1 note  ∞  short link

Tiny Fiefdoms, Fad Diets, and Making Good Stuff

Posted December 9, 2011 @ 11:35 am

The Web’s full of tiny fiefdoms. Web standards, content strategy, information architecture, user experience design, responsive design, usability, user research, test-driven development, behavior-driven development, mobile-first development, interaction design, agile, extreme programming.

They’re easy to identify. Look for a buzz-wordy label that encapsulates a small portion of what’s involved in building software (for the Web or otherwise). Find the purveyor of that label. Look at his or her inner circle; they’ll likely be espousing the same strategy and frequently congratulating each other on ever-so-minor successes. You’ll see them speaking at the same conferences, often presenting the same undifferentiated talks every time. Observe how many people follow this group on Twitter and how many of them subscribe to the methodologies of the purveyor. Congratulations; you’ve found a fiefdom.

Not all of them are bad. Luke Wroblewski’s mobile-first approach is smart. Having seen him talk, I can tell you that he’s a bright guy with some great ideas. But best of all: Luke doesn’t sit on his hands. He’s constantly absorbing new data, refining his thoughts on the subject, and trying to help people make their way in the strange, claustrophobic new world of mobile development. And he does a lot of this for free through his blog, which—to my mind—shows that he cares immensely about the message.

Luke’s an aberration, though. Most fiefdoms are like fad diets. They’re flash-in-the-pan ideas that work for some people. But fad diets work because—possibly for the first time—the practitioner is paying attention to what he or she eats. It’s not magic; it’s attention and care.

The best thing that can happen to a fad dieter is that he or she walks away from the experience with a better appreciation for nutrition. Similarly, the best thing that can happen to a follower of one of these software development methodologies or business practices is that he or she walks away with a better understanding of the common sense principles involved in making a solid product.

Sadly, some fad diets have no science behind them, no substance, which means you can’t learn anything. Likewise, some tiny Web fiefdoms are led by charlatans, many of whom are very lazy.

But here’s the thing: you don’t need fad diets, and you don’t need buzz words or a fancy label or marketing spin or the promise of easy or whole conferences devoted to something something writing microcopy blah blah to understand what’s necessary to make a good product. You don’t need a champion. You don’t need a team of experts.

At least one company seems to be getting this right. I watched a presentation earlier this week by Zach Holman about how the people at GitHub—developers, designers, everyone—build their product. It couldn’t be simpler.

They don’t use some technique that has a service mark attached to it. They focus on the details, and they care a lot about what they’re building. Period. And they ship a lot of code. Often. Probably more (and more frequently) than me, you, your company, your friend’s startup. And judging by what Zach said, a lot of this is because they trust each other to do their best work. GitHub is proof that trust, coupled with a lightweight branch-pull-deploy workflow, can lead to amazing, profitable software. But what struck me is that a lot of what they do is plain common sense, and their methods grew organically out of the culture of the company.

They didn’t need a consultant to tell them this. You don’t need a consultant, either.

The next time you hear someone prattling on about Behavior Driven Content Testing with Waterfall Methodologies for Agile, Responsive Design, do yourself a favor, step back, and evaluate what he or she is pitching. Here are some questions for your bullshit filter:

Personally, I’m going the safer route by ditching all of this stuff. I’ve fallen for pitches in the past, for ideologies that sounded fantastic. I even went so far as to call myself a user experience designer for a while. Truth is, though, I’m just a developer who makes software. I make it with attention to detail, a helluva lot of thought about how users will interact with it, and immense care about the finished product. But I don’t need a fancy title to point that out. My work should do that. And I’d rather spend time making things that demonstrate what I’m capable of than palling around with a bunch of thought leaders on some social network.

Fuck buzz words. To hell with fiefdoms. Sweat every pixel; care about your users. Make something good.

2 months ago  ∞  1 note  ∞  short link

Personal Interests

Posted November 7, 2011 @ 11:37 pm

In November of last year, I posted a thing about my Instapaper account. It included this picture and the following description:

Coincidentally, the set of folders that grew organically out of the stuff I’ve been saving to Instapaper over the years is probably the best taxonomy for my varying personal interests that I’ve ever managed to develop.

Since I wrote that, I’ve only become more circumspect about what goes into that list of personal interests. It’s become somewhat sacred, and I’ve started using it as a system of organization in a few other places (e.g., iBooks).

Recently, though, I added a new folder.

Mir and I are having a baby. I’m going to be a dad.

3 months ago  ∞  1 note  ∞  short link

Stewardship

Posted October 3, 2011 @ 12:21 pm

On Saturday, I finally paid for a Typekit account. You’re looking at the result of that purchase. The fonts used on this site are being served up by Typekit’s servers. Pretty, right?

Today, I’m debating asking for my money back and shutting down the account. Why?

Just a few moments ago, Adobe’s CTO Kevin Lynch took the stage at their annual MAX conference and explained the company’s Creative Cloud strategy. Part of that announcement is very big news for us: Typekit has been acquired by Adobe.

God. Fucking. Dammit.

Next Verse, Same As The First

This scene plays out over and over again.

  1. VCs fund a startup.
  2. Startup creates a product.
  3. Startup attracts users.
  4. Startup sells to some mega-corporation for tons of money.
  5. Mega-corporation lets the startup’s technology wither and die.

We’re at step 4 in Typekit’s story. The sad thing is, I really believed they were in it for the long haul, what with Jeffrey Veen talking about how the point of starting his own company was to ensure he’d always have a seat at the decision-making table.

Step 5 isn’t always a guarantee. Whether it comes to pass depends on the ability of the mega-corporation to be a good steward, to continue to steer the product or service in a forward direction. Most of the time, this never happens because either the company doesn’t care enough (see Cisco’s buyout of Flip), because the purchase was a talent acquisition (see Facebook’s purchase of Drop.io), or because the smaller company was a direct (and successful) competitor to the mega-corporation.

Typekit is a successful competitor to Adobe. I don’t suspect this buy-out is going to go well for Typekit’s users because Adobe will likely be a poor steward. They have no reason to push this product forward, as that would mean promoting other type foundries.

Typekit’s team is convinced that this won’t happen, though.

Ask Michael Arrington how long “business as usual” lasted after TechCrunch was sold to AOL. (Spoiler: it took about a year for Arrington to be ousted and for the team to disintegrate even after AOL promised he would retain creative control.)

As a paying user of Typekit, I’m concerned that the product will suffer from poor stewardship under Adobe. As a person who purposely avoids purchasing Adobe products, I feel duped into tangentially giving them my money. And as a person who respects the company’s founders, I feel a bit like I’ve had the rug pulled out from under me—I expected better.

The only people who stand to walk away from this without a shred of doubt or trepidation would be the folks at True Ventures. Congrats to them on a successful exit, and thanks for giving hope to the next guy-with-an-idea that he, too, can one day leave his users stranded while making a fuck-ton of cash.

4 months ago  ∞  1 note  ∞  short link

The Modern Web Developer

Posted September 28, 2011 @ 11:53 am

Let’s take it as read that a modern Web developer should focus on using technologies that were introduced during the last two years. With that in mind, here’s a quick (though not exhaustive) overview of the browsers and display resolutions that a modern Web developer would consider supporting.

Desktop Browsers

Mobile Browsers

iOS Display Resolutions

Android Display Resolutions

Typical Desktop Display Resolutions

Overview

A Dose of Realism

This is an untenable situation. Even if you decide not to support Opera—which a lot of developers tend to do—you’re still looking at 7 browsers and 21 versions. And you’re still going to have to deal with all of those screen resolutions if you’re interested in your site looking good on the majority of phones and tablets. I hope you’ve caught up on responsive design.

Those browsers and resolutions represent an awful lot of testing that we’re being forced to do because we have no control—no input, even—into the development process of browsers and devices.

When I started to write this article, I knew the situation was bad. I didn’t realize it was this bad.

“I’m talking about drawing a line in the sand, Dude. Across this line, you DO NOT…”

I think it’s time that Web developers stopped letting browser and device vendors dictate the shape and focus of our work. Today, Amazon’s introducing yet another tablet—the Kindle Fire—with yet another Webkit fork. The tablet’s going to sell well; there’s little doubt of that. This concerns me for two reasons:

  1. How often will Amazon update its proprietary browser to keep up with standards?
  2. The tablet’s resolution is a bit of an oddball size at 1024x600.

About ten years ago, my wife—who wasn’t my wife at the time—told me something that’s only become more true as I’ve aged: as you get older, you have to pick your battles.

I’m getting older. You’re getting older. The Web’s getting older. At what point do we decide that we’re done trying to support all of these browsers and resolutions and devices? Where’s our line in the sand?

Personally, I’m tired of spending time coding for specific use cases instead of making websites. The focus has been lost, and the work is far more tedious and a helluva lot less interesting.

Not every browser is worth coding for, nor is every device.

  1. There are at least 15 resolutions. The desktop resolutions listed above only cover about 66% of Internet users. ↩

4 months ago  ∞  short link

On Netflix and Qwikster

Posted September 26, 2011 @ 11:38 am

A quick overview:

It’s no surprise that these broadband/cable TV providers have been slowly constricting the amount of bandwidth users have for doing things like streaming media from companies like Netflix and YouTube. It’s clearly anti-competitive, and it puts Netflix’s business model in jeopardy. They’ve been betting on streaming for a while despite the reaction from broadband providers.

Here’s a thought: As long as Netflix continues to operate as a business that streams media while providing DVDs, these broadband companies can argue that any charge of anticompetitive behavior is silly because Netflix still relies on physical media. Splitting the companies makes Netflix’s argument stronger.

Qwikster can’t complain to the government about bandwidth restrictions; the new Netflix can.

5 months ago  ∞  short link

X Is Killing the Web

Posted September 21, 2011 @ 1:19 pm

First, a few words from Joe Hewitt:

“We should dissolve the W3C and run the web like an open source project. No more specs, just commits. Does Linux need a standards body?” [via]

“How could anyone seriously defend the W3C in an era where proprietary platforms (see iOS and Android) are destroying the web?” [via]

“Yes, I would love there to be only one browser. The “web kernel”. Fork it if you want. We don’t need specs. Specs are killing the web.” [via]

Where To Begin

I don’t mean to pick on Joe Hewitt. I love Firebug and couldn’t do my job without it. But being legitimately angry about something necessarily means ditching the broad, sweeping generalizations and getting down to brass tacks.

In the same line of thought of my last post here, I think there are some fundamental misunderstandings about the Internet and the Web that are being propagated by statements like this. Let’s have a look.

A Few Definitions

The Internet is a network of machines that carries data. It’s sending information from one of Tumblr’s servers to the computer in front of you (doesn’t matter if that’s a laptop, phone, or tablet—they’re all computers).

The Web, in its purest sense, is the interconnected set of hypertext documents that we view in our browsers. This Tumblr blog is part of the Web.

A browser is a piece of software that can access data on the Internet using the hypertext transfer protocol (HTTP). You’re viewing this Tumblr blog in your browser.

These things define the popular idea of the Web as it existed many years ago. The last decade has been incredibly transformative. Our nomenclature hasn’t kept up. Yes, the Internet is still the Internet, and a browser is still a browser, but what we refer to as the Web now is fundamentally different from a collection of linked documents.

Our Current Definition of the Web Is Broken

Note: This is not some pro-Web-3.0 screed.

We’re pushing a lot more than hypertext over the pipes and wires of the Internet now. Tim O’Reilly was on the right track when he coined “Web 2.0” and said it encompassed the advent of user-contributed content. But Tim Berners-Lee was right, too, when he refuted the term, saying the phrase was simply bringing to the fore some of the ideas he had for the original Web—that it would be read and write.

I think what O’Reilly was getting at, though, was the rise of Web applications and API-driven services that exist outside the traditional definition of the Web. They don’t fit in the description of the Web as a medium for hypertext documents.

Take Instagram, for example. Here’s a photo sharing service that, at its inception, used the Internet to push data to an application on a phone.1 The receiving application was not a browser, nor was the app displaying the data as hypertext. The only relationship the data had to hypertext was that it was transmitted via the HTTP protocol.

The W3C’s specs never came into question when someone viewed their photo stream in Instagram. Nor did any browser. Webkit rendering wasn’t an issue, either. In the end, the Web (even as we know it today) was never involved.

Instagram in its original form was a data store, an API, and a native app for iOS. It transmitted data via the Internet, but it wasn’t a Web app (I take it as read that a Web app is necessarily interacted with via a website in a browser, not via a native front-end to an API).

To be clear: Instagram never broke, destroyed, or killed the Web because it wasn’t part of the Web.

And yet, Instagram was still considered by most to be part of the Web.

Native vs. Web

Joe Hewitt is working on a project called Scrollability that aims to bring iOS-style inertial scrolling to Web applications. It’s an admirable project, but I think it underscores the real argument at the heart of Joe’s tweets: Web applications are not first-class citizens on iOS and Android.

As I’ve said before, they never will be; there’s too much money to be made by Apple and Google (and now Microsoft). Call it unfair, but I think it’s also unfair to claim that Webkit or the W3C is to blame for the lack of feature parity between native applications and Web applications. And it’s somewhat ludicrous to say that iOS and Android are destroying the Web because the developers of those platforms are reluctant to add new features to their respective forks of Webkit without a spec.

To imply that Webkit has stagnated because of a slow spec process is to forget about Internet Explorer. Maybe it’s not entirely germane (or possibly too much of a we’re-so-lucky argument), but seriously, we’re lucky today to have browser vendors in control of a large part of the market who are supporting standards (even if it’s happening slowly) rather than eschewing them because of their monopoly.

Honestly, I’m not a big fan of the W3C, either. As with any bureaucracy, it’s a tortoise, and waiting for new specs is painful. But having a spec prevents companies from pulling a Microsoft and implementing things willy nilly. That needs to be avoided.

The fact that Google and Apple are already implementing somewhat proprietary versions of Webkit frustrates me. The idea that they’d jump entirely outside the bounds of specifications for the sake of faster feature parity with native apps makes the Web developer in me want to throw up my hands and quit. I’d rather wait for the spec.

The Web Is Not the Future

In a reply to another Twitter user, Joe said, “I want the future to be the web. I am trying very hard to push it faster. It’s a slog.”

The thing is, the Web is fine. What Joe’s worried about is the future of Web applications and how they’re supported on emerging and existing platforms. That’s a distinction that needs to be made. The Web isn’t going anywhere.

But the brass tacks that we’re getting down to here is the “slog”—the speed at which progress is being made toward providing feature parity at the OS level between Web applications and native applications. The complaint has little to do with the Web and everything to do with wanting Web applications to run more like traditional desktop or native applications.

When you realize that these two things need not overlap, though—that they can both exist separately to perform optimally in a given context—the argument becomes one of preference, one front-end medium versus another. And to that, I say, if your Web app is trying very hard to be a native app, make it a native app. Square peg, square hole. Just be sure to give it a solid API. If, in the future, browsers give you what you need, you can always migrate to a Web-based front-end on the strength of your API.

The Web, Web applications, and native applications that transmit data via APIs are three very different things. To conflate them under the banner of “the Web” is a mistake, and there are clear circumstances in which each should exist separately from the others. To imply that one would destroy the other is either hyperbole or wishful thinking.

Not all native applications should be Web applications and vice versa.

Not all Web pages should be generated by an API, and not all APIs should generate Web pages.

Not all data on the Internet is part of the Web.

  1. Yes, I know; parts of Instagram are accessible via the Web now. ↩

5 months ago  ∞  short link

Euphemisms

Posted September 20, 2011 @ 11:07 am

“I don’t like words that hide the truth. I don’t like words that conceal reality. I don’t like euphemisms or euphemistic language. And American english is loaded with euphemisms. Because Americans have a lot of trouble dealing with reality. Americans have trouble facing the truth, so they invent a kind of a soft language to protect themselves from it. And it gets worse with every generation.” - George Carlin

The argument about which platform to design for first—mobile or desktop—is growing louder every day. And it’s been bothering me. Up until today, I couldn’t put my finger on why.

Mobile computing and desktop computing are nonsensical terms. What we’re seeing is the separation of business computing from personal computing—truly personal computing—which up until the last three or four years had been indistinguishable because of hardware.

In 2007, your laptop at home could have been your laptop at work and vice versa. Both used the same hardware and software to perform very different tasks. In 2011, if you have an iOS device, chances are good that the computer you check email with at work looks nothing like the computer you browse the web with at home.

Mobile applications and mobile operating systems are successful because they’re simple. But I believe the simplicity of mobile software is coincidental. People have always wanted the level of simplicity that modern mobile apps afford. However, they couldn’t demand it from the hardware that was available. When given few constraints, developers will cram things into every available pixel.

But that’s just it—smart phones enforce simplicity via hardware constraints. And now that consumers have simpler software, they want it everywhere. That’s why apps are starting to transition back to the Mac from the iPhone and iPad, and it’s why Apple brought things that made iOS easier to use back to the desktop with OS X Lion. It’s happening everywhere. The Iconfactory’s Twitterrific is essentially the same app on the Mac, iPhone, and iPad. Elements of successful, simple design are being added to OmniFocus on the Mac because they worked so well on the iPad.

This explains why the iPad has been successful, too. Like the iPhone, it’s a hardware platform that enforces the simplicity that users crave.

I think it’s time we stop calling iOS and Android and WebOS “mobile platforms.” Yes, you can carry them around with you, which makes them inherently mobile. But that’s tantamount to calling your wallet a mobile money container. Phones. Tablets. Slates. There’s a simpler term available to us that gets to the heart of what we’re designing for: personal computers.

And while we’re at it, let’s ditch the euphemisms we’ve adopted. We shouldn’t argue mobile .vs non-mobile as a starting point for design. The crux of that argument is simple vs. complicated. That’s the discussion we should be having, and it will always come down to this: distill your application down to its primary functions, and make those functions as fast and easy to use as you possibly can. Regardless of platform. Regardless of the size of the device. Regardless of OS.

Simple vs. complicated is a platform-agnostic discussion, and it should take place whenever a design decision is being made. People avoid it because it’s a thistle, a tough discussion that often leads to hard questions and passionate, heated arguments. But it has to happen.

We need to remember that, at the end of the day, after we’ve waded through the jargon and the weasel-words and the conflict-avoidance, no matter what device we’re designing for, the goal should always be simple software.

5 months ago  ∞  1 note  ∞  short link

Google, Plus-or-Minus 1

Posted July 25, 2011 @ 11:11 am

I think I’m going to have to give Google+ a pass for now. Don’t get me wrong; it’s not a terrible service. But the user experience stinks.

The iPhone App

I’ve already complained about the busted mental model supported by the iPhone app. But there are two other issues that make the app kinda useless for me.

Load Times

Google+ is crazy-fast in a browser. But on the iPhone, using the pull-to-refresh functionality can take upwards of 10 seconds to reload a stream. I’ve tested this over 3G and on my home cable connection, which routinely pulls down 20+ Mbits/sec, so I know my connection isn’t the issue. The app is inexplicably slow.

UI-Blocking Network Operations

To make matters worse, refreshing data appears to be a blocking operation, meaning you can’t interact with the app at all while it’s fetching data. Combined with slow load times, the app sometimes locks up for 10 to 15 seconds.

As an iOS developer, this is utterly baffling. Not to be a fanboy, but this is the kind of behavior I’d expect from an Android app. Every other social networking app I’ve used—Twitter for iPhone, Tweetbot, Facebook, Instagram, etc.—manages to handle network activity without blocking the UI. This is bush league stuff. Given Google’s size and resources, it’s inexcusable.

Spam

Take a look at this. It’s a post from Robert Scoble about the death of a prominent software developer. The highlighted section is a reply from a spammer.

[It’s hard, but try to ignore the fact that this asshole used a post that was written in remembrance of a recently deceased friend to hawk a shitty product. That’s a wholly different problem that falls outside the scope of this article.]

This is the second time in the last two days that I’ve seen a popular Google+ user turned into a megaphone by a spammer. Right now, Scoble has over 92,000 followers on Google+, so he’s an attractive target. With Google planning to lure celebrities to the service, this problem will likely get worse before it gets better.

I understand that spam is a problem for every service, but this is the first service I’ve encountered where you’re penalized by spammers for following popular users. Fixing this will be a big uphill battle waged in public with my streams as a battleground. I’d rather not watch it play out.

Random Account Suspensions

Speaking of the above spammer, why does he/she/it still have an account when other legitimate users are having their accounts suspended? To be clear: these people aren’t just losing access to Google+. They’re losing access to every Google service tied to the account they were using with Google+, including Gmail. It’s a common refrain, but I’m (mostly) convinced that Google still doesn’t grok how to run a social network.

It’s Not All Bad

Users of services like Google+ are less fickle than your average Web user. Once they pick a service, they stick with it because their data is entrenched. Right now, they have a handful of more polished services available to them, and there’s no compelling reason for them to bounce from, say, Facebook to Google+. That’s not to say this couldn’t change.

It’s going to take Google a while to iterate on what they’ve started with, but the foundation is strong and they’ve built a ton of early momentum. That momentum, though, is a double-edged sword. It provides great press, but it also means Google’s going to have to act fast to shore up these issues.

7 months ago  ∞  short link

Just

Posted April 15, 2011 @ 12:46 pm

“Can’t you just…?”

“Why doesn’t this just…?”

“This should just…”

“Why can’t this just…?”

Yep. Getting really sick of the word “just.” I’m going Sam-Jackson-in-Pulp-Fiction on the next person who uses that word to oversimplify what I do.

Think about it; would you ask your doctor to just cure your cancer? Would you ask your personal trainer to just make you skinnier? Would you ask a scientist to just send some people to Mars? Would you ask a writer to just bang out a few new novels?

When used this way, “just” has two very, very bad connotations.

  1. It shouldn’t take you long to fulfill my request because…
  2. Your work is easy.

You’ve demeaned a colleague by telling him or her that the job he or she does is inherently simple. Nice work, jackass.

Seriously, never make the assumption that someone else’s job involves nothing but trivial work. I’ve yet to meet a professional whose job is wholly uncomplicated. Always assume that the people you’re working with have jobs that are harder than yours. Always. Once you do, you’ll probably never use the word “just” when making a request, because you’ll realize that it makes you look like a 4-year-old asking mom to cut her steak for her.

Maybe this is more prevalent on the Web where developers seemingly wave magic wands and make things appear and disappear. No one sees what happens inside the black box, so they assume that it’s simple. I’m here to tell you that, brother, it ain’t.

10 months ago  ∞  short link

« Older

© 2011 Jeff Mueller. Icons by P.J. Onori and Komodo Media. Powered by Tumblr and Slicehost. Twitter Feed.

Ninja Tip: Pressing j and k will autoscroll your browser from one post to the next. Yup, just like ffffound.