UI organization (toolbars and panes)

In a few meetings, we’ve discussed questions of how major areas of Spyder’s UI are placed and interact with each other. This issue serves to document those discussions and explore potential solutions. We are focusing mainly on toolbars/buttons and default pane placements (especially the upper right one where lots of panes live together).

Problems

Almost every pane besides the editor and console being thrown in one corner has a few consequences
- That corner doesn’t have meaning or organization. It’s a catch-all
- A lot of things in a small space (or a space that’s the wrong orientation, like putting vertical content in a horizontal box) means little content is visible at once. This is true of the pane content and pane names/tabs.
The few panes that aren’t in the upper right corner (Outline, Projects) feel strange being the only panes in their respective areas. It also takes up a lot of unnecessary space.
Discoverability of non-main panes and many Spyder features is difficult. Looking in the main/OS menu isn’t as common.
Some users (especially new or potential users) might find the UI overwhelming or challenging to navigate because so many panes and buttons are shown by default.
Certain panes make sense to use in groups or when focusing on a specific activity. Right now, the UI does not encourage or enhance that experience.

Potential solutions

Reorganize existing toolbars
Change which panes appear as default
Create a sidebar that groups certain panes based on what they are used for, which panes go together, or something like that
Make it easier to show and hide panes so that we can afford to show less by default

Things to consider

The ability to easily reorganize Spyder’s panes might be a draw for some users. Should we and how do we preserve that?
Sidebars are a more common solution in similar software. Will solutions like this interrupt the way panes work and the experiences that make Spyder unique?
Be cautious of breaking up Spyder’s UI even further. More buttons or panes or pane locations can easily create more problems than they solve.

With this many problems and the high impact of changing main organizing principles of Spyder in mind, this will take a good bit of thought (and hopefully testing). As always, feedback is appreciated! Have I missed a problem or consideration? Do you have an idea for a solution? Please chime in.

I’m working on mocking up a variety of options for dealing with the main toolbar since it has a mix of levels of information (some parts are for all of Spyder, others more closely associated with specific panes or activities). This is a similar train of thought as to what I brought up to make more room for buttons that affect all of Spyder in early #8, but also more comprehensive.

Even though I’m not posting mockups yet, I surveyed a few members of the Spyder team about their associations (both on a pane and use case level) with all the items in the main toolbar. It’s a small sample, but it’s helping me get a few different perspectives about the main areas of Spyder interact with each other and different work flows. Here are a few patterns I’m seeing working through that:

There seems to be a lot of agreement on what buttons go with what. That should be good for making decisions about where these items belong!
A majority of the main toolbar was associated with the editor, more often than any other option. Could this mean that the editor should have its own unique toolbar, or that the editor is perhaps enough the core of Spyder for it to make sense letting so much of it be in the main toolbar? A point for further discussion.
The debugging-focused buttons are the only items that have the most association with the console (others might have a few votes, but the debugging buttons are lead by the console). This aligns with some of our previous discussions as well.
Participants tended to associate a button with either one of the use cases/activities listed or most of the list. I’m not sure if this is helpful info or not yet, but it was interesting since we’ve talked a little about alternate ways to organize or prioritize features than their associations with panes.

Side note: in other meetings, we’ve also discussed the place of the additional main toolbars (found in the main menu) that hide several useful features. Though we’ve been discussing them as separate issues, the choices go together and will probably converge soon.

Here’s a few more thoughts on how this is progressing. Right now, I’m still focused on the feedback I got from some of the Spyder team members with particular focus on how they relate options currently in the main toolbar to the rest of Spyder’s panes (not diving too much into activity/workflow association yet). Since I ran a kind of card sort, I’m presenting where each button was sorted most often both as a list and with the icons grouped visually like they are from a true card sort. A few of these were very close, but it’s only sorting between the editor and console that almost or actually ties.

Popular sorting results

All of Spyder

Maximize Current Pane
Fullscreen Mode
Preferences
Working Directory (and navigation)
Browse a Working Directory
Change to a Parent Directory
Editor
New File
Open File
Save File
Save All Files
Fast Switch Between Files
Fast Symbol Search in Files
Run File, Run Current Cell
Run Current Cell and Go to the Next One
Run Selection or Current Line
Run Again Last File
Debug File
Run Current Line
Editor and Console (tie)
Step Into Function Method of Current Line
Run Until Current Method or Function Returns
Continue Execution Until Next Breakpoint
Console
Stop Debugging
Python Path Manager

I would not recommend allowing the popular results to be directly used as choices for toolbar placement. Still, here’s what that could look like in a simplified Spyder’s interface:

(It actually looks a good bit like the mockup in #8 that prompted this discussion a while ago.)

Individual sorting

I’m not listing these all out to save time. I wanted to include each sort because I think it is interesting to see them side by side rather than just what ended up being chosen most (because no individual actually made the most popular toolbar results).

Participant 1

Participant 2

Participant 3

Participant 4

Participant 5

Participant 6

Since these give us a more detailed understanding of possible in-team connections between features, toolbar buttons, panes, and how they might be grouped, my next thoughts will be around experimenting with how Spyder shows this content. This should also begin referencing the activity type part of the survey, too. I’ve already started sketching some potential toolbar or toolbar-like experiences other than that currently in Spyder or the one mocked up above.

Time to get a little wild! This week was experimenting with possible ideas for what to do with Spyder’s toolbars. All of these ideas are experiments to get us talking, not necessarily recommendations. There are a few different concepts we could choose to work around. And apologies in advance for how similar all the mockups look at first glance; we're working with details here.

First, here are a few changes that are (or are supposed to be, I make mistakes) in all the mockups:

Stop debugging is removed (because start debugging will switch when running)
Fullscreen button is removed. I think 4.2 might have already removed this because we realized it is only on Mac and doesn’t need to exist.
Maximize current pane is removed as a single button. I’d rather have it in the “more” menu on each pane so users can more easily tell which pane will be maximized.

Keep the same amount of toolbars and reorganize what is there. This means the main toolbar and what panes already have them.
Reorganize the existing toolbars and add more where relevant, particularly letting the editor and console have their own toolbars since they are major parts of the interface with features closely tied to them.

I’ve done some mockups (like above), but here's another idea.

Give every pane a toolbar, even if some of them would be more empty than others. Many of the panes that go to the upper right by default already do this to some degree. This also might let options/buttons be more spread out across relevant places rather than having a few very full toolbars.

Using the variable explorer as an example, here’s a how that could look.

Use less conventional “toolbars.” I think it is unlikely we will choose this direction, but I want to bring it up anyways.

My main thought right now is to group features that rely on/are only useable based on cursor placement and selection. (I haven’t given it deep enough thought on the interaction and I also can see a lot of problems with this example already.)

Have only one toolbar and have it change based on which pane is active. I could see this causing some problems, but I’m still at the point I want to propose a lot of different ideas I don’t think the team has discussed yet. For example:
Being able to switch between toolbars grouped by which features are commonly used in similar tasks. This could be used in combination with some of the above options, too. A simple example is the debugging buttons.

spyder-ide / ux-improvements