• androng 7 minutes ago

    Hello, I will be using your app soon. I was looking for something playwright related for the website I am making. I am so glad that the price is not "contact us".

    I noticed in your video that Donobu does not move the mouse to the search box before typing in it. I hope this does not trigger captchas or anti-bot protection--I was thinking of adding "Firebase App check" to my website since Firebase recommends it to everyone and it uses "Recaptcha Enterprise". not sure if this will turn my website into an "adverserial website".

    I think Donobu would also be a lot more helpful on mobile since there are more phones than desktops in general. I was looking for some kind of automated mobile testing and found none. quickest way I can think of to add that is using the new iOS 18 with desktop control of the phone.

    I think you could "easily" translate this to arbitrary desktop control test software. or make some other agent software that does. if you don't someone else will https://youtube.com/clip/UgkxcFMelp1K31l7pH0Sbghb4sJ-eF0O8-x... If you made the desktop control software, I think you would get mobile control software for free.

    • pavlov 4 hours ago

      Such a nice, simple landing page. I could immediately understand and appreciate what this app does by first looking at the picture where the flow is defined, then seeing the flow executed on video.

      It's like the old Apple commercial: "There is no step three."

      Congratulations on the launch!

      • asabla an hour ago

        This looks really interesting and could really be a nice addition to my daily work.

        I just downloaded the application, but are unable add OpenAI API keys. Looks like it's probably on my end (with quite an aggressive DNS blocking lists). So my guess here is: I'm unable to add API keys when telemetry is blocked.

        Suggestion: please do add some error message when then this occurs. As in, did the request fail (500), faulty key etc

        • wewtyflakes an hour ago

          Thank you for the direct actionable feedback, we will improve that messaging.

          Regarding debugging your specific problem, when an API is attempted to be added, the local process attempts a 1-token request to the cheapest model with the GPT platform (in your case, gpt-4o-mini on OpenAI) to verify that the key works. Though, if the account has no balance, this request may fail even though it costs a fraction of a fraction of a penny (though anything that fails that request will cause the API key to be considered invalid).

        • sahmeepee 3 hours ago

          Playwright (and axe) is a good option, but how do I have confidence it's performing the test correctly and repeatably? If the test seems flaky how do I know it's the software and not randomness of the AI part? I want tests to be predictable.

          • wewtyflakes 3 hours ago

            For running the axe test itself, once the agent has decided to run it, is a dedicated tool to run an off-the-shelf axe script. The axe script itself does not change from run to run, so assuming you are running the test on the same page, you should get the same result.

            • sahmeepee 2 hours ago

              The axe element will be the same each time, but you can do that without any AI shenanigans - just run it in a normal Playwright test.

              My question was really about the page interactions and the assertions being driven by AI: if they are going to be generating different code every time the test runs, how can you have any confidence in the test not having false positives and false negatives at least some of the time, unless you read the generated script each time?

              That sounds like a lot more work than just writing the test once in the traditional way (codegen or manually) and tweaking it only when there's a breaking change to the page.

              If people are genuinely using this approach then there must be something I'm missing.

              • wewtyflakes 2 hours ago

                We are going to be adding the ability to trigger more actions (beyond the normal clicks/keyboard) without AI by using the in-browser control panel. We wanted to add it for this ShowHN, but we ran out of time on our self-imposed deadline. :(

                Regarding variability of flows, you can cement a given flow by pressing the `rerun` button. That takes AI out of the driver's seat and the flow will rerun the set of actions decided on in the original flow as if it's on rails.

                Regarding creating a test manually, that will be a best fit for pages that have consistent selector logic for elements, though we found that as soon as a page starts randomizing element IDs, this approach starts to struggle. We get around this by creating a prioritized list of selectors for every action that touches the DOM, so that if `document.querySelector("#shenanigansId")` fails, the run can still continue by choosing the next-best selector, and so on. Thankfully this logic requires no AI at all, though it is heuristic at the end of the day.

          • bkyan 3 hours ago

            Is there anything in the tech stack that make this app specific to Macs, or are you simply rolling this out to Macs, first?

            • wewtyflakes 2 hours ago

              We're rolling out to Macs first since that is what our development environment has been, though nothing is stopping us from supporting Linux or Windows once we have those environments properly set up. It is on the near-term road map!

            • rexreed 4 hours ago

              Interesting! How far away is this tool from being a desktop simple RPA solution? Would it be able to interact with desktop apps and simulate mouse or keyboard actions in the future?

              • wewtyflakes 3 hours ago

                Right now we are constrained to using the DOM of webpages. This is because we need some reasonable way to detect what parts of a UI are interactable or not (though we do some magic to do this); this would be a bigger challenge for arbitrary desktop apps. Also, there would be new security aspects that would have to be meticulously considered if we were to allow an agent to control arbitrary desktop apps. Constraining the agent to the browser has nice alignment in this way.

              • mattfrommars 2 hours ago

                Just to be clear, did you really decide to use Java to build a desktop application for Mac? I see you mentioned Java 21 as main business logic layer, which technology did you use to build the desktop application?

                • wewtyflakes 2 hours ago

                  We really did! :) Though, there were some unfun challenges around that, like getting distribution to work without having to get people to go through the pains of installing the JDK. Thankfully, since our UI is just a web browser, we did not have to go down the path of JavaFX or anything like that; our UI is just plain JS/HTML making API requests to a propped up server on localhost:31000 (for the curious).