Element A

The robotics team at Woodrow Wilson high school is known in the region given their 2016 state

championship. Wins like this were only accomplished through dedication and hard work, and

commitment to frequent practice and meetings at school. However, accountability for presence at these

meetings has reached an unprecedented low, and an imminent problem of attendance is brewing.

Several different factors feed into the culmination of the problem. They include a lack of an

immediate reason for attendance to be taken, leading to a lack of motivation to complete it by all

involved in Robotics, and negligence to take attendance by the team members, team captains, and

advisors at each meeting.

The stakeholders in this issue are immediately apparent:

 The robotics advisors

 The robotics team members

This issue revolves around an isolated incident at Woodrow Wilson, and few others are affected

to a notable scale.

The current system in place in Woodrow Wilson robotics is nothing more than a spreadsheet to

be filled in by the advisors at each meeting detailing who is present. The issue with a system like this is

that it is too hands on and it is too much effort to be cohesive in the daily routine of robotics.

The success of the prototype was defined by a set of design criteria to test its functionality and

how it fits into the robotics environment. They included the following:

 The app must be easy to use. The total time from the beginning of the user interaction with the

system to its end must be a two second process, essentially, it should be as simple on the user

end as “click, click, done.”

  The system must be implemented into robotics as something cohesive with the work

environment. The robotics team members should not have to go out of the way to complete the

process.

 If all else fails, the system must be an improvement on the existing attendance system, which is

that the team captains input who is present at each meeting directly into a google spreadsheet.

All of this criteria is going to be dependent upon user feedback and how well they like it for its

success to be defined.

The Woodrow Wilson Robotics Team has a significant issue with accountability in their

attendance system and requires a new solution. The proposed solution was an app that could run on the

team Android tablets, where it would be a two second process for each team member to sign

themselves in at the beginning of each meeting.

The Woodrow Robotics Coalition is divided into six individual teams which compete individually,

and the members are divided amongst the six teams. The app would open on a simple landing page,

which would be little more than an icon for each of the six teams, which the member would tap to go to

a second page with the individual team members listed. Once a name is chosen, the app will redirect to

a confirmation page, and then return to the home screen of teams. For each member that signs in with

the app, the date, time, and information for each person (name, team) will be exported to a shared

Google spreadsheet which will contain the data for each log on the app.

The app, like other basic android apps was coded in Java and will be later packaged for mobile

function. The app uses a simple structure where the data (names, teams) is stored in one class, each
page pulls its functions from that class instead of reiterating the data repeatedly. The app is launched

from the main menu page and uses a dependent chain to access each subsequent class. The most

difficult challenge will be the implementation of syncing with a shared google spreadsheet, given all the

moving parts and my lack of experience.

Landing page which will be the home screen where the user can choose their team

The page which opens after a team is chosen from the main menu

This is the page which pops up after a team member chooses their name and will automatically redirect

to the main menu after five seconds.

This shared spreadsheet will auto-populate with the values taken from the app. If a team member does

not sign in, they are not included in the roster and will be counted absent.

The main process of this app development is the constant debugging and reprogramming. First,

the data class had to work. Then, the main menu display class had to work, and then it had to work with

the data class. Then the main menu class had to function together with the team display class, but now

it doesn’t sync with the data imported from the data class (I could go on). Any prototyping in a

programming project is just the constant reiteration of function figuring out what one line or missing

semicolon in hundreds of lines of code is causing the whole thing to crash.

Element H

The current solution is an app which will enable the robotics team at Woodrow to have an

effective accountability system for team attendance. The prototype Java app is in place and ready for

testing. Element H centers around how to test the effectiveness of the product, and it must meet a

certain criterion in order to be considered successful, or if another iteration of the prototype is

necessary.
 The design criteria entail all that the product must do in order to mitigate the problem at hand.

For the attendance issue, the criteria consist of the following:

 Simplicity – the app must be straightforward on the UI end of things, with minimal effort from

the user. The total user interaction with the program should be contained to five seconds or

less.

 Dynamic – the app should be flexible and adaptive based on the needs of the team. For

instance, if a new member joins the robotics team the app should compensate with a function

to add the new person.

 Above all else, the app must be an improvement upon the current system in place in Woodrow

robotics. Otherwise, what’s the point?

The main way to test the effectiveness is to get it in place within the robotics daily routine. The

week following spring break, the app will be implemented into robotics meetings preceding the

upcoming competition. After a week of testing, the results will be pulled, and the robotics team will be

polled on how well they thought the system worked. The poll will include questions such as how easy it

was to use and if the user thought they could make this a part of the daily routine, or if they had any

problem with the experience.

The main attributes of success with this app will depend on the market feedback. Satisfaction

(or lack thereof) will be the main indicator of a successful venture. If the market determines that the app

falls short, then the iterative process of prototyping will resume.

Element I
The success of the prototype was defined by a set of design criteria to test its functionality and how it

fits into the robotics environment. They included the following:

 The app must be easy to use. The total time from the beginning of the user interaction with the

system to its end must be a two second process, essentially, it should be as simple on the user

end as “click, click, done.”

 The system must be implemented into robotics as something cohesive with the work

environment. The robotics team members should not have to go out of the way to complete the

process.

 If all else fails, the system must be an improvement on the existing attendance system, which is

that the team captains input who is present at each meeting directly into a google spreadsheet.

All of this criteria is going to be dependent upon user feedback and how well they like it for its

success to be defined.

There were two intended testing plans for the app. The first was the prototyping process

testing, which mainly consisted of constructing the app and its functionality prior to implementation

with the actual robotics team. This was done in the Java IDE with consultation and advice from problem

stakeholder and local expert on app development Terry Tolleson, and this testing occurred in the weeks

preceding Spring break.

The second iteration, as discussed with stakeholder and robotics advisor Daniel Garrison was to

put it in place at each of the robotics meetings during a given week and see how well implementation

worked, if the robotics team members were satisfied with the product and if it could have a cohesive

place in the work environment. This phase of testing depended on the market feedback.

Unfortunately, due to issues with the first phase of testing, the app never made it to the market

for testing at all. Iteration after iteration was performed in the first phase of testing in a vain attempt to
build the intended functionality of the user interface of the app, as well as the behind the scenes

cohesion in connecting the program to a live google spreadsheet, all to no final avail.

This time and ability constraint forces the conclusion of testing on the current prototype. For a

solution to move forward I would need to consult with a skilled individual on the programming concept

needed to develop the intended functions for the app, namely the program interactions with a live

google spreadsheet. It is currently unclear if this process will continue.

Element J – Peer Review from Lucas Woltjen

There is a clear and straightforward explanation and description of the problem and how it is

effecting a group of people. Even though Mr. Abdo acknowledges that this is an isolated incident, he

provides clear evidence that this is a problem that is worth solving. Through Element A Mr. Abdo

explains that the problem he is choosing is in fact a problem and then proves it by providing the groups

of people that it effects. Next, he moves on to begin talking about the criteria for the prototype and

there is no evidence of previous solutions that were found in Element B. The criteria he provides

however, show meaningful thought went into identifying them to make this product a success. Although

adding an “if all else fails” seems like a bit of a lack of faith in the actuality that this project is actually

going to be completed.

Once Mr. Abdo moved into the design phase of this project more detail surfaced and an in-

depth picture of the solution in minds emerged. He wanted to create an app that would be available to

the students in the robotics classed to allow a more streamlined process for taking role at meetings,

which would in turn create more of a sense of accountability to be present. After in-depth explanation

of the prototype however, he moves on to Element H, skipping or lacking depth in Elements E and F.

In Element H Mr. Abdo provides another explanation of the project that could be taken out

because it was only a few pages before when we heard it for the first time. However, there is a clear and
concise plan to test and implement the prototype to the robotics team which allows more insight onto

how this project is going to work. Then in Element I, he provides his set of criteria again which isn’t

necessary as it was provided a page above. Besides that, the testing phases and results are clearly laid

out and it is evident that he had gone through the testing process but come up short due to time

constraints and a lack of experience in the coding field.

Overall, it is clear that Mr. Abdo has gone through the majority of the engineering design

process and come incredibly close to having a working prototype that could be implemented for its

intended use. I would have liked to see a more in-depth analysis in this document to better explain the

steps taken in this project but what was provided did the job in terms of explaining how he went about

solving the problem of attendance at robotics meetings.

Element K – personal project reflection

The project of Woodrow Robotics Attendance was not an orthodox occurrence within the

context of EDD. This project was not one that was drawn up out of inspiration. It did not have to survive

the scrutiny of elements A, B and C, and it faced no class chopping block of project voting. This project

did not have to endure the problem and solution definition of elements DEF, and therefore an

evaluation of the process cannot be done in traditional fashion.

This project was, in short, a solution handed to me on a silver platter. It came with the problem

baggage and design criteria, as it was the latest in a long line of attempts by the Robotics advisors to

have an effective method of attendance. There was little creative workaround in the solution design, as

the intended function was defined when the solution was given to me; for “click, click, done” in this

context leaves little room for interpretation.

 The initial plan was to prototype through iterations until the Robocats were satisfied with the

solution, with the main versions primarily consisting of UI changes and added functionality. However, it

soon became apparent that not even the initial intended function of the app syncing to a live google

spreadsheet would be able to be completed with my expertise in the given time frame, and therefore no

true testing was ever able to be done.

Element L – the future of the project

Despite the valiant effort put forth in the context of this project, the problem remained

unsolved. The future of this project in the broader scope of solving the problem is up to the persistence

of the stakeholders and how big of an issue they determine this to be. From there they could continue

with an app design solution, return to a solution from 2018 which would implement fingerprint sensors,

or convene something completely new.

Despite its shortcomings, I believe there is value in my product, and if someone were to follow

this project and wanted to continue where I left off, I would gladly hand over my prototype for them to

finish. There are some UI adaptations which need to be made and finally there is the behemoth issue of

the google sheet coordination. I would recommend consultation with someone familiar with practical

java applications before moving forward, and the investigation of alternative methods for making it

happen.