Your mental model of the Internet can affect how you imagine the future of your Internet services.
I contend you should be thinking about providing primarily DATA and PROTOCOLS to your users, not interfaces. Let them build their own interfaces to suit their needs. In terms of interface skillsets, XML and JavaScript become the key.
For people who started using the net with the start of the web, I guess it goes something like:
"The Internet is a collection of web pages that you visit by entering the web site address. You can locate web pages by doing a search. An individual web page provides access to some particular information or service. Also, you can use the Internet for email."
If you started on the net before the web, you maybe think something like:
"The Internet is a set of standardized communications protocols which can be accessed using separate client applications. For example, TELNET protocol, FTP, SMTP, NNTP, ... which you use with your telnet program, FTP program, mail client, newsreader. There are a number of options you can pick from in terms of client applications."
This second way of thinking helps a great deal I think.
It tells you there are three things:
- some data or service you want to get
- a protocol to get it
- a client application (or many client applications) that implement that protocol
I have observed that librarians have difficulty separating these concepts.
That is not surprising, many people who are technology users confuse the interface with the implementation. For example, if you ask someone what an icon is on the screen, and what they are doing with it, they will say it IS a particular file, and they are performing actions on it.
When in fact an icon is a representation of a file, through which you can signal to the operating system that you want it to perform some tasks for you.
It seems to me that over the past 10 years, a lot of people have confused "providing Internet services" with "putting up a web page". This has worked well, but it is not the future of the net. I don't want your (often badly designed, feature-poor) interface. I want to access your data and display it wherever and however suits me. If I just have your interface, it may be very difficult for me to combine it with other information in interesting ways.
Yahoo, Google, Amazon, and other big web players get this.
BusinessWeek July 25, 2005 Mix, Match, and Mutate
Mash-ups portend big changes for software companies, Web sites, and everyone online. No longer just a collection of pages, the Web is morphing into a sort of global operating system, à la Microsoft Corp.'s Windows. And now, people are learning to program Web 2.0 with much of the same innovative energy of the personal computer's early days. "It's the Wild West all over again," says Alan Taylor, a Monster Worldwide Inc. Web developer who created Amazon Light, a fast-loading version of Amazon's site that also includes services from Google, Yahoo, and others.
The upshot: People are seizing far more control of what they do online. In the process, those efforts are putting skin on the bones of Web services, the long-delayed promise of software and services that can be tapped on demand. "They're taking little bits and pieces from a number of companies and stitching them together in some clever way," Amazon Chief Executive Jeffrey P. Bezos noted recently. "You'll start to see the real power of Web services."
At the same time, these bottom-up efforts present tough challenges for the sites on which the new services are built. Mash-ups often use the data without asking first, then present it in unintended ways. Not surprisingly, some Web site operators have bitten back. Yahoo initially blocked one mash-up site from using its traffic data with Google Maps before relenting, and Amazon asked Amazon Light's Taylor to change how it linked to potential rival sites. "All this definitely keeps us on our toes," says Jeffrey S. Barr, Amazon's Web services evangelist.
Some mash-up software presents a potential danger to users as well. Greasemonkey, an add-on to the Firefox browser, allows the quick installation of software "scripts" to customize the way a Web site works on a particular PC. Crooks could write malicious scripts -- say, to secretly log keystrokes to steal financial data, says Book Burro creator Jesse Andrews. But he thinks the threat can be minimized with software tweaks and peer review of scripts.
INEXPENSIVE R&D
In any case, none of that has slowed the mash-up momentum. For one thing, Amazon and other Web giants are now embracing the mash-up movement by offering developers easier access to their data and services. Moreover, they're programming their services so that more computing tasks, such as displaying maps onscreen, get done on the users' PCs rather than on their far-flung servers. Besides speeding up the experience, the shift makes it easier for outsiders to add their tweaks, says Google Maps product manager Bret Taylor.
The appeal for Web sites? Mash-ups offer a way for them to tap the creativity and hard work of the masses, who do the work and get out the word -- and the software -- through blogs and Web sites. "We want to encourage community participation," says Paul Levine, general manager of Yahoo! Local. "It's essentially research and development and marketing for us."
The results are often remarkable. Chicagocrime.org, for instance, combines two services -- a Chicago Police Dept. crime Web site and Google Maps -- and lets you type in an address to see recent crimes nearby. The site attracted 1.2 million page views in just the first two weeks after it began in May. Creator Adrian Holovaty, a full-time Web developer at the Lawrence (Kan.) Journal-World's online unit, thinks there may be a business in mash-up creation.
So far, mash-up business models don't extend beyond running a few Google ads and collecting fees for sending buyers to e-commerce sites. One reason is that most Web sites don't allow for-profit use of their data by outsiders. But as traffic to mash-ups grows, companies may cut deals -- especially if mash-up sites spur new markets. Map-based mash-ups, for instance, might finally attract ultra-local businesses to advertise on the Web.
Loosely Coupled weblog July 26, 2005 Why Yahoo bought Pixoria [Konfabulator]
Here are the ingredients that I believe give Yahoo! Widgets (formerly known as Konfabulator) such huge potential:
- Desktop-based Javascript. At the heart of Yahoo! Widgets is a JavaScript interpreter that runs either on a Mac or on Windows. What this means is that someone can write a program in JavaScript that executes on the desktop without requiring a browser. That has a huge appeal to the hundreds of thousands of people who know at least something about how to code using JavaScript. It has enormous power in the hands of the small minority of them who really understand what's achievable with JavaScript, and can now achieve it without having to boot up a browser first.
- XML-based parameterization The structure and basic parameters for a Yahoo! Widgets application are defined in an XML file, which is parsed on launching the application. This enforced separation of configuration information from coding is a big contributor to the inherent ease-of-use and flexibility of the architecture.
- GET and POST methods Yahoo! Widgets defines a URL object that allows a widget to access information stored at a Web URL. The most obvious application (and there are already widgets that do this) is to put a self-updating RSS feed reader on the desktop. This alone justifies Yahoo!'s purchase, because imagine the value of being able to put a Yahoo! Widget on a user's desktop that constantly alerts them to new content appearing on the website. But one can also think of many other commercial applications for a number of REST-style web services besides RSS.
A key element about providing data and protocols is to understand that the consumer may no longer be a user sitting at a computer screen with a web browser. It may be a purely automated process, with no user involvement. It may be used on a PDA or other mobile device. Provide the information, let the users do what they will with it.
Why is this important? Because empowered individual users can move much, much faster than just about any other organization. Wikipedia and eBay work because they provide platforms for thousands upon thousands of people who are passionate about some specific thing. That thing might, amazingly, be some information your library can provide, but they just can't get at it to work with it right now.
Charlene Li writes in Why Yahoo buying Konfabulator is more than just about widgets:
I am at the mercy of app developers ...
But why should I have to wait for developers...? This is where I think Yahoo! gets very, very interesting with Konfabulator. As a developer tool, it may have some interesting potential for developing neat interfaces into Yahoo!’s vast stores of content and information. But if Yahoo! can put the power of widget creation into the hands of end-users, it would give us end users the power to not only create custom content streams a la RSS and MyYahoo!, but also allow us to filter, distribute, and combine that data in any way we see fit.
Paul Miller has written an insightful post in his new blog, Thinking about the future: Thinking about this Web 2.0 thing.
UPDATE 2005-10-16: Lorcan Dempsey writes about these ideas today under the rubric of Recombinance.
No, I got it, but libraries have to work at all levels: full service (complete with extensive interface) for those who don't have time, energy, knowledge, or inclination to re-mix down to API or XML or open datastores for those who want to build their own way in. Also, some licenses for library products require display in the original home.
as for >I have observed that librarians have difficulty separating these concepts.
I *still* fight with librarians who confuse database vendors with database producers (like inspec vs. dialog/ev2/ebscohost) ... so good luck!
Posted by: Christina Pikas | August 17, 2005 at 12:42 PM