How to encourage ethical usage and discourage unethical usage?

Question

I am currently creating a computer malfunction tool at a university IT center. Ideally, the tool is supposed to work as something similar to an amber alert, where the reporting of some event could be pushed to every users client. For instance, if a computer stops working, a warning could be pushed out to all available IT people in the building. The goal here is extremely fast response time, so that we can have every single computer running, and very fast response times during peak building hours. However, this tool relies entirely on the reports by student and faculty, as a ticketing system would be too slow and not useful in maintaining proper building uptime.

While completely ethical usage would make this tool extremely useful, it's naive to think that there won't be unethical users. I have a couple obvious problems, and couple not so obvious problems I would like to work out if possible. This tool might not be able to come to fruition, so it might just act as a user experience exercise.

1. How can I discourage false reports?

   • A glaring issue that I see arising, is that many users will use this tool simply for mayhem. The reporting of a false problems would render the entire tool completely useless. How can I encourage proper usage, while eliminating improper use completely? Is this even possible for a tool like this? I feel like user accounts might solve some of the issues, but there really is no point to collecting that kind of data. I also came up with something similar to Google Circles, where only people in your circle can push updates to your client, but that's basically just texting. Best case scenario, I want all recipients of a notification to be able to take immediate action without worrying about false claims.

2. How can I push this information out to clients in a way that's effective but easy to use?

   • I was imagining using something like a popup in the top bar of a device. In a single use scenario, this would work great, as the mere sighting of that icon would cause the user to take action. Is there any other way that I could separate the warning system from other applications? From say maybe a text or a Facebook notification?

3. Finally, how can I limit usage to particular buildings?

   • In the case of WiFi connectivity, it seems easy enough to limit communications to only that network, but what about when users are on Mobile networks, or on a massive network spanning across a campus? I don't want users from building A to receive messages from building B, however I don't want a user to have to "join" a building network every time they want to use the tool. Would a geo-location limitation, similar to yik yak work?

Thanks in advance, and I'm open to all suggestions and project directions.

Answer 1

1. If fast response time is paramount, you won't have time for a triage step to filter out bad reports. Accountability/auditability is your only other choice to limit false alarms. Patrons who cry "wolf" will eventually need consequences, but maybe they can be identified other ways (cameras, door access records, computer logon records, etc.) The good news is this may not be a problem you need to solve immediately. You could wait to see how badly it's abused before implementing a harsh, expensive, or overly complex solution.

2. The pattern you are looking for is called Publish-Subscribe. A subscriber says "I want to be notified about X", and the publisher notifies every subscriber when X happens. Some kind of administration will be needed here to add authorized subscribers to the list - perhaps your IT people are members of the group "LocalResponders", and you update the list of subscribers every night, or some similar sort of mechanism to add and remove people.

3. You will have to maintain a list of what it means to be "in a building", and find an attribute that your subscribers have that won't be burdensome to change.

   • Opening a "Check in to a building" app is an activity that your users won't stick with. Not recommended.
   • GPS/Location data is very expensive to continually poll, in terms of your users' phones battery life. Polling every 5 minutes could force your Apple users to recharge their iPhones twice a day just to keep the location information current. Polling every hour might not be enough if your IT people are more mobile than that. Maybe your campus has an operating schedule that would suggest an optimal polling frequency.
   • Perhaps your RADIUS servers can tell you which access point the users are connected to, and you'd then only need a list of access points per building (this might even improve accuracy by being able to distinguish an access point between 2nd floor and 4th floor, for example.) But reliability of that will depend on your WiFi coverage, and other physical aspects of the installation - it's not uncommon to connect to a WiFi access point from a nearby building instead of a closer access point that's shaded by an interior wall.
   • Maybe you have a different access control system, such as a door control system where your people have to scan their badge to enter. Your server could subscribe to notifications and keep track of the last building entered by each IT person.
   • You could statically assign a 'primary building' per user, and route every request from J. Random Hall to the assigned occupants. Of course, if they're not in their primary location, they'll get false alerts that they'll have to ignore; and if nobody's in their primary location, your users will get no service at all.

One thing you haven't mentioned is a "responding" button. If you're going to contact five people with an alert, do you think all five are going to rush from their chairs to answer every call? Or are all five going to remain seated because "someone else will get that?" By giving the responders some kind of "claim" or "responding" button, pressing it will cancel the alert the others see. It will also let the user know that help is on the way.

Another thing to consider is a what happens if no-one responds? How long are you going to let your users stand there in the dark? One minute? Five minutes? What do they see if they get no response after the time has elapsed? Do you signal responders in the nearest adjacent building? Do you signal a supervisor to head to the user's site to apologize profusely? Do you tell the user "we're sorry, all our techs are currently busy helping other people, your problem is important to us, we will get to you soon, your average wait time is - twenty - seven - minutes?"

How long does a computer have to be down before you dispatch an IT person? Are you polling the computers every 15 seconds? Every 30 seconds? Is it enough to respond to a ping, or does the computer require an installed agent to respond? Does the agent do some preliminary diagnosis or analysis? Or do you just send all system events to the server, and if you don't hear from a computer after 1 hour you assume it's dead?

Do you know if every problem requires a physical response? Can most of these problems be handled automatically by a software agent; or by remote staff, eliminating travel time? Can your per-computer agent software tell the difference?

Finally, the big question is on your IT people. What is their incentive for answering these calls? Do they get points for answering first, or responding within 30 seconds, or completing a response in 10 minutes or less? Or is this just extra work for which they receive no special rewards? How do you settle differences when Joe is the smart guy who takes 30 minutes on tough problems, but Jim is the fast guy who slaps a bandaid on within five minutes, allowing him to answer more calls? All that will drive their behavior, which is the ultimate goal of this kind of project. You can't just expect someone to jet to the scene because their mobile phone gave them an alert.

If you're going to take on this primary task, you have to see it through to its completion. And it's a very big project, just from what you've described.

Answer 2

This is an extremely large question, but I'll do my best.

How can I discourage false reports?

It sounds like you're talking about this in terms of a university environment. I assume people already have assigned email addresses from this organization, so it seems like you could use their existing account to enable a one-time registration of their device so they can create reports.

Users will be much less inclined to abuse the system if they understand that their reports are connected to their account, rather than just an anonymous post.

If a user is abusing the system, ban them.

^{download bmml source – Wireframes created with Balsamiq Mockups}

How can I push this information out to clients in a way that's effective but easy to use?

That sounds like what notifications were designed for.

Finally, how can I limit usage to particular buildings?

You should allow users to tie their reports to a location (if not using GPS, then by selecting the building and room details from a map or a list). By doing this, you could alert the nearest 5 technicians or so with a preliminary alert. If after 15 minutes, the issue still isn't "picked up" by a technician, you could send a secondary alert with a higher priority to the nearest 10 technicians.

Answer 3

Accountability is a good way of ensuring proper use - If a user knows that a report will come with their name and ID and that records of reports are kept for analysis, they will be less likely to use the tool for fun.

Another way to deal with the problem of false or unreasonable reports is to build some sort of triage into the tool - make it a tool to solve common IT issues that allows reporting if all else fails. That way the user will have to complete a certain number of self-diagnosis tasks before they can submit a report. You could also use the data from the self-diagnosis to compile the report.

Along with an account system, you will quickly start to gather a great store of data that may lead to the avoidance of certain problems all together - If you know who is reporting problems you may uncover a training issue with certain faculties, or groups, if you now where problems are occurring you may uncover issues with certain sites, if you know when problems are occurring you may uncover problems associated with usage rates, etc.

For notification you will need to find what is most useful for your users. You may even find it useful to integrate with a 3rd party such as IFTTT so that you can allow the users to decide how they receive alerts and what to do with them.

As for location, I've been doing some research into things like this recently and there are quite a few options but the do rely on external hardware: NFC gates, BLE beacons, etc. all work great for triggering proximity events including checking in and out of a given space - although this is more of an implementation issue and is definitely not my strong point.

Answer 4

I think the second and third question has already been answered quite well, so I just want to focus a little bit more on the first one. There are actually a number of strategies that have already been suggested, but I'll summarize and see if it helps you identify the one(s) that is most applicable.

• Tracking reputation: it can be similar to the points system on UXSE, or you can simply keep count of the number of useful reports made (like the flags that we can raise on questions for moderators to look at), but if you don't want to keep accounts maybe even device IDs or something semi-anonymous?
• 'Punish' bad reports: not necessarily an actual punishment, but delay their report in the queue for users that seem to raise less important reports so that you can still deal with it but at a lower priority level
• Reinforced learning: for people who submit report of the wrong priority or importance, next time they try to do the same type of report again you can remind them that the last report(s) submitted has the same issue so that they should think about submitting the same report again because it will not get priority
• Create a community driven goal: put up a dashboard of number of good reports submitted and problems they helped to solve (e.g. cut down amount of time something isn't working). This will give people a positive goal to aim for since you mentioned that you want to improve the accountability of the whole and not the individual user.