2

Imagine a call center web application with a soft phone that automatically detects when a call has started or the caller has hung up. The obvious approach to receiving these messages would be some kind of server push (a.k.a. Comet). It's pretty disastrous if we miss one of those server pushes.

Must this application be written as a single-page JavaScript-heavy app, or is a more traditional multi-page app also a reliable option? (Or is this what iframes are for?)

My biggest worry about using a multi-page app is losing push messages when changing pages.

My biggest worry about using a single-page app is complexity.

Improve this question
1
  • On an SE page, for example, if an existing page is open, SE can highlight the Inbox icon in the header to say you have a new message. If you get a new page, then presumably the page you get includes the new/current state of the inbox (i.e. highlighted). Therefore the state change -- or the latest state -- isn't lost when you get a new page. So perhaps I don't understand the question.
    – ChrisW
    Apr 25, 2019 at 8:44

1 Answer 1

Reset to default
1

As far as I know, the soft dialler resides on a separate server by itself, and the agents interact using web interfaces. Your web app must introduce constraints on the agent like not being able to "change pages" without disposing a live call first. Now, If I were you, yes, I'd use "heavy" AJAX in my pages to accomplish this. Also, check out ViciDial if you're serious on writing your own CC suite.

I'd recommend a mix of AJAX and traditional multi-page setup (e.g., you don't need to AJAXify the log-out/log-in of an off-call agent)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.