Skip to content

Instantly share code, notes, and snippets.

@Hans5958
Last active April 13, 2022 06:57
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save Hans5958/d9d6474c56abfde8c9000f4baf951575 to your computer and use it in GitHub Desktop.
Save Hans5958/d9d6474c56abfde8c9000f4baf951575 to your computer and use it in GitHub Desktop.
Analysis of Timeline Granularity - made for https://github.com/placeAtlas/atlas.

Analysis of Timeline Granularity

Made for placeAtlas/atlas.

Since the epoch of the timeline feature (so-called time travel), many members of the community suggests to add more time on the Atlas. I myself the one who supports the idea, but we should think about it for a while, especially on how fine we should make the timeline. Henceforth is my scribe about it.

Conditions

Here are my conditions on choosing the granularity of the timeline.

1. Do not make it too fine

Too many canvas to choose on the timeline would result in following consequences.

  1. Too big size on repository

    Unless doing it in a separate repository.

  2. Too much increase in bandwidth on website.

    In other words, Netlify won't be happy, unless doing it in a separate box.

  3. Too difficult for users who contribute

    We want this entry to be good, so users need be very precise when setting the period. This would decrease interest, even the interest of existing contributors to edit more.

  4. Too much ambiguity that confuses users who contributing

    See one entry on https://www.reddit.com/r/place/ and seek through the timeline. Ask yourself "When does it start? When does it end?"

Some opinions that are not aligned with this condition:

  1. Per-second atlas (using other sources that can be implemented inside the atlas)

    Obviously would result in users needing to be very, very precise, and needs to know when does it start and when does it end.

  2. Use the timestamp for an entry's period.

    Assuming that the timestamp is on seconds, it would be way, way, way, too fine. Even without the background changing every second, users would need to see other sources, while being very, very, very precise. We're not even talking the ambiguity.

2. Do not make it too rough

Too little canvas to choose on the timeline would result in following consequences.

  1. Not enough representation of all communities participated on the canvas.

    "Streamers covering our art!" one community said.

Some opinions that are not aligned with this condition:

  1. The old version of the Atlas!

    Thank god we implement that!

3. Be consistent

Every one hour? Go ahead. Every day? Good for me. Every 1 minute? At least it is consistent. Half an hour and then one hour for some reasons? No!

Suggestions

Keep in mind that the size represeting normal .png images. If anyone want to use other formats (excluding .jpg), then obviously it wouldn't apply.

Every 1 hour

Element Quantity
Images 82 (1 excl. whiteout)
Size (2 MB) 164 MB

I think this is the best in my opinion. We got plenty enough to cover 99% (guesstimation) of the communities of the canvas, while small enough that people can seek and find the start andn end point easily.

Every 6 hours

Element Quantity
Images 13 (1 excl. whiteout)
Size (2 MB) 26 MB

This is the current setting on the Atlas, although there are more images than 13. I just realised it is not quite round. But again, I think this is a good starting point.

Every 30 minutes

Element Quantity
Images 164 (1 excl. whiteout)
Size (2 MB) 428 MB

Reaching closing to 500 MB, I think this is my borderline. I would not suggest going any fine.

Other quantites

Element 4 hour 2 hour 10 minutes 5 minutes 1 minute 30 seconds 1 second
Images 20 40 492 984 4920 9840 295200
Size (2 MB) 40 MB 80 MB 984 MB 2 GB 10 GB 20 GB 590 GB
@fabi321
Copy link

fabi321 commented Apr 13, 2022

I just looked at the raw images from Alex Tsernoh, and it is roughly 1 image every 30s, resulting in 5GB of total data. But I do agree that either every hour or every 30min is the most useful scale.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment