Todd Biske: Outside the Box

Archive for the ‘UI’ Category

In this article from the Wall Street Journal, author Christopher Mims quotes mobile analytics company Flurry’s data that 86% of our time on mobile devices are spent in apps, and just 14% is spent on the web. While Christopher’s article laments that this is the “death of the web”, I’d like to put a different spin on this. We are now entering the age of what I call the “micro-UI”.

The micro-UI represents a shift toward very targeted user experiences focused on a much smaller set of capabilities. A phrase I’ve used is that we are now bringing the work to the user, rather than bringing the user to the work. It used to be that you only had access to a screen when you were in the den of your house with the desk with the built-in cabinet for your “tower” (why do they still sell those?) with a wired connection to your dialup modem, or your computer on your desk at work. Clearly, that’s no longer the case with smart phones, tablets, appliances, your car, and many more things with the capability to dynamically interact with you. I just saw rumors today about the screen resolution of the new Apple Watch, and I think it has higher resolution than my original Palm Pilot back in the late 90’s. On top of that, there are plenty of additional devices that can indirectly interact through low power bluetooth or other tethering techniques.

In this new era, the focus will be on efficiency. Why do I use an app on my phone instead of going to the mobile web site? Because it’s more efficient. Why do notifications now allow primitive actions without having to launch the app? Because it’s more efficient. It wouldn’t surprise me to even see notifications without the app in the future.

For example, how many of you have come home to the post-it on your door saying “FedEx was unable to deliver your package because a signature is required.” Wouldn’t it be great to get a notification on your phone instead that asks for approval before the driver leaves with your package in tow? But do you really want to have to install a FedEx app that you probably will never open? Why can’t we embed a lightweight UI in the notification message itself?

In the enterprise, there are more hurdles to overcome, but that should be no surprise. First, the enterprise is still filled with silos. If it were up to me, I would ban the use of the term “application” for anything other than referring to a user interface. Unfortunately, we’ve spent 30+ years buying “applications,” building silos around them, and dealing with the challenges it creates. If you haven’t already, you need to just put that aside and build everything from here on out with the expectation that it will participate in a highly connected, highly integrated world where trying to draw boundaries around them is a fruitless exercise. This means service-based architectures and context-launchable UIs (i.e. bring the user to the exact point in the user interface to accomplish the task at hand). Secondly, we need to find the right balance between corporate security and convenience. All of this era of connected devices rely on the open internet, but that doesn’t work very well with the closed intranet. Fortunately, I’m an optimist, so I’m confident that we’ll find a way through this. There are simply too many productivity gains possible for it not to happen.

I believe all of this is a good thing. I think this will lead to new and better user experiences, which is really what’s most important. Unlike Christopher’s article, I don’t see this as the death of the web, as without the web as the backing store for all of this information, none of this would be possible. It is a reduction in the use of a browser-based UI, and he’s correct that there are some good things about the web (e.g. linking) that need to be adapted (app linking and switching) to the mobile ecosystem. On the other hand, however, this increased connectivity present opportunities for higher productivity. Apple (e.g. Continuity), Google, Microsoft, and others are all over this.

All content written by and copyrighted by Todd Biske. If you are reading this on a site other than my “Outside the Box” blog, it’s probably being republished without my permission. Please consider reading it at the source.

I just posted a response to a question about the iPad in an enterprise setting over in an eBizQ forum and decided that I wanted to expand on it here in a blog post.

Much of the discussion about the iPad is still focusing on a feature by feature comparison to a netbook or a laptop. The discussion can not get out of the 20 year old world of keyboards, mice, and the windows and desktop metaphors. To properly think about what the iPad can do, you need to drop all of this context and think about things in new ways. In my previous post on the iPad, I emphasized this point, stating that the iPad is really about taking a new form of interaction (touch, with completely customizable interface) and putting it on a new form factor. In answering the eBizQ question, I realized that it goes beyond that. The key second factor is context awareness.

Back in 2007, I attended the Gartner Application Architecture, Development, and Integration Summit and the concept of “Context-Oriented Architecture” was introduced. In my blog post from the summit, I stated that:

[Gartner] estimates that sometime in the 2010’s, we will enter the “Era of Context” where important factors are presence, mobility, web 2.0 concepts, and social computing.

In that same post, I went on to state that this notion of context awareness will create a need for very lightweight, specific-purpose user interfaces. While at the time, I was leaning toward the use of Dashboard widgets or Vista sidebar items, but guess what has taken over that category? iPhone and iPod Touch apps. Now, we have the potential for a device with a larger form factor that can present a touch-based interface, completely tailored to the task at hand. This is another reason why I don’t see multi-tasking as a big deal. The target for this audience isn’t multi-tasking, it’s for these efficient, single-purpose interfaces. Imagine going into a conference room where your iPad is able to determine your meeting room through sensors in the building, where it knows what meeting you’re in and who else is in the room through calendar integration, it knows the subject of the meeting, and can now present you with a purpose-driven interface for that particular meeting. Our use of information can be made much more efficient. How many times have you been in a meeting only to wind up wasting time navigating around through your files, email, the company portal, etc. trying to find the right information. What if you had an app that organized it all and through context awareness, presented what you needed? The same certainly holds true for other activities in the enterprise beyond meetings. As we have more use of BPM and Workflow technologies, it is certainly possible that context awareness through location, time, presence of others, and more can allow more appropriate and efficient interfaces for task display and execution, in addition to providing context back into the system to aid in continuous improvement.

This isn’t going to happen overnight, but I am very excited to see whether Gartner’s prediction of the 2010’s being the “era of context” comes true. I think it will, and it will be great to look back from 2020 and see just how much things have changed.

All content written by and copyrighted by Todd Biske. If you are reading this on a site other than my “Outside the Box” blog, it’s probably being republished without my permission. Please consider reading it at the source.

I couldn’t resist sharing my thoughts about the iPad along with every other technology pundit out there. I’m very intrigued by the possibilities of the iPad. From what was announced on stage, there’s nothing that immediately jumps out to say, “Wow, this is going to change world.” The reason for this, however, is because that ship already set sail with the iPhone/iPod touch. I recently read an article about Apple’s approach to user interface technology, and how the touchscreen display was really the game changer. Why be burdened by a full keyboard if you don’t need it? Instead, allow the interface to be fully customizable to the task at hand. The iPhone/iPod touch did this. The iPad is a recognition that the small form factor of the iPhone is simply not suitable for all applications. If the handheld form factor is class one, then something around the size of a sheet of paper is form factor two. Anything bigger than that starts to make more sense in a desktop setting, rather than being primarily portable.

Given this angle, I think the iPad positioning makes a lot of sense. Frankly, it’s surprising we haven’t reached this point sooner. Way back in the early nineties, I took a seminar course in graduate school on human computer interaction, and four or five students had to engage in panel discussion on where interfaces would go five or ten years from then. I don’t think a single one of them expected the keyboard and mouse to still be the dominant UI technology almost twenty years later, but that is the case. It’s time to recognize that while well suited for some activities, that interface is also a boat anchor for other activities. A platform like the iPad now opens things up to more customized interfaces that may be much more efficient and intuitive for tasks. Ironically, I think it’s this same thinking that pushed Apple away from the original web-based focus of the original iPhone and into the world of custom apps. While a developer may be able to reach a wider audience with a browser based application, that’s at the sacrifice of the UI, despite AJAX, Flash, HTML 5. This is also why I don’t see Flash support as a big deal. Yes, it prevents us from watching browser based video, but I’d much rather have a specialized app with a more intuitive interface for doing so. Why be burdened by the web browser if you don’t have to?

So, is the iPad revolutionary? No, I think it’s evolutionary from the iPhone/iPod touch. I’m very interested to see what applications can be developed for this form factor for the educational and medical markets. On a laptop, it’s likely that those advanced applications would have required a desk, because there’s just no way to hold the laptop, with it’s keyboard, and try to manipulate the track pad, pointer nub (whatever it’s called), or a mouse to achieve the interaction needed. With the iPad, it’s cradled in one arm, with your other hand free. You can have advanced interactions. This is where it will show its stuff. Just as the iPhone didn’t have too much to show with v1, but the partner apps became much more sophisticated with the 3G and the 3GS, the same will be true with the iPad. Two to three weeks didn’t allow partners to show much at the kickoff, but I think we’ll all look back a year from now and see some revolutionary apps that have been freed from the burden of the keyboard and mouse interface.

In a RIA Weekly podcast, Michael Coté and Ryan Stewart had a brief conversation on the role of RIAs in portals. They didn’t go into much details on it, but it was enough to get me noodling on the subject.

In the past, I’ve commented on the role of widgets/gadgets ala Apple’s Dashboard and Vista’s Sidebar and how I felt there was some significant potential there. To date, I haven’t seen any “killer app” on the Mac side (I have no idea about Vista given that I don’t use it at home or at work). One thing that I found curious, however, was that when I went looking for a decent Twitter client for the Mac, there was no shortage of dashboard widgets, but actually very few desktop apps. I wound up choosing Twirl initially, and am now using TweetDeck. Both of these are Adobe AIR applications.

So what does this have to do with portals? Well, my own view is that your desktop is a portal. A portal should contain easy access to all of things you need to do to do your job. The problem with desktops today, however, is that the typical application is so bloated, that the startup/quit process is very unproductive, and if you leave them open all the time, you need dual monitors (or a really big monitor) and a boatload of memory (even though most isn’t getting used). For this reason, I still really like the idea of these small, single-purpose widgets that do one thing really well. The problem with it right now, however, is that Dashboard and Sidebar fall into the out-of-sight/out-of-mind category. I want my Twitter client in a visible portion of my desktop at all times, or at least with the ability to post a visual notification somewhere. If I leverage a Dashboard widget, it’s invisible to me unless I hit a function key. It’s out-of-band by intent. There are things that belong there. That being said, the organizational features of Dashboard could easily be applied to the desktop, as well. If I had a bunch of lightweight widgets that I used to do the bulk of my work always available on my desktop, that would be great. It had better perform better than the current set of applications that I have set to start at login, however.

Where does RIA fit in? I don’t know that I’d need portability from my desktop in a browser-based portal environment. I’m sure there a people out there that do everything they need to do on a daily basis via Firefox and a whole bunch of plugins. I’ve never tried it, nor do I have any interest in doing so, but for people in that camp, common technology between a desktop portal and a browser-based portal could be a good thing for them. For me, my primary interest is simply getting a set of lightweight tools for 80% of my day-to-day tasks that aren’t so bloated with stuff I don’t need. I thought a bit about portability of my desktop environment across machines (i.e. the same TweetDeck columns at work and at home), but I think that’s more dependent on these widgets storing data in the cloud than it is on storing the definition of my desktop in the cloud somewhere, but that might be of interest, as well.

The gist of all of this is that I do believe there are big opportunities out there to make our interaction with our information systems more efficient. Can RIAs play a role? Absolutely, but only if we focus on keeping them very lightweight, and very usable.

Presenter: Anthony Bradley

This presentation has started out with the unsurprising news that enterprise adoption of mashups is significantly trailing its use in the open Internet. He’s come up with a two-faceted classification model for mashups. The first facet is the integration pattern, which is one or more of the following (these aren’t mutually exclusive):

• Visualization integration
• Content integration
• Gadget page space co-location
• Gadget page space integration

The second facet is the application type, which can be one of:

• Personal portal delivery
• Packaged application extension
• Location awareness
• Panoramic awareness
• Situational awareness

All in all, I’m not sure what value this is bringing. I’ve posted previously on categorizations and taxonomies and how they need to have some purpose behind them. I’m not seeing the purpose behind these classifications. Typically, I’ve used classifications in reference architecture work where I try to map a particular type to particular constraints/patterns on the architecture and design, and I don’t see how these groupings do that.

He now had one slide that talks about the need to architect systems that allow them to be “mashable.” This I agree with, but again, it’s nothing new. We’ve been talking about this since the early days of portals, and you could even argue that it’s been around longer than that. He did present a proposed architecture for some of this at the end that may prove valuable to some attendees. Unfortunately, I don’t think he convinced anyone in the audience that mashups is something they should be thinking about. Personally, I think even the term puts some people off. I’d rather hear about the need to support “integration at the glass.” There’s too much of an association between mashups and just throwing something on a Google Map to make it have broader appeal, in my opinion.

I’ve recently been trying to help out with an issue which has required me to roll up my sleeves a bit, and unfortunately it has brought pack all too familiar memories. Our computer systems (and often the documentation that goes along with it) simply makes things way too difficult. In my opinion, the thing that I’m trying to do should be a relatively straightforward function, but as I’ve dug into it, I just seem to run into an endless set of configuration parameters that need to be specified. Now, while I’m pretty far removed from my days as a developer, I still consider myself tech savvy and a very quick learner. I can’t help but think what the average joe must go through to try to make these things work. It’s almost as if these systems were written to ensure a marketplace for systems integrators and other consultants.

This all comes back to usability and human-computer interaction, areas that have always been a passion of mine. If your products aren’t usable, it’s simply going to create frustration and distrust. If your documentation or support channels are equally poor, the situation will continue to go down. What’s even worse is when there isn’t a workaround, and the only option left to a user is to find an expert who can help. As a user, I don’t like to be painted into a corner where I have no options. We need to keep these things in mind when we build our own systems for our business partners. If we design systems that aren’t usable and require that the business come find someone in IT every time they try to do certain options, that’s a recipe for disaster. If you don’t have a usability team in your organization, I strongly urge you to find some experts and start building one.

While I didn’t attend the later session on it, in the opening keynote of the AADI Summit on Monday, the term “Context-Oriented Architecture” was mentioned. A colleague (thanks Craig!) caught me in the hall and asked me what my thoughts were on it, and as usual, my brain starting noodling away and the end result was me leaving the conversation saying, “you’ll see a blog entry on this very soon!”

I’ve brought up the slides from the Gartner session on it, and they estimate that sometime in the 2010’s, we will enter the “Era of Context” where important factors are presence, mobility, web 2.0 concepts, and social computing. The slides contain a new long acronym, WYNIWYG (Winnie Wig?), which stands for “What You Need is What You Get.” While it seems that the Gartner slides emphasize the importance that mobility will have in this paradigm, I’d like to bring it back into the enterprise context. While mobility is very important, there is still a huge need for WYNIWYG concepts in the desktop context. There will be no shortage of workers who still commute to the office building each day with the computer in their cube or their desktop being their primary point of interaction with the technology systems.

I think the WYNIWYG acronym captures the goal: what you need is what you get. The notion of context, however, implies that what you need changes frequently within a given day. Keith Harrison-Broninski, in his book Human Interactions, discusses how a lot of what we do is driven by the role we are playing at that point in time. If we take on multiple roles during the course of our day, shouldn’t we have context-sensitive interfaces that reflect this? If you’re asking the question, “Isn’t this the same thing as the personalization wave that went in (and out?) with web portals?” I want to make a distinction. Context-sensitivity has to be about productivity gains, not necessarily about user satisfaction gains. Allowing a user to put a “skin” on something or other look and feel tweaks may increase their overall level of satisfaction, but it may not make them any more productivity (I’m not implying that look and feel was the only thing that the personalization wave was about, but there was certainly a lot of it). As a better example of context-sensitivity, I point to the notion of Virtual Desktops. This has been around since the days of X Windows, with the most recent incarnation of it being Apple’s Spaces technology within Leopard. With this approach, I can put certain windows on “Virtual desktops” rather than have all of them clutter up a single desktop. With a keystroke, I can switch between them. So, a typical developer may have one “desktop” that has Eclipse open and maximized, and another “desktop” that has Outlook or your favorite mail client of choice, etc. Putting them all in one creates clutter, and the potential for interruptions and productivity losses when I need to shift (i.e. context-shift) from coding to responding to email.

Taking this beyond the developer, I bring in the advent of BPM and Workflow technologies. I’ve blogged previously on how I think this will create a need for very lightweight, specific-purpose user interfaces. Going a step further, these entry points should all be context-sensitivie. I’m doing this particular task, because I’m currently playing this role. Therefore, somehow, I need to have an association between a task and a role, and the task manager on my desktop needs to be able to interact with the user interaction container (not any one specific user interface, but rather a collection of interfaces) in a context-sensitive manner to present what I need. In our discussion, he brought up an example of an employee directory. An employee directory itself probably doesn’t need to be context aware. What does need to be context-aware is the presence or lack thereof of the employee directory depending on the role I’m currently playing. Therefore, it’s the UI container that must be context-sensitive.

All in all, this was a very interesting discussion. In looking at the Gartner slides, I definitely agree that this is a 2010+ sort of thing, but if you’re in a position to jump out (way) ahead of the curve, there’s probably some good productivity gains waiting to be had. I recommend getting pretty comfortable with your utilization of BPM technology first, and then moving on to this “era of context.”

I recently had a conversation with Ron Schmelzer of ZapThink and we started talking about how the nature of the entry point for enterprise users to interact with the information technology will change in the future. You’ll notice that I didn’t use the term “application” in that sentence and there’s a reason for that. Personally, I want to get rid of it. To me, it implies a monolith. It’s a collection of functionality that by its very nature goes against the notion of agility. When I look at a future state where we’re leveraging BPM, SOA, and Workflow technology, I see very small, lightweight entry points that are short and to the point. I’ve mentioned this before in connection with Vista Gadgets or MacOS X Dashboard Widgets.

Ron brought up a ZapFlash that came out over a year ago that he wrote called “SOA: Enabling the Long Tail of IT.” I didn’t make the connection at the time, but it makes perfect sense now. In the ZapFlash, Ron describes the “Long Tail” this way:

The Long Tail, a term first coined and popularized by Chris Anderson, refers to the economic phenomenon where products that are of interest to only small communities, and thus result in low demand and low sales volume, can collectively result in a large aggregate market. This large collection of small markets can significantly exceed the more traditional market that the most popular and high volume sales items can generate. For example, Amazon.com generates more business in aggregate from its millions of books that each only sell a few copies than they do from the top 100 best sellers that might each sell tens of thousands of units.
One quick way of summing up the Long Tail is by saying that thereís more opportunity in catering to a mass of niche markets than a niche of mass markets. Large enterprises in particular are composed of masses of such niches, operating in different geographies and business units, catering to specific demographics with tailored solutions to meet the needs of all constituents. And yet, the centralized IT organization that serves the needs of the entire organization is typically woefully unprepared to serve these masses of niches: large numbers of users with widely varying IT needs. How, then, can IT support the needs shared in common with all the business groups without overextending its centralized resource to meet the specific needs of each of the individual groups?

Fundamentally, we’re both talking about the same thing. What I describe as very lightweight user-facing entry points are the “long tail” of applications. They’re small, niche solutions that get the job done. Underlying all of this is a robust SOA that are the enablers of these solutions which is loosely-coupled from the user-facing needs. If you think about it, the long tail of application development today is the business user using Excel because they could get done what they needed quickly. I’ve even done this myself, and even progressed up to getting a simple database setup to do a bit more. We shouldn’t be on a quest to squash these out, but rather to figure out how to enable it in a manageable way. The problem is not that somebody’s Excel macro pulling data out of Oracle exists, the problem is that we’re not aware that it exists. Clearly, someone had a need to put it together, and if we can find a way to enable this to where we’re aware of it and our systems support it easily, even better. Personally, I think the technologies we have at our disposal today are on track for making this a reality.

Another Briefings Direct SOA Insights podcast has been posted by Dana Gardner in which I’m a panelist. In this edition, Dana, myself, Joe McKendrick, and indepdent blogger Barb Darrow discussed the role of RIA and rich media with SOA and the impact of associated technologies, such as Flash, AJAX, and Silverlight on the space. You can find a full transcript here or listen to it here. You can also subscribe via iTunes.

Brandon Satrom posted some of his thoughts on the need for a composite application framework, or CAF, on his blog and specifically called me out as someone from which he’d like to hear a response. I’ll certainly oblige, as inter-blog conversations are one of the reasons I do this.

Brandon’s posted two excerpts from the document he’s working on, here and here. The first document tries to frame up the need for composition, while the second document goes far deeper into the discussion around what a composite application is in the first place.

I’m not going to focus on the need for composition for one very simple reason. If we look at the definition presented in the second post, as well as articulated by Mike Walker in his followup post, composite applications are ones which leverage functionality from other applications or services. If this is the case, shouldn’t every application we build be a composite application? There are vendors out there who market “Composite Application Builders” which can largely be described as EAI tools focused on the presentation tier. They contain some form of adapter for third party applications, legacy systems, that allow functionality to be accessed from a presentation tier, rather than as a general purpose service enablement tool. Certainly, there are enterprises that have a need for such a tool. My own opinion, however, is that this type of an approach is a tactical band-aid. By jumping to the presentation tier, there’s a risk that these integrations are all done from a tactical perspective, rather than taking a step back and figuring out what services need to be exposed by your existing applications, completely separate from the construction of any particular user-facing application.

So, if you agree with me that all applications will be composite applications, then what we need is not a Composite Application Framework, but a Composition Framework. It’s a subtle difference, but it gets us away from the notion of tactical application integration and toward the strategic notion of composition simply being part of how we build new user-facing systems. When I think about this, I still wind up breaking it into two domains. The first is how to easily allow user-facing applications to easily consume services. Again, in my opinion, there’s not much different here than the things you need to do to make services easily consumable, regardless of whether or not the consumer is user-facing or not. The assumption needs to be that a consumer is likely to be using more than one service, and that they’ll have a need to share some amount of data across those services. If the data is represented differently in those services, we create work for the consumer. The consumer must translate and transform the data from one representation to one or more additional representations. If this is a common pattern for all consumers, this logic will be repeated over and over. If our services all expose their information in a consistent manner, we can minimize the amount of translation and transformation logic in the consumer, and implement it once in the provider. Great concept, but also a very difficult problem. That’s why I use the term consistent, rather than standard. A single messaging schema for all data is a standard, and by definition consistent, but I don’t think I’ll get too many arguments that coming up with that one standard is an extremely difficult, and some might say impossible, task.

Beyond this, what other needs are there that are specific to user-facing consumers? Certainly, there are technology decisions that must be considered. What’s the framework you use for building user-facing systems? Are you leveraging portal technology? Is everything web-based? Are you using AJAX? Flash? Is everything desktop-based using .NET and Windows Presentation Foundation? All of these things have an impact on how your services that are targeted for use by the presentation tier must be exposed, and therefore must be factored into your composition framework. Beyond this, however, it really comes down to an understanding of how applications are going to be used. I discussed this a bit in my Integration at the Desktop posts (here and here). The key question is whether or not you want a framework that facilitates inter-application communication on the desktop, or whether you want to deal with things in a point-to-point manner as they arise. The only way to know is to understand your users, not through a one-time analysis, but through continuous communication, so you can know whether or not a need exists today, and whether or not a need is coming in the near future. Any framework we put in place is largely about building infrastructure. Building infrastructure is not easy. You want to build it in advance of need, but sometimes gauging that need is difficult. Case in point: Lambert St. Louis International Airport has a brand new runway that essentially sits unused. Between the time the project was funded and completed, TWA was purchased by American Airlines, half of the flights in and out were cut, Sept. 11th happened, etc. The needs changed. They have great infrastructure, but no one to use it. Building an extensive composition framework at the presentation tier must factor in the applications that your users currently leverage, the increased use of collaboration and workflow technology, the things that the users do on their own through Excel, web-based tools, and anything else they can find, how their job function is changing according to business needs and goals, and much more.

So, my recommendations in this space would be:

1. Start with consistency of data representations. This has benefits for both service-to-service integration, as well as UI-to-service integration.
2. Understand the technologies used to build user-facing applications, and ensure that your services are easily consumable by those technologies.
3. Understand your users and continually assess the need for a generalized inter-application communication framework. Be sure you know how you’ll go from a standard way of supporting point-to-point communication to a broader communication framework if and when the need becomes concrete.

In addition to commenting on my blog, Francis Carden, CEO of OpenSpan, also was kind enough to give me a short demo of their product. In my previous post, I introduced the concept of a “Desktop Service Bus” and wondered if the product would behave in this fashion. One of the interesting things I hadn’t thought of, however, is exactly what a desktop service bus should behave like? For that matter, what’s the right model of working with an enterprise service bus? More on that in a second.

Francis did a nice little demonstration for me that showed how custom integrations could be built quickly, first by interrogating existing applications (desktop or web-based) and grabbing possible integration points (virtually any UI element on the screen), and then by using a visual editor to connect up components in a pipeline-like manner. If you’re familiar with server-side application integration technologies, think of this tool as providing an orchestration environment, as well as the ability to build adaptors on the fly through interrogation.

Clearly, this is a step in the right direction. Francis made a great comment to me, which was, “People stopped thinking about this [desktop integration] because they’d long forgotten it was possible.” He’s right about this. With the advent of web-based applications, many people stopped talking about OLE and other desktop application integration techniques. The need hasn’t gone away, however. Again, using the iPhone as an example, many people complain about its lack of cut-and-paste capabilities.

Bringing this back to my concept of a desktop service bus, there clearly is a long way to go. When I see tools like OpenSpan or Apple’s Automator, it’s clear that they’re targeted at when a need to integrate is determined after the fact. You have two systems that no one had thought of integrating previously, but now there is a need to do so. This is no different than integration on the server side, except that you’re much more likely to hear the term “silo” used. When I think about the concept of a desktop service bus, or even an enterprise service bus for that matter, the reason a usage metaphor doesn’t immediately come to mind is that it’s not the way we’ve traditionally done things. When we’re building a new solution, the collection of services available should simply be there. There’s a huge challenge in trying to organize them, but if we can organize all of the classes in the Java API’s and all of the variety of extensions through intelligent code completion, why can’t we do the same with services, whether available through a network interaction or through desktop integration? It will take a while before this becomes the norm, but thankfully, I think the connectivity of the web is actually helping in this regard. Users of sites like Flickr, Facebook, Twitter, MySpace and the like expect the ability to mash and integrate, whether with their mobile phones, their desktop machines, other web sites, and more. Integration as the norm will be a requirement going forward.

One of my email alerts brought my attention to this article by Rich Seeley, titled “Desktop Integration: The last mile for SOA.” It was a brief discussion with Francis Carden, CEO of OpenSpan Inc. on their OpenSpan Platform. While the article was light on details, I took a glance at their web site, and it seems that the key to the whole thing is this component called the OpenSpan Integrator. Probably the best way to describe it is as a Desktop Service Bus. It can tap into the event bus of the underlying desktop OS. It can communicate with applications that have had capabilities exposed as services via the OpenSpan SOA Module, probably through the OpenSpan Studio interrogation capability. This piqued my interest, because it’s a concept that I thought about many years ago when working on an application that had to exist in a highly integrated desktop environment.

Let’s face it, the state of the art in desktop integration is still the clipboard metaphor. I cut or copy the information I want to share from one application to a clipboard, and then I paste it from the clipboard into the receiving application. In some cases, I may need to do this multiple times, one for each text field. Other “integrated” applications, may have more advanced capabilities, typically a menu or button labeled “Send to ABC…” For a few select things, there are some standard services that are “advertised” by the operating system, such as sending email, although it’s likely that these are backed by operating system APIs put in place at development time. As an example, if I click on a mailto: URL on a web page, that’s picked up by the browser, which executes an API call to the underlying OS capabilities. The web page itself can not publish a message to a bus on the OS that says, “Send an email to user joe@foobar.com with this text.” This is in contrast to a server-side bus where this could be done.

In both the server-side and the desktop, we have the big issue of not knowing ahead of time what services are available and how to represent the messages for interacting with them. While a dynamic lookup mechanism can handle the first half of the problem, the looming problem of constructing suitable messages still exists. This still is a development time activity. Unfortunately, I would argue that the average user is still going to find an inefficient cut and paste approach less daunting than trying to use some of the desktop orchestration tools, such as Apple’s Automator for something like this.

I think the need for better integration at human interaction layer is even more important with the advances in mobile technology. For example, I’ve just started using the new iPhone interface for FaceBook. At present, there is no way for me to take photos from either the Photos application or the Camera application and have them uploaded to FaceBook. If this were a desktop application, it isn’t much better, because the fallback is to launch a file browser and require the user to navigate to the photo. Anyone who’s tried to navigate the iPhoto hierarchy in the file system knows this is far from optimal. It would seem that the right way to approach this would be to have the device advertise Photo Query services that the FaceBook app could use. At the same time, it would be painful for FaceBook if they have to support a different Photo Query service for every mobile phone on the market.

The point of this post is to call some attention to the problem. What’s good for the world of the server side can also be good for the human interaction layer. Standard means of finding available services, standard interfaces for those services, etc. are what will make things better. Yes, there are significant security issues that would need to be tackled, especially when providing integration with web-based applications, but without a standard approach to integration, it’s hard to come up with a good security solution. We need to start thinking about all these devices as information sources, and ensuring that our approach to integration handles not just the server side efforts, but the last mile to the presentation devices as well.

Richard Monson-Haefel posted a great piece on his blog on widgets and gadgets (also posted on the Burton Group APS blog here). It serves as a good introduction to them. After a thorough definition, he primarily focuses on their use in a consumer setting. As a followup, I’d like to see him post more on their role in the enterprise. It’s something I’ve commented on, as well as Om Malik. As I’ve stated previously, I really think they have a potential role in workflow-based solutions as a vehicle for providing lightweight interfaces that are single-purpose in nature, that is, they provide an interface for doing exactly the task that needs to be done, nothing more, nothing less. They start up quickly and they go away quickly. Hopefully Richard will take the bait.