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
Go Appian!
Very intesting - it appears as if they snuck in an update to this just this past weekend. It's funny since I didn't get any maintenance downtime notices...
Edit: from the Hotfix release notes, I assume this is the item referenced in AN-218956.
I dunno, it seems to me as if they could've at least made the existing icons scale properly in the middle of the new-style icon with dark blue rectangular border, to match the other ones. I'm not sure what (if any) design process was involved here.
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.
I give that a pass. Plenty of other things to develop first so I can at least stop looking at bad icons faster.
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).
Updating this to add (instead of cluttering community with another top-level post, though in this case i'm *sorely* tempted) - the 22.4 update's new Process Modeler nodes completely ruin the look of icons from Plug-in Smart Services. How did this pass testing?
Before:
Now:(note how bad the bottom-row node icons look...)
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).
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.
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".