Dear Confluence DC team,
over the last months I’ve noticed a trend that annoys me in new UIs for Confluence DC. It happens more and more often that new UIs you release have nearly no semantic markup. They look nice but when you look at the DOM, there’s no way to tell what is what.
In the “good old times”, we had CSS classnames and ids and semantic elements like BUTTON
s with type=submit
.
Why is that important? Test automation and automated scripting. We use Playwright for automated E2E testing of our app and we also use Playwright scripts to configure fresh Confluence instances (the Playwright script basically clicks through the setup assistant, disables unwanted UPM apps, imports spaces and the like).
An example to show what I mean
The new space import assistant (we’ve encountered it in version 9.0.0-rc2 for the first time, but it might be around longer) is a great example for the problem. Let me show you some examples:
This is the success screen. There’s a green “Finished” status label in it. It would be nice to check that it exists in our automated import script to make sure everything worked. Shouldn’t be too hard, I mean it looks like it has something like class="success"
, doesn’t it?
Wrong! The highlighted DOM element below is the status item. There’s nothing about it except the localized label to find out what’s going on. There’s also nothing else meaningful on the whole page (anything with a class like “success” or the like) that would allow a non-human to interpret the result:
One more example from the same new UI module: After uploading the ZIP file, a modal dialog appears. We obviously want to click the blue button:
But in the DOM, the two buttons are EXACTLY the same, except for the localized labels (which we should never use because… localization) and the color, defined deep down in anonymous auto-generated CSS classes. Our only way out: selecting via the order buttons, hoping nobody moves them or changes the markup: SECTION[role=dialog] BUTTON:nth-child(2)
.
What’s the point?
As these examples show, this sloppiness in creating the UI seriously weakens automated test cases for everybody. Many selectors for elements are weak selectors, because we need to rely on order, hierarchy or (shudder) even the localized labels. This makes automated tests break more often than necessary, reducing the assured quality of Marketplace Apps and therefore the whole Atlassian ecosystem.
Please return to a practice of sprinkling meaningful IDs, roles and classnames in your UIs. Maybe let your engineers spend a day writing automated tests for their UIs so they feel the pain.
I understand that there’s a lot in your backlog, we’ve all been there. All sympathies, but this would really help us out. Thanks for considering!
Dear community, do you have the same problem? Or are we the only ones using stuff like Playwright? Or do we miss something?