Introducing the Command Bar | Hacker News Reader

Introducing the Command Bar

github.com

419 pointsdko98 comments

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.

For a universal search bar I've been wanting to implement a chat bot style thing for issuing actions:

   /find search term

Which is actually the same as not including "/find"... it acts like a search box when not told otherwise.

   /goto inbox
   /goto home

Navigation to common pages.

   /me is dancing

That one updates your status.

   /me slaps [user] with a trout

Is the equivalent of a Facebook poke I guess.

i'm not trying to be a jerk, i swear, but Google (especially since the autocompletion and nigh-instant results) would count, i think.

Gmail has something similar, try to press G L and then start typing to move to a label. Might require something to be activated from labs though.

That is cryptic keypress shortcuts, not quite command lines.

Playing with this for a few minutes:

* I wish it had vim keybindings (ie, hit esc, then use hjkl to navigate)

* It gives me the option to follow myself. (Bug?)

* I like how I can learn commands via the autocomplete bar (issue, branch, graph, etc)

* I like how the autocomplete bar refreshes after I have control-tabbed away and back. Too many autocompletes lose this behavior

* Searching in a repository username/repo <searchterm> doesn't work the way I expect. It just brings up the regular search

Overall, very useful though.

I'd be pretty happy with Ctrl-(1-9) to action the nth item in the visible list.

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.

Ctrl-[1-9] is the hotkey for Firefox (not Alt-[1-9]).

Actually, it depends on the platform, it's Ctrl on Windows and Alt on Linux (and Command on Mac).

Well, learn something new everyday....

+1 for vim keybindings. I noticed JIRA actually has these the other day (the only thing I like about it).

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.

Pentadactyl requires Firefox and Firefox is a memory eating pig.

Thankfully, not here (it's using 300MB of Resident Memory after being open for days). On what OS are you?

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.

Tab Mix Plus, an addon for Firefox allows multi line tab lists and is very customizable.I have been using it for years.

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.)

[emphatic] Vimium user here.

Would you accept a pull request to satisfy https://github.com/philc/vimium/issues/61?

Like many of the commenters there, I often only find myself reaching for the mouse while browsing to select and copy text.

If it's something you're open to I'd be willing to give it a shot.

It seems like it should emulate readline, doesn't it?

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 ;)

Or that its vim bindings are TOO natural and thus call undue attention to the inevitable incompleteness of its vim "implementation"

It'd also be nice if it had focus on page load.

I can type 's' rather quickly.

Ah missed that part. Good to know.

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).

One of the several reasons that I use Ctrl-[ or Ctrl-C. ;)

Just use VIM proper; after all, It's All Text! https://addons.mozilla.org/en-US/firefox/addon/its-all-text/

(alternatively, use Pentadactyl and press C-i when the focus is on a text box)

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.)

[1] http://twitter.com/jnunemaker/status/247800799625887744

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.

Try Vimium. converts entire browser to vim bindings

http://vimium.github.com/

I use Vimperator, which has a similar sense to it

Among the problems created: overlap and conflict between browser and site keybindings.

I hate sites that have vim bindings as i already uses vimium for chrome. Im looking at you fffound and vimeo!

The site is called VIMeo.

Cool toy, but how about letting users just search for code in a repo properly?

+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.

Even slightly-delayed searching would be a huge deal, engineeringwise.

They're working on it: Check out the search box in the right side of this screenshot from a github blog post a week or so ago:

https://a248.e.akamai.net/camo.github.com/367fe330bc1ad4431b...

The post itself mentioned: "Spoiler alert: you might notice a few things in this screenshot that haven’t fully shipped yet."

Well, we already have a command bar at the top of the window. What about these commands?

    http://github.com/username
    http://github.com/username/follow
    http://github.com/username/unfollow
    http://github.com/me/dashboard
    http://github.com/me/notifications
    http://github.com/username/reponame/search/term
    http://github.com/username/reponame/branchname

What is your point? REST is meant to make it easy for machines to talk to each other.

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.

My point is that the address field of my browser is already a "command bar" and that the URI is already a command line.

With a carefully chosen URI scheme, 100% RESTful or not, you have your command bar.

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...

Agreed.

The one command-line feature I want most on Github is `git grep`. I have cloned projects locally solely to be able to do that.

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.

To remind everyone how awesome xkcd's commandline is:

http://uni.xkcd.com/

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?

I don't really get why they built this... Anyone?

hitting 's' anywhere on the page activates the command bar. I will use this a lot.

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?

Well, I can't speak for burke, but I use GitHub Enterprise at work. Once this trickles down to GH:E, I'll probably use it very regularly.

I'm a developer at Shopify, and all of our development happens on Github. I also spend a fair bit of time working with issues on open source projects.

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.

Thanks for the 's' tip.

Too bad they didn't also use '/', like gmail and atlassian products.

A downside of using '/' is that it is already used in Firefox to mean search-in-page.

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.

Ah, this makes a lot more sense to me now. Pretty cool!

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.

With vimium[1] you get most of the keyboard-functionality in Chrome that Pentadactyl offers for Firefox.

[1]: http://vimium.github.com/

Or use vrome[1]. [1]:https://github.com/jinzhu/vrome

Vimium is awful compared to pentadactyl.

If you want a command line for your own site, you can use the GCLI project (BSD licensed, use it freely!)

https://github.com/mozilla/gcli

This is the command line that's in Firefox 16's Developer Toolbar (final release is coming in early October):

https://hacks.mozilla.org/2012/08/new-firefox-command-line-h...

I love command lines, personally :)

Nice. I wish more GUIs had this kind of capability.

Long live the command line. At least until I get my neural implants.

This is similar to a plugin I have been using in Alfred for quick access to Github (but not nearly as feature complete):

https://github.com/KevinSjoberg/github.alfredextension

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.

Note, Chrome junkies, the Firefox awesome bar already does most of these :)

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.

I put together a little admin command line that you could bring up with the ~ key that looks like this: http://i.imgur.com/mq7ko.png?1

It is built for asp.net but you could easily apply the same concept somewhere else. More info if anyone is interested: http://lukencode.com/2011/12/11/netbashan-alternative-to-end...

I think it would be even better to have some terminal emulator on github. Even now with so improved UIs I like command line interface.

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?

I'd like to search for repos, create new repos, create initial files, edit existing, star/unstar, watch/ignore, work with messages etc.

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.

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.

You may want to check a few CLI tools:

https://github.com/defunkt/github-gem

https://github.com/defunkt/hub - http://defunkt.io/hub/

You only miss one thing:

* map the '/' symbol to focus:search box.

What about Opera users?

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.

As burke noted above (http://news.ycombinator.com/item?id=4534670), pressing 's' will activate the search bar.

This was also the one thing I was missing from the post. I did try '/' as well.

It looks like ctrl-/ works.

Giving the type of people who like command lines a command line -- not a bad idea!

The down side is that, I think, this is really only useful for the github power user. The upside is: I'm a github power user!

Seriously, though, I hope they don't use this command line as a sort of cop-out for continuously improving their UI.

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.

It was already shown here https://github.com/blog/1252-how-we-keep-github-fast. So we could have known it would come.

Am I the only one who thought this was going to let me run git commands?

yeah me too. then i realized this would do for a web interface

I wondered why the "search" bar had suddenly got really slow today and caused Firefox to freeze a little bit when using it.

Need to juice the performance a bit I think

Great feature - I really like it. My only request is that the suggestions be clickable links so that you can open one in a new tab.

Don't you use the browsers address bar for that?

Now I just need an Alfred extension that talks to the backend URLs

cool, but how about making it context (page) aware, so you could write just "@watch" on a repo's page?

Death to the CLI/GUI religious wars.

Reply on news.ycombinator.com