 | Kevin Cook 9/26/2007 11:49:25 AM Perhaps another way to compress the edit form, is to have a third column option, in addition to the second column option?
|
 | basenine 4/23/2009 2:01:16 AM It would be great to be able to create a section in the second column in a "Form" view.
|
 | Philipp Matuschka (MMB) 3/23/2011 1:21:03 PM This looks excellent
|
 | Ben Fatchen 3/23/2011 4:18:38 PM Love it. This will greatly improve data entry logic for a number of our users.
|
| basenine 3/23/2011 5:05:16 PM Fantastic - it's possible to do, yes?
If so, let's just do it :)
|
 | Scott Miller 3/23/2011 5:49:53 PM Excellent. Ready by tomorrow?! :-)
|
 | Rick Cogley 4/11/2011 6:31:27 PM Any flexibility is appreciated. This looks very nice.
|
 | Kirill Bondar 4/15/2011 4:46:24 AM |
| Kirill Bondar 4/15/2011 4:54:14 AM If you wonder what's happening - our goal is to let users avoid multiple input forms and use single, default form for everything. All layout variations should be handled with behaviors. So, new layout, drag-and-drop editing and all other goodies will apply to default forms only.
Also:
* layout now adapts to page size;
* field label is moved to the left to make default (full-width) form vertically compact. Though there will be an option to display the label above the field content (likely relevant for 1x controls and multiline fields).
* Boxes have rounded corners if the browser supports it.
I'll post more mockups next week.
|
| Philipp Matuschka (MMB) 4/15/2011 8:51:17 AM Kirill
This looks like a great plan. While you are at it, would you consider putting in multi-language support. This is becoming an ever more pressing issue for me.
Thanks
|
| Kirill Bondar 4/15/2011 9:21:00 AM @Philipp: multi-language support should not be limited to forms: there are tables, columns, views, buttons and a lot of other stuff that appears in the UI.
|
| Philipp Matuschka (MMB) 4/15/2011 7:11:02 PM I quite agree, but one needs to start somewhere. I wrote multi language systems myself years ago, so i know how much effort is involved
|
 | FCI ADMIN 4/21/2011 1:00:50 AM If possible, Please have sections with different colors. it does not have to be user control feature. You can default sections with pre-select colors.
I love a new proposal form design you are working on.
Thanks
|
| Scott Miller 5/10/2011 9:22:59 AM Hi Kirill
Any updates on this? You mentioned posting some mock ups.
Thanks
|
| Philipp Matuschka (MMB) 5/17/2011 11:08:02 AM Looks fantastic to me. So much more professional than what we have now
|
 | Michael Ver Duin 5/17/2011 11:22:23 AM Can't wait to try it. Look great!
|
| Kirill Bondar 5/23/2011 10:14:29 AM NOW in Labs. When enabled, Default Form's behavior changes; more setup controls will be available.
It is in early stage and works goes on - don't even try to use it in a production environment. There are known problems with layout in IE6/IE7; editor is clunky and will be replaced with WYSIWYG version with more layout options.
|
| basenine 5/23/2011 6:40:41 PM Yep - it will look good... Like you mention - a bit clunky to edit at the moment but I'm sure that will be resolved with the WYSIWYG.
Is all this going to be ok with Firefox/Safari and Chrome?
Cheers
|
| Kirill Bondar 5/23/2011 7:18:18 PM The layout uses CSS float box model which is the part of CSS1 standard released in 1998. Every more or less modern browser is capable to render it without problems.
IE6/7 claim to support float box model but have buggy implementation and it is a lengthy trial and error process to make it work there - not a high prio task for the moment.
|
| Kirill Bondar 5/25/2011 7:41:19 AM We've updated the layout slightly: extra paddings were removed so now it matches old version by height. Also, removed gray backgrounds in edit mode.
|
| Kirill Bondar 5/25/2011 7:44:18 AM Assuming, we'll enable displaying column descriptions as tooltip OR as text above/below the input control, the question is: do you really need text sections? An another one - should the sections have own description text?
I know, I know, more features means more flexibility, but we'd like to keep it as simple as possible so please do not vote for "to have it all" :))
|
| Kirill Bondar 5/26/2011 8:56:38 AM To simplify testing we've added "Copy to default form" button to non-default forms - it will convert existing layout to the new model of the default form. Sections state formulas are converted to behaviors as well.
|
 | gerardo garcia 5/26/2011 1:27:46 PM @Kirill when do you estimate this will this be safe for production?
|
| Kirill Bondar 5/27/2011 8:32:53 AM We are testing usability ourselves and perform small adjustments here and there; hopefully we'll finish by the end of next week. For WYSIWYG editor we'll need some more time.
Generally you can turn grid layout on or off anytime - there no conversion process, the switch only affects the way default form renders on the screen and there is minimum amount of code forks, mostly in setup parts (extra buttons etc).
Please remember:
If you have custom forms everywhere - they remain handled in an old way whether grid layout turned on or off.
I guess admins likely have a separate role in the app - so, they can be assigned the default form for viewing and editing. You can turn grid layout on, rearrange the controls, add sections etc. If you encounter the problem, you can either turn it off, or reassign old form back.
|
| Scott Miller 5/28/2011 4:50:20 PM In the proposal the column names appear above the columns. Do you intend for this to be an option? It is aesthetically pleasing in your proposal and I wonder what it would look like in general use.
|
| Kirill Bondar 6/1/2011 5:15:16 AM Added "Label above" checkbox, cleared by default
|
 | Liquid Rapid 6/6/2011 4:53:45 PM This is awesome! I love the greater customizability. The flow-based layout and a WYSIWYG editor would both be awesome. The idea of controlling section visibility with form behavior is great - I've wanted to do that in several situations.
I'm a little wary of the idea of only having a single form. I use multiple custom forms to achieve a few different things. I would want to know that I would still be able to do these things with the new form functionality before I switched over. (Would I just create different sections, and show and hide them with behaviors?)
One thing I do with custom forms is provide different forms to different roles. You mentioned this one above. For example, I have one form for application admins, another for company admins, another for the sales team, and another for all non-sales staff. They each have different columns visible, in some cases the same columns visible but with different editability (ie, readonly on the staff form, but editable on the company admin and application admin forms). In some cases, the different forms have the same columns, but laid out differently. ie, on the staff form the column is in one section, but on the application admin form - since the app admin has so many more columns, and uses them differently - that same column is in a different section. Would I be able to do that with a single form? Maybe I would have the same column on the form multiple times, in different sections - then show and hide those sections per role?
Another thing I do with custom forms is assign them to buttons. This is a key feature in virtually every application I build. I depend on it in many places. I create a simple form appropriate for doing one particular action - like retiring an employee, where you only want to enter the date of retirement - then assign that to a Custom Action button. I think it really enhances usability to have context-sensitive forms in this way. The context in this case being the action the user is performing. Would there be some way of achieving this with the new, single-form functionality?
Re these questions:
>Assuming, we'll enable displaying column descriptions as tooltip OR as text above/below the input control, the question is: do you really need text sections? An another one - should the sections have own description text?
I definitely vote yes to keeping a "text element" feature. I use it regularly on forms to provide a kind of "overview description" of how to use the form. Also, when I have multiple custom forms on a table, they each have their own overview text. I would vote for the capability of controlling visibility of text elements with form behavior, the same way you suggested controlling sections with form behavior.
I also use the "Show as HTML" feature of text elements on forms. In a few places, I have images displayed on the form, in text elements. The images complement the overview by providing a visual diagram of the data flow in that table, to help users visualize how to use the features of that table.
I haven't actually done this yet (besides testing), but I would want to keep the ability to embed Javascript into a form in some way. Right now I would do this with a text element shown as HTML, with Javascript code in the text element. I have a few ideas for cool features that require Javascript embedded on the form.
The idea of sections having their own text descriptions makes a lot of sense to me. I guess if there were text elements, I could simply create a text element as the first element in a section, and use it to display a description of the section.
Great idea - nice one guys!
|
| Kirill Bondar 6/7/2011 4:51:36 AM @Nathan
Multiple layouts - Setting form element to readonly/required depending on role could be done via behaviors. But having (completely) different layouts... well, this might be a problem.
Custom Actions - simple ones - to ask user for the value (optionally) and assign it to selected record(s) can now be done with "Custom Buttons"
Text sections - to keep them as a separate entity or not - final decision will depend on usage. Displaying description near the input control would allow to handle many of scenarios currently in use. To provide advanced formatting or to display images based on record's data you can use XHTML-Formulas. Yet at the moment there is no replacement for JavaScript scenarios.
|
| Liquid Rapid 6/7/2011 3:24:52 PM Hi Kirill - Thanks for your reply to my long comment!
Re the Custom Actions vs Custom Buttons - Yeah, I know about the "allow user to edit columns" feature of Custom Buttons. But it doesn't let me control the layout of the columns I select. They seem to be ordered randomly, near as I can tell. Possibly in the order the columns were created (ie, alphabetical by column ID). And I also don't have the ability to section the Custom Button forms, or to display a normally-editable column as read-only or required on those small forms. Those are the features I turn to Custom Action buttons for.
What I often want to do in these action-specific forms is display some data to the user, relevant to the action they're performing, as read-only. It's possibly editable data (on a normal form they can edit this column), so I need to be able to control the editability of the column on the action-specific form. Or, a lot of times I want to make a column required on the action-specific form, which is normally editable but not required on the main form. ie, it's something that's normally editable but optional, but when performing this particular action it's a piece of data that's absolutely required to complete the action.
If I could link in forms to Custom Buttons, I would use them instead of the Custom Actions feature. Or, if I could define a form directly on the Custom Button, the same way I define the main forms, then I'd be able to do the same things. I'd prefer to use Custom Buttons, but they just don't let me do the things I want to do. And if the new form layout functionality means I lose this key functionality, that I can't do any other way, I would (reluctantly!) opt out of using the new feature and stick with the old forms functionality.
|
| Liquid Rapid 6/7/2011 4:29:29 PM More on how I use action-specific forms - I just realized that in some places I actually use a Text element on the action-specific form to provide some direction on what to do to complete that particular action, or notes about the action.
Like: Enter the start and end dates of the extended leave. The start date must be on or after the first of the current month.
I think, again, that really helps with usability - the ability to provide contextual direction built-in to the interface.
And here's one that actually has legal ramifications: By clicking Save on this form, you agree that the details on your time sheet below are accurate, and you agree to the following company policy. [... and then the policy, in the Text element]
So I'd like to keep the ability, in some way, to display action-specific directions and notes.
|
| gerardo garcia 6/7/2011 4:31:33 PM I also use that action-specific directions specially with external users.
|
| Kirill Bondar 6/8/2011 6:19:02 AM As far as I remember behaviors work for custom buttons as well. What if we add some layout abilities to buttons as well as pseudo-variables to determine what button was pressed?
|
| Liquid Rapid 6/8/2011 1:36:55 PM Hi Kirill - That would be awesome! That would allow using Custom Buttons for these things, which I would actually prefer. The Custom Action buttons aren't affected by form criteria, so I'm stuck with only static forms there. If I could use Custom Buttons for these action-specific forms, that would add the ability to make dynamic, action-specific forms. I would happily move everything over to Custom Buttons.
As long as I have some way to display text on the button forms too, for directions and notes, I'd be happy.
Maybe also a pseudo-variable for "no button pressed", so I can control behavior differently outside of actions.
|
| Kirill Bondar 6/10/2011 6:59:36 AM To work with related tables, you need to show reference column in edit mode to render record picker. In view mode, you likely need to hide reference as it often contains some meaningless ids, yet you need to show a lookup column to render readable value.
Today, we've made one subtle change in a new layout logic.
In edit mode, reference column renders a record picker. In view mode, reference column will display the content from the "Name Column", as specified in the relationship.
|
| Kirill Bondar 6/10/2011 7:16:04 AM As we are moving toward the completion of new layout we've made some menu reorg when "gridlayout" lab is enabled.
Forms menu now consist of "Set default form", "Behaviors" and "Web-To-Records". All functionality related to non-default forms is moved under Rules > Custom Forms.
Web-To-Record (W2R) behavior will be also changed. We'll allow to have only one W2R per functionality table. Enable W2R, select the columns you want to be updateable, save, and on the next screen you'll find HTML template available for further customization.
|
| Liquid Rapid 6/10/2011 2:55:10 PM >In edit mode, reference column renders a record picker. In view mode, reference column will display the content from the "Name Column", as specified in the relationship.
Nice, that's great!
|
 | Brent Bischoff - Admin Account 6/24/2011 5:44:33 AM Like to new form layout but would like more formating options to be available. I would like to be able to control font type, size, fore and background colours with text and sections. Would also like the ability to have a sections within a section to provide the option to create sub sections under a main section group.
|
| gerardo garcia 6/24/2011 5:07:52 PM On previos form layout if I had a link button, you have to press the button within its boundaries.
On Grid form layout if you click on any empty space infront of the button it will activate the link. This is amplified when button is 4x with instead of 1 or 2x.
Is this on purpose?
It is not a great problem, just that I found myself opening unwanted links some times because of my habit of doing clik in form "empty spaces" to change the mouse position.
|
 | Damon Savage 6/30/2011 11:40:44 AM Not sure if this has been mentioned. I think it would also be helpful to add an edit button capability for each section of a form. So if sections are added to the form, you can make just that section editable by clicking the edit button to the right of the section rather than having to edit the entire form just to edit a section of it.
|
| Liquid Rapid 7/30/2011 5:13:33 PM I realized there's one more important thing I use Text elements on forms for:
>Text sections - to keep them as a separate entity or not - final decision will depend on usage. Displaying description near the input control would allow to handle many of scenarios currently in use. To provide advanced formatting or to display images based on record's data you can use XHTML-Formulas. Yet at the moment there is no replacement for JavaScript scenarios.
I use HTML text elements to create subsection headers on large, complex forms. Some of the forms I have in production are long, with many sections. I think a few actually take up more than an entire screen on my monitor. Some of the sections may have 20 or 30 columns in them. To help keep that complex interface under control, I split the sections into subsections, by creating text elements that act as subsection headers.
I simply wrap the content of the text element in < b > < / b > tags. That bolds the header text to differentiate it from the data on the form. I've experimented with using columns to do this, but I don't like how the column name is shown. Text elements have no column names, so they can't be confused for data on the form. I'd hate to lose this subsection capability; losing this capability would hurt the usability on few forms I have in production.
|
| gerardo garcia 8/18/2011 4:14:14 PM Email notifications now come in table format.
Would be great if field names and sections would have a gray or light blue color background. Also if the link buttons could work. Only works (in gmail) if instead of button there is a link. Thanks.
|
| Kirill Bondar 9/8/2011 7:12:59 AM Support for text sections is online. Next is to fix the styling finally. Then adopt email notifications to match browser style.
|
 | mcook 9/8/2011 5:28:26 PM Kirill, I am most impressed on how you efficiently used Idea Exchange on this issue. It makes us want to use our Idea Exchange in the same manner.
|
| Kirill Bondar 9/9/2011 8:48:41 AM @Gerardo: button is now rendering as a link in e-mail notifications, in both new and old style forms; this was an obvious bug.
|
| gerardo garcia 9/9/2011 8:51:30 AM Thanks Kirill!
|
| Kirill Bondar 9/9/2011 9:00:00 AM Yet another update today.
4-column layout works well on 1280px screen with sidebar shown in every desktop browser except of IE6; latter needs more brute force. Visual style is now close to a final stage. Comments and suggestions are appreciated.
On narrow screens sections and elements will fold; we'll try to make folding logic more predictable in the next update.
|
| Kirill Bondar 9/9/2011 9:22:47 AM Just to clarify: "New layout" is completely different code path, so you should be able to switch forth and back without any hassle.
1) Grid Layout should be enabled in Labs, once disabled everything is rendered in an old way.
2) Only Default Forms are rendered in a new style. If the role has custom form associated with it, it will be rendered in an old way. This logic allows you to switch to a new style gradually.
3) Old style default form uses column order defined in the table. New form settings are stored in separate structures. Changes made to new default form do not affect old default form.
4) Section and text-related behaviors are applied to new forms only.
|
| Kirill Bondar 9/9/2011 4:53:53 PM Merged with:
168 - Third Column for Edit Forms
|
| Philipp Matuschka (MMB) 9/12/2011 5:40:15 AM Kirill. Just looking at how the new style forms look on my screen. Suggestion: Where field names need to wrap (and this happens me quite often as I am migratin my system to German) would it be possible to do vertical centering rather than just a straight wrap. I think this would be more intuitive.
|
| Kirill Bondar 9/12/2011 8:10:59 AM E-Mail notification's style now matches screen style. E-Mails use table-based layout and basic HTML features as much as possible so they should render (almost) equally in any mail client including web-based, such as Gmail.
|
| Kirill Bondar 9/12/2011 8:17:19 AM @Philipp: The only elements that are centered vertically are table cells. Table rows, however do do not fold to fit the screen. New layout tries to simulate table, but is not table per se to enable folding; cells do not have equal height to be centered vertically. Maybe there is a hack we do not know of, but I'm afraid vertical centering is technically impossible in this case.
|
| Kirill Bondar 9/13/2011 8:17:49 AM In absense of drag-and-drop editing we've added a small bonus for admins.
When mouse is over the field, small dropdown arrow appear in the left corner of a cell. Clicking an arrow opens dropdown menu with some common form editing operations.
|
| Kirill Bondar 9/28/2011 10:13:18 AM Today we've issued another update - getting closer to "implemented" status.
Section headings are now emphasized.
Edit mode does not gray control cell, instead, entire block for the control that has focus is grayed.
Setup part was also revamped a bit. Most noticable is a new Preview button: it allows view to check form's appearance in either view or edit mode for selected role and form behaviors.
|
| Kirill Bondar 9/28/2011 10:26:03 AM So far the most questionable point is the with of controls' label.
Minimal block size is 1/4 of total form's width. No problem when the lable displayed above, but might be one to display the label and the control side-by-side. And display controls in the grid we have to use the same label width for any block width.
On a 1280px screen with sidebar turned on the form's width would be around 1080 pixels. 1/4 block's width is then 270 pixels. From this size the label takes about the half. This might be OK for 1/4 block, but it's too narrow for 1/2 block.
Yet, we doubt someone will use 1/4 blocks to display the label and the control side by side. So, the idea is to force "Label Above" for all 1/4 blocks. Since we won't care about 1/4 label's width anymore, we can safely increase it.
|
| gerardo garcia 9/28/2011 7:49:39 PM Thanks Kirill.
Im good with force "Label Above" for all 1/4 blocks.
|
| Philipp Matuschka (MMB) 9/29/2011 4:17:14 AM I've noticed that when you now add a new field to a table, it automatically adds this, slightly randomly, to the top of the form, either just above the first section or just inside the first section. In the old system, it used to put these fields at the bottom of the form, where they were less intrusive or automatically found themselves in a collapsed section called say "More ....".
Could I request that either the old system is re-adopted or that new table fields are not automatically added to the form at all, or some other variant. But definitely the current solution seems sub-optimal.
Thanks
|
| Kirill Bondar 9/29/2011 4:29:34 AM @Philipp: The principal difference between old and new is "System Columns" section. While in old form we were rendering it automatically based on a flag. Because of automatic section rendering it was enough to insert new column to the end of the form.
In a new approach "System Columns" section and its content behaves any other section/column.
To determine the position to insert new column we scan the form from bottom up to the top while we encounter system columns like key/owner/users/dates of creation/modification. If the section comes up next we skip it as well (assuming it's a System Columns section). Resulting position is the position to insert (or, at least it should be).
We'll investigate the situation.
|
| Philipp Matuschka (MMB) 9/29/2011 4:41:02 AM OK, I see your logic. Even if I would have done it differently, it is consistent. However it doesn't seem to be actually working that way.
Thanks
|
| Kirill Bondar 9/30/2011 10:16:00 AM @Philipp: Thanks for the report, fixed.
|
| Kirill Bondar 10/6/2011 7:39:31 AM |
| Kirill Bondar 10/9/2011 7:55:47 PM |
| Rick Cogley 10/20/2011 8:08:01 PM Hi Kirill - we are planning out how we might migrate to this new functionality and the custom buttons issue is one that will affect us. I was wondering if you or how you might have handled the items you and Nathan are discussing around your comment:
> What if we add some layout abilities to buttons as well as pseudo-variables to determine what button was pressed?
Please advise.
|
| basenine 2/28/2012 9:59:35 PM Hi there Kirill et al, Just a thought on the new form layout... I noticed that in your very 1st example: http://teamdesk.crmdesk.com/image.aspx?mode=file&id=8559the "View" is clean and crisp. With what has been implemented, it's slightly harder to view. I think the mockup version is easier to read simply because there is an outline around the grey field box. Would this be easy to implement in the next update? Cheers |
| Kirill Bondar 3/1/2012 5:23:45 AM @Brett - mockup is indeed beautiful, but unfortunately, when we start experimenting with real layouts we quickly realized that borders paddings and spacings add visual noise to default forms.
|
| basenine 3/1/2012 5:31:26 AM Thanks Kirill,
It does take a lot of time tweaking the layouts to get the look as simple as possible but the flexibilty is awesome.
Cheers
|
| Kirill Bondar 7/1/2013 10:08:52 AM Merged with:
255 - Ability to create section in second column in form
|
 | Kelly Waters 8/18/2013 9:53:30 AM i tested the new form format lab.
all the forms were gone! I could only edit the default form,
i switched back so I could see and edit the existing forms.
thanks
|
 | Slava Shinderov 8/18/2013 9:58:08 AM |
| Kirill Bondar 6/11/2014 10:26:15 AM |
| Rick Cogley 6/11/2014 6:50:23 PM I'd really like that, personally. Anything that makes forms easier to make.
|
| basenine 7/18/2016 2:22:31 AM I'd like to suggest that the "new" Forms grid layout be updated to the following (or at least have an option to):
When any number of columns wide is selected in the grid, say 3, it takes up the whole width of the page instead of just ¾ (or ˣ/₄) of the page width.
|
| Philipp Matuschka (MMB) 7/18/2016 2:49:55 AM Good idea
|
 | Philipp Matuschka 2/24/2017 7:20:26 AM Brett, I get the feeling that once an idea is marked as Implemented, additional comments don't get looked at any more. I am about to open a new Idea for Form Layout and you may want to add your comment from 7/18/2016 to it
|
 | nathan tanner 8/5/2021 8:09:57 AM I would like to have it so that once a layout is designed, that based on user role the layout is LOCKED or NOT LOCKED. Meaning, i do not wish for all users to change the layout.
|
