CS373 - Pokedex Presentation

Our slides for our presentation

Transcript

1. CS373-Pokedex Fazal Ali, Carter Boclair, Chris Lawson, Trevor Nguyen, Chris Rice
2. Reviewing: PokeDex Critiques and Notable Issues (from your friends IDB1 1)
3. Our Critique
4. What did we do well? 1. Intuitive & dense API ◦ Our API is fairly simple to use and can provide a relatively large amount of info with a single call 2. Simple & visually interesting front-end ◦ The button and color design of our pages helps keep the user-experience simple but engaging 3. Readable table design ◦ Our tables are cleanly-laid out and contain easily understood information 4. Fleshed-out sorting capabilities ◦ Our sort feature can look at essentially every metric we present to the user
5. What did we learn 1. How to create modular, reusable code ◦ We have shifted to writing code in snippets that can be moved around and re-applied to a large amount of different situations (such as our tables) 2. How to utilize tools to speed up development of said code ◦ Tools like Bootstrap and React make developing flexible and reusable code like our tables much easier by allowing things to be broken down into components 3. How to present and update tables to reduce requests and page reloading ◦ We learned to use webhooks to remove a previous design limitation where re-sorting or adjusting the table required reloading the entire page
6. What can we do better? 1. Some data is presented in a potentially confusing way ◦ For example, Mega Absol currently shows in the table as “absol-mega” ◦ This is a limitation absorbed from the API we gathered data from ◦ Resolving this would require much more bloated and “if-else”-heavy code 2. Our tables are perhaps low in visually engaging elements ◦ Our tables contain a lot of information presented in a simple and clean fashion ◦ However, all visual information related to an instance, such as what a pokemon looks like, is shown on the individual page for that instance ◦ This potentially leaves our tables as less visually-appealing than many other parts of our site
7. What puzzles us? 1. How could we refactor our code to be even more flexible? ◦ We would love to explore how much more of our code could be broken down into components to reduce file sizes and code complexity. 2. Why are some potentially useful metrics not shown/calculated? ◦ Some useful pieces of data, such as pokedex #, are not currently shown ◦ This is largely a product of project limitations and wanting to polish what is already there ◦ We would enjoy expanding range of data 3. How do we handle exceptions in our data? ◦ As mentioned before, some instances have aberrant data associated with them i. For example, some moves have no accuracy rating ◦ Typically, we just associate a reasonable default value in such case ◦ However, these may not always be the most obvious way to present such cases
8. Reviewing: Track My Candidate (from our friends IDB2)
9. Their Critique (take with a grain of salt, really) (we don’t get it) (read at your own risk) (you’re still reading?)
10. What did they do well? - Nice front page - Nice pictures - Nice copyediting - Nice idea - The about page has nice icons and good loading. - The loading spinners tell the user the data is loading, which keeps us patient.
11. What did we learn from their website - We learned about elections - We learned about politicians - We learned about bills - We learned about the political process and how elections are important.
12. What can they do better? - They can have a better continuous deployment setup to make sure the latest version of their website is deployed. - They can try to have a different presentation video. - They can try to optimize their images so the page loads faster. - API server crashes on medium to large requests - Documentation is missing attributes
13. What puzzles us about their website? - We are puzzled about how they got the nice CSS effects. - We are puzzled about their presentation video link. (see about page) - We are puzzled about what causes their website to be slow to load.