You are searching for keyword: {{ keyword }}

PODCAST: Using the Principles of Minimalism to Create Better User Support, with Dr. Hans van der Meij

INSTRKTIV Podcast

User support often does not effectively satisfy the propensities of the user. That’s what John Carroll and his colleagues at IBM observed around 1982 and how the minimalist approach to technical documentation began. Minimalism in technical communication is a use and user-centered approach to create better user support. .

In this podcast, I am interviewing Dr. Hans van der Meij, who has been researching the principles of minimalism for almost 30 years. Hans explains the four principles and how they help to reduce training time while increasing learning. 

Listen to the interview below and make sure to subscribe to the INSTRKTIV’S INSANE INSTRUCTIONS SHOW on your favourite podcasting platform. You can find the free transcript of this episode on my website as well. 

If you have a topic or question you’d like me to cover, send me an email here.

SOME TOPICS WE COVERED:

  • Principle 1: Choose an action-oriented approach.
  • Principle 2: Anchor the tool in the task domain.
  • Principle 3: Support error recognition and recovery. 
  • Principle 4: Support reading to do, study and locate.
  • Using YouTube to address user errors
  • Game-based learning, 
  • Hypervideo 
  • Interactive instructions
  • Video instructions

REFERENCES MENTIONED IN THIS EPISODE:

Minimalism

  • Carroll, J.M., & Van der Meij, H. (1998). Ten misconceptions about minimalism. In J.M. Carroll (Ed.), Minimalism beyond the Nurnberg funnel (pp. 55 - 90). Cambridge, Mass: MIT Press.
  • Van der Meij, H. & Carroll, J.M. (1998). Principles and heuristics for designing minimalist instruction. In J.M. Carroll (Ed.), Minimalism beyond the Nurnberg funnel (pp. 19 -53). Cambridge, Mass: MIT Press.

Four Components Model 

  • Van der Meij, H., Blijleven, P. & Jansen, L. (2003). What makes up a procedure? In M.J. Albers & B. Mazur (Eds.), Content & Complexity. Information design in technical communication (pp. 129-186). Mahwah, NJ: Erlbaum.
  • Van der Meij, H., & Gellevij, M.R.M. (2004). The four components of a procedure. IEEE Transactions on Professional Communication, 47(1), 5-14 

Video design

  • Brar, J. & van der Meij, H. (2017). Complex software training: Harnessing and optimizing video instruction. Computers in Human Behavior, 70, 475-485.
  • Van der Meij, H. (2017). Reviews in instructional video. Computers & Education, 114, 164-174.
  • Van der Meij, H., & Van der Meij, J. (2013). Eight guidelines for the design of instructional videos for software training. Technical Communication, 60(3), 205-228.

  • Hans van der Meij can be reached at H.vanderMeijatutwente.nl

Read the Full Podcast Transcript Below:

Ferry V: Hi there, and welcome to this podcast. In this podcast, we're going to talk about the principles of minimalism in technical communication. Our guest for today is Dr. Hans van der Meij who is widely considered as the expert in the field of minimalism. Dr. Hans van der Meij is senior researcher and lecturer at the Faculty of Behavioral, Management and Social Sciences of the University of Twente in the Netherlands. Hans has over 80 publications on Researchgate.net, and he is praised within the industry for his work. Hans can tell us everything about e-learning, instructional design, video, game-based learning, and minimalism. Hans, welcome.

Hans: Thank you.

Ferry V: To start, Hans, how did you get involved in technical communication, and specifically in minimalism?

Hans: I started my research in education where I was involved in studying how students study for themselves. After studying and questioning, which is an important predictor of self-study, I became interested in software instructions. The first and major publication that I read about, it was Minimalist Principles from John Carroll. That immediately took my interest, and I never left it.

Ferry V: Why did it take your interest?

Hans: It disagreed with a lot of ideas that were prevalent at that time, which is you have to give lengthy explanations, you do not support errors, because that is not the right behavior that you should support. Carroll's work was carefully couched in observations, and was actually looking into the fact that if you want to help people, you have to know what they want, what they need, and then you can help them.

Ferry V: What year did he conduct the research?

Hans: I'm not precisely sure, but I started my research in 1990, together with a PhD student of me at that time Jack Molisani What we did is we didn't get Carrol’s book yet, The Nurnberg Funnel. So, we started with the original manual, the first minimal manual that he produced, and we analyzed that with reverse engineering, and then we came up with our principles for minimalism. After two years of work with it, we met, Carroll and I, and we agreed largely on the principles. That's how we got to collaborate.

Ferry V: Do I understand it correctly that you came up with the principles of minimalism?

Hans: No. Jack had, I think, six or eight principles, but these were too vague for our perceptions, for our designs. We made them much more detailed. Making them more detailed also involved making bigger trunks. I think Jack distinguished six or eight major principles, we distinguished four, and within the four, we had sub principles. Basically, it's a manner of arrangement.

Ferry V: What I understood is that John Carroll, he conducted his research within IBM, is that correct?

Hans: Yes, he worked with IBM, yes.

Ferry V: It's not only theory, but it’s also very well-researched as well.

Hans: Jack did not do a lot of empirical studies with a lot of people, but he analyzed the people he studied in a natural environment where they had a natural interaction with the interface and with the support. He conducted more of a qualitative study. That was basically a very good starting point for designing theory, because you tend to start experimenting only when you have a theory. Jack didn't have a theory. He started with explorations to devise a theory. Our work actually elaborated on that, and then could work with actually what we considered to be the general theory of minimalism, to devise a number of experiments with more participants, and so on and so forth.

Ferry V: I will talk about those principles later. For how many years have you been working on the principles of minimalism now?

Hans: We started in 1990, that's about 29 years, 30 years now.

Ferry V: Is minimalism the only topic that you're researching, or do you research other fields as well related to instructional design, for example?

Hans: Game-based learning, because that's also a self-instructional idea. And video instructions, but basically the core is always minimalism.

Ferry V: Minimalism is also part of game-based learning and of video instructions?

Hans: Yes. The key tenet of minimalism is that you support people in their actions.

Ferry V: If you could give a description of minimalism in just one sentence, what would minimalism be, how would you describe minimalism?

Hans: Use and user-centered approach.

Ferry V: You're saying use and user-centered approach? What is the difference?

Hans: Use is the approach that you can have indicating what you give for people to support their task performances, to support their actions. User-centeredness means that you have to understand your audience's needs, capacities, contexts to adapt that use to their needs and perceptions and desires and so on and so forth. What you typically see in the literature is that the propensities of the users are very hard to capture and sometimes are ignored in the use-centered approach. Minimalism always considers the user in combination with use.

Ferry V: Can you consider it as a design philosophy?

Hans: Yes.

Ferry V: It is a design philosophy?

Hans: Yes.

Ferry V: Period. When you apply the principles of minimalism, or when you apply minimalism? What would be the benefits of applying minimalism?

Hans: You get people on task much faster, much better, and with less support intervening. In one of my publications, I say that the rule is one-third. People take one-third of the time needed to learn the things that they otherwise learn with other documentation. The documentation is one-third smaller, less thick, and is one-third more effective than other documentation.

Ferry V: This applies to documentation, but also to game-based learning and video instructions?

Hans: No, this is purely from the minimalist perspective. In video-based instructions, it's very difficult to have a comparison in conditions like in the original software-paper industry. That rule of one-third doesn't apply there.

Ferry V: You already mentioned the principles of minimalism. Can you tell us in short what those principles are?

Hans: The four main ones are; first is you want to select the use-centered approach. People come to documentation because they want to perform a task with software. Obviously, the software industry tries to sell the software as an intuitive interface for which you do not need support, but our research indicates that people always need support of some kind. That support is to perform the task. That's the user-centeredness. It is the core, first and main idea of minimalism. The main principle.

The second principle is that when you teach a task for software, it has to have meaning for the person's work. What you can see is some approaches teach software functionality, and minimalism always asks people to teach people software functionality for their job. For a teacher, you teach different things for word than for a researcher, because they have different needs for different functionalities of word, which is what we call task-orientedness of minimalism. That's the second principle.

Ferry V: Before we go to the third principle, you're mentioning software a few times. Do you mean that the principles of minimalism can only apply to software documentation?

Hans: No. We use the principles also for training, for educational tasks in Math, and all other kinds of tasks. But the origin, the source is software training.

Ferry V: Meaning that it's better, or it has more effect when you apply it to software documentation, or is the effect similar?

Hans: There can be the same effects, but as a researcher, I always hedge myself. It has been studied extensively for software training, which is procedural skills training. For conceptual skills training, you can apply minimalism, but you may have to put in some conceptual or more conceptual information than you would for software training. So there are modifications that you need to take into consideration when you're looking at a different domain.

Ferry V: Can you tell us what the third principle is?

Hans: That's my favorite. Address error. Support people in handling error. That means you want to prevent error whenever possible. You want to help the people to manage error when they occur. Meaning, you have to support detection, you have to support correction, and these are the two minimal aspects of error management. Probably, you can support some problem diagnosis in that information, which is one of the special moments in minimalism where you give more than what people actually need.

Ferry V: Do you have an example of that?

Hans: If you have made a mistake with software, the first thing you need to do is to detect that you have made a mistake, or that the software did something wrong.

Ferry V: For example, if you don't see happening “this”, then you might have made a mistake?

Hans: Yes. If you want to present a word in bold, and it appears in italics, you must infer that something went wrong. That is, that you start correcting your mistakes. So you press control Z to remove the move, and then it's plain text again, and then you select the bold icon, and then it's in bold, and then you're correct. That is detection and correction. Right?

Ferry V: Yes.

Hans: The step in between is diagnosis. The diagnosis is, I see that my word is presented in italics. What did I do wrong? Then you look at the three signals in your word, the three icons on your word. Oh, I press italics, which is next to bold. I may have made a mistake, and just clicking it on just the wrong icon, and that's a diagnostic action. That helps you understand that you can have different aspects of presenting words in Word, like in bold, italics, strikethrough, and that's what you get from diagnosis: you get some feeling of how some software is organized in sections and within sections into separate parts and so on.

Ferry V: Do I understand it correctly that this error recognition information and error solving information is provided within the instructions? So not in a separate chapter, for example, a troubleshooting chapter?

Hans: That's correct.

Ferry V: That's how minimalism really distinguishes itself, or that's like really a characteristic of minimalism?

Hans: Yes. There are nowadays even in general education, more approaches that take into consideration the fact that people do make mistakes, which is not a novel insight. It's an insight that people just don't want to get. What we have always advocated in minimalism is that you give error information on the spot, meaning where it occurs. If it's later on the page, people will look for it hopefully on that page, but people typically don't look too much beyond pages or beyond sections. If you put in your error information at a separate section, it might still be useful, but not as useful as just in time presentation.

Ferry V: Would you say that a troubleshooting chapter or section isn't necessary anymore when you provide--?

Hans: No, you don't hear me say that. I do think that's important because providing error information on the spot is very difficult and very time-consuming. So, I do see the value of separate sections, but then you have two key problems. One is that people need easy access to the error information, which is an important aspect of good indexing, or frequently asked questions, or whatever you call it. The second is you have to explain very carefully the context within which the error may occur.

That is what index just called the extension problem, which is if you say bold is wrong or italics is wrong, you need bold, then people don't understand that it's applicable to them, or in their situation, or not. During a task execution, it's self-evident that something is wrong or right, and in a separate chapter, but it's not. So you need to explain something more about the context of the problem, so that people understand, "Oh, yes, I'm in this situation, so this help is important for me." Is that clear?

Ferry V: That's totally clear, Hans. But I was thinking for a technical writer, it can be quite difficult to come up with all the kinds of errors that can occur when you go through a sequence of instructions.

Hans: The crux of the matter is that you have to address the most important ones and give support for that, and address the lesser important ones with more conceptual information though, so that people have to self-rely and self-correct themselves.

Ferry V: Can you explain the concept of conceptual information a bit further?

Hans: Let's keep with the example of the word that you present in a particular format. If you understand Word’s organization, you understand, and you can see that in Word bold, italics, strikethrough, and there's one more- are organized in a section for changing the font of your text. If you understand that you're addressing a problem with the font, people immediately look at the right section and understand, okay, so now I need to understand which font I use.

Ferry V: Clear.

Hans: That's conceptual information. If you look at the organization of good software, you always see software, even with large sets of menu options, they're organized conceptually in a meaningful way, and not alphabetically most of the time. So alphabetic organization is wonderful if you have no knowledge, and conceptual is wonderful if you have conceptual knowledge. The conceptual knowledge will bring you easily to where you want to be in an interface.

Ferry V: Anything else you want to add to this third principle? Or do you want to discuss the fourth principle?

Hans: No, the third principle is the most underestimated, and probably the most important one in the near future. If I'm looking at a lot of analysis that we're conducting on YouTube videos, you see a lot of popular videos addressing user errors. I think this principle will become more and more important as it's being accepted that you make mistakes when you're working with software, and there is help. Help available in the form of video is probably the most effective help around nowadays.

Ferry V: Do you mean because of the fact that there are so many YouTube videos discussing errors, that this automatically means that there's too little error support given in existing documentation? So people start making their own?

Hans: We've conducted two inventory studies on the presence of error information and user support and the situation. The main outcome from these inventories is that there is too little support for error handling, error management by the user. This is one important reason why YouTube videos are so popular. Another reason is that people find it difficult to read when they're dealing with a problem. YouTube videos are very easy to handle because they're visualized mainly. So, you get actually better support easily, more easily acceptable, accessible, and more feasible.

Ferry V: Those YouTube videos are mostly an enhancement of the written documentation.

Hans: A necessary complement, if not, sometimes the most important part that is submitted.

Ferry V: What would you suggest for technical writers? How would you integrate those YouTube videos? Or how would you integrate video with written documentation?

Hans: I would use the company website to produce a number of videos on prevalent problems.

Ferry V: Another benefit of using video, as I understood, is that it works more efficiently and more effectively. Is that correct?

Hans: Yes. We've conducted about 10 years of study on, or maybe 15 years of study, on paper documentation. After these, this time, I started my first investigation on videos. I did a comparison study, comparing paper versus video. Even though we use the paper version that had been tested for 15 years and improved over that period, the first video that we created, and of course, it was iterated a number of times, was so much better that I never look back, and always, from that period on, look only at improving the instructional video.

Ferry V: About the fourth principle, Hans, if I remember it correctly, it has to do with supporting various users?

Hans: Yes, it concerns the problem of gaining easy access to your documentation.

Ferry V: What do you mean with easy access to documentation?

Hans: It's true for paper as well as for video, and perhaps for video even more. The first obstacle to finding information is that you have to have the proper terms to find the proper video. That's the first obstacle to finding videos on your problem. The second obstacle is within the video, you need to find the proper section. That's a typical issue that you have with video and with paper.

You have to find the right place, and in the right place, you have to find the right information. That is something some people want to look at a video from start to finish. Some people want to jump in at the right moment where their issue is discussed.

Ferry V: Are you talking about really lengthy videos now, or does this apply to short videos as well?

Hans: For short videos it is just as applicable.

Ferry V: As far as I know, when you create a video instruction, it's always best to create really short instruction videos that discuss one topic at a time, so give a solution for only one user's answer.

Hans: Yes, but then what is the label that you give to that video? Sometimes the label that you give to your video may be a command from software, is not the thing that people are looking for, or maybe looking for the wrong way. One of the key things that we do with improving access for video is have a table of contents so that people can see what the concept is about. The first part of the video is always an explanation of the goal. Then people can decide quickly, "Oh, this is for me. This is what I'm looking for, or this is not what I'm looking for." Maybe some of the other lengthy or shorter videos are appropriate for my issue.

Ferry V: Meaning that you start with some kind of a table of contents, which also implies that one video can contain several sections, or several sub-sections discussing more than one topic. Is that correct?

Hans: That's correct. Basically, what we do in our research mainly is we have a chapter, and the chapter has some sub-chapters, and within sub-chapters, you have sub-sections, and that's the same with video.

Ferry V: This fourth principle mainly applies to video, or can you best explain it by this example?

Hans: We actually use the paper metaphor to better explain the problem for software with video training, but both are applicable.

Ferry V: What I read as well about the fourth principle is that I think it's called heuristic belief or heuristic principle. The first principle, or heuristic belief that you discuss on your website is that you have to be brief, and you shouldn't spell out everything. That applies to text?

Hans: That applies to video as well. Basically, it's something that people associate with minimalism. For me, and I'm sure for Caroll too, it's a derivative property of selecting an approach that is use and user-centered. The brevity is the result of being use and user-centered.

Ferry V: That absolutely makes sense. Let's make one sidestep because last May, the new 82079 Standard for Instructions for Use was published, or actually I have to say Information for Use. I think one of the main advantages, or actually one of the main breakthroughs, in my opinion, is that minimalism is being mentioned in this new standard. Are you aware of it?

Hans: I've heard it, and I've seen it.

Ferry V: You've seen it, right. I do have the standard here, and there is a definition given for minimalism. I would like to read that out loud. It says, "Minimalism is a principle that information for use includes critical information and the least amount of other information needed to be complete." Talking to you now, it sounds like maybe a bit like too short, or incomplete description.

Hans: It's incomplete, it's fake, and it's not well-informed.

Ferry V: Can you explain that?

Hans: Completeness is not an issue that is important. You don't see any principle that describes that you have to be complete. Actually, there is one set principle which says that you can be incomplete if you capitalize on user inferences. Now, obviously, don't go into the joke of writing incomplete instructions when people are flying a plane, and they need a checklist to check whether they're doing it correctly because that's a silly example. Incompleteness is an important characteristic of minimalism, in that if you want to be complete, what does completeness mean?

Does it mean that you have to say, “Open Word”, or does it mean that you have to say, “To open Word, you must press with your finger the shift key”. There is a distinction between what is complete and what your user already knows. That's the distinction where you get into user- centeredness. You have to assume that users can do certain things in order to not repeat information that they already know. That's something which covers completeness in a different way, looks at it as use and user-centered approach.

Ferry V: That sounds to me like really one of the difficulties a technical writer might face deciding what is absolutely necessary and what is obsolete or less relevant, so to say.

Hans: Isn't that why our job is a smart job?

Ferry V: That's correct, Hans. [laughs]

Hans: You have to think carefully about whether you're addressing idiots or professionals. Typically, we're writing for professionals, whether they're novices or experts in their fields, but you don't treat them like idiots. You treat them in their respect as to what knowledge you can assume that they have, and that's where you depart from.

Ferry V: If you were asked to redefine this definition of minimalism, which you mentioned the use-centered and user-centered approach here, or how would you--?

Hans: I would mention the error management principles too because that is something which is actually a principle that is counter-intuitive for brevity, because if you add information about problems that people may not face, you're adding redundant or additional information that they might want to skip. Then there is the principle of easy access, and error information in our documentation is always easily skipped.

You capitalize on what we call information mapping processing which is all key information is presented in its own place in its own way. Once people get the hang of how something is organized as this information mapping, people will quickly know where to find what information, and then error information is skipped easily and is found easily when needed.

Ferry V: I would like to quote another part in the 82079 Standard about minimalism. As far as I can see that error recognition or the error support problem solving isn't discussed at all in the standard. Maybe we can emphasize that a bit more. Here's a piece of text from the 82079:  

”Minimalism shall be applied. Minimalism is an approach to information for use that includes critical information, and the least amount of other information needed to be complete. Critical information includes the safe use of the product, the security of the information created with the product, or the privacy of the information created or stored with the products.” 

What do you think of that?

Hans: In terms of privacy, the guideline is for a very broad audience. My research is more restricted to a particular set of software tasks. I can't address that. 

What I'm missing is the component of error information. You want to safeguard, which is to prevent certain error, but you want to help people when they make a mistake. That's something that I would add. By the way, research indicates that one-third of the time on the task of most people is spent on dealing with mistakes. If you leave out that component, you're missing one-third of the time on task of people.

Ferry V: Let's talk a bit more about video instructions, because video is really a hot topic also in industry, of course. What I noticed there are more and more companies wanting video instructions as an enhancement of written documentation. To mention the 82079 Standard one time more is what I think is an advantage or an improvement of the new standard, is that where the former standard said that it's still mandatory actually to deliver a written manual with the product, the new standard says that it depends on your target audience. So it depends on the needs of your target audience, whether you decide to provide a written manual or to create, for example, a digital version of your documentation, like a video or an online help environment. This makes it much more interesting to rethink the user instructions for many companies.

Meaning that more and more companies are exploring the possibilities for creating video instructions. I did a bit of research. I read some of your papers. In one of your papers, you're mentioning the term hypervideo. Can you tell me what hypervideo is?

Hans: Basically, what you have on paper is when you are looking at a particular item, like the bold item, and you don't know what it means. If your cursor hovers over it for a few seconds, it will pop out a glossary. Meaning this item presents every word in bold. In hypervideo, you have the same optionality. So you have one of the options of hypervideo is that you can put in a link to a particular object on the video, and people can look up the meaning of that link. You have some explanatory information when you need it. That's the principle of just-in-time presentation again.

Ferry V: I'm familiar with the term context-sensitive help. Is that something similar?

Hans: That's quite similar. That's another aspect of hypervideo which is there is a clickable link to other information. Another aspect of hypervideo is that you may have a community of communicating people, so sometimes you have people who are connected to a community where they can look up the information, like the frequently asked questions for them, constantly updated.

Hypervideo has opportunities for sticky notes, like a note that you make yourself with a video, like ‘don't do this because you're missing something out’. You can insert your own links in your own video, so you create your own documentation, which is very helpful for troubleshooting. You can create information links that address certain background information, and you can have information in a hypervideo that leads you to a community with which you can communicate. Actually, it is like a helpdesk which is constantly available.

Ferry V: Is there a way to design a hypervideo?

Hans: Hypervideo requires different software, and that software is becoming more and more common, but understanding the use of hypervideo is more difficult for any user, and for the designer to design is also more complex. What you now see is applications in mobiles which are tending towards more hypervideo than video, and these are in the more advanced stages of developing user support which is sensitive to the user's actions. That's also an aspect of hypervideo. If people click on a particular part of the video, they are directed to a different part of explanation. That's also an aspect of hypervideo.

Ferry V: When I hear you talking about hypervideo and all the other examples, principles, theory you're giving, I desperately want to see some examples. Are there any good websites where you can see examples of hypervideo, how to apply hypervideo, or correct examples of hypervideo? Some examples of the principles of minimalism which brings it a bit more alive?

Hans: I have a number of papers which describe the theories and the application and empirical research on video and on hypervideo.

Ferry V: Are those papers freely accessible?

Hans: People can always mail me, then I can mail them one or a few of these papers. That's not an issue. Some of them are open access.

Ferry V: You maintain your own website where you write about minimalism, or where you provide a lot of information about minimalism and the principles of minimalism.

Hans: That has been produced a number of years ago, and I don't update it. I'm updating it with my publications, but not on the website. I have a LinkedIn website where I publish some of the videos that we produce. Recently, an article appeared, and in there we have included the videos that we were using in the study for people to study these videos, and that's becoming more common in education and in research also, that people provide the source material, so that you can see what's being done in the study with the materials present.

Ferry V: So you're inviting people to connect with you through LinkedIn?

Hans: Yes, or through email.

Ferry V: In the beginning, you mentioned The Nurnberg Funnel by John Carroll, which is quite a read. It's theoretical, it contains quite some pages. Are there any other good reads?

Hans: That's the first book. The second book, Minimalism Beyond The Nurnberg Funnel, is actually the book that you should read for, that you-- Key chapters on principles and misapplications of the principles. So there are chapters two and three, if I'm correct, which are written by Jack and myself, which gives a condensed view on minimalism.

Ferry V: Those two books will provide someone with enough information about minimalism?

Hans: Yes. Just the second book will provide you with all the information that you need.

Ferry V: In combination with your papers, or are your papers an enhancement of the principles?

Hans: There's one thing that I've worked on for a number of years that is an extension that is not in the book, and which is called the Four Components Model. Basically, what it states is that if you look at a particular component of a manual or an instruction, then typically, task instructions have four key components, which is goal information, information about prerequisites, information about action and software reactions, and troubleshooting or error information.

These are four components that you see represented in tasked instructions for 95% of all task instructions. I analyzed about 120 manuals to come up with this model. That's a more detailed view for writing instructions about task instructions which are a sub part of any minimalist, or any software documentation.

Ferry V: Additional information, or in-depth information about this is given in your articles?

Hans: Yes.

Ferry V: What you mentioned as well in your articles, you talk a lot about interactivity, and then mainly when it comes to video instructions. With video instructions, you can make the instructions much more interactive than you can do with written documentation. Can you tell how this works and how interactivity is a better way or can stimulate the use of a product?

Hans: There are two sides to the coin. One is if it's a regular video, you can look and sleep, because the video will show you a model of the actions and you can fall asleep and drink beer and get coffee and relax and whatever. After, at the end of the video, you know nothing. In paper, when they say, “Press X,” if you don't press X, nothing happens. So paper is in essence more activating than video. That's the interactivity principle against video, but what you can do in video is put in particular key moments where you have a pause so that people can think because you don't have always the need to perform an action to understand that this is the action that you need to perform.

Interactivity in instructional video is best explained with hypervideo. I'm taking one example that I solved 10 years which was one of the first versions of hypervideo for the national telephone company. I was analyzing their documentation for them, and they sent me documentation, and it was for a modem. I was looking at the video, and the video posed the question, "Which modem do you have? Modem one or two?" I was waiting for the video to explain, but the video invited me to press the selection button for a key modem, after which a new part for that modem appear. That's a key part of interactivity that you can not achieve on paper, and you can not achieve in a regular, linear video.

That's where interactivity comes in. If you have a lot of options, interactivity is wonderful because it leads you through its trajectory of selections that you make as a user to indicate ‘this is my situation, this is my situation, now this is, oh…’, and then you are getting to where your problem is. That's where interactivity is a key feature that helps people understand that they are getting to their problem. It's like the menu options that you have for getting to a company where you have to select, select one if you want to have that, select two if you want to have-- Well, they're a pain in the neck, but if done well, they are very efficient in getting you to where you want to be.

Ferry V: Is that the same kind of interactivity that is involved in serious gaming?

Hans: I think yes.

Ferry V: Because you're doing a research on serious gaming as well?

Hans: Yes.

Ferry V: Is serious gaming something of that could be of importance to technical writers in the future?

Hans: I know some companies which teach people certain procedures through serious games because it trains them particular physical activities that are necessary for the job. For surgeons training with games, shooting games, is very effective because it trains their fine motor skills.

Ferry V: Is it more effective than video instructions?

Hans: Yes. If you need to train your physical skills, and it's what you need to manipulate your finger at them and your attitudes there and react quickly to, then games are very effective.

Ferry V: It serves a different purpose, so it's really-- In this case, the example you mentioned, you would say serious gaming is being used for training physical skills, and you would say video instructions can be used for cognitive skills, for example.

Hans: Yes. You don't have to automate those activities. You just have to be able to perform them, and the physical actions needed to perform there are not complex. Complex, you need to practice.

Ferry V: We’ve discussed minimalism, the principles of minimalism, I think I already called it a breakthrough, and maybe it's not defined correctly in the 82079 Standard, but it is being mentioned in this new standard for user instructions, which is an international standard, so I think it's really a great breakthrough.

Hans: I agree.

Ferry V: Meaning that I think it will be widely adopted by the industry, if it has not already been done over the last few years, but it will be much more widely adopted. We've talked about video instructions, we've talked a little bit about serious gaming. I think also when it comes to video instructions and serious gaming, there has been done a lot of research. How do you predict the future? Do you think that from this research that it will evolve into commercial products? Do you think that businesses will adapt the research that you and your colleagues, other people worldwide are conducted?

Hans: What I hope is that people make better products for their users, meaning including support for their users. What I see on YouTube is that there are a lot of good video designers, but they're not very many, very good video designs if you look at it very closely. What my wish and hope is that my research contributes to helping people that help themselves.

Ferry V: You're not talking about video games here, but about serious games, so to say.

Hans: Serious games, instructional video, instructional tutorials.

Ferry V: Let's say that I'm a technical writer, or I'm an entrepreneur or a marketing manager, and I would like to start implementing maybe the principles of minimalism. And I think, hey this might be really useful for my users. We need better documentation, or maybe we need video instructions to improve the learning of a product, or maybe is serious gaming, an option, what would you recommend to start with?

Hans: That they start out with what's the context and the proficiency of the user, so if your user can use paper, video or mobile, what technology is available in a particular place. Then just read some literature and try it out.

Ferry V: You have to know if your user has access to the internet, for example, 24/7, or at the moment that he needs the information?

Hans: That's one of the disadvantages of interactive video. You need probably the internet, but if it is canned, you don't need the internet. You have to consider all these situations whether or not it's useful or meaningful to have an application. For instance, my students do a lot of work on building instructional video for cooking. Cooking instructions are, of course, interesting to make. But if you're concerned with getting your desk dirty, you're always considering that you don't do that with a PC. Maybe a mobile, maybe a leaflet with the context of use is probably one of the most important and most critical decisions to make first.

It's like I was reminded of the book of James Hartley, he says the most important decision that you have to make when you're designing something on paper is the size of paper. That's true for whatever instructions you make is what is the key medium and place or room that you have available for instructing people. If you have a mobile, you do things differently than when you have a PC or you have a piece of paper. Those are the most important starting points for your design, and then you can look at what you need to teach, and what your audience can absorb or needs to absorb, and then you can mix the two.

Ferry V: That's really, really useful information, Hans. I think we've discussed many, many, many things about minimalism, video, a bit of serious gaming, topics that are hugely important within the field of technical communication, and I think will become even more and more important. Hans, thank you for this interview. This is really useful for all technical writers that want to apply the principles of minimalism and write better documentation.

Hans: You're welcome.

Ferry V: I would like to thank the thousands of listeners that follow my show, and I'd like you to listen to the show next week, and all weeks that will follow us well. What have you got to lose? You are on your way to creating happier and safe for users. And I invite you to email me with your queries, or just to say hi, or maybe you want to be in the show. So continue listening, or you won’t be safe anymore. Only joking of course.

ferry vermeulen

Ferry Vermeulen

Founder of INSTRKTIV and keen to help users become experts in the use of a product, and thus to contribute to a positive user experience. Eager to help organisations to reduce their product liability. Just loves cooking, travel, and music--especially electronic. You can also find him on:
Profile PageLinkedin, Instagram and Twitter!


You may also be interested in

  • 19 April 2024

    The Machinery Directive's Guide Allows Digital User Instructions

    Today's update to the Guide to the Application of the Machinery Directive introduces a major development: digital user instructions are now allowed, aligning with provisions from the new machinery regulation....

    READ MORE

  • 19 April 2024

    The new machinery regulation and the implications for user manuals

    This article gives an overview of all the changes in the new machinery regulation compared to the machinery directive in relation to the user instructions and goes into a bit more detail about digital manuals....

    READ MORE
https://instrktiv.com/en/blog/podcast/minimalism/
instrktiv.com
CC-MAIN-2024-33
88284
application/http; msgtype=response
sha1:JFAJA6Q6FIARRZGCR5VRJ5XF4BFYZIOS
<urn:uuid:92ce3b14-a438-42e9-b9ae-ed7090a48de9>
2024-08-03T11:02:49Z
104.21.23.140
text/html
sha1:4TRYB6UPGW5MWDF6UE3K7CKJNQIYBCYG
<urn:uuid:4a251e38-56ba-4848-a130-aa20fc04a8ea>
https://instrktiv.com/en/blog/podcast/minimalism/
response
<urn:uuid:0d783122-1769-44ce-a968-a428511aa7ef>
isPartOf: CC-MAIN-2024-33
publisher: Common Crawl
description: Wide crawl of the web for August 2024
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-134
software: Apache Nutch 1.20 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.5-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/