Matt Marshall

2 Posts with Tag cms (All tags)

30 Jan 2017, 09:09

Brimstone: Plans and Situated Actions

I've grown a bit restless with Brimstone (the software that's running this site) at the moment. I've been dribbling in features here and there to keep myself occupied, but I think it needs a bit of an overhaul both visually and in the background.

TODO

  • Change the CSS and page structure from Bootswatch to Materialize I've never enjoyed doing my own CSS other than a few small bits, so this move is largely just for the visual appeal and a vector for removing JS
  • Remove Admin Section reliance on JavaScript I've never enjoyed writing JavaScript either. During the restructuring I'm going to be changing the admin section to have minimal JavaScript, and elegant rollback. Currently the features that rely on JS are posting Notes and Replies, and favourites. Since this is the bulk of interactions with the software, I think it needs changing a bit. I like some shiny interactive features, but these shouldn't be necessary to create particular forms of content.
  • Condense Notes and Posts into single data structure The bulk of my content is written as Notes, which are a shameless emulation of Tweets and were actually the first type of content I produced. Posts are the longer, blog-post style, pieces of content. There's literally no other reason other than my excitement and stupid categorisation of content that they need to be separate. I'll do content inference instead; pieces with a title get published with an 'Article' template, and those without get a 'Note' template. With a location field, it means I can also infer check-ins as well as add richer data to all posts. This might not work for later content types such as exercise data as they don't share many common fields. Syndication templates can also be produced.
  • Restructure the URLs to content and implement redirects for old Tweet citations
  • Feature to import all tweets between certain dates to create a backlog of content
  • Implement a basic exercise tracker
  • Implement a basic spending tracker
  • Produce summaries of my content (heavily inspired by Rhiaro
  • Implement proper user management to let people 'install' the software themselves, without editing files to create a user.
  • Release the source on Github.

That's a lot to do, and I'm thinking of dedicating an evening a week to the project. We'll see how it goes. For now, you get bonus points if you understand the relationship between the title and the content of this post.

cms brimstone data content

29 Dec 2015, 19:23

Tags vs Categories: All hail tags

I've just recently completed most of the CMS portion of the site, allowing me to publish a few of the posts I've been working on over the Winter-break. I made a few design decisions along the way I'd like to share, mostly related to tagging and organising content.

I currently have two main types of content. Posts and Notes*, I worked on my Notes first since it gave me a way to syndicate out to Twitter, play with the Twitter API, and not have to write any serious post content. I then moved onto (largely) finishing off Posts. The Tag entity has many-to-many relationships with each, allowing the two types of content to share tags.

* I actually think I broke some IndieWeb rules by calling my blog posts 'Posts' instead of 'Articles'. I think 'post' is meant to denote any type of content!

Don't be afraid of the #hashtag

Starting with Notes affected a lot of the design process. My Notes are totally and unashamedly supposed to emulate Tweets. This meant I was already producing Notes with inline hashtags as they were syndicated out to Twitter. It was easy enough to write a bit of code to parse a Note for hashtags and create Tags as a Note is uploaded. Each time a Note is written, it's parsed for hashtags, which are extracted, checked against the database, and either updated or created accordingly. Easypeasy. This allows me to use tag inline in Notes.

I knew I wanted to be able to tag Posts so that they showed up next to Notes in tag searches, but it didn't quite feel right hashtagging them. I was wrong. Hashtagging is absolutely fine for Posts. Although you can argue that a hashtag is geared towards microblogging since it can be discerned inline as opposed to added in a separate 'Tags' form, I honestly don't see why this makes them entirely unsuitable for use. The hashtag now has a wonderful history of use-cases, being used for: social justice movements; events and community dialogue; and even organising protests. Tagging your posts with hashtags allows you to contribute to these global dialogues, or at the very least acknowledge them.

Let the Tag take charge

Two things became apparent in my code when I was building Tags. First -- I'm at least initially going to forget to put the hash on my Post tags. Second -- Hashes are going to look horrible as url slugs.

My Tag model thus consists of two fields, the name (full hashtag) and the slug (hashtag minus the hash). I did this mainly because I thought it wasn't particularly good practice to have to add (or remove) hashes when displaying or retrieving tags from the database. When tags are created, their name is set. Inside the setName() function, all tags are converted to hashtags if they're not already. The slug is then updated automatically to the stripped version without developer input. This is to counteract my own stupidity. This mainly gets used in Posts, as tags from Notes are generally extracted if they're a hashtag already.

Tags can be categories

Most of the arguments I read on this matter seemed to follow the line of "Categories are for broad, high-level descriptions of content; Tags are for low-level, post-specific descriptions". I don't buy that at all.

Tags are created dynamically, as and when they're needed by the user tagging something. As you, or your user, writes content tags will inevitably recur. Why can't you just tag some content with a tag that happens to be a high-level description of a post? That way you've created a category organically through use of the system. I read an argument about a downside of tags (link below) being the browsing experience, and having to generate a tag cloud to filter out the most popular tags. Erm, couldn't you just create a panel with a list of manually 'pinned' tags that act as category filters? If you or a user notice a tag recurring quite a bit in content, and it's a broad description -- just slam a link to it on your Blog's index page. You need to do this anyway with Categories, why not just save the hassle of manually assigning them?

In conclusion, tags are generally a good way to go. They can describe and categorise content at low and high levels, they're generated organically on the fly, and if you go with the hashtag then you've got the opportunity to participate in community (or global) dialogues.

Long live the tag.

tags cms design posts hashtags