This is a list of project announcements such as new features sorted in chronological order, from the newest to oldest.
Significant entries will have a corresponding announcement on the following official accounts:
At github.com/ourbigbook/ourbigbook/commit/075872a0a5ca7faf171d45834bc2b47995a15634 and nearby previous commits we've optimized the database queries made on article pages, mostly by adding some key missing indices and cache columns.
As a result, ourbigbook.com/cirosantilli now starts downloading the first byte 2x as fast as before, going down from about 1200 ms to around 600 ms, at a time region which makes a huge difference for user experience.
We will also start keeping better performance logs at: Section "OurBigBook Web performance log" to make sure we don't regress as easily.
Announcements:
We've greatly improved the Visual Studio Code extension adding support for the most important VS Code language features: Ctrl + T header search, Ctrl + click jump to header, header outline and link autocomplete
Thanks to Juhani Junkala for the awesome CC0 chiptune game soundtrack! opengameart.org/content/5-chiptunes-action
Announcements:
The article body now shows by default on all article lists. So do comment lists.
The major application of this is to quickly browser through a users's top or latest posts, e.g. ourbigbook.com/go/user/cirosantilli/articles?sort=score
Previously, the body would only show on:
- topic listings
- discussion comment lists
Now it shows everywhere else as well, except that in other views, only a fixed height preview is shown to allow quickly going through large articles without too much scrolling.
A "view more" button can uncover the hidden content if the user wishes to usee it.
A "Show body" control was also added to toggle body vs the previously existing table mode.
Announcements:
It is now possible to mark articles as unlisted on OurBigBook Web: Section "OurBigBook Web unlisted articles".
The most important effect of this is that unlisted articles don't show on the table of contents of its ancestors. They also don't show on many article listing by default, e.g. on the list of user's latest articles.
The main use case we have for this feature right now is to stop polluting the table of contents with articles a user does not wish to show, and especially when doing local to Web upload, where Web articles are marked as unlisted by default if they are deleted locally.
We offer unlisted as an alternative to deletion for now because of the general philosophy what "permalinks should never break". This is currently not true as we don't have article history and therefore no permalinks. However, once history is implemented, we want to make it so links to specific versions will never ever break by forbidding article and history deletion entirely. Marking articles as unlisted will then allows to prevent deletion, while still keeping table of contents tidy.
In order to give more immediate topic value to readers, and to better highlight the topics feature, we now show a few articles on the same topic at the bottom of every article page, essentially acting as a preview of the corresponding topic page.
For example, if you visit the "Calculus" article by user Barack Obama: ourbigbook.com/barack-obama/calculus then at the bottom of the page you can see a section "Articles by others on the same topic (3)" which displays up to the 5 most highly upvoted articles in the same topic written by other users, much like the topic page for the "Calculus" topic: ourbigbook.com/go/topic/calculus.
By comparison, the topic page shows more articles by default (20), supports pagination, and allows for other forms of sorting such as viewing the latest articles in a topic. We are initially not adding those options to the article page itself as there is already enough stuff going on there.
Announcements:
Previously, when clicking a link to an element that is present in the current page, the URL fragment would contain the full ID that element.
Now, only the ID relative to URL path shows.
A very common use case for this is when clicking table of content items.
For exmple, from ourbigbook.com/barack-obama/mathematics, clicking the ToC item for "Calculus" would previously lead to ourbigbook.com/barack-obama/mathematics#barack-obama/calculus
After this change it leads just to: ourbigbook.com/barack-obama/mathematics#calculus, without repeating the "
#barack-obama
part as it already appears in the URL path /barack-obama/mathematics
.Short URLs were already used on Static website publishes, and weren't implemented on OurBigBook Web yet simply because this is hard. The reason this was much harder to implement on Web is that due to Dynamic article trees we can't know at render-time what the correct fragment will be, as it depends on what shows on the page or not.
And furthermore, articles by different users can appear on the same page due to topics.
The simple but not ideal solution that we were using up to now was to just have full IDs on every HTML element, make every a point to an absolute ID like
/barack-obama/mathematics
, and then use JS effect to hack that to #barack-obama/mathematics
if the element is in the page.What we did now is to take the Js hacks one step further, and actually replace the "long URLs" with short ones. This was not easy, partly because the browser interfaces are not amazing in that area, partly due to fighting with React. But we manage to get it working mostly well.
Announcements:
Docs: Section "Horizontal rule "
Behold:
Before the rule.
More before the rule.
\Hr
After the rule.
More after the rule.
which renders as:
Before the rule.More before the rule.After the rule.More after the rule.
We're experimenting with a more traditional and boring "dark" theme than the green on black classic previously used.
Readability is probably slightly better, though it is hard to measure these things. It is quite possible that the change matter much more for some people than others who have different eye sight phenotypes.
Perhaps the most important outcome of this is that it will greatly reduce the endless complaining from the community. Though perhaps that was a feature rather than a bug?
Beyond the theme change, many other changes were made. Many of those improvements feel like undisputable upgrades, e.g.:
- headers are not colored differently from regular text
- table borders are less visible
- navbar and footer are more discrete and readable
The CSS code was also refactored and it is not much easier to make broad color changes such as these in the future, as color constants are not more closely grouped, and fewer constants are now used.
Large parts of this change were pushed forward by sidstuff who contributed a several code snippets and ideas to it.
It is now possible for admins pin an article to the homepage. The initial use case is to help with new user onboarding. Documentation: pinned article.
Previously we would only create an entry in the
_file
output directory for headers marked wiht the \H
file
argument.For example the file file_demo/hello_world.js in this repository has an associated header with the
file
argument in our index.bigb := file_demo/hello_world.js
{file}
An explanation of what this text file is about.
Another line.
As a result, when doing a split header conversion, it would get both:
- a
_file
output directory page at path_file/file_demo/hello_world.js
file_demo/hello_world.js - a
_raw
directory page at path_raw/file_demo/hello_world.js
file_demo/hello_world.js
On the other hand, the test file file_demo/nofile.js has no such associated header in the source code.
Before this change, file_demo/nofile.js would only get an
_raw
directory entry under _raw/file_demo/nofile.js
and not _file
entry. But now it also gets both.The advantages of a
_file
entries over _raw
entries are as follows:_file
entries can have metadata such as:- OurBigBook content associated to them when they have an associated
_file
header. For example at file_demo/hello_world.js we can see the rendered text:Of course, in that case, they would also get theAn explanation of what this text file is about.Another line._file
entry even before this update. However, this update does allow for a smooth update path where you can first link to the_file
entry from external websites, and then add comments as needed later on without changing URLs. - Google Analytics and other features via ourbigbook.liquid.html
- OurBigBook content associated to them when they have an associated
_file
always shows on static website hosts like GitHub Pages, since they are just HTML pages. This is unlikeraw
files which may just get downloaded for unknown extensions like.bigb
rather than displayed on the browser:_raw
files are downloaded rather than displayed in browser for certain file extensions on GitHub Pages
This change is especially powerful following Always show large text files on
_file
split headers.Because we now have
_file
entries for every single file, we have also modified _dir
directory directory listing pages to link to _file
entries as those are generally more useful than _raw
which is what they previously linked to. And you can always reach _reaw_
from the corresponding _file
is needed. Example: docs.ourbigbook.com/_dirPreviously, large files with an rather than the file contents both on their split and non-split versions, e.g.:
\H
file
argument associated to them would show a messageindex.js was not rendered because it is too large (> 2000 bytes)
Now, the split version docs.ourbigbook.com/_file/index.js alwayws shows the full text file.
When not in split mode, limiting preview sizes is important otherwise multi-header pages might become far too big. Ideally we would have found a way to reliably use
iframe
+ loading="lazy"
to refer to the file without actually embedding it into the page as we do for images, but we haven't managed to do that so far.This allows us to now see files that were previously not visible anywhere on the rendered HTML without download due to
_raw
files are downloaded rather than displayed in browser for certain file extensions on GitHub Pages.The main focus was the Table of contents rendering, which had a lot of redundant stuff. Headers were the next largest gain.
The main techniques used to reduce size were:
- auto-generate a few elements on-the-fly with JavaScript for on-hover effects, but only if it doesn't affect SEO and readability when JS is turned off
- use a lot more CSS
::after
and::before
to avoid embedding repetitive icons multiple times on the HTML
After this changes, the rendered size of cirosantilli.com fell from 216 MiB to 156.5 MiB, which is kind of cool!
In previous updates we added insane topic links which allow you to write
#mathematics
to link to OurBigBook Web topics such as: ourbigbook.com/go/topic/mathematicsThe outcome of that however is that it is also easy and correct to create links to topics that don't yet exist on the OurBigBook Web instance.
To make this nicer, we've unconsciously copied Wikipedia once again, and added a "Create an article for this topic" link
For example, currently OurBigBook.com the topic "Endoplasmatic Reticulum" does not have any articles on it. So if you created a link
<#endoplasmatic reticulum>
, it would redirect you to: ourbigbook.com/go/topic/endoplasmic-reticulumPreviously, this would show "Topic does not exist". But now it shows a button that opens the new article editor with pre-filled title "Endoplasmatic reticulum". The title choice is only a heuristic as it can't know the correct capitalization, but it covers most cases corectly by default and can be modified manually as needed.