Bob Balaban's Blog


    Bob Balaban


    Mashups? "Bashups"? "Smashups"?

    Bob Balaban  May 20 2007 08:44:27 AM
    Greetings, Geeks!

    Ok, I need your help on this one, I'm confused. I've been hearing about "mashups" now for a few months. Boy, have I been hearing about seems as though they're on the radio in the morning, and on the blog or in the trade-news column of every MBLIFMR pundit on the Net. (That's "Management By Last In-Flight Magazine Read", for you newbies).

    It seems to me that there's way less here than meets the eye, but of course this is UI-land, and I don't always trust my own judgments here. I want to say what I think "mashups" mean in the Domino Web App space, and I want YOU, dear, loyal Geekdom denizens, to tell me whether I'm right on, close, or WAAAAYYYYY wrong. Ok? I promise, you won't hurt my feelings.

    Cutting directly to the chase -- to me a mashup is nothing more than a bunch of rectangles on a browser page, where each rectangle represents the UI for a different app. Sometimes the rectangles (mashlets?) can "talk" to each other, sometimes not. One nice feature for the user experience (in most cases, anyway) is that when the content of one mashlet updates, the other's don't have to refresh. I guess this is what AJAX is for, and that's probably a good thing.

    I've seen other, fancier mashups (like the ubiquitous GoogleMaps examples) where the mashlet UIs are actually overlaid, on on top of the other. This style seems useful for geographically oriented information, but not much good otherwise (ok, I said this was my opinion!)

    To me, if I'm accurate in my description, "mashups" are really a Portal-style interface, with a few variations: 1) A Portal page is "assembed" (the UI is aggregated) on a server, whereas a mashup could be aggregated on a server, but could also be aggregated on the client; 2) Portlets come with an inherent (because the code really only exists on the server) ability to talk to each other ("click 2 action", or the newer form, "Composite Applications"), mashlets might or might not have that ability, as there are no standards for how to do it -- so all mashlets from Google, say, can talk to each other, but not to mashlets from Microsoft...

    There's an inherent advantage in doing a mashup where all of the mashlets originate (or get their data content) from the same domain: browsers generally don't let "active content" (such as Javascript code) access servers outside the domain from which they were loaded. I hear that there are ways to "workaround" this limitation (perhaps I'll do an upcoming post on "Cross-site Scripting", but not today), but for the most part you're not supposed to do that. This would seem to imply that Portal servers have an advantage -- they can aggregate portlets that pull from anywhere -- but I think a robust mashlet framework would allow this as well: you'd just have to have your off-domain mashlet proxy its data request through the server, probably not real hard, but quite a bit more subject to security than XSS...

    How am I doing so far? Is this stuff here to stay, or are we just fooling around?

    Assuming this stuff is real for now, what does this mean (or what COULD it mean) for Domino Web Apps? (Now we head off into What if....? land)

    Supposing you, the Domino Geek Developer, had a way to lay out a Web page with multiple mashlets, where each mashlet was the front-end to some app (could be a Domino app, like a user's Inbox, could be a discussion db view, could be an Activities list...). The pattern would be that each app is represented by some code (let's say it's JavaScript) -- which you don't have to write, but which you can edit/modify/override if you want) and some CSS (which you don't have to write, but which you can....). When the "page" is invoked by a URL to the server, the basic layout and mashlet code is downloaded, and then each bit of mashlet code starts up and fetches the data to populate itself, AJAX-style.

    Let's also hand-wave into existence a client-side communication mechanism whereby mashlets can securely exchange "properties" and trigger "actions". For example, when the user clicks on a mail message in the Inbox mashlet, the Activities view automatically re-shuffles itself to show all Activities involving the sender of that email. And of course, all names in all mashelts are automatically presence-enabled for Sametime....

    I kind of like that idea, do you?

    It seems (to me, anyway) awfully close to Composite Applications, which, if you've been following the betas for Notes 8 you've already heard about. Both patterns involve assembling "components" onto a page and figuring out how they can/should talk to each other.

    But I see a couple of important differences:
    1) CompApps require WebSphere Portal or the Notes rich client to run, Domino mashups would run in a browser (though of course they could also consume Portal mashlets/portlets)
    2) CompApps require pre-wiring of the components at assembly time (this is something you do in the Composite Application Editor in Notes 8); mashups may or may not require pre-wiring. If they use the "Click 2 Action" style of automatic discovery, then "wiring" is dynamic and occurs on the client page at runtime.

    Discuss! Is this something we should build? Would you use it?
    Naturally, it pre-supposes some new capabilities on the Domino server for this to work right. I have hinted at some of these in other posts, but I'll say no more about it right now.

    1John Head  05/20/2007 11:48:41 AM  Mashups? Bashups ? Smashups ?

    Bob - I love the idea of having mashups with domino components work on the web, and the client side - click 2 action like wiring. I guess in the implementation i would rather have this added to the composite application model so it only have to build and maintain one thing. I would also want to see this work with other pieces that are not domino cotent. Last, you should check out { Link } ... its an amazing mashup building tool. For instance, here is one that mashes the New York Times headlines with Flickr ({ Link } They also have an amazing web ui pipe builder. Worth checking out if your going down the roads of mashups.

    2Doug Finner  05/20/2007 2:47:55 PM  Mashups? Bashups ? Smashups ?

    When I think of a mashup, I think of something done by the user, not the developer. Web mashups are made from multiple sites that each offer the user a way to aggregate specific information into something of interest to them. I could be like portlets or it could be something much more interesting like having the data from multiple sites pre-processed to present totally new information.

    If I was going looking for a mashup thought leader, I'd go here - { Link } Jon's been playing with this stuff for quite a while and has done some really interesting user mashups.

    I think the key for the data provider (Domino) is to make sure you provide a workable api that the user can use (think google or flickr or ebay apis).

    3Baiju Thomas  05/21/2007 7:40:27 AM  Mashups? Bashups ? Smashups ?


    There is no doubt that it'll be a really useful addition to the domino development. We build theses kind of mashlets in our applications. If we can control the style, columns rows etc for each mashlet it'll help the developers in a big way.

    4Brian Miller  05/21/2007 10:30:08 AM  Mashups? Bashups ? Smashups ?

    Bob, I think that you might be pinning the mashup idea down to something too narrow. You're not combining "rectangles" in the UI, you're combining data feeds from disparate/unrelated sources, and coming up with a UI that makes sense for the information being combined. That's all a "mashup" is. I'd look at "composite applications" as a subset of mashups.

    Here's my idea. Look at what Yahoo Pipes is doing. Consider that you can download any feed to the Domino server by instantiating a small http client on the server side. You can "reflect" it through a request to the Domino server, so that all data feeds, regardless of format, appear to be originating from the same server. Add a drag-and-drop builder interface a la Yahoo Pipes, and you've got a "build a mashup in 5 minutes" NTF that you can freely distribute.

    Of course, we advanced folks would want access to the plumbing. But, just being able to consolidate data sources so we can get at them via AJAX requests to our one Domino server would save developers a lot of time.

    If course, this can all be done with tools that we have today, which might just make it a good OpenNTF project. :)

    5Jeff Gilfelt  05/21/2007 10:35:18 AM  Mashups? Bashups ? Smashups ?

    I agree with @2. To me, a mashup is something produced by a user rather than a developer. Perhaps I am missing the point, but what is being described sounds an awful lot like the functionality of a portal server.

    The name "mashlet" (which I think sounds totally lame) implies that these are things built for the purpose of being "mashed". The likes of Yahoo! and Google aren't providing anybody with "mashlets" - they are just exposing some really useful web services APIs that people (some developers, some not) are using in cool and creative ways.

    If IBM just concentrate on delivering a rich, robust and developer friendly API for Domino that can be exposed using standards like web services and RSS, then mashup support will take care of itself.

    6Kerr  05/21/2007 11:36:00 AM  Mashups? Bashups ? Smashups ?

    I'm coming down on the side of mashups being anything you can build by combining existing services. This is especially the case when you don't have any control of the source services. I don't think that it is necessarily the case that combining the source services needs to happen on the end client machine or that the combining is done by an end user. The key is that the services are put together to do something new that they couldn't do on there own. It might be quite complicated to mash the services into something useful, more complex than could be expected from wiring up via a GUI.

    7Nathan T. Freeman  05/21/2007 4:24:31 PM  Mashups? Bashups ? Smashups ?

    If mashups are just client combinations of web services, then to what degree is this a matter of tools from DOMINO? I could see wanting to do this from a NOTES CLIENT, but I suppose that we should be getting this from WSDL consumption in 8, right?

    Domino could facilitate arbitrary client-side mashups via the data API discussed previously here.

    If they're SERVER combinations of web services, then isn't that redundant to Portal?

    8Bob Balaban  05/22/2007 10:42:31 AM  Mashups? Bashups ? Smashups ?

    Greetings, Geeks!

    @1 - Interesting point about the relationship of Mashups to Composite applications. My guess is that we'd have both, and try to figure out how to work the tooling environment so that it's easy to build either.

    Yahoo Pipes is on my list of things to investigate...

    @4 - Brian, I agree with you that mashups are more properly about data feeds than about rectangles, it's just easier to describe it that way. Your suggestion about proxying off-domain feeds through the server is a valid one, I think we'd have to do something like that to help control cross-site-scripting issues anyway.

    And you're right, of course, people are doing this today (I've seen some nice demos by Scott Good, for example). But we want to make it a whole lot easier.

    @5 - Agree with your comment about feeds, just as I agreed with @4 too. I have written elsewhere about some ideas I have for improving access to data and services on Domino, and we're not giving up on that. The point about "mashups" is that it will likely involve a bunch o' code on the client side, too.

    If you don't like "mashlets", suggest another word!

    @6 - I think it will be the case that some Web apps of this style will be pre-assembled by a designer, and others will be more ad hoc, done by end users. Of course, those end users may also want to persist their assembly back to the server, so that it's there next time. This usage style would seem to imply the need for a browser-based design environment (even if a simpler one) too, right?

    @7 - Not sure what you mean by your reference to WSDL. WSDL is being used in Notes 8 to describe properties and actions in CompApps components (though the designer and certainly the end user never sees the xml).

    9Nathan T. Freeman  05/22/2007 4:07:49 PM  Mashups? Bashups ? Smashups ?

    @8 - Supposedly, in 8, we can consume web services via Lotuscript by importing a WSDL into a script library. At least, that's the impression I got from the designer behavior. But the information is vague to say the least.

    10Jake White  05/23/2007 10:25:05 AM  Mashups? Bashups ? Smashups ?

    Greetings -

    Here's a link to Alex Barnett's blog post on Mashup design patterns -- it seems to have good links to a variety of commentary on what a "mashup" is to others...

    { Link }

    (via the Daily Grind at { Link })

    11Scott Good  06/04/2007 11:54:30 AM  Mashups? Bashups? Smashups?

    Hi Bob,

    First, I completely agree that "mashup" and, even more so, "mashlet" are lame terms. I'm sure it will stick but as we saw with JSON, a good name goes a long way to gettting technology into the mainstream. Have to think about that...

    So, anyway.

    The thing you said which I'm surprised no one has jumped on is getting away from the need for WebSphere Portal (or the Notes rich client). I think that's an important goal.

    While I can appreciate why our good friends at IBM would like us all to buy, install and pay maintenance on WebSphere Portal implementations, making that a requirement of building a Domino mashup will immediately eliminate some huge percentage of the market simply because they (a) don't want the hassle, (b) don't want the expense, or (c) both.

    I love the idea of self-discovering elements but also agree that the best of these things are going to use multiple feeds. With only one feed you're pretty limited in what you can do inside the "rectangle." You're pretty limited in how sophisticated the presentation can be.

    With more feeds you have more options. We are constantly looking for real estate on the glass for our applications. Being able to make my rectangle able to do many different things based on the needs at the moment (think about the glass cockpits in today's aircraft) makes it potentially a much more powerful tool.

    But, above all else, don't force us to buy more stuff (WebSphere Portal) to use it (please).