I really feel that the user stories for the projects need to be more specific. I’ve been thinking this since the Random Quote Generator. With that one, it stated “feel free to use any API or library you need”, so I initially thought, OK, maybe the purpose is to allow us the creativity to do the project any way we want.
However, I also think that there is a big difference between stifling creativity and specifying goals for the purpose of teaching something and/or making sure that the result works the way it should.
For example, with the Random Quoter, there are essentially two way you can do it. One way is to go to a quote site, copy a few dozen quotes, and build your own list. Then, for these to be presented randomly, you need to generate a random number yourself and figure out the logic to use that to present each quote randomly. The second way is to use an API that delivers the quotes to you one by one in an already random order. These approaches are really quite different and I feel that the course needs to know what it intends to teach here. If you noticed, all the projects in that section used API’s, so I’m guessing the focus here was to get people using and used to API’s. But that’s only obvious after doing three or all four of the projects. Whether the point was to get people using API’s or to generate random numbers, it should be specified. This is not limiting creativity. it’s simply telling us what the point of the project is. We can still be as creative as we want with it.
In the calculator example, I felt there should have been a few warnings. I was testing mine a lot and I believe I got all the bugs out, but there are a couple that, if I hadn’t thought of just clicking away randomly, I wouldn’t have found and thought to fix. Looking at other people’s projects, I can see that most people forgot to check for and prevent double decimals, for example. This is something I was just lucky to stumble across when clicking away randomly and realized when I saw I did that, “oh yeah, two decimals isn’t possible. Gotta fix that.” But this depends a little on luck, or, I suppose, extremely thorough analysis of every possible combination of user input. Then I started thinking about it more and started to do some real testing. I came up with a list in my post in the Project: Calculator thread of things I watched for. But as I was looking at more and more calculators, it occurred to me that these are things that most people just didn’t think about. I didn’t even think of testing until I accidentally discovered that! Most of us already have our heads stuffed with new information and are concentrating on getting the project done. It’s so easy to forget that testing should even be done and even if we do think about it, it’s hard to know how to do good thorough testing. I really strongly feel that a list of things to be careful for should be provided in the description. Things like:
- it should only accepts one decimal point
- the user should be able to change their mind when pressing operators without having to start over
- numbers should all fit into the display (no numbers cut off resulting in only half a digit being visible at the end)
IMO, this is not about creativity or letting the student “figure it out on their own”. Again, it’s just about setting some clear expectations. IMO, if any of these three points aren’t working properly, it’s a bug. Plain and simple, it’s not working the way a calculator should work. Styling and design and how to achieve these goals is still up to the student to decide so it’s not like we’re removing the burden of thinking. LOL
Throughout the course, we are presented with dozens and dozens of challenges that run a variety of tests to ensure that the function does what it should do. Why not specify the basic functional expectations in projects too?