For the next version of Tickets - suggestions on a specific topic

[AndyH]

All.

For the next version of Tickets, I'm doing lots of good things but I'm after some ideas on one specific area. I am building a "Wizard" type functionality for New Incident creation which will be able to be switched on or off by user - hopefully this will help new users to get used to using Tickets as it becomes ever more detailed. The Wizard would be a series of modal popups which guide the user (with some help text as well) through putting in the important and mandatory information when creating a new Incident. What I need help with would be the order in which these should come which I believe is something that should be driven by operational processes. My suggestion to start this off would be:

1.       Name, Reported by and whether it is part of a major incident (I’ve added the ability to flag a new incident as part of an MI from the new incident screen).

2.       Type and Priority

3.       Location and To address (if required)

4.       Description

5.       Any files to add (can be used to store an ICS form against an incident for co-op from other agencies or other attachments)

I want to get this right as I do think it will be a useful feature so any suggestions as to what may be a better order will be gratefully received and contribute towards what I hope will be a useful addition.

Cheers

AndyH

[Yitz]

Andy 

I want to make sure I understand the goal here. The purpose of this wizard is to facilitate training new users and reinforcing correct behavior for existing users? 

If the purpose is as described above why not create a wizard whose order and verbiage can be customized in the Admin area. This would allow each organization to train based on their rules, regulations and best practices. This way you don't have to worry about the specific order or language and the system simply reads the order and language the organization would like to follow. 

Tickets is an awesome product. However it is not very flexible from an administrative standpoint an approach as described above would be a step in the right direction.   

Lastly, would it be possible to create a script/routine that automatically messages the responders assigned to a call with the call stats (As defined by the organization, similar to the way the message function works when the user is assigned to the call ) when the dispatcher closes the ticket? 

Thanks as always

[AndyH]

Yitz.

Yes good idea but at the moment probably for the future. Tickets as it is currently built doesn't lend itself to that level of customisation but I do have plans for the future. I see this as very much an interim step while I get my thoughts together about the next major change (which I am playing around with in my head at the moment). I'll have a bit of a rethink as to whether it would be easy enough to build in that sort of admin customisation to the Wizard order.

Yes I take on board the comment about building in some flexibility in the backend but I will hold that off to the next major big change as it will require a lot of recoding but it's definitely in the plan.

When you say call stats, what sort of elements and what sort of flexibility, it's all possible as the actual stats stuff is in a separate file already that can be pulled into other places as required.

Cheers

AndyH

[Yitz]

Gotcha 

On the last item I was thinking tha tit should set up similar to the initial notifies. Meaning in config have each admin enter letters that represent the elements they want to include in the disposition message

Some items to consider including are the: 

Call ID

Call Receive Time

Address 

Call Type

Each units D/R/O/FE/FA/Clear times

And the Final disposition of the call including the comments

Just a thought hopefully others can weigh in as well

[Jeff Carrier]

Andy, 

We have a blind operator and we're really trying to deploy this for ARES use.  He says he uses System Access for his screen reading software.  Is there support built in for screen reading software or do you have any suggestions?

I'd also be interested in any members on the list that use this for Amateur radio EMCOM as it's "use" in that arena is quite a bit different than it's public safety application.

[Jason Godfrey]

Hello.

If that matches what you are looking for, I've setup Tickets for the last several years to support Minnesota Bike MS events. Amateur Radio is one of our major "inputs." I run a rather old version as it works for me and I have some local modifications I haven't felt like incorporating into a newer version.

- Jason

--
You received this message because you are subscribed to the Google Groups "Open Source CAD" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-source-c...@googlegroups.com.
To post to this group, send email to open-so...@googlegroups.com.
Visit this group at https://groups.google.com/group/open-source-cad.
For more options, visit https://groups.google.com/d/optout.

[Barrie Campbell]

System Access To Go is a free download at http://www.satogo.com/en/. You can give it a try yourself.

Since the app is a web page, it is likely reasonably supported out-of-the-box. Have him poke around and see what he can find. 

Thanks

Barrie 

AD7PE

--

You received this message because you are subscribed to the Google Groups "Open Source CAD" group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-source-cad+unsubscribe@googlegroups.com.
To post to this group, send email to open-source-cad@googlegroups.com.

[mdtayl...@gmail.com]

@Jeff Carrier

We are using both Tickets and Members in our ARES organization. Our main server is in the EOC, configured to run offline, and easily configurable for other organization to use if the internet goes down and they need a hand.


Mark

[Aaron McCann]

I think it certainly a good idea. Granted, I'm just starting to dip my toes in the water, but I've done IT for several years. Users tend to get overwhelmed very easy, and I think that breaking the new incident creation into smaller, bite-sized chunks will be beneficial. I'd think that the outlined steps are fine, but perhaps ordered 1, 3, 4, 2, 5.

Aaron

[mdtayl...@gmail.com]

Andy, for the sake of argument, let's say one department does the following:

1. Type and priority
2. Locations
3. Interum save so that units are dispatched with minimal information
4. Name of caller and contact
5. Full incident description with supporting information
6. Add files
7. Final save and updated information sent to responding units.

And another department follows your scheme, or another that follows Aaron's scheme.

Can the wizard have an organization selection tool so that Admins could customize the steps, including an interim save with dispatch occurring?


Mark

On Thursday, December 15, 2016 at 9:55:37 AM UTC-6, AndyH wrote:

[Christopher Andrews]

My thoughts are...Ive changed my field names, but these correlate to same thing...

1. Incident Address/Location CrossStreet (around address. This is the most important thing in emergency dispatch. Nothing else matters if we cant get to where you are.

2. Nature/Type. What is the issue? We know where you are, now we know what to send.

3. Person reporting / Phone number.

4. Call Details notes, specific problems, etc.

That's what I would consider my wizard. Maybe make it so when you set up the wizard, the New Incident screen shows, but with boxes before each field letting you pick the ones you would like on the wizard, and number them in order, 1, 2, 3, etc...

On Thursday, December 15, 2016 at 9:55:37 AM UTC-6, AndyH wrote:

[SO-CM]

1) When Logging in as a unit, collect info of unit #, the names of the crew and region working.

2) Have the Request Access form the same as the user form minus the access level. Also give them the option to select their own password that conforms to what the super admin sets as well as a Carpathia for security and make all fields required.

3) Super Admin having the ability to setup access levels and permissions. (Example, a Dispatcher is set to Admin as a Supervisor but you don't want them having access to the config screen) or setting up custom access levels and permissions.

4) Ability to change top color separate from the main. And maybe more color or texture options.

5) In MDB the ability to make and print member and special event ID cards. It is getting more and more required, especially on disaster events.

[SO-CM]

Also with the status check pop-up, add the ability to extent the time or cancel time checks per incident.

[Justin Gilbert]

Would be nice to have a more involved patient database. 

1) Allow tix to auto assign patient ID.

2) Have to ability to search patients and what incidents they are linked with.

3) Try and reduce duplicate same patient records.

On Thursday, December 15, 2016 at 10:55:37 AM UTC-5, AndyH wrote:

[SO-CM]

1) list calls by CAD number instead of case number to help save on space in the situation screen, but have case numbers listed in the call.

2) Ability to issue case numbers for different types of incidents.

3) add to the situation screen another box that shows units, members, facilities, and admins that are logged in as a quick reference for dispatchers. This would be somewhat like the info box under the config screen but with out the ability to edit and users.

4) admin definable access levels. Over and above what is currently available. (ie.. give a supervisor admin access, but only allow them access to certain stuff)

[SO-CM]

That sounds like a really good idea. I have several brand new dispatcher if you need some test subjects :)

[Arnie Shore]

Anyone here working with NEMSIS data?  (https://nemsis.org/)

What can you tell us re tools,experiences, etc.

AS

[Justin Gilbert]

Any timeline for the next release?

[AndyH]

Justin.

Version 3.30 is now available for wider testing, it's not ready yet for full release but is working pretty well I think - enough to get some wider user experience. If you would like to test it drop me an email and I'll get it across to you.

Key points for this release:

1. Integrated Tickets MDB with a script within Tickets to import existing Tickets MDB installations. Integrated Tickets MDB gives you the ability to have Units defined and then assign "members" (single or multiple).You can also set Tickets to use either the unit contact details or the member contact details (multiple members on a single unit will all get comms). All the existing Tickets MDB functionality is included.

2. New Incident Wizard. You need to switch this on in settings and configure clicking on the link in config. This provides a modal popup with multiple screens that you can configure with which fields appear on which screen. There are a small number of mandatory fields that can't be deleted although they can be moved between screens. When you have this configured and switched on, when you click on "New" in the top bar, the new incident screen opens up but with the modal popup in front, you can't click out of it to close it, you need to click cancel or work through it. When you submit the last screen in the wizard, the new incident is submitted.

3. New Full Screen Incident / Operations screen (click "pop out" above the incident list on the situation screen). This is a combined function screen which includes elements of the Situation screen, call board, messaging etc. There are two versions of this screen - default which uses an incident list and Version 2 (set by setting the system setting full_sit_v2 to 1) which uses rectangular buttons for each incident. If Broadcast is switched on, you also get broadcast comms in a window on this screen list newest first. If you are using Ringfences and exclusion zones there is also a part of this screen which shows alerts as a button you can click on to go to the unit which triggered the alarm. There is no map on this screen which allows more screen space for other stuff. You can also set this screen as you main situation screen if you want by setting the system setting "alternate_sit" to 1.

One final thing is that we have started revising the screens to make them screen reader compatible for site impaired use. This I by no means complete however you will start to notice some changes in the look and feel of some of the screens to bring them in line with best practice for HTML5 and screen readers (moving away from tables for displaying forms to use different methods that screen readers can handle).

So basically lots of new stuff to have a go with. It's been a long time coming but I believe it is almost there subject to testing working out.

Cheers
Andy

On Friday, January 5, 2018 at 8:14:02 PM UTC, Justin Gilbert wrote:

[NSWN IT Jody Fielder]

Andy,

I wouldn't mind testing this for you. I can give you a login for the CAD so you can view how its utilized if you would like. 

Can you explain to me what Tickets MDB is and what its used for?

Thanks

Jody

[Justin Gilbert]

When creating a new ticket, it would be nice to have the "Nature" start to auto filter based on text you are typing in. Our organization has about 60 different call types.

[Maurizio Giacomello]

Hi to all,

for the next version I will suggest the integration with Telegram application so from tickets we can send telegramm message to unit and receive text feedback to me added on situation like "On scene", status, position or other thing.

Maurizio