FWD » Deployment

There was a subject that was brought up in one of the meetings, a subject about what a common user should do or should be asked in case something unexpected happens in the application. I'll exemplify with a short story:

The chain looks like this. First, Goldencode which collaborates with Company A. We take Company A's application and convert it from Progress to Java and send the result back. Company A has a few clients on their end: Company 1, Company 2, etc. Company A tested the FWD application, and, after the final checks, deployed it to Company 1.

Now, imagine an average Joe from Company 1 doing its very average work of inputting receipts, checking invoices, or other average business stuff. In other words, average Joe is the end user for the FWD project, and he uses the browser version of the application. He has little to none programming experience, he only does what he's told to: check invoices, receipts, etc.

Then, at some point, something unexpected happens, either an error is shown on screen, or the application freezes, or the computer is caught on fire, you get the idea. Not only that, but Joe panics and starts to frantically click all kinds of stuff on the screen, or even push buttons on the keyboard, which all in all makes the situation worse. Seeing that the unexpected behavior doesn't go away, average Joe talks to the support team of Company 1 which then calls the support team from Company A.

Now, the question. What questions should the support team from Company A address to average Joe (via the support team from Company 1)? Or in other words, what sort of information would be useful to extract from Joe to make the investigation of the root cause easier? Not necessarily questions, it can also be things that average Joe can press to obtain more information.

The point of the task is to discuss about this scenario and come up with a list of questions that the support team from Company A should ask Joe, and/or stuff for Joe to click to obtain more details. So, I am keen to hear your suggestions and ideas.

One more thing to note is that we should consider average Joe highly unskilled in terms of doing complicated stuff on a computer. For example, he might freak out if someone asks him to open the Developer Tools in a browser. We need to come up with some questions/suggestions that are accessible and not very technical.

One idea that came up was to design a 'Panic' (or diagnosis) button in FWD that average Joe can press and certain pieces of information will be automatically extracted from the computer and zipped up (and possibly sent to the support team of Company A). This way we won't have to rely upon Joe's knowledge or potential misrememberings of the situation. I don't know how easy it would be to design such a thing, but I definitely think we should explore this idea further.

Company A should already have a support structure in place to deal with ticketing and the like with Company 1. So they would need to be trained to extend their support scripts to include what would be necessary to support FWD. So this is more of a "train-the-support-team" arrangement you are looking for?

Roger Borrello wrote:

So this is more of a "train-the-support-team" arrangement you are looking for?

Yes yes. We (Goldencode) don't have access to talk to the average Joe and Company 1, we can only work with Company A (a.k.a. our customers) and 'train' their support team to do a better job at diagnosing the issue when something unexpected appears.

Yes yes. We (Goldencode) don't have access to talk to the average Joe and Company 1, we can only work with Company A (a.k.a. our customers) and 'train' their support team to do a better job at diagnosing the issue when something unexpected appears.

FYI, we already have:

• Admin Console is one of the things to start with
• JMX and general Java platform tools (e.g. jmap)
• FWD Logs

Also, Radu, you should take into account that the OG 4GL application has close to none of these (there is no Admin Console, JMX, jmap, etc.). Maybe there are some equivalents, but as long as FWD achieves that kind of observability or even a bit more, then it is fine.

• what problems are actually triggered by Joe?
  • Dead screens are also dead in 4GL. The panic behavior from 4GL will be reproduced - Joe is not the first time seeing this. If it is not, then it is a bug :)
  • Deadlocks or infinite loops. If it is expected, then the 4GL UX is reproduced - Joe is not the first time seeing this. If it is a bug, then lets understand from Company A how it was handled in 4GL: was there a 4GL tool that helped the process? can we also have such tool in FWD? etc.
  • Slow loading screens. If it is expected, then the 4GL UX is reproduced - Joe is not the first time seeing this. If it is a bug, then lets understand from Company A how it was handled in 4GL: was there a 4GL tool that helped the process? can we also have such tool in FWD? etc.

I would not drive this conversation from brainstorming, but from actual 4GL customers, based on "hey, how did you manage this panic in 4GL?"; "isn't FWD doing the same?"; aren't the Java and FWD tools useful on that?

Radu, task #10451 is designed to log all relevant events, giving deeper insights into the user journey. It only requires a directory.xml configuration to make the events visible in the log file. However, the task is still under review..

#10451 is more low level that we are thinking here.

The customer at issue is worried more about asking the end user for some information and tests they can capture/run to provide the support team with enough useful information to report to GCD.

The customer gave an example of networking issues. There is no bug involved but an end user seeing network issues (slowness, network outages) will see a problem in our web client. What can we have that user provide to help the customer and us in our diagnosis. I know that we could ask them to open up the developer tools in the browser and do some diagnosis, but that is not practical to expect an end user to perform. Instead, what if we had a menu item in the web client that could display useful diagnostic test output?

There are a few additional considerations: in some extreme scenarios the UI may become completely unresponsive, or a deadlock could occur. In those cases, how would the diagnostic information be captured?