Well to be honest, the issues really just come down to UX not being held as a priority here, since quite a few elements of the program's design flow just don't work as you'd logically expect them too.
For example, in both VWO and Target you're basically encouraged to put the test live before you're given the option to preview it in a web browser. The process only gives you the chance to save a draft and preview after you've set up the goals and been encouraged to put it live.
How I'd do it on the other hand is that the system would create a draft test as you start building it, and the editor window would have an option to preview it in a browser, which would do the same thing as the preview option for 'saved' tests. That way, people can browser test as they go along.
Images would work more like the WordPress media gallery, with a button accessible in both versions of the editor to select them there, plus the same option coming up if you choose to edit an image in the visual one. This would let people add/update images in the code only mode, plus make it much easier to find existing uploads, since VWO doesn't give you any way to see what media you've uploaded before.
(Target doesn't even seem to let you upload new images to their servers at all, which is kinda ridiculous)
Making the UI consistent in other places would be useful here too. For instance, both the rules for running the test and the audience segmentation use a very similar interface (with a dropdown menu and options for browsers, IP addresses, device types, etc) but the former has options the latter doesn't, like going by cookie values or JavaScript variables. These look the same, and the rules available to filter by should be the same.
I also feel such a piece of software needs to be able to know what's on the page/in the DOM and run/segment audiences based on that too. Because at the moment, if certain pages don't have a certain URL structure/cookie value/window variable, we can't limit the test to those pages (on either VWO or Target).
However, in some cases, they may have an element with a certain ID or class present instead. So we should be able to have the platform check for that, and run the test/segment results based on whether a certain element exists in the DOM. Same with the actual content of an element too; we should be able to run a test only if say, the h1 tag has a certain word in it.
The whole 'only one subaccount at once' and 'editor/preview window is tired to the main one' suck to deal with too. That's because at the moment, if I have two sites on VWO and want to compare a test across them, it flat out doesn't allow that. But this makes no sense. The subaccounts shouldn't be completely firewalled for those with the right permissions here, they should only be separate for those who only have access to one or the other. It should be like a forum permissions setup, where say the owners of Google.com and Microsoft.com can only access tests on their domain, but a marketing team working with both can compare them without having to use multiple browser sessions.
And the window thing... well that needs to stop existing at all. At present, closing the test window/tab will also close any separate windows/tabs associated with said test, at least in VWO.
They should just stay open as you'd expect them to.
So yeah, that should give you a bit more detail here. However, I'll probably write a whole article on the matter later too, complete with pictures and videos showing the issues from a user perspective, since both VWO and Target are pretty much UX/usability trainwrecks that need real designs teams like the ones used for Slack/Apple/Netflix/whatever.
from Hacker News - New Comments: "WordPress" http://bit.ly/2Grv7Qb
via IFTTT
No comments:
Post a Comment