Make Blog Easier to Navigate/Search

[joepavitt]

Story

No response

Description

With all the additional (and regular) great content that is now being added to our blog, it's becoming trickier to navigate and search our blog.

Proposed Solutions/Improvements:

• Different Tile Styles: Part of the challenge is a visual scanning issue, in that the article tiles are all very similar, we could look at different colour combinations, or auto-generated tile patterns for different types of articles (e.g. Releases, Funding Announcements, Inside FlowForge)
• Tagging/Filtering, Each article is given one (or multiple) category/topic, permits us to venture into wider content types (e.g. Onboarding a non-techy to GitHub) - I really like how PostHog do theirs:

inspiration: https://posthog.com/blog

[iskerrett]

I agree each blog needs to have a unique graphic that includes words that relate to the blog topic. The current homogeneous tile format doesn't add any value.

FWIW, I don't really like the posthog graphics since they don't actually convey any information about the blog topic.

[joepavitt]

If you have any blogs that you've seen that you like @iskerrett please share them here so that I have something to take inspiration from.

[iskerrett]

I like the gitlab blog and I more familiar with HiveMQ .

Doing unique graphics for each blog post is more time consuming but they can also be reused for social media.

[joepavitt]

https://posthog.com/blog/dynamic-open-graph-images

PostHog have a really neat way of doing this for the socials. Auto-generated OpenGraph tiles for each post. A nice balance of procedural to save time, but personal/unique to each post to make it more shareable/engaging.

Will reinforce though, I completely agree with your comment re: their graphics

I don't really like the posthog graphics since they don't actually convey any information about the blog topic.

[iskerrett]

I agree it is a good idea to automate the creation of OpenGraph images. However, if I understand correctly the graphics are pretty static but they overlay unique text based on the page. This is a good approach but it still creates similar tiles that are not differentiated if all put on the same page, ie the blog home page.

[joepavitt]

Think there can be some middle ground whereby we have a few tiles/themes for different categories of article, e.g. a Node-RED themed tile for NR-focussed articles, a fixed style for Release Announcements, etc.

Then, we use the relevant theme, with article preview/title for the images.

[joepavitt]

Exploring tile ideas/designs: https://www.figma.com/file/hXDN5PnY3TmeQSv3n7Hna5/FlowForge-Website?node-id=817%3A2776

preview:

Will add some layout options in the next week or two.

[joepavitt]

Thinking about the categories of content that we will publish, so far, given we already have published, we have:

• Community Newsletter
• Node-RED Tutorials
• FlowForge Tutorials
• Release Announcements
• Inside FlowForge: opportunity for FF employees to talk about internal practices and reflections, e.g. tools we use, experiences we've gained, ideas we've put into action
• News
• Customer Stories

[joepavitt]

proposal:

[joepavitt]

Have spent 4 hours on this today, and am concluding that this is not possible with Eleventy (using Edge functions, etc.) - this should have been a few minutes of work. Until we move away from Eleventy, this will not be a feature we can add.

[joepavitt]

progress is available on https://github.com/flowforge/website/tree/blog-nav-tags

• I added the filter buttons & respective CSS classes
• Managed to get blog.posts added to the Eleventy Edge globalData
• Could access the edge.url.search to get the query params (if present)
• Could produce an edge-rendered for-loop for the global edge data

Blockers:

• No access to many eleventy filters tat we're reliant upon when edge rendering
• No access to the GenerateSVGPost functionality on edge either

[joepavitt]

ZJ's 💡

• use `/blog/
• Make blog a component
• Duplicate the blog page multiple times, each endpoint available.
• Buttons then navigate to each child page

[joepavitt]

Just spent another 2 hours on this given @ZJvandeWeg's idea and still concluding that it isn't possible with Eleventy. Tried:

• {% include %} - automatically passes context to the included HTML, which meant we could loop, but async shortcodes do not work and trip the rendering (commented on an old Eleventy issue here)
• {% import %} - Requires use of macros (but they don't support async), set (doesn't support async) or setAsync (see here) which doesn't doesn't work at all, even with a Hello World example.
• {% extend %} - more appropriate for when the child elements have the variation and parent is static, for us, the child elements (blog articles/tiles) are consistent, and so we'd still require a lot of duplicated code for each blog tag.

all had their individual downfalls, and again led me to wanting to leave Eleventy behind asap. Developer experience is awful and is taking up days of my time weekly.