For those of us that have been holding off a bit on getting to know the new Designer in Forms, Update 3 to version 11 might be the right time to make the switch. I've spent a couple weeks getting familiar with it so want to share my thoughts here as well as hear what other have picked up.

I was in a spot where UAT was about to begin, so I took the holiday slowdown as a chance to refactor those processes to use 1 large form designed with the new Designer rather than 6-10 individual forms using the old-style Designer. Here are my main notes; I'll use number formatting not because the order matters, but to make it easy to refer to if there is a follow-up comment or question.

1. The updates to Field Rules are super powerful and helpful. It enables me to show/hide various sections based on the process stage. But not just that; things can be made required or read-only by the new field rules, too. It also includes showing/hiding the action buttons.
2. When using rules, you have to think by action rather than step. Meaning, my brain would rather define "at this stage, show A, B, and C and make X, Y, and Z read-only". However, show/hide for a given field or section needs to be within the same rule. That said, you can split out the show/hide and the read-only or required rules.
3. Groups and nested logic really make this work. Which is good because it's easy to accidentally make something required at the wrong stage based on a field set in an earlier stage.
   1. 
4. CSS works about the same as before. Of course, it's not as big a deal now that you can just place fields side-by-side. Since a lot of CSS was to overcome some of the shortcomings of the old designer, it's less necessary now.
   1. And watch out: a lot of the CSS gets evaluated on the Designer itself, so if you're hiding a label or other part of a field, it can disappear from the editor.
5. Read-only fields are not at all obvious, to the extent that I worry users will get frustrated trying to edit a field. No more gray background, just a border around the textbox that is lighter if read-only. From another post, I found this CSS to make fields show as grayed out when they're read-only:

   1. input[readonly],
      textarea[readonly],
      .ng-select-disabled .ng-select-container {
        background-color: #e0e0e0!important;
        border: 0px;
      }

       

6. Likewise, JavaScript is less necessary now given all the additional built-in functionality, which is good because it's quite limited. Calling it "JavaScript" is misleading. It's much more accurately called "Scripting", where most of the logic is tied to the new LFForm Objects. I was able to get a few things working using the Cloud documentation while waiting for the updates to the on-prem documentation, but mostly I had to figure out how to do things with built-in functionality.
7. A couple of things don't work quite right with the new Field Rules
   1. Upload fields made read-only can still have their attachments removed, but not uploaded. Dev team is looking into it.
   2. Signatures have a similar issue of not really being read-only. But this means that any signature gathered before the end of the process cannot be displayed at later steps: it just shows up as an empty, read-only field.
8. There's a new Preview pane for attachments that's really cool. It seems to only be available if you enable previews (where it shows the image below the upload); however, I added CSS to hide that built-in preview but keep the pane option available (don't want to take up so much space).
   1. 

   2. tr.uploaded-file-preview{
        display: none;
      }

       

9. There's an unfortunate bug that makes saving the form into Laserfiche ignore Field Rules and display everything when there are Lookup Rules in place. To overcome this, I made a copy of my form, removed all the lookup rules, and then use that copy in the Save To Repository action. Kind of annoying, but not terrible. If the main form gets modified, just create a new copy for saving.
10. Along those lines, Field Rules to affect the form based on stage of the process should be set by the Stage and not the individual step unless absolutely necessary. If your save to repo step is in the same stage as the final user action, this should ensure they look the same. (This does make using the Preview to test less useful, however.)
    1. 

I'm sure there are other things that I've picked up that I'm forgetting, and more that other people know that I don't yet. Feel free to chime in with your own tips!