images path update

docs/general-style-guide.md

@@ -13,18 +13,18 @@ The guide will focus on the following to achieve this:
 People scan in an `F` pattern.
 We can leverage and place the most valuable information in the their scanning path to ensure that they at least get an overview of the contents while scanning.
 We can do that by:
- - **Clear hierarchy between titles and content text** 
+ - **Clear hierarchy between titles and content text**
     Ensure that section titles have a noticeably larger font-size than the content.
     Use markdown headings to create an hierarchy throughout the document.
 
- - **Keep section titles short and concise** 
+ - **Keep section titles short and concise**
 
- - **Subject first for informational sections** 
-    Sections describing special considerations can put the subject first like `Multiplexed (cellhash) libraries` 
+ - **Subject first for informational sections**
+    Sections describing special considerations can put the subject first like `Multiplexed (cellhash) libraries`
 
-- **Action first for instructive sections** 
-    When titling sections based on steps users need to take to setup/ troubleshoot, put what action they are expected to take first, like downloading, or configuring. 
-    Example: `Configure the metadata file` 
+- **Action first for instructive sections**
+    When titling sections based on steps users need to take to setup/ troubleshoot, put what action they are expected to take first, like downloading, or configuring.
+    Example: `Configure the metadata file`
 
 
 ## Organizing the information
@@ -38,16 +38,16 @@ When writing instructive documentation, tuck away the details like advanced conf
 
 The example below describes the target file organization, presenting the general case first and then presenting how to organize files for specific cases.
 
-   ![general-to-specific](images/go-from-general-to-specific.png)
+   ![general-to-specific](style-guide-images/go-from-general-to-specific.png)
 
 
 ## Using lists
 
-Use bullets to emphasize information and make it easier to scan. 
+Use bullets to emphasize information and make it easier to scan.
 
 Use it for describing:
 - Requirements
-- Steps for setting up 
+- Steps for setting up
 - Features
 - Lists of inputs or output files
 
@@ -62,30 +62,30 @@ Use the buttons for links critical for users to continue on to the next stage li
 
 In the example below, presenting the link to the example metadata file as a button makes it easier for the user to find the link.
 
-   ![why-add-buttons](images/why-add-buttons.png)
+   ![why-add-buttons](style-guide-images/why-add-buttons.png)
 
 
 ## Using tables
 
-Use tables to describe 
+Use tables to describe
 - Variables
 - Parameters
 - Metadata columns.
 
-![describe-metadata-fields](images/describe-metadata-fields.png)
+![describe-metadata-fields](style-guide-images/describe-metadata-fields.png)
 
 ## Using code blocks
 
 Use code blocks for commands and snippets that users can copy and reuse for themselves.
 
-![command-in-code-blocks](images/command-in-code-blocks.png)
+![command-in-code-blocks](style-guide-images/command-in-code-blocks.png)
 
 
 ## Use visual aids
 
 Use illustrations to quickly summarize concepts, processes, and pipelines.
 
-Use screenshots to help explain how users need to navigate complex interfaces. 
+Use screenshots to help explain how users need to navigate complex interfaces.
 
 # Language
 
@@ -94,21 +94,21 @@ We can write documentation which is easy to understand by incorporating the belo
 ## Active voice and present tense
 
 The use of an active and present tense will make the documentation direct and simple.
-Active voice makes it clear who is taking which action. 
-Present tense gives the sentences an assertive feel. 
+Active voice makes it clear who is taking which action.
+Present tense gives the sentences an assertive feel.
 This is especially important when writing instructions.
 
 ## Use the simplest form of the word
 
 Use everyday language as much as possible.
 
-Try to use the simplest synonym when possible. 
+Try to use the simplest synonym when possible.
 
 For example, instead of `utilize`, say `use`.
 
 ## Short sentences
 
-Shorter sentences help breakdown complex ideas into bite-sized chunks which help users absorb information better. 
+Shorter sentences help breakdown complex ideas into bite-sized chunks which help users absorb information better.
 
 ## Short Paragraphs
 
@@ -125,7 +125,7 @@ Jargon is unavoidable but try to use terms that our audience will know.
 For example, using `PRs`, `runs` is acceptable (and necessary).
 Avoid using jargon outside of our audience's wheelhouse like `deploy`.
 
-In cases where using an unfamiliar term is unavoidable, add an additional sentence briefly explaining what it means in this context. 
+In cases where using an unfamiliar term is unavoidable, add an additional sentence briefly explaining what it means in this context.
 If the concept is complex, link out users to learn more about it.
 
 ### How to refer to users, ourselves, and others
@@ -144,7 +144,7 @@ You will need to make a copy the example notebook and create your analysis.
 
 ## Instructive
 
-We must ensure that our instructions are clear about what the user is expected to do vs what will done for them by the Data Lab or other contributors. 
+We must ensure that our instructions are clear about what the user is expected to do vs what will done for them by the Data Lab or other contributors.
 
 It is especially important to use active voice and present tense when writing instructions.
 
@@ -155,9 +155,9 @@ Here are some tips to ensure clear and easy-to-understand instructions:
 Choose the most easy-to-follow way to do the task and provide instructions for that method.
 
 Avoid showing users multiple ways to do a task.
-It will only confuse them. 
+It will only confuse them.
 
-Don't show how power users might complete the task, even if that is easier. 
+Don't show how power users might complete the task, even if that is easier.
 
 For example, if the user can set configurations either with a file or with a command, choose one method and provide instructions only for that.
 
@@ -167,7 +167,7 @@ When describing exceptions, be clear about the case and what actions users need
 
 Avoid things like 'Depending on the functions, you can do Y."
 
-Instead say, "When you use function X, do Y and when you use function A, do B." 
+Instead say, "When you use function X, do Y and when you use function A, do B."
 
 ### Everyone loves a good example