-
Notifications
You must be signed in to change notification settings - Fork 37
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
UI: too much jumping around (via new UI) #705
Comments
I love the idea. Maybe plone.restapi could be helpful (instead of implementing the backend endpoints needed by this single page app, we just use plone.restapi). |
@djay FYI, I will have an intern working on that topic (starting in April) |
@ebrehault thats fantastic news. We intend to work on helpers idea once we get client signoff (#618). |
I think two additional things missing are
|
Use Mosaic to manipulate the form layout instead of TinyMCE sounds strange (physically, a Plomino form layout is an HTML string, Mosaic is not an HTML editor). |
@ebrehault mosaic is actually an html editor. Just that it moves around place holders which are html, in the same way that plomino moves around place holders which are html. The difference is that mosaic placeholders have to be grid cells. I'm not sure how that would map into plomino.
But then how do you have fields inside a table for example? Either it would require something like shortcodes/line tiles (tinymcetiles) or two modes, mosaic vs tinymce. |
@djay I don't think the technical difference is really the key thing here. I am more worried about the functionnal difference: when you edit a form layout, you really don't want to cut it down into columns and rows, or to snap to any grid. This is not flexible. Nevertheless a dual mode could be useful in some cases. |
Created a new issue that should really be part of this one. I don't think I really showed this in the mockups above and was just wondering if this was going to be included in the IDE work? #736 |
@ebrehault I've been thinking about it more and I think settings shouldn't be in its own tab. I suggest that all form, field, action, hidewhen settings appear in a splitpane to the right of the form layout to which they belong. I think it will feel natural to use the layout to click on a field and then edit its settings without having to switch tabs. This will also reduce the opening and closing of tabs as only one settings within a form can be open at once. It also means you don't have lots of repeated fieldids cluttering the screen. |
true, makes sense |
New UI mockup. Main differences are that
|
Need to get the visual fields feature working in the ide. Currently the IDE just inserts spans like this Where as we want it to insert the same example widgets in the visual fields branch such as |
Latest branch we are working on and instructions to build and test are in https://github.com/plomino/Plomino/blob/advanced_ide/ide/README.md |
User problem
There are several places in the UI that require lots of clicking, switching screens in the process of creating forms. e.g.
Options
There are a bunch of ways to solve this. Here is a mockup of one idea.
1. [x] IDE Settings in tabs
Combines the following ideas
Option 1 seems like a big change but with reusing code from the theming control panel it might not be too much work. Possibly the most work would be the code view but it doesn't have to be very smart to start with. It could throwing away code inbetween functions and not allow custom ordering. Later those could be fixed by storing in special comments.
2. [v] IDE settings in splitview
see https://app.moqups.com/[email protected]/jbaUkc1plo/view
Similar to above except:
plan
Option 1 has been partially implemented in Angular 2 here - https://github.com/plomino/Plomino/tree/tinymce_field_settings/ide.
This branch also has some enhancements such as fields in tinymce being more visual.
Option 2 (IDE with a tab per form) is better so we will refactor the code to incorporate these features.
The text was updated successfully, but these errors were encountered: