Significant Website Implementations

[harrymkt]

Website

Hello everyone. This discussion is to ask all of you about the website update I'm about to implement into, and so since contribution guideline suggests to open a discussion or an issue for significant changes, so? Here I am.

I started using Cobalt not long ago, but I found it easy and efficient to use. I was also able to quickly understand Liquid, its templating language.

Here is a list of features and updates I could implement on the website. Please advise me on which features and updates to prioritize.

Pagination (recommended)

The pagination feature is simply put, posts being separated into pages. As the number of blog posts grows, having a pagination feature becomes beneficial.

• Pagination can sort posts by published dates or titles.
• You can define how many posts are displayed on a page.
• You can define permalink syntax, for example, nvgt.gg/blog/post-name, or for pages starting at 2, nvgt.gg/blog/all/2/post-name.

Custom Js For Published Date

A JavaScript file can be added to display published dates in the user's local timezone, regardless of the timezone set for the posts.

Reading Time

It is also beneficial to have a Reading Time feature in posts, so readers can know the approximate time it will take to read them.

• Can define the average number of words read per minute (WPM).

Blog Search

A search feature can also be added, but it is not necessarily required. The search feature is not built-in Cobalt. It is used by a conpination of 2 Liquid scripts, one which generates the JSON file containing the posts, and one for the actual search input. I found the search feature while I'm browsing about the Cobalt on the internet.

If any of you have suggestions for more features and updates, please feel free to leave a comment.

[samtupy]

Hi,
Thanks, these sound like cool additions!

As for pagination, I'm totally fine with that so long as a post's permalink will never change. For example I completely agree with the idea of viewing the second page of the posts by accessing nvgt.gg/blog/page/2/ or anything like that, but if the page number becomes part of the permalinks for actual posts themselves, the link would no longer be a permalink, as far as I know the perma in permalink stands for permanent. If a post on page 2 suddenly slides to page 3 because it's older, but the link to the post used to be nvgt.gg/blog/page/2/post-slug, now such a link would become invalid as it would change to nvgt.gg/blog/page/3/post-slug, breaking any external links to the post. So as long as this potential issue can be avoided, I'd be completely OK with you adding pagination.

Displaying local timezone and average read time would be cool as well and sound pretty straight forward, please feel free! Another possible suggestion would be if you can make it so that the publish date appears on the post pages themselves instead of just on the post listings, but without making the individual post markdown files more complicated themselves, that would be cool. If I or someone else wants to make a new post, I don't want them to have to bother with including the publish date display, so this should only be done if it can be somehow integrated into the general post template.

I also don't mind if we add a posts search facility. We already have cobalt generating a jsonfeed, however this might not be enough as it only generates small excerpts of the posts. If there is a way to get cobalt's jsonfeed generator to write out the entire post I would recommend we do that and then use this jsonfeed as input to such a search facility, however generating a custom json file is probably fine so long as it is done transparently at build time.

I look forward to seeing these in action!

[harrymkt]

Hello.

Regarding the post permalink, it will never change. Only the page number accessed will change. For example, blog/all/2 will access page 2 and display the posts that are within that page. The permalink for posts will be blog/post-name, regardless of which page is being accessed. If a post is moved to page 3 because it is older, it will be displayed on page 3, but the blog/post-name permalink will not be affected by its page structure.

As for the automatic published date, if I understand correctly, it is not possible because Cobalt requires the published date to be provided in the markdown file's YAML section. We can automatically set the date, but it will refresh each time Cobalt builds a new version of site update, so all posts will share the same dates because of that. Therefore, it is necessary to provide the published date metadata within the posts themselves.

[day-garwood]

I must admit I'm not a big fan of the reading time idea.

We all have different reading speeds and suggesting a reading time makes assumptions about the reader that I believe we really have no right to assume. This is especially true for blind users who use TTS and/or braille.

However I do think it's important that users know how long the post is. So I would propose an alternative of having a word count rounded to the nearest decimal unit of words. So an 83 word article would estimate 80 words. A 246 word article would estimate 200 words. And a 3850 word article would round it to 4000 words (although that's less a blog post and more an essay).

Just my thoughts.

[TheQuinbox]

I'd tend to agree, while I don't think average reading time would necessarily hurt anything I find them to always be woefully inaccurate as someone running fast Eloquence. In other words, I'm not opposed, just not sure on the usefulness. Word count or a similar metric might be more helpful.

[braillescreen]

I'd certainly enjoy a word count display.

[harrymkt]

Hello @braillescreen, @TheQuinbox, @day-garwood.

I've currently implemented in #95 pull request.
The implementations are both reading time and words count. The words count is not rounded, meaning it will be displayed, for instance, Total words: {{word_count}}, which is estimated to read within {{fraze}}, outputs Total words: 940, which is estimated to read within 4 minutes.

[samtupy]

Hi,
Thanks for the work thus far!
I think that showing both word count and reading time is a good compromise between anyone who might find such a metric helpful Vs. anyone who knows that it's bunk in their unique situation and wishes to ignore it. As long as the word count is displayed I think that's the most important, with a reading time feature being a convenience for those who find that their reading speed tends to match with such displays. In other words I think the current implementation offered in #95 should do the trick.
*** note edit after this point:
I made a mistake regarding the published dates, at some point on this website the dates were only showing on the post listings, not on the posts themselves. Apparently I fixed this at some point, and then completely forgot that I'd taken care of it, and thus suggested that you fix something that isn't broken. I need to be more thorough. My mistake, I apologize!
I'll get this properly reviewed and merged soon. Thanks again!

[samtupy]

This has been merged in aece4ab and then was gotten fully working in 5ea5ded, so we'll go ahead and close this thread. Thanks!