3.12.2011
Although I don’t use a credit card often, I did have a balance to settle recently. While in the Chase Online account management controls, I had a need to view some activity history. While using it, I noticed a couple of usability points which I thought I would outline here as a user experience exercise:
Note that when a user selects the “Specify a date range” radio button, the “Beginning date” and “Ending date” fields are not only enabled for keyboard entry, but the red asterisk indicator is added to those field labels to remind us that these fields are now required to submit the search. Naturally, when the “All transactions available” radio button is selected instead, those red asterisks are removed because the range fields no longer apply to the user’s search.

On the other hand, I found the “valid date range” link’s location to be counter-intuitive. Shouldn’t it sit next to the “Specify a date range” text? After all, a valid date range doesn’t apply in any case where all transactions are searched.

Additionally, a fundamental ux standard is beings snubbed here with the placement of the cancel button to the right and the default-emphasised action (submit) button on the left. If the default action were something destructive as in a “Delete”, one might find this almost forgivable. However, this is not the case with searching.
3.12.2011
After building a subscription-based web application to serve clients at the small ad agency I work for, I needed to run a maintenance query against one of the database tables on some regular basis. Records needed to be deleted from the table according to the value contained within an expiration date field. ( dte_exp )
Unfortunately, the low-traffic web application is running on a shared hosting server and the host does not allow for MySQL events under shared environments. (Introduced in MySQL 5.1) So, I needed to find another way to schedule a query.
My solution was to create a cron job containing a raw SQL command like so:
mysql -h localhost -D mydbname -u myusername -pmypassword -e "DELETE from mytablename where dte_exp < NOW()"
Notice that that the password argument is the only one in this command which does not include a space.
A cron job must also contain a schedule when created. Cron schedules aren’t something I need to do frequently, so I never can seem to retain the scheme in my head. After a quick Google search and refresher, I came up with this, which says that the job should run every night 7pm. The screenshot below was taken of my web host’s account control panel once the job was created.

The net result of the query will be the removal of all rows in the table which contain an expiration date which is older than 7pm on the day the query runs.