Small screen layouts

[kmutzet]

What's the problem?

The problem we are trying to address surrounds the need for a new layout for smaller screen sizes. When the window gets too small of a size, the automatic layout words/buttons get cut off (reference screenshot below). This makes it really difficult to navigate the learning page and work on a smaller screen.

• What is the task, goal, or need this request would help someone accomplish? This request would open up Wordplay to be usable at any time from a person's phone or small computer screen and be easily navigable. This will help people access their projects on the go, or if they are multitasking and want multiple windows on their screen at once.
• What is the context or scenario in which they would experience it? Users may experience this issue when accessing Wordplay from their mobile devices, especially when they have limited screen space available. Also for those that use computers, doing split screen for different browser windows makes wordplay become sized weirdly (things get cut off). Fixing this issue will make it easier to use when in that situation
• Who is the group of people who would be in this situation? Individuals who prefer to access Wordplay from their phones or those who may not have access to a computer. Also those who have other things open at the same time and need to do a smaller screen layout.
• What is it about the current design that makes the need above hard to satisfy? The current design does not adapt well to smaller screen sizes, leading to important words/buttons being cut off, making navigation difficult on mobile devices and computers.

If what you're describing above is broken functionality, including usability, accessibility, localization problems, report those as defects, as they are things to be fixed, not added.

What's the design idea?

What do you propose to change or add to address the problem above? Describe some functionality, a design concept, a redesign, or alternative designs that might address the problem. Provide as much detail about the idea as you currently have, but no need to provide an exact design specification if you don't have one. (That goes below).

The proposed solution is to introduce a new layout specifically tailored for smaller screen sizes, such as those found on mobile devices or split computer screens. This new layout would reorganize the elements vertically to ensure everything remains accessible and navigable even on limited screen real estate. Vertical Layout: When the screen size becomes small enough (typical mobile screen size, or maybe less than 1080px/~third of a mac screen size), the layout transitions to a vertical orientation. This means arranging elements vertically on the same page, making everything scrollable.

Design specification

To combat the vast amount of elements that is immediately visible on big screens at Wordplay, we propose two ways to make these elements clearer and more accessible: 1) stacking the main screens vertically 2) a hamburger menu that allows for switching between individual tiles and website links 3) an editing mode, and 4) always showing the stage and editor together, except when in editing mode, in which case the stage preview is shown.

Default Screen:

In the default screen for the workspace, the user can type their code by tapping the code chunk. The stage is visible and on the top of the screen because the user can see it clearly. The next element in the mobile version is the function. This can be collapsed by pressing the up arrow next to the function icon. The code is on the bottom of the screen and takes a standard amount of space, rather than being cluttered. Additionally, the file name is at the top, so it shows the file name, with a dropdown allowing file access. Furthermore, the Wordplay logo leads to the homepage similar to how it functions on a desktop. Each of the individual containers would work the same as their desktop layout, i.e., users can still swipe to view the other buttons at the bottom of the stage that aren’t immediately viewable.

Typing Screen:

Figure 1

Figure 2

Figure 3

Figure 4

For the typing design specification, we have to only show a stage preview rather than a whole stage. This is because 3 windows along with the keyboard pop-up can get extremely crowded. To mitigate this issue, we propose solely having the feedback and typing. The user does not need to see the actual stage until after they’re done typing. When editing, the stage preview shows (figure 1). However, when the user taps the stage, it highlights red, where they can either pause (figure 2), play (figure 3), or exit the stage preview (minimize button). The screen can be paused while currently typing so the user doesn't feel overwhelmed with the stage constantly moving while typing. It can also be minimized and expanded upon clicking the open stage menu (figure 4).The special characters will be moved above the keyboard to make it closer to the keyboard for typing, and users can swipe to see the rest of the symbol bar. Once the user clicks the check icon, they can access the menu and see the full stage once again. Additionally, we decided to have the typing stage closest to the keyboard, so the user can easily see what they are typing while looking at the keyboard.

Menu Pop-Up Screen

For the menu design, the user can click the 3 lines in the top right of the menu. From there, the menu will pop-out on the side. There is a minimize button to collapse the menu. This menu will mitigate the information overload with smaller screens and have all the necessary components of the homepage that the user can easily access. Our justification for making the hamburger menu half the width of the screen is that it is standard and similar to editing google docs on the mobile version, which many young users are accustomed to. The half-width hamburger menu is meta content intended for temporary access, therefore the user can still see their code when looking at the menu to find the feature that suits their needs.

Pallette/Guide Screen:

Figure 5

Figure 6

We decided to refine both the palette (figure 5) and guide screen (figure 6) to allow for the code to exist so the user can drag options to the code chunk they are working on. Additionally, the user can see the preview of the stage while working with the guide/pallette feature. The user can also exit the screens to return to the main editing screen by pressing the "minimize" button

File drop-down Screen:

We have decided to have a file dropdown so the user can select a source file to work on. However, the user cannot edit multiple files at the same time given the small screen size.

[amyjko]

Thanks for reporting! Hopefully someone will take this on; it would be great to envision a better small screen experience. (One idea I had was more of a stack layout for vertical screens and a row layout for horizontal orientations, so that one would scroll to get to different sections of the interface.

[amyjko]

Oh, and @tammyn17 and @kmutzet, I see you assigned yourself. Do you plan on designing this?

[tammyn17]

@amyjko We just tagged ourselves for the issue proposal. Sadly, I believe Kate and I won't be able to sign up for next quarter due to our schedules.

[amyjko]

Ah, okay. You should remove yourselves if you're not planning on working on it. "Assignee" means you're responsible for making progress on the issue.

[nhinds2]

Greetings, I would like to be assigned to this issue if possible @amyjko

[megngo]

Hi, I would also like to be assigned to this issue if possible! @amyjko

[amyjko]

Assigned you both!

[nhinds2]

Design specification

To combat the vast amount of elements that is immediately visible on big screens at Wordplay, we propose two ways to make these elements clearer and more accessible: stacking the main screens vertically, as well as hiding certain elements until the user needs them.

Default Screen:

In the default screen for the workspace, the user can click the pencil icon to start typing their code. The stage is visible and on the top of the screen because it is the most visible. The next element in the mobile version is the function. This can be collapsed by pressing the up arrow next to the function icon. The code is on the bottom of the screen and takes a standard amount of space, rather than being cluttered. Additionally, the file name is at the top, so it shows the file name. Furthermore, the Wordplay logo leads to the homepage similar to how it functions on a desktop. Each of the individual containers would work the same as their desktop layout, i.e., users can still swipe to view the other buttons at the bottom of the stage that aren’t immediately viewable.

Typing Screen:

For the typing design specification, we have decided to remove the stage. This is because 3 windows along with the keyboard pop-up can get extremely crowded. To mitigate this issue, we propose solely having the feedback and typing. The user does not need to see the actual stage until after they’re done typing. The special characters will be moved above the keyboard to make it closer to the keyboard for typing, and users can swipe to see the rest of the symbol bar. Once the user clicks the “done editing button”(check icon), they can access the menu and see the stage once again. Additionally, we decided to have the typing stage closest to the keyboard, so the user can easily see what they are typing while looking at the keyboard.

Menu Pop-Up Screen

For the menu design, the user can click the 3 lines in the top right of the menu. From there, the menu will pop-out on the side. There is a minimize button to collapse the menu. This menu will mitigate the information overload with smaller screens and have all the necessary components of the homepage that the user can easily access.

Guide Screen:

From the menu toolbar, the user can click and the guide will show the full screen. This is different from the previous design because originally opening the guide would lead to a lot of horizontal and vertical scrolling inside a small window pane. This can make the mobile layout extremely crowded. From this, the guide can become a full screen to help the user have a full navigation pane and minimize once they have gathered complete information. They can still use the search feature to help with navigation.

[amyjko]

Process reminders, as stated in the design wiki:

• Design specifications go in the main issue body, not in comments, so that they are easily discoverable.
• If you're requesting design feedback, you need to take the person you're requesting feedback from.

[nhinds2]

Hi @amyjko, I updated the design spec to be in the main issue body. Apologies for the misunderstanding

[amyjko]

Thanks for keeping things tidy! I read through it, and generally think it's moving in a good direction. A few clarifications and questions:

It seems like the basic design involves two big ideas: 1) a hamburger menu that allows for switching between individual tiles and website links, 2) an editing mode, and 3) always showing the stage and editor together, except when in editing mode, in which case the stage is hidden. Do I understand that correctly? If so, I think the general concept works, except for the following:

• It's not clear how one would navigate to showing the editor/stage combo if currently viewing the palette or guide
• It's not clear how one would navigate to other source files, since may source files are possible in a project.
• Why is an "edit" button needed? Why can't that just be based on whether the editor has keyboard focus?
• If someone was viewing the palette and wanted to drag a code example from it, how would they, especially with the need to enter an edit mode? Or would they be required to copy and paste?
• Why is the hamburger menu only half the width of the screen? Why not full screen with some padding?
• We could show an stage preview hovering over the editor, instead of hiding it, so it's not entirely invisible.
• It's not clear what other functionality you've hidden in your design proposal. Are all of the toolbar controls still there, just behind scrollable toolbars? Or are you proposing to hide controls?

[nhinds2]

Hi Amy, thank you for your feedback. We have addressed the questions in the main design spec under the section titled "Updated response to feedback". Thank you!

[amyjko]

Thank you for the updates; they're hard to understand when separated from the broader design proposal. The specification should be a clear description of what to build, not a chronology of design decisions. See if you can revise it so that it's one clear description of the final design. Thanks!

[nhinds2]

Hi Amy, I revised the proposal so it is one central description of the final design and includes the edits. Thanks!

[amyjko]

Thanks. A few things I'm still confused about:

• The text mentions a "done editing" button, but I don't see that anywhere in the mockups.
• Why does the stage preview highlight in red when focused? That's not the focus color in the rest of the application. Why the inconsistency?
• Why is it not possible for any of the tiles in the project view to be full screen? Why are the editor and stage the only tiles that support split view? It seems like there are a lot of inconsistencies in this design that creators would have to learn, and that they all behave differently from the desktop version. Why not a design that just makes every tile full screen, or allows any two tiles to be split vertically?
• We talked about supporting a swipe navigation between tiles instead of a hamburger menu. Is there a reason you decided not to support that design convention?

[nhinds2]

Hi Amy! We have changed the design proposal to address questions 1& 2 and plan to ask for clarification about 3 & 4 in-person at the meetup tomorrow.

[megngo]

Final Status from Spring Quarter:

• Main goal of next design revisions is to standardize screen behavior (which screens can be split, should all screens be able to be split, how will users know how to choose which two screens are split at a time, if there should be a swiping function to switch between certain screens)
• Ideate between the different designs mentioned above and weigh pros and cons of each
• If certain screens can't be split and are only available in full, rationalize why and justify the extra learning the user has to undergo

[amyjko]

@megngo @nhinds2, will you both be continuing work on this issue? If not, unassign yourselves, so we know. Thanks!

[nhinds2]

Hello, I'll plan to work on this issue in the summer.

[nhinds2]

Thanks. A few things I'm still confused about:

• The text mentions a "done editing" button, but I don't see that anywhere in the mockups.
• Why does the stage preview highlight in red when focused? That's not the focus color in the rest of the application. Why the inconsistency?
• Why is it not possible for any of the tiles in the project view to be full screen? Why are the editor and stage the only tiles that support split view? It seems like there are a lot of inconsistencies in this design that creators would have to learn, and that they all behave differently from the desktop version. Why not a design that just makes every tile full screen, or allows any two tiles to be split vertically?
• We talked about supporting a swipe navigation between tiles instead of a hamburger menu. Is there a reason you decided not to support that design convention?

Hi Amy, we have addressed and made changes from the other questions in the updated design spec, but we wanted to answer these questions in the comments as they are more nuanced and pertain to the design concept as a whole.

• Why is it not possible for any of the tiles in the project view to be full screen? Why are the editor and stage the only tiles that support split view? It seems like there are a lot of inconsistencies in this design that creators would have to learn, and that they all behave differently from the desktop version. Why not a design that just makes every tile full screen, or allows any two tiles to be split vertically?

Introducing the ability to split any two tiles would complicate the user experience, as it may not always be intuitive which tiles should be paired together (for example, the feedback screen and guide). This could lead to confusion and difficulty in learning how to effectively use the feature. Additionally, allowing any two tiles to be split would require users to familiarize themselves with dragging and resizing frames on the phone, which might be challenging, especially for new users.

Furthermore, our decision to keep only the guide and palette fullscreen was driven by practicality — these tiles contain the most text, making the fullscreen view beneficial for readability. Other elements, primarily for typing and interaction, do not necessarily require fullscreen to be effective. Users have the flexibility to adjust their view by minimizing unnecessary elements like stage preview or feedback, while user buttons provide straightforward interaction options.

• We talked about supporting a swipe navigation between tiles instead of a hamburger menu. Is there a reason you decided not to support that design convention?

Our justification for choosing a hamburger menu over swipe navigation is that we found it would be difficult for the user to know where they are in terms of swiping and the correct page they are on. In terms of choosing conventions, we prioritized discoverability and labeled navigation over convenience and quick access, since many users are not familiar with swiping. Hamburger menus are a lot more familiar for users. For instance, google docs has the hamburger menu, which is convenient for users and many young users are already familiar with it for typing, whereas the swipe feature is more complex and less intuitive.

[amyjko]

Thanks for the updates! More questions:

• It seems like the hamburger menu is only sometimes visible. Is that just an artifact of the sketches, or by design?
• The edit button, when pressed, seems to disappear and be replaced by a check button in the top left. Why move the position of this toggle button? Doesn't it make more sense to have this toggle be a single button that switches between modes?
• For clarity, the hamburger menu is just the footer in desktop mode, right? I can't quite tell, since it's missing some of the other features of the footer.
• How would creators access the project footer that appears above the site footer while in mobile mode? (This is where sharing, project name, and other project level features are shown).
• The sketches still show the collapse and full screen buttons on tiles. Are those still supported in mobile mode? What is their behavior? (Collapse doesn't make sense because the whole window manager is different in mobile mode, and maximize doesn't quite make sense either, since they're already maximized).

[nhinds2]

• It seems like the hamburger menu is only sometimes visible. Is that just an artifact of the sketches, or by design?

The hamburger menu is only visible on the stagnant screen, not typing screen. This is because the hamburger menu could not be accessed when the keyboard feature is there, and users would need to hit the check button to see the menu. This is similar to the convention in Google Docs, where editing only has the ability to type, and then later see the views.

• The edit button, when pressed, seems to disappear and be replaced by a check button in the top left. Why move the position of this toggle button? Doesn't it make more sense to have this toggle be a single button that switches between modes?

We could have a toggle button, however we thought that the editing mode would be automatic since you would touch it to type the code, and thus does not need a toggle button.

• For clarity, the hamburger menu is just the footer in desktop mode, right? I can't quite tell, since it's missing some of the other features of the footer.

Correct, the hamburger menu is the footer in desktop mode.

For the last two comments, these are still issues that need to be further discussed. Unfortunately, the small screen issue is an issue that both Meghan and I are unable to continue working on. Our thought process in our initial designs should be documented within the design specification and the answers to clarifying questions in the comments, but we are willing to add further elaboration if needed on what is already documented for whoever decides to pick up this issue next.

[amyjko]

Okay, thank you for the clarifications, and for the good start on this redesign! It's not quite finished yet, but it's a good foundation. I'll unassign you both.

[Davidxuwuhu]

I can try to implement this

[amyjko]

@Davidxuwuhu I say go for it! There are lots of subtle issues here that interact with HTML, CSS, and JavaScript. I recommend making a detailed implementation plan using GitHub's checklist syntax in a pull request, so everyone can follow along and help out.

[joonpiter]

@Davidxuwuhu, will you be going forward with this issue?

[Davidxuwuhu]

Yeah i am currently working on another personal project but I will work on it more as the school year starts

[Davidxuwuhu]

Hi Amy would you mind helping me find which files in the repository relate to this issue? Thanks!

[amyjko]

Happily! First, make sure you're talking to assignees of #368, which also are working on some layout issues. You should work together on these two issues.

All layout for the project view lives in:

• ProjectView.svelte, which is a huge component that does a lot of different things.
• Layout.ts, which stores the current layout state.
• TileView, which represents a window in the project view.
• LayoutSetting.ts, which represents the persisted layout setting chosen. This needs to be reconciled with the design, which may break the data stored in this because it no longer follows the paradigm of open and closed tiles.