...
Description: Traditional webapp/app for both user classes. A one-click check-in feature (one-click at minimum, more information optional) pops up on the child’s screen even if they are not within the application (push request) to remind them and give them the opportunity to check in.
...
Efficiency: One click for checking in is efficient (if no more information is requested). Being able to set a regular check-in on a schedule is efficient for the parent, not having to go to the application every time they want the child to check in. It is also efficient to be able to see all of the previous checkins done by a child on one screen. The Inefficiently. the parent needs to go to the application/website to see check-ins insead of getting them instantly on their phoneand being notified when they come in.
Safety: Need to be editing a scheduled CheckIn event to delete it prevents spurious deletions by parents. The application doesn’t make it clear to the child that his location (GPS) will be sent - this is not exactly a safety issue, but can lead the child to have an incorrect model of the system. The parent needs to go to the application/website to see check-ins, which means that they might not know that their child has already checked in (also an efficiency issue, as noted above).
Design 2
Description: Webapp/app for parent to set things, app for kid to check in, check in calls parent with recorded message. Details as in design 1 are also available on the website. There is possibly The check-in history would also differ from design 1 in having all children's histories and settings put together (interleaved). This design could include a different mode (not shown in these storyboards) where parent does not need an account, just enters own phone number, kid’s phone number, requested info, and time (or instantaneous), then gets the recorded message check-in by phone. (In this case, they would not be able to see the details on the website at a later time.)
Learnability: Similar to design 1. A parent might be woken up disturbed unintendedly by phone call if they forget that this is what the app does. It would take less effort than design 1 to learn how to navigate the feed, because there are fewer functions that the parent can performof the elimination of tabs, and the fact that all settings are in one place.
Efficiency: Efficiency for parents may be better than in design 1 because of the check-in history as a feed instead of per-child in separate tabs, so a parent who cares about all the relevant current information will not need to switch to different areas of the UI. However, it becomes more difficult for the parent to locate the information they are looking for because there is more information in the same place. This is the only way in which the UI differs from design 1 Getting a phone call with the check-in information may take longer for the parent to deal with (having to listen to a whole message instead of scanning some text), and if they don't remember everything it said, they may need to go to the website anyway, increasing the total amount of work they need to do to deal with that check-in.
Safety: Parent may miss the call telling them the check-in info, though it will still be available on the site in the mode where parents have accounts (i.e. reduces to the safety of design 1 in this case). Parent may also be disturbed while busy or woken up by the call.
...
Learnability: Child doesn’t need to learn to use a new application, and most children know how to text. Child does have to remember how to format the text message, which is fairly unnatural. If mobile app frameworks support an app starting a message with default text in it, this awkward format could be replaced with obvious places for the child to fill in information.
Efficiency: This forces the child to spend more time typing their location. Also, will be error problems because the format of the message is very specific and not used for anything else.
...