The first thing I see which I do not like is the “non-fixed-width” font, which causes the timer to jump around as the numbers change.
The second thing is minor. When I click the ? button and the message box appears, you should also make it disappear when click off of it and not just rely on the X in the upper right-hand corner. Most apps these days work in this way.
Third, I can cause the timer to not function simply by clicking the speaker button one or more times. After clicking it, the start button will not start the timer.
Is this in regard to the numbers moving left and right? If so, I hadn’t noticed that before now! When you say non-fixed width font are you referring to the choice of font family or do you think it was a result of css?
I will implement this, great idea.
Oh dear, thanks for spotting this. I noticed initially you said you did play, stop, volume, stop before ascertaining the speaker was an overall problem, which is a quite specific combination Was this something that crops up often and quite methodical? I want to start spotting these issues more effectively myself. Either way thanks again, I better get back to work!
I was merely testing your app out. I was not specifically looking for problems. When there are buttons on an app I click on them to see what they do and see if they do what I expect them to do based on what seems to be their intent. I found some other issues after clicking more combinations (can not remember the order now), where the initial settings page shows and the work timer is running and I can click on the - and + buttons for break and work and it changes the timer in unpredictable ways.
It has been my experience when testing my own apps that I try to assume someone does not understand which buttons they are supposed to click first, second, third. etc… and just start clicking stuff to see if it does anything. Since you wrote the code for your app, you are probably only testing what you have designed to work instead of all the edge cases a user my attempt to do. ALWAYS assume their could be either a naive or malicious user using your app. When you are still in the designing stage of you app (before any code is written), you need to think about inputs and outputs for your app. For the inputs, you need to think about any constraints that need to be placed on those inputs (i.e. button clicks out of order, disabling/enabling buttons based another button being clicked, etc…). Most of this will come from experience just like you are getting now. You now know you must test your app not as you intend for users to use it, but how they might use it (accidentally or intentionally).
As your projects get more complex, you should look into Test Driven Development. Let’s say you are working on a project with over 100,000 lines of code (like one I have). When you make a small change to your code, you do not want to have to manually check the site for what could be messed because of your latest changes. Instead, as you are developing your project, you build tests which are automatically ran after each major change has taken place. These tests are testing things as you would normally manually test behind-the-scenes so you can be confident your changed did not break anything on your site. It is a little more work on the front-end, but once the tests are built, you don’t have to “hope” nothing broke.
This looks very useful, I’ve never enjoyed not knowing confidently what effect a change I make may have on the whole and it is a feeling I encounter often!
In my tic-tac-toe, I actually ran through a function that simulated the game by assigned the user random moves many times and output the moves when the computer lost, so I suppose I have ran into this before without realising. I really should just start applying this to everything.