committing new version of jekyll doc theme -- 5.0, with some refinements to come with the documentation
This commit is contained in:
tomjohnson1492
@ -2,28 +2,27 @@
|
||||
title: Pages
|
||||
tags: [getting_started, formatting, content-types]
|
||||
keywords: pages, authoring, exclusion, frontmatter
|
||||
last_updated: November 30, 2015
|
||||
summary: "This theme uses pages only, not posts. You need to make sure your pages have the appropriate frontmatter. One frontmatter tag your users might find helpful is the summary tag. This functions similar in purpose to the shortdesc element in DITA."
|
||||
last_updated: March 20, 2016
|
||||
summary: "This theme primarily uses pages. You need to make sure your pages have the appropriate frontmatter. One frontmatter tag your users might find helpful is the summary tag. This functions similar in purpose to the shortdesc element in DITA."
|
||||
sidebar: mydoc_sidebar
|
||||
permalink: /mydoc_pages/
|
||||
---
|
||||
|
||||
|
||||
## Where to author content
|
||||
Use a text editor such as Sublime Text, WebStorm, IntelliJ, or Atom to create pages.
|
||||
|
||||
My preference is IntelliJ/WebStorm, since it will treat all files in your project as belonging to a project. This allows you to easily search for instances of keywords, do find-and-replace operations, or do other actions that apply across the whole project.
|
||||
My preference is IntelliJ/WebStorm, since it will treat all files in your theme as belonging to a project. This allows you to easily search for instances of keywords, do find-and-replace operations, or do other actions that apply across the whole project.
|
||||
|
||||
## Page names and excluding files from outputs
|
||||
|
||||
By default, everything in your project is included in the output. This is problematic when you're single sourcing and need to exclude some files from an output.
|
||||
|
||||
Here's the approach I've taken. Put all files in your root directory, but put the project name first and then any special conditions. For example, mydoc_writers_intro.md.
|
||||
|
||||
In your configuration file, you can exclude all files that don't belong to that project by using wildcards such as the following:
|
||||
By default, everything in your project is included in the output. You can exclude all files that don't belong to that project by specifying the file name, the folder name, or by using wildcards in your configuration file:
|
||||
|
||||
exclude:
|
||||
|
||||
- filename.md
|
||||
- subfolder_name/
|
||||
- mydoc_*
|
||||
- mydoc_writers_*
|
||||
|
||||
|
||||
These wildcards will exclude every match after the `*`.
|
||||
|
||||
@ -33,35 +32,32 @@ Make sure each page has frontmatter at the top like this:
|
||||
{% raw %}
|
||||
```yaml
|
||||
---
|
||||
title: Your page title
|
||||
tags: [formatting, getting_started]
|
||||
keywords: overview, going live, high-level
|
||||
last_updated: November 30, 2015
|
||||
summary: "Deploying DeviceInsight requires the following steps."
|
||||
title: Alerts
|
||||
tags: [formatting]
|
||||
keywords: notes, tips, cautions, warnings, admonitions
|
||||
last_updated: March 20, 2016
|
||||
summary: "You can insert notes, tips, warnings, and important alerts in your content. These notes are stored as shortcodes made available through the linksrefs.hmtl include."
|
||||
sidebar: mydoc_sidebar
|
||||
permalink: /mydoc_alerts/
|
||||
---
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Frontmatter is always formatted with three hyphens at the top and bottom. Your frontmatter must have a `title` value. All the other values are optional.
|
||||
Frontmatter is always formatted with three hyphens at the top and bottom. Your frontmatter must have a `title` value. All the other values are optional. If you omit them, the theme won't break.
|
||||
|
||||
Note that you cannot use variables in frontmatter.
|
||||
|
||||
The following table describes each of the frontmatter that you can use with this theme:
|
||||
|
||||
| Frontmatter | Required? | Description |
|
||||
|-------------|-------------|-------------|
|
||||
| **title** | Required | The title for the page |
|
||||
| **tags** | Optional | Tags for the page. Make all tags single words, with hyphens if needed. Separate them with commas. Enclose the whole list within brackets. Also, note that tags must be added to \_data/tags_doc.yml to be allowed entrance into the page. |
|
||||
| **tags** | Optional | Tags for the page. Make all tags single words, with underscores if needed (rather than spaces). Separate them with commas. Enclose the whole list within brackets. Also, note that tags must be added to \_data/tags_doc.yml to be allowed entrance into the page. This prevents tags from becoming somewhat random and unstructured. You must create a tag page for each one of your tags following the pattern shown in the tags folder. (Tag pages aren't automatically created.) |
|
||||
| **keywords** | Optional | Synonyms and other keywords for the page. This information gets stuffed into the page's metadata to increase SEO. The user won't see the keywords, but if you search for one of the keywords, it will be picked up by the search engine. |
|
||||
| **last_updated** | Optional | The date the page was last updated. This information could helpful for readers trying to evaluate how current and authoritative information is. If included, the last_updated date appears in the footer of the page.|
|
||||
| **summary** | Optional | A 1-2 word sentence summarizing the content on the page. This gets formatted into the summary section in the page layout. Adding summaries is a key way to make your content more scannable by users (check out [Jakob Nielsen's site](http://www.nngroup.com/articles/corporate-blogs-front-page-structure/) for a great example of page summaries.) |
|
||||
| **datatable** | Optional | Boolean. If you add `true`, then scripts for the [jQuery datatables plugin](https://www.datatables.net/) get included on the page. |
|
||||
| **video** | Optional | If you add `true`, then scripts for [Video JS: The HTML5 video player](http://www.videojs.com/) get included on the page. |
|
||||
|
||||
{{site.data.alerts.tip}} You can see the scripts that conditionally appear by looking in the _layouts/default.html page. Note that these scripts are served via a CDN, so the user must be online for the scripts to work. However, if the user isn't online, the tables and video still appear. In other words, they degrade gracefully. {{site.data.alerts.end}}
|
||||
|
||||
## What about permalinks?
|
||||
What about permalinks? This theme isn't build using permalinks because it makes linking and directory structures problematic. Permalinks generate an index file inside a folder for each file in the output. This makes it so links (to other pages as well as to resources such as styles and scripts) need to include `../` depending upon where the other assets are located. But for any pages outside folders, such as the index.html page, you wouldn't use the `../` structure.
|
||||
|
||||
Basically, permalinks complicate the linking structure significantly, so they aren't used here. As a result, page URLs have an .html extension. If you include `permalink: something` in your frontmatter, your link to the page will break (actually, you could still go to sample instead of sample.html, but none of the styles or scripts will be correctly referenced).
|
||||
| **last_updated** | Optional | The date the page was last updated. This information could helpful for readers trying to evaluate how current and authoritative information is. If included, the last_updated date appears in the footer of the page in rather small font.|
|
||||
| **summary** | Optional | A 1-2 word sentence summarizing the content on the page. This gets formatted into the summary section in the page layout. Adding summaries is a key way to make your content more scannable by users (check out [Jakob Nielsen's site](http://www.nngroup.com/articles/corporate-blogs-front-page-structure/) for a great example of page summaries.) The only drawback with summaries is that you can't use variables in them. |
|
||||
| **permalink**| Required | This theme uses permalinks to facilitate the linking. You specify the permalink want for the page, and the \_site output will put the page into the root directory when you publish. The page will appear inside a folder by the same name, with the actual page being index.html. Browsers will automatically show the index.html file inside of any folder, so permalinks avoid the .html extension with file names. Permalink names don't have to match your file names, but it might be easier to keep them in sync. If you don't use permalinks, Jekyll automatically uses the file name and folder path as the link.|
|
||||
| **datatable** | Optional | 'active'. If you add `datatable: active` in the frontmatter, scripts for the [jQuery Datatables plugin](https://www.datatables.net/) get included on the page. You can see the scripts that conditionally appear by looking in the \_layouts/default.html page. |
|
||||
| toc | Optional | If you specify `toc: none` in the frontmatter, the page won't have the table of contents that appears below the title. The toc refers to the list of jump links below the page title, not the sidebar navigation. You probably want to hide the TOC on the homepage and product landing pages.|
|
||||
|
||||
## Colons in page titles
|
||||
|
||||
@ -69,56 +65,53 @@ If you want to use a colon in your page title, you must enclose the title's valu
|
||||
|
||||
## Saving pages as drafts
|
||||
|
||||
If you add `published: false` in the frontmatter, your page won't be published. You can also move draft pages into the _drafts folder to exclude them from the build.
|
||||
If you add `published: false` in the frontmatter, your page won't be published. You can also move draft pages into the \_drafts folder to exclude them from the build. With posts, you can also keep them as drafts by omitting the date in the title.
|
||||
|
||||
{{site.data.alerts.tip}} You can create file templates in WebStorm that have all your common frontmatter, such as all possible tags, prepopulated. See {{site.data.mydoc.mydoc_urls.mydoc_webstorm_text_editor.link}} for details. {{site.data.alerts.end}}
|
||||
{{site.data.alerts.tip}} You can create file templates in WebStorm that have all your common frontmatter, such as all possible tags, prepopulated. See <a href="{{ "/mydoc_webstorm_text_editor" | prepend: site.baseurl }}">WebStorm Text Editor</a> for details. {{site.data.alerts.end}}
|
||||
|
||||
## Markdown or HTML format
|
||||
|
||||
Pages can be either Markdown or HTML format (specified through either an .md or .html file extension).
|
||||
|
||||
If you use Markdown, you can also include HTML formatting where needed. But not vice versa — if you use HTML (as your file extension), you can't insert Markdown content.
|
||||
If you use Markdown, you can also include HTML formatting where needed. But not vice versa — if you use HTML (as your file extension), you can't insert Markdown content in the file.
|
||||
|
||||
Also, if you use HTML inside a Markdown file, you cannot use Markdown inside of HTML. But you can use HTML inside of Markdown.
|
||||
|
||||
For your Markdown files, note that a space or two indent will set text off as code or blocks, so avoid spacing indents unless intentional.
|
||||
|
||||
If you have a lot of HTML, as long as the top and bottom tags of the HTML are flesh left in a Markdown file, all the tags inside those bookend HTML tags will render as HTML, regardless of their indentation.
|
||||
|
||||
## Where to save pages
|
||||
|
||||
Store all your pages inside the root directory. This is because the site is built with relative links. There aren't any permalinks or baseurls used in the link architecture. This relative link nature of the site allows you to easily move it from one folder to another without invalidating the links.
|
||||
You can store your pages in any folder structures you want, with any level of folder nesting. The site output will pull all of those pages out of their folders and put them into the root directory. Check out the \_site folder, which is where Jekyll is generated, to see the difference between your project's structure and the resulting site output.
|
||||
|
||||
## Page names
|
||||
|
||||
If this approach creates too many files in one long list, consider grouping files into Favorites sections using WebStorms Add to Favorites feature.
|
||||
I recommend prefixing your page names with the product, such as "mydoc_pages" instead of just "pages." This way if you have other products that also hae topics with generic names such as "pages," there won't be naming conflicts.
|
||||
|
||||
## Github-flavored Markdown
|
||||
Additionally, consider adding the product name in parentheses after the title, such as "Pages (Mydoc)" so that users can clearly navigate different topics for each product.
|
||||
|
||||
You can use standard Multimarkdown syntax for tables. You can also use fenced code blocks. The configuration file shows the Markdown processor and extensiosn:
|
||||
## Kramdown Markdown
|
||||
|
||||
Kramdown is the Markdown flavor used in the theme. This mostly aligns with Github-flavored Markdown, but with some differences in the indentation allowed within lists. Basically, Kramdown requires you to line up the indent between list items with the first starting character after the space in your list item numbering. See this [blog post on Kramdown and Rouge](http://idratherbewriting.com/2016/02/21/bug-with-kramdown-and-rouge-with-github-pages/) for more details.
|
||||
|
||||
You can use standard Multimarkdown syntax for tables. You can also use fenced code blocks with lexers specifying the type of code. The configuration file shows the Markdown processor and extensiosn:
|
||||
|
||||
```yaml
|
||||
highlighter: rouge
|
||||
markdown: kramdown
|
||||
kramdown:
|
||||
input: GFM
|
||||
auto_ids: true
|
||||
hard_wrap: false
|
||||
syntax_highlighter: rouge
|
||||
```
|
||||
markdown: redcarpet
|
||||
|
||||
redcarpet:
|
||||
extensions: ["no_intra_emphasis", "fenced_code_blocks", "tables", "with_toc_data"]
|
||||
```
|
||||
These extensions mean the following:
|
||||
|
||||
| Redcarpet extension | Description |
|
||||
| --------------|---------------|
|
||||
| no_intra_emphasis | don't italicize words with underscores |
|
||||
| fenced_code_blocks | allow three backticks before and after code blocks instead of `<pre>` tags |
|
||||
| tables | allow table syntax |
|
||||
| with_toc\_data | add ID tags to headings automatically |
|
||||
|
||||
You can also add "autolink" as an option if you want links such as http://google.com to automatically be converted into links.
|
||||
|
||||
{{site.data.alerts.note}} Make sure you leave the <code>with_toc_data</code> option included. This auto-creates an ID for each Markdown-formatted heading, which then gets injected into the mini-TOC. Without this auto-creation of IDs, the mini-TOC won't include the heading. If you ever use HTML formatting for headings, you need to manually add an ID attribute to the heading in order for the heading to appear in the mini-TOC. {{site.data.alerts.end}}
|
||||
|
||||
## Automatic mini-TOCs
|
||||
|
||||
By default, a mini-TOC appears at the top of your pages and posts. If you don't want this, you can remove the {% raw %}`{% include toc.html %}` {% endraw %} from the layouts/page.html file.
|
||||
By default, a TOC appears at the top of your pages and posts. If you don't want the TOC to appear for a specific page, such as for a landing page or other homepage, add `toc: none` in the frontmatter of the page.
|
||||
|
||||
If you don't want the TOC to appear for a specific page, add `toc: false` in the frontmatter of the page.
|
||||
|
||||
The mini-TOC requires you to use the `##` syntax for headings. If you use `<h2>` elements, then you must add an ID attribute for the h2 element in order for it to appear in the mini-TOC.
|
||||
The mini-TOC requires you to use the `##` Markdown syntax for headings. If you use `<h2>` elements, you must add an ID attribute for the heading element in order for it to appear in the mini-TOC (for example, `<h2 id="mysampleid">Heading</h2>`.
|
||||
|
||||
## Specify a particular page layout
|
||||
|
||||
@ -128,17 +121,13 @@ You can create other layouts inside the layouts folder. If you create a new layo
|
||||
|
||||
## Comments
|
||||
|
||||
Disqus, a commenting system, is integrated into the theme. In the configuration file, specify the Disqus code for the universal code, and Disqus will appear. If you don't add a Disqus value, the Disqus code isn't included.
|
||||
|
||||
## Posts
|
||||
|
||||
This theme isn't coded with any kind of posts logic. For example, if you wanted to add a blog to your project that leverages posts, you couldn't do this with the theme. However, you could easily take the post logic from another site and integrate it into this theme. I've just never had a strong need to integrate blog posts into documentation.
|
||||
Disqus, a commenting system, is integrated into the theme. In the configuration file, specify the Disqus code for the universal code, and Disqus will appear. If you don't add a Disqus value, the Disqus form isn't included.
|
||||
|
||||
## Custom keyboard shortcuts
|
||||
Some of the Jekyll syntax can be slow to create. Using a utility such as [aText](https://www.trankynam.com/atext/) can make creating content a lot of faster.
|
||||
|
||||
For example, when I type `jif`, aText replaces it with {% raw %}`{% if site.platform == "x" %}`{% endraw %}. When I type `jendif`, aText replaces it with {% raw %}`{% endif %}`{% endraw %}.
|
||||
For example, with my aText configuration, when I type `jlink`, aText replaces it with {% raw %}`<a href="{{ "/page" | prepend: site.baseurl }}">page</a>`{% endraw %}.
|
||||
|
||||
You get aText from the App Store on a Mac for about $5.
|
||||
You get aText from the App Store on a Mac for about $5. However, the Mac Store version of aText won't work on Mac OSX El Capitan due to sandbox security restrictions, so you need to download the app outside of the App Store to make it work.
|
||||
|
||||
There are alternatives to aText, such as Typeitforme. But aText seems to work the best. You can read more about it on [Lifehacker](http://lifehacker.com/5843903/the-best-text-expansion-app-for-mac).
|
||||
There are alternatives to aText, such as Typeitforme. But aText seems to work the best. You can read more about aText on [Lifehacker](http://lifehacker.com/5843903/the-best-text-expansion-app-for-mac).
|
||||
|
||||
Reference in New Issue
Block a user