The Tree Slider - GitHub

https://github.com/blog/760-the-tree-slider

by sant0sk1 • 16 years ago

182 34 16 years ago

storborg3• 16 years ago

I would love it if this widget eager-loaded the directory structure for a couple levels (doesn't even need to load the commit data) so that it made the navigation to a specific file/folder even faster.

solutionyogi• 16 years ago

When I saw the video, I thought it was 'speeded' up. But the repo browser is as fast as what they show in video.

Try jQuery Mobile repo:

https://github.com/jquery/jquery-mobile

[Obviously, you will need Chrome/Firefox 4/Safari.]

alnayyir• 16 years ago

Very nice, but I wish they would cut the animation.

tjarratt• 16 years ago

Actually I don't think that's necessary - I'd much rather they focus on making individual loads very fast, instead of pre-loading data. 9 times of out 10, I'm not going to peruse the ENTIRE directory structure even one level deep, so it should only get the data I want.

Also, they would need to store that, and I don't necessarily want my browser storing my entire directory structure (and possibly file contents) for any amount of time other than when I'm actually browsing it.

Try it out, it really is very fast without having to eagerly load anything at all.

pjscott• 16 years ago

They could build a page-transition graph: for each page, what are the links that people are most likely to click? This could let them figure out what the top one or two most common next-pages are, and those could be pre-loaded.

That would be more work for the GitHub guys, but I'm pretty sure it would work.

storborg3• 16 years ago

The individual load still takes a full HTTP round trip, which is going to be slow no matter how you slice it. Comparatively, storing several layers of a directory structure (all you need is file/directory names in a JSON tree) is pretty tiny.

binaryfinery3• 16 years ago

A sliding UI is worth #2 HN spot? Wow.

olalonde• 16 years ago

If I'm correct, it's interesting because the transition is done without using a URL fragment (http://url/#fragment).

binaryfinery3• 16 years ago

FTFA: "Want more? Check out the HTML History API Demo and MDC's Manipulating the browser history documentation. Facebook has blogged about their use of this stuff, and Flickr has been doing it for months on their lightbox view."

So, its not even news. Unless, I suppose, the reader learned javascript in 2001 and feels they don't need to keep up on new things. That's the HN crowd is it?

Fuck, I've been learning javascript for a week and I know how to do this.

cool-RR• 16 years ago

Great! I've been looking forward to this feature for a long time.

wmf• 16 years ago

It looks like the sliding transition may also mask network latency; clever.

kellysutton• 16 years ago

The best transitions are those that mask loading of something else. Ever think of why icons on the iPhone explode out when opening an app or the app image zooms to the front?

patio11• 16 years ago

Back when BCC was a desktop application, I once got complaints that someone missed my "busy bees" on the splash screen after she upgraded her computer. The JRE load hit below one second and she didn't see the screen anymore.

jws• 16 years ago

From the Digital Equipment Corporation, VMS Guide to Performance Tuning, from before 40% of the HN readership were born:

  5.3.4.3 Lower the Baud Rate if Terminals Smooth Scroll
    If many of the applications at your site write characters to
    terminals in the smooth scrolling mode … you might consider 
    reducing the baud rate [from 9600 to 4800] …  the decrease in
    the baud rate would be barely perceptible to the users.

VT100 transitions come to the rescue!

(Smooth scrolling was at 6 lines per second. Glassy smooth, especially if you kept the line saturated to the flow control limits. But as a consequence it couldn't accept more than about 4000bps of data on 80 character lines.

That particular hint never made much sense to me because it is about saving interrupts and a screen of data took the same number of interrupts at 4800 or 9600. I think it was more about slowing down the users without them noticing to avoid upgrading the computing resources.)

borism• 16 years ago

"A century after the wireless telegraph revolutionised communications, the Internet has re-established a telegraph that runs on (telephone) wires." -Umberto Eco,

who's essay was widely criticized here yesterday for some factual mistakes. He did get one thing right though.

bodhi• 16 years ago

And thankfully they didn't screw up the ability to open links in a new tab.

muitocomplicado• 16 years ago

Agreed, would like to see this applied to Issues.

jfager2• 16 years ago

Very nice, but what I'd personally rather have is a two-pane navigator: explore the tree in the left pane, see file contents in the right, a la NERDtree, eclipse, and other IDEs.

jdminhbg• 16 years ago

This isn't [only] two panes, but it gives you the ability to navigate files while still seeing the directory structure: https://github.com/sr3d/GithubFinder

It's implemented as a bookmarklet that you can activate on any github repo for an advanced view.

jfager2• 16 years ago

That is beautiful, thank you.

compay• 16 years ago

I find the animation to be rather annoying.

yan• 16 years ago

I guess this is a good place to ask, but does anyone know why GitHub opted not to list the file size in the file viewer? Whenever I browse other peoples' code I always want to glance at file sizes to see which files I should peruse first.

cdavid• 16 years ago

Maybe because it is difficult to do so efficiently ? It is hard to get per-file information in git, so you would have to be pretty clever to get it working w.r.t. history.

Other bugtrackers which were based on svn had a lot of issues with git because of this.

marknutter• 16 years ago

I wonder if this is better than sammy.js

The Tree Slider - GitHub

Related Stories