From 0004cdd903915b11989e19bcebe70cfb2bd1e780 Mon Sep 17 00:00:00 2001 From: Ryan Watters Date: Thu, 23 Feb 2017 08:51:51 -0600 Subject: [PATCH] Update few functions --- content/functions/delimit.md | 7 +++-- content/functions/dict.md | 6 +--- strategy.md | 41 +++++++++++++------------ themes/hugodocs/archetypes/functions.md | 5 ++- 4 files changed, 30 insertions(+), 29 deletions(-) diff --git a/content/functions/delimit.md b/content/functions/delimit.md index 38bd8f934..af88df7cf 100644 --- a/content/functions/delimit.md +++ b/content/functions/delimit.md @@ -2,8 +2,9 @@ title: delimit linktitle: delimit description: loops through any array, slice, or map and returns a string of all the values separated by a delimiter. -qref: d godocref: +qref: +workson: [] date: 2017-02-01 publishdate: 2017-02-01 lastmod: 2017-02-01 @@ -14,9 +15,9 @@ draft: false aliases: [] --- -`delimit` loops through any array, slice, or map and returns a string of all the values separated by the delimiter. There is an optional third parameter that lets you choose a different delimiter to go between the last two values. +`delimit` loops through any array, slice, or map and returns a string of all the values separated by a delimiter. There is an optional third parameter that lets you choose a different delimiter to go between the last two values in the loop. -Maps will be sorted by the keys, and only a slice of the values will be returned, keeping a consistent output order. +Maps will be sorted by keys, and only a slice of the values will be returned. This maintains a consistent output order. `delimit` works on [lists][], [taxonomies][], and [terms][]. diff --git a/content/functions/dict.md b/content/functions/dict.md index 57178a8e0..983802eb7 100644 --- a/content/functions/dict.md +++ b/content/functions/dict.md @@ -3,6 +3,7 @@ title: dict linktitle: description: godocref: +workson: [] date: 2017-02-01 publishdate: 2017-02-01 lastmod: 2017-02-01 @@ -11,10 +12,5 @@ categories: [functions] toc: false draft: false aliases: [] -notesforauthors: --- -## Example - -## Advanced Example - diff --git a/strategy.md b/strategy.md index be8ed595f..9f1cf2add 100644 --- a/strategy.md +++ b/strategy.md @@ -1,6 +1,6 @@ # Hugo Docs Concept Strategy, Tactics, and Requirements -> **Disclaimer:** Before any of my fellow content strategists banish me to content strategy hell, know that I *know* this is a *very schlocky* version of the documentation required for a real content strategy. +> **Disclaimer:** WIP. Before any of my fellow content strategists banish me to content strategy hell, know that I *know* this is a *very schlocky* version of the content strategy document. **Updated 2017-02-21** @@ -32,26 +32,26 @@ * limits the efficacy of Alogolia's document search feature through redundant content groups, headings, etc * does not leverage SEO for external search engines * does not leverage Hugo's more powerful feature (e.g., there is only *one* archetype); leveraging these features would help address the aforementioned shortcomings (i.e., scalability, consistency, and search) - * assumes a higher level of Golang proficiency than is realistic for newcomers to the Golang programming language or to web development in general. + * assumes a higher level of Golang proficiency than is realistic for newcomers to static site generators or to web development in general. An example of this is the sparsity of basic vs advanced code samples through the templating functions. * If you don't make it *very easy* for authors to contribute to documentation correctly, they will inevitably contribute *incorrectly*; * content modeling is king * go DRY (e.g., with shortcodes) - * set required metadata + * set required metadata (and use *archetypes*) * develop for contribution guidelines to dev *and* docs ## Goals -Hugo documentation should... +New Hugo documentation should... -* reduce confusion surrounding Hugo concepts as `list`, `section`, `page`, `content type`, etc. and thereby +* reduce confusion surrounding Hugo concepts; e.g., `list`, `section`, `page`, and `content type` and thereby * make it easier for new users to get up and running - * create better consistency and scalability for Hugo-dependent projects (viz., http://themes.gohugo.io) - * reduce frequency of questions surrounding said concepts in the Hugo Discuss Forum + * create better consistency and scalability for Hugo-dependent projects (viz., [themes.gohugo.io](http://themes.gohugo.io)) + * reduce frequency of questions surrounding said concepts in the [Hugo Discussion Forum](https://discuss.gohugo.io) * not require or assume any degree of Golang proficiency from end users; - * that said, Hugo can—and *should*—act as a bridge for users interest in learning Golang (e.g., by including `godocref` as a default front matter field. See [`archetypes/functions.md`][functionarchetype]. -* be easiest to expand and edit for *contributors**, but even easier to understand by *end users*. + * that said, Hugo can—and *should*—act as a bridge for users interested in learning Golang (e.g., inclusion of `godocref` as a default front matter field for all function and template pages. See [`archetypes/functions.md`][functionarchetype]. +* be easiest to expand and edit for *contributors** but even easier to understand by *end users*. * be equally accessible via mobile, tablet, desktop, *and* offline. -* not include an "extras" section because [this is the last place end users look to learn about Hugo](https://discuss.gohugo.io/t/site-with-different-lists-of-sections/5536/3). Instead all "extras" should be integrated into a new +* not include an "extras" section; i.e. since [this is the last place end users look to get up and running with Hugo](https://discuss.gohugo.io/t/site-with-different-lists-of-sections/5536/3). Current *Extras* should be integrated into the new defined content groupings and site architecture. * easily scaffold for future multilingual versions ## Audience @@ -66,11 +66,11 @@ Hugo documentation should... The SSG developer has -* limited proficiency in Git and DVCS +* basic proficiency in Git and DVCS * no to little proficiency in Golang * working proficiency in front-end development---HTML, CSS, JS---but not necessarily front-end build tools -* familiarity with at least one double-curly templating language (e.g., liquid, Twig, Swig, or Django) -* proficiency in the English language +* basic familiarity with at least one double-curly templating language (e.g., liquid, Twig, Swig, or Django) +* proficiency in the English language for the current version of the documentation * proficiency in other languages (for future multilingual versions) ### End User: Themes (i.e. blogger/author/hobbyist) @@ -78,8 +78,9 @@ The SSG developer has The themes end user has * limited proficiency in the command line/prompt -* proficiency in a supported content format (specifically markdown) -* access to static hosting but with limited proficiency in deploying a static website +* proficiency in one of the [supported content formats](https://hugodocsconcept.netlify.com/content-management/supported-content-formats/)(specifically markdown) +* access to static hosting; +* limited proficiency in deploying a static website ## Requirements @@ -87,7 +88,7 @@ The themes end user has - [X] Built with Hugo - [X] Performant (e.g., 80+ [Google Page Speed Score](https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fhugodocsconcept.netlify.com%2Fabout-hugo)) -- [X] Front-end build tools for concatenation, minification +- [X] Front-end build tools for concatenation, minification, of static assets - [X] Browser compatibility: modern (i.e. Chrome, Edge, Firefox, Safari) and IE11 - [ ] CDN - [ ] AMP? @@ -105,9 +106,9 @@ The themes end user has ### Editorial/Content - [ ] Basic style guide - - The style guide should server to facilitate a more consistent UX for the site but not deter contributors to the documentation -- [X] Contribution guidelines (see [working draft on live site](https://hugodocsconcept.netlify.com/contribute-to-hugo/contribute-to-the-hugo-docs/)) -- [X] Standardized content types (i.e, [see current archetypes](https://github.com/rdwatters/hugo-docs-concept/tree/master/themes/hugodocs/archetypes) + - The style guide should facilitate a more consistent UX for the site but not be so complex as to deter documentation contributors +- [X] Contribution guidelines (see [WIP on live site](https://hugodocsconcept.netlify.com/contribute-to-hugo/contribute-to-the-hugo-docs/)) +- [X] Standardized content types (see [WIP archetypes in source](https://github.com/rdwatters/hugo-docs-concept/tree/master/themes/hugodocs/archetypes) - [X] New content model, including taxonomies ([see tags page][tagspage]) - [ ] DRY. New shortcodes for repeat content (e.g., lists of aliases, page variables, site variables, and others) - [X] New site architecture and content groupings @@ -115,7 +116,7 @@ The themes end user has #### [Content Strategy Statement](http://contentmarketinginstitute.com/2016/01/content-on-strategy-templates/) -> The Hugo documentation increases the Hugo user base and strengthens the Hugo community by providing intuitive, beginner-friendly usage guides. Hugo documentation makes visitors feel excited and confident that Hugo is the ideal choice for all their static website development needs. +> The Hugo documentation increases the Hugo user base and strengthens the Hugo community by providing intuitive, beginner-friendly, regularly updated usage guides. Hugo documentation makes visitors feel excited and confident that Hugo is the ideal choice for static website development. #### [Editorial Mission](http://contentmarketinginstitute.com/2015/10/statement-content-marketing/) diff --git a/themes/hugodocs/archetypes/functions.md b/themes/hugodocs/archetypes/functions.md index 785b444e5..e355fc597 100644 --- a/themes/hugodocs/archetypes/functions.md +++ b/themes/hugodocs/archetypes/functions.md @@ -4,8 +4,11 @@ description: "" godocref: "" publishdate: "" lastmod: "" -tags: [] +godocref: +qref: +workson: [] categories: [functions] +tags: [] toc: false draft: false aliases: []