I’m mentoring someone. The user interface shows their code on the left, our conversation on the right. These are HTML panes or a reasonable facsimile thereof: you can grab a vertical bar between them and drag it left / right to change the relative size of the two panes.
That’s great! Except it only lets me drag it a few millimeters left / right, so it ends up just mocking me!
Please make it so this pane divider can be usefully moved.
Changing these to min-width=25% and min-width=30% makes this panel much more pleasant to work with.
However – the code pane has source code and really doesn’t appreciate being truncated. It’s problematic with the original panel divisions, and even worse when I shrink the code pane. (Still worthwhile if I am doing big work in the conversation pane…)
The code pane would be greatly improved if it had the ability to wrap lines and to have a scrollbar. Each source file’s tab should have a checkbox to choose between wrap & scrollbar, and these choices should be remembered across sessions and across submission iterations. (That is, if foo.js in iteration 1 was set to have a scrollbar, foo.js in iteration 3 should have a scrollbar.)
Hey @filbo, firstly a warm welcome to the Exercism Forum. I’m Jonathan (Exercism Community Manager) so wanted to introduce myself. Firstly, thanks for pointing this out, and I’m sure it’ll be something we can look into.
Hi Jonathan, thanks for moving this. I thought I’d found the right place, but apparently didn’t open the right parent topic to find my way to Bugs & Features, which I certainly would have chosen if I’d found it…
I suggested above that minima of 25% and 30% would work better, but I would revise that to basically make those minima as small as possible. Maybe no ‘min-width’ at all; maybe 10% or whatever is necessary to accommodate the basic widgetry of a squashed empty pane on each side.
Basically, there is no need for this to specify a ‘looks reasonable’ minimum because it’s under user control. If at some particular moment the user needs one pane to be super-wide, and this squashes the other one to unusability, that is fine, it’s what the user wants at that moment and there’s no need to protect him from it. If these numbers were in charge of a default presentation then they would need to protect a reasonable appearance; but they aren’t.
The interface I’m typing this in right now more or less exemplifies this idea. Here I have a typing pane on the left, a ’ Welcome to Exercism — thanks for contributing!’ message on the right (with an ‘esc x’ button which I assume will expand the typing pane across the whole bottom… nope, it puts up a realtime preview window, so that’s cool); and a top pane showing the discussion to which I am replying. Between the top (discussion) pane and the bottom (typing + preview) pane(s) is a draggable separator. This separator allows itself to be dragged all the way up (completely eliminating the discussion pane); and most of the way down (squashing the typing pane down to a single line). I would characterize this as almost as liberal as it ought to be: ideally it should allow me to squash the typing pane all the way down to just its ‘<- Reply’, ‘Close’ buttons on the bottom, if for a while I want to view the discussion pane in biggest glory. But the distance between what it does allow and what it ought to allow is quite small and not particularly harmful. Unlike the mentoring interface about which I raised the topic.
… so let me just say that, broadly, any sort of draggable multi-pane interface should allow panes to be closed away completely and, alternatively, squashed so far as to be not-useful at the moment, but still holding their place for quick reconstitution. It is a user interface, let the user in situ determine which parts they need at the moment.