Context
It’s important to make the adding and editing of devices to an event as simple as possible. It relies on volunteer time which is usually limited!
Constraints
Some things to take into account with the design of this component are that it is/will be used:
- in various environments (at an event, after an event)
- by multiple different types of volunteer (host, repairer)
- on multiple types of device (mobile, tablet, desktop)
Design decisions
In the new design we have changed a couple of things.
- Viewing list of devices. When viewing the list of devices, we have made it more compact so an event with lots of devices is less overwhelming.
-
Adding devices. Devices can be added with a ‘Quick Add’ bar. The rationale behind this is that adding devices is done by the host, usually after an event but possibly during, and that this should be quick capture that mimics what is currently captured on the flipchart.
- it is designed to be similar to the basic info you would provide when checking in a device at an event
- it is designed to allow quick adding of devices if you are inputting a full flipchart sheet of devices info after an event (you can quickly type, tab, type, tab, through the basic fields, hit ‘Enter’ at the end to add the device, then immediately continue entering the next device)
-
Editing devices. Devices can be edited by hosts and anyone else that volunteered at an event.
- Going in to edit the device generally takes place afterwards and allows for more detailed input by either host or Restarter.
- The most likely amendments are fleshing out the problem/solution field and uploading photos, and these are the two that are given greater exposure when editing as opposed to adding.
General note: only hosts can add and delete devices, whereas everyone who volunteered at an event can edit.
Questions
- Should the quick add bar go above or below existing devices in the list? Both? See the poll below.
- Should the Add method be the same as the Edit method? (i.e. no quick add, but a full dialog)
Notes
- We are still actively working on the mobile/tablet interface for this - it is not quite there yet.
- If there are strongly differing views, we could consider making the interface optional per user.
- And potentially different in different contexts.