The "modern" activities don't make sense

The new modern activities often don’t make sense. First off, the Use App/Browser makes it more difficult - instead of easier - to use variables to reference the object. Variable use is best practice, not re-grabbing the object with selectors every time.

Another example is the Click activity. If it has its own properties to store selectors, why must it be inside a Use Application/Browser scope? Why can’t we use it standalone like the old Click activity? I’m seeing this a lot of places, now, where things have been made more complicated not simpler.

When I use a Click activity inside a Use App/Browser scope, the Click activity still gets its own window selector. Why? It should be using the scope. So every time I add a Click activity I have to remember to fix the selector or delete it, when the selector shouldn’t be filled in at all.

Then I try to use Click as an image click, but the easy way to specify an offset (with the recorder) is gone. The old Click Image activity was better than the new combined Click activity.

It is starting to feel like when you’re deciding on these kind of changes you don’t get feedback from people like me who do this all day every day. This has always been a huge problem in the software industry - product managers and programmers who don’t actually know the experience of their users.


Hi Paul.

  1. How so? You have input and output properties to reference windows/apps.
  1. What do you mean? How are you fixing the selector, what’s wrong with it?
  1. You can configure the offset however you want, during recording too, without extra steps/clicks. You can even set the anchor point on the fly. Have a look
    What functionality are you missing?

And when you use them, it still populates the selectors, making it unclear what is being done.

Say I have a web page open where the title includes the username, so I take out the username and use a wildcard. This I do in the Use App/Browser selector. Then when I put a Click into the Use App/Browser and select what to click, it doesn’t know (like the old way) that it’s inside a browser scope, so the Click activity ends up with its own selectors that I have to manually remove or edit.

Yes I know this now. But it’s not intuitive. The wizard style of the old recorder makes it intuitive.

One big one is the ability (like the old recorder) to select which thing I want to do. The new modern stuff tries to be too smart. Sure it works most of the time, but for situations where it doesn’t, it’s much more tedious to code.

  1. It populates the selector if you indicate, because that’s what Indicate is supposed to do. If you don’t indicate, and use just the input/output elements, they remain empty.

  2. Ah yes, I see what you mean, and you’re a bit right and a bit wrong. Yes they’re there and granted, it might suggest that you need to edit them, but feel free to leave them as they are and 99.9% of the time it will work fine :smiley: But noted, we’ll think about how to suggest that you generally don’t need to edit them.

  3. I disagree, and research disagrees too. Try it out for yourself: take somebody that has never seen Studio before, and ask them to do an offset click with Modern, and then Classic. You’ll see the difference.

  4. You can in the Modern recorder too. Hover over any unselected element during a recording, and then hover the little (+) sign. Then pick the desired action:

Why does it populate the window selector when it’s inside a browser/app scope? A Click activity that’s inside a browser/app scope shouldn’t need nor have a window selector.

That doesn’t feel clean to me, to just leave them. It would be nice to know how they’re handled, so I can make sure all my code is correct. Is the window selector simply ignored for activities inside a scope? Can I clear that property?

I’ve seen Studio before. So this change negatively impacted me.

I guess what I’m saying is I prefer things to be more manual where the recorders are concerned, and to have specific tools for specific tasks, not one tool that tries to do it all. This is the perspective of a seasoned user, not a new user. Maybe this new combined recorder would have been better suited for StudioX and not regular Studio?

By the way, I love the new selector window with selector, fuzzy, and image, the way it designates anchors too - that’s all fantastic. It’s the properties of the activities where it has become complicated, specifically how the properties of nested activities now interact with each other.

Noted, will do.

Yup, makes sense, sometimes objective improvements will negatively impact existing habits, but they have to be improved otherwise they will negatively impact everyone.

But you do have specific tools for specific tasks, that menu allows you to (optionally) pick the exact action you want to make. But maybe I’m missing something; is there a specific scenario you want to perform that you can’t do (better/easier) with the new recorder, but was possible with the old one?

I think the modern UI activities make sense when you use them in combination with the Object Repository, otherwise I still prefer the old set of activities too.

Especially the requirement for every activity to be in a Use App/Browser scope is annoying, like postwick already mentioned.

The ability to choose which set of activites to use makes all of this a non-issue for me. I just hope the old set of UI activities won’t be discontinued any time soon :face_with_monocle:

@lukasziebold, besides the requirement of a Use app/browser, what else makes you prefer the Classic ones?

There is no plan to discontinue the old ones, you can actually even mix Classic & Modern ones in a modern project.

I would like to add that there are some things I really, really like about the modern design interface and activities.

The new tool for generating selectors, combining the selectors with image recognition, click to designate anchors, this all works so well. I also just found out how it will actually parse an argument in real time when you’re doing {{argname}} in the selector, to allow it to validate properly.

The Open, Close, Maximize, etc options being baked right into the Use App/Browser activity is fantastic.

Check App State is very well done. It really makes the logic easier than “element exists + if/then”. Being able to toggle the branches is icing on the cake. (I’d really like to be able to toggle branches for the If activity, too)

For the more basic activities (type into, click, etc), I really like how the important options are right there in the activity, without using the Properties pane. Little things like combining Type and Type Secure into one activity are really nice for the overall coding experience.

1 Like

Hey Cosin, a good question I didn’t actively think about yet.

The more I do, the more I realize it all comes down to simplicity and familiarity. There are so many more options in the modern UI activities (which are really well done for advanced UI automation) that the classic activities just feel less complicated.

Also the teams I am working with are not very familiar with modern UI automation and adoption (or even knowledge) of the Object Repository is very rare! As a developer it is easier to work with the tools my collaborators already know. You probably know how slow enterprises can be, kind of hard to keep up with UiPath’s pace of innovation :rocket:

That said I am looking forward to elevate my and my teams’ UI automation game to the next level with modern activities and Object Repository etc.

1 Like

I see, makes sense. If you have any specific issues that you noticed more developers run into, pls let us know. By issues meaning not only bugs or things that they can’t do, but also things that are unclear or unexpected

1 Like

Hi UiPathers!

Since I’m new to the Studio, a started to check all possibilities with Modern design first. As @postwick said in the quote, I still can not figure out the use of a Window selector in the modern Click Activity when it is nested inside the Use Browser/Application activity.

I correct the selector with “*” in my application (Use Browser/Application), and deleted Window selector string from the modern Click activity just to check which Win selector is being used - one from “Use B/A” or from nested Click activity

When I run the project, Click activity can not be executed even it is nested inside the Use B/A activity. The error I get is: GetWindowSelectorTags not implemented for tag ‘webctrl’

My question is, similar to Paul’s one…does the Click Activity (and other nested ones) must use it’s own Win Selector?

I would appreciate the answer…

Many thanks,

Since we work most of the time on a test environment when we create the automation, the window selectors won’t work on the production environment. SImple reason, the window selector has a different title in test environment or even app name. So we need to change every window selector.
With modern, it implies a lot of additionnal work. Even anchors and verifiy part of click/type activities have their own window selector that we need to adapt → this means 3 Window selector to adapt. It is just too much and for maintenance the same.
Creating object repository doesn’t help much either, since the issue with the window selector is the same.

→ Proposition: by default (or changeable in Project settings) the window selector is taken from the use application (like for attach window). If the developer needs to define a specific window selector, he can.

What do you think?

Oh and fuzzy selectors are not acceptable a lot of times because of the way the target apps are developed. One field can have a very similar selector to another (just 1-2 characters different)


Can we get some clarification on how Window Selectors work? What’s the point of the Use Application/Browser activity being required if, for example, a Click still needs its own Window Selector?

1 Like