First let me start this off with some good news. The left-hand object bar has been further tweaked and reorganized. I previously commented that "process model / interface search results" being at the top of the list (as they are in 22.3 and lower) makes it harder to access the Smart Service Nodes we're after when that's what we're actually searching for. It looks like they listened! Yay!
But for the main point of this post: i've noticed that Grid Lines are now turned off by default and there is no way to undo this except by turning them on manually every single time you load a process model.
At first I was hoping this was a bug in my Community Edition instance, or some incomplete feature or temporary break. But other users are now posting screenshots from 22.4 versions around community and it seems like it may have been "intentional".
Hey Appian folks? This may have been intended to "look cleaner" or something - but to me, psychologically, it makes me think something hasn't loaded correctly. As far as I know, with as long as I've been looking at process models with grid lines, I anticipate this effect will last a long time.
I see they're still there. They're redesigned but I guess I don't have any major qualms with the newer, simplified grid lines (i'll paste an example below for everyone's reference). Can we just have them turned back on by default? Could it at least be given as an override in designer user-level preferences or something?
I know the product backlog is huge, lots of higher-priority stuff, etc. But I think this is something that wasn't necessary to change.
Discussion posts and replies are publicly visible
Chris said:Default End Nodes to Terminate
That's one I've mentioned myself in the past, somewhere around here. Not sure why I didn't think to include it in my list above.
Chris said:the auto-connect which occurs when dropping a node on a flow line
I dunno there. I use that one a *lot*, personally. There's nothing quite as satisfying as connecting (and chaining) a start and end node, then laying out a skeleton-process of other nodes between them and not having to re-draw the connection lines every.single.time.
I do think it could be tweaked and, perhaps, give us a hotkey to temporarily disable it or something. Though IMHO if it's causing you constant issues with tightly packed processes or multiple overlapping flow lines, that indicates maybe a misdesign in the way your flow lines are currently setup. I'm constantly cleaning up old nightmare-fuel process models where you can't trace any flows since they *all overlap*... but that's on those original devs.
Chris said:Differentiate Smart Services in the left panel by Plugin or Appian/OOTB.
And, identify what plug-in something is FROM, at least maybe on the node configuration screen. The fact that this is (still) so opaque is really unbelievable.
Mike Schmitt said:I dunno there. I use that one a *lot*, personally. There's nothing quite as satisfying as connecting (and chaining) a start and end node, then laying out a skeleton-process of other nodes between them and not having to re-draw the connection lines every.single.time. I do think it could be tweaked and, perhaps, give us a hotkey to temporarily disable it or something. Though IMHO if it's causing you constant issues with tightly packed processes or multiple overlapping flow lines, that indicates maybe a misdesign in the way your flow lines are currently setup. I'm constantly cleaning up old nightmare-fuel process models where you can't trace any flows since they *all overlap*... but that's on those original devs.
I can see how this could could go either way, maybe a checkbox/control to turn auto-connect on/off. I guess most of my work since this became a feature has been in enhancing older processes, vs creating new.
..and in many cases, the developer is Old Chris which built a massive process in 2012 with what features were available at the time . Ones you show to newer developers, and they say things like "Sweet heavens!!"
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!
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.
Paging Sam Wahbeh in case that might help get some eyes from Appian on this thread (Thanks again for your feedback on my older thread for the Global Search behavior regression introduced in 22.3, btw).