Improve flexibility of ordering in row/stack modes (while maintaining intuitive layout)

[ellipsis7449]

What are you trying to do that you can't?

From #912, I believe being able to modify the layout of tabs in the row and stack modes is worthwhile enough to explore. Currently, the configurations are very rigid, with three rows/columns (depending on your mode):

Row:

Stack:

What is your idea?

I understand this is a very intuitive design, and there's already a free mode where the user can move and resize dialogs to their heart's content. My suggestion here is not to switch which tabs are together or not together in a row/column, but to simply have the ability to mirror the layout. This way, we can keep the current intuitiveness, but the user has a bit more control over where they want these tabs relative to each other.

I'm thinking of 2 ways the layout can be mirrored:

1. Horizontal mirroring: For Row, Stage + Palette column switches with Guide + Collaborate. For Stack, Palette and Stage switch, Guide and Collaborate switch.
2. Vertical mirroring: For Row, Palette and Stage switch, Guide and Collaborate switch. For Stack, Stage + Palette row switches with Guide + Collaborate.

The position of the Code tab is never affected, as it is alone in the middle for both modes. I'll certainly add more mode design ideas if I think of any, but for now, I think this is pretty flexible.

[amyjko]

Thanks for reporting! Leaving this marked needs design, as there are several questions about how this might be supported and controlled.

[ellipsis7449]

@amyjko I think I'd be interested in designing support/control for this!

I'm mostly thinking UI design for this one (where to find mirroring options + how the mirroring interface/dialog would look and be interacted with), but do you think there are other aspects of designing this that I should consider?

[amyjko]

For the way the problem is framed, I think the key design questions are:

• Who needs flexibility and why?
• What are the implications of them not having flexibility?
• What degree of flexibility should be exposed, given these problems?
• What are the tradeoffs of different levels of flexibility? Will it create new problems?
• If flexibility is offered, how can it be presented and controlled while minimizing added complexity for simpler use cases?

[ellipsis7449]

Who needs flexibility and why?

• People who like the structure of Row/Stack, but want the freedom of Free. In Free, the windows may overlap at first, and the user has to manually drag and resize windows to their preference. This may be annoying and take time away from getting to the fun part—creating!
• People coming from other interfaces who are used to a certain layout on their screen. They might want to keep a similar layout as what they’re used to, and modes like Auto and Two, which are the only two that may allow users to switch the sides on which their tabs go, require a bunch of fiddling around—and even then, the layout is not consistent.

What are the implications of them not having flexibility?

• People are stuck with a layout they might not like as much, or stuck in fiddling around to get a layout they want, which may not be permanent. It means less time to learn Wordplay—more energy goes in fiddling with layout and less goes into programming and creating.

What degree of flexibility should be exposed, given these problems?

• There should be enough options to cover the most likely possible configurations in Row/Stack mode, but it shouldn’t have the same flexibility as Free. Row/Stack is more structured, and already has a resize option, so the only additional flexibility should be where the tabs are positioned when displayed.
• We should also cover only a couple configurations, and not all.

What are the tradeoffs of different levels of flexibility? Will it create new problems?

• If we provide complete flexibility (i.e. any possible configuration of tabs in Row/Stack—there are 120 such configurations), it’d be completely overwhelming to the user and certainly very difficult to implement. It would also make Free somewhat redundant.
• If we provide a default configuration but allow users to drag windows to switch them with others, this provides a much more structured approach to Free, but again makes that mode somewhat redundant. It may also prove difficult to implement, given the ability to resize windows (what happens if a user switches a larger window with a smaller one? etc.).
• If we only provide a switch in one orientation (horizontal for row, vertical for stack), we assume that’s the only way users would want to switch, which certainly might not be the case.

If flexibility is offered, how can it be presented and controlled while minimizing added complexity for simpler use cases?
My proposed design is to build on top of the existing Row/Stack layouts, which are already highly intuitive.

Presentation 1:

• It can be controlled using an extra button below the interface (either between the row icon and keyboard shortcuts button, or making the row icon clickable and adding to the tooltip saying mirroring is available).
• This button would open up a menu with four views of the screen layout (depending on whether it’s Row or Stack mode)
• Pros: Users can see how the screen would look in each mode. (Unless they are sight-impaired.)
• Cons: Needs an extra button, or additional tooltip, that may not feel linked to the mode.

Presentation 2:

• If Row or Stack mode is selected, an additional menu option pops up in the Settings.
• This menu just has the four views in a list.
• Pros: Very nice integration into the current settings menu.
• Cons: Users cannot see a view of the screen for each mirroring. However, this may not be as important since the mirroring would immediately be applied upon choosing, just like the modes are.

The four views:

• Default / No mirroring: The current layouts we have on Wordplay.
• Horizontal mirroring: Row — Stage + Palette column switches with Guide + Collaborate. Stack — Palette and Stage switch, Guide and Collaborate switch.
• Vertical mirroring: Row — Palette and Stage switch, Guide and Collaborate switch. Stack — Stage + Palette row switches with Guide + Collaborate.
• Both: Horizontal and Vertical mirroring at the same time. The reason I’m including this option is because it’s more intuitive than having the user be able to select Horizontal and Vertical mirroring at the same time. And four options can be laid out in a 2 x 2 grid, which looks nicer than 1 x 3 or 3 x 1.
• The position of the Code tab is never affected, as it is alone in the middle for both modes.

This design is simpler for implementers to put in place, as it builds upon the current layouts we have for Wordplay (just switching certain windows here and there), and it provides a pretty good amount of flexibility for users, while still keeping some intuitive structure. Presenting/controlling this functionality also slots into the current interface pretty easily, as it can be done with just one extra button (or not!) and one simple dialog.

Please let me know what you think, and any improvements I could make!

[amyjko]

Thanks @ellipsis7449; it may take me some time to review this. Possibly before meetup tomorrow, possibly later.

[amyjko]

Thanks for the rationale; I think I largely concur that there are some opportunities for flexibility that wouldn't create undue complexity. I think I follow the proposal, but I'm not entirely following what additional views are being proposed. I think a mockup of your two proposed presentations and 4 views would help. These don't have to be formal — they can just be sketches — I just want to make sure I understand what you're proposing.

[ellipsis7449]

Alrighty… some moderately poorly photoshopped images of alternate views, and sketches of presentations:

Row

Default

Horizontal Mirroring

Vertical Mirroring

Both

———————

Stack

Default

Horizontal Mirroring

Vertical Mirroring

Both

———————

Presentation 1

Slide 1: The red square represents where the mirroring button would be. This button would only appear in Row and Stack Modes. The alternative would be that the red square is actually the row/stack icon, and the icon would be made clickable.

Slide 2: Upon clicking this extra button, a dialog opens up (fancier than this ofc) with screenshots of what the screen will look like in each mode. These screenshots should probably be default images that have all the tabs open, rather than what's currently on the user's screen. (The default new project, as shown here, would probably be best!)

———————

Presentation 2 (my personal preference…)

Slide 1: In any other mode, like auto, the settings look as they are right now.

Slide 2: Upon clicking Row or Stack, an additional row of settings appears right below the mode setting (probably called "mirroring"), with the options as shown.

———————

Hope this makes things clearer :) Let me know what you think!

[amyjko]

Thanks for the clarifications! I definitely understand the proposal now. A few minor revisions before I approve this design:

• I think alternative 2 (the settings dialog update) is the better choice, as we discussed.
• The labels on these four options are very important, but I'm really not sure what they should be, as there's not really a semantic meaning to any of the arrangements (e.g., most won't remember what the default represents, and the other options are more defined relative to that unknown default). It might be necessary to come up with some semantic meaning (e.g., "output on the left").

[ellipsis7449]

Ah, that's very true. I do have an alternate idea based on your suggestion—it'd be fun to use something akin to stage directions to denote where the stage will be in each configuration (at least in English).

• Stage top left
• Stage top right
• Stage bottom left
• Stage bottom right

I kind of like this better than the original terms I had proposed, both because of what you pointed out and because it's more consistent across Row and Stack modes.

Deciding what to call the "Mirroring" menu item based on this is a bit more challenging. I think something more general like
"(Tab) Configuration/Configure" or more in line like "Stage Position" might work.

On second thought, there is also the issue that the above labeling doesn't imply that ALL the windows change position, which the original terms do. I'm not sure whether this is a big enough drawback, but adding descriptive enough tooltips to try and remedy this would be difficult… we could try adding a tooltip that's like "reassembles tabs/windows/whatever-it's-called such that Stage is in [position]." (I'm not sure about what exactly the tooltip wording would be for quicker access and understanding, but something along those lines.)

What do you think? Any other ideas?