Typeview – see what your users type before they press ‘enter’
blog.hipmob.com
blog.hipmob.com
Also, we do not log Typeview information.
EDIT: "You" = any visitor to a site enabled with Hipmob.
Making a user unwittingly transmit information to another human is a much bigger deal.
> Also, we do not log Typeview information.
Anything "sent" is "recorded" IMO. Besides the fact that we just have your word for it, all transmitted information is contained in a log somewhere in the company. That's the reality which may or may not be under your control.Without clear visual cues or one of those cookie-notice style "This text field will send back everything entered into it. By continuing to use this text field, you're consenting to this" message, it's unethical.
Legally splitting hairs : If I'm in a cafe, I have no expectation of privacy. But if I lean over to tell someone something private, you still have the equivalent of a boom mike over us.
But hey, "legally", I should have no expectation of privacy right? But is it ethical?
Mentally, the google search box has a very different contract than a textbox to communicate with support staff, the user generally gets immediate feedback and understands their data is being sent as they type.
Why do you hide the fact that you're doing this? If it was live updating the shared chat view for both users, it would be obvious. It's obvious users won't like this though, and will be very cautious what they type, so I don't blame you for trying to hide it.
We actually aren't trying to hide it (an HN post is not really the sort of thing one does when one is trying to hide a feature: we're actually advertising and soliciting feedback). We've disabled Typeview while we work on the privacy and user experience.
The points about user expectation are well taken: we will add explicit opt-outs for the site operator and the site visitor, as well as visually obvious indicators to the chat widget so the person typing knows what's happening and can choose to opt out then and there.
The demo in the video doesn't have any instant feedback, so doesn't continually reinforce the idea that intermediate data is being sent.
A visual cue such as Instant Search makes it much clearer that the server is reacting to your input, I suppose. Absent that, it is rather worrisome.
Similar in concept to capturing passwords that don't succeed, in case they may be valid for other sites where the user has accounts.
(Note, I don't do either of these things, just saying that people should not be surprised.)
If you are going to use it to engage a single user one-on-one you run the risk of revealing you were spying on them. I, for one, would rather not have to constantly feel like I was hiding something when talking to my users. Users are comfortable with the idea that you can see access logs for page transitions, and use that to help assist them. They are not comfortable with the idea that you can see things they typed and decided to not submit to a server.
From a technical perspective this is neat, but from a user experience perspective, I wonder how they surface the fact that this is happening?
I would suspect that lots of people refine a post box's content before hitting send, without really expecting anyone to be watching what they do..
EDIT: After getting feedback from some customers, we're building in an optout so that users
a. know that what they're typing can be seen, and b. can opt out of their typing being seen at all.
I think the benefits of the system are A: faster response times by reading as they type and B: reading drafts of what people type, to understand them better.
I commend you guys for trying something new and working to make your product better, but even more now for realizing you need to think this through a bit more..
Whilst this looks useful, it's questionable if it's ethical and furthermore it may even be illegal in certain juristrictions with strong privacy laws.
Personally I'd rather format my text on a notepad and copy/paste it to the chat than let others spy on me like that and even then only if I was forced to use it.
Which, fortunately, I'm not. This is one of the reasons I use NoScript.
Aside from providing a banner indicating that the keystrokes are being sent, you could also show something in the conversation log window as the user types, similar to the way the CSR view looks with a small "sending..." caption above it. If you updated that with each keystroke, the user would see his message being composed in the composition field, and in the conversation log window at the same time. I don't have data to back it up, but if implemented properly, the cue would hopefully inform the user that what he's typing and re-typing are being seen by the CSR without requiring the user to understand whatever text was provided in the banner/notice (I subliminally dismiss those anyway).