Week 16 Work NotesTuesday Apr 16
- Testing ajax calls. Adding error handling when json parsing fails, or if there is a server exception, or an Ajax timeout.
- Starting to work on the "activate card" function in js.
- Adding a progress indicator to show we're in the middle of a ajax and/or cardreader operation.
- Thinking through how to handle the removal of a card when we're in the middle of a transaction.
- Refactoring out all ajax calls into its own js-class.
- Fixing progress indicator (which stackoverflowed in IE8)
- Learning more about ActiveX exception handling when called from js.
Thursday Apr 18
- Now catching and handling all js exception with window.onerror.
- More testing of error and exception handling.
- Adding error handling for when card is removed during transaction.
- Testing and fixing validation of input fields.
- Fixing ajax timeout error handling.
- Thinking through card validity dates, and when a card is to be considered expired or empty.
Friday Apr 19
- Formatting of date and time. Trying to replicate what goes on in Java.
- Coding empty card recognition. Discover that a null end date means the card never expires. Have to change my if statements accordingly.
- The name field from the card is full of \0000. Clean!
- Enable/disable code for input fields is all wrong. Refactoring to methods into one that handles all cases.
32 hoursSummed up, I spent 32 hours working on the following:
- UI: Error handling and input validation (Ajax, ActiveX, card data)
- UI: Progress indicator
- UI: Enabling/disabling of input fields depending on state
- UI: Datetime formatting
- Business code: Recognizing empty card put onto reader
Conclusion #1I spent almost all time dealing with user interaction issues. Did I have to spend so much time with error handling and GUI stuff? I guess not. I could have skipped a lot of the error handling code and testing I wrote. I could have skipped the progress indicator. I could have trusted the user not to click buttons at the wrong moments. Basically I could have saved a lot of time.
But I didn't. Why? Because otherwise I would have ended up with a really low quality application. Software quality is all about user experience. This is conclusion #1:
- You need to pay attention to detail and invest a lot of time into UX if you want to build high quality software that makes users productive (and happy?).
Conclusions #2 and #3What if I were to estimate the time required for the tasks I completed during those four work days? Well, actually all of the tasks are sub tasks to just one user story:
- Activate Card: Make it possible to activate a new card and write name, access list, validity dates and amount to it.
- No matter how much work experince you have it is just darn difficult to understand how many small tasks are needed to get a story done.
- Your boss is not going to like it when you add four days to the schedule for just "error handling". And he's going to get the answer he wants.