UI/UX improvements

[chesterhow]

• Retain current list of people when executing commands that shouldn't toggle the people displayed (Fixes [PE-D] Always returning back to the original list #202)
  • i.e. add-date, del-meeting, add-debt should not reset the list of people back to the full list if they are currently viewing a certain group
  • Calling updateFilteredPersonList with no params will now check if there is a currentGroup to be displayed, and if so uses the appropriate predicate. Else it uses the predicate to show all persons.
• Add text wrap for long names (Fixes [PE-D] Long names do not cause text wrap and they disappear into the side #164)
• Add padding to group names in group list panel (Fixes Group list should have some padding for content #129)

[ivantjh]

Should AddCommand always return to the all person view? Should DeleteCommand still stick to the groups view?

[chesterhow]

Should AddCommand always return to the all person view?

Yes. As a user, after adding a new person, the natural intuition is to check that the new person has been added. While we have a confirmation message, it would be better to switch to the all persons view so that users can visually confirm that their new person has been added.

If they were still on the groups view, visual confirmation would not be possible as it takes another command to add the new person to the group.

Should DeleteCommand still stick to the groups view?

Yes. Similarly, after deleting a person, the natural intuition would be to verify visually, by comparing the current list of people with the previous list of people they saw. If the person is no longer there, users can rest assured that the person is deleted.

If they were initially on the groups view, with 3 people. They would expect to see a new list of 2 people. Switching them to the all persons view would throw them off slightly as they are now presented with a list of potentially more people.

[ivantjh]

lgtm!

[ivantjh]

#221 (comment) Ok thanks for the reply