Create Trip List – request for simpler work flow

1. Background. A Trip List is the subset of the Booking Requests list. It lists only the participants approved by the Leader(s), plus the Leader and any co-Leaders. The Trip List contains one data column that is not in the Booking Requests list – the participant’s emergency contact details. (Reason: to minimise exposure of this data for privacy reasons)

In an emergency, authorised Committee Members use the Trip List to give Police and other emergency personnel the names and details of the people who are participating in the activity.

If a ‘lazy Leader’ starts the activity i.e. starts hiking, without submitting a Trip List, and there is an emergency, the Authorised Committee members will at least be able to see the Booking Requests list or saved Trip List, which is a big advantage over our current manual way of doing things.

2. The System’s present workflow

1. Log in as a leader

2. Activity Management

3. Manage Bookings (screenshot below)

4. For a particular activity, Edit Bookings

5. Add Bookings, Approve, Reject etc.

6. Create Trip List (screenshot below)

7. Go to Bookings (screenshot below)

8. Save (screenshot below)

9. For the particular activity, Edit Trip List (screenshot below)

10. Submit Trip List (screenshots below)

In summary, the present workflow is:

1. Log in as a leader

2. Activity Management

3. Manage Bookings

4. For a particular activity, Edit Bookings

5. Add Bookings, Approve, Reject etc.

6. Create Trip List

7. Go to Bookings

8. Save

9. For the particular activity, Edit Trip List

10. Submit Trip List

3. The issues with this workflow

(a) The workflow contains an unnecessary detour. It would be simpler to allow leaders to skip steps 7 to 9.

(b) Step 8, ‘Save’ appears on the ‘Edit Booking Requests’ page, but does not apply to the data that is visible on the ‘Edit Booking Requests’ page. It applies to the data that was visible at Step 6. This confused Leaders at the group testing.

(I did, in the wireframes I emailed Shailesh on 7 January, ask for a ‘Save’ and an ‘Exit without Saving’ button in the Edit Booking Requests page, which is probably why there are there But now that Zealous has implemented auto-saving on this page, these buttons are no longer needed on the Edit Booking Requests page.)

(c) At present, Leaders have an ‘Add Bookings’ option via ‘Edit Bookings’ which is good, thanks (see Screenshot at step 6, above). Leaders also have an ‘Add Bookings’ option via ‘Edit Trip List’ (see Screenshot at step 10, above). In group testing, leaders had different comments on being able to Add Bookings at the Trip List stage:

‘It’s confusing because it makes it possible to have a person on your Trip List that was not on your Booking Requests list’ ‘It’s confusing - why does the ‘Edit Trip List’ page allow you to Add a Booking but not to Cancel one? Just before an activity starts, it is more

common for a requestor to cancel, than for the leader to receive and accept a late booking.’ ‘It’s good! It’s a useful short cut – I can add a late booking to a Trip List, without having to go back to ‘Edit Bookings’.’

After consultation with a number of leaders on how to make the workflow less confusing, we would like all changes to be made via ‘Edit Bookings’, and no facility to make changes on the Trip List Page i.e.

On the Edit Booking Requests page, display the ‘Create Trip List’ action (no change) Once a leader has clicked on Create Trip List, we would like the System to display the Trip List and to automatically save it (Screenshot C4 shows

requested change) Once a Leader has Created a Trip List, on the Manage Bookings page, please:

o display the Booking Status ‘Trip List saved’ o display the action ‘View Trip List’ (changed wording from ‘Edit Trip List’) (Screenshot C5 shows requested change)

Remove the ‘Edit Trip List’ page. (screenshot C6 shows page that is no longer needed)

I will explain to leaders in Help documentation that ‘Edit Bookings’ is where they must make all changes; if they want to change a Trip List they need to make the change in Edit Bookings and then click on Create Trip list again.

(d) The workflow would be clearer to Leaders with some text changes eg change ‘Download File’ to ‘Download Trip List’. (screenshot C4)

(e) The search boxes on the Trip List page need two changes:

Please change the ‘User Name’ search to a ‘Name’ Search, and The ‘Status’ search is not needed, because on the Trip List page, there is only one status for each booking request i.e. ‘Approved’. Screenshot C4

4 Two more related issues

4 (a) The ‘View Booking’ page

>> Manage Bookings

>> Edit Bookings

>> Magnifying Glass >> ‘View Booking’ page

The ‘View Booking Page’ allows a leader to overtype data, but not to save it. So the Leader’s ability to edit a Requestor’s details, e.g. to change the Requestor’s Pick-Up Address for this particular trip, is not working as required by Blue Sky:

7.2.10 A Leader should be able to update other Request information (for instance if a Requester has contacted the Leader outside the system and said they can now only take 2 passengers in their car, not 3).

However, we think it will be simpler at this stage of the project to withdraw requirement 7.2.10. I will explain to leaders in Help documentation that if they wish to, for example, note that the requestor can now only take 2 passengers, they should note that in ‘Leader Comment’.

To make it clear to the Leader that the fields on the ‘View Booking’ page cannot be edited, please use the mouse-over graphic, which presently displays if you mouse-over First Name, Last name and User Name. (Screenshot C 1 shows requested change)

4 (b) Copy-able email addresses

Blue Sky requirement:

7.3.4 Because some Leaders may prefer to send email messages to people on Request Lists or Trip Lists outside the System, the System should allow the Leader to copy to their clipboard the email addresses of the people on a Request or Trip List.

We still need this requirement. (Screenshots C2 and C3 show two options to do this)

5 Proposed workflow

The above changes will permit this simpler workflow:

1. Log in as a leader

2. Activity Management

3. Manage Bookings

4. For a particular activity, Edit Bookings

5. Add Bookings, Approve, Reject etc; Add Leader Comment; Add Bookings (Note that the System presently saves all these actions automatically, which is good)

6. Create Trip List. Opens page showing the Trip List. The System automatically saves the Trip List. This removes the present Workflow Steps 7 to 9

7. Submit Trip List

6 Reasons and comments

Proposed workflow 5 and 6. Remove button ‘Save’ from the Edit Bookings Page

Reason: all the actions available on the Edit Bookings page are automatically saved by the System, so the ‘Save’ button is redundant.

The Approve, Reject, Waitlist and Cancel actions, are saved immediately by the System. The ‘Add Leader Comment’ action, available via the magnifying glass icon, is saved by the System when the Leader ‘Submits’ the comment. Adding a booking, which is available via the Add Bookings button, is saved by the System when the Leader clicks on ‘Send Booking Request’.

Since there is no need for a ‘Save’ button, the ‘Exit without saving’ button can be renamed as ‘Back to Manage Bookings’.

Proposed workflow 7. Changes to the Trip List page.

Change title from ‘Create Trip List’ to ‘Trip List’ because the action of creating the trip list is already done

Change the search box from ‘User Name’ to ‘Name’ because Leaders will be more likely to search by a word in someone’s name, than by their User Name.

Remove the search box ‘Select Status’ because the only status on this page is Approved.

Move the buttons ‘Go to Bookings’ and ‘Download File’ to the foot of the Page, because then a Leader can find all the action buttons (except Search which is always near the top) in one place.

Change ‘Go to Bookings’ to ‘Back to Manage Bookings’ because a Leader, after creating a Trip List, is more likely to want to work on another Activity via the Manage Bookings page.

Change ‘Download File’ to ‘Download Trip List’ because its meaning is clearer.

LG 25 June 2016, revised 5 July