Feedback Thoughts

I have a hard time falling asleep.  Always have and probably always will.  So I lay awake thinking about ‘stuff’.  Last night I started to think about the REAL Software Feedback system.  I have no particular beef with it – it’s just it doesn’t help me very much in certain areas.

I’ve used a lot of different bug reporting systems over the years.  Some are awful and some are really good depending upon the project.  Feedback is somewhere in the middle and I think a few changes would make it an outstanding system for REAL Software and for us users – particularly those that participate in the beta program.

First, add a category to the feedback report.  Just off the top of my head, I think these categories would be helpful:  Feature Request, Crash, Failed Assertion, Incorrect Functionality, and Incorrect Documentation.  This would be helpful for RS engineers in working on the really important types first (i.e. crash and failed assertions) and the rest later.

Second, I need to be able to say what version of REAL Studio I’m reporting against.  I often get a message from an RS developer asking what version of Studio I saw this in because they don’t see in the version they’re working on.  I’ve resorted to putting the version in the comments which seems kind of silly.  Feedback, as I understand it, is using inter-app communications to get the version of Studio.  As long as it’s running.  If it’s not running it uses (assumes?) the latest version.  Which might be incorrect.

I often report things when Studio ISN’T running (I just go up to the Finder search and type Feedback to open it quickly).  So I’m either reporting no version or against a possible wrong version.  It would be nice if Feedback recognized this and let me select from a possible list of versions.

I understand that RS will test it against whatever their most current version is, but to be more efficient I would think knowing what the exact version the bug is reported against would be more helpful than showing the latest version.

We now have incremental release notes.  Yay!  Maybe the Release version information should be in Feedback too.  Ideally, I’d love to get an email from the Feedback system whenever the version it was fixed in was released.

For example, I noticed in the latest release notes for R5 alpha 2 that a bug I submitted is supposedly fixed.  As the submitter I would like an email telling me that R5 alpha 2 has a fix for that bug/feature request and kindly asks me to verify that the it is fixed or not.  As the submitter, I should be able to Verify or Reject the fix.

Not being able to vote down a feature request is a long standing beef of mine, but I’ll not beat that dead horse today.  Perhaps the voting should be broken out into two categories:  Feature Requests and Bug Fixes and presented as such?

Well, that’s it for today.  Maybe tonight I’ll go to sleep quickly.  What do you think would be more helpful in Feedback?

6 thoughts on “Feedback Thoughts

  1. One thing that still gets my goat is an e-mail I received today from the feedback system. I’ve complained about this before, so I’m probably just wasting my virtual breath. I filed a bug report due to something not working as it *should*. After months of waiting, I get “This case has been closed because the behavior described is not a bug. Please add a separate feature request, thanks.” What?!? If you (being RS) thinks that the bug I filed should be a feature request instead of a bug, re-categorize it yourself. It is rude and irritating to get an e-mail like this and think I’m going to spend my time copy & pasting the same content. Not gonna happen.

    Before someone at RS wants to rebut the report itself, the one I filed was pertaining to the old EditField control and isn’t really relevant anymore with the new TextField & TextArea controls. Regardless, the point is the same. It is not good customer service to receive the above quoted e-mail. It’s like being punished for doing a good deed. What would be good customer service would be to receive an e-mail stating “We thank you for filing the bug report. However, we believe this is not a bug, so we have changed the category from Bug to Feature Request. Again, thank you for your time & wanting to help improve our product.”

  2. I love those mails “Bug has been fixed.” Then I eagerly download the next version to check, if the bug is really fixed. After seeing that it’s not fixed I add a comment with the request to re-open it. After some days this still isn’t done. That the bug is a showstopper doesn’t seem to be really important. The same goes for bugs that are fixed and are still not closed by my request.

    These are the people issues.

    Other than that I fully agree with you. Some additional things:
    – A severity is needed. A crash is bad, but if it’s obscure it doesn’t need to be so bad.
    – Speed: the app is so slow. Slow to start, slooowwww to load data.
    – Stability: crashes often.
    – It’s so stupid to force a search before submitting a new issue.
    – The interface is confusing. It looks slick, but the useability really is poor.

  3. @Christian Miller
    Yeah, I had that happen too and I basically told them to do it themselves because all of the relevant information was in the initial feedback report. And, like you, I thought it was condescending that they wanted me, the customer, to enter it all again.

  4. @Beatrix Willius
    Forcing a search before submitting a new issue is a good idea, in my opinion. Why is it so stupid?

    I can’t think of any reasons why this is a bad idea either for the user submitting the case or from RS’ perspective. Duplicate reports seem like a bad thing to me.

  5. It’s an awesome thing in our view.
    We have thousands of active users and if every one sent in one bug report once a month the flood of new reports would be simply overwhelming.
    I’ve found just in my to do list over 150 exact duplicates of reports.

    Please DO make an effort to see if the issue you are experiencing has already been reported and sign on to existing reports where you can. Add information to them if possible.

  6. Hi Bob,
    Sorry you’re an insomniac too. My migraines make it very difficult to fall asleep. Most nights I get 3-5 hours of sleep. I make up for it on weekends by sleeping all morning.

    Sometimes I’m up at 3 AM just thinking, sometimes not thinking at all, or I’ll wake up at 4 AM with a programming idea or solution, searching for something to write it down before I forget it.

    I agree with you about adding categories. Not only would that help us, but it would help RS too, by helping them see immediately what needs to be fixed vs. a wish list. Then, instead of hearing that “the number two item in the feedback is a feature request”, we’d know that “the number one bug is this, and the number one feature request is that.”

Comments are closed.