diff --git a/docs/no_toc/01-intro.md b/docs/no_toc/01-intro.md index 7eebd65..a0ef3c8 100644 --- a/docs/no_toc/01-intro.md +++ b/docs/no_toc/01-intro.md @@ -7,7 +7,7 @@ output: html_document # Introduction -Title image: Documentation and Usability +Title image: Documentation and Usability ## Motivation @@ -20,15 +20,15 @@ Increasing the usability and quality of documentation for a tool is not only hel The course is intended for cancer informatics tool developers, particularly those creating tools as a part of the [Informatics Technology Cancer Research](https://itcr.cancer.gov/informatics-tools). -For individuals whom: Create informatics tools, want to learn how to apply user experience design principles to their tools and want to increase the quality of their documentation +For individuals whom: Create informatics tools, want to learn how to apply user experience design principles to their tools and want to increase the quality of their documentation ## Topics covered: -Concepts discussed in Documentation and Usability course:Apply usability research concepts, Create user friendly guides, Document code clearly, Obtain helpful user feedback +Concepts discussed in Documentation and Usability course:Apply usability research concepts, Create user friendly guides, Document code clearly, Obtain helpful user feedback ## Curriculum -This course will demonstrate how to: Understanding why usability and documentation is vital, Identifying your user community, Building documentation and tutorials to maximize the usability of developed tools, Obtaining feedback from your users +This course will demonstrate how to: Understanding why usability and documentation is vital, Identifying your user community, Building documentation and tutorials to maximize the usability of developed tools, Obtaining feedback from your users The course includes a hands-on exercises with templates for building documentation and tutorials for cancer informatics tools. Individuals who take this course are encouraged to use these templates as they follow along with the course material to help increase the usability of their informatics tool. diff --git a/docs/no_toc/02-why_documentation.md b/docs/no_toc/02-why_documentation.md index 1386b03..ba70929 100644 --- a/docs/no_toc/02-why_documentation.md +++ b/docs/no_toc/02-why_documentation.md @@ -7,7 +7,7 @@ output: html_document # Documentation: Why it's worth the effort! -Learning objectives This chapter will demonstrate how to:Understand good documentation increases the impact and usability of software tools. Understand good documentation is helpful for both tool developers and users. +Learning objectives This chapter will demonstrate how to:Understand good documentation increases the impact and usability of software tools. Understand good documentation is helpful for both tool developers and users. ## The context of bioinformatics tool development @@ -15,7 +15,7 @@ Tool development is an exciting but long process -- filled with lots of careful Tina the Tool developer, perhaps like you, has just gotten her product working well and many of the bugs have been sorted out. Tina's awesome tool is working exactly as designed and Tina is excited to get her tool out there to be used by the community! -Tina the Tool Developer says, After years of tedious work my informatics tool is working!. Tina’s awesome tool is a sparkling brand new. +Tina the Tool Developer says, After years of tedious work my informatics tool is working!. Tina’s awesome tool is a sparkling brand new. ^[For all cartoons: Avataars by https://getavataaars.com/. Icons by https://thenounproject.com/ License CC BY-NC-ND 2.0. @@ -23,11 +23,11 @@ Emojis by OpenMoji License: CC BY-SA 4.0.] This is indeed cause for celebration! Perhaps researchers like Uri the Tool User will come across Tina's awesome tool and share in Tina's enthusiasm for the project! Tina's bioinformatics tool may be just what they were needing for their research project! -Upon finding Tina the Tool Developer’s awesome tool, Uri the Tool User says Tina’s tool is just what I need for my research project! +Upon finding Tina the Tool Developer’s awesome tool, Uri the Tool User says Tina’s tool is just what I need for my research project! Uri the Tool User can't wait to apply Tina's awesome tool to their project! But, it may not be long before Uri encounters errors, or questions about Tina's awesome tool, no matter how high quality Tina's programming of the tool is. -Tina’s awesome tool says unintelligible warning, Error: The jargony sounding thing has encountered a problem and is on fire with the word error written all over it. Uri the Tool User is distressed and confused. +Tina’s awesome tool says unintelligible warning, Error: The jargony sounding thing has encountered a problem and is on fire with the word error written all over it. Uri the Tool User is distressed and confused. Often users like Uri, particularly in the biology and cancer fields, have little to no programming experience. Even if a user does have programming experience, they are still unfamiliar with how Tina has set up tool. The tool may even be working exactly according to Tina's vision but if users like Uri do not understand Tina's vision or basic programming principles that Tina might take for granted, it can lead to a lot of frustration and time inefficiently spent. @@ -35,7 +35,7 @@ If the tool's documentation is non-existent, scarce, out-of-date, or filled with Lack of usability often leads users to ditch even the most well-programmed of tools. -Uri the Tool User says I have other projects due! I can’t spend more time trying to figure this tool out. Tina’s awesome tool is still on fire with errors written all over it but has been thrown in a wastebasket by Uri the Tool User. There is no documentation to help Uri the Tool user figure out how to use Tina’s awesome tool. Uri the Tool User is even more distressed and has a tear in their eye from frustration. +Uri the Tool User says I have other projects due! I can’t spend more time trying to figure this tool out. Tina’s awesome tool is still on fire with errors written all over it but has been thrown in a wastebasket by Uri the Tool User. There is no documentation to help Uri the Tool user figure out how to use Tina’s awesome tool. Uri the Tool User is even more distressed and has a tear in their eye from frustration. This is the unfortunate and all-too-common result of many bioinformatics tools. @@ -57,32 +57,32 @@ We realize many tool developers feel unenthused about the process of creating do We'd like to assure you that the effort for creating documentation has a high return payoff for the continued success of your tool as a whole! -Thorough and easy-to-digest documentation not only benefits users, but tool developers themselves! +Thorough and easy-to-digest documentation not only benefits users, but tool developers themselves! Returning to our cast of characters, let's say that Tina the Tool Developer, had the time and knowledge to create awesome documentation for her tool. -In this next scenario, Tina the Tool Developer has skillfully created documentation that goes along with her awesome tool. The documentation is a personified document icon. +In this next scenario, Tina the Tool Developer has skillfully created documentation that goes along with her awesome tool. The documentation is a personified document icon. Uri the tool User is still likely to encounter errors and problems, but with thorough and easy-to-digest documentation, Uri is better equipped to troubleshoot these problems! They may also learn more about the features and limitations of the tool that will better guide Uri's next steps! -Uri the Tool User is again trying to use Tina’s awesome tool and encounters warnings: Tina’s tool is on fire. This time however, Tina’s documentation is present and says I can help and Uri the Tool User, though not happy, is not as frustrated as before. Although Tina the Tool Developer is not present, Tina’s documentation can help communicate to Uri how to navigate Tina’s awesome tool. +Uri the Tool User is again trying to use Tina’s awesome tool and encounters warnings: Tina’s tool is on fire. This time however, Tina’s documentation is present and says I can help and Uri the Tool User, though not happy, is not as frustrated as before. Although Tina the Tool Developer is not present, Tina’s documentation can help communicate to Uri how to navigate Tina’s awesome tool. Being equipped with user-centered documentation, Uri is more likely to be able to reach the next steps of their research and potentially share a publishable result! Tina's tool is now more likely to be cited in publications, or other forms of media. -Uri the Tool User is enamored with Tina’s awesome tool that has awesome documentation because it has helped them wrap up their research project that is represented by a wrapped gift. Uri the Tool User says, Tina’s awesome tool saved me so much time and let me complete this awesome work!. +Uri the Tool User is enamored with Tina’s awesome tool that has awesome documentation because it has helped them wrap up their research project that is represented by a wrapped gift. Uri the Tool User says, Tina’s awesome tool saved me so much time and let me complete this awesome work!. This rewards Uri for having used Tina's tool, making Uri not only likely to continue to use the tool for their next projects, but Uri may also help spread the word about how great their experience with Tina's tool was. -Uri the Tool User is telling all their colleagues how much they love Tina’s awesome tool that has documentation. Uri has a phone is posting to their professional social media accounts about how great Tina’s awesome tool and documentation is. A megaphone is pointed at a crowd. More users are informed about Tina’s awesome tool and Tina’s work is disseminated. +Uri the Tool User is telling all their colleagues how much they love Tina’s awesome tool that has documentation. Uri has a phone is posting to their professional social media accounts about how great Tina’s awesome tool and documentation is. A megaphone is pointed at a crowd. More users are informed about Tina’s awesome tool and Tina’s work is disseminated. This means that Tina may have a larger user base for her tool and will help Tina with future funding opportunities and making connections that will help her create more awesome tools! Well-documented tools help developers better maintain their code in the future because they may forget the mechanics of their tool over time. If future Tina has to divert her time and effort to another project but then returns to do tool maintenance, documentation may help jog her memory! -Future Tina the Tool Developer now has gray hair and Tina’s awesome documentation is between Tina and Tina’s awesome tool. The documentation says It’s been awhile, let me re-introduce you to the awesome tool you made a while back! +Future Tina the Tool Developer now has gray hair and Tina’s awesome documentation is between Tina and Tina’s awesome tool. The documentation says It’s been awhile, let me re-introduce you to the awesome tool you made a while back! Thorough and easy-to-digest documentation may also help other tool developers contribute features or fix bugs in Tina's tool. Here Colin the Contributor was able to read Tina's awesome documentation. It not only got him excited about the tool, but allowed him to program a new feature which he sent to Tina. -Colin the Contributor says, Tina’s documentation introduced me to the tool so well that I was excited to contribute a new feature! The feature is represented as a sparkling code. Tina the Tool Developer is excited to incorporate this new feature to the tool. +Colin the Contributor says, Tina’s documentation introduced me to the tool so well that I was excited to contribute a new feature! The feature is represented as a sparkling code. Tina the Tool Developer is excited to incorporate this new feature to the tool. Now that you are hopefully energized and ready for creating documentation for your tool, let's talk about a bit user-centered design concepts! diff --git a/docs/no_toc/03-lessons_from_user_designers.md b/docs/no_toc/03-lessons_from_user_designers.md index 8cf5424..04bab2a 100644 --- a/docs/no_toc/03-lessons_from_user_designers.md +++ b/docs/no_toc/03-lessons_from_user_designers.md @@ -7,7 +7,7 @@ output: html_document # Lessons we should borrow from user designers -Learning objectives This chapter will demonstrate how to: Understand good documentation increases the impact and usability of software tools. Understand good documentation is helpful for both tool developers and users. +Learning objectives This chapter will demonstrate how to: Understand good documentation increases the impact and usability of software tools. Understand good documentation is helpful for both tool developers and users. ## Thinking about user-centered development @@ -16,7 +16,7 @@ In other words, user-centered design is an exercise in applied empathy [@deMatos This is why a common saying in user-centered design is "You are not your user" [@Alexakis2017]. Although it may be true that you may have a lot in common with your user, this saying is based in the idea that you should not assume your user knows what you know or thinks like you do. For example, a warning message that may seem perfectly clear to you as a developer, may be a foreign language to your user. -Tina the Tool Developer and Uri the Tool User both are looking at Tina’s tool that has error written all over it with a warning sign. Tina says These error messages tell me exactly what I need to know and everything is working as I intended! But Uri the Tool User says I don’t understand what I’m doing wrong these errors are unintelligible to me! +Tina the Tool Developer and Uri the Tool User both are looking at Tina’s tool that has error written all over it with a warning sign. Tina says These error messages tell me exactly what I need to know and everything is working as I intended! But Uri the Tool User says I don’t understand what I’m doing wrong these errors are unintelligible to me! ^[For all cartoons: Avataars by https://getavataaars.com/. Icons by https://thenounproject.com/ License CC BY-NC-ND 2.0. @@ -30,7 +30,7 @@ As compared to yourself, your typical user may likely have a different: And most importantly _your user does not know your tool like you do_! You have spent many, many hours developing this tool and its unrealistic and impractical for them to spend the same number of hours with your tool that you have. -Your user does not know your tool like you do! +Your user does not know your tool like you do! Also keep in mind users are humans in a context. Humans have demands in their life, have been working long days, and are tired/frustrated/distracted/etc. Making your tool as easy as possible to use increases the likelihood of your user continuing to stick with your tool and even becoming an advocate for your tool to their colleagues! @@ -82,7 +82,7 @@ Humans are drawn to intuitive visuals. Visuals are efficient means of communicat Sometimes this is particularly helpful for complicated concepts. For example, BEDtools (@Quinlan2010) allows for the manipulation of genomic sequences in BED files. Some of these principles can be complicated to visualize, but the authors of BEDtools do a great job of using visuals to explain each function: -BEDtools has nice visuals with their documentation that help explain complicated subject matter. In this figure they’re showing how ranges are merged together. +BEDtools has nice visuals with their documentation that help explain complicated subject matter. In this figure they’re showing how ranges are merged together. Here, this figure explains how the merge function works given a particular set of ranges. diff --git a/docs/no_toc/04-good_documentation.md b/docs/no_toc/04-good_documentation.md index 5158f01..1e84556 100644 --- a/docs/no_toc/04-good_documentation.md +++ b/docs/no_toc/04-good_documentation.md @@ -7,13 +7,13 @@ output: html_document # What does good documentation look like? -Learning Objectives This chapter will demonstrate how to: Identify major components common to good documentation. Describe the purposes of components of good documentation. Set up our documentation templates for following along with the rest of this course. +Learning Objectives This chapter will demonstrate how to: Identify major components common to good documentation. Describe the purposes of components of good documentation. Set up our documentation templates for following along with the rest of this course. ## Major components of good documentation In this chapter we are going to cover the major aspects of a well-documented tool. In the subsequent chapters, we will talk about each of these components in more detail, providing relevant examples and tools. Others have divided this system into different categories which we have taken inspiration from for what we describe here [@divio]. -The anthropomorphic documentation has 6 major components in this illustration including: The why, getting started, how-to examples, reference guide, code comments, and user feedback. +The anthropomorphic documentation has 6 major components in this illustration including: The why, getting started, how-to examples, reference guide, code comments, and user feedback. ^[For all cartoons: Avataars by https://getavataaars.com/. @@ -22,7 +22,7 @@ Emojis by OpenMoji License: CC BY-SA 4.0.] We can think of these components of documentation in terms of how much time a user has invested in learning the tool: -The various components of good documentation: The why, getting started, how-to examples, reference guide, code comments, and user feedback are on a continuum in that order from the most to least amount of time spent invested in a tool. +The various components of good documentation: The why, getting started, how-to examples, reference guide, code comments, and user feedback are on a continuum in that order from the most to least amount of time spent invested in a tool. This isn't always a perfect linear timeline like this, users may use these items in a different order than we expect, but this demonstrates the intent of how users would progress through the documentation. diff --git a/docs/no_toc/05-getting_started_sections.md b/docs/no_toc/05-getting_started_sections.md index 38dba94..249c9ca 100644 --- a/docs/no_toc/05-getting_started_sections.md +++ b/docs/no_toc/05-getting_started_sections.md @@ -7,13 +7,13 @@ output: html_document # Creating a smooth getting started section -Learning Objectives. This chapter will demonstrate how to: Understand the goals of a getting started section. Make installation step instructions more user-friendly. Write a user friendly getting started section for your tool. +Learning Objectives. This chapter will demonstrate how to: Understand the goals of a getting started section. Make installation step instructions more user-friendly. Write a user friendly getting started section for your tool. ## The goal of a getting started section A getting started section is new users' first experience with your tool. It is also can be the most frustrating experience for your user if installation doesn't happen smoothly. -Your new users are represented as a baby chick emoji who is surrounded by a photo of an alligator labeled with your tool’s software dependencies. Software dependencies and other installation problems can easily overwhelm new users. +Your new users are represented as a baby chick emoji who is surrounded by a photo of an alligator labeled with your tool’s software dependencies. Software dependencies and other installation problems can easily overwhelm new users. ^[For all cartoons: Avataars by https://getavataaars.com/. Icons by https://thenounproject.com/ License CC BY-NC-ND 2.0. @@ -51,7 +51,7 @@ Do some steps take more time than others? Warn them about that. Are there output Where it makes sense, you **use screenshots as assurances** to the user that they are on the right track. Being able to see that your users' screen matches what is shown in your screenshots reassures them that things are progressing correctly. Conversely, if something does not match, it can help them narrow in on a problem. _Keep in mind out-of-date screenshots can add to the confusion! -- more on tips about how to keep things up to date in a later chapter._ -The documentation tells Uri the tool user to look for a screenshot. Uri has that same screenshot and says This matches what I’m seeing! I’m confident I’m on my way! +The documentation tells Uri the tool user to look for a screenshot. Uri has that same screenshot and says This matches what I’m seeing! I’m confident I’m on my way! Install steps should also try to address any common pitfalls, particularly **how different operating systems might require different steps**. You may consider having separate sections or pages to describe install steps on different operating systems. @@ -59,7 +59,7 @@ What dependencies does installing your tool require? Will these be installed aut **To recap:** -Install Steps Goals include: Be as clear and specific as possible - copy and paste commands. Assure your user about what to expect. Address any common pitfalls. Address how operating systems might differ. Provide steps for software dependencies. +Install Steps Goals include: Be as clear and specific as possible - copy and paste commands. Assure your user about what to expect. Address any common pitfalls. Address how operating systems might differ. Provide steps for software dependencies. Installation steps can be tricky -- and admittedly hard to give guidance on when individual computer' set ups can differ so much, but the more you are able to workshop your guidance to your users here, the more they will appreciate it and stick with your tool! @@ -80,7 +80,7 @@ Give your users the fewest steps needed to produce a rewarding result that will This rewarding result might be a cool visual or a plot -- but also should demonstrate the most popular thing your users would like to see. -The software tool says 'you installed me successfully'. The new user, represented by a baby chick is rewarded with some rewarding output, represented as a gift. +The software tool says 'you installed me successfully'. The new user, represented by a baby chick is rewarded with some rewarding output, represented as a gift. ### Directs the user to the how-to examples section @@ -90,11 +90,11 @@ Now that your user has successfully installed your tool and understands the basi [Snakemake has a great getting started section](https://snakemake.readthedocs.io/en/stable/getting_started/installation.html) [@Molder2021]. The makers of Snakemake tell their users how to install Snakemake using different situations and keeping dependencies in mind, right after which they have a short tutorial to entice their users! -Here is a screenshot of snakemake’s documentation. It shows the sidebar which has installation, a tutorial, and another short tutorial. +Here is a screenshot of snakemake’s documentation. It shows the sidebar which has installation, a tutorial, and another short tutorial. [GSEA](https://www.gsea-msigdb.org/gsea/doc/GSEAUserGuideFrame.html) introduces their users to multiple options of how they can run the tool and nicely use reassuring screenshots throughout to let their users know if they are on the right track [@Subramanian2005]! -Here is a screenshot of GSEA’s documentation. It shows screenshots to assure the user what to expect. +Here is a screenshot of GSEA’s documentation. It shows screenshots to assure the user what to expect. ## Exercise: Create your own getting started section! diff --git a/docs/no_toc/06-how-to_examples.md b/docs/no_toc/06-how-to_examples.md index edaced7..d4631b9 100644 --- a/docs/no_toc/06-how-to_examples.md +++ b/docs/no_toc/06-how-to_examples.md @@ -7,7 +7,7 @@ output: html_document # Creating helpful how-to examples -This chapter will demonstrate how to:Understand the goals of a how-to examples. Describe components included in useful how-to examples. Create how-to examples that will increase your users’ familiarity with your tool. +This chapter will demonstrate how to:Understand the goals of a how-to examples. Describe components included in useful how-to examples. Create how-to examples that will increase your users’ familiarity with your tool. ## The goal of how-to examples @@ -15,7 +15,7 @@ While getting started sections are geared toward brand-new users, how-to example How-to examples are like recipes in a cookbook. We can generally assume your user has found the kitchen, now give them sets of steps to create something awesome! -Uri the Tool User has a thought bubble with “the basic concepts of the tool” which are represented as various food ingredients: an apple, butter, milk, eggs. Uri the Tool User has a question mark about how to create an end point that is represented here as a pie. +Uri the Tool User has a thought bubble with “the basic concepts of the tool” which are represented as various food ingredients: an apple, butter, milk, eggs. Uri the Tool User has a question mark about how to create an end point that is represented here as a pie. ^[For all cartoons: Avataars by https://getavataaars.com/. Icons by https://thenounproject.com/ License CC BY-NC-ND 2.0. @@ -49,7 +49,7 @@ Make sure your example adequately introduces the example: what are the measureme Example code is not the same as backend code. Although example code should also be functional and work, its primarily meant to teach. Even more so than usual, code in examples should always prioritize clarity over cleverness or even brevity. -Example code is not the same as backend code it is primarily meant to teach! +Example code is not the same as backend code it is primarily meant to teach! This means your examples should include the most easily readable code you can muster -- this often means extra workshopping to reach peak clarity. Give commentary at each and every step -- don't assume your users understand your typical conventions. Also in the interest of being as readable as possible, try to stick to a styling conventions -- s p a c i n g matters! @@ -80,7 +80,7 @@ If your users follow along with your examples successfully, next they will proba **To recap:** -Useful How-to Examples:Covers what your users are interested in. Gives every step specifically. Provides example data. Doesn’t require more packages. Models best practices. Gives ‘tailoring’ tips. +Useful How-to Examples:Covers what your users are interested in. Gives every step specifically. Provides example data. Doesn’t require more packages. Models best practices. Gives ‘tailoring’ tips. ## Good examples of How-to examples diff --git a/docs/no_toc/07-reference_guides.md b/docs/no_toc/07-reference_guides.md index 1db6523..e259ef8 100644 --- a/docs/no_toc/07-reference_guides.md +++ b/docs/no_toc/07-reference_guides.md @@ -7,13 +7,13 @@ output: html_document # Creating handy reference guides -This chapter will demonstrate how to: Understand the goals of a reference guide. Describe characteristics of helpful reference guides. Create a reference guide that will aid your user’s ability to interpret and utilize your tool to the next level. +This chapter will demonstrate how to: Understand the goals of a reference guide. Describe characteristics of helpful reference guides. Create a reference guide that will aid your user’s ability to interpret and utilize your tool to the next level. ## The goal of a reference guide Reference guides are the dictionary of your tool: they aren't meant to be read front to back, but the best ones are easily searchable. Your user will have something in mind that they are trying to find information on -- the quicker they can find it, the quicker their question can be answered. -Uri the tool user has encountered an error in the tool that says Error flux capacitor cannot take this data format. This causes Uri to think of a question: What kinds of data formats does the flux capacitor take? This will lead Uri to look up flux capacitor in the reference guide. +Uri the tool user has encountered an error in the tool that says Error flux capacitor cannot take this data format. This causes Uri to think of a question: What kinds of data formats does the flux capacitor take? This will lead Uri to look up flux capacitor in the reference guide. ^[For all cartoons: Avataars by https://getavataaars.com/. Icons by https://thenounproject.com/ License CC BY-NC-ND 2.0. @@ -76,7 +76,7 @@ Depending on the destination of your package, a consistent format may already be **To recap:** -Helpful Reference Guides: Are searchable. Are comprehensive. Describes data formats. Entries are consistently formatted. +Helpful Reference Guides: Are searchable. Are comprehensive. Describes data formats. Entries are consistently formatted. ## Good examples of reference guides diff --git a/docs/no_toc/08-code_comments.md b/docs/no_toc/08-code_comments.md index 79d2c53..279f7cd 100644 --- a/docs/no_toc/08-code_comments.md +++ b/docs/no_toc/08-code_comments.md @@ -7,7 +7,7 @@ output: html_document # Creating clarifying code comments -This chapter will demonstrate how to: Understand the goals of good code documentation. Describe characteristics of helpful code comments. +This chapter will demonstrate how to: Understand the goals of good code documentation. Describe characteristics of helpful code comments. ## The goal of a code documentation @@ -62,7 +62,7 @@ Here are more resources about good code comments that have plenty of great discu **In summary:** -Good code documentation: Is a part of writing good code! Increases the readability of your code. Clarify where the code requires explanation. Can help you write out your thought process. +Good code documentation: Is a part of writing good code! Increases the readability of your code. Clarify where the code requires explanation. Can help you write out your thought process. ## Exercise: Evaluate your own code's comments diff --git a/docs/no_toc/09-user_feedback.md b/docs/no_toc/09-user_feedback.md index acac271..bd9600d 100644 --- a/docs/no_toc/09-user_feedback.md +++ b/docs/no_toc/09-user_feedback.md @@ -7,14 +7,14 @@ output: html_document # Obtaining user feedback -This chapter will demonstrate how to: Understand the goals of obtaining user feedback. Construct user feedback methods that inform work on your tool. Create a plan for how to obtain user feedback for your tool. +This chapter will demonstrate how to: Understand the goals of obtaining user feedback. Construct user feedback methods that inform work on your tool. Create a plan for how to obtain user feedback for your tool. ## The goal of user feedback How do you know if your code is working? You test it and get feedback! Similarly, how do you know if your tool is working for your user? Ask them for feedback! -Tina the Tool Developer and Uri the Tool User both are looking at Tina’s tool that has “error” written all over it with a warning sign and is on fire. Uri the Tool User says Is this supposed to be on fire? Tina the Tool Developer pours a bucket of water on the fire and says Oh! Let me put that out! +Tina the Tool Developer and Uri the Tool User both are looking at Tina’s tool that has “error” written all over it with a warning sign and is on fire. Uri the Tool User says Is this supposed to be on fire? Tina the Tool Developer pours a bucket of water on the fire and says Oh! Let me put that out! ^[For all cartoons: Avataars by https://getavataaars.com/. Icons by https://thenounproject.com/ License CC BY-NC-ND 2.0. @@ -94,7 +94,7 @@ Make sure to check that they are okay with you recording the session (if that is A very important point from @Csontos2019: -Assure your participant that they shoulder no blame. Never let the participants helping you with their valuable feedback feel frustrated. +Assure your participant that they shoulder no blame. Never let the participants helping you with their valuable feedback feel frustrated. **[Step 4) Analyze & Report](https://uxstudioteam.com/ux-blog/usability-testing/#Step_4_Analyze_Report)** diff --git a/docs/no_toc/10-other-features.md b/docs/no_toc/10-other-features.md index c1ab238..9264159 100644 --- a/docs/no_toc/10-other-features.md +++ b/docs/no_toc/10-other-features.md @@ -7,7 +7,7 @@ output: html_document # Other helpful features -Learning Objectives. This chapter will demonstrate how to: Add other helpful features that help usability of a tool. Determine which of these features are most useful for your particular context. +Learning Objectives. This chapter will demonstrate how to: Add other helpful features that help usability of a tool. Determine which of these features are most useful for your particular context. ## The goal of these "other features" diff --git a/docs/no_toc/11-documentation-maintenance.md b/docs/no_toc/11-documentation-maintenance.md index 0f1c9e0..dffc096 100644 --- a/docs/no_toc/11-documentation-maintenance.md +++ b/docs/no_toc/11-documentation-maintenance.md @@ -7,7 +7,7 @@ output: html_document # How to keep your documentation up to date -Learning Objectives. This chapter will demonstrate how to:Identify good practices for documentation maintenance. Implement processes to help keep documentation up to date. +Learning Objectives. This chapter will demonstrate how to:Identify good practices for documentation maintenance. Implement processes to help keep documentation up to date. ## The goal of documentation maintenance @@ -15,7 +15,7 @@ Perhaps you’ve been making improvements or otherwise updating your software to But your work is not done yet. For each (user-facing) update you make to the tool, you should also make a documentation update. As a user, the only thing worse than having a tool with no documentation at all is having a tool with documentation that is out of date or otherwise incorrect. -Uri the Tool User is trying to use Tina’s awesome tool, but the documentation is now an ugly brown and out of date. The out of date documentation tells Uri to Look for the red square button! Uri has a question mark above their head because there is no red square button to be seen; only two circle buttons and a heart shaped button. +Uri the Tool User is trying to use Tina’s awesome tool, but the documentation is now an ugly brown and out of date. The out of date documentation tells Uri to Look for the red square button! Uri has a question mark above their head because there is no red square button to be seen; only two circle buttons and a heart shaped button. If documentation updates aren't prioritized, your tool can easily get several versions ahead leaving the documentation you carefully crafted rather useless and misleading. @@ -32,7 +32,7 @@ However you track your tasks, also track your documentation issues and always pa A very simple but all too common problem with out of date documentation is broken links! -The out of date documentation tells Uri the Tool User 404 page not found. Uri is not happy. +The out of date documentation tells Uri the Tool User 404 page not found. Uri is not happy. You can catch these broken links by manually clicking on all your links, but sometimes broken links will still slip through the cracks anyway! There are GitHub actions and other automated tools that can check your URLs for you. Take advantage of automation to do this for you so you can save your time an effort for other improvements to your tool and documentation! diff --git a/docs/no_toc/404.html b/docs/no_toc/404.html index a340997..f811c77 100644 --- a/docs/no_toc/404.html +++ b/docs/no_toc/404.html @@ -6,12 +6,11 @@ Page not found | Documentation and Usability - + - @@ -32,7 +31,6 @@ - @@ -50,11 +48,16 @@ - - + + + +