Category Archives: Web development

Startups Need Design Talent

Reading Chris Dixon’s blog this morning and his latest post caught my eye, talking about some of the things (NYC) startups need and do not need.

Second point on Chris Dixon’s list for startup “needs”:

2) More web product design talent. This is the scarcest talent of all (more so than engineering). NYC has perhaps the best design community in the world, but most of the designers are trained in non-web design fields (e.g. print design).  Most of the good design schools don’t emphasize web product design (some exceptions – e.g. my friend Zach Klein taught an excellent class at the School of Visual Arts last semester on web product design). NYU’s ITP stands out as a program that focuses on the intersection of design and technology (e.g. the Foursquare team went to school there). CMU’s HCI program and MIT’sMedia Lab are also great. Other schools need similar programs.

As someone working in this area (in Toronto) I find it amazing there would be a lack of digital design talent available in New York city, arguably one of the biggest hubs globally for such talent.

Rethinking The 1024 Paradigm

Wheat Field Under Threatening Skies, 1890, Vincent van Gogh

Here’s an interesting topic many of us working in the digital field can relate to—a topic which seems to come up more and more lately. I’m talking about the 1024 paradigm. That is, the tendency to design anything destined for the Web browser environment to be visually optimized for screens 1024 pixels wide by 768 pixels tall.
Everyone has likely heard those numbers at one time or another—but how do they influence our digital experiences?

Note: I’m not going to bore you to death with another one of those long posts examining the history of computer screens, GUI layout implementations or technical aspects of designing for the various screen resolutions over the years. While this could be a wider topic for discussion encompassing CSS strategies and Web standards, I’ll try and keep this post brief.

I call it [1024] a paradigm because for many years the prevailing consensus among digital designers and developers has been this display size (1024 by 768 pixels)—more than any other dimension—represents the most common screen size for people viewing the sites we produce.

However, like all paradigms there’s a beginning, middle, and end—and just like 800 by 600 and 640 by 480 before it, I think the end is near.

Yesterday I was having a discussion with one of my colleagues on this very topic. We were noticing the emergence of more horizontally-oriented user interface designs on the Web—and we think it’s great from a creative and UX perspective. In our talk it occurred to us, the old 1024 pixel design paradigm still drives (or constrains, depending on how you look at it) most—if not all—the digital designs we produce for our clients. This isn’t anything negative or bad, just something we’ve observed.
In fact, acknowledging a sizable portion of the Web audience, albeit dwindling (like IE6 usage), still view many of the sites we create on screens running 1024 by 768 pixel displays, shows we are very much cognizant of accommodating the widest possible viewing audience. Call it due diligence or forced sentimentality, it’s something I imagine many of our clients unconsciously appreciate.

On the other hand, if you consider the growing pervasiveness of wide screens (…walked into any Best Buy lately?)—and by wide I mean 16:9 aspect ratios up and beyond a width of 1600 pixels—I genuinely wonder why we’re still taking such great lengths to ensure our clients digital designs are optimized for this particular screen dimension.

So what if (designers and creatives love to say “what if…”—sometimes to the grief of developers who must implement the “what if” scenarios and concepts into viable solutions) 1920 x 1200 pixels and larger became the new standard on the Web?

What could we do with all that extra screen real-estate from a creative and design perspective? Would we start to see 4, 5, or 6 column layouts?

Could we put greater emphasis on larger typographic treatments and better leverage negative space?—these are visual communication techniques graphic designers exploit well in print.

In any case I’m intrigued by the possibilities of designing for larger screens just as I was excited about exploring full screen Flash-driven UIs a few years back with runtime stage resize listeners (via Actionscript) to achieve more flexible interfaces.

Still, vertically-oriented (1, 2, and 3-column) layouts have their place and have been the norm for years on the Web, serving us quite well. But perhaps it’s time to rethink the 1024 x 768 pixel paradigm, retire the old scroll bars and page fold rhetoric and move on to embracing a wider view of the things we experience on our screens.

For the record: my desktop (home and work) is 1680 by 1050 pixels while my laptop is 1280 by 800 pixels and my wife’s laptop (now 6-years old still running XP) is 1440 by 900 pixels.
My high definition television (now 5-years old) which I occasionally use to browse the Internet through my PS3, has a native display of 1024 by 768 pixels.

Steve Jobs Versus Everyone

I find it odd to come across an article on Web standards this morning on Smashing Magazine proclaiming the end of Flash by including, quite oddly, imagery of United States military personnel.
In presenting what the author considers compelling reasons for Web standards adoption in favour of Flash and (I suppose) other plug-ins, we see imagery of a soldier brandishing a machine gun while displaying a big thumbs up.

Ahh.. yes.. of course, I see the connection -the debate is over; diplomacy has failed and it is now time for brute military force -destroy Flash and all plug-in Web technologies; it’s our way or the highway I guess (or, at least in the eyes of the misguided author).

This rationale really bugs me. That is, I am a big proponent of thing X (in this case, Javascript) so I am going to do everything in my power to stamp out and criticize thing Y (in this case Adobe Flash) because I feel there is only one viable way to build Web sites. It’s like being stuck in a meeting where one individual monopolizes the discussion by sucking all the collaborative air out of the room.

The author goes on to argue that Flash sites are beginning to gradually disappear from the Web. Strange, I didn’t notice anything different about the FWA today. Perhaps the author’s conjecture was based upon the recent news regarding Apple’s latest SDK agreement which essentially blocks Flash developers from the iPhone and iPad. So I suppose Flash sites must have instantaneously disappeared overnight then?

I am sorry, but I like to think there are multiple ways to architect Web experiences. Certainly a site like Record Tripping for example, could not realistically be achieved exclusively through Javascript libraries and HTML5 contrary to what Flash opponents would have you believe.

C’mon, if you actually took the time to research your post by reading between the lines of the (ongoing) Apple versus Adobe feud, you would realize a lot of the premature hype regarding the demise of Flash actually surrounds Steve Jobs’ desire to keep the App Store free from competitive offerings. As John Gruber (a.k.a. Daring Fireball) writes:

So what Apple does not want is for some other company to establish a de facto standard software platform on top of Cocoa Touch. Not Adobe’s Flash. Not .NET (through MonoTouch). If that were to happen, there’s no lock-in advantage. If, say, a mobile Flash software platform — which encompassed multiple lower-level platforms, running on iPhone, Android, Windows Phone 7, and BlackBerry — were established, that app market would not give people a reason to prefer the iPhone.

And, obviously, such a meta-platform would be out of Apple’s control. Consider a world where some other company’s cross-platform toolkit proved wildly popular. Then Apple releases major new features to iPhone OS, and that other company’s toolkit is slow to adopt them. At that point, it’s the other company that controls when third-party apps can make use of these features.

While Steve Job can quite frankly do what ever he wants to maintain Apple’s competitive supremacy in the mobile application marketplace, we all know technology moves fast and things eventually change. The iPhone is certainly not the be-all and end-all ecosystem for mobile application development. So, as a developer, if you do decide to start playing by Apple’s strict rules, be prepared to surrender your freedom to the whims of the tyrannical App Store. To paraphrase an old saying: All Your Base Are Belong To Steve -can’t say we didn’t all see this coming.