Playground UI prototype feedback

announcements
1

Hello everyone :slight_smile:

Recently, Rust playground developer @shepmaster, and I have been working on a UI prototype for the Rust Playground. I'd like to explain our thinking a bit, and ask for potential feedback.

The playground is widely used, both by newcomers to Rust and experienced developers, and in conversations and issues on the repo we can see it does things well, and some things we can still improve. In particular, there is a will and a need to add more features, better support existing and new contexts, etc. However, this can't easily be done in the current UI, where space is not readily available.

We needed to tweak the header above the editor:

  • to be more usable on narrow screens: for example, when having 2 playgrounds side by side for comparisons, or on mobile devices (at least for viewing code, more so than for typing code on a phone per se). The existing header is already too wide for those use cases.
  • if we could "hide" the less common actions, it would make the UI more usable for newcomers, at a potential cost for more experienced users.
  • to allow us to add features in the future: there are open issues and PRs blocked on this, adding them today would worsen the situation. For example, supporting backtraces, -C -Z or env flags, and soon enough: dealing with the 2018 edition.
  • this space gain also has a cost in discoverability, however those kinds of problems happen only at the beginning, and can be mitigated with documentation, videos, inline help, etc. (i.e., it's only a temporary state of affairs, fixed by training and habit forming).

So what we've worked on is try and move towards having dropdown menus/windows/popovers to conserve space. This would be a first cut, and we'd then improve on it to better support the broad range of uses (especially for experienced users as we'll see later).

image

First, even though they are useful and used, emitting assembly, IRs and WASM are less common use cases, and just having them present has both a cost in space and time (it takes longer to find what you're looking for when there are more options). So we propose having a dropdown with the different "build actions" one can do. At the same time, supporting today's WASM use cases slightly better: automatically switching to Nightly instead of being disabled on other channels.

image

Then, a bit of reordering to keep related things closer to each other and we have the "Mode" and "Channel" selectors. This would be the most controversial change, it's less common that they are changed for newcomers (than experienced users) but it's still common. We have made multiple attempts at this and ended up with what we feel is a reasonable compromise. Having a dropdown helps with having more descriptive text for the options (hopefully helping newcomers, especially for our Channels, uncommon in other languages).

image
image

The rest of currently existing actions are now located on the right side of the screen, with the Tools and Config actions dropdowns.

image

To conclude, here are some examples of things we've thought about for the future and later revisions:

  • being able to switch the default action in the "Build/Run/Test" button for one of the build/ASM/MIR/LLVM IR/WASM actions
  • having shortcuts to each tool: some users use the playground a lot to format code before posting it elsewhere (GitHub comments, Stack Overflow, etc).
    image
  • add "advanced compilation options" to match power users' needs, for example on-demand backtraces (/me waves at @withoutboats :wink: and "arbitrary" flags (even though with the space we could have more descriptive options for some flags, for example ones related to the 2018 edition).
    image
  • there's space to add more tools, like the 2018 edition rustfix.
  • some possible "adaptive behaviour", e.g. showing more of the UI when there is space available, and collapsing it back when there is little.

We are at the point where we could make a PR right now, and to help with gathering feedback we've put a build of the UI here. This is just the UI part of the playground: there is no rustc backend, no servers or tools, links or sharing — the usual features won't work. However the UI is live and allows taking it for a spin.

(We'd also like to thank, in no particular order, for their help and early feedback: grissess, june, danopia, eddyb, nox, eijebong, guiea_7, sleffy, osspial)

34 Likes
2

In my opinion the mentioned pain points are valid and the new design addresses them truthfully. Good job!

I don't know where I need to look for these issues so my feedback might have been already discussed.

Is mode switching actually used a lot? To me it seems to be a set-once feature which could be coupled more tightly to the chosen channel. I'd argue it's used only by 'advanced rustaceans' for performance/code generation comparison. Most people would leave it's value at default.
Moving the mode into the dropdown of the channel would ultimately free up space of one entire button on the bar (see below). The amount of clicks to change away from the default value would stay the same (relative to this exact prototype, not the live version). Worst case doesn't get worse.

So the recommended minimum device size would fall into the tablet class? Maybe explicitly support phone sized devices for only viewing code?
The latter could allow for removal of the split view and possibly other elements entirely.

1 Like
3

I think of "run" and "output mir/llvm/etc" as logically separate operations, so I'm not a fan of hiding them in the Run dropdown.

The grouping of "tools" isn't great either -- rustfmt is applied to the input (with no interesting output in the log), and clippy doesn't modify the input, but it's all about its output. So if only thing that groups them logically is that they're "tools", that's not very strong, because rustc is a tool, and all other Run options run some tools, too.

How about having the tabs with outputs for all possible tools/modes visible by default and populated lazily? Then "Run" would become a "Save/refresh" button:

55
551350×72 8.05 KB

1 Like
4

I'm super into all of this!

3 Likes
5

First of all, thank you for the feedback.

I don’t know where I need to look for these issues

The issues are from the Playground repo — unfortunately none of this post's work was discussed there, there's only the previously existing issues.

Is mode switching actually used a lot?

If I remember correctly, Mode is used a lot, but as you mention it's very likely to be a subset of uses (for example at specific points in one's session). Unfortunately, yeah, there are different subsets we have to account for.

Moving the mode into the dropdown

Your proposal makes sense, and it's funnily what we started with :slight_smile: For example, as a regular dropdown, and also as a form you had to validate:

image

image
image324×527 56.4 KB

And switched to the 2 buttons version shown in the original post after some early feedback.

So the recommended minimum device size...

This prototype fits under an iPhone 6 width, or half a 15-inch screen (around 700px or so). We normally shouldn't have to do anything more for narrow screens, I think. (But we still have the option of adapting to even narrower screens with the Mode/Channel combination you mention. However, I feel that at such narrow sizes, one would probably not have a lot of advanced uses).

As for split views and such, we were only looking at the header at this point, and might revisit this topic later.

Thanks for the feedback, it is noted and very much appreciated :slight_smile:

6

That proposal looks pretty great!

One minor nitpick is that from a distance, the "mode" dropdown in "release" mode looks like it is about selecting a rustc release for the uninitiated.

EDIT: I think the new mockup that you posted while I was writing nicely addresses this, but at the cost of near-duplicate "option" vs "config" terminology.

Also, is the simple editor actually used?

7

The simple editor has better accessibility for screen readers and mobile devices.

2 Likes
8

Thanks for the clarification! It does indeed make sense as a workaround until Ace is fixed (if ever... the longevity of that issue is disturbing).

9

Thanks for the feedback !

I think of “run” and “output mir/llvm/etc” as logically separate operations

Fair point. (The button is not just the Run button, it switches form Run to Build to Test depending on the code in the editor). In my own use I see this whole group of actions (with mode and channel) as "rustc". (And the "--emit" ones especially, as "advanced uncommon uses of rustc", hence their "less accessible but still amongst rustc friends" positioning)

The grouping of “tools” isn’t great either

It's indeed usually a way of grouping things together that don't fit anywhere else, however it's also a common idiom in UIs, so it might not be that bad and not worsening what we already have ? It's also how these are referred to if I remember correctly, precisely "dev tools", so there might also be a preceding familiarity with the term there.

How about having the tabs with outputs for all possible tools/modes

Interesting idea. It feels a bit confusing to me at first — especially when most of those tabs won't be of use in most of cases and users (possibly overwhelming). It's definitely an unexpected direction though, therefore good food for thought!

Thanks for the interesting feedback, again, noted and appreciated :slight_smile:

1 Like
10

Thank you for the feedback!

One minor nitpick is that from a distance, the “mode” dropdown in “release” mode looks like it is about selecting a rustc release for the uninitiated.

Interesting, I had only seen them referred to as "version" but can see how that could be confusing indeed.

If it turns out to be indeed a common pain point in feedback, we might have options, for example "optimized" or maybe "--release" (-O2 and the like) to use cargo's or rustc's flags. Maybe it will help that the default is Debug, so it would only show Release if one had switched it or gotten a link to a gist.

I say this every time but I mean it: thank you for your feedback, it is noted and much appreciated :slight_smile:

11

As another possible suggestion, does the UI toolkit that you are using provide some typographic wiggle room? When putting the old and new playgrounds side by side, it is pretty clear to me that the new controls' labels are currently less readable due to a combination of...

  • Smaller font sizes
  • ALL CAPS (without even small caps to save the day)
  • Lower color contrast (yeah, I know, everyone loves lighter shades of gray these days)

It is still above my readability treshold if I concentrate a bit, but I am young and have one fully functional eye. I would want to have someone older or with bigger sight issues to have a look at these controls before declaring them ready to roll :slight_smile:

2 Likes
12

Important point indeed.

Fortunately this is not using a UI toolkit, so I wouldn't think there will be particular limitations we'd hit working in this area :slight_smile: — I added this to the list of things to look at.

Thanks!

13

[ options: release / beta ] might be confusing if there's also [ config ] button (since changing options is a synonym of configuration). Perhaps [ compiler: optimizing / beta ]. Or maybe [ config ] could be split between configuring the compiler, and configuring the editor?

Regarding grouping of tools, I've realised that there are two groups: affected by the compiler config (run, asm output), and not affected (clippy, rustfmt), so that sort of vindicates "tools" grouping. But maybe that's also an opportunity for stronger grouping of other compiler-dependent buttons.

1 Like
14

Oh right, yeah, this button — and possibly the grouping of mode and channel together — seemed confusing in the early feedback we've received. This made us switch to the 2 buttons shown in the first post and in the live prototype. I've edited that screenshot-containing-reply to clarify that this was a screenshot of what we initially started with :slight_smile:

It could still be a useful idea, in which case the "compiler : " prefix would probably work better than "Options" indeed.

As for the grouping, again interesting thoughts. Card sorting could help produce a grouping if it turns out to be inadequate.

15

One alternative name for "mode" is "profile", this is what is used to refer to it in Cargo.toml (at least, I assume that is what the playground is doing behind the scenes). Naming it this might have better forward-compatibility with supporting customising the profile (e.g. being able to enable lto) and be more familiar to users that have done so via Cargo.toml in the past.

2 Likes
16

The cleanup looks great.

I personally have never encountered a reason for switching between release and debug builds. I suspect it has to do with people who want alternative outputs? In that case the option should be hidden unless somebody selects one of those?

The only thing I'd like to be able to tweak is the runtime integer overflow checks, but still I think I'd want a release build with that. Pherhaps somewhere we'd want basic "build options" for that? (hidden in a '...' next to the rust release channel chooser possibly)

And for some reason the 'Share' button feels a bit hard to spot. That might be due to the images being a bit cramped. But it might be better to move it more the left (next to run?) or mostly to the right?

Edit:
A minor nitpick, but the Run optioneel "Build" does not do what it says. It really is the "build + execute" option that results not Ina build program, but the result is the output of that program.

17

A few words I have:

  • Put the “Share” button next to the “Run” button
  • Themes should change not only the editor but the whole UI
  • Add City Lights and Feather themes.
1 Like
18

Couple of questions:

  1. Will release be the default target? The screenshots imply it is. I'd rather have faster compile times so debug by default makes sense to me.
  2. Will settings be persisted across sessions? I live largely in the nightly world right now so would appreciate that option being sticky
  3. I'm not keen on rustfmt being hidden in a menu. I know it's behind a key combo, but making it top level visible, or even better apply automagically on run/save, would feel better IMO.
  4. Will the compile times be faster now that it's web 3.0? :wink:

Looks really good overall though. The playground is an invaluable tool for working with Rust so it's great to see some updates to it!

19

Themes are provided by the Ace editor, an open source project. If you'd like to see more themes, that is the correct place to contribute them to. There's some thought of adding overall themes to the entire playground, but that will be in the future.

Thanks!

20

Yes, the "things we’ve thought about for the future and later revisions" section in the original post has a ... menu for exactly such options. I don't know whether this specific option would deserve space in the menu or not. :man_shrugging:

That button actually means three possible things:

  1. Build and execute code (if a main method is present)
  2. Build code (if #[crate_type = "lib"] is present)
  3. Run tests (if #[test] is present)

There's been discussion about splitting those into separate functions instead of the automatically-detected variant that is currently present.

Debug will continue to be the default, that's just the setting we happened to take the screenshot on ("release" is longer than "debug", so we check that the most)

It probably wouldn't switch with this update, but that is some feedback we've heard once or twice, so it's a possibility. You can cheat for now by adding ?channel=nightly to the URL.

Considering it's the number 1 feature I use in the playground, I feel your pain. However, based on the code I've seen come out of the playground, it's not as commonly used as I'd hope. The key-combo is mostly going to be to restore my own ease of use. :innocent:

I cannot even begin to imagine the intense amount of wailing and gnashing of teeth that this would cause... :wink:

3 Likes