3 ms·

I would love to have a file manager implementing hyperbolic navigation. I am not even sure why it is not a common feature of file managers.

mikewarot 4y ago
It displays ALL of the nodes, given the millions of files and thousands of folders on a typical computer these days, some form of pruning would be required. Just loading all the nodes would take a few minutes on most computers.
- ykonstant 4y ago
  >some form of pruning would be required. ...sure. There you go.
- danbruc 4y ago
  There is no reason that processing a few million files could not be done at interactive speeds. Searching for certain filenames on Windows is awfully slow with Explorer, but there are tools like UltraSearch [1] which directly scans the Master File Table of NTFS volumes and will find all matching files orders of magnitudes faster. Also the UI is not a problem, I experimented myself with something vaguely similar and it was relatively easy to have millions of nodes - I think I just used plain buttons controls for nodes - in WPF at interactive speed. I think it somehow involved quadtrees to make it fast, just naively instantiating millions of buttons did not work, but it was doable. This was however ages ago and my memories are quite fuzzy. [1] https://www.jam-software.com/ultrasearch_free https://www.jam-software.com/ultrasearch_free
  - d_tr 4y ago
    Interesting. Why doesn't the built-in search feature use a similar technique then?
    - danbruc 4y ago
      Because Explorer certainly relies on APIs that abstract away the file system details and the smallest common denominator is probably recursively walking the tree structure of the file system which is orders of magnitude slower than scanning through a few megabyte of a central database.
      - anigbrowl 4y ago
        Also it tries to search within files. I have a huge document library and it's often faster to look up a partial filename from the command line than to use Explorer's search, is slow and buries the file I want amid hundreds of irrelevant results.
DonHopkins 4y ago
https://www.cs.umd.edu/hcil/treemaps/ https://www.cs.umd.edu/hcil/treemaps/ Treemaps for space-constrained visualization of hierarchies. Including the History of Treemap Research at the University of Maryland Started Dec. 26th, 1998 by Ben Shneiderman Later updates by Ben Shneiderman and Catherine Plaisant - Last update Sept 2014 A History of Treemap Research at the University of Maryland During 1990, in response to the common problem of a filled hard disk, I became obsessed with the idea of producing a compact visualization of directory tree structures. Since the 80 Megabyte hard disk in the HCIL was shared by 14 users it was difficult to determine how and where space was used. Finding large files that could be deleted, or even determining which users consumed the largest shares of disk space were difficult tasks. Tree structured node-link diagrams grew too large to be useful, so I explored ways to show a tree in a space-constrained layout. I rejected strategies that left blank spaces or those that dealt with only fixed levels or fixed branching factors. Showing file size by area coding seemed appealing, but various rectangular, triangular, and circular strategies all had problems. Then while puzzling about this in the faculty lounge, I had the Aha! experience of splitting the screen into rectangles in alternating horizontal and vertical directions as you traverse down the levels. This recursive algorithm seemed attractive, but it took me a few days to convince myself that it would always work and to write a six line algorithm. This algorithm and the initial designs led to the first Technical Report (HCIL TR 91-03) in March 1991 which was published in the ACM Transactions on Graphics in January 1992 (http://www.acm.org/pubs/citations/journals/tog/1992-11-1/p92-shneiderman/ http://www.acm.org/pubs/citations/journals/tog/1992-11-1/p92...). Choosing the right name took probably as long, but the term 'treemap' described the notion of turning a tree into a planar space-filling map. My initial design simply nested the rectangles, but a more comprehensible design used a border to show the nesting. Finding an effective visualization strategy took only a few months but producing a working piece of software took over a year. Brian Johnson implemented the algorithms and refined the presentation strategies while preserving rapid performance even with 5,000 node hierarchies. The TreeViz application ran on color Macintosh models and led to the widely cited paper (HCIL TR 91-06) jointly authored paper in the October 1991 IEEE Conference on Visualization. This paper was reprinted in Readings in Information Visualization. I think treemaps are a convenient representation that has unmatched utility for certain tasks. The capacity to see tens of thousands of nodes in a fixed space and find large areas or duplicate directories is very powerful. I still use TreeViz for cleaning up my Macintosh. It does take some learning for novices to grasp the tree structure layout in treemaps, but the benefits are great. PhD student Brian Johnson's implementation added many other interesting features such as zooming, sound (as a redundant or independent code, for example, larger files had a lower pitched sound), hue/saturation control, many border variations, and labeling control. We struggled to deal with the problem of many small files in some directories, but wound up showing only a blackened area that invited closer examination by zooming. We knew that encoding a linear variable such as file size as an area was breaking a graphic design guideline, but the benefits of seeing a large range of file sizes seemed like a compensation. We also knew that visually comparing long narrow rectangles to squarish ones was problematic, but cursoring over the boxes produced the exact file size on the bottom of the display. [...]

mikewarot 4y ago

It displays ALL of the nodes, given the millions of files and thousands of folders on a typical computer these days, some form of pruning would be required. Just loading all the nodes would take a few minutes on most computers.

ykonstant 4y ago
>some form of pruning would be required. ...sure. There you go.
danbruc 4y ago
There is no reason that processing a few million files could not be done at interactive speeds. Searching for certain filenames on Windows is awfully slow with Explorer, but there are tools like UltraSearch [1] which directly scans the Master File Table of NTFS volumes and will find all matching files orders of magnitudes faster. Also the UI is not a problem, I experimented myself with something vaguely similar and it was relatively easy to have millions of nodes - I think I just used plain buttons controls for nodes - in WPF at interactive speed. I think it somehow involved quadtrees to make it fast, just naively instantiating millions of buttons did not work, but it was doable. This was however ages ago and my memories are quite fuzzy. [1] https://www.jam-software.com/ultrasearch_free https://www.jam-software.com/ultrasearch_free
- d_tr 4y ago
  Interesting. Why doesn't the built-in search feature use a similar technique then?
  - danbruc 4y ago
    Because Explorer certainly relies on APIs that abstract away the file system details and the smallest common denominator is probably recursively walking the tree structure of the file system which is orders of magnitude slower than scanning through a few megabyte of a central database.
    - anigbrowl 4y ago
      Also it tries to search within files. I have a huge document library and it's often faster to look up a partial filename from the command line than to use Explorer's search, is slow and buries the file I want amid hundreds of irrelevant results.

DonHopkins 4y ago

https://www.cs.umd.edu/hcil/treemaps/ https://www.cs.umd.edu/hcil/treemaps/ Treemaps for space-constrained visualization of hierarchies. Including the History of Treemap Research at the University of Maryland Started Dec. 26th, 1998 by Ben Shneiderman Later updates by Ben Shneiderman and Catherine Plaisant - Last update Sept 2014 A History of Treemap Research at the University of Maryland During 1990, in response to the common problem of a filled hard disk, I became obsessed with the idea of producing a compact visualization of directory tree structures. Since the 80 Megabyte hard disk in the HCIL was shared by 14 users it was difficult to determine how and where space was used. Finding large files that could be deleted, or even determining which users consumed the largest shares of disk space were difficult tasks. Tree structured node-link diagrams grew too large to be useful, so I explored ways to show a tree in a space-constrained layout. I rejected strategies that left blank spaces or those that dealt with only fixed levels or fixed branching factors. Showing file size by area coding seemed appealing, but various rectangular, triangular, and circular strategies all had problems. Then while puzzling about this in the faculty lounge, I had the Aha! experience of splitting the screen into rectangles in alternating horizontal and vertical directions as you traverse down the levels. This recursive algorithm seemed attractive, but it took me a few days to convince myself that it would always work and to write a six line algorithm. This algorithm and the initial designs led to the first Technical Report (HCIL TR 91-03) in March 1991 which was published in the ACM Transactions on Graphics in January 1992 (http://www.acm.org/pubs/citations/journals/tog/1992-11-1/p92-shneiderman/ http://www.acm.org/pubs/citations/journals/tog/1992-11-1/p92...). Choosing the right name took probably as long, but the term 'treemap' described the notion of turning a tree into a planar space-filling map. My initial design simply nested the rectangles, but a more comprehensible design used a border to show the nesting. Finding an effective visualization strategy took only a few months but producing a working piece of software took over a year. Brian Johnson implemented the algorithms and refined the presentation strategies while preserving rapid performance even with 5,000 node hierarchies. The TreeViz application ran on color Macintosh models and led to the widely cited paper (HCIL TR 91-06) jointly authored paper in the October 1991 IEEE Conference on Visualization. This paper was reprinted in Readings in Information Visualization. I think treemaps are a convenient representation that has unmatched utility for certain tasks. The capacity to see tens of thousands of nodes in a fixed space and find large areas or duplicate directories is very powerful. I still use TreeViz for cleaning up my Macintosh. It does take some learning for novices to grasp the tree structure layout in treemaps, but the benefits are great. PhD student Brian Johnson's implementation added many other interesting features such as zooming, sound (as a redundant or independent code, for example, larger files had a lower pitched sound), hue/saturation control, many border variations, and labeling control. We struggled to deal with the problem of many small files in some directories, but wound up showing only a blackened area that invited closer examination by zooming. We knew that encoding a linear variable such as file size as an area was breaking a graphic design guideline, but the benefits of seeing a large range of file sizes seemed like a compensation. We also knew that visually comparing long narrow rectangles to squarish ones was problematic, but cursoring over the boxes produced the exact file size on the bottom of the display. [...]