While this may be handy for the CSR, I could see this leading to unpleasantly surprised users if the CSR references something they typed but didn't send.
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..
The goal is to give customers tools they can use responsibly, and allow them exercise judgement. This is obviously the leading edge and we thought long and hard before enabling the functionality. One idea we have towards making visitors more comfortable with this would be to create a notification that enables visitors to see that what they're typing can be seen? Hopefully customer feedback helps us figure out which direction to go here.
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.
If you want users to know what they are typing is sent, then echo it into the window above. That's a strong yet non-intrusive way to let them know the data is being sent.
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.
No, it isn't innovation. People have thought of this and dismissed it because it's unethical. Your optout won't solve this in a way that doesn't clutter the UI. And even if it is fairly loud, not everyone will read it. You'll need a clickthrough.
Hi Ben - thanks for the feedback (also responded to you on twitter). We've disabled the feature as of now and we'll only roll it out again once we can give visitors clear and easy options to know what's being seen, and opt out as well.
I think this is the responsible approach. Someone else made the important point that "if I choose not to send something, respect my choice".
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..
It seems like it was created to solve a serious problem for users. As a user, however, I would feel a lot less comfortable using any website that I know has this service, if I choose not to send something, my decision should be respected.
Would an explicit flag to turn this off be better? We looked at this similar to instant search results in Google: as you type the results update. Obviously having a human at the other end elevates the privacy concerns: are there other angles we should also be looking at?
It sounds like a good experiment. Personally, I think I would always want it turned off, but if it is painfully obvious that you are opting in to allow the other side to always see what you type, it seems much better (as long as it is really easy to change this permission in real time).
We've gone ahead and disabled it while we work on the privacy and user experience. We will make the indicator and opt-out really easy to see and reach.
Hey HN - OP here (ayo at Hipmob). We've been working on tools to give our customers more insight on what's happening with their users. We started by just giving a typing indicator, and thought we could give our customers a hand by letting them look a little deeper. Would love your thoughts/comments here, or just email me at ayo@hipmob.com.
This idea on its surface sounds horrible. First, it feels like it crosses some ethical lines. Second, if you help a user and tell them (or, let it slip) that you figured out their problem by spying on their typing, they will probably be horrified.
We looked at this more like instant search results (similar to what most search engines do already) where the server updates the results as the user types into the query box. The human operator does increase the privacy questions, though.
I mean, can you give a real-world example where this technology has resulted in an increase in user happiness? The only way I could see this being helpful is if you aggregated the data and made inferences across multiple users. But then, you are spying on everyone.
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.
So I accidentally paste something sensitive I need to edit before sending and now your servers are keeping a log of it, sent over plaintext? Highly unethical.
We looked at this more like instant search results (similar to what most search engines do already) where the server updates the results as the user types into the query box. The human operator does increase the privacy questions, though, but this wouldn't be any different from accidentally pasting something sensitive into the Google search input.
The difference is that search-as-you-type is immediately obvious that it's occurring. Unless there is an obvious user cue that their typing is being sent immediately across the network, I'd consider this more scary than helpful.
Tom,
thanks for the comment: we've disabled Typeview while we work on the privacy and user experience. We clearly didn't think that through as well as we should have.
As it turns out Google search-as-you-type is actually retained for 2 weeks in full, and then whittled down after that. https://support.google.com/chrome/answer/180655?hl=en. Google probably doesn't have human review of the data though: the machines are much better for that at their scale.
There is a contextual difference beyond just UI cues too. Making a user unwittingly transmit information to you is probably at most a minor sin when the receiving end is a dumb machine that doesn't do much/anything with the data.
Making a user unwittingly transmit information to another human is a much bigger deal.
Google Instant has instant feedback based on what you type, which quickly and easily cements the idea that Google is processing what you type as you type it.
The demo in the video doesn't have any instant feedback, so doesn't continually reinforce the idea that intermediate data is being sent.
I don't want to slam your site too much, but just because You don't log Typeview information doesn't mean someone doesn't. If you're using regular HTTP then everything the user types in your textbox can be intercepted by people on the network or logged on proxy servers anywhere. This is not something the user expects to have to worry about.
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.
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?
This used to be how the old UNIX program ytalk worked, you could watch the other person type. It was obvious what was happening though, whereas everyone assumes that an edit box allows you to, uhh edit, before choosing to send.
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.
Welcome to HN (I see this account was created within the last couple of minutes).
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.
ICQ used to have this years ago. I think its kind of an invasion of privacy. People expect things to only be sent once they hit send, not as they are typing
From what I remember, Wave had it optional as they even said themselves a lot of people were uncomfortable with the idea of people seeing their train of thought (and mistakes). It's an interesting idea but it's a horrible way to treat the user.
Technically trivial, ethically horrible, especially if it's not disclosed to the user.
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.
Technically trivial, ethically horrible, especially if it's not disclosed to the user.
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.
Well, technically, in this case since the response from the server doesn't matter, this has always been possible. There are lots of pre-AJAX ways to send data to a server from JavaScript, including requesting Images (which is what Google Analytics uses) and generating dynamic iframes.
I hope to god this does not become widespread. I type all sorts of crazy shit in text boxes. Everyone's basic assumption is that no information is sent until you hit 'enter'. Deploying this in the wild would seem like a huge invasion of privacy. Akin to turning on a user's webcam and a screen capture to turn your users into unwitting usability testers. In other words, please use this responsibly.
Brett,
we looked at this more like instant search results (similar to what most search engines do already) where the server updates the results as the user types into the query box. The human operator does increase the privacy questions, though.
I robbed Fort Knox- I look at it more like I'm simply relocating the gold bars from place to place. The fact that it's all in my basement does increase the grand larceny questions, though.
No deja vu: just repeating myself so folks don't have to scroll through the entire page looking for responses that may apply to their comments (they may still do so if they choose, but they don't have to).
Ah, yes - Instant Search... I thought about that as I typed this. I typically find myself naively hoping that Google treats Instant Search differently than (Actual? Real? Not sure what non-instant would be called) Regular Search, and does not store my fingers' wanderings.
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.
This is Femi from Hipmob: we looked at this more like instant search results (similar to what most search engines do already) where the server updates the results as the user types into the query box. The human operator does increase the privacy questions, though.
Is an application that spies on your use of that application still spyware? Presumably it's in the EULA somewhere. Personally I label spyware as something that spies on other parts of your system, not itself.
This is Femi with Hipmob: there ARE some privacy concerns we have over this, and as it evolves we expect to add additional notifications and controls. The human operator element does make it more privacy-sensitive, but we looked at it more like a real-time search query submission: most modern search boxes will send the query details as you type in, and show prospective results in real time. Obviously, there isn't a person staring at your search query in real time so it is more anonymous, but that was the thought process that guided this.
I will actively not use a site using this technology and if someone doesn't create a firefox plugin to block this I'll probably take a stab at it myself.
Very intrusive. I'm never radical when it comes to boycotting sites that collect any information they can, but this is one situation where I wouldn't touch a site using it with a ten foot pole. Without a note explicitly stating that anything typed is recorded, it goes completely against user expectations.
As it's implemented I'm not a fan of the idea for much the same reasons that have already been discussed. But I think there's a way to implement it that makes it more transparent to the user precisely what is going on:
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).
Matthew, we've gone ahead and disabled it while we work on the privacy and user experience. Some more thought is clearly necessary (one of the reasons we posted here) and something like the banner solution you suggested is probably the way to go.
All, thanks for the feedback. We've disabled the Typeview functionality and rolled that update out. We're going to:
1. Provide an opt-out on the site operator side (so a site operator can choose not to use it).
2. Provide a clear indicator that typing information is being sent in the chat widget (so a site visitor or mobile user knows it is happening).
3. Provide a clear, easy to reach opt-out so that the site visitor or mobile app user can opt out of Typeview (if it is enabled).
65 comments
[ 5.0 ms ] story [ 129 ms ] threadFrom 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..
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.
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.
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.
The demo in the video doesn't have any instant feedback, so doesn't continually reinforce the idea that intermediate data is being sent.
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.
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?
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.
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.
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.
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.)
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.
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).