Heatmap generator incoming

I won’t be able to make a mockup until much later today, but for example:

The old one, despite being simpler, was much more readable. I still like the arrangement of things in the new one, the only thing I don’t like is that the speed gradients as they are don’t synergize with the rest and make the text less readable.

This was the example I used before on Discord, where it’s particularly bad:
image

This mock from Rose does what I was talking about before, it removes the colorful, busy background from the text area, caused by the gradients extending up (the problem then becomes the text outline, which works fine for medium/big texts, but can become clutter and reduce readability for small texts - white shadows could be experimented with instead).

In summary, a clear background with a high contrast color for the text would go a long way. That’s the only thing I have been suggesting.

So each script will be downloaded locally each page visit? Won’t that stress the server more? That will be up to a few MB per visit per user.
Maybe it is possible to make the client generate the necessary data/images only once when uploading the funscript files. That would generate some sort of BBCode to reference the heatmap/metadata to be rendered in the post in a static way.

This replaces bitmap heatmaps. But it appears to me that it will indeed increase the data traffic.

Funscripts (10-100kb) are generally smaller then images (100kb+)

My new theme:

@Rose theme:


tnx to @Rose for text outlines

I did a quick check on my collection and most of my funscripts are over 100KB.
And a few are over 1MB when they are generated with FunscriptToolbox since they include the audio signature.

And I’ve checked a couple of heatmap images currently existing in posts and they seem to be in the 8KB to 16KB range.
So this will probably have an impact on the data usage (I’m also not sure if the browser would cache the funscripts or svgs with this plugin).

I wonder how does it look with a script 1 hour+ ?

Looks like idk

Okay fap hero is a bad example

Heatmap bitmap images can range from 5 to about 110kB.
Calling funscripts 10-100 and images 100+ is quite misleading.
Example of a small heatmap image is this topic:

That’s a ~7.4kB bitmap.
Compare that to the funscript it’s a heatmap of, which is a 234.9kB script file.

I hope you can acknowledge that scripts aren’t typically smaller than heatmap images. Sometimes the script is larger by multiples of 10s, sometimes by 100s. Other times the image is larger by 5 times.

1 Like

I went to a random thread and the heatmap was 5kb, your screenshots are ~50kb and they can be optimized a lot. If you store metadata in text and only have the heatmap part as image then it will be a lot smaller. They also have a known more or less constant size.
I’m just pointing out that there are a lot of threads that have multiple scripts, some index threads probably have 50-100 of them. What if someone uploads 6axis script that each is multiple MB in size.

I don’t know discourse internals/api but it feels like a proper way would be to make some sort of custom component, similar to how hyperlinks are displayed, instead of doing it client side on each visit.
Also I think the work of generating the data should be offloaded to the person uploading and only done once.

Images and other static content are not served from the server. They’re served from Either an S3 object storage or CDN cache.

I like those better. Less noise/redundant coloring. Easier to read.

The size of what is fetched/served isn’t relevant for server performance.
The goal was to solve this problem in a way that doesn’t require a massive project of updating all the posts. This ensures 2 things.

  1. All posts with script attachements will have previews
  2. We don’t need to programmatically update all the previous posts and handle failures or risk breaking the server.

In terms of performance and server load, adding the image processing to the backend is arguably way more intensive than asking the client to pull the file and process it in browser. especially since assets arent’ served from the server, the server sees NO LOAD at all when client processed.

Funscripts are not zipped unlike images
So actual download size is way smaller, and if they are pre-gzipped takes less size on the server disk

It would be fine if there were no themes, rerendering wouldn’t require three hours of server time, and I wouldn’t change heatmap style five times a day
But we may consider it later

Ah, then it should be omitted if the post isn’t tagged as multi-axis IMHO.

1 Like

Since I’ve been drilled by our interaction designers at work I have a few suggestions based on what I’ve learned from them.

  • Make the text black with a white background. That will make good contrast regardless of which theme is being used.
  • Make the entire image larger. Text like duration, actions etc. is very small and the text area need more space to make it possible to use a larger font. It must be readable on a 4K 15-16 inch laptop screen.
  • If you can have a fixed color as background for the actual heat map that would also simplify things. You can render it in one way regardless of theme used. A darker color seems to be better since colors like cyan, light green and yellow are used which have low contrast on a white background. Again, ignore the theme. Use predefined colors that guarantee good readability.
  • “L0” is not relevant for single axis scripts and is just a distraction. Only include it if the post has the multi-axis tag. I assume that is possible since you were considering rendering a $-sign for paid scripts.
1 Like

We have implemented a white outline. A white text area instead might be a good idea.

The heatmap will be made taller. It’s currently the maximum width of a post, but expanding it vertically does make room for larger text. :+1:

There’s an option for users to choose to have a solid fixed color (grey) background instead of transparent. Will test how dark it should ideally be.

I’m providing a couple of alternative heatmap styles, but Dimava and ultimately Vlad are in charge.

If you could provide mock-ups your ideas are more likely to translate into the/an official look of the heatmaps, so I recommend doing that if you want.

I don’t think we should be calling these heatmaps anymore. This is a heatmap:

The current “heatmaps” carry not only the speed at a given time, but also include the position data (I call this graph the “action tracker”). I’m being pedantic, but I think it’s important to recognize that we are trying to communicate a lot more information than a 1D heatmap is capable of.

I think this is the best style of visualizer in use around the site. These are two variations, but very similar. The first one has better scaled text, but I also wanted to share an example with a shorter script.

I would want these qualities adapted to the site universal visualizer:

  • Focused purpose, first an action tracker, then a heatmap
    • If it isn’t action tracker first, why bother including that data at all?
  • Concise makes clear
    • Background is black, not tinted the same color as the action tracker
    • Heatmap only effects one element, don’t repeat yourself
  • Muted, but still plenty expressive color palate
    • No piercing neon colors! Much easier on the eyes
  • Action tracker over text
    • Most scripts bottom out consistently, and have more variation on the upper end of strokes. Text below makes it easier to see the top end of strokes.

Most of the clutter in the current visualization stems from the heatmap color impacting too many spaces. Appearing in the text bar and the action tracker makes it seem like there are two separate, but effectively identical heatmaps in the same graphic. Appearing in the action tracker and the background of the action tracker makes it difficult to read positions because they are the same color as the background. It only needs to impact one, ideally the action tracker itself.

All of that said, a variant that was strictly a traditional heatmap (like the first image I linked to), with no position data would probably be a good option to include. assuming that is in the realm of possibility for the user configuration. Could probably just make the background tint fully opaque for a quick and dirty version.

One more item. The TCode axis takes up a ton of space, but it adds very little value. I’d guess at least 95% of scripts are going to be L0. Why bother with a full height box with information that is useless for most users? Get rid of it. Obviously, it will be very useful for multi-axis and should still be included in those cases. However, I would move it to an element next to the duration, actions, etc. That way it isn’t changing the width of the script area when it does appear. Maybe that’s not so important idk.

TL;DR:

  • Make everything completely transparent but the graph and the text
  • Have only the graph colored like the heatmap
  • Consider muting the color scheme somewhat
  • Add a variant that is like a traditional heatmap with no position data
  • Consider moving the TCode axis into the text bar with the other items, and hiding it if it isn’t a multi-axis script.

Sorry this is probably a mess to read. Really like this idea and am excited to see it come to the site.

readers should opt-out, not posters. even if the poster thinks their version is better, the reader will have their own opinions. the poster can always include as many images as they want.

i’m going off topic, but it’s crazy to me that it isn’t a requirement to attach free scripts directly to the post. there are posts two dozen images and gifs that make you load a separate site to download a 20KB text file.

3 Likes

I am stating we have 3 options for the heatmaps at this point for whether users will be opt in or opt out. This is clearly going to be a disruptive change in the UI so I figure the solution should be one that works with the existing state of the forum, with minimal changes.

Always on

This will enable the heatmaps to be visible when the cursor is hovering the funscript hyperlink.
This allows the theme to be usable for everyone out of the box, easier to maintain for us, and works with the existing posts format.


Peek 2025-04-24 11-46


Opt Out

OP can choose whether these posts will show the heatmaps. Users will see this change going forward, formatting in posts might not fit well depending on how it’s setup.

Opt In

We build a custom discourse plugin that gives users the ability to switch this on or off.
The formatting in posts might not fit well depending on how it’s setup, but only users who opt in will see this.

I personally am in favor of the Always on option as I think it fits most people’s needs/wants.

  • Always on
  • Opt Out
  • Opt In
0 voters

The mockup by @smeedler below matches what I said. White text and heatmap colors on a black background provides very good contrast and makes it easy to read and distinguish the colors. It’s also good that there aren’t any distractions like the axis for a single axis script. I’m perfectly fine with including axis for multi-axis because there it serves some purpose there.

I’m probably fine with @Dimava colors. I would probably like to see a funscript that follow actions (examples looks like sound or beat, but I can be wrong).

The colors and style in your example is also fine.

I don’t really understand poll options, they are confusing (noone reads the descriptions)

I think calling the option “Always on” is a disservice to its attractiveness.
It only appears as pop-up on hover, but it applies universally.

1 Like