Quick thoughts on Minimalist Design Patterns for Brimstone

Minimalism is one of the inspirations I draw from when hacking at Brimstone. So far this has manifested by removing things like excessive UI elements, cumbersome Javascript and CSS frameworks (thankfully PureCSS exists), and streamlining things such as how Posts work and are displayed.

I had a thought recently when considering the About page, and how a more minimal approach might look. At the moment, the approach is still relatively minimal; the UserProfile object has a field which can store text used to render the About page using markdown. If it's null or empty, the templates don't render a link to the About page and the controller redirects any attempts to directly go to /about to the index page.

How then, do I think it may be improved? Obviously these are rough ideas -- I also don't think there's anything explicitly wrong with the way things are done currently. What might seem simple to me might not be simple to others, and in fact I think there's an argument that these design patterns could add complexity in some regards.

Under both of the following proposals, the UserProfile object has the about attribute removed, and controller logic is changed to accommodate the new pattern.

Idea 1 - Using a Post for an About Page

Under the current design, the About page is simply a text field containing markdown that is rendered when the visitor calls /about. This works basically exactly the same as a Post but is a bit less versatile e.g. Posts store a lastModified attribute which can inform the reader if/when the Post was last edited and give some idea of freshness.

Under this design pattern, Post receives a new boolean attribute which marks it as the About page. A form or button is implemented, along with a controller to handle elevating a Post to this position with the following logic:

post = post // from controller
previousAbout = searchPosts(where: about == true)

if ( previousAbout is not null ):
    previousAbout.setAbout(false)
fi

post.setAbout(true)

return new Response(200)

The About page template can actually remain, with the controller simply changing the variable it passes into it to achieve the goal. Another consideration, however, is the header templates logic when choosing to render an /about link. Currently it utilises a UserProfile object already passed in to the template which is used for H-Card generation and Site titles as well as visible elements such as the name and profile image. Since the UserProfile object also contains the About page, it simply checks to see if it's null or not to decide whether to render the /about link. If I made the About page a Post, the controller would need to inform the template separately, unless the UserProfile maintained a 1-to-1 relationship with a single post, which is nullable. This changes the previous controller logic above to:

post = post // from controller
userProfile = user.getProfile()

userProfile.setAbout(post)

return new Response(200)

Which I actually prefer. The UserProfile still has an about attribute, but it's a reference to pre-existing content and can be switched without a search of the database and it prevents duplication; where since Post already contains the necessary attributes for a good About page it makes sense to leverage it.

Idea 2 - Using a tag for an About Page

This one also utilises Posts, but with a slight twist. Instead of elevating a single Post to become an About page, what if we simply used a Tag? That way, the user could add content to their about page on-the-fly simply by tagging a Post with an about tag?

I don't think this is without issues -- for example how do you order things? What about reordering things on the page? How about editing posts, you have to hunt them down (admittedly just a search for the tag about…)? There's also the issue of the header rendering the /about link from earlier -- this means every controller needs to do a search for Posts tagged with about and check the length of that result, to decide.

I'm sure there's a way around this, and I really like the idea of a cumulative About page which can be made up of otherwise disparate content, for now I'm going to try out Idea 1 and see how that goes.