| Home | CHANGELOG | VHP Portal | DEV Portal |
The goal is to take the living service ticket and ‘reactify’ it, and at the same time deliver quality of life UX updates without impacting usability or the features available. Certain areas, such as the scoring of the presentation or the Work Order information, will remain the same, while others such as the Checklists, Service Items, or presentation will have changes and improvements made.
The service items section will be condensed to one page, with the majority of the information on the ‘info’ section hidden behind an additional button press. The repairs will instead take focus. The reasoning for this is that repairs are where the majority of work is done, and streamlining this will reduce button presses as the techs can immediately start adding repairs once they switch to Service Items. Additionally, the information for Service Items is pulled from Jonas so is not likely to be modified by the tech unless they’ve created an additional Service Item in the field.
Another major change with service items is switching the preset repairs (diag, etc) to checkboxes. This can be changed to something else, however the way it currently works would not work out of the box in react and would require additional components/time to create in a way that doesn’t break other components and works well. Checking the box can add the repair to the list of repairs if that helps clear up any confusion on the tech’s end of things. question: would diagnostics/etc ever have a qty of more than 1 per service item?
The biggest change with the service items is the new layout. We can explore different possibilities for these layouts, but essentially the idea is to open up the possibility for the tech to have items open side by side - specifically, have items tied to each system open side by side. So for example, working on an Air Conditioner and a thermostat side by side. There will be selectable filters (like the quote dash) for each individual item as well as selectable filters for each system. Selecting a system would reset the service items filters and vice versa. We would also have the ability to toggle between multiple views, such as large card (takes up the whole screen), 2 card view (side by side), 4 card, or list. The list can be scrollable. This will also make it easier for techs to verify and compare work they have completed
Checklists will see the most changes, as we would overhaul the presentation to focus more on the calculations techs would run through for the scoring process. The larger view would be similar to the view we used for service items, possibly without the side by side view if we don’t think it’s necessary. There would be a dropdown to switch between systems, and buttons to toggle the checklists that are part of that system. There would also be a button to configure and edit the currently selected system. Each system will have a system name, and associated service items and checklists. Checklists can be toggled using chip buttons, similar to the service items view. Each checklist form would be a form associated with the checklist type (cooling, air quality, etc). Fields would be organized according to, when possible, their calculation, or left out on their own. If a field is part of a calculation, it will show up under any calculations it is part of as a child field. Fields which are not associated with a calculation will show up on their own without any child fields. Child fields which don’t stand on their own wouldn’t be shown on their own, only as part of their associated calculations. This should simplify the process for working through a checklist. So for example, Cooling: Lost Capacity would show at the top, and ‘within’ it, the fields required to fill that (including any already calculated fields, which would be uneditable)
At present, techs would only be able to see fields for the checklists they’ve selected - we can potentially have a “master” if they would need the ability to have access to every checklist item in a single checklist, however if the lists we are given are robust enough then this shouldn’t be an issue.
When it comes to the internal structure of the checklists, we would either store the values in within each included or as a master list of values. The master list would be better as we’d have values in one place then. We won’t want to use the cooling/heating/system sorts as that will be messy to deal with, and can be better reconstructed by creating cooling/heating/system as checklists like the enhanced cooling and air quality visit checklists. So instead of ‘checks’ we could have something like ‘values’ which would just be a master list of every value. This will make updating them more manageable in React and will help with reflecting changes across checklists for identical items.
The presentation scoring will remain the same (see air quality mockup). The presentation for the repairs will be updated to match the visuals of the scoring presentation. The signature will become a popout using a floating button. The contract form will have the option to be a toggleable popout, but will be designed in a way that it can easily fit into the presentation and always be shown as I strongly suspect they will want the contract form visible.
Document everything more or less
App opens in Dashboard, 3 tab layout
This conversion would also be a good time to get the ticket to be able to operate better offline. We would for sure want to handle saving offline, storing in localstorage and then syncing when they have a connection. - Would we want to be able to handle conflicts? If so, are we tracking when things are updated?
The other thing we can handle with this now is phone support. Doing checklists on the phone has been brought up before and this conversion would make that really easy too accomplish. - Can use useWindowDimensions to roughly detect the kind of device we’re on - Would want to properly build in portrait mode support - Autosaving as part of this? - Need to account for status bar/
Dashboard Custom Components:
Main App:
Service Item Page:
ServiceItemCard:
<View> // Control row
<TextInput />
<TextInput />
<Button />
</View>
<ScrollView>
<FlatList>
<Item /> // Service item row item
</FlatList>
</ScrollView>
</View>