The picture above is not a snake. It’s a snake-mimic caterpillar, hemeroplanes triptolemus. Neat, huh?
In general, a bug is something that everyone can agree on needs to be fixed: an error message preventing someone from doing something; a page not loading; the software causing duplicate records to be added; a mistake in a calculation; et cetera. Generally speaking, the developers can just go ahead and fix these things without a whole lot of consultation.
But if it’s not a bug, and HIFIS is working the way it’s supposed to, then it’s more of a value or judgement call. Someone with authority needs to review the non-bug requests - these are generally called enhancement requests - and decide which ones to implement quickly, which ones to put on the back burner, and which ones to ignore completely.
So, when is a bug not a bug?
“Add Diversion” right is required to “Add Diversion Workflow” - this seems like a bug and I thought it was a bug, but turns out this is what the developers consider to be the expected behaviour. Therefore, since HIFIS is working the way it is supposed to, it’s not a bug.
New VI-SPDAT types not in Coordinated Access module - feels like a bug, but actually what happened was updating the Coordinated Access module was not in the instructions for the developers when they added the new VI-SPDAT types. Updating the CA module to account for the new VI-SPDAT types is therefore a request for a new feature.
Add housing history prevents duplicate housing histories but doesn’t check against admissions - The submitter is making an assumption that HIFIS is supposed to prevent adding a Housing History record if the client has a current Admission, but that’s never been something that HIFIS does. This is an idea for something new that HIFIS could do in the future, but it’s not a simple bug to be fixed. For example, what happens if a different shelter is slow at data entry - they keep a client booked into shelter well beyond when the client actually left, then a housing team houses the client, but they can’t record the move-in because a different service provider is bad at keeping their data up to date?
Are those things issues? Sure. But developers consider there to be an important difference between a bug - HIFIS is not working the way they intend - and an enhancement request - HIFIS is working the way they intend, but someone doesn’t like how it’s working.
Let’s go through a few different varieties of issues you might come across in HIFIS.
Bugs
Everyone has heard the term bugs before. Specifically, a bug refers to a technical glitch in which the software does not work as the developers intended. When something should work but doesn't, that's a bug. When a bug is present, the only thing you can do is report the bug to the HIFIS Client Support Centre. Bugs tend to get resolved more quickly than other requests, but they would be fixed in a future update to the software, so at a minimum you must wait until the next software version. Some (made up) examples of bugs are:
When a user selects a particular option in the "Reason for Turnaway" field, the user can't save the Turnaway record (this is made up, don't worry)
When a user has the Display right for Health Issues, they can't actually Display the Health Issue unless they also have the Edit right for Health Issues (this is made up, but there have been similar real issues)
When a user clicks the Reset Password button, the whole server crashes (also made up, don't worry)
Non-Issues
Next, let's talk about non-issues. A non-issue is when a user complains about something and there is no issue because what they're complaining about is by design. In this case, there's nothing to fix other than to explain to the user why things are the way that they are. Some examples of non-issues are:
A user complains that when a client is booked in at another shelter, they can't book them in at the shelter they work at. It might look like a bug to them, but the cause of this would actually be because of the Concurrent Book-Ins setting. Many communities intentionally prohibit a client being booked in to multiple beds at the same time. So the user is complaining about something that is intentional.
A user complains that when they create a Bulletin, users at other shelters can't read it. It might look like a bug, but the cause of this is because Bulletins, like many other things, are owned by the Service Provider that created it. Either this is a non-issue (that's how Bulletins are supposed to work) or a configuration issue (can be addressed through user rights).
A user complains that they cannot join their client to a family. When you investigate, you discover that the client is already the head of their own family, and HIFIS intentionally prevents a family head from joining another family while they remain the head of their own family.
User Error
A particular type of non-issue is user error. This sort of issue occurs when a user reports that something is broken or not working because they are doing something wrong. It might look like a bug to them, and you might be scratching your head trying to figure out why they have a bug and nobody else does, but when you look into it, you discover they are doing something quite incorrectly. We're highlighting this as slightly distinct from other non-issues because you can identify this as being fixable by more training, or maybe you'd just discovered a usability issue (see below). Some examples of user error are:
A user complains that any time they add a service restriction, it's not creating an alert for that client. You investigate and discover that all of that user's service restrictions have a start date and time equal to the end date and time, so the user had been successfully restricting the client for 0 minutes, and had done this several times because they thought it wasn't working.
A user complains that they cannot upload documents to a case file. You check and they definitely have rights that are working properly. However, you find out that the user is new to HIFIS and was simply expecting an attachment field like on consent, incidents, or identification, and didn’t see one when adding a case file. They hadn’t gotten past the “Add Case” screen to see the “Documents” tab.
A user complains that they cannot add a new service provider. However, the “Add Service Provider” screen is broken into two tabs. There is a commonly-missed second tab, Address, that has a mandatory field on it. The service provider was failing to save because one of the mandatory fields was being left blank.
Configuration Issues
Configuration issues are quite common. What this means is that someone set up some part of the software imperfectly and a user is discovering that they would prefer for it to be configured differently. In this case, it's almost always within your power to address. Some examples of configuration issues are:
A user complains that there isn't an option that they need in a particular drop-down menu. The cause of this is someone not adding that option to the drop-down menu, which can be easily fixed. Or potentially the option is there, but the service provider is not subscribed to it.
A user complains that they can't run a particular report. At first, that sounds alarming (maybe it's a bug?), but then you try to run the report and it works fine. After some investigation, you find out that a front-line staff is trying to run a report for administrators, and you've used Report Categories to configure who had access to the report.
A user complains that they can't see a client's income records. The cause of this is because they don't have the user rights to do so; either this was a mistake (configuration issue) or intentional (a non-issue).
Usability Issues
Usability issues are not bugs, but are sometimes similar to non-issues. A usability issue is when the software is difficult to use, but nothing is actually broken. A note here is that a usability issue is often subjective. One user might find a usability issue with some aspect that another user has no problem with. There is nothing you can do about a usability issue except to request to the HIFIS Client Support Centre that they improve the software. However, since usability issues are often subjective and technically, nothing's broken, they are often considered to be a very low priority by the HIFIS Development Team and are addressed slowly. Some examples of usability issues are:
A user finds it annoying that they can only select one goal per case. They're working on multiple goals with a client and they don't want to have multiple case files open. This is how the software is supposed to work, so nothing is broken, but the user would prefer that the software worked differently, so it's a usability issue.
A user complains that they can't delete a Housing Placement they created in error. This sounds like it might be a bug (should work but doesn't) or a configuration issue (incorrect user rights) or even a non-issue (you've decided that they shouldn't have permission to delete Housing Placements). However, the way that a user can delete Housing Placements is via the Administration menu through Client Service Delete, so they might have permission to do so but they don't know how. This isn't intuitive, so it could be seen as a usability issue.
Performance Issues
Performance issues have to do with the technical performance of the software and the server that's running it. Time-outs, lagginess, and frequent downtime are all indicators of poor performance. Sometimes, performance issues can be resolved by your IT support - perhaps the server that's hosting HIFIS 4 doesn't have enough memory or processing power. Sometimes, however, a performance issue is caused by some inefficiency in the software, and so it needs to be reported to the HIFIS Client Support Centre and addressed by them. Some examples of performance issues are:
A user complains that it takes forever for a particular report when they run it for a long date range or for many clients.
Users complain that they can't login to HIFIS 4 at 10:00 at night, when they are at their busiest. This suggests that too many people are trying to login at the same time and the server isn't equipped to handle it.
The Goods & Services List won’t load for a service provider that uses it very frequently. It’s because there are so many Goods & Services attached to that service provider that the page times out before it can load.
Conclusion
We hope that this discussion helps you to understand a little bit better the different types of issues you might encounter while you’re trying to manage your HIFIS instance. Is this knowledge going to change your world? Probably not. But we hope it provides context so you’re a little bit more equipped when you come across a user complaining about something and you don’t know what the next steps are.
Comments