22.4 Feedback - major overhaul to process modeler has removed Grid Lines by default

If anyone from Appian sees this anytime soon, here's a non-exhasutive list of Process Modeler quality-of-life features that I've been tracking for a long time now (not 22.4-specific of course), but all of which would improve designers' experience anywhere between "small but frequently helpful upgrade" to "dramatically better" (imho).

• The very continued existence of Single-Line expression boxes (where a multi-line expression can be written, but which will be collapsed to one upon saving) is ... flabbergasting.  I can't even accurately put into words how frustrating this is.
• The modeler Title Bar (the dark-blue area next to the "Appian Process Modeler" label) continues to be a large, empty, waste of screen space, which could be repurposed to show some helpful information about the Currently-Open Model / Instance, which is quickly obscured in the Tab header once a lot of tabs are open.  Instead, when monitoring many open process instances, I'm forced to mouse-over the tab and read the pop-up-text, even to tell which instance i'm CURRENTLY on.
• Right-clicking on Flow Lines should show standard functionality (chaining, labels, etc) FIRST, and then "suggested nodes" after that.
• The Right-Click Menu itself can easily be obscured by the Messages Panel for objects at or near the bottom of the process model.
• Variables in Expression Editor: welcome (re-)Addition, however they leave a little bit to be desired.  What is the data type of this CDT field?  Is this PV a single or array item?  Currently there's no way to tell, and these should be available at-a-glance.
• Process Model [Generated] Documentation: there is no way to see values configured as interface inputs on the Forms tab of User Input Tasks.  Particularly when passing PV values or expression-calculated values into interfaces for read-only purposes.  That means if a PV is used only in a Form input (directly), it will not be seen at all in the generated documentation.
• For the Process Instance Editor: there's no reason the "CTRL+S" hotkey shouldn't save the instance edits (like it already works in the model editor).

If anyone else agrees or has suggestions on any of the above, please upvote / comment / let me know otherwise somehow.  Or should each of these just be submitted as individual support cases?

Agree with pretty much all the suggestions here!

Mike Schmitt said:

Variables in Expression Editor: welcome (re-)Addition, however they leave a little bit to be desired.  What is the data type of this CDT field?  Is this PV a single or array item?  Currently there's no way to tell, and these should be available at-a-glance.

In my little 21.1 instance I have mouse-overs for data types in the expression editor, that is gone in 22.4?

Dave Lewis said:

Also, restart gateways.

Yes!  Not sure why we have never gotten the ability to restart gateways.  I find myself having to edit process instances to put dummy script tasks in front of them to restart at that point.

Mike Schmitt said:

Right-clicking on Flow Lines should show standard functionality (chaining, labels, etc) FIRST, and then "suggested nodes" after that.

Definitely annoying to have Activity Chaining at the bottom, when it's basically the only thing I ever right click on the lines for.  I'm fine if they remove the Suggestions all together.  I don't know of anyone who would right click a flow line thinking, "Should I put something random here?"

A few more adds from my perspective:

1.)  Default End Nodes to Terminate.  90% of my end nodes Terminate, and it's 5 extra clicks each time to configure one as such.

2.)  I would prefer removing the auto-connect which occurs when dropping a node on a flow line.  This has caused me more hassle than it's worth, when moving nodes around in a tightly organized process and you don't realize something has changed flow, a debugging nightmare ensues.  Seems backwards as well to build a flow and then add services instead of adding your functionality/services then connecting them in order.

3.)  Differentiate Smart Services in the left panel by Plugin or Appian/OOTB.  This could help developers realize which plugins they are using, and look for OOTB solutions that might fit the bill first.

I'm sure I'll come up with more 

Chris said:

Ones you show to newer developers, and they say things like "Sweet heavens!!"  

LOL, same here usually.

Though when enhancing old processes, usually the "drop-a-node" is a lifesaver to me - if I don't feel like dealing with it, I'll just go around and clear out some of the surrounding flow lines first and re-draw them afterwards.  But things that used to require like 15 steps, like adding a new dummy node to be a "merge" between flows, is super swift now that you can just drop nodes on lines, especially if you understand how they work (like, drop a script task on the main flow line, then drag and re-drop it on the line where you want the "merge" to happen, and by magic, you now have a Y-merge, instead of having to manually re-draw everything).

Chris said:

turn auto-connect on/off

To clarify on my understanding somewhat, though, what exactly would you hope the new behavior to be, and what would this accomplish / allow you to accomplish that you're currently prevented from doing (or by dropping nodes just-slightly-off the current flow lines, for instance)?  I'm struggling to envision how i'd use this feature if it were added, TBH.

Mike Schmitt said:

To clarify on my understanding somewhat, though, what exactly would you hope the new behavior to be, and what would this accomplish / allow you to accomplish that you're currently prevented from doing (or by dropping nodes just-slightly-off the current flow lines, for instance)?  I'm struggling to envision how i'd use this feature if it were added, TBH.

The more I think on this, the less of a big deal it seems.  It has been just a few times I've been bit by not noticing an accidentally-connected node, which became much easier to debug on the second round .  With the improvements to Appian over the years, we are able to make much more efficient (less nodes) processes, where the older, bigger models have been where I've run into this.

The initial thought however would be to have an option similar to changing connector styles, with auto-connect defaulted to On, and the ability to turn Off, but I don't think I would prioritize this over anything else mentioned in the thread so far.

Novel thought though - how about giving us the ability to change the style of already-placed flow lines? 

For example/fun, working in an older PM such as below.  Can't touch any of these nodes without causing a headache! 

I'm so sorry you did this to yourself (assuming from past conversation, and how long I've been developing too, that this is what happened).

100% agree about Terminate.  Absolutely true.  I remembered there was a lot of stuff that I switch from default behavior absolutely EVERY TIME except once; somehow forgot about Terminate. 

General idea is the default be what I change it to normally now, then I only go through effort once, instead of every time but once.  Appian, just consult with folks doing Solutions, and see what they always click to change, and default it to what they change it to every time.

What other data would you like included in the expression editor? If you do mouseover the variables we show the data type as well as the inline documentation. 

I can't speak for all of these but when we re-added the expression editor in 22.4, we did add back the ability to mouse-over for data types + inline documentation (if available). 

1. The process model icon palette (to help developers know when they are selecting an OOTB smart service
2. Adding it to the Node dialog box (to help developers who are troubleshooting a process model)

In the legacy expression box, it would show the data type of individual CDT fields upon mouseover (i'm pretty sure, at least.  i don't have access to a legacy instance to check this.  Chris?)

I can't remember whether it showed the array/singular setting on the PV, but it really should show that too (at least how it works in the Expression Rule editor, see below screenshot).

In the legacy expression box, it would show the data type of individual CDT fields upon mouseover (i'm pretty sure, at least.  i don't have access to a legacy instance to check this.  Chris?)

I can't remember whether it showed the array/singular setting on the PV, but it really should show that too (at least how it works in the Expression Rule editor, see below screenshot).

Mike Schmitt said:

In the legacy expression box, it would show the data type of individual CDT fields upon mouseover (i'm pretty sure, at least.  i don't have access to a legacy instance to check this.  Chris?)

Yep, in my 21.1 instance expression editors it does show both the type, and indicates a list on hover-over, for regular PVs and CDT elements:

Would you be able to add a screenshot also showing the mouseover for a CDT property, for additional reference?

Sure thing.  CDT itself:

CDT element:

Thanks Chris, this is about what I remembered.  I guess an important distinction is that the data was shown in a mouseover "hover text", whereas now the detail is shown in the dialog info panel (which i'm fine with, and is probably for the better).  Sam Wahbeh does this clarify the distinction I was making, with respect to the behavior of the new version and the detail I feel is lacking?