Jump to:
| Project: | Form Builder |
| Version: | 7.x-1.x-dev |
| Component: | Form Builder Core |
| Category: | task |
| Priority: | critical |
| Assigned: | Bojhan |
| Status: | active |
Issue Summary
With D7UX Project I have been fairly distracted to work on any Formbuilder UI stuff. But neither less wanted to give my dump of design issues that need to be solved.
A new tab on each widget settings :
Data Storage
- Database settings
- new page?
- prominent in widget creation
- field_name?
**- Set if you want to share it across other content types**
There needs to be work on the pallete:
Pallete.
- Styles (Vertical tabs ect)
- Existing fields
- Being able to collapse (20+ widgets)
The option tab needs to be designed to accommodate more:
- taxonomy
- pathauto
- default tokens
Workflow for data storage
- field_name!! (display not important after configuring, it needs to be configured)
- field-type (after, or sensible default)
Seperate UI
- Dislay of field is seperate UI
- Linking existing fields
Comments
#1
Jeff Noyes put up http://jeffnoyes.com/content/drupal-cck-fields-ui , which is quite similair to our idea but focuses more on existing widget model. I hope we can find a good solution for existing widgets as well, right now our pallet for it is kind of hard to use.
#2
Clearly Form Builder is not going to get into Drupal 7 core at this point. We should open separate issues for these tasks if they will be implemented in Drupal 7. In truth, the CCK (or Field) implementation of Form Builder should be done in a different module entirely and use Form Builder as an API.
#3
I am going to reopen this, although I agree that they need seperate issues. Lets atleast have this issue open untill that happend.
#4
Obviously not going to happen in D7.
#5
Err.. this is an any version issue, and your D8 queue is not open yet.
#6
From @dasjo in #1266976: Form Builder in Core to provide Schema, Form & Display fields edit forms (marked duplicate):
#7
I've been thinking about what the UI should look like too and I just took another look at that session from DC London. I like the 3 tab approach mentioned above -- schema, form, and display. But I have a couple other thoughts:
1 - Display has to allow for multiple views. Many sites I work on have a half dozen or more view modes for each content type. So I guess that would be sub-tabs under the display tab. But form builder would have to be smart enough to add every element to every display as it gets dragged in.
2 - Every project I have ever worked on starts with wireframes of the way the site will look. Now you have to look at the display, mentally break it down into the elements it represents and figure out what type of field it would be, and then think about what element would be used to input that value.
So if we want to make the process of creating content types in D8 easier, I would want to provide a way to start with the wireframe to create a rough representation of the display --drag in a formatter, give it some settings and identify what kind of data it holds (the schema). The schema would automatically get built from the settings used for the formatters and each data type could start out using whatever widget is the default widget for that type, but you could switch back to the schema tab at any time to see what your content type contains, and to the form tab to select the specific way that people would enter that information.
#8
And for the 'hint' of what the element would like when displayed, you could populate a dummy field with values using the same hooks we use to provide dummy values to Devel Generate, then use the formatter to display it, so a long text field would have a block of ipsum lorum text, an image field would have a auto-generated image, etc.
#9
@KarenS I think you are fully in line with what we are thinking. The questionable thing is, for users is it "display first" or "form first" - the research we have done in the past years and the polling that quicksketch did its still a bit inconclusive. From reading your post, you want "display first"?
From my perspective, ideally we can do both. But I assume that is one nasty idea :) Creating designs for this is on the schedule of the UX-team, but we currently have our hands full with module redesign.
#10
http://blip.tv/jeffnoyes/d7-cck-fields-ui-2712754
#11
I was referring to the demo quicksketch had at the very end of the DrupalCon London video linked to above. He brought up a way to incorporate all these elements into the same UI using tabs that looks like a potential way to make it relatively easy to work from either end in.
I still disagree with all the people who insist that someone other than a developer who is looking at a wireframe and trying to figure out how to implement it is going to even think about forms. In most projects I've worked on they don't even have a wireframe for the form, none of the non-technical people are thinking that way at all. They have a wireframe of the way it will be displayed and they want to figure out how to display it. They eventually figure out that they need a form to collect the information that will be displayed, but that is not where they start out.
#12
@KarenS I would personally agree, I wonder if nate could add notes - what the conclusions where from his feedback round.