Wow, a command-line interface to a website is something I never thought I'd see.
My first reaction was that it's a step backwards because the usual benefits of a command line aren't present here (you're usually already using your mouse, commands can't be piped, no shell scripts to run things in sequence)...
But I'm intigued -- maybe it's a possible step forwards? The implementation is very well done. I suppose maybe it functions like traditional keyboard shortcuts in a way? To follow a user, instead of finding their page and clicking follow, you just type "@user follow".
Still, all the commands are so basic, and many are infrequently used, I don't really see much of the "shortcut" value. I'm very curious to see if this user interface concept grows. Imagine if this became a standard way to interface with web API's!
I know for one of the games I work on, the chat-commands/command-line interface is one of the most popular user interface features for power users. And the main reason is what you suggest about navigating and clicking. Admittedly, in a game you might "/equip meat helmet" or "/use mmj" a lot more frequently than you will friend someone on github, but it's a similar concept.
One could make a measure of velocity for hacker news posts about terminals/CLIs by measuring how fast it takes someone to gripe that it a)doesn't have vim bindings OR b) has vim bindings that feel unnatural ;)
I'd like to counter here that I prefer that sites don't assign vim bindings, or at least allow me to disable them. The reason being that I make extensive use of the vimium Chrome plugin (similar to pentadactyl on Firefox), which maps common vim keys to useful browser shortcuts (j/k to scroll, shift-j/k to switch tabs, f to enable a "type to click links" mode, etc). On 99% of the websites I use, I almost never need to touch the mouse, which is a especially appreciated when using a laptop with a nub mouse.
When websites use these common vim keybindings in an attempt to be helpful or "hacker cool", they completely bork my browsing setup until I disable the plugin for that site. My experience after that is usually a mix of awkwardly readjusting to the default browsing setup and reflexively trying to use vimium hotkeys and being surprised when they do something completely different. So, while Google Reader gets much "hacker" praise for its vim hotkeys, they make the site a lot more difficult to use for me -- there, accidentally hitting my "scroll down" button will scroll to the next article and make me lose my place, for example.
To web app developers, I completely understand that vim users that use plugins like vimium are a niche within a niche and not all that important in the grand scheme of things, but we would very much appreciate it if you bury the option to disable vim hotkeys somewhere in your site's settings menu. Very few people may be affected if you don't do this, but to those that are, it's even more frustrating than sites that remap the arrow keys, use touch events on mobile browsers, break "middle click to open in a new tab" functionality for no good reason by using javascript onclick events instead of standard anchor tags, or break pagedown functionality by covering up the top part of the document with a giant floating "like this on twitbook" bar.
I'm not trying to troll, but frankly, I don't understand why people who want to use advanced extensions like Vimium/Pentadactyl opt for Chrome and its crippling extension API.
With Pentadactyl, what you describe just isn't a problem: the extension captures the keys and prevents websites from screwing that up, unless you want to access them, in which case you just press C-z to enable 'Pass Through' mode.
I didn't take your comment as a troll -- I even considered mentioning that problem in my post. The trust and power that Firefox gives towards extension authors is certainly a strong point in its design for "power users" (letting, for example, Firefox adblockers prevent the ads from even being loaded, while Chrome adblockers can only hide the display elements). The thing is, though, no one browser is perfect; Firefox lacks Chrome's process isolation, support for the latest Flash plugin on Linux, I prefer Chrome's visual design and user interface, etc -- the point being that I prefer Chrome/Chromium for certain reasons external to extension capabilities, and I'm not willing to switch back to Firefox just to get my vim hotkeys to work on Google Reader.
I realize it's not fair to expect web app developers to adapt to my (or anyone else's) custom browser configuration, but in this particular case, they're adding vim hotkeys primarily as a convenience to fellow vim users, not as a defining feature of their site. Given that, I think they should be aware that there is a subset of those vim users who are negatively affected by their kindness.
Humorously, Chrome just completely crashed while I was writing this (running on the latest Quantal beta), prompting me to remove a bit I wrote about Chrome being more stable than Firefox due to its process isolation. I have a hunch that the fault lied in the Flash plugin, however, which doesn't seem to be terribly stable on Linux. I've never had a browser-wide crash on Chromium in the past, but not being able to watch certain Youtube videos and missing the convenience of Chrome's PDF plugin prompted me switch to it. Not sure I made the right decision.
I use Chromium over Firefox purely so I can open many tabs without having to scroll the tab bar. I use extensions to bind keys, block content, block scripts, etc. I realise these work better (and some only work) in Firefox. But the scrolling tab bar is a deal breaker.
Vimium dev here. We actually disabled Vimium on Google Reader because we were getting complaints about how it breaks Reader's own keybindings. If you wish, you can re-enable Vimium by going to the options page; once enabled, its keybindings should take priority over the page's own -- please file a bug if that isn't the case. (However, if you pressed a key that doesn't correspond to a Vimium command, it will automatically pass the keystroke down to the page's own key handlers.)
In multiple places on github, as a vim user, I occasionally instinctively hit escape. Github sometimes closes a comment box and I lose all the stuff I had been typing. It's an unfortunate UI issue for me (and probably others).
No! Ctrl-[1-9], switches between 1-8 and last tabs in Chrome. I know that Alt-[1-9] works too, and is even more cross-browser (works in Firefox), but I still prefer Ctrl. I'm not sure why, though.
Re vim bindings, this tweet[1] by John Nunemaker makes it seem unlikely. (Not actually sure how serious he is, but it's a funny tweet - and I say that as a Vim user.)
Perhaps a satisfactory solution for everyone would be to make "esc" defocus the input field? Github already has a "command mode" by default, and focus on the textbox can serve as the mode switching mechanism. The "s" key would then replace "i" in vim.
+1. The search results for this could merge in commits and be a really valuable way to figure out whats going on in a well factored, modular codebase where things can be spread out in many different tangled folders. Something like 'ack for github' would be fantastic.
For a site like GitHub, I would imagine this is a huge engineering effort to do right. For instance, in a plain vanilla code search facility, how would you expire results efficiently when the text can change from minute to minute (to seconds, to even less)?
Super efficient search would be great and idea, but slightly delayed searching is perfectly acceptable imo. Especially because I am not necessarily looking for extremely up-to-date changes.
That's no reason to stop imagining other UI modes. I found the idea of websites feeding browsers with completions for the omnibar and accepting direct actions as REST quite interesting.
Imagine you want to follow xyz on Twitter, you could open the full page, use the search, pop the pop-up and click follow, or you could type tw tab follow xyz enter in the omnibar.
Personally I don't relish the thought of memorizing the REST API of every website I visit. Anyways, it's not like they did away with the URI scheme you are describing...
This UI concept seems to be gaining in popularity. Jira 5 has a similar (though less powerful) option-completion action bar that you can pull up with a shortcut when viewing an Issue.
I've been considering adopting a similar concept for a complex enterprise application that I maintain where the number of possible actions on a certain page is huge.
I really like seeing this UI approach becoming more popular. I find it particularly worthwhile because I think it helps build familiarity without being limiting the way simple autocomplete can. This approach broadens the knowledge of the user — even (I think) in the case of something like GitHub where most users are particularly competent.
I like github for their sweet hosting and easy collaboration. I have no idea who would use this command bar. Do people really want to move the mouse to click on a cli and then guess/remember the syntax?
As someone who uses GitHub's web interface multiple times a day, the ability to dig down into specific actions and pages for a repo will save a lot of time clicking around. The big one for me, adding issues.
This is the killer feature of this, I am programmed for keyboard shortcuts, its why I'm productive in Vim, its why I use Gnome-do for launching, and its why I feel the web browser is my only real need for a mouse (Vimperator and the like don't seem to do it for me)
Once I hardwire a combination into my head, anything else feels slow and laboured to the point that I hate using it, and often I am found trying to use shortcut keys when a simple mouse touch would work better.
Some people are predominantly mouse people, and if they are productive doing this, this is of course ok, but a feature like this would be an added boon in my opinion for any website.
oh, that makes it much better. I only have a handful of repos and a few collaborators, so I don't really spend tons of time on GH. I imagine you spend more time than me to be excited by it -- what are you doing on there?
Not leaving the keyboard is one big thing. I ditched webkit for Firefox in order to be able to use Pentadactyl, but it's worth it to not have to leave the home row.
Learning a few commands is not hard, and there is always the ol' mouse to fall back upon if you don't want to remember all those commands.
This paradigm is very powerful. The only thing I see missing from these types of interfaces is the ability to select part or all of the output and use it as input for a new command.
Think of it as an intermediate step of piping where the user has the ability to manually filter content. This UI concept would cover the vast majority of UI needs as almost any workflow could be captured with the following...
1.) Issue command that produces 0..N results.
2.) View results in list format.
3.) Select individual results for details view.
4.) Select 0..N results as input to a subsequent command.
This seems like a step in the right direction, because GitHub's search remains awful.
For example, I can now type in "<user>/<repo> #123" to go to an issue, but if I am already on the Issues page for that repo and I type "#123" in the box labelled "Search: Issues & Milestones..." it still comes up with nothing. And that's not even challenging.
I'm desperately hoping that this feature is an indication that they've noticed that finding anything on the site requires either 8 million mouse clicks or manually editing URLs.
Keyboard is at least 100x as productive as mouse (assuming you know what to do and what to type). Even the best peachy UIs cannot change it. Still there are things that aren't convenient to do from CLI like photo retouching, but these are quite obvious exceptions.
That said, I'm not sure what would you like to do in such terminal?
My question was in fact about features that this command bar does not provide. Part of the ones you mentioned was already available before (like file editing), but simply not in a CLI-related manner. Some of these they could surely add, i.e. whatever can be put in this command bar yet not turning it into terminal.
If you're going to do real job, just do in your real terminal emulator, xterm, rxvt, you name it. What's the point of having GitHub terminal in browser? If you want to do quick'n'dirty fixes/improvements directly from the browser, then it's like asking yourself for troubles, because there is quite higher chance that you'll commit a mistake (even literally speaking) than if you'd be using your own terminal that you work with on a daily basis.
I agree that a keyboard is orders of magnitude more conducive to productivity, but I'm surprised that you do some of these frequently enough to make learning the commands a worthwhile endeavor, if one of these consoles were available. Even starring/unstarring is something that I do frequently, but I don't think I'd get any boost out of typing 'star' instead of just clicking on the star when my brain is already saying "make that star thing light up."
My point of view is based on personal experience. I explain it:
Git was initially a set of commands from terminal. A lot of programmers use terminal everyday. Even now I have terminal opened for doing different stuff. This terminal-nature of git itself and of github audience makes it obvious it would be used.
The other interesting question is how it would be implemented. With my repos on github (as opened as private) I think it would be great to have an opportunity to do some set of things from the site CLI.
P.S. I understand there are a lot of those who prefer GUI over CLI but I believe I am not the only one who wants to have CLI also available.
I find this really annoying, I use '/' to use the browser find-in-page, and apps hijacking it for their search field instead ruins it.
Yes, there are other bindings, but / is in finger-memory at this point.
I wonder if there's some sort of noscript-alike that would give you fine-grained enough control to permit exactly which keys could be intercepted by an app.
I want this for every website, and for most of the desktop apps I use. Typing, for me, is so much easier than finding menu items and clicking on them. Imagine Photoshop with an autocompleting command line instead of a maze of menus. I could work so much faster.
It is fantastic that a command interface is now a part of a very public system like github.
These things really speed up work for power-users and let maintainers add functionality without adding more complexity to the user experience than is appropriate.
This is awesome. I would love to see the concept of a website command line interface explored a bit further, hopefully Github implement something like Vim keybindings and a few other useful commands. The future is bright, man.
My first reaction was that it's a step backwards because the usual benefits of a command line aren't present here (you're usually already using your mouse, commands can't be piped, no shell scripts to run things in sequence)...
But I'm intigued -- maybe it's a possible step forwards? The implementation is very well done. I suppose maybe it functions like traditional keyboard shortcuts in a way? To follow a user, instead of finding their page and clicking follow, you just type "@user follow".
Still, all the commands are so basic, and many are infrequently used, I don't really see much of the "shortcut" value. I'm very curious to see if this user interface concept grows. Imagine if this became a standard way to interface with web API's!