Links for the quiz app - Robert Frazier

Robert_Frazier_Quiz_App.txt

Link for github repository: https://github.com/RobertVFrazier/Quiz-program

Link for the web page hosted on github: https://robertvfrazier.github.io/Quiz-program/

"Your feedback

This app is in pretty good shape overall, Robert. One key thing prevents it from passing, though: it's not quite mobile-friendly. Your score and question counter are cut off by 320px viewports, which is the smallest viewport we grade against. Also, keeping elements large on the whole is great, but the text of your radio labels is a bit too large at that size - things get cramped. In future apps, you might have an easier time with design if you think of your smallest screens first. Design for those small screens until the app looks good, and make incremental changes as the screen widens. You can let elements grow slightly, add columns, etc. etc. Thinking this way will prevent this pain point from getting you again."

There are three separate sets of specifications for this project:

https://courses.thinkful.com/web-dev-001v1/assignment/3.3.1
https://gist.github.com/alfaraday/c54c3504b3bb14a879428e9939f6f430#file-responsiveness-checklist-md
https://docs.google.com/spreadsheets/d/1QNzJZ6xgoaOlAxC5XPPolLYltFjOZjZeMEju7IEfkho/edit#gid=1227063358

Not one of them mentions anything about testing on an obsolete phone with a 320px viewport, much less that the project will be considered a failure if it does not work on such a phone. Before submitting this project, I did ensure that it worked on the following, in both portrait and landscape mode:

a computer screen, any widow size
Galaxy S5
Nexus 5X
Nexus 6P
iPhone 7
iPhone 7 Plus
iPhone 8
iPhone 8 Plus
iPhone X
iPad
iPad Pro
Motorola Moto G 3rd generation

That is, every mobile device emulation on Google Chrome, plus my own cell phone. This is what is asked in the second link above: "Used Chrome DevTools to simulate common mobile device viewports and confirmed that everything behaves as expected." I should have gotten credit for doing that much, even though I did not meet a criterion which was never mentioned.

"On the flow side of things: everything generally works fine, but right now, your form does not allow users to submit with the enter key, which is an expected behavior of forms."

I have that working now. Some shift-tabbing is needed, but the elements which are in focus are always indicated.

"You give clear feedback, if a little redundant. There's probably no need to repeat the question on the feedback page, but a little more context is always better than not enough context."

That is the feedback I would want when taking a quiz.

"For accessibility: mind how you use the role attribute. Which is to say, don't assign roles to everything, because this is redundant at best, and the wrong role could cause problems with assistive technologies. Stick to assigning the fallback roles for the HTML5 new-ish sectioning elements, as discussed in our lesson on accessibility in HTML. Refer back to that if you need a refresher!"

I only used the role attribute in seven places. All of them used it correctly. After reading the above, I removed all six of the role attributes I was using for the question radio buttons. The curriculum you referred me to (https://courses.thinkful.com/web-dev-001v1/assignment/1.2.5) does say to include a role="main" for the

element, so I'm leaving that one in.

"Your form structure is pretty good, but your fieldset needs a legend. The legend is there to explain the purpose of an upcoming set of form controls, so that means in this case that the legend should probably be the text of the question being asked."

Done. It made no difference to the NVDA text reader. Again, none of the three spec documents mentions anything about the legend. If it is important (and it is, as far as I can tell), it should be in the curriculum, and the project requirements should mention it.

"Your JavaScript is pretty good! It could be tidied up a bit. There are places where you .show() and .hide() a lot, and those numerous small changes to individual parts of the DOM could be batched to make fewer changes to larger parts of the DOM instead, which reduces load on the browser and would be easier to maintain. Other little things include how many individual variables you declare and then reassign later, as in the pushToQuestions function."

I have added a showCurrentPage function to handle the .hide/.show for the various pages.

"As a final note: be mindful of the project specs when you plan out your work. Your use of an API here is great, and I know that's something that was required of you in the full-time course, but it is not part of the requirements here. Going above and beyond might not seem like a bad thing, but it is important to watch how far you stray from a spec. You want to keep clients happy!"

I got permission to rework the API quiz app I did before, rather than do a simpler one from scratch.

"Focus on making this app look good on small screens and you should be good to move on, but also tackle the other notes here if you have time! I look forward to seeing your changes."

That is exactly what I did. If I had known that it would be tested on 320px viewports, I would have made it work on those before submitting it. There was no way to know about that. I did get it working great on nine different cell phone types and two iPad types, before getting it to work on a large computer monitor.