Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upMake external tutorials a first class citizen #449
Comments
This comment has been minimized.
This comment has been minimized.
You are right, refresh is pointless without I'll ask Forestry to update the post with your suggestion. |
This comment has been minimized.
This comment has been minimized.
I know we are pretty smart about live-reloading changes in JSON and images etc. inside bundles ... |
This comment has been minimized.
This comment has been minimized.
Alright, the post has been updated. Back to original topic, I think it could be very helpful to add at the end of a documentation page a very short selection of "good reads" which dive in detail into the given topic/feature. I think it may be more efficient into helping users than adding yet another section to the doc site listing good reads unrelated to each other. @budparr I wonder if you have design ideas, suggestion from other sites? |
This comment has been minimized.
This comment has been minimized.
I don't see anything wrong with linking to things at the end of a post, but there's a risk that outside posts go stale or disappear (having collected hundreds of links over the years, I can you can count on that. That was partly why I suggested "guides" where tutorials can be curated. They're not mutually exclusive, of course, and something like the post at Forestry would not be appropriate as a guide. Nonetheless, we definitely need to get people more how-tos and clear examples, that's the number one thing I hear from people. |
This comment has been minimized.
This comment has been minimized.
I was more thinking in the line of a "see also" box in the middle somewhere, i.e. near the relevant section. I have done it in one or two places with the "note" shortcode, but I feel it gets a little bit buried. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I think better in a data file then related back. That seems more manageable and makes articles useful on more than one page. |
This comment has been minimized.
This comment has been minimized.
No, my gut feeling is still a shortcode, e.g. 1 link to a relevant article inside a section/paragraph. |
This comment has been minimized.
This comment has been minimized.
Yes I see your point. Beside it allows the editor to add a short sentence describing how this reference can help the user at this point in the doc. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@budparr This came up earlier in a separate thread too. I believe that data files are a better way to do this. That way you have a single point of controlling all external post references, rather than going within each doc file and manually adding it. The data file can have a simple structure like:
Then in the Single point of control
|
This comment has been minimized.
This comment has been minimized.
I think the shortcode vision works great because, the post in question may not be about the whole page presently being read by the user. In this sense, we should design a sort of unique Read onFor more information on how to use whatever in such context.
|
This comment has been minimized.
This comment has been minimized.
I definitely see your point. The two approaches aren't mutually exclusive, but ultimately, we just need to find ways to make more concrete examples available and give users an easy way to find them. |
This comment has been minimized.
This comment has been minimized.
stale
bot
commented
Nov 29, 2018
This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help. |
bep commentedApr 13, 2018
Like this:
https://forestry.io/blog/build-a-json-api-with-hugo/
We need a better way to link to those -- a standard way, more visible.
Which describes custom output formats much better than I did when I wrote the first version of the one on gohugo.io.
And @regisphilibert
I think the correct advice would be to run with
--disableFastRender
. But I kind of don't understand it. The liverload doesn't work for JSON -- but a CTRL + R should?