General usability issues summary

My general usability issues summary since 10/02/2016, while some of them probably can be solved by usage or coding methodology, which i haven’t grokked yet.

  1. Client side error tractability - lot’s of errors are described as call to function in raven.js , like an call to captureExeption, while event described in Sentry UI is not describing a cause of an error, thou signifies that the error has thrown. I suspect that it 's related to anonymous/async-callback javascript function calls.
  2. Error Grouping - large portion of errors are not grouped by same causality, probably related to same reason as an item stated above, in conjunction with javascript common libraries cross-browser compatibility issues, like in case of jQuery 2.X usage on IE/Edge clients . A personal remark, as usual, i spotted that MS Internet Explorer/Edge is a common denominator for this issue, compared to Chromium derivatives.
  3. Regression traceability over time period - Sentry seems to be a great tool to aggregate client side issues in order to be an catalyst tool for continues product improvement. Rate limiting is a necessary tool for engineering as same as in marketing. But “rate limiting” also introduces a different adaption curve that isn’t seems to be a benefit for all sides. “Rome wasn’t built in a day” - entrepreneurs are tend to be experimental, therefor an idea, can introduce a “flood” of errors while account is on free or some degree of paid plan. The idea that was introduces is still not profitable or able to pay back for tractability. Other perspective is a seasoned saas that also can introduce a flood of error events when new product feature is deployed to production. For cases mentioned above, “rate limiting” is an notification for a “change” which can not be analysed properly due to “rate limiting”, thou it pushes for an upgrade while “primary cause data set” is lost (i just guess, but rate limited event are probaly /dev/null’ed). Thou i would like to mention that there is a kind offer to contact account manager to increase “rate limiting” for a specific cases, but it is still a marketing move. Reasonable product approach would be : charge for “view ability”, seems to be a bit more practical, while also introduces a “cost wise product aspect” challenge.
  4. Error Reproduction communication - Sentry does shows trace to an error in code , allows to map it to project management system, etc . Although it is not enough to be an efficient tool in case marketing/tech representatives ratio is low. It is reasonable to think that most efficient way is to introduce an “error reproduction replay” with context. User feedback - seems related (haven’t tried), thou verbal descriptions of web client error are usually a nonsense.