FrontierNav Weekly: 14 September 2020

Changes

• Existing guides can now be edited and deleted.
• Videos can now be embedded in Markdown-enabled content like Discussions and Guides. (more below)
• Phrases can now be highlighted in Markdown-enabled content to create Searchable Links. When clicked, it'll open up Universal Search for quick access to data. (more below)
• Added a footer to most pages to indicate licenses.
  • I'll add a Contributors page soon to give credit to data sources and contributors and link to it in the footer.
• Moved all social media links to the footer.
• Moved all documentation to GitHub for easier management until FrontierNav is more capable of hosting it.
• Fixed ability to created empty Change Requests and redirected to Discussions for suggestions. (more below)
• Fixed middle-click and right-click on links being overidden but doing nothing.
  • If there's no custom logic, it'll just do default browser behaviour.
• Games now use thumbnails where appropriate rather than cover art.
  • This should make it easier to identity games in small areas like the navigation.
• Fixed Play State defaulting to "Playing" rather than "Plan to Play" for games without a release date.
• The feed used for "Community News" is now a standard JSON Feed.
• Updating sitemaps no longer requires a code deployment. (more below)
• Organised internal build configuration for easier maintainence.

Support the project

Thank you to this week's patrons!

If you would like to support FrontierNav, please consider donating on Patreon. Doing so helps fund development and keeps the project going. Thank you.

Embedded Content

One of the ways to make Community Guides more interactive is to embed interactive elements like maps. To get that ball rolling, I started with more simple embeds: videos.

The aim is to enable interactive elements without getting bogged down by custom formats and markup. Ideally any textual content on FrontierNav should be easily exportable into plain text so that contributors have the option to write their guides in whatever format they want. I don't want to be in a situation where I'm maintaining a custom markup language or JSON WYSIWYG schema.

So, I've gone with empty links to indicate embedded content. That is:

[](https://youtube.com/...)

The [] indicates to FrontierNav to fill the content in given the link.

There are downsides to this approach, but I plan to improve it as I work things out. For example, rendered in Markdown, this would just be an empty <a> tag with a href; doesn't make much sense outside of FrontierNav's renderer.

Searchable Links

Similar Embedded Content, for Searchable Links the content is provided but the link is not:

[Small Potion]()

The () indicates to FrontierNav to find the link given the content. This is kind of like how Wikis work with [[A Page]] though as it triggers a search it's a bit more flexible with data changes. Since Community Guides can be created by anyone without a maintainer, having links work after data changes is important.

I was thinking of making the search that's triggered behave like "I'm feeling lucky" and just open up the first result automatically. This would make Searchable Links seemless and give the impression of a pre-defined link. But the current Universal Search system doesn't support that easily. It's definitely something to keep in mind as I further improve search capabilities.

Change Request Confusion

It looks like someone misunderstood the Change Request process and ended up sending over an empty Change Request that was more of a suggestion to fix some data. I renamed "Merge Requests" to "Change Requests" recently, and didn't account for that confusion.

A "Change Request" can be easily misunderstood to be along the lines of a "Feature Request". That is, "I want this changed", rather than "I want my changes merged (applied)". I don't know if this'll be a common problem, but in case it is, I've removed the ability to create empty Change Requests (which was a bug anyway) and placed a notice asking people to use Discussions for any suggestions. If it continues to be confusing, I'll just rename it back.

Search Engine Optimisation

Back on the topic of SEO again. I noticed Bing/DuckDuckGo don't index FrontierNav at all. I knew that was the case, they don't execute JavaScript. It just kind of sucks. So I went back to some SEO improvement I mentioned a few months back. Namely, Link Previews.

I made some progress by moving out Sitemap generation from the rest of the deployment process. Link Previews will use a similar system. I still need to think of a good way to generate and maintain thousands of them while avoiding the downsides introduced when I last looked into it.

Next Up

Last week I mentioned adding the ability to draft and unpublish guides, but thinking it through, it's not really needed. Guides can be edited and deleted easily enough so those use cases are covered.

Next up, I'll be integrating all the current Markdown features with the Data Tables to support Wiki-like pages. I'm not 100% sure I want to introduce the opinionated nature of Wiki pages with the fact-based Data Tables so I might keep them separate internally. Wiki features can be part of the community database like discussions and guides. In a way they're more like "stickied" guides for individual entities. However, while there can be many guides created and maintained by individuals, the Wiki is more of a single point of collaboration, so I'll need to have a similar Change Request process. In which case, it makes sense to use Data Tables as a starting point to avoid re-implementing the same process.

Thanks for reading.