PsychoPy Update: New Look/Feel

[TParsons]

Hi all,

Over the past month, I’ve been working on a new look and feel for PsychoPy, replacing the now quite dated wxPython default styles with a more modern, flat look. I’m pleased to say that this will soon be pulled into the master branch, so those of you using PsychoPy via Git will be able to try it out!

Below are some before-and-after screenshots of the Builder, Coder and Runner so you can see what’s different:

Builder

Coder

Runner

With this new look comes a new “dark mode”, for both the interface itself and the “theme” by which text is styled in Coder view:

Coder themes are now defined by .json files, so in the very near future we’re hoping to add functionality to allow users to write and install custom themes, similar to other code editors like PyCharm or Sublime Text.

This new look will be included in the next version of PsychoPy, so please do have a go with it, I’m keen to get any feedback now so that we can make any improvements before the next version release!

Thanks,

Todd

[wakecarter]

That’s a lot of red lines!

Since routines are green if they have a fixed duration and blue if they are endless, how about keeping the same colours for components.

Alternatively (and IMO even better), put endless components in red, responses that have no duration by can force the routine to end in blue and components with durations in green. That would give immediate feedback if, say, someone added a keyboard component which was endless and they forgot to click Force end of Routine.

Best wishes,

Wakefield

[TParsons]

Could do! There’s already code to change the colour of the lines when the component is disabled so it’s certainly possible to change colour depending on a parameter. What I’m wary of (and this is why we changed the routine colours to blue and green) is that people will see a red bar and think they’ve done something wrong, when in many cases an endless routine is actually what you want. Whereas, if all the bars are red, it’s clearer that this is just the colour that components are.

[wakecarter]

If the red bar is an endless routine without a Force end routine option ticked then you have done something wrong unless you have a code component to override the routine’s behaviour.

[TParsons]

What about if another component has Force end routine, so you don’t need it on the one you’re editing? Let’s say you wanted to test how many times a participant could press the space bar before the experimentor clicked the mouse - the mouse and keyboard components would both be infinite, but only the mouse would end the routine.

[jon]

I did have some concerns too that the new red looks quite a lot like an Error colour. I guess we previously had a pink but somehow that looked less like an alert.

I like Wakefield’s suggestion that we could use the colours to be informative though as well. We’ll need a new documentation page (that won’t ever be read) explaining what all the colours mean

[wakecarter]

@TParsons

What about if another component has Force end routine , so you don’t need it on the one you’re editing? Let’s say you wanted to test how many times a participant could press the space bar before the experimentor clicked the mouse - the mouse and keyboard components would both be infinite, but only the mouse would end the routine.

I think that the components that the infinite components should be red (for warning) and only the one(s) with a force end of routine should be blue. An infinite text component would therefore always be red but you could easily see which out of mouse and keyboard components can be used to end the trial.

For code components it might be useful to show a bar for them if they have code in Each Frame. The bar could be infinite if any other components are infinite and the same length (and green) if all other components have a duration. For infinite code components they could be red or blue depending on whether they contain endRoutine=True (which I assume is the only way for a code component to force a routine to end).

[jonathan.kominsky]

I’m thrilled to see a file browser in the new coder interface. I see a structure tab too, if that’s working that’s a huge upgrade to PsychoPy as a coding environment.

The builder I think I’d need to see in action, the borderless aesthetic for the stimuli and such generally isn’t one I like but with good highlighting behavior I think that should be plenty usable. The red is a little weird, as has been discussed, but I like the idea of using color to be informative.

[Michael]

• I’m very happy to see the Coder view get some attention, which is also adding really useful function on top of the aesthetic overhaul.
• The new flat icons are most effective in the Runner view, where they have clear meaning. But would suggest
  • The “stop task” button needs to show a proper cross symbol, rather than a capital X. It currently has clear serifs, which can give the impression that it has something to do with text rather than being a “stop” symbol.
  • The “debug” symbol is quite hard to make out. For clarity, could it just be a positive bug image, rather than a negative one embedded within a blue circle? That would allow it to be slightly larger and more legible (the triangle “play” symbol works well as it is, because it is much simpler).
• It’s nice to get some consistency with the icons in the regular Builder mode, but with the shift to simpler, flatter icons, it can be harder to make out what some of the more complex ones mean. While some are clearly obvious (like the microphone and keyboard), even for experienced users, we will need to identify some by hovering over them with the mouse. To be fair, that is an issue with the Builder currently too. I wonder if it would be possible to provide a simple small text label under each icon? That is the way many native Mac apps work - the toolbar can be customised by right-clicking to show other icons only or icons plus text.
• We could probably also take the opportunity to avoid some of the current duplication - e.g. the slider, rating scale, form, and brush all clearly belong under the “Responses” section, but probably just for historical reasons we also have them under “custom”, which is a bit confusing as to what the purpose of that section is. And maybe the syringes also belong under either “stimuli” or (maybe better) “IO”?

[TParsons]

@wakecarter

I think that the components that the infinite components should be red (for warning) and only the one(s) with a force end of routine should be blue. An infinite text component would therefore always be red but you could easily see which out of mouse and keyboard components can be used to end the trial.

I’m still not sure about flagging up all infinite components - I think I might give the wrong idea that infinite components are breaking it and not a normal part of many experiments. However, some visual indicator for components which can end the frame would be good, so I’ll look into that. Maybe the force end could be red and the others blue? So the red is more “this one is powerful” than “this one is wrong”. Otherwise can easily just use other colours! This is the colour scheme, that orange could be nice, particularly against blue:

Coolors.co

Could also use the same colours but a different shade - I have darker/lighter variants of each colour here made by a uniform ±15 to each RGB value.

@jonathan.kominsky

I’m thrilled to see a file browser in the new coder interface.

I’d love to take credit but that was in the Master branch before I did anything! The structure browser is in progress but the bare bones are there I believe.

@Michael

• The “stop task” button needs to show a proper cross symbol, rather than a capital X. It currently has clear serifs, which can give the impression that it has something to do with text rather than being a “stop” symbol.
• The “debug” symbol is quite hard to make out. For clarity, could it just be a positive bug image, rather than a negative one embedded within a blue circle? That would allow it to be slightly larger and more legible (the triangle “play” symbol works well as it is, because it is much simpler).

Both good shouts, I put the debugger in a circle partially for uniformity with the Run button, partially for visibility. I think I can simplify it though - make the legs further apart and thicker so they’re more visible at 16px. I may try spriting it at 16px and then tracing as a vector, rather than the other way around.

@Michael

I wonder if it would be possible to provide a simple small text label under each icon?

I really like this idea! wxButton does have some functionality for labels I think so I’ll have a play with that today - the only worry is being too visually crowded, but we’ll have to see how it looks.

@Michael

We could probably also take the opportunity to avoid some of the current duplication - e.g. the slider, rating scale, form, and brush all clearly belong under the “Responses” section, but probably just for historical reasons we also have them under “custom”, which is a bit confusing as to what the purpose of that section is. And maybe the syringes also belong under either “stimuli” or (maybe better) “IO”?

Fully agree, yes! Custom does make more sense as Code and Variable, the others make more sense in just responses / IO.

[wakecarter]

@TParsons

Maybe the force end could be red and the others blue?

I’m happy with that way round too – so long as one of the colours used matches the corresponding routine colour. One additional reason to use red for a component that can end the routine is that you might have a routine just containing such a component and it would match the routine colour.

[TParsons]

Pull successful, the new look is officially in the master branch!

[mdc]

@Michael

I’m very happy to see the Coder view get some attention, which is also adding really useful function on top of the aesthetic overhaul.

Other improvements to coder will be added once the overhaul stabilizes. I’ve worked on an improved find and replace dialog since the builtin one is pretty awful on Windows. Also Coder supports syntax highlighting for Java script and a few other languages now. I also created a new color selector box that is consistent across all platforms and supports multiple colorspaces PsychoPy uses.

Also the PsychoPy preferences dialog was revamped and there is a proper error dialog when the UI encounters an internal error to make bug reporting easier.

[aisa2]

Will there be updates for the js code formatting? I have found that it still applies python formatting when I’m looking at code in js (e.g. comments defined by // are not seen as comments, while those defined with # are).

[mdc]

Is this in coder or in the code component view?

[aisa2]

@mdc it’s in the code component view

[TParsons]

Aha, I hadn’t spotted that one! It works fine in the code editor because each tab has its own “lexer” (a code which tells PsychoPy what language it’s in), but I think in the code editor it uses the same lexer for both boxes… I’ll see what I can do

[Michael]

When I run the latest developer version on macOS 10.14.6, there is no toolbar in either the Builder or Coder views. So the only way to run an experiment is to use the keyboard short cut to bring up the Runner view.

I then looked in the View menu, but the only option there is to show or hide the tab bar. Oddly, when you select that, it has no effect on the tab bar, but duplicates the window title bar instead. Here is a screenshot showing the absent toolbar and weird double window title:

Is it just me, or do other people see this too?

[jon]

This is currently going through a lot of work and a broken version must have been uploaded

[jon]

Oh, actually, this is an issue just on macs by the looks - everything’s working fine on windows. Damnit, that will probable be harder to track down!