I’m not sure what I think about the chat idea, but it is certainly worth considering.
One thing to bear in mind. There is a basic law of software that any good software will have features added until it becomes rubbish. I’d like to put that day off as long as possible. That’s why we are focused on improving the underpinnings. There is a lot of work that goes on that y’all don’t see, which is the point. I’m trying as hard as as I can to remove code. The site performance is nowhere near I’d like it to be, especially on mobiles. And another JavaScript widget will only make things worse.
For additional features, what I’d like is more like voice or discourse, separate apps that are linked. I wonder if a chat feature could be done that way?
Having heard the other feedback as well as yours, I think what might makes sense is to have a support.suttacentral.net or help. site that could hold all manner of end user help items. The live chat could run completely from that. I think this is the way that many support sites run. I don’t think there is any advantage (and as you say many disadvantages) to having the chat layered into the main site.
I don’t think that site would even have to run from the same server.
I like it, a dedicated support url. I’ll give some thought to it, in the meantime ideas are appreciated!
The problem isn’t the server, it’s the client side js. More JavaScript means more performance tax paid by all users, including users in developing countries on entry level mobiles.
People who need help think simply. They think, “I need help.” They do not think, “I need help with this topic and need to call that person”
People who need help think simply. They think, “I need help.” Indeed, when one needs emergency help, there is one number to call. The person at the other end of the line responds as needed, handling a diversity of requests.
Sounds wonderful, right? Well…
“Hello SuttaCentral, I am suffering, what should I do?”
“Hello SuttaCentral, I am suicidal, what should I do?”
“Hello SuttaCentral, how do I login?”
When help is sought and support is offered, we cannot be choosy about how we help. We have to help. And if we can’t help and say that we can’t help, then we will have taught people that we can’t help when they need help. With the brahmaviharas, one can’t hold back. They are infinite. When we offer help, we have to Help.
If we offer help, we should offer help in a way that is unlimited. SuttaCentral itself does this right now. SC provides unlimited help by providing free global access to the EBTs.
But if we are going to go down that path… When you call a crisis line for help, they can talk to you and provide you with some personal help. But the main thing they are doing is directing you to other services. This has nothing to do with being choosy about how we are helping.
I’m talking about providing technical support for using the suttacentral.net website.
No, this is just silly. Sorry. I’m talking about providing technical support for people trying to use the website. If someone is so distraught trying to use the website that they become suicidal… Seriously?
No, that’s not true. Why do you think that? Are we talking about different things?
What we offer and what people perceive we offer are different things.
To address this, we need to be very clear and directive about chat use. Effective chat use is often shielded by FAQs that people must wade through prior to using actual chat. This frees up chat responders to only deal with non-FAQ issues. FAQs also provide direct support without limit. FAQs weed out random requests and focus chat questions on what can be usefully answered. Chat alone is not a support strategy.
I agree. Every time people here have suggested having a FAQ etc. I have agreed. That is why I suggested having an entire section (help.suttacentral.net) dedicated to organizing help material. As I said early on, part of the job of chat support would be to direct people to articles, etc that had more detailed and complete answers.
So I think you are talking about the process where one enters a question for chat but is then presented with articles that might answer the question. I’ll have to see if the software I’ve been looking at provides that feature.
Personally, as someone who does try to look though help articles before starting chat, I find those “does this answer you question?” suggestions kind of annoying since I already did a search and couldn’t find what I was looking for.
I’m guessing that chat volume is going to be very low. My personal experience is that once I start chatting with a support person I realize other questions that I had. So even where I find myself in a situation of having asked what ends up being a silly question initially, I often get lots of other help I wasn’t initially expecting when I started the chat.
Karl that is a really good point. In case anyone thinks he is exaggerating, we do in fact get requests like that through the forum here. Not often, but it happens. Anyone who is staffing a chat service would need to know how to respond.
Indeed. My reaction was more to the point made (I think??) that we shouldn’t offer chat support simply because we weren’t going to be providing suicide counseling.
Yes, there will need to be all manner of training and guidelines. But I think it’s very doable. It may even shave a bit off forum mod work. I’m thinking about if someone wants to talk about their practice, for example. That’s something that we wouldn’t even send them to Discourse for.
Live support is like standup comedy. It’s brutal when you get it wrong.
I worked my way through college providing frontline support answering whatever came in through the door. Sometimes it was “the bathroom is there”. Sometimes it was “have you considered a different major?”
Live support is like standup comedy. It’s great when you can touch people and ease their pain. And it’s brutal when you get it wrong.
Having a set of FAQs would be a necessary shield around a live chat service.
But what would be neat about developing such a resource is that it could work immediately as a standalone.
That’s interesting because i was just thinking about writing an example article and mock chat about site language.
Site language is an especially pressing problem because it changes all the menu items. How may of us have chosen the wrong language on a gadget and then been lost as to how to change it back because all the instructions are in that language.
Back to the post you linked to. This is a good example of someone having multiple issues and lumping them all in one message. That’s not a problem, however it makes it a little bit more challenging to solve it asynchronously. Chat is a remedy for that.
Well, I guess it’s all relative. Someone having to wait two days to find out that the browser they are using (which is default on windows machines) can’t view the site? Doesn’t seem like a success story to me. It could have been cleared up in about 2 minutes with a live chat.
We also need to be aware of success bias (is that the proper term?). It’s really not possible to know how many people have the same experience this person did but never reached out. For those of us who live on frequently use forums, it may be hard to imagine that most internet users have never even registered on a forum, let alone would know how to post a troubleshooting request.
This person was also exceptional in that they were able to describe their problem in a way that someone could understand it mostly in one go. Also the ability to share a screen shot is uncommon. By seeing the screenshot showing Edge it was fairly easy to suggest a solution.
I would guess that for this particular user, if there was a help site (that they could still access when the language of the site was switched to Chinese) they probably could have diagnosed their own problem. But again, we just have no way of knowing how many people are just giving up.
[By the way, if the site is truly impossible to view on Edge, can’t we have a notice for people using Edge of this fact?]
In the software industry we build software based off of items that are in what’s called, the problem space.
We gather problem space items from quantitative and qualitative customer feedback from a wide variety and a large amount of customers. This feedback helps us determine what the customers underserved needs and wants are.
Then we build a solution for it.
What try to to do is prevent building software based solely off of good ideas. These are what we call delighters. A delighter is great, but it is more to set your product apart from another product to pull people over to your product and is not really a core necessary function.
If you only build delighters that have no core function or serve underserved needs or wants then they usually become wasted time and effort.
Purely my opinion:
Your idea is great. But from a product perspective, it’s important to make sure that the great idea is a need or a want from the majority of users.
I think I understand your point, that one shouldn’t create unneeded features. However I think there are someways in which this model doesn’t quite fit.
First, we don’t have a way to collect data from the people who gave up on using the site because they had problems. That I can think of. That makes it hard to do decision making in the way you propose. So part of the idea with the project is that it would be tried as an experiment. If after 3 or six months it proved to be unnecessary, or if we gather enough data on the problems people have so that we can solve them some other way, then great. We’ve learned something. And we’ve improved non-live help or reduced the major issues.
I think it’s also important to remember that what I imagine as live chat is not part of the suttacentral.net website. There would simply be a link to a help website from which people could do a chat if they wanted. So the danger of it complicating the main website would be near zero, eh?
Oh, without a doubt there is no need for chat support for the majority of the users. The site isn’t that bad. So again, I’m having a hard time applying your method to the problem.
I think we can safely say that the majority of users who have a problem using the site would like to solve the problem they are having. So in that sense, we could say “majority of users with problems.” Then of course you would need to break that down into percentage of those users who would want chat to solve their problem. How to know that? If we had a help site, we could track usage and see at what point people opted for chat I suppose.
Personally, I’m coming at this from a Dhamma perspective. If I had the opportunity to help someone overcome the hurdles they are facing to access the suttas, then I would want to take it. Volume wouldn’t matter. And frankly the method of giving help doesn’t matter either.
