Recently in Information Architecture Category

Update - We have received a phenomenal number of proposals – almost 50% more than last year. We have also had a huge number of requests for extensions, so we have extended the deadline for speaking proposals through next week – until May 28th. Don’t delay though, as our program committee is already pouring over the proposals we have.

Proposal Deadline: May 16th 28th, 2011

The Gilbane conference is all about helping organizations apply content, web and mobile technologies to communicate with their ecosystem of customers, employees, suppliers, partners, and the rest of the world in the most effective and efficient way possible.

This means understanding what technologies can and can't do, what practices in applying them succeed or fail, and how to plan for changes in market and technology evolution. We bring together a diverse audience of technologists, marketers, strategists, business managers and analysts to learn, share, and debate best practices and strategies. Our conference is organized into four tracks so attendees in marketing, technology, a business unit, or an internal function will be able to plan a customized agenda.

To submit a proposal for a presentation or panel to contribute your expertise and experience, please see the topics below listed for the four tracks, then follow the instructions and guidelines for submitting proposals using our proposal submission form. Send any questions to speaking@gilbaneboston.com. 

You can also learn more by visiting the conference website at http://gilbaneboston.com, where you can also see information from our 2010 conference. 

Customers & Engagement track
Topics to be covered include: Web content management, content strategies, analytics, web design and UI, social media, digital and cross channel marketing, rich media, global reach, multilingual practices, personalization, information architecture, designing for mobile devices, e-commerce, search engine optimization. Read more

Colleagues & Collaboration track
Topics to be covered include: Collaborative authoring, intranets, knowledge management, search, wikis, micro-blogging and blogging, managing social and user-generated content, integrating social software into enterprise applications, SharePoint, portals, social software platforms, enterprise 2.0 strategies. Read more

Content Technologies track
Topics to be covered include: Multi-lingual technologies and applications, smartphone, iPad and tablet app development, XML, standards, integration, content migration, search, open source, SaaS, semantic technologies, social software, SharePoint, and relevant consumer technologies. Read more

Cross-channel Publishing track
Topics to be covered include: Multi-channel publishing, multi-lingual publishing, mobile app and digital product development and marketing strategies for the iPad, and other tablets and ebook readers, mobile content management, digital rights, digital asset management, DITA, documentation, structured content, and XML. Read more

http://gilbaneboston.com/speaker_guidelines.html

http://gilbaneboston.com/speaker-submission-form.html

Follow the conference on Twitter at http://twitter.com/gilbaneboston. Tag: gilbaneboston

Questions?: speaking@gilbaneboston.com

Sneak peek at the conference community site to be announced next week.

LinkedIn today announced Signal, a new feature (currently in beta) that lets members see an activity stream that combines LinkedIn status updates and Twitter posts from other members who have opted-in to the feature. LinkedIn has licensed the Twitter firehose to incorporate all of its members' tweets into the site, not just tweets with the #in hashtag embedded, as is current practice.

While it is hard to imagine anyone other than corporate and independent talent recruiters will make LinkedIn their primary Twitter client, Signal does have an element that is worthy of emulation by other social networks and enterprise social software providers that incorporate an activity stream (and which of those does not these days!) That feature is role-specific filters.

I wrote previously in this post about the importance of providing filters with which individuals can narrow their activity stream. I also noted that the key is to understand which filters are needed by which roles in an organization. LinkedIn apparently gets this, judging by the screenshot pictured below.

Notice the left-hand column, labeled "Filter by". LinkedIn has most likely researched a sample of its members to determine which filters would be most useful to them. Given that recruiters are the most frequent users of LinkedIn, the set of filters displayed in the screenshot makes sense. They allow recruiters to see tweets and LinkedIn status updates pertaining to LinkedIn members in specific industries, companies, and geographic regions. Additionally, the Signal stream can be filtered by strength of connection in the LinkedIn network and by post date.

The activity stream of every enterprise social software suite (ESS) should offer such role-based filters, instead of the generic ones they currently employ. Typical ESS filtering parameters include individuals, groups or communities, and workspaces. Some vendors offer the ability to filter by status as a collaborator on an object, such as a specific document or sales opportunity. A few ESS providers allow individuals to create custom filters for their activity stream. While all of these filters are helpful, they do not go far enough in helping individuals narrow the activity stream to view updates needed in a specific work context.

The next logical step will be to create standard sets of role-based filters that can be further customized by the individuals using them. Just as LinkedIn has created a filter set that is useful to recruiters, ESS providers and deploying organizations must work together to create valuable filter sets for employees performing specific jobs and tasks. Doing so will result in increased productivity from, and effectiveness of, any organization's greatest asset – it's people.

Following my post last week on the need for additional filters in enterprise microblogging tools and activity streams, I participated in an interesting Twitter conversation on the subject of microblogging and complexity. The spontaneous conversation began when Greg Lowe, a well-respected Enterprise 2.0 evangelist at Alcatel-Lucent, asked:

"Can stand alone micro-blogging solutions survive when platform plays introduce the feature?"

I immediately replied:

"Yes, if they innovate faster"

Greg shot back:

"is microblogging autonomy about innovation, or simple elegance? More features usually leads to lower usability?"

And, later, he asked a complementary question:

"is there a risk of Microblogging becoming "too complicated"?"

Is Greg on to something here? Do more features usually lead to lower usability? Will functional innovation be the downfall of stand-alone microblogging solutions, or will it help them stay ahead of platform vendors as they incorporate microblogging into their offerings?

One of the commonly heard complaints about software in general, and enterprise software in particular, is that it is too complicated. There are too many features and functions, and how to make use of them is not intuitive. On the other hand, usability is a hallmark of Web 2.0 software, and, if we make it too complex, it is likely that some people will abandon it in favor of simpler tools, whatever those may be.

But that dichotomy does not tell the entire story. Based on anecdotal evidence (there is no published quantitative research available), early adopters of Web 2.0 software in the enterprise appear to value simplicity in software they use. However, as a colleague, Thomas Vander Wal, pointed out to me yesterday, that may not be true for later, mainstream adopters. Ease-of-use may be desirable in microblogging (or any other) software, but having adequate features to enable effective, efficient usage is also necessary to achieve significant adoption. Later adopters need to see that a tool can help them in a significant way before they will begin to use it; marginal utility does not sway them, even if the tool is highly usable.

Simple may not be sustainable. As I wrote last week in this post, as enterprise use of microblogging and activity streams has increased and matured, so has the need for filters. Individuals, workgroups, and communities want to direct micro-messages to specific recipients, and they need to filter their activity streams to increase their ability to make sense out of the raging river of incoming information. Those needs will only increase as more workers microblog and more information sources are integrated into activity streams.

In the public microblogging sphere, Twitter provides a solid example of the need to add functionality to a simple service as adoption grows in terms of registered users and use cases. As more individuals used Twitter, in ways that were never envisioned by its creators, the service responded by adding functionality such as search, re-tweeting, and lists. Each of these features added some degree of complexity to the service, but also improved its usability and value.

In the evolution of any software, there is a trade-off between simplicity and functionality that must be carefully managed. How does one do that? One way is to continuously solicit and accept user feedback. That allows the software provider and organizations deploying it to sense when they are nearing the point where functionality begins to overwhelm ease of use in a harmful manner. Another technique is to roll out new features in small doses at reasonable intervals. Some even advocate slipping new features in unannounced and letting users discover them for themselves. Hosted deployment of software (whether on-premise or off-site) makes this easier to do, since new features are automatically switched on for people using the software.

So back to the original question; can stand-alone microblogging solutions fend off the collaboration suite and platform vendors as they incorporate microblogging and activity streams in their offerings? My definitive answer is "yes", because there is still room for functionality to be added to microblogging before it becomes over-complicated.

Based on the historical evolution of other software types and categories, it is likely that the smaller vendors, who are  intensely focused on microblogging, will be the innovators, rather than the platform players. As long as vendors of stand-alone microblogging offerings continue to innovate quickly without confusing their customers, they will thrive. That said, a platform vendor could drive microblogging feature innovation if they so desired; think about what IBM has done with its Sametime instant messaging platform. However, I see no evidence of that happening in the microblogging sphere at this time.

The most plausible scenario is that at some point, small, focused vendors driving microblogging innovation (e.g. Socialcast, Yammer) will be acquired by larger vendors, who will integrate the acquired features into their collaboration suite or platform. My sense is that we are still 2-3 years away from that happening, because there is still room for value-producing innovation in microblogging.

What do you think?

The use of microblogging and activity streams is maturing in the enterprise. This was demonstrated by recent announcements of enhancements to those components in two well-regarded enterprise social software suites.

On February 18th, NewsGator announced a point release to its flagship Enterprise 2.0 offering, Social Sites 3.1. According to NewsGator, this release introduces the ability for individuals using Social Sites to direct specific microblogging posts and status updates to individuals, groups, and communities. Previously, all such messages were distributed to all followers of the individual poster and to the general activity stream of the organization. Social Sites 3.1 also introduced the ability for individuals to filter their activity streams using "standard and custom filters".

Yesterday (March 3rd), Socialtext announced a major new version of its enterprise social software suite, Socialtext 4.0. Both the microblogging component of Socialtext's suite and its stand-along microblogging appliance now allow individuals to broadcast short messages to one or more groups (as well as to the entire organization and self-selected followers.) Socialtext 4.0 also let individuals filter their incoming activity stream to see posts from groups to which they belong (in addition to filtering the flow with the people and event filters that were present in earlier versions of the offering.)

The incorporation of these filters for outbound and incoming micro-messages are an important addition to the offerings of NewsGator and Socialtext, but they are long overdue. Socialcast has offered similar functionality for nearly two years and Yammer has included these capabilities for some time as well (and extended them to community members outside of an organization's firewall, as announced on February 25th.) Of course, both Socialcast and Yammer will need to rapidly add additional filters and features to stay one step ahead of NewsGator and Socialtext, but that represents normal market dynamics and is not the real issue. The important question is this:

What other filters do individuals within organizations need to better direct microblogging posts and status updates to others, and to mine their activity streams?

I can easily imagine use cases for location, time/date, and job title/role filters. What other filters would be useful to you in either targeting the dissemination of a micro-message or winnowing a rushing activity stream?

One other important question that arises as the number of potential micro-messaging filters increases is what should be the default setting for views of outgoing and incoming messages? Should short bits of information be sent to everyone and activity streams show all organizational activity by default, so as to increase ambient awareness? Perhaps a job title/role filter should be the default, in order to maximize the focus and productivity of individuals?

There is no single answer other than "it depends", because each organization is different. What matters is that the decision is taken (and not overlooked) with specific corporate objectives in mind and that individuals are given the means to easily and intuitively change the default target of their social communications and the pre-set lens through which they view those of others.

Box.net announced today that it has integrated its cloud-based document storage and sharing solution with Salesforce.com. Current Box.net customers that want to integrate with Salesforce CRM can contact Box.net directly to activate the service. Salesforce.com customers may now download Box.net from the Salesforce.com AppExchange.

Box.net services will now be available in the Lead, Account, Contact, and Opportunity tabs of Salesforce CRM. In addition, the Box.net native interface and full range of services will be accessible via a dedicted tab on the Salesforce CRM interface. Users can upload new files to Box.net, edit existing files, digitally sign electronic documents, and e-mail or e-fax files. Large enterprise users will be given unlimited Box.net storage. The Box.net video embedded below briefly demonstrates the new Salesforce CRM integration.

While Box.net started as a consumer focused business, today's announcement marks the first tangible manifestation of its emerging enterprise strategy. Box.net intends to be a cloud-based  document repository that can be accessed through a broad range of enterprise applications.

The content-as-a-service model envisioned by Box.net will gain traction in the coming months. I believe that a centralized content repository, located on-premise or in the cloud, is a key piece of any enterprise's infrastructure. Moreover, content services -- functionality that enables users to create, store, edit, and share content -- should be accessible from any enterprise application, including composite applications such as portals or mashups created for specific roles (e.g. sales and/or marketing employees, channel partners, customers). Users should not be required to interact with content only through dedicated tools such as office productivity suites and Content Management Systems (CMS).

Other content authoring and CMS software vendors are beginning to consider, understand, and (in some cases) embrace this deployment model. Box.net is one of the first proprietary software vendors to instantiate it. Adoption statistics of their new Salesforce CRM integration should eventually provide a good reading as to whether or not enterprise customers are also ready to embrace the content-as-a-service model.

Jive Software's announcement last week of the Jive SharePoint Connector was met with a "so what" reaction by many people. They criticized Jive for not waiting to make the announcement until the SharePoint Connector is actually available later this quarter (even though pre-announcing product is now a fairly common practice in the industry.) Many also viewed this as a late effort by Jive to match existing SharePoint content connectivity found in competitor's offerings, most notably those of NewsGator, Telligent, Tomoye, Atlassian, Socialtext, and Connectbeam.

Those critics missed the historical context of Jive's announcement and, therefore, failed to understand its ramifications. Jive's SharePoint integration announcement is very important because it:

• underscores the dominance of SharePoint in the marketplace, in terms of deployments as a central content store, forcing all competitors to acknowledge that fact and play nice (provide integration)
• reinforces the commonly-held opinion that SharePoint's current social and collaboration tools are too difficult and expensive to deploy, causing organizations to layer third-party solution on top of existing SharePoint deployments
• is the first of several planned connections from Jive Social Business Software (SBS) to third-party content management systems, meaning that SBS users will eventually be able to find and interact with enterprise content without regard for where it is stored
• signals Jive's desire to become the de facto user interface for all knowledge workers in organizations using SBS

The last point is the most important. Jive's ambition is bigger than just out-selling other social software vendors. The company intends to compete with other enterprise software vendors, particularly with platform players (e.g. IBM, Microsoft, Oracle, and SAP), to be the primary productivity system choice of large organizations. Jive wants to position SBS as the knowledge workers' desktop, and their ability to integrate bi-directionally with third-party enterprise applications will be key to attaining that goal.

Jive's corporate strategy was revealed in March, when they decreed a new category of enterprise software -- Social Business Software. Last week's announcement of an ECM connector strategy reaffirms that Jive will not be satisfied by merely increasing its Social Media or Enterprise 2.0 software market share. Instead, Jive will seek to dominate its own category that bleeds customers from other enterprise software market spaces.

Today is the long-awaited day when 100,000 lucky individuals receive access to an early, but working, version of Google Wave. I hope I am in those ranks! Like many people, I have been reading about Wave, but have not been able to experience it hands-on

Wave has been a hot topic since it was first shown outside of Google last May. Yet it continues to be quite misunderstood, most likely because it is such an early stage effort and most interested people have not been able to lay hands on the technology. For that very reason, Gilbane Group is presenting a panel entitled Google Wave: Collaboration Revolution or Confusion? at the Gilbane Boston conference, on December 3rd.

The confusion surrounding Wave was highlighted for me yesterday in a Twitter exchange on the topic. It all started innocently enough, when Andy McAfee asked:

To which I replied:

That statement elicited the following comment from Jevon MacDonald of the Dachis Group:

I am not a technologist. I seek to understand technology well enough that I can explain it in layman's terms to business people, so they understand how technology can help them achieve their business goals. So I generally avoid getting into deep technical discussions. This time, however, I was pretty sure that I was on solid ground, so the conversation between me and Jevon continued:

Now, here we are, at the promised blog post. But, how can Jevon and I both be correct? Simple. Google Wave encompasses not one, but several protocols for communication between system components, as illustrated in the figure below.

Figure 1: Google Wave Protocols (Source: J. Aaron Farr, http://www.cubiclemuses.com/cm/articles/2009/08/09/waves-web-of-protocols/)

The most discussed of these is the Google Wave Federation protocol, which is an extension of the Extensible Messaging and Presence Protocol (XMPP). However, Wave also requires protocols for client-server and robot server- (Web service) Wave server communication. It is also possible, but probably not desirable, for Wave to utilize a client-client protocol.

Jevon was absolutely correct about the XMPP protocol enabling server-server communication in the Google Wave Federation Protocol. The Draft Protocol Specification for the Google Wave Federation Protocol lays out the technical details, which I will not explore here. XMPP provides a reliable mechanism for server-server communication and is a logical choice for that function in Google Wave, because XMPP was originally designed to transmit instant message and presence data.

It turns out that the Google Wave team has not defined a specific protocol to be used in client-server communication. A Google whitepaper entitled Google Wave Data Model and Client-Server Protocol does not mention a specific protocol. The absence of a required or recommended protocol is also confirmed by this blog post. While the Google implementation of Wave does employ HTTP as the client-server protocol, as Jevon stated, it is possible to use XMPP as the basis for client-server communication, as I maintained. ProcessOne demonstrates this use of XMPP in this blog post and demo.

Finally, there is no technical reason that XMPP could not be used to route communications directly from one client to another. However, it would not be desirable to communicate between more than two clients via XMPP. Without a server somewhere in the implementation, Wave would be unable to coordinate message state between multiple clients. In plain English, the Wave clients most likely would not be synchronized, so each would display a different point in the conversation encapsulated in the Wave.

To summarize, Google Wave employs the following protocols:

• XMPP for server-server communication
• HTTP for client-server communication in the current Google implementation; XMPP is possible, as demonstrated by ProcessOne
• HTTP (JSON RPC) for robot server-Wave server communication in the current Google implementation
• Client-client protocol is not defined, as this mode of communication is most likely not usable in a Wave

I hope this post clarifies the protocols used in the current architecture of Google Wave for you. More importantly, I hope that it highlights just how much additional architectural definition needs to take place before Wave is ready for use by the masses. If I had a second chance to address Andy McAfee's question, I would unequivocally state that Google Wave is a "concept car" at this point in time.

Postscript: The heretofore mentioned possibilities around XMPP as a client-client protocol are truly revolutionary. The use of XMPP as the primary communication protocol for the Internet, instead of the currently used HTTP protocol, would create a next generation Internet in which centralized servers would no longer serve as intermediaries between users. Web application architectures, even business models, would be changed. See this post for a more detailed explanation of this vision, which requires each user to run a personal server on their computing device.

My friend Sameer Patel wrote and published a very good blog post last week that examined the relationship of Enterprise Content Management (ECM) and enterprise social software. His analysis was astute (as usual) and noted that there was a role for both types of software, because they offer different value propositions. ECM enables controlled, repeatable content publication processes, whereas social software empowers rapid, collaborative creation and sharing of content. There is a place for both in large enterprises. Sameer's suggestion was that social software be used for authoring, sharing, and collecting feedback on draft documents or content chunks before they are formally published and widely distributed. ECM systems may then be used to publish the final, vetted content and manage it throughout the content lifecycle.

The relationship between ECM and enterprise social software is just one example of an important, higher level interconnection -- the nexus of defined business processes and ad hoc collaboration. This is the sweet spot at which organizations will balance employees' requirements for speed and flexibility with the corporation's need for control. The following (hypothetical, but typical) scenario in a large company demonstrates this intersection.

A customer account manager receives a phone call from a client asking why an issue with their service has not been resolved and when it will be. The account manager can query a workflow-supported issue management system and learn that the issue has been assigned to a specific employee and that it has been assigned an "in-progress" status. However, that system does not tell the account manager what she really needs to know! She must turn to a communication system to ask the other employee what is the hold up and the current estimate of time to issue resolution. She emails, IM's, phones, or maybe even tweets the employee to whom the issue has been assigned to get an answer she can give the customer.

The employee to whom the issue was assigned most likely cannot use the issue management system to actually resolve the problem either. He uses a collaboration system to find documented information and individuals possessing knowledge that can help him deal with the issue. Once the problem is solved, the employee submits the solution to the issue management system, which feeds it to a someone who can make the necessary changes for the customer and inform the customer account manager that the issue is resolved. Case closed.

The above scenario illustrates the need for both process and people-centric systems. Without the cludgy, structured issue management system, the customer account manager would not have known to whom the issue had been assigned and, thus, been unable to contact a specific individual to get better information about its status. Furthermore, middle managers would not have been able to assign the case in a systematic way or see the big picture of all cases being worked on for customers without the workflow and reporting capabilities of the issue management system. On the other hand, ad hoc communication and collaboration systems were the tools that drove actual results. The account manager and the employee to whom the issue was assigned would not have been able to do their work if the issue management system was their only support tool. They needed less structured tools that allowed them to communicate and collaborate quickly to actually resolve the issue.

We should not expect that organizations striving to become more people-centric will abandon their ECM, ERP, or other systems that guide or enforce key business processes. There is a need for both legacy management and Enterprise 2.0 philosophies and systems in large enterprises operating in matrixed organizational structures. Each approach can provide value; one quantifiable in hard currency and the other in terms of softer, but important, business metrics (more on this in a future post.) The enterprises that identify, and operate at, the intersection of structured process and ad hoc communication/collaboration will gain short-term competitive advantage.

On Wednesday, May 6, 2009, at 1:00 p.m. (Eastern), the New Orleans Tourism Marketing Corp. (NOTMC), the Gilbane Group, and ISITE Design will host an online repeat of one of the most popular sessions from the 2008 Gilbane Conference in Boston. Join us to hear Nathan Williams, NOTMC's Interactive Director, talk about their exhaustive search for the right WCM solution and the extensive user experience planning they undertook in the process. I (Tony White) will describe the process the Gilbane Group used to help NOTMC evaluate WCM products, and ISITE Design will highlight key ways in which they helped NOTMC plan a successful information architecture.

To register for this online event, click here.

The first wiki, WikiWikiWeb, was created 14 years ago today, by Ward Cunningham. Since then, the wiki has become one of the most widely deployed collaboration tools available. One might even call the wiki the catalyst of the Social Software movement.

Why is the wiki so popular? There are several reasons, including ease of use, structured navigation, and the ability to track changes to wiki pages and roll back to previous versions. The democratic nature of the format, in which anyone who has access can edit the wiki, is undoubtedly a major contributor to its success as well.

The primary reason for the wiki's success is its flexibility. Wikis have been used for everything from collaboratively authoring a document, to managing a project, to establishing a corporate knowledge base. We are seeing the same phenomenon today in Twitter, which is being used in ways that its creators never imagined.

So, at age 14, what has the wiki taught us? That collaboration tools should be designed for flexible, yet intuitive, use. Complexity is kryptonite to collaboration. Let's remember that before we build and deploy enterprise collaboration software.