4 ms·

I made a proof-of-concept text viewer with this in mind - https://github.com/aappleby/wideboard https://github.com/aappleby/wideboard

skulk 2y ago
I wonder if instead of shrinking the text geometrically when zoomed out, you could shrink it semantically (with a LLM or something similar) as in the wikipedia image ZUI example. Of course this would require an enormous amount of pre-processing to get multiple levels of zoom shrinkage.
- postepowanieadm 2y ago
  That's a really cool idea!
- bradmcnally 2y ago
  There is a great demo of this in Sensecape. https://youtu.be/MIfhunAwZew?t=165 https://youtu.be/MIfhunAwZew?t=165
  - solardev 2y ago
    That's really cool! How does it do the idea summarization?
- peddling-brink 2y ago
  Just as much as a map. I did something similar using a local LLM to summarize paragraphs. Using a public turbo model or even something local would be very doable.
- hateful 2y ago
  I like this idea, but it should have a limit - because every time I zoom in to read the name of a road on a map and the text resizes to a smaller size for infinity I wish it didn't.
  - solardev 2y ago
    You probably know this, but in Google Maps at least, you can use browser zoom (ctrl/cmd +/-) to change the size of labels without zooming into the actual map. ------ Speaking of maps, I got to work a fun zoom project a few years ago: https://map.fieldmuseum.org/ https://map.fieldmuseum.org/ We used https://openlayers.org/ https://openlayers.org/ and thought long and hard about how to best handle zooming and variable levels of information density & visual hierarchy. If you zoom all the way out, we just highlight where the building is relative to the surroundings. As you start to zoom in, we start to highlight major exhibitions and entrances. Then as you zoom in more, we start showing recommended paths, smaller exhibitions, etc. The label sizes try to scale up and down at each level, smoothly, in order to balance readability and density. Eventually you can reach the max zoom level and the labels will just grow bigger and bigger, but the SVGs dynamically shrink so they remain pictograms and not just contextless-lines. Then if you keep going, you eventually find microscopic easter eggs :) The code is pretty jank (and abandoned), but it's FOSS vanilla JS/HTML/CSS, and the only dependency is on OpenLayers: https://github.com/arcataroger/openlayers_indoor_map https://github.com/arcataroger/openlayers_indoor_map
Solvency 2y ago
just because this zooms doesn't mean you made a ZUI. the spirit of a ZUI is change of information/density/etc at different levels of zoom. like google maps.
- hateful 2y ago
  Or that infinite scroll game of life that was on here a few weeks ago! more density, same information!
tomthe 2y ago
Wait, how is this possible?? I tried to visualize a few tens of MB of text in the browser [1] on a canvas and it gets really choppy if I don't optimize it by not showing stuff that can't be read. Impressive that it can handle gigabytes of text! [1]: https://tomthe.github.io/hackmap/ https://tomthe.github.io/hackmap/
- wongarsu 2y ago
  I'd wager by making the requirements simpler. Wideboard is rendering monospace, so every document is made up of of 8x16px cells, and you just have to decide which glyph to render in each. From a quick skim of the source code this is mostly precalulated. Basically each document is rendered as one rectange, where the shader converts the current position to the row/column of the character to be rendered. There is one texture that holds the length and starting offset of each line (using one pixel per line), and another texture that for each offset tells you which glyph to render (using one pixel per glyp). The third texture is the glyph map that holds the actual glpyhs (a simple 256x256 texture of all supported characters). The last texture is static, the other two are calculated once as the document is loaded, and there is a neat shader that uses all three textures to render the actual document view. Since the shader is sampled at fewer points if the rectangle takes up fewer pixels on your screen this works out well for zoomed out views.

skulk 2y ago

I wonder if instead of shrinking the text geometrically when zoomed out, you could shrink it semantically (with a LLM or something similar) as in the wikipedia image ZUI example. Of course this would require an enormous amount of pre-processing to get multiple levels of zoom shrinkage.

postepowanieadm 2y ago
That's a really cool idea!
bradmcnally 2y ago
There is a great demo of this in Sensecape. https://youtu.be/MIfhunAwZew?t=165 https://youtu.be/MIfhunAwZew?t=165
- solardev 2y ago
  That's really cool! How does it do the idea summarization?
peddling-brink 2y ago
Just as much as a map. I did something similar using a local LLM to summarize paragraphs. Using a public turbo model or even something local would be very doable.
hateful 2y ago
I like this idea, but it should have a limit - because every time I zoom in to read the name of a road on a map and the text resizes to a smaller size for infinity I wish it didn't.
- solardev 2y ago
  You probably know this, but in Google Maps at least, you can use browser zoom (ctrl/cmd +/-) to change the size of labels without zooming into the actual map. ------ Speaking of maps, I got to work a fun zoom project a few years ago: https://map.fieldmuseum.org/ https://map.fieldmuseum.org/ We used https://openlayers.org/ https://openlayers.org/ and thought long and hard about how to best handle zooming and variable levels of information density & visual hierarchy. If you zoom all the way out, we just highlight where the building is relative to the surroundings. As you start to zoom in, we start to highlight major exhibitions and entrances. Then as you zoom in more, we start showing recommended paths, smaller exhibitions, etc. The label sizes try to scale up and down at each level, smoothly, in order to balance readability and density. Eventually you can reach the max zoom level and the labels will just grow bigger and bigger, but the SVGs dynamically shrink so they remain pictograms and not just contextless-lines. Then if you keep going, you eventually find microscopic easter eggs :) The code is pretty jank (and abandoned), but it's FOSS vanilla JS/HTML/CSS, and the only dependency is on OpenLayers: https://github.com/arcataroger/openlayers_indoor_map https://github.com/arcataroger/openlayers_indoor_map

Solvency 2y ago

just because this zooms doesn't mean you made a ZUI. the spirit of a ZUI is change of information/density/etc at different levels of zoom. like google maps.

hateful 2y ago
Or that infinite scroll game of life that was on here a few weeks ago! more density, same information!

tomthe 2y ago

Wait, how is this possible?? I tried to visualize a few tens of MB of text in the browser [1] on a canvas and it gets really choppy if I don't optimize it by not showing stuff that can't be read. Impressive that it can handle gigabytes of text! [1]: https://tomthe.github.io/hackmap/ https://tomthe.github.io/hackmap/

wongarsu 2y ago
I'd wager by making the requirements simpler. Wideboard is rendering monospace, so every document is made up of of 8x16px cells, and you just have to decide which glyph to render in each. From a quick skim of the source code this is mostly precalulated. Basically each document is rendered as one rectange, where the shader converts the current position to the row/column of the character to be rendered. There is one texture that holds the length and starting offset of each line (using one pixel per line), and another texture that for each offset tells you which glyph to render (using one pixel per glyp). The third texture is the glyph map that holds the actual glpyhs (a simple 256x256 texture of all supported characters). The last texture is static, the other two are calculated once as the document is loaded, and there is a neat shader that uses all three textures to render the actual document view. Since the shader is sampled at fewer points if the rectangle takes up fewer pixels on your screen this works out well for zoomed out views.