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.
-
Too big size on repository
Unless doing it in a separate repository.
-
Too much increase in bandwidth on website.
In other words, Netlify won't be happy, unless doing it in a separate box.
-
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.
-
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:
-
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.
-
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.
-
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:
-
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 |
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.