Approaches for deployment and access of content in delivery portals

In the field of Technical Communication the focus has always been on supporting users in their search for information in a way that is appropriate for the target group. Products are becoming more and more complex, current standards require manufacturers to provide up-to-date Technical Documentation and digitalization is advancing rapidly. Content Delivery Portals offer new possibilities to provide information in a timely and user-friendly manner. They make it possible to provide the user with web-based, target-group specific information through navigation with facets and presents a new possible use of search engines in Technical Documentation. This paper deals with different possibilities on how content can be deployed and accessed for the user. The approaches are implemented in tools that are already on the market to illustrate the possibilities of deployment and access on real-life circumstances. In addition, an outlook is given on what the conceptual implementation of microDocs might look like.


Introduction
Search engines are ever-present in our everyday life. The most used search engines providing us with various information are Google, Yahoo!, bing, Baidu and YANDEX RU [1]. They present search results when the user, for example, searches for a restaurant nearby, for specific products or simply to retrieve general information of just about anything.
In our research we dealt with search engines in a very specific field. Companies try to use enterprise search systems to provide users with the necessary information needed for their situation in the shortest time possible. We investigated two approaches to provide content for the user, tested the possibilities of filtering and elaborated on both of the approaches by means of two different Content Delivery Portals.

Theoretical Overview
Although already widely known within the field of Technical Communication, this paper will give a short overview on the methods of generating Technical Documentation, especially on those used for the academic project of Karlsruhe University of Applied Sciences and the University of Aizu in context of Content Delivery Portals and ontology usage. In order to do so, it is important to explain the definition of the terms topics and documents with which technical writers work while generating Technical Documentation and the reasons why some technical writers prefer one method over the other. Furthermore, the usage of metadata and its relevance will be clarified, especially relating to this research.
For our research topic we wanted to find out if it is more practicable to work with single topic files or with whole documents. To accomplish this, we worked with different systems and different types of filters. The initial question was: How can we best engineer our content for the user accessing it in a Content Delivery Portal?

Topic
In the field of Technical Communication a topic is defined as content that is self-contained and can be understood without further context. Overall, there is a rule that just one thought should be integrated in one topic, so that the content is clear and easily understandable and the user does not get overwhelmed with too much information he does not need at that time [2].

Topics and metadata
To define a topic unambiguously, metadata is needed. With clearly defined metadata, a specific topic can be retrieved and differentiated from other, similar topics. There are different concepts for attaching metadata to a topic. In the academic project of Karlsruhe University of Applied Sciences and University of Aizu, the PI-Concept which was developed by Prof. Dr. Wolfgang Ziegler was used for the metadata. This concept consists of different types of metadata. On one hand, there is metadata that describes the product and on the other hand there is metadata that describes the type of information given. Furthermore, the PI-Concept differentiates between intrinsic and extrinsic metadata [3]. Intrinsic metadata describes the product or the information itself and explains what it is, so for example, the product is the smart home device "smart bulb" and the information type is a task. Extrinsic metadata describes, where the product or the information is used, for example, a specific cable is used in the smart home device "smart bulb" and the information is used in an installation manual.

Document
Often, it is not enough just to view a single topic to help the user deal with his problem. For example, if the user wants to know how to install the app for controlling the smart home device "home energy use monitor", he may need further information about the app, the registration for the app or maybe he needs to know how he can connect his smartphone to wifi to download the app. For some topics, it is insufficient to just show the user this specific topic, but he needs further information from other similar topics to fulfill the steps he wants to do with his product.
One approach to solve this problem is by working with full documents. In the field of Technical Writing it has long time been the standard and often still is to think of documents as a whole that consists of different topics in a logical order. Documents are structured by different concepts, for example, the table of contents at the beginning gives a first overview as to where the user can find certain information. But there are other approaches for the user to navigate as well, like glossaries or crossreferences in printed document and hyperlinks in Onlineor PDF-documents. The benefit of a document is that you have full context and all of the information that is needed for one special product to be found in one place. There should be no questions without answers left after reading the whole documentation. But that is just a theoretical view on how a user can use Technical Documentation. In real-life nearly no one reads an entire document of Technical Documentation for a certain product. He simply searches for the information piece or topic he needs and possibly uses other topics to get some more context. Therefore, sometimes a single topic isn't enough because the user needs more context, but a whole document is often too much.

Evaluation of topics vs document
In every-day life both approaches -giving user information with single topics or in a whole documenthave their reason for existence. Everything depends on how much content the technical writer has already gathered. If there is no Technical Documentation readily available, many technical writers work with a top-downapproach where they generate single topics based on rules and use them in a Content Delivery Portal. If there is already some published Technical Documentation the technical writers often already thought in whole documents and normally just works ahead with this bottom-up-approach [4].

Implementation of the research topic in a real project
For the project between the students of Karlsruhe University of Applied Sciences and the University of Aizu, the topic "Smart Home" was defined, which is why the content in the following chapters will be related to this topic.
For the research, the software Smart Media Creator, developed by Expert Communication Systems, was used as a Component Content Management System (CCMS) to create the content, metadata and facets in. In the course of the project, content was implemented into the CCMS and provided with metadata oriented on the PI-Concept, which builds the basis for this research. Additionally, two Content Delivery Portals were used into which the content and facets were imported to see the output. The two portals are i-views content, which is the Content Delivery Portal developed by the company intelligent views gmbh and Schema Content Delivery Server, short SchemaCDS, developed by Schema gmbh.

Export of content and facets in the Component Content Management System
To export content and facets into the Component Content Management System Smart Media Creator, so-called "books" are packed. To clarify the difference between a book for the export of content and a book for the export of facets in this project, the terms "content book" and "facet book" are used. To export content, a "content book" is created and the modules containing the metadata are referenced. Metadata must also be assigned to the "content book" itself, as to be able to filter for the book later in the Content Delivery Portal. To export facets, a "facet book" is created and metadata is arranged in a structure that should show up later as facets in the CDP.

Implementation of the approaches for deployment of content
For the approach of deploying documents, "content books" were created in the CCMS that included all topics that belong to a certain smart home device and metadata were assigned to that book. On the other hand, for the approach of deploying single topics, a "content book" was created for each topic and all the metadata were assigned to that book that the topic itself contained. On the Figures  1 and 2 the outcome is displayed. The single topic book has a lot more metadata assigned than the document book, because the content of the book can be specifically classified.

Implementation of the approach for access of content
For the access, a "facet book" was created in the CCMS. The structure for these facets was not designed to comply with the PI-Concept, but to fit the user behaviour looking up information and to name the facets self-explanatory.
This decision is based on the consideration that a user is not familiar with the terms and the logic of the PI-Concept. This means, for example, that he would rather search for a facet that is called "Installation" and maybe then filters for a "description" or a "task" about the installation than to search for a facet that is called "Information-intrinsic".

Import of the content and the facets into iviews content
For the research the intelligent views gmbh provided the Graph knowledgebuilder where the ontology was created by a group of students and the functions of the CDP could be configured. The settings made for the CDP in the Graph knowledgebuilder are displayed immediately in the CDP. For more information about the ontology and functions in the Graph knowledgebuilder see: Ontologies and use cases based planning of content delivery.
In the Graph knowledgebuilder it is intended to import content and metadata with the iiRDS format. To do this, the imported metadata must have exactly the same name as the ontology objects in order to automatically link the content with the Knowledge Network.
Because the CCMS that was used in this project couldn't provide the content with iiRDS, the workaround was to create single Chapter-Instances in the i-views Graph knowledgebuilder for each topic and add the plain HTML-Code of the content.
Using this workaround, it was not possible to import the metadata that were already assigned to the content in the CCMS or to import the "facet book". To still get a filter option in the i-views CDP, a relation to the ontology had to be set manually.
Since there was only the opportunity to import the HTML-Code for every single topic manually, there were already single topics created. For the documents the same procedure had to be applied but in the end, the single Chapter-Instances had to be interlaced to get a "document".

Output of the approaches in i-views CDP
Since the transfer of metadata and facets from the CCMS to i-views was not possible due to the different exchange formats, the differences between the approach of deploying a document and single topics cannot be specifically identified. However, the general possibilities of searching in the CDP can be mentioned: In the CDP the user has to type in the search field of the starting page a keyword to get the filter search showing. The results are all topics, that include the keyword in the heading or the actual content and you also have the opportunity to set specific filters. When the user clicks on a topic, it shows the topic and additionally on the left side the structure of the document where it is located.

Import of the content and the facets into SchemaCDS
The content and its metadata from the CCMS was exported in the XML format and transformed into a zip.file that could be imported into SchemaCDS. The facets can be delivered similar by importing a navigation.xml in the facet section of SchemaCDS. For more information about the transformation of data see: Data transformations from CMS to CDP enriched by semantics.

Output of the approach for deploying documents in SchemaCDS
For the approach of deploying documents the "content books" were imported that included all topics about one device and the "facet book". Fig. 4 demonstrates facet filters on the left sidebar. These facets are created by the "facet book" imported before. If the "facet book" included metadata that are not assigned to any "content book", they wouldn't show up in the sidebar. Another finding is, that there is no opportunity to search for metadata that are assigned to the topics contained in the books on this sidebar.
For filtering those specific topics there are two other options. One way is to type in a search word in the search field. Then it suggests all topics and documents that include that search word and also shows if the topic is a main chapter of a book or a lower chapter. Another way is to click on a document and open the filter criteria panel where you can also filter for topics within a document as displayed on the figure.

Output of the approache of deploying single topics in SchemaCDS
For the approach of deploying single topics the "content books" were imported that each included just one topic and the same "facet book" that we used for the approach for deploying documents.
Because every single topic book has assigned the metadata of the topic, all metadata are shown at the start at the left sidebar. It provides further opportunities to find your single topic right at the beginning of the users research without looking for them in whole documents. When the user clicks on a single topic, the filter criteria can also be expanded but since there is no book, there are no results when creating a filter.

Further approach to access single topics
Since the sidebar shows all facets that are assigned to the "content book" as metadata, it is very crowded when using the approach of providing topics. One way to reduce this information overflow, and support the user in his facet search, is to change the structure of the facets. The approach differs from the approach described in chapter 3.3 to restructure the PI-Concept to a small extent and to reformulate the terms in a user-friendly way and concentrates on structuring the facets into several small blocks. The structure is intended to be a list through which the user can click in order to get the desired information. In addition, the SchemaCDS offers the function that only facets that have been assigned to the account as metadata are displayed. This function helps the user to see what further information is available on his topic. An example is shown in Fig. 6. If the user is looking for installation instructions, he can see that there is also a troubleshooting available. The comparison of documents and single topics that are deployed and accessed by a user in a Content Delivery Portal let us assume, that it depends on the use case which approach is the better one. It also showed, that both approaches are not ideal. There is another possibility to provide the user the content in the CDP. This possibility is relatively new and is called microDoc [5].

Definition microDoc
A microDoc [6] is a collection of a few topics that are contextual. For example, if a user wants to know how to install the app for the home energy monitor on his smartphone, he normally wants to know how to register and use the app as well. In a whole document, he could normally find this information in the next chapter. In single topics, he could find this information in topics with similar filter criteria. In a microDoc, he can find this contextual information at first glance.

Creation of microDocs
Because microDocs are relatively new, there is no common approach how to create them until now. Top level would be used, if you could create microDocs automatically based on rules on the metadata that combine some topics with similar metadata. Another efficient approach would be to track the users trace in a CDP to get ETLTC2020 SHS Web of Conferences 77, 0 0 (2020) https://doi.org/10.1051/shsconf /20207703005 30 5 to know which topics he needs, one after the other, and to create microDocs based on this tracking results.

Workaround creation of microDocs in this research
In the research it was not possible to use an automatic option for creating microDocs or to track the user. The first implementation phase was used for microDocs which means that the microDocs were created manually by hand. The microDocs were created by defined rules that can only be applied to the specific domain of the research: the content about smart home devices and specific defined use cases.

Topic types for microDocs
The content that was created and used within this research project consists of different topic types. These are: description, task, troubleshooting and glossary entry. The rules for the microDocs created from the content are affected by these topic types.

Specific rules for microDocs in this research field
1) A microDoc consists of at least 3 topics and at most 7 topics. 2) A microDoc can contain content about different smart home devices (for the use case general information). 3) Normally, a microDoc should only contain content about one specific smart home device. 4) A task (how to install the app) always comes with a description (what is the app) and if available the description of the app's functionality or a superordinated topic that helps to get to know where this information belongs. a) If there is a troubleshooting topic that helps to solve a problem to this specific task, it should be also contained in the microDoc. b) If there is a glossary entry topic for one of the words used in the task, it should be also contained in the microDoc. 5) If several different tasks must be performed to complete a task, they belong to one microDoc. 6) If the user cannot do anything with an instruction without further instructions, then further instructions belong in a microDoc until the result is satisfactory. a) e.g. task_install_the_app, task_setup_of_wifi, task_registration_at_the_app 7) A microDoc only consists of different troubleshooting topics in individual cases, if they should be coherent. Otherwise the user isn't interested in other problems.

Single topics vs. document
We assumed, that people are used to document structures and use the table of content of the document to navigate. Therefore, the document offers a common access to the user. The single topics only offer the facet filter to navigate. Hence, the access to a single topics has to be in a clearly arranged structure. In a further step, the compatibility with different use cases would have to be tested in order to be able to make a statement about which approach is better suited for which applications. The foundation for this research was presented with this work.

microDocs
In our research, the ideal way of using the single topic books is with the described microDocs as an add-on. This would be an approach of combining the two aforementioned methods. MicroDocs do not provide as much information as whole documents do and do not provide too little information without context as single topic books do. The best way to implement microDocs would be by means of automated creation.

Compatibility of different tools
Using different tools can cause problems because of the missing standardization of exchange formats. Even with standardized exchange formats like iiRDS, using different tools can be complicated since the terminology of the metadata has to be exactly the same in both tools.