-
-
Notifications
You must be signed in to change notification settings - Fork 274
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
drag & drop next steps #101
Comments
This comment was marked as outdated.
This comment was marked as outdated.
Rewritten to describe a more complete visual editor paradigm. |
In addition to a drag and drop UX, I think that a UX that would behave like Notion could feel really great (maybe?). As a developer, I feel like I'm wired to build apps by starting with finding on the page what component and where to add next. Having to go to the side to find a component to drag it feels slower than being able to stay focused on the area of interest.
add.mp4
|
Not having to navigate to and browse the component panel would also lend itself to a nicer keyboard interaction model for power-users/accessibility. |
I guess #359 will be a part of this enhancement? |
Here are some ideas for an initial grid system we could use, fully based on the Material Design guidelines. I think it looks like a great starting point to reason about the drag & drop system to implement: The responsive layout grid is made up of three elements: columns, gutters, and margins.
ColumnsContent is placed in the areas of the screen that contain columns. GuttersA gutter is the space between columns that helps separate content. MarginsMargins are the space between content and the left and right edges of the screen. BreakpointsA breakpoint is the screen size threshold determined by specific layout requirements. At a given breakpoint range, the layout adjusts to suit the screen size and orientation. Recommended values for screen sizes/margins/number of columns here: Layout SpacingI suggest that we default to a grid with the same spacing as in the Material UI guidelines:
Element Spacing and SizingEvery element should exist within a rectangular container. The following properties should be adjustable within an element:
When scaling a layout, components can have fixed or responsive widths within the range of size constraints. |
Layout CompositionA large screen layout has three main regions:
Body regionThe body region is used for displaying most of the content in an app.
Common Dashboard Design PatternsHere are some common design patterns for dashboards / internal tools that we might want to accommodate for.
This research was based on competition examples and case studies, templates from similar tools and dashboard UI designs found around the web.
|
Based on the RFC above, and after looking at many competing tool UXs, here's how I think the next version of our visual editor could work. Regular componentsI agree with everything Jan wrote in this section, and it all seems to be according / easy to conform to something like the Material UI design guidelines. Layout componentsThere would be 2 types of layout components: rows and columns. We could have an explicit column component, as Jan defined it. The top-level column (the page itself) would be a full-width column, and its minimum height would be the height of the screen/viewport. A column could only contain rows, and components (including columns, except the top-level column) could only be placed inside rows. Rows, just like columns, would be configurable components with the ability to change properties such as their background color, margins and padding. However, a row/column's total width, including margin, should always fit exactly in the grid columns. I don’t think a non-layout element’s horizontal span would need to be adjusted in relation to the grid, but in relation to its parent row (or other type of container component) only. For responsive layouts, the largest grid would have 12 columns, and then for smaller screens we could have one with 8 columns and the smallest one with 4. I don't think we should use any grid gutter as it just complicates things. Drop algorithmI think it’s a good idea not to have any layout previews for now, and I agree that they can be confusing.
I like the idea of splitting each component into quadrants with diagonal lines - we just might need to reserve some area in the center of container components too. I agree that the most deeply nested element should always be the one selected if there’s multiple elements under the cursor.
I like the idea of having some kind of modifier or hover menu for selecting components at multiple levels. Notion-style UXI believe we could add something like this later on top of this drag and drop system, so different users could have different options? I'm sure there would be flaws and unpredicted obstacles in this concept, but what we need is a concept good enough for me to start experimenting with and we could make changes along the way, and try fixing any flaws that come up. |
Closed by #466 @apedroferreira? |
i'm working on this #359, which could be kind of considered a sub-issue of this one. |
Closing this issue as basic functionality for everything mentioned here seems done to me, even though there's lots of room to improve these features of course. |
Visual editor
This RFC tries to specify a paradigm for our visual editor. For internal tooling we want something that allows for flexible layout, yet is constrained enough to require minimal manual tweaking.
Regular components
fullWidth
property onTextField
). Other components will horizontally adapt to any width imposed on them (e.g. image, datagrid)Layout components
In terms of layout we identify two types of components, columns and rows.
column
a column works vertically. It acts as a component on the horizontal axis (adapt to the width imposed to it by the layout algorithm). It serves as the container for rows. Its only possible children are rows and its only possible parent is a row. A only needs to be manually created when the user wants to build something like a sidebar.
rows
Rows are never created explicitly, they are implicitly created depending on the drop position of certain elements
page
On the top level, a page acts as a column
Drop algorithm
We must avoid layout shifting as much as possible, therefor we will not live preview elements as they are dragged on the page. Dragging a new element only highlights cursors as available drop targets. Dragging an existing element, to move it around, stays in place until the drop is performed.
The biggest challenge of drag and drop visual editor is to calculate a predictable insertion position for the drop target. I propose the following algorithm:
For any other [X,Y] mouse position during the drag
This algorithm takes care of the most common situations, top level inserts and inserting at the deepest level. In very deeply nested layouts it may be necessary to insert an element in between two nested layout components. I expect this to be an edge case for internal applications, but it can be solved by designating a keyboard modifier (shift or Cmd) that opens a context menu with all the container components in the same axis which can then be hovered to specify the exact insert position.
Resizing components
Should changing the width of a component or moving it around in its row be constrained by the available columns. Or should rows be allowed to overflow. Will overflow behavior be necessary to allow responsive design? (e.g. width = 3 columns when lg, 6 columns when sm,...)
Benchmark
This RFC borrows some ideas from makeswift.com. Stronlgy encouraged to familiarize yourself with its editor canvas implementation.
considerations
The text was updated successfully, but these errors were encountered: