I will suggest that there are 3 aspects to this problem.
- Input - How does the length of the script get set in the database?
- Display - How does the length get displayed in the topics list?
- Filter/Search - How does the filter/search capability incorporate the length?
Each of these is a difficult problem to tackle. An ideal solution would be one that balances the value of all 3, rather than prioritizing one over another. I don’t have any insight as to what the backend of what Eroscripts looks like, so I’m going to throw out some possible solutions based on speculation.
Solving issue #1 - How does the length of the script get set in the database?
I’m going to assume that Discourse provides some sort of scripting capability or API. I’m also going to assume we can add a field to the topics database for “Length”, and that it will default to null. Here is what the algorithm might look like:
- Check that the post is in one of the script categories. If not, Length field stays null.
- Parse the text of the topic for “Length: ” or “Duration: ”. Attempt to parse the time that follows that text. If the parse is successful, enter that length into the database and done. If not, continue.
- Open each attached funscript file, and parse the field “duration:N” where N is the time in seconds.
- If there is only a single funscript and it successfully parses the duration value, that value gets set as the length for the topic. If it is unsuccessful in parsing the value, then the length for the topic remains null.
- If there are multiple funscripts with the same duration value, enter the value as the length for the topic. If there are multiple funscripts with different durations, the length for the topic gets entered as an value that indicates multiple lengths are present in the topic. (e.g., “-1”)
The goal of this algorithm is to end up in 1 of 3 states. You either have a null length, a length value, or a value to indicate multiple lengths are present in the topic. The outcome of this solution should be the Length field in the database containing either null, -1, or a time value.
There are some potential difficulties with this algorithm. Paid scripts will be more difficult, as the funscripts themselves are not usually available within the topic. Those would have to rely on the topic creator to properly include a “Length: ” somewhere in their post. There is incentive for them to do that because when someone is going through the topics list, seeing a timestamp will look more professional and will also draw in people specifically looking for those lengths. Devil’s advocate is that by not including the field, they might get more clicks because people have to do a little extra work to figure out how long the script is. Another difficulty is if the “Length:” cannot be parsed because of misspelling, using a different word, etc. Lots of potential pitfalls happen when you try to parse a specific keyword from community-driven content. This could be overcome with a very thorough parsing algorithm that catches misspellings, etc, or it could be overcome with some clever scripting during the post that will warn the author when the length field is not found or able to be parsed correctly.
Solving issue #2 - How does the length get displayed in the topics list?
This one is likely the most technically challenging to solve. Looking at the Discourse site, I’m not seeing any examples of where they’ve updated the topics list to include custom data. However, that doesn’t necessarily mean it’s impossible. Here are a few ways we might be able to do it.
Method 1 - There might be an API that allows us to add custom data to the topics list. If so, we’d only need to pull the Length field from the database and display it in a new column in the topics list.
Method 2 - We could build a hook into the database that when the length is entered, the title is updated to put the time in minutes at the front. So a topic titled “TheObsidianGeneral is a dummy” would be updated to look like this: “{3:42} TheObsidianGeneral is a dummy”. (I don’t suggest we do this method, as it involves modifying the actual title field in the database.)
Method 3 - Similar to method 2, but this would be done at the UI level. The underlying database value for the title would not be touched. When it comes time to display the title in the topics list, the Length field is added to the front of the title text after the title has been pulled from the database and right before it gets displayed.
Method 4 - Display the timestamp in the bottom-right corner of the thumbnail. This is my personal favorite, but could also be the most tricky to implement. Basically when the thumbnail is getting pulled from the database, or when it’s getting drawn, we throw some processing in there that overlays the timestamp based on the Length field.
The goal of solving this issue is making it possible for someone to see at a glance of the topics list how long a funscript is, so they can make an informed decision on whether to click it or not. This will allow people to visually filter out lengths that they are not interested in.
Solving issue #3 - How does the filter/search capability incorporate the length?
In theory this should be pretty simple. Assuming we have some sort of scripting ability or access to the API, we should be able to update the filter/search capability to include parameters based on the Length field. Depending on the community’s preference and the ability of the developer, we’ve got a couple different options:
Option 1 - Minimum and Maximum length fields in the advanced Filter/Search options.
Option 2 - A slider for minimum and maximum in the advanced Filter/Search options. (More difficult to implement and less precise, in my opinion.)
Option 3 - Checkboxes for predermined lengths. For example, <3 mins, 3-5 mins, 5-10 mins, 10-30 mins, 30-60 mins, >60 mins. You could check each box you are interested in.
If I had my way, I would go with a magical option 4, where we have min/max fields when you’re doing an advanced search, and then the checkboxes for if you’re filtering.
If you took the time to read all that, thank you! As we approach this problem, I think it’s important that we keep an eye on the end goal: a solution that will balance the importance and feasibility of each aspect of this problem.
