Input methods selection (simulate, send window messages) for Click & Type activities

Default, Simulate type, Window Messages

Problem: behind these 3 methods there are a few very important features that might or might not be available to you, depending on your chosen method.
Things like background operation, hotkey support, and speed, being the most important features that are directly affected by this choice. That connection is totally hidden to the user.

The problem is compounded by the choice of controls: 2 checkboxes for choosing between 3 options.
A dropdown list is the prefered option for choosing 1/3 options.



In an ideal world the 3 choices and their implications should be obvious to an untrained user. We can start by giving them more descriptive names. Unfortunately, not the easiest task.

Here is a list of properties/implications for the 3 input methods:

One option could be something like this:
• Simulate human - this is the default method because it’s the only one that is 100% compatible. It works by simulating a human operating the mouse and keyboard so it can do everything a human can.
• Background Compatibility - because this one works in background and is slightly more compatible than the next one
• Background Turbo - theoretically this is the fastest of the 3. Technically, depending on the UI architecture, the speed of diff methods can vary. But I think we can choose one of these last 2 as the one that’s generally fastest.

These 3 might not be the best options, so feel free to pitch in with other suggestive names for the 3 methods.

1 Like

I would go with the old naming:

  • Hardware
  • Window Messages
  • API

I agree with Mihai.

While “descriptive” names are good, they tend to hide the implications. Sure, it needs to be understandable, but if the names of the functionalities correspond too close to 1:1 normal language, the underlying functionality never gets checked. I don’t see a better way to name things than based on what it actually does, not what it looks to be doing.

Your software is aimed at a wide range of people, but in the end this is software development so some technical terms are expected. “Dumbing down” (for a lack of a better term) tends to isolate people that actually can make awesome things with it (see Win10 reactions to “Something went wrong!” error messages, change in start menu from 7->8 etc.).

Functionality matrix looks nice though and I think would make for a very smooth learning curve on this. Just glancing over it gives more information than any name will.


Just to add a point here.

We have both type of users (Technical as well as Functional). For Technical folks it will be easier to take out a meaning of the names however for functional people it will be quite tough.

I would go with a Descriptive name(Can be different from mentioned above) rather than conventional names.


That’s certainly correct and I’m not disputing it.

If a user, no matter Technical or Functional, can’t comprehend the above table or can’t be bothered to look it up, he will fail with making a working workflow in other ways. It’s not like it is required to know exactly how WindowMessages or the API method works, just the basic differences between them are needed.
And if it’s too much to handle, I can’t see how that person would be able to handle variable types, selectors, db’s etc. There’s only so much you can do with a recorder (no matter how great it is, and you have pretty good ones!) until you need to make something manually.

What I’d like to avoid is “protecting” users from their own lack of knowledge, or making them think they know how something works while they don’t. Although it may work short term, at least from my experience, it always backfires in the long run. Even for people you’d expect should know better (see Expert Beginner).

I’d really like to see UiPath avoid mistakes I’ve seen with other software that markets on the premises of being “easy to use, no prior experience required”, with the catch being “… as long as you do only basic stuff, otherwise you actually need to study things”. I think it leads to hiding the actual workings, increasing abstraction levels and obfuscations that make actual, advanced work nigh impossible because you need to untangle everything to get the exact effect you need (without breaking licenses, so no de/recompiling like you can do with most SDK’s).

Whatever naming will be decided, it IMHO boils down to documenting it properly and making the documentation readily available from within the tool (even a link is enough). If I need to fire up a browser and google with correct phrases to see how your activities work, no matter how good or bad the naming is, there’s an issue. And since workflow-foundation topics are almost non-existent across the web, it’s better to not need to search by yourself.

// Sorry for a long post, hopefully the gist of it is understandable



The purpose of renaming these 3 methods is to better describe what they do, and all their underlying implications to the normal UIPath user (which is, with coding skills, but not necessarily UI automation experience).
I’m afraid that giving no information about what the options do or what’s the difference between them does not encourage research into underlying functionality, it encourages frustration.

But your point is definitely noted, and about that, maybe you can tell me a bit more.
When you first encountered these options, did you feel their current names (Window msgs, Simulate) were clear to you? as to what they do, and when you should use them?

If a user, no matter Technical or Functional, can’t comprehend the above table or can’t be bothered to look it up he will fail with making a working workflow in other ways

Yes, but the fact that you need to fire up a browser and lookup a table using appropriate keywords is a huge drawback, no matter the application, experience, or type of user.
Ideally, all these 3 options should not exist, and you should not have to deal with them. But since that’s not possible, we do want to make it as easy for you as possible.


As a preface - before starting with UiPath, I had very little experience with UI automation.
And a disclaimer - I’m “arguing” only because I want this software to succeed, because I really like what is possible with it :slight_smile:

Actually when I started it was Hardware, WindowMessages and API (with API being the default I think back then?). I still sometimes call them like this, because those names are all different from each other - there is no room for inprecision (“I used background method. Which one?”).

The names were decent enough and to the point - they described how the text/click will be sent. API indeed I needed to look up on the wiki (since it’s a broad term), but that is what I consider normal learning process for a new framework.
Those names did have exact meaning, I just didn’t know what they meant because I didn’t have the knowledge required to understand them. This didn’t change the fact that the first thought was “It sends the click via WindowMessages or Hardware emulation or an API”.

I’m not saying to not give any information. HardwareEmulation, WindowMessages and API are actual communication methods, even if the user doesn’t recognize them as such or doesn’t know how they work, like I did in the beginning. This encourages learning - it’s an actual term I can research.
I can’t research “Background Compatibility” or “Background Turbo”, these terms don’t exist outside UiPath, and even if they do, those explanations won’t be relevant.
“Simulate human” is a step above that, but it still hides the fact that it’s simulating a hardware driver.

Exactly. When someone with coding experience sees a Click activity and the Method: WindowMessages, it’s clear the click will be sent via WindowMessages. That person might or might not know how those work, but hiding the fact that the actual Method it’s sent with is WindowMessages won’t make him know that either. What it can be used for is what tutorials and docs are for, that’s normal for programmers.

On this we agree I think (hence I said that making it available in the software itself, even via a link, is important), although my wording might’ve been lacking. With every framework you need to lookup the docs at some point. It’s just a matter of how easy it is to find the answer, so again, it boils down to how well will you document everything (and I mean really everything).

Here I really need to say I don’t agree. If the message can be sent in different way, I want to be able to control it. Sure, the software (with the recorder) can provide the defaults etc., but don’t hide the options please. Some applications really need to very weird setups to make them work with the robots (because their UI is essentially “broken”), don’t take that option away.
I’d even argue that the activities don’t expose enough, not the other way around.

In the end, at least personally for me, it doesn’t matter that much how it’s called, as long as the docs for it are accurate, extensive, up to date and are not hiding important stuff that I may need to research further if I encounter an edge case that was not envisioned.

Let’s hope others give opinions too and that the topic doesn’t get dominated :slight_smile:


Forgot to ask:
Similar to the other change topic, how will the compatibility be handled? This is changing the interface for activities, so the same worries as for GetText activities apply here.


Maybe we could show that functional matrix as a tool-tip in UiPath Studio when hovering properties?


Or include it in trainings and manual

Actually we really appreciate your “arguing”. Healthy debate is gold for finding the best solution to a problem.

True, maybe I underestimated the amount of information these provide to some users.

Officially, the most efficient way of understanding something is “progressive disclosure”. Or giving the right information when it’s needed, not sooner not later.

So there are 2 possibilities:


• The first contact with these properties is through their names in the dropdown, we’ll call this Level 1 of information.
Level 2 – tooltips show more info, including their technical names and a few details about how they work.
Level 3 – (contextual help - the little “?” button in the top-right) we’ll show a detailed description, the feature matrix above, & related links.

This way we give the right information when it’s needed, without asking the user to google things. Because like you said, you don’t always need to know all the details.

To me this is the preferred approach to cover both novices and experts alike, I would say equally.

B The other approach is similar but with level 1 & 2 switched

Level 1 – technical names (let’s say Hardware events, Window Msgs, API)
Level 2, tooltips, show info about what they mean and what they do, for less experienced devs
Level 3, contextual help that points to documentation, the same as in option A

So the choice between the two (A/B) comes down to target audience.

We have no intention to :slight_smile:


Backwards compatibility should be ok since it’s just a UI change, technically it works the same way.

1 Like

This discussion was a bit derailed by the naming issue. My bad, should’ve kept them as separate threads.

So how do you guys feel about switching between the 3 input methods with a dropdown, instead of 2 mutually exclusive checkboxes? Same naming as now.


As long as the naming stays the same, I’d say it would be a good change.



Thank you for this valuable information.

Thank you much,
Great functionally table. Finally you made it clear how to use it.

You mean in Modern UIA?

As a new user, the current naming (Hardware Events, Window Messages, Simulate) is somewhat confusing, even after doing the Academy beginner course, as I still sometimes expect “Simulate” to be what actually is Hardware Events (what you proposed initially as “Simulate human”). I understand from this thread that the technical names have significance, while some more descriptiveness would have helped me as a new user. I really enjoy that the current options are available in a drop-down list, by the way.

If a name change becomes relevant again in the future, here’s my proposal:

  • Fast API - refers to its high speed
  • Flexible Window Messages - refers to its good score across properties/implications
  • Robust Hardware Events - refers to its high compatibility

I think the inclusion of Fast, Flexible, Robust would have given me as a novice an idea of how I would experiment between the different input methods. I may have thought “Of course I want my process to be fast”, but upon noticing an error with a specific activity, I might have tried Robust (or Flexible) instead as it implies it should work better than Fast.