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?

Just some quick work they could do on default behaviors:

1.  Make Alerts default to sending only to the administrators of THAT process model.  There may be some folks for which that is OK, and some that still want to change default, but nobody wants Alerts to go to every last developer on the environment.

2.  Make "Save Draft" on User Input nodes default to unchecked instead of check.  The amount of effort across all Appian developers to repeatedly uncheck the same box for every interface made dwarfs the effort  to check the box when they want to use that feature.

Also, some really nice features would be if the lines didn't have to overlap as hard as possible, which gets especially annoying when only 1 of several overlapping lines doesn't have an activity chain, and you need to find it.  Also, on debug, it would be super awesome to have some visual cue for how many times a process flow flowed over the same line.

Also, restart gateways.

Dave Lewis said:

nobody wants Alerts to go to every last developer on the environment.

Or that one VP who insists on having an Admin account in TEST that he never touches anyway, but still gets all alert emails for...

And, thanks - i captured these (with attribution) in my running text document that I finally decided to start the other day.  Part of me thinks this would make a good Google Doc (or maybe spreadsheet), though that seems like a lot of work.

Mike Schmitt said:

Or that one VP who insists on having an Admin account in TEST that he never touches anyway, but still gets all alert emails for...

This is where I say "Oh do you still want that admin acct now?!"  

I do think the alerts going to all admins can be good for a small team, we have 4.5 developers for an environment with ~70 applications and ~75k processes active at any time, we all share the burden of alerts to help with staff coverage, training, etc.

I think this could easily fit into Dave's suggested reconfiguration though - all our process models have one of a few high-level Appian Admin groups added as the Process Administrator, so your use case (assuming some similar proper setup is already in place) might be as simple as making sure all developers belong to those groups, or whatever subset of those groups that are relevant to them.

Dave Lewis said:

Also, restart gateways.

Not only that, but right click and see the instances that have been fired off and at what times (like with any other style of node).  Similar with timer nodes (and an expanded ability to trigger the next instance, or force the next triggered instance to skip, etc).  These seem so incomplete in the current implementation, enough to make me think the engineers in charge of updating PM functionality have never really had to do O&M work on active production systems with large, unruly, and often old-and-buggy process models.

Dave Lewis said:

Also, restart gateways.

Not only that, but right click and see the instances that have been fired off and at what times (like with any other style of node).  Similar with timer nodes (and an expanded ability to trigger the next instance, or force the next triggered instance to skip, etc).  These seem so incomplete in the current implementation, enough to make me think the engineers in charge of updating PM functionality have never really had to do O&M work on active production systems with large, unruly, and often old-and-buggy process models.

Mike Schmitt said:

Not only that, but right click and see the instances that have been fired off and at what times (like with any other style of node).  Similar with timer nodes (and an expanded ability to trigger the next instance, or force the next triggered instance to skip, etc).  These seem so incomplete in the current implementation, enough to make me think the engineers in charge of updating PM functionality have never really had to do O&M work on active production systems with large, unruly, and often old-and-buggy process models.

Speaking of restarts, one addition would be able to restart a User Input Task at the Output phase, where the user has completed the task and an output has failed.  The issue I run into here is, say when a output expression calls a DB that is offline temporarily, you have to restart the entire node (and explain to the user to complete their task again), causing a business disruption, instead of continuing per say, the completion of the node.

Otherwise for clean processing, we are forced to move any potentially sensitive integrations to a following Script Task, eating up another node, as to restart them seamlessly to the user.

Something like 2 rows here, for UITs, "Start at Input" and "Start at Output".

That's admittedly a more complex thing to develop (at least I assume, having no idea what the back-end code would look like to handle that stuff), but as an O&M administrator (among my many other hats), I like it.

I assume we'd be acting under the presumption that this option would only ever show up after the node had (attempted to) complete once?  There's a bit of a "can of worms" effect there too for, like, MNI instances, etc.  But still worth having for the simpler use case, I figure.