Journal Plugin Updates

@CJ_Bernstein @Jrgong I just pushed various updates to the journal plugin. Of note are the following

  1. New (better) way of ordering posts (@CJ_Bernstein will fix your issue)
  2. New admin control in category settings to let you force-reorder journal topics to fit journal ordering (or to revert to normal ordering)
  3. New journal entries timeline (and a site setting to turn it off if you don’t like it)
  4. Minor fixes (e.g. re-adding the post meta data showing which post is being responded to)

See more about the settings here

See an example here


@CJ_Bernstein @Jrgong I’m particularly interested in feedback on the UX aspects of the journal based on your use cases, for example

  1. The default naming of elements. Currently we’re using “entry” and “comments”. These can be changed in “Customize” > “text” however what is chosen as a default matters.

  2. The UX elements within a topic, including

    1. Whether there should be additional information in the post meta area of journal entries and or comments.

    Screenshot at Jul 13 14-08-27

    1. The UX of the entry timeline

    2. The UX of comments, e.g. the show-on-hover treatment of post controls in the more limited comment UX element (compared with normal discourse posts), or the use of border lines to demarcate the comment area.

    3. The use of journal metadata in both the topic “map”

      and around the topic title

  3. The UX and nomenclature of the topic list, for example which columns should be present and why?

I’m going to continue to be quite interested in this plugin for the next couple of months, partly for the plugin’s sake itself, partly for both of your specific uses, and partly because I’m using the same post ordering system and UX in a learning management plugin I’m developing for Pavilion’s own use (to teach open source software development). So if you have interesting ideas about how to improve this system, now’s the time to share them (or remind me if you’ve already shared them).

I may not necssarily impelement everything you suggest, and we may move some requests to paid work to be done seperately if feasible, but this is the focus of my open source work, particularly in August.

1 Like

Hey Angus

I like this idea. In the long run we want a custom title for each entry anyway as customization.

Timeline: In it’s current state it feels a bit “jumpy” due to collapsed comments. Any way that the timeline only counts the journal entries? See the screen recording (includes a bug, will report is separately):

from user perspective I find it a bit confusing that the column with the reply count is missing. I think it would be beneficial to add a per-category setting to display the stock topic list without any modifications. Otherwise I see colliding issues with other plugins such as TLP or other theme components.


Yeah, I’m going to add this later today.

No, in the recent work in this plugin I’ve definitively decided against trying to do this. Basically it’s just too complicated to pull off properly, let alone to maintain it alongside changes in Discourse.

The way the discourse topic timeline counts posts is complex, which is partly why it’s not perfect in Discourse itself, for example you may notice in vanilla Discourse that deleted posts or whispers will throw off the timeline count. There are various posts on about this. Additionally trying to get the timeline to show only journal entries is just not feasible unfortunately.

That’s why I’ve gone with a seperate entries timeline approach.

But what should be shown in that column? Remember in normal discourse replies are every post in a topic aside from the first post.

What columns should a journal category have?

cc @CJ_Bernstein

1 Like

So I suppose, even if we would modify the filter button to show only the entries (not the comments) of the journal author, the timeline would still throw different numbers?

To be honest, I would just leave it as stock. For the reasons mentioned above: not causing extra issues with other theme components. In the end, no one will hand-count all the comments to see if the number is of replies is 100% correct or not. Unless it’s a huge deviation.

Potentially, yes. Also keep in mind that journals are not limited to a single author. Moreover, while I understand that you see journals as similar to the post filter functionality, it’s quite different technically speaking. I wouldn’t use it as a proxy for thinking about the journal functionality.

I know you’ll be wondering (and have wondered) why I didn’t just extend the post filter functionality, which seems to get you 70% of the way there. There are a few different technical reasons. I can get into them if you really want to, but the explainations wouldn’t mean a lot if you’re unfamiliar with the Discourse codebase. Aside from that, you’re going to have to take my word on it I’m afraid :slight_smile:

Perhaps it’d be better to cross that bridge when we get to it? Aside from TLP, which can be worked with, is there anything else you have in mind? Personally, I think it’s more strange to have a topic list that doesn’t relate to the nature of the topics it’s listing. This is what I’ve done with the similarly ordered topics in the related plugin I’m building (Steps = Entries; Comments = Comments).

Nevertheless, in the Journal Plugin the column is just being hidden with CSS, which I’ve removed. If we add in topic list changes, I’ll put them behind a setting.

Hey angus

I appreciate the long answer! I am totally with you that you had your reasons why you made that implementation your way, no need to explain.

I was merely describing that when hitting the “filter by user” button users would rather expect to see only entries (not comments) of that particular user.

I see you have a really analytical mind and want to portrait displayed information in the most representative and accurate manner. While I am still totally with you, I prefer to go the KISS way for that and rather allow room for small “misinformation”. Only once users notice that, we will fix it.

In this particular case most people don’t really care about exact number of posts when they see a topic in the topic list. Of course if the number is super low and deviates a lot (let’s say it says 12 posts, but inside there are only 3), then they are confused. But even with 250 posts displayed but only seeing 240 inside the topic isn’t a big deal.

I think making it optional is a great solution. Since we are using a lot of different theme components and planning to make some replacements, we want to avoid known unknowns and leave no room for
Otherwise our users have to deal with visual bugs until the manner is reproduced, reported, fixed, tested, update-requested and installed. That takes 1-2 weeks in the end.