Skip to content
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

Open
djay opened this issue Jan 8, 2016 · 14 comments
Open

UI: too much jumping around (via new UI) #705

djay opened this issue Jan 8, 2016 · 14 comments

Comments

@djay
Copy link
Contributor

djay commented Jan 8, 2016

User problem

There are several places in the UI that require lots of clicking, switching screens in the process of creating forms. e.g.

  • can't add fields until you save a form once
  • can't do partial save on a form and return to layout editing.
  • saving formulas often require saving and then scrolling down the form to return to editing.
  • you sometimes have to jump between form layout at code or fields.
  • you have to pick an ID before you can add a field.

Options

There are a bunch of ways to solve this. Here is a mockup of one idea.

1. [x] IDE Settings in tabs

  1. Single page app similar to IDE or theming editor (ACE)
    Combines the following ideas
    • filterable tree control to get at all elements including fields
    • Can open many forms, fields etc at once and save and continue editing. Can tab between them and leave them unsaved.
    • New [+] just asks for a name and then opens in a new tab.
    • Form UI is split into 3 kinds of pseudo files.
      • Layout is the primary view using tinymce. Creating/editing a field etc opens a new tab.
      • Code view combines all formulas into a single pseudo .py file so you can edit them all in one place. Unused formulas use "pass".
      • Settings view is everything else from DX just pulled via AJAX. Probably reordered a bit.
        • Adds in the helper idea (see common formulas without coding (via helpers) #618) to the setting screen. Not really related to this issue though. But could mean less clicking to get repetitive formulas done.
        • Another possibility is that they are pseudo files also and appear under the Form.
    • Overlays used for ACL, DB settings and import/export.
    • Not themed at all.
    • plone toolbar only used for plone stuff.
    • Preview might come up as a split pane so the form can be tested while edited.

2-plomino redesign

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

screen shot 2016-11-21 at 10 49 56 am

screen shot 2016-11-21 at 10 49 46 am

see https://app.moqups.com/[email protected]/jbaUkc1plo/view

Similar to above except:

  • code and settings don't appear as their own tabs. Settings for fields should be on the same screen as the visual fields and having one tab per form makes tabs less confusing.
  • the settings for fields, forms, db etc appear next to the editor. in particular you can edit field settings which still seeing the field you are editing.
  • there is a palette to quickly add new fields and templates (see can't quickly add (via palette) #757). This will combine with layout macros which will give the capability to turn a subform into a reusable template which can repeatedly be DnD onto a new form. In particular it allows label and field combinations to be created quicker.
  • You can make a form tab switch between code and layout mode.

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.

@ebrehault
Copy link
Member

I love the idea.
I am pretty sure it is a lot of work, but such a tool would be very useful.

Maybe plone.restapi could be helpful (instead of implementing the backend endpoints needed by this single page app, we just use plone.restapi).

@ebrehault
Copy link
Member

@djay FYI, I will have an intern working on that topic (starting in April)

@djay
Copy link
Contributor Author

djay commented Feb 10, 2016

@ebrehault thats fantastic news. We intend to work on helpers idea once we get client signoff (#618).
One thing I didn't put in the mockups above was an alternative UI for helpers being virtual subobjects as well under Form or Field. I'm not really sure about it because then logically a helper instance should have a name, which it doesn't really need to. On the other hand, to include it inside the settings screen ( asin the mockup above) means its kind of a CRUD inside a CRUD. What do you think?

@djay
Copy link
Contributor Author

djay commented Feb 18, 2016

I think two additional things missing are

  1. DND of fields into tinymce
  2. editing properties of fields/objects without having to click to open an overlay. onscreen at the same time. split screen maybe with tinymce on one side and properties on the other?
  3. switch tinymce for mosaic. esp if there is a way to allow tiles inline as well as a block,

@ebrehault
Copy link
Member

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
Copy link
Member

@djay work in progress! @Bo-Duke started today.

@djay
Copy link
Contributor Author

djay commented May 25, 2016

@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.

  • a field or label can perhaps be tiles.
  • But a subform can't be a tile I don't think.
  • A hidewhen would have to be a property of a row or tile.
  • Accordian would also be a property of a tile I think.

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.

@ebrehault
Copy link
Member

@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.
When you design a form, you should be able to write it from top to down just like if it was an actual paper form.
TinyMCE proposes a Word-like approach, while Mosaic is an Excel-like approach. My experience is that creating a form with Word is just fine, but creating one with Excel is a nightmare.

Nevertheless a dual mode could be useful in some cases.

@djay
Copy link
Contributor Author

djay commented Jun 10, 2016

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

@djay
Copy link
Contributor Author

djay commented Oct 6, 2016

@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.

@ebrehault
Copy link
Member

true, makes sense

@djay
Copy link
Contributor Author

djay commented Oct 18, 2016

New UI mockup.
https://app.moqups.com/[email protected]/jbaUkc1plo/view

Main differences are that

  • code and settings don't appear as their own tabs.
  • there is a palette to quickly add new fields and templates. click to add to the bottom, or DnD.
  • the settings for fields, forms, db etc appear next to the editor. in particular you can edit field settings which still seeing the field you are editing.
  • similar to https://www.wufoo.com/form-builder/

@djay
Copy link
Contributor Author

djay commented Dec 16, 2016

Need to get the visual fields feature working in the ide.
To do this need to look at how the code in tinymce.js works from this branch - https://github.com/plomino/Plomino/tree/tinymce_field_settings and make it work instead when you drag a field from the left tree into tinymce in the IDE code here - https://github.com/plomino/Plomino/tree/tinymce_field_settings/ide.

Currently the IDE just inserts spans like this
screen shot 2016-12-02 at 3 47 37 pm

Where as we want it to insert the same example widgets in the visual fields branch such as
screen shot 2016-12-05 at 11 08 31 pm

@djay
Copy link
Contributor Author

djay commented Jan 31, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants