Now that I'm spending more time on FrontierNav, I did a lot in July so looking back and writing it all up is draining.
I'm also writing the weekly reports making it difficult for me to filter out stuff I've said in the previous month's report and stuff I've said in the previous weekly reports.
So, I may decide to stop writing monthly reports in the future. Instead, I'll link to the weekly reports and related articles as a summary.
Let me know what you think.
The user interface for FrontierNav has been overhauled. Apologies in advance if the changelist lacks context. The main thing to takeaway is that a lot has changed. To give things more context I'll have to go through the old user interface and take before-and-after screenshots which is a lot of work.
The aim of the overhaul is to provider faster and consistent navigation and in the future support multiple visualisations on the same page.
Navigation bar is now entirely on the left.
Moved search to a button which activates a search overlay.
Added a "CTRL + P" shortcut to toggle search.
Sidebar is now available on all pages.
Removed overlaying behaviour of sidebar on desktop.
Sidebar now pushes content to the right, so it doesn't cover content.
Removed toggle, forward and back "tabs" on sidebar in favour of universal title bars with close buttons.
Moved user drawer to the left for consistency.
Added user's library to the navigation bar for easy access.
Removed navigation from game pages.
Navigation is now only on the navigation bar without duplication.
Removed game description and video trailer from game overview page.
Removed "wiki" pages in favour of showing the universal sidebar.
The universal search is now using a "fuzzy" search algorithm again. This means text doesn't need to exactly match the thing you're looking for and results appear faster.
Xenoblade Chronicles X
Added Treasure map.
Added minimaps for all existing maps.
The editor is now in a working state. It is not "feature complete" as the number of possible features is endless. The main focus now will be to use it as the sole way to add data to FrontierNav, adding any new features to it when needed.
The list of changes here will be too long so I've recorded some simple examples below. Try it out yourself if you want.
I'm going to use the Editor now to add more data into FrontierNav for Xenoblade X, Xenoblade 2 and some of the emptier games. The main goal being to add more immediately obvious functionality to it.
This week I've been doing a lot of UI experiments. A lot of it was fueled by yet another poor desktop experience being introduced by a major web company. This time it was Twitter. Luckily they have Tweetdeck which provides a much better desktop interface anyway.
Added change tracking
Added support for exporting changes
Added support for importing changes
Tables now support keyboard navigation.
Made sidebar universal.
Everything is now consistently on the left. No more navigation on the top, user login on the right, page navigation on the left, sidebar on the left, etc.
This is a step towards a frame-based UI to support multiple pages and visualisations on a single screen using frames. Kind of like windows but more intelligent so that FrontierNav can make better use of space on larger screens to reduce clicking around.
It feels like I'm rebuilding an operating system GUI...
Experimented with smaller font sizes and padding to see how a space-optimised FrontierNav might look and behave. This will become more important when a frame-based UI is available and screen space becomes more valuable.
FrontierNav Editor Initial Release
The FrontierNav editor is pretty much complete. Of course, there's a lot of features and improvements I'll be adding a long the way as with any product. But in terms of data-entry, the foundations have all been laid.
The biggest issue now I guess is figuring out the best ways for users to apply their changes. FrontierNav isn't active enough to allow any public change to get applied without moderation. So chances are, I'll go for a request-based approach. Users can make changes and send them over for approval when they're done using the import/export feature.
As a first step, I'll be using the editor to fill in the missing data for Xenoblade 2 and X. Adding functionality to the editor as I need it for others to use in the future. That's a much better approach than hacking scripts together and throwing them away.
Automated Change Submissions
I'll probably remove the need to import/export changes in the near future. If changes are stored on Firebase, there's no need for it outside of offline usage. However there's a risk of flooding the database so it'll need to be restricted to trusted "Editors" or rate-limited.
I finished "Donkey Kong Country: Tropical Freeze" on the Switch finally. It's a good game. Astounding music and level design. Some flaws. Very different from Mario's more nimble and acrobatic platforming. Donkey Kong's a lot more weighted and slow; as you'd expect from a gorilla.
I'll probably pick up "Starlink: Battle for Atlas" from my backlog next. Not expecting much from it.
Agility, the mobbing timer I made a while back, had a bug report. Since it's just a single web page, I recently stripped it down from a Middleman static generated site, to a simple static site with no build step. It's a lot easier to maintain now. I'm still a bit reluctant to be maintaining it though since it's not something I use anymore and I'm not getting anything out of it. But it's not a big deal.
The proper solution to this is "Server-Side Rendering" (SSR). I've tried SSR before, but it doesn't work. A lot of the code wasn't made for it in mind so it just fails. To fix it would mean going through a lot of code and also making sure any future code works in both cases. It's a big investment.
An alternative I've been thinking of is to go through every page in a web browser and dump the HTML. I've tried it this week using Puppeteer to automate the process and... it works.
There are a few issues though: cache invalidation (as always) and deciding where to run it. It can't run server-side since it's using a whole web browser which is slow and eats up a lot of resources, so it'll need to run in parallel. Which in turn means it'll need to know which pages to cache.
Right now, the experiment is using the sitemap.xml to scrape FrontierNav. That works for the more simple pages. But pages like the Maps have potentially hundreds of elements, and dumping all of that into HTML will be ridiculous. These pages are the most likely to be shared on social media. I could strip the excess post-render, but then the solution becomes more complex, at which point SSR becomes more appealing again.
Running in parallel is also a lot of waste since the vast majority of pages won't be directly navigated to. I could make it more intelligent and have it use access logs to find the pages it should cache, but then it's caching after the fact so it'll always be one step behind.
I've become more comfortable using Web Workers now. My first implementation of it for the Universal Search had a single global Worker searching across multiple indexes. Now, there's one for each index, created only when Search is activated and discarded after. I really can't tell what difference it's made since there aren't any Dev Tools that show individual performance metrics, but from an implementation point of view, it makes a lot more sense. There's no point having Workers waiting around, hogging resources.
It seems every week there's a new vulnerability found in an npm package. While this is great progress for the community, it's a pain to deal with when maintaining multiple projects. Automation is a solution, but then you need to maintain the automation. Removing dependencies and writing your own just means you'll probably have vulnerabilities that you don't know about since no one's looking. Eventually dependencies rot and security issues take over. At that point you need to abandon ship and find a new one.
I can't remember how I started going down this route, but I do know that as someone with multiple websites, I should be doing the most to ensure nothing malicious is being loaded onto my viewer's computer.
Actually, I do remember. I was looking into how FrontierNav can introduce an iframe-based, postMessage API to allow third-party integrations -- an exciting topic for another time. Loading iframes from other places is of course open to abuse, so I looked into securing it.
Weekly Report is going to be a new series of blog posts giving an update of what I did in the current week. The aim is to share what I've done and also to help me appreciate and compare my acheivements.
While there will be FrontierNav-related updates in this series. They'll also contain unrelated updates related to my other projects. If you just want FrontierNav updates, you can wait for the monthly FrontierNav Progress Reports.