Laurence picked up on this earlier today: EMC’s D6 Web Services Challenge. Whether you’re an established partner or an up-and-coming consultancy of one or more individuals, you’re invited to take the challenge and submit your entries in the next couple of months (i.e. by 9/28/2007 per contest rules). First prize is $50,000, with total prizes amounting to $100,000! This is a great chance to get your name and company established as a leader where the new Documentum Foundation Services (DFS) are concerned. So, please consider taking the challenge!
A few months back I posted my review of The Starbucks Experience. At the time I raised a concern to Starbucks: when you “outsource your experience” to someone else (e.g. to grocery stores such as Safeway or Albertsons), you run the risk of damaging your brand. The people running the Starbucks kiosk are employees of the grocery chain, not Starbucks. They don’t buy into the brand from an experience stand point, and apparently are not encouraged (e.g. via incentives) to do so by their employer (or indirectly by Starbucks).
Well, I recently had an awkward moment at a “true” Starbucks location. However, the customer service I received was quite positive. You see, I was without cash and without my wallet–except I came to realize this only after placing my order. The barista simply asked for my name so that she could correlate my transaction with my return, credit card in hand. Trust was emphasized: “I know you’ll come back. No worries.” Impressions like this are long-lasting.
Thanks, Starbucks and especially to the kind barista on Santa Rita Road!
Update 8/2/2007: I see that Marc Farley picked up this post. Who knew of the connection between Starbucks and iSCSI.
Yesterday Laurence talked about the challenges that a multitude of interfaces can present a solution builder, specifically in the context of ECM, and today Billy added his thoughts. While both posts seem to be focused more on visual interfaces (UI) than non-visual interfaces, the concerns raised apply to interfaces in general.
Here are my thoughts:
- I very much agree that it’s more a matter of should than can. Is the new UI or user experience relevant to my business? Does a new experience enable the retirement of any other experiences? Does a new experience lower training costs (e.g. is it more intuitive to my users)?
- At some level, all user experiences from a vendor should be consistent. However, one must also consider where ultimate experience control resides. For example, I see at least two major categories of users where ECM applications are concerned: (1) those who prefer a standalone experience, typically within their web browser of choice, and (2) those who prefer that the vendor provide an integrated experience within the primary applications serving the business’s knowledge work (e.g. Office applications, a third party portal, etc.).
- I agree with Laurence: UI should serve the task at hand; not the other way around. You have a job to accomplish and the provided experience should clarify and simplify that job–even anticipate next steps, etc.
- How a business is run and wants to be run will determine whether or not a solution has one or more graphical/visual aspects. Knowledge work is becoming more specialized; so, each user experience should be tailored specifically to the particular link in the value chain it serves. Some have called this approach “purpose-built applications” or “task-centric experiences.” At the same time, there are horizontal (cross-cutting) concerns with visual needs, too (e.g. CIO dashboards, BAM, management consoles for admins, etc.).
When you provide presentation tier code as part of your solution–“whole cloth UI’s” as Billy calls them, you should acknowledge that users can be a fickle bunch (read: today’s Lexus experience will become a Yugo eventually–it’s a matter of when, not if).
So you should have a well-factored architecture that separates business logic and services, which serve all your UI’s, from application logic and services, which serve a particular UI (e.g. web-based, Office-based, etc.). Doing so, should produce a “thin veneer” for a presentation layer, which is easier to evolve or replace. Again, the UI serves the task at hand; over time, a new UI may serve the task better.
Today Tim Bray reported that Atom is done. This is good news for the Web, and this is an important opportunity for ECM vendors.
I appreciate it when those involved in a standard take the time to share a concise vision for why the standard matters. According to Tim Bray, Atom’s raison d’être is “Publish” Everywhere. (Or, perhaps, publish-and-edit everywhere, reading last night’s IETF announcement.)
Others have already commented on the potentially powerful relationship between REST and ECM. Given APP’s RESTful approach and it’s focus on publishing and editing web resources (e.g. documents, multimedia, metadata), one should expect to see Atom (format and protocol) take hold across the ECM ecosystem.
It would be helpful to see someone like Sam Ruby, who directly participated in both the WebDAV and Atom working groups, would please comment on why WebDAV failed where Atom is seen to succeed. After all, the purpose of WebDAV–Web Distributed Authoring and Versioning–sounds very similar to Atom‘s present purpose. Both protocols rely on HTTP. Etc. Etc. Tim’s candid reply to a relevant IETF working group thread–“I’ve never really studied DAV”–is also unfortunate.
If, indeed, he’s in the majority, then how can a previous WebDAV and potential Atom standard adopter truly know when Atom-WebDAV divergence is intentional and appropriate, and not just accidental or lazy? Those who invested time in adding “checkin” and “checkout” to their authoring software on behalf of their WebDAV embrace, may be reluctant to add shiny new “publish button” supporting Atom, unless it’s clear how history won’t repeat itself (or rhyme, as Mark Twain would instead suggest).
Aside: In general, I find it difficult to talk with others about a standard that has more than one focus (e.g. SAML – (just another) token format or “the universal solvent of identity information,” Atom – feed format or publishing protocol, etc.). Sounds like Tim has similar concerns with the vague nature of “Atom” (without further qualification). Since “APP” is becoming a fairly common acronym for Atom Publishing Protocol, how about “AFF” for “Atom Feed Format (i.e. RFC 4287)? This could leave “Atom” for all-inclusive conversations (i.e. both APP and AFF).
While a quick Google of “cleartype vista” indicates that there is no universal warmth to Windows Vista’s ClearType support, I enjoy reading text in Vista more than I do in XP–even with the tuner powertoy for the down-level OS. I’d like to better understand Vista’s integration with ClearType in more detail; so, if you have a good link to share, thanks in advance.
This improved user experience around text and much-improved power management (i.e. extended battery life) have given my work laptop an unexpected boost in usability. There are still a set of issues that prevent me from recommending Vista generally to folks, and I’m hoping that SP1 later this year will address these completely. (I can always hope, right. )