The forced DateTime designer in the invoke workflow is not only annoying (as pointed in the linked topic), but also dangerous - you do not want hardcoded values in invoke arguments in general, and especially for something like datetime, and this designer change encourages it (as you have to go “out of your way” to pass a normal variable, like you should).
This is another case where a) it looks like a change for change’s sake, b) the change encourages bad design, c) the “new” way gets in the way.
I’d be really curious to know - did anyone ever ask for this? And even if they did, with a good argument? At best this looks like a “you think you want this, but you don’t” situation, and should’ve been rejected.
Please stop messing with core activities without exploring what your changes mean for users on different levels. This one is just bad for all:
For new users that are just learning it makes it confusing and teaches bad practices (hardcoding arguments)
For mid-level users this is be annoying, and might be confusing
For expert users this is not only annoying, but also puts UiPath in bad light, because we know what ripple effects this can have on beginners that we will later need to deal with
As a side thing, we don’t need more complexity in the designers. Studio is already a resource hog anyway, and these types of small things really add up (and personally, I wouldn’t 100% trust someone who thought this was a good idea to spend time on to handle this in a cpu/memory efficient way…). And all complexity = more code to maintain = more opportunities for bugs.
PS. Before someone replies with “but you can change it to expression…” - yes, you can. But that’s extra clicks (every time) + a newbie will not know that immediately. And it’s more of a general design direction feedback as well.
I agree completely. I complained about this when they first started getting away from “just enter an expression” on all the activity properties. Having to click multiple things to just get to the “advanced” editor is annoying and over time is very time consuming.
I think it mostly comes down to the Ux, some of these changes arent bad in some theory, but the way to access them leads to confusion.
If I may use another example, in many activities now they require an iResource as an input instead of a file path like they used previously.
Except you CAN still use a file path as you can ‘switch’ the input from an iResource to a string, but its a menu option hidden away behind several clicks and its not intuitive so you wouldnt know to do it natively.
Another example of the same thing I have seen trip people up is on the Outlook send mail activity.
Previously in the properties panel you’d specify if the mail was html or plain text, now in the new activities its just a ‘body’ in the activity and I’ve seen people get really stuck as they cannot see how to switch, again, thats hidden away behind a menu button where you press to toggle between the html input and the plain text input.
Its largely part of stopping to show the properties panel for the modern application cards but also just a difficult Ux overall. I think these date time components being put in like this are another symptom of the same problem of having a field ‘mutate’ into different formats, but it not being clear.