Archived entries for Info Mgmt

More small pieces fit together more ways

In early February Todd Sampson wrote that The API is the Product. I think he’s right on. Behind the exciting buzz of sites and services that make getting bits of info online easy are some very cool APIs that let anybody and everybody create entirely new ways to input or output that same data. (The apparently trend to smaller pieces of data is interesting too, and part of the ease.)

Here are a few of those sites: FireEagle for location data (a single geocode), TripIt for travel data, Delicious for links data (a single URL+ tags), ThingFo for experience data (in 30 chars), Twitter for vitality data (140 chars).

These APIs make possible an undeniable wave of creative hacks within the small orbit of any of the services even individually. This growth testify to the mass variety of niche needs and personal priorities. It seems the ocean of data is really a petri dish.

When these hacks cross-pollenate — when the ins and outs of the data sets start sharing and talking with each other — things get even more interesting.

Those that dismiss mashups as simply “things on a map,” “widgets on a blog,” or “applications on facebook” don’t see the full power. I don’t claim to either, but important coolness seems inevitable when data becomes small and abundant while APIs become prolific and potent. More small pieces fit together more ways.

(Perhaps this is a small part of why Douglas Crockford says that “Mashups are the most interesting innovation in software development in decades.”)

Gotta Agree

Installing software people didn’t request erodes trust. It’s especially repugnant when it hitches a ride with a security or version update. Marshall Kirkpatrick’s right: downloading software has to be opt-in, not opt-out.

As technologists, we want up to date users. Beyond the real user-safety issues, it frustratingly holds us back. The oldest browser is the lowest common denominator and holds us all back. But sneaking new software into the sacred realm of auto-updating flows is unwise. We cannot take advantage of users at the exact moment we want them to trust us blindly and reflexively.

Multiple Apple products are within arm’s reach. My first technology experience several decades ago was on an Apple product. Love ‘em, but they should know better.

I’m glad John wrote his post.

Foreward to O’Reilly’s High Performance Web Sites Book by Steve Souders

Steve Souders wrote High Performance Web Sites: Essential Knowledge for Front-End Engineers last year for O’Reilly. He generously invited me to write the foreward.

The book was published about six months ago, but in writing the my last blog post (on the 20 new rules just released) I noticed that I didn’t have an easily-accessible copy of my contribution. So, please forgive me for pasting it here for future reference.

Book Cover: High Performance Web Sites

Foreword

You’re lucky to be holding this book. More importantly, your web site’s users are lucky. Implement even a few of the 14 techniques Steve shares in this groundbreaking book and your site will be faster immediately. Your users will thank you.

Here is why it matters. As a frontend engineer, you hold a tremendous amount of power and responsibility. You’re the users’ last line of defense. The decisions you make directly shape their experience. I believe our number one job is to take care of them and to give them what they want—quickly. This book is a toolbox to create happy users (and bosses, too). Best of all, once you put these techniques in place—in most cases, a one-time tweak—you’ll be reaping the rewards far into the future.

This book will change your approach to performance optimization. When Steve began researching performance for our Platform Engineering group at Yahoo!, I believed performance was mainly a backend issue. But he showed that frontend issues account for 80% of total time. I thought frontend performance was about optimizing images and keeping CSS and JavaScript external, but the 176 pages and 14 rules you’re holding in your hand right now are proof that it’s much more.

I’ve applied his findings to several sites. Watching already-fast sites render nearly twice as quickly is tremendous. His methodology is sound, his data valid and extensive, and his findings compelling and impactful.

The discipline of frontend engineering is still young, but the book in your hands is an important step in the maturation of our craft. Together we’ll raise expectations about the Web by creating better and faster (and therefore more enjoyable) interfaces and experiences.

Cheers to faster surfing!

–Nate Koechley

Senior Frontend Engineer
Yahoo! User Interface (YUI) Team,
Platform Engineering, Yahoo! Inc.

San Francisco, August, 2007

Data Ocean vs Document Lake

Friend and Yahoo! Developer Network (YDN) Director Matt McAlister has a good post today on Creating leverage at the data layer.

Matt cites Tim Berners-Lee from a recent interview saying that the future of the web is one where we and our agents “can access all the data” via a “much more seamless and much more powerful” interface and experience made possible “because [of] integration.”

That’s different than how it’s been. Documents are a subset of Data. The Web has been a lake of Documents. It is becoming an ocean of Data.

We’ve surfed the lake of documents with a web browser. But a web browser is not always the right tool for the ocean of data. One of many examples is that many people consumer Twitter via a desktop client like twitterific or twhirl. In fact only 45% of recent messages (of people I follow) were posted via the web interface. It’s not a stretch to conclude that a majority of twitter users have determined that there is a better way to interact with twitter’s data than with a web browser. (If not the stats, then certainly the trend.)

I see that as evidence that A) some new interfaces are required for some new types of data; and that B) the web has interesting data to consume outside of a browser.

In the same vein, Matt writes that “Social networks are a good user interface for distributed data, much like web browsers became a good interface for distributed documents.” He’s right: social networks are a great way to consume the so-called vitality stream.

Moving on he writes that the markets and technologies supporting this new world “are still in very early stages.” His notion that “there’s lots of room for someone to create an open advertising marketplace for information, a marketplace where access to data can be obtained in exchange for ad inventory, for example” is important.

There’s more good stuff in his post, but I gotta get back to my other work. I didn’t even mean to write this much about it — so i’ll stop now and let you head over there if you want – but I’ve got a bit more that I’m mulling that I’ll try follow up with.

Live on Yahoo! Live

"Control" or "Why is interactive design different from print design?" (Khoi Vinh presentation)

The Web is not Print. I’ve said it a million times.

But it took the master, Khoi Vinh, to express why. He doesn’t have all the answers yet, but he states the problem space more clearly than I’ve heard elsewhere. And that’s half the battle.

Here is his presentation posted on Slideshare. If you’re involved in web design or web development, do yourself a favor and click through it. It’s called "Control".

He is, of course, a great storyteller, so while I’ll post a few quotes here you’re much better off reading his slides directly.

If narrative is the guiding principle of traditional design, then control is its most important tool. But the guiding principle of interactive media is not narrative — it’s behavior. Designing for behavior means transferring some measure of control from author to user.

What are we designing? Digital media is as different from print as a speech is different from a conversation. They’re both exchanges of information between people. But one is a controlled environment and the other is uncontrolled. In fact, what we’re talking about here is the difference between documents and conversations. Digital media looks like writing, but it’s actually conversation. This push and pull is essential to media evolution. Documents and conversations are not mutually exclusive. They are inherently dependent upon one another.



San Francisco, California | Creative Commons By-2.5 License | Contact

RSS Feed. This blog is proudly powered by Wordpress and uses Modern Clix, a theme by Rodrigo Galindez.