The Tree Slider - GitHub(github.com)
github.com
The Tree Slider - GitHub
https://github.com/blog/760-the-tree-slider
9 comments
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.
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.
It's implemented as a bookmarklet that you can activate on any github repo for an advanced view.
That is beautiful, thank you.
I find the animation to be rather annoying.
It looks like the sliding transition may also mask network latency; clever.
From the Digital Equipment Corporation, VMS Guide to Performance Tuning, from before 40% of the HN readership were born:
(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.)
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.
(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.)
"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.
who's essay was widely criticized here yesterday for some factual mistakes. He did get one thing right though.
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?
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.
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.
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.
Other bugtrackers which were based on svn had a lot of issues with git because of this.
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.
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.
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.
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.
That would be more work for the GitHub guys, but I'm pretty sure it would work.
Good idea, but _lots_ of work to implement it the right way.
Not to mention that the vast majority of Github repositories don't have enough traffic to properly build such a graph.
A reasonable fallback would be to look at the proportion of commits that touch files under each directory - the more active a directory is, the more likely it is to be of interest. Still probably not worth it in the majority of cases though.
I like that idea quite a bit, actually- I'm envisioning a sort of "heat map" UI, where each entry in a directory listing's background color is determined by its commit frequency.
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.
Have you actually tried the feature? (I'm honestly curious). Sounds like you're throwing around a lot of what-ifs for a problem that doesn't exist.
Yes, I've used the feature--I spend a lot of time every day using Github. At my office, where I have a fast connection, it works very well and I like it. At home, where I have a shitty connection, it's hardly faster than the old method.
I'm just pointing out that since they've changed the arrangement (e.g. no page reload when navigating between directories), they could take advantage of it to get a huge performance gain rather than a small performance gain.
I'm just pointing out that since they've changed the arrangement (e.g. no page reload when navigating between directories), they could take advantage of it to get a huge performance gain rather than a small performance gain.
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.]
Try jQuery Mobile repo:
https://github.com/jquery/jquery-mobile
[Obviously, you will need Chrome/Firefox 4/Safari.]
Very nice, but I wish they would cut the animation.
And thankfully they didn't screw up the ability to open links in a new tab.
Agreed, would like to see this applied to Issues.
Great! I've been looking forward to this feature for a long time.
I wonder if this is better than sammy.js
A sliding UI is worth #2 HN spot? Wow.
If I'm correct, it's interesting because the transition is done without using a URL fragment (http://url/#fragment).
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.
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.
It's interesting because it's been a major gripe on Github (at least in my circle), and now that they finally have it, we're all happy.
Relax, dude.
Relax, dude.
[deleted]
Awesome! Why don't you post your amazing UI for us to critique instead of complaining that not every single link that anyone likes is revolutionary?
[deleted]
I'll be honest, I have only seen this once before, and I do web development as my job. As far as I can tell, it's not that common on the web yet.
[deleted]
Well then, my apologies to all. I was genuinely surprised that this got so much news, but perhaps I shouldnt have been such a dick about it.