Writing Software Documentation, Chapter 5 – Nelson & Haupt

Barker’s Chapter 5 informs us on the importance of the research phase of analyzing documentation users. Analyzing user research should be done with interviews, questionnaires, and surveys, either choosing to do one of the research types or all three. When analyzing the users it is best to focus on the eight areas of; tasks and activities the user will perform, user’s informational needs, users work motivations, level of the user’s computer experience, knowledge of the program’s subject matter, community, learning preference, and the user’s usage patterns. Try to immerse yourself into the workplace world of your users, list as many types or groups of the users as you can. Which users would most probably use the program and which users can be interview most easily.

Keep in mind the importance of sensitivity to the culture the users comes from and their nations or workplaces. When analyzing a user it is important to know that you may need to get authorization to interview people in the workplace. Pay particulate attention to information related tasks like communicating, storing, and sharing.

Barker points out to analyze the users before and after tasks by noticing small facts about the users, their attitudes and habits. Look for items such as notes stuck to bulletin boards, diaries of skills, or third-party computer manuals that the users employ in their daily use of existing technology.


In some instances a mock-up of the user or a model may need to used to perform the research. Barker suggests the use of library occupational guides, placement services that college or university use, or even job descriptions found in publications put out by companies.

Remember that deadlines and timeliness of reports often are what makes documentation useable or not. To help out in the research the use of a flow diagram may help to better clarify how the users' tasks are being accomplished.

When planning to do research Barkers suggests following some general steps.

1. Research into the user’s job and the programs.


2. Review the software..


3. Establish the scope, how many, with whom, etc..


4. Make a list of interview questions..


5. Get permission..


6. Set a schedule, date, times, and places..


7. Follow up, thanks you letters, reviews, and testing..

Techniques for Analyzing

1. Shadowing, observe the user by spending time at the workplace watching the users perform their jobs and tasks in addition to interviews and questionnaires.


2. Getting involved, don’t let the user know what you want to happen ahead or time because you may run the risk of chancing what happens naturally.

Barker mentions the use of cultivating a relationship with the users. What Barker does not mention is that if not done correctly then having a relationship may alter the research being done.

Chapter 5 describes the process of performing a user analysis as the initial stage in creating software documentation.

The user analysis is divided into eight categories:

1. Tasks and activities the user will perform


2. User’s informational needs


3. User’s work motivations


4. Level of the user’s computer experience


5. User’s knowledge of the program’s subject matter


6. User community


7. User’s learning preference


8. User’s usage pattern

The procedure for conducting a user analysis also consists of eight steps:

1. Choose users carefully


2. Anticipate transfer of learning: study users before and after using a program.


3. Research professional behaviors


4. Write use cases


5. Plan interviews carefully


6. Involve users in all phases of the project


7. Identify document goals


8. Tie the user analysis to document features

Each of these steps is described in detail in Chapter 5. It should be noted that the process described in this chapter is applicable only to large-scale documentation projects. The level of detail required has a direct relationship to the complexity level of the software application. Small projects will still require the technical communicator to perform a user analysis but it will be scaled back in scope and detail.

On large projects the technical writer is part of a dedicated writing team. This team normally consists of a manager, lead writer, writer, editor, graphics designer and test. The writing team works with the development team. The development team is usually composed of a project manager, software developers, market/systems analysts, technical specialists/programmers, and a documentation specialist. Additional information on these teams is found in Chapter 6.

It is common for the writing team to simultaneously develop documentation for multiple publishing formats. These can include hardcopy, PDF, online (HTML and XML), help systems, and localized (translated) versions of the documentation.

The user analysis phase of a project can last for months. During this time both the development and writing teams have extensive interaction with the user community. In the case of single source documentation projects the user analysis phase can become a development project all of its own. This is because actual document analysis must be performed to accurately describe the logical structure of different classes of legacy user documentation. Once the structures have been defined the development and/or writing teams will code those structures into XML/SGML schemas and/or Document Type Definitions (DTDs). Of particular interest is the fact that if Framemaker will be used by the user community then an additional step is necessary. The DTDs will need to be translated into Framemaker Element Definition Documents (EDDs). The EDDs merge logical structures with typographical markup. Thus, a user creating documentation based upon an EDD will be able to use Framemaker to compose fully marked-up text and then save that text in to a content management system and eventual use in an online documentation publication.

Something the text does not cover but is becoming increasingly common in user analysis is the creation of taxonomies. Taxonomies are systems of subject classification. These are important to online technical communicators because of the emergence of the Darwin Information Typing Architecture (DITA). DITA provides a framework for storing text elements (for inclusion in online compound documentation) based on subject headings. The key is that DITA does not define the classification of the logical structure of your subjects (taxonomies) for you. That is left for the development/writing teams to accomplish. Once taxonomies are defined they can be hard-coded into the XML data repository for a single sourcing content management system. At this point the authors using the system will be able to construct and manage online content based on custom subject tree structures (taxonomies) for their organization.

Guidelines for Developing Instructions ch. 5 (Ahles/Hennis)

In this chapter, Inaba, Parsons, and Smillie talk about the use of graphics in instructions. According to them, the role of graphics is to show where the equipment item of interest for each step is located, and what it looks like (39). Graphics are meant to make procedural documents usable and act as a compliment to the text. The graphics should work in a way so that the text can be direct and easy to understand. The chapter then goes into some ground rules on what to use with graphics.

Locators
Locators are the arrows and labels used to identify the items in a graphic. The authors give several rules on how to use locators in a graphic:
Use a locator to help the user find the area containing the item if it isn’t immediately obvious from a general view.
Use a locator and detailed view to show a detail difficult to see on the bigger view.
Use a caption to identify the locator or item unless the identity is obvious.

Detailed View
The detailed views are those that show all the components and parts mentioned in the text of the instructions. Rules given for the detailed view included only use a minimal number of illustrations to support the text, avoid unnecessary details or graphics, and show hands or tools in order to simplify the instruction text.

Types of Graphics
There are many types of graphics that can be used in procedural documents. All of which have their own rules and ways to be used. One of the most common is the line art graphic, which can be represented in two-dimensional, three-dimensional, or traced drawings. Although it is common to think that a photograph is better than a drawing, but a drawing can have much less clutter than a photograph and provide a more accurate representation. The rules for these drawings are as follows:
Three-dimensional drawings should be used for detailed views whenever possible.
Two-dimensional drawings should be used when 3D graphics aren’t available.
Only use traced drawings when 3D drawings aren’t economically available.

Captions and Callouts
Captions and callouts are two ways of supporting whatever type of graphic that you choose to use in a procedure. A caption can be used as a title to identify a graphic or portion of a graphic. The rule given for captions is to use them when the view or location of an item is not readily apparent

Callouts are numbers accompanying an arrow that points to a component or part in the graphic that’s also referenced in the text. For callouts, it is recommended to only use straight lines, restrict their length to one quadrant, place callout numbers at the tail end of each arrow, and arrange callouts in an easily recognizable sequence.

Ch.5 - Rockley, Managing Enterprise Content (Erik Sorenson & Emma Baumann)

This chapter talks about the content lifecycle. No doubt, as documents circulate many people will have their hands on them. Rockley states that it’s imperative that there be a unified strategy when managing content so that it can be utilized effectively by all who are involved. Rockley talks about the importance of eliminating anything that will impede the development of a unified strategy. The process of implementing a new system and methodology is a costly and time consuming task. Rockley states that it is important to take the time and analyze processes, whether they have worked well or not, in order to determine which ones will make the cut. It can be uncomfortable for those involved to have their work put under a microscope but in the end it will save time and money to identify problems and solutions in the beginning. Below is a look in to the lifecycle.

Content life cycle (in no particular order):
Deliver-Create-Review-Manage

How content is created:
Planning- Identifying need for the content
Design- Physical and contextual content, identifying templates and structure
Authoring and revision- typically all content is reviewed before publication

How content is managed:
Version Control- each document that is saved is versioned along with other documents
Access Control- allowing specific individuals to manage and change content

How content is delivered:
Companies can deliver and often will to multiple platforms. It is important to note who is receiving the content and how it is being delivered (Web, paper, PDF). How is the content managed differently for each medium?

Once all of the aspects of the life cycle are noted, it is important to look at who the content is being delivered to and how it’s being delivered to them. You need to identify the role of each user and basically interview them to see what is effective and what isn’t in their opinions. Taking in to account many views may help to deliver a more objective and useful product. There can be many issues once content is created that otherwise would go unnoticed until production if the interview process is skipped. Rockley states that this process is critical to understand how the intended audience is functioning with the product. There are a myriad of problems that can arise upon further interviewing. These problems can arise from the users and all the way back to the authors. The intention is that everything from the software and the final publication of the product be consistent in order to achieve maximum output with optimum consistency. Rockley includes multiple questions that one can ask each division of the content life cycle in order to ensure that nothing is being skipped or overlooked. Again, most of her questions aim at the goal of creating a unified content strategy, one which everyone is familiar and comfortable with.

Chapter 4 - Managing Enterprise Content-Rockley

Rockley addresses the need for understanding your organization's needs and goals in order to build an effective unified content strategy. To do this one must look within the organization to find out what type of content management and authoring issues may be present.

By addressing dangers such as economy, missing the market window and legal liabilities an organization can prepare for such situations before they arise. For example, a unifed content strategy can aleviate costs for content development and maintenance. This can free up an organization's budget when times aren't so good.

Rockley also states that within the dangers are opportunities such as faster time to market, new/improved product or service and improved customer support. By having a unified content strategy, it allows information to be changed quickly for new services or products without having to start from scratch. When a company realizes their strengths, they also will see opportunities. Rockley says that by focusing on an organization's strengths, they develop a positive outlook for moving forward. Some of the most common strengths are people, market recognition/ customer loyalty and innovation. A unified content strategy can assist in supporting these strengths for an organization. A good example of this is when customers respond favorably to more effective content therefore becoming more likely to remain loyal.

Rockley writes of the importance for an organization to also identify their goals, which are based on available opportunities, as well as identfy the challenges before moving forward with changes. The chapter states that one way of determining challenges is to ask key people within the organization what they perceive as challenges that could impact the organization's goals. Some of the most common listed are: time and money, resistance to change and maintaining existing deliverables.

To conclude Rockley says it is important to realize that a unified content strategy will not be a solution for all dangers, indentified within the organization. It's focus is intended to help solve problems experienced within the organization in the areas of content creation, management, delivery and communication with internal and external customers. This is just one piece of an organization's overall corporate strategy to addressing dangers, realizing opportunities and building on strengths.

Rebecca Guadagnoli and Jaya Narayana

Guidelines for Developing Instructions: Chapter 4 (Case/Pass)

Chapter four of Guidelines for Developing Instructions develops a series of rules for task preparation. The authors argue that once the user begins a task, the user should be able to continue to completion without having to stop to find tools, buy supplies, prepare equipment, or readjust materials. Therefore, it is essential to provide the user with a planning information page to explain what a user will need to have or need to do in order to successfully complete the given task. Below are the thirteen rules of task preparation as discussed in the book, many of them directly quoted:

Rule 1. Include planning information at the beginning of the procedure when the task requires any of the following:
- Tools, equipment, or supplies
- Preconditions to be met before the work can begin
- consideration of a variety of equipment configurations
- Different numbers and types of workers
- A number of tasks grouped into different series
When deciding how much planning information to include, consider the expected mode of use, and what the expected user will know, not know, or need to know. Be as specific as possible.

Rule 2. The format for planning information should abide by all of the following:
- it should be consistent throughout the entire document
- it should enable quick and accurate scanning
- it should follow the normal document presentation principles discussed in chapter three.

Rule 3. Use separate instructions for each model unless they are identical or almost identical. This includes multilingual instructions; a set of instructions should include no more than two languages to prevent the user from being lost in unusable information.

Rule 4. When the instructions apply to only specific models of a product, list the models under the heading. The same rule applies to when a step or a task only applies to specific models of a product.

Rule 5. When the instructions apply only to specific equipment items of a product, list the equipment under the heading. This rule also applies to when a step or task only applies to specific equipment items.

Rule 6. Include in the planning information the conditions or requirements that must be met before starting the procedure. Warn the user beforehand (assuming the user will read the instructions first) of whatever needs to be done before trying to do the task.

Rule 7. When there are multiple prerequisite conditions, present the conditions in list form. This will help the user take a step-by-step approach to completing the prerequisites, and will increase the odds that the user won’t miss a prerequisite.

Rule 8. Use ANSI Z535.4-1991 or -1998 Product Safety Signs and Labels as a standard for presenting safety information. These are standards regarding the efficient usage and visual appearance of the words Danger, Warning, and Caution in documentation.
- Danger indicates an imminently hazardous situation that, if not avoided, could result in serious injury or death. Danger should appear in white letters on a red background.
- Warning indicates a potentially hazardous situation that, if not avoided, could result in serious injury or death. Warnings should appear in black letters on an orange background.
- Caution indicates a potentially hazardous situation that, if not avoided, could result in minor or moderate injury. Cautions should appear in black letters on a yellow background.

Rule 9. When safety is a concern, explain the hazardous conditions to the user ahead of time in the planning page. Tell the user what to watch out for, and how to know if they have done something potentially dangerous.

Rule 10. Identify any help required of another person to successfully complete the task. If the user will need other people to be involved in the task, the user should know about it ahead of time so he/she can arrange to get the help.

Rule 11. Identify the resources and materials needed to complete the task. When writing for a technician, you do not need to include things that are always present in the technician’s workspace, such as a set of standard tools. However, when writing instructions for consumers, you should list all tools, expendable resources (gas, grease, tape, etc), or products needed.

Rule 12. When a sequence of tasks is involved, list the items and resources needed by task so the user knows which items are for which task. That way, if the user is only going to complete one task, he/she can prepare just for that one task.

Rule 13. When the package or procedure includes more than one task, provide a table of contents as part of the planning information to help the user quickly find the task of interest.

Writing Software Documentation
Bynum/Peterson
Chapter 4 – Writing to Support – Reference

Where Chapter 3 addressed writing process documentation (Writing to Guide), Chapter 4 focuses on writing reference documentation. It’s Barker’s assertion that reference manuals are geared toward users who are adept at using the software and only need to go to the reference material for answers in complicated situations. He says that reference documents usually contain very little “how to” to information. Their function is to direct the user over a hurdle and allow him/her to continue on with a task.

Reference (or support) documentation can take many different forms, including:

• Command descriptions
• Menu overviews
• Lists of definitions
• Function descriptions
• Examples
• Error messages

Barker promotes the use of the following five guidelines to develop effective reference materials:

1. Choose the Right Form of Reference
   Barker states that advanced users who go to reference materials are usually looking for a quick answer to a specific question or problem. There are several standard formats that lend themselves to different scenarios—appendices, readme files, job aids, and flipcards. These conventions allow an experienced software user to know where to expect to find the information they need.
2. Decide What to Include
   When writing reference documentation a person must decide which topics to include, such as commands, interface elements, and/or definitions of terms.
3. Establish a Pattern
   “Recognition through regularity” describes this guideline. A successful reference document repeats consistent patterns that provide familiarity to users.
4. Organize Reference Section
   Support documentation requires making decisions on the order of material will be presented. There are two basic organizational options: alphabetical and menu-by-menu. Barker says that there is an advantage to using the menu-by-menu format.
5. Show How to Use the Reference Section
   If users are familiar with the different format support documentation can take, instructions are usually not needed. However, if multiple formats are combined, an introductory section could be beneficial.
   

Managing Enterprise Content
Willis/Bach
Chapter 3 – Assessing Return on Investment for a Unified Content Strategy.
This chapter primarily consisted of the setting and meeting of goals when deciding whether or not to implement a unified content strategy. It was divided primarily into three parts, "Identifying goals," "Qualifying goals," and "Quantifying goals." The first two are easily summarized, with statements such as the following:
A fictitious company was used in demonstrating the process of deciding whether or not to implement a unified content strategy. The process was as follows:
Identifying Goals:
- Shorten time-to-market (how long it takes to get an item from conception to sales).
- Reduce cost of content development.
- Improve accuracy and quality of content.
- Reduce manufacturing defects.
These are all noble goals, but they aren't very specific. Without further guidelines, slight improvement can be viewed as successfully completing a goal. Hence, the next category:
Qualifying Goals:
- Reduce time-to-market by two months
- Reduce cost of content development by 25%
- Ensure content accuracy at all times (100% accuracy)
- Reduce defects to less than .01%
The last task of Quantifying the content is a bit more difficult. This essentially breaks down to how much benefit (read: money) the company gains by following these guidelines. For instance, maintaining constant 100% content accuracy can be fairly costly; however, if the company is sued due to a flaw in a manual, the loss could be catastrophic. Even if the company wins the case, the costs for simply defending themselves alone will be far greater than the cost spent on making sure they aren't sued in the first place.
The above process is not possible without gathering metrics (real costs). To do this the following steps need to be taken.
-Identify tasks.
-Measure the duration of a task.
-Calculate the cost of a task.
Ongoing metrics need to be performed as well.
Compare savings and/or value to the cost of achieving a goal.
After calculating the return on investment, the determination to implement a unified content strategy should reveal itself.

Ch. 3 - Guidelines for Developing Instructions (Emma Baumann & Erik Sorenson)

Chapter 3 of Guidelines for Developing Instructions discusses general presentation principles of creating instructions. All of the principles in this chapter have to do with helping the user acquire information quickly and accurately. They are short-term memory, consistency and fixed syntax, text-graphic, figure-ground ratio, sequence, and multilingual.

The main principle that is explained in this chapter is short-term memory. For developing instructions, the duration of short-term memory should be considered 1 to 30 seconds, and the capacity is four related actions. This means that it should take a user no longer than 30 seconds to read the instruction for a particular step, look at the equipment pertaining to the step, and start the action process. This section goes on to explain this principle by giving specific examples of what/what not to do when writing instructions. The authors advise writers to aim to make instructions usable enough that the user will follow the instructions rather than trying to “wing it” and do it on their own. What is meant by this is that lengthier instructions don’t necessarily mean more usable instructions. Many people skip over long paragraphs, so it’s better to create short, concise step-by-step instructions so that the user will actually read each step.

The consistency and fixed syntax principle is simply based on the idea that using repeated action verbs, sentence structure, and graphics helps the user access and understand the instruction quickly. The text-graphic principle is the idea that text is appropriate for what to do, how to do it, and the sequence to do it in. Graphics, on the other hand, are best suited for the location and object of the action (showing where to perform the action).

Figure-to-ground ratio refers to the item of interest (“figure”) as compared to the area around the figure (“ground”). The text states that a ratio of 1:7 is the max for scanning accuracy and time. Basically, in an illustration, each piece of the equipment is the figure when the user is looking specifically for that piece, and all other parts of the equipment are the ground. In the same way, if callout numbers are used to point to each part of the equipment, then the number a user is looking for is the figure and all other numbers are the ground. This means that if a writer is using callout numbers, they should only use up to seven, unless the numbers are arranged in a structured and recognizable way.


Sequence simply means that a writer should arrange steps in the order that actions should occur, instead of random steps. The principle of multilingual format explains that when creating instructions in two different languages, they should be kept in separate sections so that the flow of information isn’t interrupted.

(Late) Chapter 2 Summary

Rebecca Guadagnoli and Jaya Narayana

Chapter two of Inaba, Parsons and Smillie discusses the 3 factors that greatly influence the ground rules for writing usable and useful instructions. They are the expected mode of use for the instructions, the basic units of instruction and the different components of information. The chapter walks us through the difference between actions, steps and tasks and how they are written affects the success or failure of the individual using those instructions. The chapter discusses that the expected mode of use for the novice verses the experienced user is quite different. For example the inexperienced user will follow the step-by-step instructions in the beginning and then less after the first couple of times, whereas the experienced user will tend to use the instructions only if they cannot figure out what to do based on their knowledge and experience with the product. When coming across unfamiliar information, both the inexperienced and experienced need the following information: what and when to perform the actions, the order of the actions, where the action is to take place and what the object of the actions looks like. The breakdown of actions, steps and tasks was interesting. The importance was stressed on the use of consistent actions verbs throughout the documentation so as not to confuse the user. Remembering when to go into more detail is key as you can say "remove the faceplate" but when talking about something more complex such as a car engine, you can't simply state "remove the engine" as there are many detailed actions and steps required for the engine to be removed. The authors mention that extensive cross-referencing can confuse the user. It is important that the step-by-step instructions convey what has to be done, how it must be accomplished as well as where, when, order and identity so the user can find it. There are other types of information needed to support instructions such as information to plan the work and description information which assists the user in understanding the equipment or system well enough to make diagnostic decisions. Finally, there is a need for flexibility in writing instructions. This is key in developing simple and effective instructions. Generally the instructions are written to meet the needs of the user, but some of the needs are individualistic.

Ahles/Hennis-Barker Chapter 3

Chapter 3—Writing Software Documentation

Chapter Layout
Barker writes about procedures in chapter three. The procedures he refers to are called guidance, how-to, and step-by-step. He presents different methods for writing different types of procedural instructions and suggests that learners want to know both how and why the software works.

What is a Procedure?
Barker says there are three types of documentation: guidance level, teaching level, and support level. Teaching level documentation is also called tutorial; the object is to teach the user the program and its uses. Support level (or reference) is user-defined; the user determines where they find the information and how much of that information they will use. Guidance level documentation falls somewhere in between teaching and reference; the user may be familiar with the program and only needs a reminder of what to do.

Guidelines for Procedures
According to Barker, authors need to make the procedures useful by tailoring them to activities that normally occur in the workplace. The procedure will be much more meaningful to the learner if it relates to something he/she does in the workplace every day. The procedure should be recognized as a building block that fits into the larger picture of what the office accomplishes in a normal day.
The writer needs to determine what the end-user will need to accomplish their task. He does this by doing a user analysis (to be covered later). The user analysis will determine how much or how little information will be included in the procedure. Barker (p.68) says that the writer will use a combination of tools in the procedure including:

• Screen Shots
  
• Cautions and Warnings
  
• Tips for Efficient Use
  
• Tables w/ Option for the User
  
• References to Other Resources
  
• Explanations
  

Formats

Barker suggests that there are basically four formats to use when writing procedures. He calls them the standard format, prose format, parallel format, and embedded help. All procedures, regardless of type, need to have evaluations done on them to makes certain that they are reasonably complete and accurate.
The standard format contains the steps in a numbered sequence from first to last. This type of procedure is often seen in instruction manuals such as software books. Most of us have seen it before, and Barker suggests that user recognition makes this type of procedure useful.
The prose format puts the procedure into sentences and paragraphs instead of numbered steps. This type of procedure is used for simple tasks done on a simple interface.
Parallel format is used with complicated fields or boxes. Numbered (lettered) steps are used along with prose explanations.
Embedded help is used when the user needs help that is specific to his location within a program. Embedded help uses markers within the program which, when called upon, present the user with information that is relevant to their place in the program. Embedded help uses various methods for presenting information including tips, cues, demonstrations, and trouble-shooting.

Barker ch 2 Pass/Case

Chapter 2 of Writing Software Documentation covers an overview to writing tutorials for computer programs.
Barker begins by identifying seven guidelines essential to writing an effective tutorial:
Identify User Actions You Need to Support—in other words, analyze your user and what specific tasks they will be doing with the program. Tie the program’s features back to the user’s goals and how they can use the program to accomplish them.
State objectives as Real-World Performance—Be realistic. Start writing a tutorial by stating, in measurable terms, what tasks you want the user to be able to do after using the tutorial. Often it is beneficial to state these goals in the tutorial for the user to see.
Chose the Right Type of Tutorial—Analyze your user and decide what format of tutorial will suit their needs the best. 5 types of tutorials Barker discusses in the text are: The guided tour, the demonstration, the quick start, the guided exploration, and the instruction manual.
Present Skills in Logical, Cumulative Structure—Imagine the typical-use scenario for your user, and use it to build your tutorial structure. Order your tutorial steps, tasks, or modules based on how your user will most likely be using the program once they learn how to use it.
Offer Highly Specific Instructions—Be as specific as possible. Don’t give general or vague information (such as telling your user to ‘enter any name’) just because your users have different perspectives of various things. Guide the user to exactly where they need to go, and tell them exactly what will help them get there.
Give Practice and Feedback at Each Skill Level—Be positive and encouraging towards your user, and remind them of the benefits of learning how to use the program.
Test Your Tutorial—Be an advocate your user by making sure that the product they get will do what they want it to do.
The second half of this chapter is dedicated to the difference between elaborative and minimalist approaches when writing tutorials. These two perspectives on writing seem to be dichotomic, one valuing thoroughness and the other valuing brevity. Sometimes the minimalist approach will be a more useful approach for a project, and sometimes the elaborative approach will be more useful, so it is worth it to explore both perspectives.
The elaborative approach focuses on peoples’ ability to retain information more thoroughly through repetition. To achieve this repetition, the tutorial utilizes introductions, summaries, examples, skill tests and a variety of other ways to present information. This approach is better suited for users that are new to computer usage, complicated procedures, or for situations in which the user must learn abstract concepts.
In contrast, the minimalist approach plays off the belief that users do not want to read instructions or unnecessary information. To follow these beliefs they try to teach using specific tasks related to the use of the software while letting the student explore the program. This approach is better suited for users that are familiar with computers, programs that require creativity from the user, or programs that have intuitively-designed interfaces.