About | Remix Defined | The Book | Texts | Projects | Travels/Exhibits | Remixes/Lists| Twitter

Tracking the DIY phenomenon Part 2: Mass customization, mashups, and recombinant Web apps, by Dion Hinchcliffe

Images and text source: ZDnet

February 25th, 2007

In my  last post, I took a look at the recent proliferation of Web widgets, which are modular content and services that are making it easier for anyone to help themselves to the vast pool of high value functionality and information that resides on the Web today.  Companies are actively “widgetizing” their online offerings so that it can actively be repurposed into other sites and online products.  And as we discussed in the last post, it’s believed that letting users innovate with your online offerings by letting embedding them in their own Web sites, blogs, and applications can greatly broaden distribution and reach, leverage rapid viral propagation over the Internet, and fully exploit the raw creativity that theoretically lies in great quantities on the edge of our networks.

DIY on the Web is looking to be a major trend; Newsweek recently speculated that 2007 will be the Year of the Widget.

Looked at this way, letting thousands and even millions of users build Web sites and apps out of your Web parts and then monetizing it with advertising, usage fees, or subscriptions sounds great in the abstract.  But one of the big outstanding questions is if widgitizing is mostly useful for gaining fast user adoption and market share, and not for building the fundamentals of a viable, long-term business online.  While this last question is still very much an open one, part of the answer will come from the way that the consumption side of DIY develops.  The question is this: Are environments emerging that will enable rich and sophisticated DIY scenarios that are usable by most people?

Everyone Assembling the Web: The Difficulty Curve

So while my last post looked at the recent growth of available Web parts, now we’ll look at the consumption side of the DIY phenomenon.  Specifically, beyond the simple copy-and-paste of snippets of HTML, what is the current state of capable tools that will let all of us assemble useful apps beyond the widget encrusted dashboards that are most likely outcome possible today?  Because without tools that enable real integration between all these portable Web parts, services, and feeds, we don’t have useful new software, we just have fancy information displays.

Like the emergent, DIY usage currently being explored and increasingly embraced with Enterprise 2.0, the idea of DIY is to get developers and IT departments out of the demand loop and letting users self-service themselves.  Like spreadsheets and desktop databases have been used for years by end users to build simple apps, with the rise of reusable, portable Web parts and feeds allows the assembly of an entire spectrum of Web apps that don’t require true software development skills.  Given the right tools that guide users down the right paths (palettes of pre-tested, approved parts, built-in security, versioning and configuration management), DIY might become a major force for leveraging the largely untapped The Long Tail of software demand, instead of becoming a giant support headache for public Web companies and internal IT departments.

Of course, what I’m referring to here is enabling end-users to create Web mashups and enterprise mashups out of the widgets, badges, gadgets, and open Web services increasingly available on Web sites and from major software vendors like Google, Microsoft, Yahoo!, and many others.

Mashup Cross Section

This is where the story is increasingly interesting as software companies race to provide various solutions for letting ordinary users assemble real Web applications, including genuine integration between visual Web parts and Web services.  Companies such as Teqlo, JackBe, Kapow, Dapper, IBM (QEDWiki), Yahoo (Pipes), CogHead, Ning, DataMashups and many others are all seeking to provide solutions to lower the barriers so that almost anyone can create the mashup they need, when they need it.  What these products will need to provide in terms of features, structure, assembly model, standards support, ability to work with parts, services, feeds, and much more is relatively unknown.  But what is clear is the vision, ingenuity, and widespread interest and potential benefit that really good DIY Web tools could bring to literally hundreds of millions of users around the world.

Read a detailed overview at Yahoo! Widgets of how the widget model evolved from the PC desktop to the Web.

While it’s still an brand new and rapidly emerging field, here are the major issues that mashup environment and DIY Web app tools will need to grapple with effectively to succeed in the market:

Key issues for successful mashup creation tools

* Ease of use: Being usable by virtually anyone with any skill level using any browser in any language without any training will be essential for mashup tools to succeed with the general public.  Any barrier to use is too high when users will gravitate to the easiest tool to use.  While choice of tools tends to be limited inside the firewall, this is not the case on the Web but it will be a factor for adoption in both locations.  I’ve covered this before in my Seven Habits of Highly Effective Web 2.0 Sites, and it cannot be stressed enough.  Time and again we’ve learned on the Web that once two-way tools are in place that the barrier to contribution and user adoption is excessive structure and complexity.
* Embody best practices in software development.  End-users are not developers and won’t understand many of the key issues in software development.  This includes testing, version control, security, scalability, and reliability to name just a few.  The best mashup tools will take care of these vital issues automatically and not get in the user’s way as they develop their situational application.
* Support open standards.  The applications that are output by mashups tools should be regular Web apps that are based on the open standards of the Web and not proprietary runtimes and formats.  Mashups should be made of current versions of HTML, Javascript, CSS, as well as any of the Web parts they include.  The Web works so well because it’s a “system without an owner” and the open source world has taught us the value of openness, transparency, and clarity.
* Use a broad array of visual parts and non-visual Web services.  From Javascript snippets, Flash badges, Web-oriented services like REST, and Service-Oriented Architecture services like SOAP, to the leading feed formats including RSS and ATOM, the leading mashup tools will support the widest range of raw ingredients.  Products like Kapow’s Mashup Server are setting the standard for letting users turning anything on the Web into a service they can use in a mashup. It’s this kind of ease of consumption that the most successful mashup tools will enable.
* Will encourage social use and uptake.  Social software is a potent force and Reed’s law instructs us that networked applications that are fundamentally social are more powerful than non-social systems.  Invites, link propagation, and feedback loops that leverage the social dimension of software may likely be critical for successful mashup platforms.

Of course, given the early state of mashups, this list is only partial and we’re still learning by watching how the first crop of mashup tools do what works and what doesn’t.  What is clear is that users are ready to embrace the supply of Web parts and services in large numbers and are getting increasingly accustumed to directly shaping their Web experiences so that they don’t have to be the manual integration point between their various software apps and sources of information.

Are you beginning to use widgets on your Web site?  Are you looking at taking the next step and looking for tools to make it easier?

Lascia un commento

You must be logged in to post a comment.

Current Projects





    Remix Theory | is an online resource by Eduardo Navas. To learn more about it read the about page.

    Logo design by Ludmil Trenkov