Merge Get *Text activities

Feedback Activities
, ,
1

For various historical reasons, there are 3 separate activities for getting text:
Get Text
Get Fulltext
Get Visible Text
(there’s also Get OCR Text but that’s a different matter)

Current implementation has a few problems:

  • can be confusing as to which one should be used and for what. documentation would also help.
  • hard to swap them around to see which works best for your situation
  • names are opaque, they don’t give enough information as to what they do
  • the mechanics of changing a method is very different from their sister activities, Click&Type. If possible we should use the same mechanics/logic.
  • The 3 actions/activities have 6 names referring to them in UIPath Studio:
    get Text
    get value
    copy
    copy text
    get Full Text
    get Visible Text
    Native (in the scraping wiz)

Solution

Merge the 3 into one activity called Get Text, with a property called Method (dropdown) with the 3 options.
The 3 current activities are already very similar: the properties of the 3 are almost identical, with at most 2 differences between any 2 activities; out of ~11 properties each. Merge these into the properties pane and activate/deactivate when the Method property changes.

Naming for the 3 options is up for discussion, but they should be informative & useful. Focused on the differences between them, or on a specific characteristics of a method. Maybe something like this:
* Item
* Blocktext background
* Blocktext detailed

1 Like
2

Hi Cosin,

Could you elaborate a little which 3 activities are on the table for merging and how would they map to the new namings?

I’m also a little bit worried that this would be a braking change - how do you plan to handle backwards compatibility in this case?

Regards.

3

Sorry about that, I edited the post to add the 3 actions I was talking about: Get Text, Get Fulltext, Get Visible Text.

Theoretically backwards compatibility is possible. When opening a project built in a previous version, all 3 actions would appear as a single activity Get Text with an extra property Method, with 3 choices:
Item
Blocktext background
Blocktext detailed

The options corresponding to the activity it replaced.

If this sort of “background convertion” is not possible, you’d have to manually replace them.

4

Thanks for clearing that up, now I see where this is coming from.

Putting compatibility aside for a second, I’d agree that maybe merging Get Visible Text and Get Full Text could be a worthful simplification (they’re in the end very similar in use and switching between the 2 would be easier), but from my experience they serve a different purpose than Get Text.

So far there were 3 types of scenarios where I wanted to get text from somewhere:

  • I know the exact element or a direct selector → Get Text
  • I know the element roughly but it could have f.e. additional nesting or other structure variants → Get Visible/Get Fulltext (depending on what tests show, usually Get Fulltext, as I fnd it faster and more reliable, unless I need WordsInfo)
  • I can’t access the element → OCR based activities

Not once (so far) I’ve had a situation where I wasn’t sure if I should use Get Text or Get Visible/Fulltext, primarily because Get Text is under Control, while others are Screen Scraping (so implicitly they’ll need parsing).
That’s a pretty big distinction in my perspective, as it needs a different workflow design. ScreenScraping based data reads, even if not OCR based, should be IMHO handled almost the same as OCR (minus character accuracy checks). Being able to easily switch between scraping and direct read may be detrimental to design pipeline, as it’s very easy to get completely different data changing one parameter, introducing more confusion than it would solve.

(of course, that’s just my opinion)

Now for the compatibility:

“Theoretically backwards compatibility is possible” is not reassuring. If I can break a workflow permanently by just opening and saving it in a different version, is a huge risk. In essence it would mean that we’d need to have a forced workflow upgrade that’s very easy to mess up - if I open in the new version, to update properly, I will see different activities, so the only way to do it is to have it open on 2 machines at once.
From what you wrote, there will be no in-place xaml update, so I’d see default Method in all of them? If not, how would it choose which one to set?

This is scary.

And this is for essentially ALL workflows (I can’t think of anything that is not a small test that doesn’t use Get * Text, unless it’s completely OCR based).

Please take a closer look at the backwards compatibility. It is 100% essential to any longterm projects.

As a quick idea even a new, separate activity would be better. Give a grace period when there are both, then remove the old ones (or move them to a compatibility package, like with V7 activities), similar to what code API’s do with Deprecated and Obsolete attributes. This would solve the compatibility and also allow for a much smoother upgrade process.

Aside of that, proposed naming seems ambigious to me a little. I can’t discern at first glance the actual differences between Blocktext background and detailed. It might be just a change resistance at this part, so take it with a grain of salt, but Get Visible Text I think was a really descriptive name. Fulltext might need a rename, but that one was great.

And I’d personally leave Get Text out of the merger. While it may be similar from parameters, it’s purpose is I think different than the other two.

Regards.

2 Likes
5

Thanks for your input. Every simplification helps, so even merging 2 out of 3 actions, like you said, would still help, and the usage would be clearer.

In the “automatic update” situation there would be no breaking, you’d open the workflow and all Get * Text actions (getText, getFulltext & getVisibleText) would be replaced in-place with the new GetText action, with it’s Method parameter set to the method it replaced.

If for whatever reason that is not possible, then it would be a breaking change, in which case it would be handled very differently.