Curated for content, computing, and digital experience professionals

Category: Collaboration and workplace (Page 37 of 95)

This category is focused on enterprise / workplace collaboration tools and strategies, including office suites, intranets, knowledge management, and enterprise adoption of social networking tools and approaches.

SharePoint – Migrating the Office Franchise to the Web

Microsoft has a lot to lose if they are unable to coax customers to continue to use and invest in Office.  Google is trying to woo people away by providing a complete online experience with Google Docs, Email, and Wave.  Microsoft is taking a different tact.  They are easing Office users into a Web 2.0-like experience by creating a hybrid environment, in which people can continue to use the rich Office tools they know and love, and mix this with a browser experience.  I use the term Web 2.0 here to mean that users can contribute important content to the site.

SharePoint leverages Office to allow users to create, modify, and display “deep[1]” content, while leveraging the browser to navigate, view, discover, and modify “shallow[1]” content.  SharePoint is not limited to this narrow hybrid feature set, but in this post I  examine and illustrate how Microsoft is focusing its attention on the Office users.  The feature set that I concentrate on in this post is referred to as the “Collaboration” portion of SharePoint.  This is depicted in Microsoft’s canonical six segmented wheel shown in Figure 1.  This is the most mature part of SharePoint and works quite well, as long as the client machine requirements outlined below are met.

Microsoft Office Sharepoint Server 2007

Figure 1: The canonical SharePoint Marketing Tool – Today’s post focuses on the Collaboration Segment

Preliminaries:   Client Machine Requirements

SharePoint out-of-the-box works well if all client machines adhere to the following constraints:

  1. The client machines must be running Windows OS (XP, Vista, or WIndows 7)
    NOTE: The experience for users who are using MAC OS, Linux, iPhones, and Google phones is poor. [2]
  2. The only truly supported browser is Internet Explorer (7 and 8.) [2]
    NOTE: Firefox, Safari, and Opera can be used, but the experience is poor.
  3. The client machines need to have Office installed, and  as implied by bullet 1 above, the MAC version of Office doesn’t work well with SharePoint 2007.
  4. All the clients should have the same version of Office.  Office 2007 is optimal, but Office 2003 can be used.  A mixed version of Office can cause issues.
  5. A number of tweaks need to be made to the security settings of the browser so that the client machine works seamlessly with SharePoint.

I refer to this as a “Microsoft Friendly Client Environment.”

Some consequences of these constraints are:

  • SharePoint is not a good choice for a publicly facing Web 2.0 environment (More on this below)
  • SharePoint can be okay for a publicly facing brochureware site, but it wouldn’t be my first choice.
  • SharePoint works well as an extranet environment, if all the users are in a Microsoft Friendly Client Environment, and significant attention has been paid to securing the site.

A key take-away of these constraints is that a polished end user experience relies on:

  1. A carefully managed computing environment for end users (Microsoft Friendly Client Environment)
    and / or
  2. A great deal of customization to SharePoint.

This is not to say that one cannot deploy a publicly facing site with SharePoint.  In fact, Microsoft has made a point of showcasing numerous publicly facing SharePoint sites [3].

What you should know about these SharePoint sites is:

  • A nice looking publicly facing SharePoint site that works well on multiple Operating Systems and browsers has been carefully tuned with custom CSS files and master pages.  This type of work tends to be expensive, because it is difficult to find people who have a good eye for aesthetics, understand CSS, and understand SharePoint master pages and publishing.
  • A publicly facing SharePoint site that provides rich Web 2.0 functionality requires a good deal of custom .NET code and probably some third party vendor software.  This can add up to considerably more costs than originally budgeted.

An important consideration, before investing in custom UI (CSS & master pages) , third party tools, and custom .NET code is that they will most likely be painful to migrate when the underlying SharePoint platform is upgraded to the next version, SharePoint 2010. [4]

By the sound of these introductory paragraphs, you might get the wrong idea that I am opposed to using SharePoint.  I actually think SharePoint can be a very useful tool, assuming that one applies it to the appropriate business problems.  In this post I will describe how Microsoft is transitioning people from a pure Office environment to an integrated Office and browser (SharePoint) environment.

So, What is SharePoint Good at?

When SharePoint is coupled closely with a Microsoft Friendly Client Environment, non-technical users can increase their productivity significantly by leveraging the Web 2.0 additive nature of SharePoint to their Office documents.

Two big problems exist with the deep content stored inside Office documents (Word, Excel, PowerPoint, and Access,)

  • Hidden Content: Office documents can pack a great deal of complex content in them.  Accessing the content can be done by opening each file individually or by executing a well formulated search. This is an issue!  The former is human intensive, and the latter is not guaranteed to show consistent results.
  • Many Versions of the Truth: There are many versions of the same files floating around.  It is difficult if not impossible to know which file represents the “truth.”

SharePoint 2007 can make a significant impact on these issues.

Document Taxonomies

Go into any organization with more than 5 people, and chances are there will be a shared drive with thousands of files, Microsoft and non-Microsoft format, (Word, Excel, Acrobat, PowerPoint, Illustrator, JPEG, InfoPath etc..) that have important content.  Yet the content is difficult to discover as well as extract in an aggregate fashion.  For example, a folder that contains sales documents, may contain a number of key pieces of information that would be nice to have in a report:

  • Customer
  • Date of sale
  • Items sold
  • Total Sale in $’s

Categorizing documents by these attributes is often referred to as defining a taxonomy.  SharePoint provides a spectrum of ways to associate taxonomies with documents.  I mention spectrum here, because non-microsoft file formats can have this information loosely coupled, while some Office 2007 file formats can have this information bound tightly to the contents of the document.  This is a deep subject, and it is not my goal to provide a tutorial, but I will shine some light on the topic.

SharePoint uses the term “Document Library” to be a metaphor for a folder on a shared drive.  It was Microsoft’s intent that a business user should be able to create a document library and add a taxonomy for important contents.  In the vernacular of SharePoint, the taxonomy is stored in “columns” and they allow users to extract important information from files that reside inside the library.  For example, “Customer”,  “Date of Sale,” or “Total Sale in $’s” in the previous example.  The document library can then be sorted or filtered based on values that are present in these columns.  One can even provide aggregate computations based the column values, for example total sales can be added for a specific date or customer.

The reason I carefully worded this as a “spectrum”  is because the quality of the solution that Microsoft offers is dependent upon the document file format and its associated application.  The solution is most elegant for Word 2007 and InfoPath 2007, less so for Excel and PowerPoint 2007 formats, and even less for the remainder of the formats that are non-Microsoft products..  The degree to which the taxonomy can be bound to actual file contents is not SharePoint dependent, rather it is dependent upon how well the application has implemented the SharePoint standard around “file properties.”

I believe that Microsoft had intended for the solution to be deployed equally well for all the Office applications, but time ran out for the Office team.  I expect to see a much better implementation when Office 2010 arrives. As mentioned above, the implementation is best for Word 2007.  It is possible to tag any content inside a Word document or template as one that should “bleed” through to the SharePoint taxonomy.  Thus key pieces of content in Word 2007 documents can actually be viewed in aggregate by users without having to open individual Word documents.

It seems clear that Microsoft had the same intention for the other Office products, because the product documentation states that you can do the same for most Office products.  However, my own research into this shows that only Word 2007 works.  A surprising work-around for Excel is that if one sticks to the Excel 2003 file format, then one can also get the same functionality to work!

The next level of the spectrum operates as designed for all Office 2007 applications.  In this case, all columns that are added as part of the SharePoint taxonomy can penetrate through to a panel of the office application.  Thus users can be forced to fill in information about the document before saving the document.  Figure 2 illustrates this.  Microsoft  refers to this as the “Document Information Panel” (DIP).  Figure 3 shows how a mixture of document formats (Word, Excel, and PowerPoint) have all the columns populated with information.  The disadvantage of this type of content binding is that a user must explicitly fill out the information in the DIP, instead of the information being bound and automatically populating based on the content available inside the document.

 

Figure 2: Illustrates the “Document Information Panel” that is visible in PowerPoint.  This panel shows up because there are three columns that have been setup in the Document library: Title, testText, and testNum.  testText and testNum have been populated by the user and can be seen in the Document Library, see figure 3.

 

Figure 3: Illustrates that the SharePoint Document Library showing the data from the Document Information Panel  (DIP)  “bleeding through.”  For example the PowerPoint document has testText = fifty eight, testNum = 58.

 

Finally the last level on the taxonomy feature spectrum is for Non-Microsoft documents.  SharePoint allows one to associate column values with any kind of document.  For example, a jpeg file can have SharePoint metadata that indicates who the copyright owner is of the jpeg.  However this metadata is not embedded in the document itself.  Thus if the file is moved to another document library or downloaded from SharePoint, the metadata is lost.

A Single Version of the Truth

This is the feature set that SharePoint implements the best.  A key issue in organizations is that files are often emailed around and no one knows where the truly current version is and what the history of a file was.  SharePoint Document libraries allow organizations to improve this process significantly by making it easy for a user to email a link to  a document, rather than email the actual document.  (See figure 4.)

 

Figure 4: Illustrates how easy it is to send someone a link to the document, instead of the document itself.

 

In addition to supporting good practices around reducing content proliferation, SharePoint also promotes good versioning practices.  As figure 5 illustrates any document library can easily be setup to handle file versions and file locking.  Thus it is easy to ensure that only one person is modifying a file at a time and that the there is only one true version of the file.

 

Figure 5: Illustrates how one can look at the version history of a document in a SharePoint Document Library..

Summary

In this post I focus on the feature set of SharePoint that Microsoft uses to motivate Office users to migrate to SharePoint.  These features are often termed the “Collaboration” features in the six segmented MOSS wheel. (See figure 1)  The collaboration features of MOSS are the most mature part of SharePoint and thus the most .  Another key take-away is the “Microsoft Friendly Client Environment.”  I have worked with numerous clients that were taken by surprise, when they realized the tight restrictions on the client machines.

Finally, on  a positive note, the features that I have discussed in this post are all available in the free version of SharePoint (WSS), no need to buy MOSS.  In future posts, I will elaborate on MOSS only features.

—————————————–

[1] The terms “deep” and “shallow” are my creation, and not a standard.  By “deep” content I am referring to the complex content such as a Word documents (contracts, manuscripts) or Excel documents (complex mathematical models, actuarial models, etc…)

[2] Microsoft has addressed this by stating that SharePoint 2010 would support some of these environments.  I am somewhat skeptical.

[3] Public Facing internet sItes on MOSS,  http://blogs.microsoft.nl/blogs/bartwe/archive/2007/12/12/public-facing-internet-sites-on-moss.aspx

[4] Microsoft has stated frequently that as long as one adheres to best practices, the migration to SharePoint 2010 will not be bad.  However, Microsoft does not have a good track record on this account for the SharePoint 2003 to 2007 upgrade, as well as many other products.

Integration of Social Software and Content Management Systems: The Big Picture

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.

The SharePoint Backend- What are the Headaches – What are the benefits

As I pointed out in my first post (SharePoint: Without the Headaches – A Discussion of What is Available in the Cloud,) you don’t necessarily need to host SharePoint in your own organization.  Although I believe that most businesses should focus on leveraging the front end of SharePoint to its full extent, it is important for non-technical users to have an understanding of what it takes to host SharePoint and why one might want to do so.  Therefore, this post provides a discussion of what it takes to host SharePoint and the driving factors for hosting SharePoint.

 

Microsoft’s original intent was to build a tool that was easy to leverage by non-technical users.  Microsoft thought of this as the natural extension of Office to the web[1].  That being said, the complexities got away from Microsoft, and in order to leverage a number of features one needs access to the back end.

Before delving into the SharePoint back end, let me point out that many businesses hire SharePoint development staff, both permanent and on a consulting basis. I think that developing custom SharePoint code should be done only after thoroughly justifying the expense.  It is often a mistake.  Instead, organizations should clearly define their requirements and then leverage a high quality third party add-on.  I will mention some of these at the end of the post.

SharePoint is a fragile product and therefore custom code for SharePoint is very expensive to develop, test, and deploy. Furthermore, custom code often needs to be rewritten when migrating to the next release of SharePoint.  Finally, SharePoint is a rapidly growing product, and chances are good that custom code may soon become obsolete by new features in the next generation.

In my first post, I pointed out that inexpensive SharePoint hosting options are available in the cloud. These options tend to be limited.  For example, the inexpensive rentals do not provide much security, only provide WSS (not MOSS), and do not allow one to add third party add-ins.  It is possible to lease custom environments that don’t surrender to any of these limitations, but they come at a cost.  (Typically starting at $500 per month[2].)  I believe that robust MOSS offerings with third party add-ons will be available at competitive prices within two years. 

——————————————————————————–

[1] SharePoint is developed by the Office division.

[2] For example, FPWeb offers a SharePoint hosted environment with the CorasWorks Workplace Suite included starting at $495 per month.

Continue reading

Google Wave Protocols: Clearing the Confusion

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:

Andy1

To which I replied:

Larry1

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

Jevon1

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:

Larry2

Larry3

Jevon2

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.

wave_protocols

Figure 1: Google Wave Protocols (Source: J. Aaron Farr,

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.

Partnerpedia Integrates Twitter for B2B Social Networking

Partnerpedia announced that its Private Networks online partner community and channel enablement solution will be integrated with Twitter for content syndication and B2B social networking. Companies should be able to stream corporate Twitter feeds directly to their profiles in Private Networks, providing updates to the community. The added feature also incorporates syndicating content published in Partnerpedia for sharing through Twitter. Expanding on Partnerpedia Private Networks’ customized branding options, companies link their corporate profiles on social networking sites to their corresponding profile in the Private Networks community. This should enable companies to extend communications beyond the Partnerpedia community and increase exposure to new potential partners. An extension of Partnerpedia’s free Open Community, Private Networks helps companies to create a privately branded online community for their network of partners. Leveraging social media, collaboration and sales enablement tools, Private Networks is designed to accelerate company business through partners. Twitter integration for Private Networks should be available at the end of October 2009 at no additional cost. https://www.partnerpedia.com/

eTouch Releases SamePage 4.2

eTouch SamePage has announced it has released SamePage version 4.2 with a customizable dashboard, stronger e-mail integration and advanced plug-in features in order to meet the needs of a remote and social-media friendly workforce. SamePage version 4.2 includes a number of new features important to remote and knowledge management workers including: advanced email integration that enables remote workers to more easily ‘wikify’ content from any smartphone; dynamic portal-like dashboard with drag and drop widgets that can be personalized at company and individual levels, eliminating the need for a separate intranet portal product; a wide selection of new plug-ins that can be customized for each enterprise, including tag cloud and project member plug-ins, among others; more detailed analytics, usage and content reports for administrators; ratings on Blog posts and more blog analytics; Support for Microsoft Office 2007; WYSIWYG enhancements to further simplify the user interface; and increased privileges for the system user or administrator to manage pages and projects. http://www.etouch.net/

Jive Announces Jive Market Engagement

Jive has announced Jive Market Engagement, a new solution that combines the power of social media monitoring with Social Business Software. Jive’s Market Engagement Solution aims to help organizations implement a unified social media strategy to interact with customers. The solution helps to socialize observations from Twitter, Facebook, blogs, and other online sources to move faster in the moment of pain or the moment of opportunity. While a small percentage of organizations use monitoring tools, most companies rely on a patchwork of alerts, people, and email to stay on top of conversations.  While these approaches may help organizations listen in on the river of conversations occurring across the social web, they certainly don’t allow companies to measure, share and engage with insights in a productive and timely way. Organizations should be able to listen, measure, engage and share insights using Jive Market Engagement to identify real-time issues, collaborate with a set of colleagues internally and ultimately more and engage in active dialogues with customers and influencers. The Jive Market Engagement Solution is designed to help organizations proactively monitor brand or product issues and competitive threats; enable quick collaboration on appropriate responses or interventions; and elevate and broaden the social conversations with a company. The “war room” environment allows for rapid decision- making from the right people within the organization. These observations are then consolidated into market summary reports, what Jive calls “Viewpoints.”  Viewpoints can be shared within an organization to foster collaboration and to develop and implement appropriate responses.  Jive Market Engagement also provides the ability to analyze the effectiveness of those responses. www.jivesoftware.com/

MadCap Lingo 3.0 for Authors and Translators Released

MadCap SoftwareExternal link has announced that MadCap Lingo 3.0 is now available. MadCap LingoExternal link, the XML-based, fully integrated translation memory system (TMS) and authoring tool solution, eliminates the need for file transfers in order to complete translation-preserving valuable content and formatting to deliver a consistent experience across multiple languages. With version 3.0, MadCap Lingo adds a new Project Packager function that bridges the gap between authors and translators who use other TMS software. Using the Project Packager in MadCap Lingo, authors should be able to work with translators to streamline the translation process, track the status of completion, and obtain more accurate project cost estimates. MadCap Lingo 3.0 also features a new TermBase Editor for creating databases of reusable translated terms, and enhanced translation memory. Through integration between MadCap Lingo and MadCap’s authoring and multimedia applications, MadCap hopes to offer a powerful integrated authoring and localization workflow. Project Packager in MadCap Lingo 3.0 is designed to make it easier for authors who need their documentation translated into another language but work with a translator who relies on a TMS tool other than MadCap Lingo. Using Project Packager, the author can create a MadCap Lingo project with all the files that require translation, and bundle it in a ZIP file and send it to the translator. MadCap Lingo displays a list of all files that need to be translated, going beyond text to include skins, glossaries, search filter sets, and much more. As a result, the author can ensure that the translator receives all of the files requiring translation. This should streamline the process while enabling more accurate translation project estimates, helping translators to avoid accidentally underestimating project costs based on an incomplete file count-and protecting authors from unexpected cost overruns. Once the translation is complete, the translator sends a ZIP file with the content. The author then simply merges the translated file in MadCap Lingo, which is used to confirm the completeness of the translation. The author can then run statistical reports showing information for each project and file to determine what has/ has not been translated, how many words/segments have been translated and/or still need to be translated, and much more. The author can then export the MadCap Lingo project to a range of outputs, such as a Flare project file for online and print publishing, Word document, or even a Darwin Information Typing Architecture (DITA) file, among others. The key new features of MadCap Lingo 3.0 are: the new TermBase Editor which enables translators to create and manage concept-oriented, multilingual terminology databases, “termbases,” making it significantly easier to reuse translated terms; the ability to import and export Term Base eXchange (TBX) files, an open, XML-based standard used for exchanging structured terminological data; translation memory – Apply Suggestions to Project function, which makes it possible to view and automatically apply translation memory suggestions to an entire project, rather than just one segment, saving hours of effort; dynamic help window pane lock lets the translator keep the current help topic frozen in place while moving around in the MadCap Lingo interface, making it easier to follow steps or other information placed in the Help topic; minimize to system tray option; multiple file support allows multiple files to be selected when creating a new MadCap Lingo project, for example HTM, HTML, XML, DITA or DOC files. http://www.madcapsoftware.com/

« Older posts Newer posts »

© 2025 The Gilbane Advisor

Theme by Anders NorenUp ↑