SharePoint User Interface

In my last post on SharePoint architecture, I mentioned that there are few parts in SharePoint architecture: farms, web applications, site collections, service applications, administration and security. User interface is represented by site collections. In my today's post, I am going to describe SharePoint user interface.

Site collection is the top-level SharePoint site which contains children sites which are organized in a hierarchy. When you create a site at the root of a Web Application, you create a site collection. In other words, a SharePoint site collection is a hierarchical set of sites that can be managed together. Sites within a site collection have common features, such as shared permissions, galleries for templates, content types, and web parts, and they often share a common navigation. Creation of site collections usually performed by a system administrator.

Site collection has hierarchical structure. When a site collection has been created, next step is to create a site. A site is a single SharePoint site within a site collection. Creation of sites can be delegated to users of a site collection. A site can inherit permissions and navigation structure from its parent site collection, or they can be specified and managed independently.

There are times when it is appropriate to create an entire site collection, and there are times when it makes more sense to create a single site. For instance, if you have many projects that fit within a larger context, it makes sense to create a single site collection for that context, and create sites to manage each project. For example, it makes sense for the engineering department to have a separate site collection from the legal department. An engineering department might have one site collection and use that site collection to house multiple sites, one site per engineering project.

A site may contain sub-sites, and those sub-sites may contain further sub-sites. Typically, sites need to be created from scratch, but sites can also be created according to pre-defined templates that provide previously set-up functionality. Sites have navigation, themes/branding, custom permissions, workflows, and have the ability to be configured or customized in a number of ways.

If the site is used for the document management, next step after the site in the SharePoint hierarchy are libraries and lists. A SharePoint Site is a collection of lists, libraries, pages, and web parts.

A list is a collection of similar items. A list contains columns that define the item metadata. Each item stored in a list shares the same metadata. For instance, you can have a list of links called "my links", where each item has a URL, a name, and a description.

Lists resemble database tables in structure and behavior. Lists support various field or data types, and can have triggers that react to list events such as creating, updating or deleting items. In addition lists can be configured to filter, sort or group items based on item data or properties.

Lists can be based on list templates, such as calendars, contact lists, tasks, announcements. You can create multiple lists based on a single list template. Lists can include workflows.

A library contains documents. In a library a document is the item with library metadata supporting the document. Each item in the library refers to a file that is stored in SharePoint database. A library is a location on a site where you can create, collect, update, and manage files.

You can customize libraries in several ways. You can control how documents are viewed, tracked, managed, and created. You can track versions, including how many and which type of versions, and you can limit who can see documents before they are approved. You can use workflows to collaborate on documents in libraries. You can specify information management policies to manage the handling and expiration of documents within libraries.

There are few types of libraries:

Document library is used for all types of documents.

Picture library is used to store digital pictures or graphics. Although pictures can be stored in other types of libraries, picture libraries have several advantages. For example, from a picture library you can view pictures in a slide show, download pictures to your computer, and edit pictures with graphics programs. Consider creating a picture library if your team reuses many graphics, such as logos and corporate images, or if you want to store pictures of team events or product launches.

Wiki page library is used create a collection of connected wiki pages. A wiki enables multiple people to gather routine information in a format that is easy to create and modify. You can add to your library wiki pages that contain pictures, tables, hyperlinks, and internal links. For example, if your team creates a wiki site for a project, the site can store tips and tricks in a series of pages that connect to each other.

Form library is used to store and manage electronic forms.

Reports library helps organizations create, manage, and share information contained in business data web parts, key performance indicator (KPI) web parts, and Excel web access web parts used for business intelligence analytics. The Records Center site template has a reports library by default, but anyone who can create document libraries within a site collection can create a report library. The reports library includes a version history for each report, and archives previous versions. Users can create new versions of reports for special events or milestones, and later revert to a previous report.

Translation management library - helps organizations create, store, and manage translated documents by providing both views and specific features that facilitate the manual document translation process. The translation management library is designed specifically to store documents and their translations. The library tracks the relationship between a source document and its translations, and it groups all of these documents together to make them easy to find. Additionally, the library can be configured with a special translation management workflow that is designed to help manage the manual document translation process.

Data connection library is used to centrally publish connection files to make it easy for users to find and use the data sources they need. Data connection files are easy to create and update, and solution designers can easily reuse them from within the Microsoft Office system client applications.

Slide library is used to share individual slides from a presentation, reuse slides, track the history of a slide, compile individual slides into a presentation, and receive notifications when a slide in a presentation has changed. Users can publish slides to a Slide Library from PowerPoint.

SharePoint has three primary page content-types: Wiki pages, Web-part pages, and Publishing Pages. The default page type is a Wiki Page, which enables free-form editing based on the ribbon toolbar. It is possible to insert Web-parts into any page type.

Web parts are sections that can be inserted into Pages in SharePoint sites. Their typical uses are displaying content defined in the web-part's settings, displaying items from lists and libraries, providing access to features in the SharePoint.

SharePoint site can also be created as Wiki site, blog site, project management site, etc. I described Wiki sites in one of my previous posts on SharePoint, In my future posts, I will describe other site types.

Business Analysis - Use Cases

In my last post on business analysis, I described user stories and gave a comparison between user stories and use cases. In my today's post, I am going to describe use cases.

A use case (a case in the use of a system) is a list of steps, typically defining interactions between a role known as an "actor" and a system to achieve a goal. The actor can be a human or an external system.

There is no standard way to write a use case, and different formats work well in different cases. There are few templates to use for a use case.

Simple Use Case

Title: goal the use case is trying to achieve

Main Success Scenario: numbered list of steps

Step: a simple statement of the interaction between the actor and a system

Extensions: separately numbered lists, one per Extension

Extension: a condition that results in different interactions from the main success scenario. An extension from main step 3 is numbered 3a, an extension from main step 4 is numbered 4a, etc.

Complete Use Case

Title: an active-verb goal phrase that names the goal of the primary actor

Primary

Actor

Goal in Context

Scope

Level

Stakeholders and Interests

Precondition

Minimal Guarantees

Success

Guarantees

Trigger

Main Success Scenario

Extensions

Technology and Data Variations List

Related Information

Casual Use Case

Title: goal

Primary Actor

Scope

Level

Story: the body of the use case is simply a paragraph or two of text, informally describing what happens

Example of a Simple Use Case

Use Case Name: Place Order

Actors: Shopper, Fulfillment System, Billing System

Use Case Description: after the user selected items to purchase, user orders the items. The user will provide the payment and shipping information. The system will respond with confirmation of the order and a tracking number that the user can use to check on order status in future. The system will also provide the user with an estimated delivery date for the order which will include all selected items. The user may already have an account with the company with billing and shipping information.

Actors

A use case defines the interactions between external actors and the system under consideration to accomplish a goal. Actors must be able to make decisions, but don't to be human. An actor might be a person, a company or organization, a computer program, or a computer system — hardware, software, or both. The term "actors" are frequently interchanged with the term "users".

Actors are always stakeholders, but many stakeholders are not actors, since they never interact directly with the system, even though they have the right to care how the system behaves. For example, the owners of the system, the company's board of directors, and regulatory bodies such as the Internal Revenue Service and the Department of Insurance could all be stakeholders but are unlikely to be actors.

Similarly, a person using a system may be represented as different actors because he is playing different roles. For example, user "Joe" could be playing the role of a Customer when using an Automated Teller Machine to withdraw cash from his own account, or playing the role of a Bank Teller when using the system to restock the cash drawer on behalf of the bank.

Actors are often working on behalf of someone else. If actor is "sales rep for the customer" or "clerk for the marketing department" to capture that the user of the system is acting for someone else. This tells the project that the user interface and security clearances should be designed for the sales rep and clerk, but that the customer and marketing department are the roles concerned about the results.

A stakeholder may play both an active and an inactive role. For example, a Consumer is both a "mass-market purchaser" (not interacting with the system) and a User (an actor, actively interacting with the purchased product). In turn, a User is both a "normal operator" (an actor using the system for its intended purpose) and a "functional beneficiary" (a stakeholder who benefits from the use of the system). For example, when user "Joe" withdraws cash from his account, he is operating the Automated Teller Machine and obtaining a result on his own behalf.

Look for actors among the stakeholders of a system, the primary and supporting (secondary) actors of a use case, the system under design, and finally among the "internal actors", namely the components of the system under design.

The relationships between all the use cases and actors are represented in a Use Case Diagram.

A use case diagram is a graphical representation of a user's interaction with the system and depicting the specifications of a use case. A use case diagram can portray the different types of users of a system and the various ways that they interact with the system. This diagram is typically used in conjunction with the textual use case and is often accompanied by other types of diagrams as well.

While a use case itself might drill into a lot of detail about every possibility, a use case diagram can help provide a higher-level view of the system. They provide the simplified and graphical representation of what the system must actually do.

Limitations

Limitations of Use cases include:

• Use cases are not well suited to capturing non-interaction based requirements of a system (such as algorithm or mathematical requirements) or non-functional requirements (such as platform, performance, timing, or safety-critical aspects). These are better specified declaratively elsewhere. 
• Use case templates do not automatically ensure clarity. Clarity depends on the skill of the writer(s). 
• Use cases are complex to write and to understand, for both end users and developers. 
• As there are no fully standard definitions of use cases, each project must form its own interpretation. 
• Some use case relationships, such as extensions, are ambiguous in interpretation and can be difficult for stakeholders to understand. 
• In Agile methodology, simpler user stories are preferred to use cases. 
• Use case developers often find it difficult to determine the level of user interface (UI) dependency to incorporate in a use case. While use case theory suggests that UI should not be reflected in use cases, it can be awkward to remove this aspect of design, as it makes the use cases difficult to visualize. In software engineering, this difficulty is resolved by applying requirements traceability, for example with a traceability matrix. 
• Use cases can be over-emphasized. For example, driving system design too literally from use cases, and using use cases to the exclusion of other potentially valuable requirements analysis techniques. 
• Use cases are a starting point for test design, but since each test needs its own success criteria, use cases may need to be modified to provide separate post-conditions for each path.

Business Analysis, User Stories, and Agile Methodology

In my last post on business analysis in content management, I mentioned that methods used in business analysis are: focus groups, documentation analysis, surveys, user task analysis, process mapping, stakeholders interviews, use cases, user stories, personas, storyboards, etc. In my today's post, I am going to describe user story method.

A user story is a short, simple description of a feature told from the perspective of the person who desires the new system capabilities, usually a user or a customer of the system. It is one or few sentences in the everyday or business language that captures what a user does or needs to do as part of his or her job functions.

User stories are used with Agile software development methodologies as the basis for defining the functions that a business system must provide. It captures the "who", "what" and "why" of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small paper notecard. User stories are written by or for a business user as that user's primary way to influence the functionality of the system being developed.

User stories are a quick way of handling users' requirements without having to create formalized requirement documents and without performing administrative tasks related to maintaining them. The intention of the user story is to be able to respond faster and with less overhead to rapidly changing business requirements.

During the process of collecting users requirements, a business analyst gets together with a users' representative to identify the specific needs of the business and create user stories.

As the customer conceives the user stories, business analyst writes them down on a note card with a name and a description which the customer has formulated. If the business analyst and the user find that the user story is lacking in some way (too large, complicated, imprecise), it is rewritten until it is satisfactory often using the INVEST guidelines.

The INVEST guidelines was created by Bill Wake as the characteristics of a good quality user story:

Letter	Meaning	Description
I	Independent	The user story should be self-contained, in a way that there is no inherent dependency on another user story.
N	Negotiable	User stories can always be changed and rewritten.
V	Valuable	A user story must deliver value to the end user.
E	Estimatable	You must always be able to estimate the size of a user story.
S	Sized appropriately or Small	User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
T	Testable	The user story or its related description must provide the necessary information to make test possible.

User stories generally are not created to be too definite once they have been written down because requirements tend to change during the development period.

User stories generally follow the following template:

As a "role", I want "goal" so that "benefit".

As a "user" I want to "do something" so that "I can accomplish goal".

As a "user" I want "function" so that "value".

There is also shorter version:

As a "role", I want "goal/benefit"

For example:

"As the CTO, I want the system to use our existing orders database rather than create a new one so that we don’t have one more database to maintain.

"As a user, I want the site to be available 99.9% of the time I try to access it so that I don’t get frustrated and find another site to use."

"As an estimator, I want to see all items I need to estimate this season so that I can see the volume of my work."

"As a user, I want to search for my customers by their first and last names."

 "As a user closing the application, I want to be prompted to save if I have made any change in my data since the last save."

User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.

As a central part of many agile development methodologies, user stories define what is to be built in a project. User stories are prioritized by developers to indicate which are most important. User stories then will be broken down in tasks and estimated by developers.

One of the benefits is that they can be written at varying levels of detail. We can write user stories that cover large amounts of functionality. These large user stories are generally known as epics. Here is an example epic from a desktop backup product:

"As a user, I can backup my entire hard drive."

Because an epic is generally too large for an agile team to complete in one iteration, it is split into multiple smaller stories before it is worked on. The epic above could be split into dozens (or possibly hundreds), including these two:

"As a power user, I can specify files or folders to backup based on file size, date created, and date modified."

"As a user, I can indicate folders not to backup so that my backup drive isn’t filled up with things I don’t need saved."

Agile projects use a product backlog which is a prioritized list of the functionality to be developed in a product or service. Although product backlog items can be whatever the team desires, user stories have emerged as the best and most popular form of product backlog item.

While a product backlog can be thought of as a replacement for the requirements document of a traditional project, it is important to remember that the written part of a user story (“As a user, I want…”) is incomplete until the discussions about that story occur. It is often best to think of the written part as a pointer to the real requirement. A user story could point to a diagram depicting a workflow, a spreadsheet showing how to perform a calculation, or any other artifact the product owner or team desires.

Every user story must at some point have one or more acceptance tests attached, allowing the developer to test when the user story is done and also allowing the user to validate it. Without a precise formulation of the requirements, prolonged nonconstructive arguments may arise when the product is to be delivered.

Agile methodology favors face-to-face discussion over comprehensive documentation and quick adaptation to change instead of fixation on the problem. User stories achieve this by:

• Being very short. They represent small chunks of business value that can be implemented in a period of days to weeks. 
• Allowing a developer and a user to discuss requirements throughout the project. 
• Needing very little maintenance. 
• Only being considered at the time of use. 
• Maintaining a close user contact. 
• Allowing projects to be broken into small increments. 
• Being suited to projects where the requirements are volatile or poorly understood. Iterations of discovery drive the refinement process. 
• Making it easier to estimate development effort. 
• Require close customer contact throughout the project so that the most valued parts of the project get implemented. 

Some of the limitations of user stories in agile methodologies:

• They can be difficult to scale to large projects. 
• They are regarded as conversation starters.

While both user stories and use cases serve the purpose to capture specific user requirements, there are major differences between them:

User Stories	Use Cases
Provide a small-scale and easy-to-use presentation of information. Are generally formulated in the everyday language of the user and contain little detail, thus remaining open to interpretation. They should help the reader understand what the software should accomplish.	Describe a process and its steps in detail, and may be worded in terms of a formal model. A use case is intended to provide sufficient detail for it to be understood on its own. A use case has been described as “a generalized description of a set of interactions between the system and one or more actors, where an actor is either a user or another system”.
Can be accompanied by Acceptance Testing procedures for clarification of behavior where stories appear ambiguous.	May be delivered in a stand-alone document.

Case Study - Wind River - Twiki Information Architecture

In the "Case Studies" series of my posts, I describe the projects that I worked on and lessons learned from them. In this post, I am going to describe the project of re-structuring content and information architecture of a content management system based on Twiki in Wind River.

Wind River is a software engineering company that used Twiki as their content management system. TWiki is a Perl-based structured wiki application, typically used to run a collaboration platform, content management system, a knowledge base, or a team portal.

Content organization and information architecture in Twiki were such that users had difficulty in finding information they were looking for. This situation made it difficult to find, re-use, and update content.

This also discouraged further adding of the new content and thus created areas where no documentation existed and the knowledge instead of being shared was being stored in personal computers. Storing the content in personal computers presented a risk of it being lost because it was not backed-up.

There was a lot of obsolete content because no content owners have been formally identified and no retention schedule has been set up. Collaborative work on the documents and projects was accomplished by users sending links to Twiki pages. Without these links it was very difficult to find information. There was no information governance in place and so content management processes were very sporadic.

The task was to re-organize the content organization and information architecture of the system and to set up information governance to solve these problems.

I strongly believe in user-centered design, so I performed the users study. I identified stakeholders within each Wind River team and created the questionnaire for collecting users' requirements for the system re-organization and the usability issues.

Based on these requirements, I re-organized the content structure and information architecture of the system. The major key to this re-organization was that the structure is very simple and intuitive. I made navigation very simple, created very intuitive labels, made sure that there is not too much information on one page and a user does not have to scroll down a very long page, that each page has a correct breadcrumb, and created taxonomy of webs (the building blocks of Twiki). Based on this taxonomy, I re-organized the location of documents. I also enhanced the system search.

For each content type, document owners were identified and retention schedule was set up with the function to flag the content that would reach an expiration date according to the retention schedule. This flag function would send an email notification to the content administrator that a certain document reached an expiration date. This alert allowed the content administrator to contact the document owner for the decision on what should be done with this document: review and update, move to an archive, or delete.

User acceptance testing of the system was performed. Users were satisfied with the system's new information architecture and indicated that it became much easier to find information.

The system with new content structure and information architecture was deployed.

Information governance was set up. Group and individual training was conducted on ongoing basis.

The project was a success. Company management and users were very cooperative in helping to make this project a success. It helped to increase efficiency and productivity and thus saved Wind River cost because employees did not waste any time on searching for documents or recreating documents that already exist.

Lessons learned

1. User-centered design is paramount to the project success. When you design and build the system based on users’ requirements, they are going to use it. Users have the sense of ownership of the system which provides excellent starting point. They know that the system you are building will be what they need.

2. Top-down support is critical for the project success. Management support is a huge factor in employees' encouragement to use the system and in setting up and enforcing procedures for information governance.

3. Assurance of users from the very beginning that they will not be left alone with the system provided their cooperation.

4. User acceptance testing helped to encourage employees to start using the system. When they participate in this process, this gives them the feeling of ownership of the system.

5. Ongoing training after the system deployment with the new content structure and information architecture made user adoption smooth.

Content Management Systems Reviews - SDL Tridion

SDL Tridion is the leading web content management system. This solution enables organisations to deliver a consistent, interactive and highly targeted customer experience, in multiple languages, across multiple web sites and channels including email, mobile sites and print.

In addition to content creation, management, translation, delivery and archiving solutions, SDL Tridion provides brand management, targeted communication, multi-channel delivery and visitor interaction capabilities.

SDL Tridion integrations well with third-party software packages such as Google Enterprise Search and online metrics suites like WebTrends and Omniture.

Content Entities

SDL Tridion’s famous Building Blocks represent the core of this WCM solution. Building Blocks are Component and Page Templates, Component Presentations, Components, Pages and Schemas.

Content authors usually create Components based on certain Schemas (which define permissible content fields), followed by combining those Components with appropriate Component Templates, thus creating Component Presentations.

A Page may contain several Component Presentations. Every Page requires an appropriate Page Template in order to be rendered properly.

There are two types of Components: Components storing text and links and Multimedia Components handling binaries (.jpg, .gif, .swf, .doc, etc.)

Pages are created in Structure Groups (i.e., a website sections) in a corresponding Publication (i.e., website).

The system comes with a set of default Page and Component Templates. Customized Page and Component Templates will need to be developed to fit the layout and code of your particular web site.

Metadata can usually be handled either on the Structure Group/Page level, or through embeddable metadata Schemas.

From the development standpoint, all Schemas and Templates are created in a development environment and then transferred to test and production environments, using the tool called Content Porter, where they become available to end-users.

Content Versioning

Versioning is quite simple and can be used for two things: to view History and to Compare. The History feature provides data on all modifications on an item (user names and timestamps are included). Using the Compare tool, you can see the exact changes highlighted in various colors made to an item by comparing any two versions.

Workflow

The basic workflow is Ready for Editing – Ready for Publishing, with the ability to modify and add other levels of approval.

You can create and customize your workflow in MS Visio with a Tridion plug-in.

There are additional modules that allow for inline and e-mail notifications. The standard, out-of-the-box version includes commentary capabilities. Tridion’s Event System can also be used to introduce a number of automatic (vs. manual) activities in the content management process.

Workflow is natively integrated into the GUI and Microsoft Outlook allowing a user to perform various activities from his/her inbox.

SDL Tridion offers the following products:

Content Manager (core product)

SDL Tridion’s Content Manager Solution uses proprietary BluePrinting technology that allows organizations to reuse and adapt content, layout, and other functionality for different pages and web sites. This ensures that companies can address target audiences in different regions around the world in a "same but different" manner. The technology enables the user to maintain centralized control of brand and message while allowing for local differentiation. This technology makes sharing complex content over multiple web sites fast and easy while maintaining centralized control and brand consistency.

BluePrinting technology has proven its value to organizations that have any of the following requirements:

• globalized websites;
• multi-website management;
• translation management;
• brand management;
• target audience marketing;
• multi-channel marketing.

Digital asset repository is managed through Multimedia Components that can store major binary extensions, which can be configured per your requirements.

Content Manager Explorer (main user interface to Content Manager) - provides rich functionality for basic to advanced content management tasks within a browser.

SiteEdit

Delivers key contributors with a WYSIWYG, browser-based interface and a collaborative environment for many online communication tasks. It is easy to use, ensuring lower training costs and easy adoption. There is version comparison and roll-back to previous version. It allows to perform simple actions like re-arranging content blocks, adding new content, editing existing content and spell-check.

WebDAV Connector (Windows Explorer access to SDL Tridion WCM and content)

Provides access to SDL Tridion WCM content using Windows Explorer. Contributors can add, edit, delete, and use content in the same way that they would use the Windows file system using the most appropriate desk top application for the task they need to perform.

Word Connector (Microsoft Word-based word processing tool for content creation)

For occasional content contributors who need to create simple text for the organization’s Web site in the word processing tool that they know best, Microsoft Word. Authors can open, edit, and create structured XML content using Word and to save this content directly to Content Manager.

Multilingual Support

It is represented by Translator Manager and enables companies to configure their translation needs within their existing BluePrint structure. This includes defining both the source and target language of typical translation processes. Users can set up that Translation Manager for a certain publication and specify target languages, as well as use workflow to specify the translation process.

For each translation process users can set up criteria, such as which translation agency to use. When properly configured, users can initiate a translation in one or all Child Publications using Translation Manager, which will prompt a translation job creation at a chosen agency.

Translation jobs can be seen in the GUI right below the Publishing Queue. From the translation jobs list users can send the job to the TMS (Translation Management System) and check the status of the translation.

Content Delivery Architecture

Content Delivery is mainly based on two products: Presentation Servers and Dynamic Content Broker. In addition, there are other modules that are part of Content Delivery, including Dynamic Linking, Personalization and Profiling, Content Distributor and Content Deployer.

The separation of Content Delivery from Content Management ensures that only approved content goes outside the firewall. Delivery of both dynamic and static content is possible, using either the Dynamic Content Broker or the Presentation Server approach.

Dynamic Content Broker assembles pages containing dynamic content based on configurable queries. Content Broker’s API is public and can be used to retrieve published content using custom built applications. It allows organizations to deliver online content based on page context, queries and visitor profiles. Provides the ability to create the best balance between static and dynamic web site content.

On the static side, Content Delivery System (CDS) distributes published content from the Content Manager to Presentation Servers, where it is stored in either a file system or a relational database.

Presentation Servers provide storage management, link management and cache management to manage large, complex and high-performance environments. They also manage Dynamic Linking feature responsible for resolving and rendering of links between published content items.

All environments, with a possible exception of test/acceptance, require a dedicated machine.

Content Porter

Content Porter is a Windows client used to import and export code, content and other items from one environment to another (up and down the chain). Content Porter can connect to any OLEDB or ODBC data sources. It ensures a structured quality-control process for all online content. Allows organizations to transfer any type of content managed in Content Manager between different environments.

Archive Manager

Automates web site archiving processes, providing the capability to retrieve an archived wWeb page or entire site for a specific date, time and visitor profile and view these pages with the original content and layout. Enables an organization to comply with regulatory requirements and record all versions of web site pages.

Business Connector

Integrates with other applications, thereby allowing companies to include information stored in external systems such as product catalogs and inventories.

Content Distributor

For organizations with an international infrastructure that need to ensure reliable, scheduled content distribution to all web servers. It ensures content consistency and compliance through many different secure transport providers.

Personalization and Profiling

Personalization and Profiling module (which used to be called WAI) is aimed to create personalized web sites and web pages catering to specific audiences. It works with both explicit and implicit profiles, ensuring that content is personalized based on information that visitors have provided.

Communications Statistics

Tridion Communication Statistics module provides in-site views of how your content is doing. Users can track how their content is performing by viewing web pages with stats graphs on it in a staging environment.

Content Management Systems Reviews - Documentum - CenterStage

In my last post on Documentum, I described one of its collaboration products - eRoom. In today's post, I am going to describe another collaboration product of Documentum - CenterStage.

CenterStage delivers the benefits of enterprise content management, advanced search, and collaboration tools on a single architecture.

It allows to:

• manage and visually organize project, team, and corporate work information; 
• launch projects with space and content templates; 
• work with team members on documents in public and private workspaces; 
• find information wherever it resides; 
• gain access to this information from anywhere.

Public or team workspaces where contributors can share and exchange ideas and activities. There is cross-project visibility and awareness for easy project management of simultaneous projects. Users can establish roles and permissions for their team members, set workspace and content policies, and use templates to ensure best practices.

The CenterStage community model brings people and content together with similar interests or objectives. A community member can become aware of many contributors and their activities across different workspaces.

CenterStage provides wide range of collaboration tools: wiki, blogs, inline authoring, discussion threads, tagging, ratings. These tools allow “collaboration with context” – the ability to see inter-related items and information in one view.

Standalone tables

CenterStage provides standalone data tables to facilitate the management of content collections. A structured arrangement of related content organized into fields, columns, and data tables provide a way for teams to manage such information as list of planned projects, contact information, action items, etc. Data tables organize information into a series of related entries making them a useful way to manage such simple items as to-do lists or more complex items as inventory tracking data. With standalone data tables, information is easy to manage, track, and update.

Search and discovery

CenterStage includes advanced search feature. Users can search with one query an unlimited number of information repositories such as SharePoint, file shares, email archives, ERP systems, ECM systems. The results are filtered, merged, and organized into logical groupings so that users can navigate to the most relevant search results.

The search and discovery features are further enhances by different viewing capabilities, providing the ability to determine contents of any file or folder without opening it. In addition to the regular thumbnail view, users can hover their mouse over any file to display its metadata or employ the slides view to grasp the actual content of any file. Search and discovery enables rapid access to the most relevant content by extracting metadata such as company name, place, and topic, and then dynamically filtering the results.

Governance, risk, and compliance

Documentum Content Server is the back end to the CenterStage solution and addresses the need to ensure that all information is compliant with regulations, legal stipulations, and best practices. The content server provides a rich set of content management services and a comprehensive infrastructure for all content applications, so implementation and administration is simplified. It also provides the scalability, robust functionality, and service orientation for global enterprise deployments.

With the content server, companies can store and manage all types of content including HTML and XML, graphics, multimedia, and traditional documents created with desktop applications. All content can be safely managed and archived. There is full audit at all stages of content creation, approval, and use while enforcing information retention and disposal. This in turn ensures optimum network performance by eliminating isolated pockets of data and content stranded across the enterprise.

Other benefits

Branch office caching services – provides quick access to any type of content regardless of bandwidth constraints or network latency.

Content storage services – allocate content across storage tiers based on its changing value and access requirements.

Media transformation services – transform and manage content such as images, video, and other rich media.

Information rights management – secure information no matter where it travels to maintain control over that information.

Transactional content management – accelerate business processes such as invoice processing or case management.

Web content management – manage the content, underlying structure, and publishing process for web sites and portals.

CenterStage Key Features

Team and community workspace	Wiki, blogs, discussion forums, tagging, RSS feeds
Organization of structured content	Standalone data tables to manage content collections
Workspace and page templates	Lifecycles
Component-based UI and composition model	Advanced search and discovery
Policy-based configuration	Federated Search
Access control	Guided navigation
Lifecycles	Content analytics

Knowledge Centered Support

Knowledge Centered Support (KCS) is a methodology and a set of practices and processes that focus on knowledge as a key asset of the customer/technical support organization. Unlike the traditional add-on process of knowledge engineering, KCS is an integral part of day-to-day operation in support centers. KCS becomes the way people solve problems and creates knowledge as a by-product of problem solving.

While KCS is enabled by technology, KCS is primarily about people. People are the source of knowledge. KCS has proven that the best people to capture and maintain support knowledge are the people who create and use it every day - the support analysts.

Goals of KCS are:

1. Create content as a by-product of solving problems, which is also known as incident management process, as well as the problem management process. As support analysts capture information related to an incident, they create knowledge that can be reused within the support process by other support analysts as well as customers with access to a self-service knowledge base.

2. Evolve content based on demand and usage. As people interact with the knowledge base within the incident management process, they should review it before delivering the knowledge to a customer. If they discover the need to correct or enhance the knowledge, they will fix it at that time or flag it for another person to fix it if they do not have the access authority to the knowledge base. Under this model, knowledge is evolved just-in-time based on demand instead of just-in-case. This lowers the cost of knowledge management.

3. Develop a knowledge base from an organization's collective experience to date. New knowledge capture within the incident management process is an experience resulting from one interaction. This knowledge has not been validated or verified beyond the initial incident. Thus the initial knowledge is not as trusted in this state, which is referred to as Draft knowledge.

It is not until reuse occurs that trust is increased. At some point the knowledge will be marked as trusted and either approved for internal use or published for self-service. The knowledge base under the KCS methodology includes knowledge that is at different states of trust and visibility. The collective experiences to date challenges the traditional thinking that all knowledge in a knowledge base must be perfect, validated, and highly trusted.

4. Reward learning, collaboration, sharing and improving. The culture of the organization should change to recognize the value of an individual based on the knowledge they share that enables the organization to be more effective and efficient.

KCS breaks through the limitations of current support strategies and enables support organizations to deliver greater value with more efficiency. The secret? Capitalizing on what they already have - knowledge. This increased value is created and managed by capturing the collective experience of solving problems and answering questions, making it reusable, and evolving it to reflect organizational-level knowledge.

KCS takes teamwork to a new level. The organization must shift to a perspective that sees knowledge as an asset owned and maintained by the team, not by an individual or a small group of dedicated content creators. The focus of the team is to capture and improve the collective knowledge, not only to solve individual customer issues, but also to improve organizational learning.

For optimum performance, KCS practices and the tools that support them must be integrated with other support and business systems, including incident management, change management, and service level management processes and systems.

Companies that have implemented KCS in both their internal and external support organizations are reporting dramatic improvements in incident resolution, training times, in customer satisfaction, and in analyst job satisfaction. As a result, they are realizing substantial savings in operating costs at the same time they are seeing improvements in service levels.

Information Architecture Components - Search Systems

In my previous posts on information architecture components, I mentioned that information architecture components can be divided into four categories: organization systems, labeling systems, navigation systems, and search systems. I described organization systems, labeling systems, and navigation systems in my previous posts. In today's post, I am going to describe search systems.

Before creating a search system for your site, consider the following questions:

Does your site have enough content? - Consider the volume of content, balancing the time required to set up and maintain a search system with payoff it will bring to your site users. If your site includes many pages with information, then search probably makes sense.

Will investing in search systems divert resources from navigation systems? - If your navigation systems do not work properly and you are trying to solve this problem, do not implement your search system until you fixed your navigation system's problems.

Do you have the time and know-how to optimize your site's search system? - If you don't plan on putting some significant time into configuring your search engine properly, reconsider your decision to implement it.

Are there better alternatives? - If you don't have a technical expertise or money to configure the search engine, consider creating a site index instead.

Will your site's users bother with search? - for example, users of greeting cards site may prefer to browse thumbnails of cards instead of searching.

Choosing What to Search

Indexing everything does not serve users well. The creation of search zones, pockets of homogeneous content, allows users to focus their searches. For example, users of e-commerce site would be interested to search products. You could later create another search option covering the whole site.

Search zones are subsets of a web site that have been indexed separately from the rest of the site's content. You can create search zones in as many ways as you can logically group them. The decisions you made in selecting your site's organization schemes often helps you to determine search zones as well. Search zones could be: content type, audience, role, subject/topic, geography, chronology, author, department/business unit. Like browsing systems, search zones allow a large body of content to be divided in new ways, providing users with multiple views of the site and its content.

Web sites contain at least two major types of pages: navigation pages and destination pages. Destination pages contain actual information you want from a web site. Navigation pages include main pages, search pages, and pages that help to browse the site. Search should take users to destination pages. Navigation pages should not be included in the search results.

It is valuable to allow users to search specific components of your documents. This would allow users to retrieve more specific, precise results. This can also make search results more meaningful.

Presenting Results

A guideline to display search results is to display less information to users who know what they are looking for (for example, only author and title), and more information to users who are not sure what they looking for (for example, summary, abstract, keywords). You can also provide users with a choice of what to display. Consider your users information needs when making this decision. If in doubt, show more information.

Regardless of how many ways you indicate that there are more results than fit on one screen, many if not all users will not go past that first screen. So, don't provide too much content per result, as the first few results may obscure the rest of the retrieval. However, let users know the total number of retrieved documents so that they have a sense of how many documents remain as they browse through the search results. Also, provide a navigation system to move through these search results.

If there are too many results, provide an option of revising and narrowing search results. Locate "revise search" link next to the number of search results. Too many or to few search results are both good opportunities to allow users to revise their searches. Allow users to modify the search without re-entering it.

There are three methods for the listing search results: sorting, ranking, and clustering.

Retrieval results can be sorted chronologically by date or alphabetically by any content type - title, author, department. Sorting is helpful to those users who are looking to make a decision or to take an action (for example, list of products). Sort option should be the one that would help them to accomplish this task. Chronological sorting is useful if content is time sensitive, for example, press releases. It is very useful for presenting historical data.

Ranking is more useful when there is a need to understand information or learn something. It is typically used to describe retrieved documents' relevance, from most to least. Approach ranking carefully as users will assume that the top results are the best. Retrieval results can be ranked by relevance, by popularity, by users or experts rating, and by pay-for-placement.

Alternative approach to sorting and ranking is clustering retrieved results by some common aspect, for example, by category or by a ranked list. These clusters provide context for search results by providing the folder that seems to fit users' interest best. In addition, they are working with a significantly smaller retrieval set and a set of documents that come from the same topical domain. There are two types of clusters: automatically derived clusters and cluster based on categories created by human "experts".

Explain to users what they did and where results came from. Describe what content was searched, what filters were applied, any current settings, like sort order, etc.

Present users with the ability to save, print or email results. A type of "shopping cart" can be used to store selected search results.

Search Interface

It is best to keep your search interface as simple as possible: present users with a simple search box and search button. A good place to place the search box is next to site-wide navigation system at the top of the page. Be consistent in placing the search box. Determining what your users' assumption are should drive the default settings that you set up when designing the simple search interface.

You may also have advanced search interface. It should allow the manipulation of search results. This interface is typically used by advanced searchers and frustrated searchers.

Search is iterative process. Allow users to move back and forth between browsing and searching.

Adopt a "no dead ends" policy. It means that users always have another option even if they retrieve zero results. The option can consist of means of revising the search, search tips or other advice on ow to improve the search, means for browsing, a human contact of searching and browsing does not work.

SharePoint Architecture

The SharePoint platform is a flexible, n-tier service-oriented architecture (SOA). It can be scaled down to operate entirely from one machine, or scaled up to be managed across hundreds of machines.

There are few parts in SharePoint architecture: farms, web applications, site collections, service applications, administration and security.

Farms

A SharePoint farm is a group of SharePoint servers that share common resources. A farm can operate stand-alone or it can also subscribe to functionality from another farm, or provide functionality to another farm. Each farm has its own central configuration database, which is managed through a either a PowerShell interface, or a Central Administration website (which relies partially on PowerShell's infrastructure).

Each server in the farm is able to directly interface with the central configuration database. Servers use this to configure services (e.g. Internet Information Services (IIS), windows features, database connections) to manage the requirements of the farm, and to report server health issues, resource allocation issues, etc.

Web Applications

Web Applications (WAs) are top-level containers for content in a SharePoint farm, and are typically the interface through which a user interacts with SharePoint. A web application is associated with a set of access mappings or URLs which are defined in the SharePoint central management console, then automatically replicated into the IIS configuration of every server configured in the farm. WAs are typically independent of each other, have their own application pools, and can be restarted independently in IIS.

Site Collections

A site collection is used to provide a group of SharePoint Sites. Each web application will typically have at least one site collection. Site collections may be associated with their own content databases, or they may share a content database with other site collections in the same web application.

Service applications

Service Applications (SAs) provide granular pieces of SharePoint functionality to other web and service applications in the farm. Examples of service applications include the User Profile Sync service, and the Search Indexing service. An SA can be turned off, exist on one server, or be load-balanced across many servers in a farm. SAs are designed to be as independent as possible, so depending on the SA, restarting an SA, experiencing an SA failure, or misconfiguring an SA may not necessarily prevent the farm from operating.

Each SA enabled on the farm typically has its own process that requires a certain amount of RAM to operate, and typically also has its own configuration database and Active Directory (AD) service account. SharePoint Server and SharePoint Enterprise include all the SharePoint Foundation SAs, as well as additional SAs.

Administration and security

The modular nature of SharePoint's architecture enables a secure least-privileges execution permission.

SharePoint Central Administration (the CA) is a web application that typically exists on a single server in the farm, however it can also be deployed for redundancy to multiple servers. This application provides a complete centralized management interface for web and service applications in the SharePoint farm, including AD account management for web and service applications.

In the event of the failure of the CA, Windows PowerShell is typically used on the CA server to reconfigure the farm. The structure of the SharePoint platform enables multiple WAs to exist on a single farm. In a shared (cloud) hosting environment, owners of these WAs may require their own management console. The SharePoint Tenant Administration (TA) is an optional web application used by web application owners to manage how their web application interacts with the shared resources in the farm.

In my next post on SharePoint, I am going to describe the SharePoint parts that a user interfaces with: site collections, sites, libraries, lists.