Manufacturer representatives


#41

The first bug report on the HearingTracker’s Bug Tracker:

http://bugs.hearingtracker.com/issues/1

This is what a proper software bug report looks like. If there a steps to reproduce something consistently, those would appear in the description as well. Other users also have the ability to add additional notes to the issue with more information or comment on workarounds, or simply subscribe for notifications when new updates or comments are added (i.e. by becoming a “Watcher”).

This is all still a work in progress and only supports a limited amount of manufacturers and hearing aids, but it’s step #1 in much larger vision! Hoping this tool and process catches on! The end goal is to get manufacturers to respond to reports of this sort and bring about an easy way to keep on top of latest developments on issues of interest to the end user.

I encourage people to post links to the bug reports within the forum chats and update the bug reports as new information about the issue becomes available. Those of us who are more technical and in tune with the type of information that manufacturers require can help less technical and savvy users on the forum to create bug reports or feature requests of this format. I will certainly try to help that process. Redmine (i.e. the bug tracking software), also has the ability to host wiki pages where we can outline steps to gather relevant information that would be useful to manufacturers in diagnosing issues (i.e. app version, firmware version, hearing aid serial number, and etc …) and we can point users there for the most up-to-date instructions.

Here is a link to the current list of manufacturers:
http://bugs.hearingtracker.com/projects

Looking forward to everyone’s feedback!


Anyone having issues with Apple MFi Hearing Aids?
#42

@ConZ27 I think this is great, and I hope that others on the forum will join you in adding and reviewing bugs. I believe the first step is to report the bugs, and then try to get manufacturers to buy in. I would assume once we drive some traffic, and once it becomes a resource for consumers, that manufacturers will want to be involved.


#43

It looks nice. But let me get this straight;

  1. We (contributors) would have to learn Redmine, right?
  2. We (contributors) would need a Redmine login account?
  3. Capture

Non contributors would just look at it?
Manufacturers would do what, just look at it? Or, same requirements as contributors?


#44

OW, granted I am a non-techie, but I wonder if we are “over-working” this whole bug/feedback arena. Coming from a marketing background, I guess I see this forum as being superb for us users sharing information and experiences. And again, if I worked for any HA maker, I’d sure be hanging here to keep my finger on the pulse.

But there are a LOT of really exceptional techies on this board, and they are a wealth of info, so I could see where some want to get into the bug reports, version controls and all that - and even share the info among other like-minded techies.

But does this circumvent what the HA manufacturers should have on their OWN site? Ideally, tech and bug issues should be resolved via the user-audi-manufacturer route.

While I wouldn’t want aggressive over-representation by an HA’s rep here, I would also not want to restrict anyone from any forum. Practically, I doubt that HA tech/sales/marketing folks are going to HANG here all day. They have a job to do. It’s us users who are the most passionate about our issues.

Well. I wouldn’t want to stymie the techies here - GOD BLESS 'EM ALL - but I also think free access to all threads and being able to contribute maybe without even a label that identifies the member (and creates bias in our own minds) would be ideal.


#45

Very well said!!! There is a whole ear/brain/sensory system connection that is so vastly different and subjective than the eye/brain connection. It’s pretty rare for audis to even test their patient’s hearing with new aids IN, and see if there is measurable improvement in actual hearing and word recognition with the new aids. It’s as if both parties are complicit in “I sure HOPE these new aids are better, cuz I spent $X000 on them.”


#46

I wouldn’t expect hearing aid manufacturers to embrace the concept of Hearing-Aids-with-Bugs.

Look at all the money they spend on promoting their latest/greatest thing and their shinny brochures with good-looking models using their latest/greatest HAs with ease and success. What, admit there might be a bug in these $6000+ gems? Fuggedaboudit.

So maybe a name change to something other than BUG might be in order?


#47

Ideally, the user accounts from Hearing Tracker / Forum should be used for Redmine as well. Making a single account work across all the 3 systems is a technical challenge that is solvable - just requires time and effort. Those who are technical enough and able to contribute to creating and managing high quality bug reports are currently a subset of the users on the forum. That said, I can understand why we don’t want to make the upfront effort to make something work across all the 3 systems if the interest isn’t there. So, for the time being … we’re in pilot mode. If people (contributors and manufacturers) get involved and show interest, we can invest more time in making it easy to use. However, the onus is on contributors to make the first step before manufacturers commit to it. I’ve personally spoken with individuals at two Hearing Aid companies that are interested in supporting an effort like this and are monitoring to see how it plays out.

I have bug reporting success stories from the last 2 hearing aid reviews I’ve done, where I’ve submitted bug reports that have made their way up to VPs and CEOs of those companies. I was recently informed that one of my bug reports resulted in a development team in Germany diagnosing a serious issue and fixing it before it got in the hands of too many hearing aid customers. This method works and benefits everyone!

For non-contributors, looking at the Redmine can still be useful. If you find bugs that sound similar to what you’re experiencing, you can follow it and get updated when new info becomes available. You can also go a step further and actually try to reproduce the issue in order to determine how many people are actually affected by it. If the steps to reproduce are written well enough, then anyone should be able to follow them and help the process in confirming bugs.

Being from the software industry myself, if you want something fixed in a product then you need to submit a report with the same level of detail as demonstrated here: Bug #1: Clicking sound in Opn 1 while Bluetooth streaming phone calls / audio streams - Oticon - Hearing Tracker Feature / Bug Database. If a developer or tester cannot reproduce your bug, it gets de-prioritized and ignored until someone submits a better bug report that actually contains enough information for a developer to do something about it. If we take the time to fill out meaningful reports, we’ll receive fixes quicker if manufacturers forward them to their developers.

Also, if issues are ignored for a long periods of time … using a system like Redmine forces a manufacturer to address the issue if we raise enough noise about it.

The success or failure of this tool is determined on how we use it as a community.


#48

I disagree with this comment. There are too many AuDs / HIS people who do not understand technology on a deep enough level to be able to support power users. Not trying to make anyone feel bad, but it’s the truth. When you have problem with your iPhone, you don’t go to Comcast or Verizon or BestBuy sales people or even their the tech support … you go straight to Apple and the Apple forums.

Here is the current, simplified chain of reporting:

User --> AuD/HIS --> Manufacturer’s Product Support Specialist --> Product Manager --> Developers

Getting answers just takes way too long and questions have to through 5 to 10 people before someone responds. Difficult bugs are even harder to communicate and probably often go unresolved.

AuDs/HIS are not subject matter experts when it comes to the technological side of hearing aids, they are experts in sound, the ear, and hearing. Having to learn about all the iPhones, Androids, wearables, hearables, and etc … and how they work and inter-operate with hearing aids is a huge distraction and costly inefficiency in the system. Those are questions that the manufacturers should be answering. I think AuDs/HIS professionals should be focusing on their area of expertise rather than be stuck playing first-level “tech support” to customers. For those who are interested and able, by all means keep at it … but I don’t think it’s for everyone.


#49

Like it or not, every piece of software imaginable ships with bugs … just a fact of life. We can call them “defects” if it sounds better?

I don’t expect the defects we log to be related to the “hearing” side of hearing aids. You need an AuD/HIS for those types of issues. However, if your hearing aid is not pairing to your phone, the bluetooth is choppy, your hearing aid randomly turns off, that’s more of what I have in mind to use Redmine for.


#50

Ideally, they would take over the defect and move it through to the Resolved state:

New -> Triaged -> In Investigation -> In Development -> Resolved -> Verified -> Closed.

(Triaged = issue has been accepted for investigation and the report is complete enough for developers to look at)

We as a community would take over the Verified -> Closed part, so that we can verify that the fix indeed works as expected.

But at the very least, manufacturer reps will hopefully comment occasionally on the defect to say where it is in the pipeline. One of us can move it through the states on their behalf. If more information is required, the manufacturer reps can help facilitate communication between the bug reporter and developers when additional information is required.


#51

I have the feeling that your good results with the bug and the transparency were because of the quality/model for the main site. It opened a door most folks never find.

I recently upgraded my computer. We know that aids are just dedicated computers. Upgrading the computer came with a huge amount of available info and reviews that were professional in scope. Contrasting that to what is available with aids is night and day.

Back in time, I did support on the OS/2 board. Almost all was user error. Here, that is very similar but real bugs do appear and can be verified using scope. It isn’t a detailed bug report like you made but it does define a need. If they are sincere, they would have been PMing users for more details and have questions for them.

When I was programming, bugs weren’t as formalized as I had a real-time interface with the client. Report-define-fix.I don’t recall manufacturers using their trained reps to provide follow up to any great degree. My impression of one of the bugs mentioned often here is that it is likely a hardware problem. If that is the case, they know about it but there won’t be a recall. If they are decent, it will be fixed in the next model.

The lack of transparency and refusal to acknowledge problems is unique for something termed a medical device. With aids it is all about the bottom line and I don’t see any willingness to change to a more enlightened program.

I think your report/solution made it to the CEO because staff could use that to point out their excellence. Internally, management wants the best results possible for the investment. Staff was just tooting their own horn.


#52

Okay, I am impressed by your Bug Tracker efforts.


#53

I think that the bug reporting can be a useful tool for all. It helps focus on what the real problem may be. If the problem is a true software bug, then it will be reproducible. The problem then becomes an issue for the HA manufacturer or the accessory device manufacturer or provider. Think about how Android patches are pushed out, most recently the KRACK vulnerability. Most devices will not see patches as they reach end of life for product support after a year.

I’ve currently got a problem with my Phonak Brio 2 and connectivity. I noticed that my left HA cuts out when I turn my head. So I checked the forums and read that the ComPilot Air II has connectivity issues if it too far from the HA’s. So I bought the ComPilot II where the increased signal strength from the neckloop supposedly solves the problem. The left HA still cuts out when I turn my head, but the problem is less severe.

Reading the forums I see the @JordanK has posted some observations about Bluetooth in this thread: Anyone having issues with Apple MFi Hearing Aids? So maybe, my problem might be Bluetooth related. Maybe it might be how the wireless signal transmission happens between the L & R HA. My gut says I’ve got a defective left HA that appears to work fine in all other respects.

What makes me say that? I don’t see a lot of comments about the issue affecting only the left HA using either the ComPilot II or ComPilot Air II with a Bluetooth connection. If I did, that is where Redmine might help. Although @ConZ27 efforts are admirable, the discrimination of what a problem might be, needs to be addressed first.

With the current model of bundled fees they should understand the technology. Consider that one of the most oft heard complaints is the inability to hear telephone conversations. That is an accessibility issue. I don’t expect the providers to be able to write code. I do expect them to understand the technologies they provide.

It is not unique, that occurs in other health fields as well. Unless it is a serious health issue, loss of sales to the competition is what invokes change.


#54

VI’ve participated in many forums where the manufacturers were present and quite active. In every case, their presence was useful and appreciated. The forums allow them to directly gauge the community’s response to new products and the community gets to provide suggestions for new features and bug reporting.

The one thing I will say is that the hearing aid manufacturers have traditionally pushed customer support down to their hearing aid resellers and appear to be quite shy about engaging directly with end users. I think this needs to change before an Elon Musk type of person comes along disrupts their business model. Lets face it, Apple and Google both have all the ingredients to launch their own hearing aids and totally put everyone out of business. The hearing aid manufacturers need to evolve and modernize their market approach.

Jordan


#55

Definitely agree with your sentiments here! It is true that the AuDs time is better spent on patient satisfaction and fine-tuning issues. Truth is, my own dear aud-guy doesn’t know the functional nuances of every aid’s add-ons like my old StreamerPro, or how to get the most out of my new Phonak Audeo B-Direct TV streamer even.

Perhaps as JordanK says in his post further on, some manufacturer techies can be lured to our board to help the power users. It’s such a golden opportunity on both sides.


#56

That is something I hadn’t even considered! Granted we (i.e., our aids) is the FLEA on the gnat that sits on the tail of a dog to companies this size… but then look at Costco. They’ve also become a major player here. Thing is, they lack the whole bluetooth/app focus that Apple and Google would be more apt to capitalize on.


#57

That’s what the Hearing Aid Forum can help address :slight_smile: … we have enough experienced and techie people here to at least help start the investigative process and rule out the obvious causes. If we can’t, open the Redmine issue and have the manufacturers jump in.

Perfect example of something can be logged in Redmine! Other users who experience this issue as well should be able to add a “+1” in the comments of the bug report in order to confirm it. If enough users are affected, it should qualify for a free repair.

For the time being, if your HA is still in warranty … might be worthwhile to send it in or have your AuD take a look.


#58

Comments saying “+1” are most often useless. There’s no telling what the +1 means. Does it mean, “the submitter is my friend and I want to support anything he submits”, “I don’t understand the issue but it looks important”, “the submitter linked an xkcd cartoon so I’m required to like the report to show everyone how cool I am”, or one of a thousand other useless reasons.

It is even worse if the reporting platform supports +1 only through comments instead of having a dedicated function to record votes, because, as useful as being able to inspect the total vote count may be, getting a notification each time someone wants to say “+1” is extremely annoying. If Redmine has a dedicated means to record votes, please turn it on, and direct the +1 votes to that instead of comments.


#59

Some background on the “+1 in the comments” thing: this is a very standard practice on open-source projects … you will find it all over sites like GitHub which host a large chunk of the world’s open-source code. Being a software engineer, this is second nature to me hence why I suggested, but I can appreciate that not everyone is from that background and this idea sounds half-baked. In most cases, it is done due to the lack of voting system, or a voting system that does not match users to votes or allows users to vote multiple times on the same issue.

Up voting or down voting a bug report with a voting system is susceptible to all of the above as well. Does not address this problem at all.

I’ll will look around at the Redmine Plugins and see if I can find an issue voting system that ties users to votes and enforces the single vote per user rule. Hopefully I’ll have some free-time on the weekend to poke around with it.


#60

That it is popular does not mean that the numbers that can be extracted from voting activity are particularly meaningful. It is likely if I introduced yet another issue tracker that I’d put some sort of reaction capability like GitHub did, even though I’m not convinced about its usefulness as a metric. The reasons for it would be the same as those of GitHub, which I cover below.

GitHub introduced the capability to react to issues, pull requests, and specific comments with a thumb up, thumb down (and a few other options) specifically to remove the reason for users to post comments consisting solely of “+1”, “-1”, “yay”, etc. Before reactions were introduced there was no other way to signal mere approval or disapproval without posting a comment, which resulted in issues with bits of substantial discussion lost in a sea of “+1” comments that don’t do one thing to move towards a resolution. Additionally, everyone who did care about the issue would get notified about each and every of these reactions, which is annoying. Nowadays if someone posts a “+1” as a comment, they are likely to be told to use the reaction capability to react to a post rather than post a comment. The more traffic the project gets, the more likely they’re going to be asked to use reactions rather than comments.

(We still have to deal with the obnoxious “Anything new?” comments, alas.)

And the capability to react to specific comments demonstrated that votes don’t mean much. People do thumb up useless stuff.

Yes, but usually without the annoyance of getting a notification with every vote. It’s been my experience on all systems that offered dedicated voting or reactions, that notifications were not sent with every vote (though maybe it is possible to opt into such notifications). I cannot tell whether Redmine will insist on eagerly sending out notifications with each vote (or reaction) because I’ve had to use it only for one project where there were not many opportunities for “+1” comments due to the fact that few people bothered to log into Redmine, and the project lead decided to switch to GitHub anyway.