Improve cells discoverability and UX

[ccordoba12]

Last Tuesday @isabela-pf mentioned a couple of very nice ways we could improve our cells support in Spyder:

• Add a button in one of main toolbars to create a new cell. Even if that's a very simple operation, having a button will allow people to become aware with that functionality more easily.
• Make the cell divider to cross the line numbers are too. That will help to better realize that cells break a file in sections.

[ccordoba12]

From my side, I'd like to mention other suggestions:

• Add an entry to our tour describing cells.
• Show a message to tell people how to run cells after they introduce the first one with the button Isabella suggested.
• Show a similar message when people select a text and run it (again, only the first time they do it).

[felixchenier]

This is not completely related, but this would be a way to settle on the "spyder-approved" way to write a cell: is it #%% or # %% (with a space)?
Both work, but the first one (which I suspect to be the spyder-suggested one) generates linter style warning that a space should follow the # in comments. If the first one is the correct version, maybe a default option for the style linter should be added to ignore this very instance of a space after a #.
I know, this is very, very minor :-)

[ccordoba12]

About my comment above: my proposal is that the first time users press the new Cell button, we show a message similar to the introductory tour one:

but asking them to take the cells tour. This tour can have the following steps:

1. Describe what a cell is and how to create cells. In this step I propose to load a file with two sections: an "imports" section and a "computation" one (for instance, this file could use the math module to compute the first 500 primes). After loading it, we should put the cursor between these two sections (which would be separated by a couple of blank lines), highlight the cells button in a red square, like we do for the editor line number area in the current tour

   

   and ask users to press it.

2. How to run cells. If users didn't press the cell button, we'd need to introduce a cell automatically before moving to this step. Besides, we should move the cursor to the first cell (the "imports" one), highlight the "Run and advance cell" button and tell users to press it twice and see the results in the console. The message on this step should also mention that they can use Shift+Enter to execute and move from one cell to another.

3. How to run a single cell. Here we can tell users to increase or decrease the number of primers they want to compute. Then we can highlight the "Run cell" button and tell them to press it to get a new result by only running that cell.

4. Debug and profile cells (see PR PR: Profile in the IPython console to gain access to variables and get a result in case of cancellation spyder#15372). We can highlight the buttons to do that and tell users they can also debug and profile cells if they want. Then we can tell them that we're going to profile the cell that computes primes and ask them to press the button for it. Before entering this step, we should give focus to the Profiler so that users can see the obtained results.

[CAM-Gerlach]

Eh, I'm not sure its worth presenting a whole tour about it, as opposed to maybe adding one additional step to our current tour that includes it, given setting up and fine-tuning these tours are very complex and error-prone—it took us two people working on it for a week to get the current one (mostly) working properly, and that was with already having it partially developed.

It might be a more efficient use of resources to give users a brief summary in the UI, and then link them to a tutorial video (which IIRC we have already) where we explain them further.

[ccordoba12]

Eh, I'm not sure its worth presenting a whole tour about it, as opposed to maybe adding one additional step to our current tour that includes it

The idea is to show this tour after users press the new Cell button (as I mentioned above). That would make your suggestion a bit unsuitable for this use case. And, instead of a single step that could easily underestimate cells' significance in Spyder, we can provide a more complete tour (like the one I suggested above).

given setting up and fine-tuning these tours are very complex and error-prone—it took us two people working on it for a week to get the current one (mostly) working properly

Well, the good thing about this is that @jsbautista could work on it thanks to the NF grant we got.

It might be a more efficient use of resources to give users a brief summary in the UI

I disagree because a single step in a tour that users can easily dismiss (because it's the first thing shown to them) could be quite easily overlooked by them.

[CAM-Gerlach]

Okay, well if @jsbautista can work on it anyway, then I guess its okay; I just know how many days of effort and debugging went into making relatively modest additions to the existing tour, especially getting it to work reliably across platforms, but if you think its worth the benefit then go ahead of course, and let me know if you want help with the UI text.