toolbar UI enhancements

[ivanov]

@takluyver and I were just discussing #4594 and had some ideas that we thought are worth capturing.

1. we should eliminate the "move cell up" and "move cell down" buttons. It only clutters the UI, and most user interfaces don't have such things, as "cut" and "paste" serve that purpose already.

   Especially once the multi-modal editing is merged and you'll be able to select multiple cells, that will be much more preferable to move many cells around (i.e. imagine selecting so many cells, that they all fill up the screen - moving them around will be really difficult, since you'll just be seeing those cells the whole time, and not the cells around them that you're trying to insert into).

2. We should have one "new cell" button, instead of the two ("new cell above" and "new cell below"). Just clicking that button should insert a new cell below, but we can allow for a long click to pop up a secondary menu of "Above" and "Below". As a minor point, @takluyver thinks that "New Cell" should be a button with text, unless someone can find or make a convincing icon for the action.

[ivanov]

Together, this would eliminate both pairs of up and down arrow buttons in the toolbar, and reduce the number of buttons there by 3.

[damianavila]

OK, I completely agree with the propose change... I think it would result in a more clean UI...
And looking at the font-awesome icons... I do not see anyone fitting the new cell button

[minrk]

I would be a bit reluctant to remove move up/down before we actually have shown that we have a better replacement with command mode, but I'm 100% behind replacing add above/below with single 'new cell' (below, presumably).

[ArcTanSusan]

1. I agree with fewer buttons and removing the move up/down pair.
2. I also agree. Instead of having the user choose where to add a new cell either above or below, we can simplify that choice. Have a single "new cell" button that adds a cell below by default.

[ellisonbg]

I completely agree that the two sets of up/down arrows is a horrible user
experience - I don't think anyone can keep them straight.

I like the idea of replacing the insert above/below pair by a single insert
cell button - maybe a plus button?

However, I think it is important that all basic notebook UI actions are
available in the toolbar or menus. Moving cells up and down is a common
enough action that I think they do belong in the toolbar. One of the user
experience ideas that I think we need to strive for is that the UI requires
no learning to get started. When users start out, they are not going to use
keyboard shortcuts at all - probably not even for running code. We can't
hide basic actions such as move up/down from these new users - it will just
anger them.

Another point is that I think the notebook needs to be easy enough for
junior high-ish aged kids to be able to use with no instruction about the
UI. As a matter of history, when I was first designing the notebook UI, I
had my 13 year old son play with it for hours with no instruction (I
actually paid him!). A lot of the current UI design came from my watching
him do this. The current UI has some serious problems, but I don't want us
to forget about non-expert users as we solve those problems.

On Wed, Nov 27, 2013 at 4:31 PM, Susan Tan notifications@github.com wrote:

I agree with fewer buttons and removing the move up/down pair.
2.

I also agree. Instead of having the user choose where to add a new
cell either above or below, we can simplify that choice. Have a single "new
cell" button that adds a cell below by default.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4610#issuecomment-29431561
.

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

[ArcTanSusan]

@ellisonbg, please see the new prototype based on your feedback in this PR: #4594

[takluyver]

I think the move-cell-up/down buttons are useful for now, but once we have the dual mode editing, and it's possible to select multiple cells, cutting and pasting will become the order of the day. That's hardly advanced - every high school student is familiar with cutting and pasting. It's swapping pairs of adjacent cells that's currently peculiar to our UI.

[damianavila]

I agree with @takluyver here... the moving up/down buttons are causing confusion to the newbie right now... in a dual mode editing, they would be a mess...

[ruffsl]

As a user of Mathematica, Matlab, and Maple Soft, I really liked having the insert up and down UI buttons. I guess I've grown accustomed to this UI feature as this is quite similar to what I've expect from the other platforms I've listed.

It sounds like most of you are gun ho about simplifying this bit of the UI, which I agree is best. But would there be anything for an advance user to customize or revert just this UI alteration within the config?

When I insert a new cell or a buffer of empty cells, I like to quickly be able to generate a buffer for working area just above or bellow a cell I'm debugging. I suppose a good analogy would be when your writing a paper or report, you may like to hit the carriage return a couple times to space out some room in the cluttered doc for your new thoughts. Because code is a bit more sequential, I debug both above and below the portion I'm testing.

I think the main issue is that as the keyboard shortcuts are a not as ergonomic or intuitive, the absence of the button in the newest notebook has hampered me a bit in forcing me to consonantly scroll around and select cells using my clumsy cursor (in order to insert multiple cells above). Something that can get quite tedious if you ever let your cell or cell outputs grow a little too large.

I would suggest that a method of teleporting one's cursor from cell to cell could mitigate this issue, alleviating people everywhere from needing to use terrible trackpads throughout the world. Perhaps this would be best extended as a keystroke, but we all know how barren the available keys combos can be in a we-browser, as proved with the need of resorting to modifier keys (by the way, do we need to limit ourselves? I've used web apps that have broken this mold. It's annoying when a normal webpage kidnaps my key combos, but I've come to expect it when a web app does).

Maybe 'Ctrl'+'B'+'up/down arrow' could suffice?

[Carreau]

Right now, extending the toolbar is not that hard ( old example I should update):

$([IPython.events]).on('notebook_loaded.Notebook', function(){
    IPython.toolbar.add_buttons_group([
        {
             'label'   : 'run qtconsole',
             'icon'    : 'ui-icon-calculator', // select your icon from http://jqueryui.com/themeroller/
             'callback': function(){IPython.notebook.kernel.execute('%qtconsole')}
        }
        // add more button here if needed.
        ]);
});

And as the all frontend is javascript/html/css, it is much easier to tweek that you imagine, you can see profusion of js extension if you search.

If you dig through open PR you will see that we are working on moving cursor/selecting cell etc.
The "configurability" is still a problem as we don't have a good way (yet) to send config from server to browser.

[takluyver]

The reason all our shortcuts are horrible at the moment is that between the CodeMirror editor and different browsers, almost all shortcuts are already taken. PR #3605 will bring us the idea of editing in separate modes, so you control cells with plain keyboard keys (e.g. b for insert cell below), and hit enter to go into text editing mode. So I guess you could say that we're taking keyboard use more towards the power user cases, and the toolbar a bit more towards discovery.

Turns out this UI stuff is hard. ;-)

[ellisonbg]

I think this work is done.