Day 278: Improving Browserflow's Editing Experience

product

I’m thinking of swallowing the “just make the product dope” pill and focusing on improving the editing experience in Browserflow. Because there’s a lot that can be improved.

Current Editing Experience

Browserflow supports two ways of creating/editing a flow:

  • Recording mode
  • Manual mode

Recording Mode

In recording mode, Browserflow detects the actions you perform in the browser and adds them to the flow:

It’s easy and straightforward. You just do what you’d normally do, and Browserflow records it all.

The downside, however, is that the set of actions you can record is limited to simple interactions like clicking, typing, creating tabs, etc. If you want to say, get the text of all the items in a list, you’d need to go into manual mode.

Manual Mode

In manual mode, you’re basically programming. You have your editor on the left side and the browser on the right side, and you switch back and forth to tell Browserflow what you want it to do:

For people who don’t know how to code, the process above seems like it’d be intimidating and confusing. Simplifying the editing experience would benefit all users, including programmers.

How can it be improved?

The Challenges

Single Context

The nice thing about recording mode is that there’s only a single context. Meaning, you don’t need to go back and forth between Browserflow and the browser — you can edit the flow entirely within the site that you’re on.

Is there a way to support doing much more inside Recording Mode to keep the single context?

Currently, manual mode has a “verb-target” design. You click on the + button, you select a verb (indicate what command you’d like to perform), and then you select a target (indicate what element that command should be performed on).

Option 1: Add “+” button on page

If I wanted to keep the editing experience within the browser, I can add add a floating + button on the page directly (e.g. in the top right corner) that shows the list of commands you can perform.

A downside of that approach, however, is that the process of recording a command differs based on the kind of action it is. To add a Click or a Type Text action, you simply perform them on the page. To add a Loop Elements action, you click on the + button first. This adds cognitive load on the user because they need to remember which commands they can just perform and which ones they have to use the + button for. But since all commands are available with the + button, perhaps it wouldn’t be too problematic in practice. I’d need to build it and test it out to know.

Option 2: Target-verb design

An alternative is to switch the “verb-target” design into a “target-verb” design. Instead of requiring the user to specify the command they want to perform before selecting the element, they’d be able to select the element first and then select the command.

Then, if they were to click on a link, a menu would pop up asking them to indicate whether they want to click the link, get the text of the link, get the URL of the link, etc. This provides a uniform way to add any command that concerns an element: Simply click on the element you care about and tell Browserflow what you want to do with it.

A downside of this approach would be that there would be an extra step involved for the commands that are automatically recorded before: Clicking on an element would now require the step of indicating that you want to click on the element (since there would be other things you might want to do with it).

On the whole, though, the target-verb design feels like it’d provide a much smoother editing experience compared to the verb-target design.

Variable Management

Another major challenge with the current editing experience is the need to manually manage variables. I previously wrote about how Shortcuts elegantly solves this problem with their Magic Variables: Day 265: The Magic of Shortcuts

What can I learn from their design?

Automatic Variable Generation

While Shortcut’s practice of automatically generating variables can make editing quite convenient in many cases, I’ve found that it acts as a hindrance in more complex workflows. When I have multiple variables of the same kind being used, I need to go back and rename them because it’s difficult to tell which variable is which. If I decide to adopt this design, it’ll probably be for a limited set of commands.

Autofill from Previous Command

Shortcuts automatically infers the target of the command from the previous command, and this seems worth adopting in the future for added convenience.

Descriptions as Variables

The design that I’m most excited to adopt is to replace variables with descriptions. I think this would make it much less intimidating for users — after selecting an element, they can name it something like “Story Title” rather than $storyTitle. Then I can add autocomplete support everywhere so that if they type “S” when specifying text to type, “Story Title” could pop up as a potential option.

The challenge here would be that creating variables from the Run Script command would require some way to indicate to Browserflow that this is a Browserflow variable. Currently, putting const $meow = 'sup' would automatically create a $meow variable. In order to allow variables to be more like descriptions, I’d have to use a different mechanism like const $['Text To Save'] = 'sup' or something similar to allow for variables with spaces. Or I can also just let manually created variables follow normal variable naming conventions since users who are creating variables are likely programmers.

Improved Editing Experience

What I imagine for creating/editing a flow:

  1. User selects where in the flow they’d like to start recording

    • The standard way to add commands would be to record rather than to add manually

  2. User clicks on an element they’d like to interact with

  3. User gives the element a description if it doesn’t have one

    • This description is then used as a variable to refer to the element in subsequent commands

  4. User chooses the command to perform on that element

  5. User repeats steps 2 - 4 until they’re finished with their flow

Additional Notes and Open Questions

  • Moving everything to recording mode would be beneficial for certain commands like Click where the user might forget to select “Wait for page to load” if they were adding it manually

  • How should I treat commands that don’t involve an element (e.g. Show Notification)?. Should the user have to switch back to the popup editor to add that manually or should I add a floating “+” button in the screen?

  • Creating a variable/descriptoin for each element will make refactoring/updating flows a lot easier when the same element is used with multiple commands

    • Currently, each selector reference is independent of the others so you need to modify each one separately
    • In order to avoid having “Define Element” or similar commands everywhere throughout the flow, it might be worth having a top-level command (or even a separate section in flow settings) for defining all elements (associating selector to description)

  • Are there commands that don’t work well with the target-verb approach? e.g. drag-and-drop? Drawing on a canvas?