The clip-thought generation has not just grown up, they have entered the workforce. Team leads point out that the young have a hard time understanding long texts in technical documentation. We cannot ignore this factor — we will have more and more of these employees. This is why we need to find ways to ensure they can work comfortably. It might involve revising some technical documentation standards.

On the other hand, it's our chance to consider whether the existing system of conveying technical information through text is good enough. It may well be that the clip-thought understanding and cognition of modern people is not a "global innovation" as such, but a return to the natural processes of the human psyche. It's only logical to ask, therefore, if using pre-Gutenberg practices could prove useful and effective?

Methods of Recording Information

Over the 7,000-year history preceding the IT revolution, humanity created two key methods of recording information: characters (pictographs) and the alphabet. Each of these methods has its own long history, as well as relative strengths and weaknesses.

It would be impossible to conclude that a certain method is superior in general — any writing system simultaneously resolves a few issues. The alphabet is better suited for a vivid description of the sun sinking into the sea or for creating a heart-breaking poem about love. Characters, on the other hand, are good for instantaneous understanding of the main idea and for fast learning. Try to convey the following information through text:

When we need to convey information rapidly and precisely, without emotional context, the imperfection of the alphabet forces us to create and use graphical systems of data communication:

mathematical and chemical formulas;
UML diagrams;
traffic signs;
smileys and emojis;
software and app icons;
hydraulic, pneumatic, electrical and other schematics.

It is especially worth noting the State Unified Shorthand System used in the USSR. In some European countries, it was taught in educational institutions. Musical notation is known to and used by dozens, if not hundreds of millions of people. Therefore, using graphical systems of data communication is a usual practice for the speakers of alphabetic languages:

Most people easily perceive and understand assembly and operation manuals in the following format:

During my time at the university, we were shown a historical antiquity — an assembly chart for the T-34 tank — at a Production Engineering class. It was entirely made up of pictures. In the context of economic mobilisation, factories had to employ poorly-educated people. Creating comics-like manuals was the only way to quickly communicate all the necessary information to them.

What about reading then? When we read actively, we employ a different sequence of perceiving textual data. Rather than following the "letter → sound → word → concept" sequence, we perceive the graphical representation of the word and immediately associate it with the concept (each word we know is a pictograph to us).

Technical Documentation: Text or Pictograph?

If we think of technical documentation as a particular type of writing — dry, with no colour or emotion — the alphabet would be inferior to characters for the following reasons:

we would need to have professionals with both philological and technical education;
reading would slow down information perception;
text would occupy a larger part of the screen;
input of a large number of letters would slow down document creation;
potential ambiguities or errors;
random coining of technical terms;
complexities in deciphering the meaning of IT system texts;
complex systems of automated documentation creation.

Using characters for Japanese, Chinese or Korean documentation would, in its turn, be somewhat inferior to the alphabet:

symbols that are in no way related to IT are used to coin terms and concepts;
lack of consistency.

It seems logical that we need a new way to produce technical documentation that would be simple for anyone to understand, regardless of their native language, and unambiguous in its terminology.

The Need for IT-Esperanto

Comparing different types of writing systems, we could conclude that characters are generally more preferable for creating technical documentation. However, the archaic nature of the characters and the inability to use modern technology makes us wonder whether a new writing system must be created. For example, using colour to convey a property of a factor. A sort of a "graphical IT-Esperanto" needs to emerge. A conceptographic writing system must comply with the following requirements:

formation of basic graphic symbols based on an analysis of technical documentation— basic, derivative and synthetic concepts are to be determined;
formation of a set of graphic symbols as a system allowing for constructing complex conceptograms. Knowing the meaning of basic conceptograms alone, the user must be able to understand the meaning of more complex ones;
ability to add text when needed;
well-known images are to be used as basic symbols.

The suggested idea is not a replica of the one implemented by the U. S. Department of Transportation that ordered the now-familiar pictographs for transport passenger orientation and similar examples. This must be a system allowing for conceptograms that can convey the meaning of any complex sentence from technical documentation with one or two symbols.

Here's a somewhat crude example of building conceptograms:

Advantages and Disadvantages Related to Using Conceptograms

Using conceptographic writing principles would yield the following advantages:

drastic reduction of the technical documentation preparation time with the help of special apps. For example, you could try to describe the following objects using words:

It would take less than a minute in a special editor:

relaxation in the requirements for documentation developers. employees with no linguistic training will be able to produce it;
drastic cost reduction for the translation of technical documentation. You would only need to translate text descriptions of the basic conceptograms. Then, specialists will "read" the pictographs;
translation into rare languages. In fact, you wouldn't even need translation since elements of conceptograms will have the same meanings in all languages meaning you will be able to avoid discrepancies;
drastic reduction in error probability:

no need to conjugate numbers, names, genders and cases;

no need to use "textual wiring" — link verbs, prepositions, modal verbs, auxiliary parts of speech, conjunctions and particles.

ability of IT systems to understand the main idea of the documentation — in the documentation file, the conceptogram will be represented by code (there needs to be a conceptogram codification system);
ability to create documentation using voice recognition. This format of recording information and the constraints imposed on the meaning will drastically decrease voice recognition complexity.

This innovation has complexities of its own:

we would need to get used to the new type of documentation;
we would need hundreds of thousands or even millions of specialists who could read conceptographic writing.

However, the practices of emergence and introduction of new programming languages (which are in fact sets of pictograms) prove that mass training of programmers would not entail any global problems. Any child from China can learn 2,000 characters in 18 months while the conceptographic writing system will have a significantly smaller number of separate graphical objects.

Gradual implementation (from one-time use of simple conceptograms to consistent increase of their number and complexity) will allow us to make the use of conceptograms a habit. The technical documentation of certain applications already uses pictograms to describe user actions.

Icons are a vivid example:

a modern user knows the functionality an icon denotes and does not have to think about its meaning. All this inspires cautious optimism regarding success of the consistent and systemic introduction of conceptograms into technical documentation.

The ability to convey information graphically must be interesting to not only developers, but also lawyers, for example. Legal documentation is also full of "dry" information conveyed through standard or conventional phrases. This is why using conceptograms would also accelerate document processing.

It would be really interesting to ask the IT community for their opinion regarding introduction of a new way to write technical documentation. How convenient would it be? Would it resolve the problems described above?

Conceptogram as a method to create more effective technical documentation