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.
Solution
First,
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.
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.
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
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
EDIT:
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.
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:
A
⢠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
Agreed
Backwards compatibility should be ok since itâs just a UI change, technically it works the same way.
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.
mpraveen1902
Palaniyappan
Parvathy
Anil_G
Swathi_Raju
Sara_Piana
Yoichi
Nitya1
ashwin.ashok
Rishita_aggarwal