Back-and-forward conversations, especially in a written form, can go forever. They involve participants and observers; become an unpleasant show, where the initial question is successfully forgotten. You may get involved into this time-waster, or even ignite it, before you realize. I confess too, at times I find hard dealing with a ping pong problem.

But here are a few early warning signs I use to recognize the beginning of a ping pong.

2 or more subjects

Either you get too many questions or ask them. Or it's the deviation from the initial subject. Unnecessary opinions and guessing. Giving too much details.

Ignored subject

Arguing, blaming, defence. In all these conversations people simply ignore each other's point. In email, ping pong arguing can go days involving whole teams and departments.

 
Per my opinion, there is no universal approach to handle this problem. However, asymmetric actions usually help.

 
If it's not important do not reply. Maybe a person on the other side just wants to have a last word.
If it's official, urgent and important - escalate.
If it's in writing, then come and talk in person, or make a call, schedule a meeting.
If it's in person, ask to enlist all points of disagreement.
Re-think and re-frame.
Either way, taking a pause helps.

Defaulting input values is supposed to simplify the workflow for a user. Yet sometimes an application has a problem accepting its own suggestion. We wrote about that. Another piece that is always worth exploring is input dependencies.

See, if an application

• has a functionality that responds on your selection by updating dependent controls (enable/disable, reload list items, change default value);


• sets defaults in accordance to each other;


• sets defaults in accordance to date, time, and regional settings;


• has a functionality that remembers user input and uses it as defaults, either on client or server side;


• has a "storage" for customizable defaults on the client side (registry, files, etc.);

...end explore if it can be messed up.

Today's tip is a content pointer.

Testing heuristics, tricks, and oracles, packed into mnemonics, on the reference page created and maintained by Lynn McKee.

Rick Grey brought the following to my attention as a Quick Testing Tip re-post candidate. It comes from Rikard Edgren over on thoughts from the test eye. Rikard takes something intuitive and builds a very direct heuristic around it in the form of a decision tree.

This tip comes from Ben Kelly. We all need to test on Internet Explorer, but we've been spoiled with tools like Firebug in other browsers. Ben has a tip to get Firebug to work in Internet Explorer:
In IE, go to your Favorites bar and copy-paste the following chunk of code and call it "Firebug". (Jonathan: In IE 7, I created a bookmark, then right-clicked on the properties, and then pasted the following code into the URL field.)

javascript:(function(F,i,r,e,b,u,g,L,I,T,E){if(F.getElementById(b))return;E=
F[i+'NS']&&F.documentElement.namespaceURI;E=E?F[i+'NS'](E,'script'):F[i]('sc
ript');E[r]('id',b);E[r]('src',I+g+T);E[r](b,u);(F[e]('head')[0]||F[e]('body
')[0]).appendChild(E);E=new%20Image;E[r]('src',I+L);})(document,'createEleme
nt','setAttribute','getElementsByTagName','FirebugLite','4','firebug-lite.js
','releases/lite/latest/skin/xp/sprite.png','https://getfirebug.com/','#star
tOpened');


Then on any website, open that bookmark and it will give you a Firebug console.

Apparently, it seems to work pretty well for CSS and DOM stuff, but has some limitations when it comes to script debugging.

Enjoy.