- Wireframe for UI
- Stop users from opening the weight entry component until a user ID is chosen
- Create Delay Angular Service
- Autofocus on ID entry and weight entry text fields
- Prevent empty or incorrectly formatted input for the id-scanner component
- Keep track of User IDs in a service
- Reject duplicate ID entries
- Create Angular Service to update backend
- Create checks for edge cases on weight
- Implement methods in weight-entry component to communicate with REST API
- This implementation was completed but replaced with the “Create Angular Service to update backend” task, which was also merged with the service to keep track of User IDs; I will expand further below.
- Fix text and element scaling
As you may hope, or expect, this final sprint is where everything really came together, and we were firing on all cylinders. We had consistent communication when needed and otherwise had tasks we could work self-sufficiently on in the meantime. Our task board was positively stuffed with tasks that expressed the minute details of our process, and we managed to complete an incredible amount of their weight considering how many there were. Having spent the first sprint unsure of what tasks actually needed doing, and the second iterating on what we had created, I believe this was the moment all the building blocks fell in place; and it felt, at least personally, that tasks were clear and specific, comprised of all the things I wished to improve from the rough iterative process mentioned in the second sprint.
I think having finalized our UI design, or at least cemented the layout, allowed for easier improvement of said design. In many ways, having a finalized user flow in place made so that much of the non-style code could be refactored to store and manage information more effectively. For instance, as mentioned in the note above, I began with calling REST API to log transactions in the weight entry component where the necessary information would end up: student ID and weight. After refactoring, I broke both the storage and management of guests into a service which could be more easily accessed by any component and centralized any API calls made using guest information. This worked perfectly except for a single instance, where I needed this service to call another component. Services can be easily imported by components but sending information to a specific component from a service is more complicated. As I understand, the code I used subscribes the component I needed to speak to, to the service, which then can send a signal to that component, which in turn calls one of that component’s methods.
Regarding what did not work, it is a combination of both personal and group strategy. While we each could work effectively alone on our own independent portions, it meant that we all became intimately familiar with only one or two aspects of the project. This has especially caused problems most recently with trying to move our respective portions into Docker, as I was the only one who knew next to nothing about Docker. Therefore, I could not help my group members work on any problems my front end code may have caused. I see not keeping up with my group member’s Docker progress as a personal failing. Now both in this class and in the workforce to come, I am wishing I had this knowledge of such a powerful and seemingly common framework. Otherwise, I am very proud of the work my group members did and think given some more cross-cutting training we would be that much more of an effective team. Especially given everything that has been going on we have managed to put together a site that is nearly ready to roll out. (With the caveat, of course, that it may not be absolutely perfect but can perform all the tasks necessary).