future development checklist

[jlnrrg]

I just found your piece of art and I am head over heals.
Even though you write to have no real ambition to continue the project,
I still like to provide a checklist of interesting features so me or other people can add wish and contribute ourselfes.

appearance

• dark mode
• include the picture in the overview
• overview page -> a better limitation view for categories (useful for a lot of recipes)
• overview page -> change title + text to a centered with boxconstraints
• recipe page -> add an highlight point, which expresses visually where to take extra caution
• do not create a scrollable list for instructions (I noticed this by using 8 steps, and the last one was empty)

functionality

• powerful search
  • search by label
  • navigate with arrow keys
• a language extension (e.g. strawberrysmoothie_en.md), for multilingual support
• on generation generate a "cookbook" pdf with pandoc that can be downloaded directly (+ single pages based on recipe)
• overview page -> extend <a></a> over whole ListItem and not just the title

content

• content, which won't be publicly available
• a general overview of all required ingrediences (not autogenerated),
  which has no instruction number (like chowdown
• support of deep _recipes folders which translate to categories
• change of ✓ in markdown files to simple "x"
• Adding title attributes for the icons on the index page. Minor, but relevant for accessibility.

generation

• github action to auto generate on new recipes added (possibly using this)
• image tag in header, which downloads the image on generation
  and adds a visible source in the html output (bc copyright)
• change to hugo (it is no intend to bash 😅, and more a note for me to consider in the future)
• allowing the hRecipe json as input and providing a parser for this site's recipes

other

• spreading the word, by contributing to different awesome lists like this and that
• Simplify the code in build.sh dealing with uncategorized recipes.
• add a list of all supported md header settings in the README.md

Feel free to add anything or even edit my post for convenience sake.

[doersino]

Hiya! First off, thank you for taking the time to compile such an exhaustive list – it always makes me really happy when something I publish gets folks excited!

There are some points that I'd indeed like to tackle (likely this coming weekend):

• Navigating the search results using the the ↑/↓ and enter keys.
• At least in search results, extending <a></a> over the whole list item and not just the title, along with a slightly different background color on hover. (Inside the main portion of the index page, the user could have added their own links as part of recipe descriptions. Wrapping the link to the recipe around the whole list item would render such links inoperable.)
• Optionally displaying each recipe's image on in the index page, this will be a setting in config.yaml and disabled by default.
• Adding more flavor-related labels (like "spicy"), along with nutrition labels – see Support for more out of the box attributes #7 for a discussion thereof. For maximum "user-definable-ness", nutrition labels could be represented as a list in the YAML font matter, like this:

  nutrition:
    - 100 calories
    - 10 g protein
    - 20 g carbs
    - ...
  

• Documenting the supported YAML front matter keys/fields in README.md. (Waiting for Support for more out of the box attributes #7 to resolve first.)
• Possibly subheadings in recipes (the question is whether they should restart the step numbering or keep it going – I'm leaning towards restarting, that seems like it would fit more use cases than the alternative) and, as you've suggested ("highlight point"), a way of drawing attention to (part of) an instruction (I'm envisioning three nested blockquotes >>> as the markup for this).
  • Level-2 subheadings (<h2>, ##) now reset step numbering. For reasons I believe to be non-work-around-able without proposed but nowhere-implemented CSS features, recipe authors need to add a horizontal rule after a heading and, more importantly, not add one before a heading, which precludes headings right at the start due to the horizontal rule hardcoded in _templates/recipe.template.md. (If that horizontal rule were a part of the Markdown document instead of being hardcoded, that wouldn't be a problem, but then recipes would ordinarily need to start with ---, which seems really inelegant to require for the common case.)
  • Three nested blockquotes >>> now produce a paragraph with a little flag icon and dark red text. Note that you can use this as part of an instruction, it doesn't need to be a stand-alone step:

    > Pour some water into a saucepan, place on high heat and bring to a rolling boil
    >
    >>> Don't burn the water!

• Possibly dark mode. Since SVGs embedded via <img> tags aren't part of the DOM, I'd probably have to inline the icons for this, which is kind of annoying.

In addition, some things that weren't on your list:

• Simplify the code in build.sh dealing with uncategorized recipes.
• Adding alt texts for the icons on the index page. Minor, but relevant for accessibility.

The following is already possible:

• Changing of "✓" in Markdown files to a simple "x" – in fact, any non-empty and (if you've got a fairly recent version of Pandoc) non-falsey value will have the same effect.

And I'm sorry to disappoint you: Most of your other suggestions are, as far as I'm concerned, outside the scope of this project:

• As I've written in the readme, I prefer the relevant-ingredients-next-to-instructions structure over the more common all-ingredients-first-then-a-block-of-instructions approach you're suggesting. That's part of the reason why I've built this tool instead of simply using an already-existing one. Maintaining both "modes" in parallel would be more work and, more importantly, it would reduce what I'd call the "dogfooding coverage".
• Any integrations with (or importing of, or exporting to) alternative recipe formats aren't something I'd personally utilize, so they're out for the same reasons.
• A GitHub action for deployment is something any user of this tool could build for their own instance if desired.
• I feel like built-in multilingual support (with little flag icons on recipe pages, I support) isn't super relevant in the "personal recipe collection" use case this tool is built for.
• Generating a "cookbook" PDF with Pandoc that can be downloaded directly is a cool idea, but then I'd have to deal with LaTeX for styling – and my falling out of love with LaTeX was part of the impetus for building this tool. 😉

All of the above shouldn't keep anyone from forking nyum and making it their own, though – it's deliberately simple and licensed under the MIT License, so there's very few limits on what you can do. You could take the design and turn it into a Hugo theme, for instance.

Finally, I'm afraid I don't quite understand what you mean by "overview page -> a better limitation view for categories (useful for a lot of recipes)". It sounds intriguing, could you elaborate?

[jlnrrg]

1. relevant ingredients. First of all, I really like this "new" approach with listing the ingredients necessary for each step, I see that making cooking easy, so it's great. from a shopping perspective I'd encourage at least the option to add a whole list of ingredients
2. multilingual support. I partly agree, as most recipes will be for my own usage, I can keep them in my mother-tongue (german), but I also have friends from other countrys, I would like to share recipes with, then it would be a nice to have to have a language switch.
3. latex pdf support. I can understand that, if you are up for the inclusion of a button somewhere, then I can handle the LaTeX styling. It was more a general testing for interest.
4. forking. I am aware and will do so and then submit pr like every good citizen 😀
5. "overview page limitation view". Right now the overview page is just a single list grouped by the categories, which works for 4 recipes, but imagine having 40 or more, then a folder structure or smth accordingly which groups the categories might feel beneficial.
   • then one could also click on the breadcrumbs and get an overview of the recipes

[doersino]

Closing since I've now addressed all the points laid out in my comment (and more).

If any of your remaining suggestions is really important to you, feel free to file them as separate issues!

[jlnrrg]

Thanks for your efford.
This was only a collection as I noticed a bunch of stuff in the beginning. So I totally agree with future single issues 😄.