Jump to:
| Project: | Usability Testing Suite |
| Version: | 6.x-1.0-beta1 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
The problem that is not so easy to overcome i see is: have neat and easy screen and audio capture, especially screen capture.
How about solving the problem differently: Setting up a special testing server (hardware). On this server UTS would reside, and a tester (testing user) can log onto this machine by some sort of remote Desktop protocol (I have come to know this by Terminal servers or on support desks where you log onto the users machine and take over his mouse).
This would enable us to setup a screen capture (not so sure about audio) software on the server that is triggered when someone starts a testing session. It also holds the advantage of the capture data already being on a machine we have access to and it does not have to be transferred via Internet (big data, slow transfer).
I see this as an alternative scenario that opens new possibilities. If the roboplay stuff is very successful, it may not be needed, but maybe we come across some other nasty pitfalls that might be circumvaded in this sulution.
Problems to be solved here I see two:
1. Someone's gotta put up that server and maintain it
2. As far as I know, always some kind of plugin is needed to log into a remote desktop (e.g. Citrix). And we wanted to avoid all kinds of plugins to be needed installed by the testing user. But maybe there is meanwhile a solution (especially for linux) that needs only a browser.
Comments
#1
Sorry, but I don't see why you need UTS for this? It seems like what your purposing is screen capture software not on the client but on a server.
Apart from that this still requires client software, it would require a whole lot more effort from the UTE's part then just recording the browser with javascript (robotplay) and it will make it harder to test participants to quickly participate in a study. While with javascript we can point our analyse UI to particular parts of the recording without much trouble. You have to keep in mind, you want to make the burden to participate and setup a study as low as possible.
I see what your purposing, but to me it looks like what we didn't want to do with UTS, because then we could just have gone for a screen recording type software that streams or a server side solution.
#2
> it would require a whole lot more effort from the UTE's part then just recording the browser with javascript (robotplay)
It's much easier to setup a VNC server and client or remote X window session such as citrix than it is to create, reproduce or deploy something of the likes of robotreplay.
However such remote GUI sessions are never the same as the participant's regular environment (browser, extensions, OS, configuration) which is a significant advantage of the UTS over other usability testing tools. And unless they are on the same local network or have very low latency across the internet (almost never) then they are not smooth or easy to use.
IMHO, these disadvantages are more than significant enough to make this area not worth exploring at this time.
#3
Seems like we can agree this is a solution, but not in line with what UTS hopes to accomplish.