The enterprise NoSQL database powering RSuite CMS has a major new update: MarkLogic 8. A wealth of new features are available in MarkLogic 8. Many of these are designed to make managing your data simpler, cheaper, and faster than ever before and will immediately be usable with existing RSuite installations. Other enhancements will provide our product team with new tools that will power features in upcoming future RSuite releases.

After taking advantage of the MarkLogic early release program, the RSuite product team has certified that RSuite is ready to be deployed using MarkLogic 8.  RSuite customers may contact support at anytime for upgrade coordination.  

We would like to congratulate our partner on this exciting release. By advancing the state of the art for database technology MarkLogic helps RSuite continue to raise the standard for content management.

For more information on MarkLogic 8 visit www.marklogic.com.

For more information on RSuite visit www.rsuitecms.com.  

The rapid shifts in publishing over the last few decades has lead most publishers to realize that the tried-and-true processes that served them well in the twentieth century may be hindering their ability to respond to the demands of twenty-first century publishing. Oftentimes part of the solution is a revision to the tools and technologies used to publish content. Technologies and tools can serve to catalyze and support needed change in an organization, but they cannot guarantee a successful outcome.

One person's hero becomes another's zero

It is tempting to look at successful peers for leadership when looking for effective revisions to your publishing workflow. After all, if a set of technologies and tools enables others to succeed, wouldn't the same approach succeed in any similar organization? Apparently the answer is "no" based on the number of failed attempts to address digital publishing requirements. Never forget that the success you see elsewhere is not just fueled by tools and technologies. There's a lot of work involved in the transition as well.

Is it the hammer or you?

It is tempting to blame the technology or tools when a transition begins to go badly. But remember, you cannot expect success with today's tools to succeed if you apply legacy techniques when using them. The tools of an 18th century blacksmith couldn't expect to compete with those of the industrial age. By the same token, modern tools cannot hope to achieve their promise with the techniques of the blacksmith. Modernization is doomed unless the blacksmith also changes. It is easy to blame the tools and technologies when transitions fail. Doing so, however, will only return you to your past - and a slow decline as more adaptable organizaeetions overtake you.

Change is often a slog rather than a glorious revolution. Never forget that it takes real effort to support a transition. Any transition will be accompanied by resistance and temptation to return to the past. Don't forget to prepare for the effort needed to move your organization after the tools are deployed.

Think about likely objections in advance. Be ready to address the real problem that lies behind the objections. Here are a few common examples when moving from traditional to digitally-oriented processes:

"These tools are impressive technologically, but won't work for us. We need something more like our old tools."

Likely problem

This explanation is often heard when those using the new tools or technologies have not had the time and/or training to understand the new environment. It is a challenge to continue production while migrating to a new environment. Unless those participating are properly prepared for the additional effort and given the appropriate resources, there is a good chance the transition will not succeed.

Solution

Provide training and resources to the staff as well as a knowledgeable champion who can serve to help facilitate a transition. When identifying such a person don't assume they will be the masters of your current systems. After all, masters of the artisanal processes may not be the right fit for transitioning to a modern machine shop. The current masters are no doubt critical to the future of the organization, but if they are firmly rooted in the current approach they may be slow to adopt new approaches. Sometimes, turning to external sources for these examples can work. Consultants or contractors can sometimes ease the transition. Don't forget to look for mentors in similar organizations who have made a similar transition.

"Our customer would never accept automated formatting."

Likely problem

Often publishing professionals assume that the standards of the 20th century are fully applicable in the 21st century. Remember, prior to the rise of sites like Google with is sparse design and interface web sites were highly designed. While pretty under carefully controlled conditions, as browsers evolved it became costly to maintain high-design sites. Today the web is dominated by utilitarian design and interfaces.

Solution

Consider whether your consumer will notice or care about any formatting issue requiring additional programming or effort. Oftentimes formatting issues that seem critical to a professional go completely unnoticed by the consumer. In many cases faster, accurate delivery trumps artisanal design for consumers.

Do the work

Transitioning to a digital-oriented publishing strategy is challenging. It is easy to find reasons to abandon new systems in favor of the old. But remember change is inevitable if you hope to adapt to and deliver digital content efficiently. The benefits available to publishers today can only be realized if you succeed at working your way out of your legacy approach.

Last week we attended the DITA North America conference in my home city of Seattle. It is always interesting to have the opportunity to interact with the DITA community. During a birds-of-a-feather lunch gathering I had some interesting conversation regarding the promise and perils of content re-use. Many of those in the conversation were new to DITA. As we discussed the challenges around content re-use in DITA I was reminded of the many pitfalls often encountered that often subvert the efficiencies promised by DITA.

The technical challenges of re-use

One of DITA's more attractive feature is its ability to provide a range of technical support for reusing content within or across publications. Traditional authoring and page layout tools tended to have limited support for re-use, and often the mechanisms for this support was proprietary. This is why more often than not these tools are underused in favor of copy and paste.

Re-use is baked into DITA

The DITA specification has effective, open concepts of re-use baked into the design. This means that using DITA for content authoring eliminates the technical hurdles limiting the re-use of content. It's topic-based approach encourages the creation of reusable content. Many organizations that move to DITA, then, are often surprised when after solving the technical hurdles content is still not widely re-used in their organizations.

Non-technical challenges

Many challenges to content re-use exist that are not technical. Unless these are addressed as part of a DITA project, wide re-use of content may remain an elusive vision. Here are some of the critical challenges that should at least be considered when trying to create an environment of content re-use.

Delivery assumptions

Most content delivered today is shifting from traditional print deliveries to a range of digital delivery formats. Yet when the content is authored it is often from the perspective of a single deliverable. Even though the tool may allow any section of a book to be re-used, you may find that the way the content is actually written prevents such use. Imagine a section of a technical manual that makes reference to other content contained in the manual. What happens if that content is re-used in a manual that does not contain the referenced section? And are such references required to be clearly tagged so that tools can provide assistance in managing such references when needed? Often this area of training is not well-addressed and authors continue to create content dependencies that are difficult to manage.

Authors who write content units only in the context of a deliverable will be tempted to write content that is dependent on the particular deliverable. You can't assume that they'll "figure it out" or that a tool can magically change such behaviors. You need to have a plan to train users not only on the technical use of the new tools but also the conceptual framework that DITA brings.

Oversimplification

Another temptation is to try to simplify your DITA implementation in an attempt to address potential dissatisfaction from your users. While it sounds like an XML editor that hides details and "acts just like Word" might be much easier for users to learn, if such a tool becomes an excuse to hide the details of DITA from the content creators then you may actually impede the realization of many of DITA's benefits. One of the important foundations of DITA is in separating content from presentation. This is at the heart of its powers to support single-source publishing.

In such a scenario, the concept of a WYSIWYG editor makes little sense. XML editors that provide a word-processor-like view are really better thought of as tools that present a style of XML useful for the authors in the creation of content. As such, when you design stylesheets for your authoring tool you probably do not want them matching your print output. Doing so risks obfuscating many important structures that are not visible in a specific print output but may be important foundations for re-use and linking. Instead of trying to match the authoring tool to a specific output format, you should consider creating styles for authors that make apparent the information they need to manage in order to create re-usable content. Metadata, conditional tagging and other supporting structures should be made apparent and easily accessed. If hidden behind a context menu or in an external panel users may find their use cumbersome. Worse, unexpected behaviors not readily apparent to someone re-using the content may occur. Such surprises often result in users avoiding the re-use of content they can't readily understand.

Access to properly configured tools and training is critical if you expect your users to take advantage of DITA's support for re-use. Not everyone needs to have a full set of content analysis skills in order to use a DITA system, but they do need to know the details of how your particular business environment is configured.

Lack of content management

Many DITA projects start using the DITA open toolkit and a file system or shared folder. But problems can occur specifically around re-use in such a scenario. Shared folders rarely provide controlled access to content. Content in directories often provides no mechanism for tracking versions, controlling updates, and ensuring that two users do not try to modify the same content (or overwrite others' content). When a small DITA project is rolled out to a larger set of users these problems worsen with increased content re-use. If a team runs into these problems they quickly begin creating copies of content anyway to avoid the problem — eliminating any potential benefits of content re-use.

Content management is also needed to support the organization of content components. Content management systems often provide the ability to support metadata and search features that make locating potential content for re-use much easier. Relying on a shared folder typically means that as the number of content components increases users' ability to find re-usable components decreases. At some point, users may decide its easier to write new content rather than try to deal with these challenges.

Unless you have a very small team that is tightly coordinated content management is an important tool for maximizing your investment in DITA.

Earning your wings

These examples represent just a few of the many potential challenges that can surprise newcomers to DITA. Some may be addressed through training. Some may improve with experience. But it is very hard for organizations new to DITA to make content decisions before they have sufficient experience. And there is often a chicken-and-egg scenario where the promise of DITA remains unrealized without an investment in tools to properly use it. Such investment is often risky, as it may require investment in integration, licenses and products unfamiliar to your organization.

In the last several years, however, tools like our own DocZone product are available that provide preconfigured integrated DITA tools on a hosted basis. For a monthly fee, you can license the use of DocZone's best-of-breed tools in an already integrated and configured environment. If your organization is new to DITA and/or content management such a solution can enable users to build experience on a professional platform without the cost typically associated with setting up such an environment yourself. Because you are in a proven, production-ready environment you are less susceptible to many of the problems typically encountered when setting up a new DITA environment. A hosted solution also can scale to address the requirements of small and large teams. The use of DITA also means that your content can be used with other DITA-based tools if needed.

Trying to achieve the full promise of DITA is a challenge whether you try learning in an ineffective shared-folder environment or try integrating an end-to-end DITA toolset for the first time. A hosted option like DocZone is a great alternative to taking on these challenges alone.

Software applications present some of the greatest design flexibility as it tends to lack many of the conventional constraints present in the physical world. In my last blog entry I wrote about some unintended ways even a good design can go astray. Similarly, customer requests have the same potential for creating problems with a product.

The customer is always right?

The first time I built an application was when I was moonlighting on database application development. In this case, the customer had space in their office where I worked. I could engage one of the users of the system any time and have them provide immediate, direct input as I went along. We rolled out the application and it proved nearly unusable. Because much of the design evolved organically focused on the details, the overall system proved unusable.

A lesson on context

I ended up discarding much of the work we had done and starting over. This time I now understood what the customer was trying to do. I also had seen firsthand how building features without a strong sense of context could create a system that was very difficult to use. I started to work in the off hours when the office was empty. Then every few days engaged directly with the customer. This ultimately proved successful.

Lessons learned

My early programming experience in many ways mirrors that of the software industry. New methodologies have been developed to develop applications that respond to a customer requirements in a productive manner

The redesign of RSuite 4 provided the opportunity for us to also revise our product development methodology. We now use the Agile methodology with shorter design cycles and more frequent updates so that product development efforts are validated quickly.

Agile allows us to be more responsive to customers. Instead of developing for months or years before putting development in the hands of users, AGILE dictates shorter development cycles usually measured in weeks. Priorities can be shifted rapidly if needed. Unexpected issues that might derail the timeline in a long development cycle are now incorporated into the normal product engineering routine.

Community input

Before beginning the redesign we launched a new community support site for our customers. This site handles the traditional support issues and made it much easier for our customers and support agents to track and resolve issues. It also serves as a "database" that the product management and engineering teams can reference when prioritizing new development.

A corporate memory of customer issues provides a historical backdrop to better understand areas that challenge users. Active, unresolved issues can also be evaluated immediately. At times we will identify an issue that we are in a position to address quickly. Already we have made UI changes that may not have been formally brought to the team's attention. Potential product improvements may be discovered whenever a customer contacts support to use a feature.

Community tools

The support community also offers customers community forums. Documentation as well as formal and informal information about RSuite can be found in our forums. Some forums are entirely made up of official information from us. Other forums are dedicated for customers to make and comment on suggestions, request advice, or offer their feedback to other customers or us. There are forums for both end users as well as integrators and developers. Having this communication available is a valuable source of direct and indirect feedback for us. 

Implementation reviews

Implementations of RSuite are also an important input into the product. We review implementations, conduct customer visits, and also host an annual conference so that we can maintain engagement with our customers and understand how they are using the product. Regular meetings occur between product management & engineering and the project managers. RSuite imposes no theoretical limitation on how the product can be extended. When we look at how solutions were implemented, we sometimes identify things that will help improve the efficiency of future projects. We can also verify our best practices are being followed and determine areas for improving communication.

Responsibly responsive

Customer feedback is an important consideration in keeping RSuite's evolution responsive to our customers' needs. Users of software may have suggestions about a specific product modification or addition. Sometimes these suggestions can be implemented as requested. To be sure it is important that we also understand the motivation and requirements behind the request. We must then consider the best strategy to address that need. Sometimes that may not exactly match the initial request. But it will likely lead to a superior result if it is contextualized with a broader product vision.

I had the pleasure to attend MarkLogic World 2014 last week. This event is always interesting and this year was no exception. I particularly found David Gorbet's day 2 keynote one highlight of the event.

Is your data center data-centered?

During the talk David discussed how too many data centers are focused on applications instead of data. Lacking a central data strategy, many organizations deploy applications as isolated silos of information targeting a single purpose use. With each new application, maintenance of the infrastructure as well as the quality of each data store is an increasing challenge. Tying data together in a meaningful way requires great effort when repositories have been designed solely around a specific application.  

MarkLogic is working to provide organizations with a way to create a true data center, with the ability to not only store data in a variety of ways like XML, JSON and binary documents. Even their licensing, training and technical announcements were presented as ways to improve MarkLogic's ability to support a data-centered data center.  

What about your content?

MarkLogic's vision for data closely aligns with RSuite's vision for content. With a canonical representation of all available content, an RSuite system can support a wide range of strategic content initiatives as well as serve as a content center for a variety of other applications. New opportunities can be pursued more quickly even as resources and risk are reduced - opportunities including new print or digital presentations, mobile apps, mash-ups, content syndication, expanding markets and new technologies for content distribution.  

RSuite brings content to your data center  

RSuite's MarkLogic-powered content management capabilities can play a key strategic role in making your content part of a data-centered data center. There has emerged a proliferation of options for creating content silos: file shares, cloud storage, NAS storage, or the myriad of other content stores offered by various tools and technologies. RSuite offers capabilities helping you bring your content and its management into a data-centered data center.  

With the ability to not extend your content with additional layered metadata and present subsets of metadata in forms targeting a range of applications and users, new requirements can be addressed without new silos. A foundation for data and content is an important tool to enable your organization to respond with agility to new challenges and opportunities in publishing.   

Maximizing the value of your content  

It's exciting to see how organizations who have invested in such strategic initiatives are recouping their investments not only through greater efficiency but also their ability to pursue new opportunities and explore ideas without undue risk. It's rewarding to have the opportunity through my work with RSuite to see organizations move to maximize the value of their content.

Constraints can be beautiful

Several years ago (before I had worked with RSuite), I posted on my personal blog a couple of times on the merits of constraint in design http://blog.chiliarchy.com/search/label/constraint. At that time, I was dabbling in software design but had yet to be responsible for establishing and communicating constraints to the engineers building a software application.

The redesigned RSuite of today often challenged me and the engineering team to balance many competing opinions and interests. With an application offering the flexibility of RSuite, it is tempting to always do more.

Engineers tend to like building things. A good engineer's "can-do" attitude will favor developing enhancements. It's more fun to create new code. Going back through existing code to refactor, trim, or remove can sometimes feel like cleaning out the garage.

Customers often request more, seldom request less

Project managers, the tip of the spear when it comes to customer projects, are also often managing requests for features. Customers tell them they need a button, widget, dial or gadget and it seems simplest to just add it. Rarely does a request come in to remove anything.

Features have immediate and ongoing costs

It's obvious that a new feature costs something to build. Most people consider this when deciding whether or not a feature is worth adding. The more important factor is the long-term costs that aren't so easy to identify. A single button can have an exponential effect on the number of test cases and unintended interactions. Documentation and support have to be revised and maintained. More features often mean more visual elements for users to process when using the software. These penalties often seem relatively tiny when viewed in isolation.

An automotive example

I was on a work trip driving from Minneapolis to a city several hours away in a rental car. I rented a Ford Focus, a car I actually owned in 2000. It was a dark winter night in Minnesota, so I took time to check the lights, made sure I knew to to operate the various wiper modes, adjusted my mirrors, and familiarized myself with the climate controls and stereo.

Unexpected company

After 45 uneventful minutes on the road, I made a quick stop for food then headed back out on the dark two lane highway. Twenty minutes later a car overtook me from behind. Rather than pass, he tailgated for a few annoying miles. Suddenly a flood of police lights had me pull over to the side.

As the patrolmen cautiously approached I fumbled for the window controls.

The car "helps"

As I was trying to unroll the window, the Microsoft Sync voice came over the speakers asking how she could help. I didn't know what I had bumped that caused this but decided to first get the passenger window down. As it opened the patrolman asked for my license. As I retrieved my wallet the car's computer voice told the officer she didn't understand the command, could he try again? I began to try to explain when the car interrupted and began listing some examples of commands she could understand.

I fumbled around for an "off" switch. Suddenly the controls I thought I largely understood were becoming confusing. I turned off the key but she kept talking. I pushed several more buttons. I pulled the key out of the ignition. She kept talking. Then I remembered that the power to the accessories remained on until the driver opened the door. I gently pulled the door latch and she fell silent. The officer seemed mildly amused as he said, "Rental car?"

Good design or a trap?

Ford's engineers had done an excellent job adding lots of additional features to this car without making it seem unfamiliar.

A myriad of optional features were present, but not obtrusive. I had left the airport confident that I could competently operate the vehicle. Under stress, however, the inadvertent activation of voice control had suddenly made me realize the large number of controls I hadn't paid attention to. In my attempts to silence the computer I had tried pressing many of them. Would I regret some of those actions later?

Taillights-off mode

The patrolman informed me that I was driving with no taillights. I told him the headlights were working and that they must have burned out. He said that he had seen this a few months prior on a Ford pickup, and asked me to try all the positions for the light control. I turned the knob to several positions. "That's it. Remember that setting."

While he went back to his car with my license, I studied the symbols on the headlight control. What seemed so natural an hour ago now looked like symbols on an alien spacecraft. The patrolman returned with my license and wished me good night.

A dubious feature documented

I'm still not sure why the car could run with the headlights on and the taillights off. Later I consulted the owner's manual. To improve accuracy and save costs, automobile manuals are modular to accommodate re-use across models and provide for optional features. In the manual, there was what appeared to be a single page showing the use of the lights. No where was there any mention of the possibility of using headlights without taillights.

If you were reading the owner's manual cover-to-cover you'd find two more pages on the lights. When was the last time you've done that? At the end of the third page, below several optional features that were irrelevant and further encouragement to stop reading, was this warning.

I had to read it a few times before realizing it applied to me. Although I still wasn't sure how this all played out. Even if we were to move the warning to a more prominent place at the beginning of the section and clarify its language, how many people have read the owner's manual before operating their car for the first time?

A lesson for IT projects

Whether designing a car, creating a piece of software or customizing an application for your organization, managing whether and how features are added is an important activity that is too often overlooked. It is easy to see how a feature might help when used as directed. The real challenge is in being able to see potential unintended consequences the feature may create.

Whether you are designing, modifying or selecting software, it is tempting to just list all the desired features and evaluate its presence or absence. Much harder is evaluating whether the features provided are provided in a usable way. Don't assume that more is always better. Sometimes a feature like "headlights on taillights off" can create problems for users.

If you find yourself having to place warnings or cautions in the documentation you should be reconsidering either the presence of or implementation of a feature.

Software often has an advantage over car design in that it is easier to add custom features to software. The CMS I work on, RSuite, makes it possible to implement features for a subset of users if needed. Sometimes customers complain that some feature isn't included.

Balancing features and design

RSuite has a flexible user interface that can accomodate a wide range of features. Menus can be rearranged and reorganized easily. This makes it not only easy to make product changes, but also can be used if a customer wishes to customize RSuite for addressing specific business requirements.

When developing the product we strive to balance the impact of additional features against the overall product usability. This often means looking for ways to clarify, simplify or modify other areas of the interface. It is also vital to test for unintended consequences that may inadertently create potential problems for users. 

Reflect on your design

A major goal as we work on our RSuite product is to find ways to design RSuite's interface to support the highly flexible architecture while discouraging practices that might create problems that are invisible or difficult to correct. This is a primary consideration whenever a user-facing modification is made to the interface. Even though objective perfection is not possible in any design, we strive to examine each implementation and look for potential refinements that could benefit the product as a whole.

We've made a number of refinements over the last several months from these activities, and have identified more substantial changes that will be rolled out in upcoming releases. Some of these will actually provide additional features to users while reducing complexity.

Potential signs of design problems

There are some areas that often indicate potential design problems. None of these are a smoking gun, but they are good starting points when reflecting on a design.

Does the feature rely on an "Are you sure?" confirmation before performing an action?

Do you find your support staff complaining that users don't read the manual? 

Are you putting cautions and warnings into your documentation?

Do you rely on users to report problems? Remember users often are unaware of problems they may have inadvertently caused - instead blaming the software.

Are there "irrational" complaints or support requests that cannot be reproduced? 

Are there support requests that have been marked "as designed"?

Have you looked at what aspects of product implementation require the most customization effort, documentation effort, or training effort?

More is not always better

Sometimes they are right and we add the feature. Other times the request is narrow, and adding the feature would probably result in more harm than good. It is easy to overlook this whether designing, modifying or evaluating software. Creating a long checklist of features is tempting. But make sure those features don't leave your users in the dark with their taillights off.

In the coming months, I’ll periodically be writing a bit about the design of RSuite 4. It has been very exciting to see the effort and thought we put in to the user experience translating into a much improved experience for our users.  

RSuite 4: Unnaturally Natural By Design

Many of our new customers starting out with RSuite 4 may not be aware of the effort required to put together such a natural design. It’s easy to forget that thousands of hours of thought, design, and refinement by many people are usually behind those interfaces that seem so effortless. Starting now and for several months I will be periodically posting this series of behind-the-scenes discussion of RSuite 4. Along the way you will have the opportunity to get a taste of some of the major challenges and opportunities when designing software user interfaces.

Indirect Action Traps Unsuspecting Users

Traditional content and asset management users might click on an image then scoot up to a toolbar or some menu to conduct an action.  You might find the preview button on the toolbar. Click it and the selected image is previewed for you.

This works fine if users operate with a clear understanding of what item they have selected as well as an action’s area of effect. Accidentally clicking the mouse or forgetting about a change of selection and users may find they've acted on the wrong item. With each mistake an inexperienced user’s confidence is eroded, often snowballing into more errors. Not only are inexperienced users struggling to get their work done, now they have to undo their mistakes. If they can find them...

Look at the RSuite 3 screenshot. The selected item is clearly identified with the orange highlighting. Bump the scroller on your mouse, however, and that orange item can slide out of view. The toolbar, though, remains visible and is still ready to act on the now-unseen item. If you are sure that the now-hidden item you want to act on is still selected then you can click the toolbar. Most users lack this surety and instead have to scroll around until they can double-check that the right item is still selected. 

After observing many types of users repeat such behaviors in a wide range of software applications, I suspect that users have become resigned to these error-prone designs. They aren't aware that this checking and double-checking is time consuming and directly impeding their ability to get work done.

Context Menus: A Step In The Right Direction

In the mid-90s mainstream computer software adopted context menus, menus accessed by right-clicking an item and selecting an action to take from a flat list of menu items. Context menus had the advantage of providing users a direct action interface. Right click an item and a list of actions relevant to that item are displayed. It was definitely a step in the right direction. Web applications like RSuite 3 typically offer context menus.

Context menus were great for users who figured out how to right-click something provided the action you wanted to take was present in the menu that appeared. But the flat menu design of context menus generally lacks the density of functionality of buttons on a toolbar. So the compromise of context menus is that some subset of available actions appear in the context menu.

A Context Menu or Scavanger Hunt

Most interfaces ended up with many actions available only in the toolbar or some traditional menu structure. It is common to also find a few actions that are only available in the context menu. There also might be additional menus hiding somewhere with the action we need. Inexperienced users struggle to memorize the interface or become a highly practiced scavenger hunters as they try to get their work done.

A careful UI designer will go to great lengths to design some logic into the interface to explain why some actions are in toolbars, others menus and still other in context menus. Unfortunately understanding the design logic usually requires a solid understanding of the application. So users who could be greatly helped if they could more easily act within the application lack the level of understanding of the software needed to interpret the design logic. 

Extensibility Is A Design Challenge

RSuite’s renowned extensibility usually requires integrators find places to extend the UI in order to interact with the user. Should I put a new button in the toolbar? In the context menu? Add to some existing menu? Or look somewhere else? Or maybe put it everywhere? Instead of focusing on the actual business goals, most traditional UI designs bog integrators down in decision-making, UI coding activities and design tasks that are not productive or efficient uses of their time.

In spite of an integrator’s best intention and effort, traditional integration projects can end up producing customized applications that feel more like trying to land a 1974 jumbo jet for the first time rather than doing my actual job. While it is easy to blame the integration team, sometimes you might find that traditional software design and integration points are complicit in the ineffective result.

RSuite 4: Consistent, Direct, Logical

RSuite 4 uses a direct action-based interface revealed by left-clicking on an item. Long toolbars filled with inscrutable icons are no longer present. Traditional menus are reserved for a few special cases. If a user wants to know what actions are available on any item in RSuite 4, just click it. Every available action for the item they click on is displayed clearly in an action menu.

Want to act on an image? Click it. A menu with icons and text clearly communicate all of the actions you can take. This simple approach means that no experience is necessary to discover what actions are available. Over time, as your implementation changes, users only have to understand the changes to the business-specific actions available. The UI remans consistent. 

Integrators have a clear, consistent design language for any extensions they care to add to RSuite. The application’s logical design greatly reduces the effort required for most common integration tasks. Adding to or removing from an action menu doesn't require any complex Javascript or other UI coding.

Would You Like To Know More?

With RSuite 4 we have worked hard to remove barriers that are still far too common in business applications. If your interested in seeing more check out our online video tour or visit our website to contact us for a demonstration.

If I was asked to design an A-list American holiday, I would never have come up with Thanksgiving. As a kid I enjoyed a few Thanksgiving dinner staples, but would have traded them for a trip to Dairy Queen in a heartbeat.

I’ve spent my share of Thanksgivings trying in one way or another to adhere to the holiday’s intended design, usually with the same cast of regulars from my daily life. 

On occasion I’ve celebrated the holiday in a house of strangers, save for the friend or two who dragged me along. One Thanksgiving I spent in The Hague, Netherlands, at a training course. I dined on my first Indonesian meal with my classmates, the only American at the table of near-strangers.

The Thanksgiving that gives me some of the warmest memories I spent alone in my room in a deserted dormitory in Minneapolis. How could a roast beef sandwich, fries and medium Coke be so memorable? The clerk who prepared it was friendly and wished me a happy Thanksgiving as I left with the bag of food. But when I discovered the promotional gold-rimmed holiday glass at the bottom of the bag - usually requiring an extra charge on a large soft drink - the clerk transformed the modest meal into a memorable feast. It remains one of my favorite Thanksgiving memories.

Something about Thanksgiving's design seems to work well even when circumstances would not seem conducive to a positive experience.

Thanksgiving's ability to create these strong feelings are not easily identified on paper. Imagine if it were invited to an RFP selection process:

American Holiday rankings:

1 Christmas (38)
2 Easter (31)
3 New Year’s Day (28)
4 Independence Day (26)
5 Valentine's Day (25)
6 Thanksgiving (24)
7 Labor Day (19)
 8 Halloween (16) 

This isn't even close to how, outside of a feature matrix, I would rank the holidays. I suspect most Americans would say the same.

A number of assumptions are inherent in this type of ranking process that produces results incompatible with our actual experience.

Do all of these features have equal importance and rank?

If I don’t intend to eat candy or decorate my home in holiday lights, should I include these features “just in case” I might want to do that someday?

We forget that adding unwanted/unneeded features to our matrix might be detrimental. Imagine being the only person not in costume at a Halloween celebration or an atheist at an Easter service.

If I had put this scoring system into my RFP, Thanksgiving would not even rank in the top half of the holidays. It turns out that Thanksgiving’s subtle design choices are easy to overlook when insulated from any actual experience.

I know that regardless of how the food turns out this evening, today is already a highlight of my year as I reflect on the many personal and professional things I have to be thankful for. 

If today you are also celebrating Thanksgiving, I hope yours is happy and memorable too.

Lately I’ve found myself doing more discussion of DITA, so it is time for another in the 5-minute-series. If you are new to XML it might be helpful to start with the previous two posts on XML and Schemas before continuing.

In the previous posts I discussed how XML isn’t a specific language, but is instead a set of rules governing the syntax of languages that may be invented. The invention of XML came out of a need to be able to describe content. Word processors and desktop publishers mostly focused on the formatting of content. When you create new content in these tools you do so as a part of the layout and formatting process. With XML, you instead try to describe what the content you are entering is, for example a paragraph, a chapter, a book, an article, a caption or whatever. 

XML provides a common syntax for creating languages to describe your content, but does not specify the actual grammar. As described in detail in the previous post in this series, XML Schemas or DTDs are used to specify the exact labels and grammar of a particular type of XML.

While you can invent your own labels and grammar based upon XML, doing so means that unless others adopt your format, you will have to customize editing tools to understand your particular vocabulary.

Instead of always creating a vocabulary from scratch, many users of XML instead adopt a shared standard. Standards exist to represent most any data you can think of, whether it be recipes, musical scores, articles, chapters, books or anything else. These standards can be shared, and tools can be created to create, edit, manage and format based on the standard. If a community exists around my particular flavor of XML, we can share tools and techniques that can mean reduced effort required to deploy content solutions.

DITA, an acronym for Darwin Information Typing Architecture, is an XML language that is extensible and can be adapted to a range of uses. DITA is based on the concept of topics. A topic is a unit of information that typically can be read in isolation or inserted into a larger document. In order to stream together topics, DITA uses the concept of a map file. A map file is simply an XML file that acts as a sort of table of contents stringing together a series of topic files.

The term “topic” is generic. DITA allows, however, the generic topic to be adapted to represent more specific structures. The basic DITA specification includes Concept, Task and Reference. These content units are more specific versions of the generic topic. They can be handled with special rules if you want. But if you don’t haven special rules, they can be also treated more generically as topics.

Benefits of a common vocabulary 

Having a common vocabulary means that users of the vocabulary can share information with each other and share tools and code used to handle the content. For example, if you use a DITA-based format, there are a number of editing tools that can be used to edit your content. Tools used to process the content can also be shared. For example, DITA includes the code and stylesheets needed to create PDF, HTML and other output formats, and the community is constantly evolving. New formats may appear and other DITA-based solutions can take advantage of the tools to support the new format without needing to modify their existing processes.

For DITA, the community provides the DITA Open Toolkit. This toolkit includes a variety of transformations that can take DITA content and render it in HTML, PDF, and other formats. It also provides an extensible architecture. If you have a customized version of DITA, you can create a plug-in that can enable DITA solutions to handle the specific requirements of your customizations. Toolkit plugins can be used to configure editing tools, extend the rules of DITA, or modify the included stylesheets used to render content so that they can account for a most specific vocabulary adapted from the base DITA stylesheets. Any DITA tool can process content even if it is based on proprietary extensions because all of those proprietary extensions are mapped to more generic DITA structures. So if I use a DITA-based vocabulary that defines a “chapter,” systems that do no understand “chapter” can always treat the encoded content as a more generic “topic.” 

So while XML is a set of rules for creating a particular language to encode your content, DITA is a particular language that was designed to be able to be extended to more specific uses that still share a common grammar. DITA provides a base set of stylesheets for rendering your content in a variety of specific formats. Many XML tools exist to process any DITA-based document, and most provide extension points so that you can adapt the tool to a more specific DITA-based language without having to start from scratch. 

Tools to edit DITA documents can edit any vocabulary derived from DITA without modification, and can be extended to support more specific vocabulary structures if desired. At RSI Content Solutions we have content management systems with support for DITA that provides a range of features that make it much quicker to deploy a DITA solution without starting from scratch. Our solutions allow editing, transformation, as well as the ability to reuse content in different contexts if needed. So while XML is a set of rules governing the structure of an infinite variety of languages, DITA is a topic-based XML language used for representing content. Although you can use DITA without any modifications, many organizations wish to encode content in less generic manner. DITA has the advantage of allowing more specific content structures to be derived from the existing generic structures if needed. This means that if you need to create an XML vocabulary you aren’t starting from scratch and you are providing a fallback mechanism for systems not aware of the specifics of your particular vocabulary.

For the bulk of my 10+ years in various jobs involving content management I found myself routinely discussing metadata at work. I don't know if I ever recall the subject arising outside of that sphere. This month that has changed literally overnight. The breaking news on the National Security Agency's PRISM program - apparently focused on collecting metadata regarding telephone calls - has brought metadata to the attention of the general public. Suddenly I'm reading tutorials on the term metadata in newspapers and magazine, hearing it defined on network television, and finding opportunities to discuss metadata with my non-technical family, friends and acquaintences. I've often said that metadata can be just as important as the content it describes, and the PRISM program serves as an excellent example of this.

I find it sometimes dismaying that even today content management problems still neglect to give proper attention to the subject of metadata. Many of the RFPs I read have highly detailed inquiries regarding the ability to work with content including re-use, componentization, and other sophisticated capabilities. Most of the time, however, they make only a few cursory inquiries regarding metadata neglecting key capabilities that can adversely affect the ability to take advantage of some of these advanced content management capabilities.

Here are some of those neglected metadata capabilities that may have a major impact of your ability to solve your content management issues.

Extensibility

More times than I care to remember I have worked with systems that have very little flexibility to modify metadata requirements after they are deployed. These are often related to technical implementation issues relating to the underlying architecture. You know you are working in such a situation if adding a new metadata field requires system downtime, interventions of a team of database administrators, or the cooperation of a team of programmers.

In practice such systems tend to limit metadata to a few narrow cases and fields. This is sometimes tolerable with systems dedicated to specific tactical production duties or limited content repositories. But when trying to deploy solutions horizontally through an organization or adapt a production system to a broader set of requirements or tasks it is typically easier to just deploy another content management solution than adapt the existing one. 

When I worked for a semantic text mining company we provided a tool that could extract a list of all of the important metadata values from a piece of text. This included things like lists of people, places, companies, landmarks, events, etc. present in the text. There was no artificial limit to how many of these things might be present. Unfortunately, when we worked with many companies we found their systems could only deal with a predefined number of items, and the user interfaces were not well-equipped to present or manage these lists of items.

Look for a content management system that has the flexibility to be modified over time. Inquire about how metadata is stored and the provisions to modifying and expanding it. Can metadata fields have any number of multiple values? Try to uncover these limitations in both storage as well as user interface.

Selective presentation

Another problem that plagues many systems is their assumption that all metadata fields are important to all users equally. In reality, most users are only concerned with - or even prepared to understand - a subset of the metadata on a piece of content. Compare the key interests of your editorial staff to that of your marketing team or legal department. Are you able to selectively present each potential viewer of content with appropriate metadata that serves their needs, without wading through a lot of information that isn't important to them? I have sat through many analysis meetings where representatives of every stakeholder gather around a table and spend hours, days or weeks trying to agree upon a comprehensive set of metadata.

Instead, look for your content management system to provide the capability to selectively present relevant metadata to different audiences. This should include the forms to view and edit metadata as well as a means to provide different search tools that make it easy to filter based on each category of users' requirements.Then you can maintain a large body of metadata appropriate to a wide range of requirements without overwhelming an individual user.

Context sensitivity

Today it is common for organizations ask for a content management system to provide them with the tools to re-use content. Yet even when the requirement is specified and delivered, in practice the capability often goes unused. One of the hidden reasons for this is in the inability of most systems to allow metadata to vary based on context.

In many situations a user may want to re-use a piece of content in a few places - but requires different metadata values in each place. As a simple example think of a photo caption. A caption appropriate in a novel may not work when the photo is used in a news article. Digital rights may be secured for the same photo multiple times, each needing its own context-specific representation. In countless situations like these, the inability to have some of the metadata vary by context means that users are forced to copy and paste content and cannot take advantage of the re-use tools provided by a system.

Even if the initial deployment of a system will not require contextual metadata you will probably find yourself wanting the capability at some point in the future. 

Versioning... or not

Most content management inquiries will ask about versioning content. But what about metadata? In many systems, metadata is either a required part of the version history of content - meaning that every change to a metadata field creates a new version of the content. This may be desirable for many of the fields, but there are some cases where all of the versions created by metadata changes end up generating so much noise in the content's version history that those features become difficult or impossible to use. 

At the other end of the spectrum are systems that do not version any metadata values. For important metadata values, this can be risky as there is no way to determine when or even if a metadata value was modified. 

In reality, most organizations will have some metadata they want to keep in the version history and others that they do not. Unfortunately, it is generally after they have started putting a tool in production that most people find out the capabilties of their system.

These four metadata requirements are significant in their impact of content management and can have major implications on how a system is implemented and adapted over time. While not all of these are a necessity to a single solution, their absence may make it difficult or impossible to adapt or expand your system in the future. 

You may be thinking of some other neglected metadata requirements you've run across. If so I'd like to hear about them.