3 1/2 things I learned from deploying a small AJAX application
Tonight I finished a project for the University of Zurich which I've been working on during the last few months.
It's a web client for accessing a MySQL database, where application forms for research grants are stored. It's built atop another application I've developed earlier this year, which focuses mainly on data entry. The new client is all about processing those several hundred research grants already entered so far by applicants and features a clean, simple interface. It fetches and filters data using AJAX calls, thus reducing page load times and relying on some lazy fetching to reduce individual calls to the database. The data is then organised, sorted and analysed, providing the committee members information they need for their evaluation process.
While working on the new client, which relies on functions from the earlier application, I realised quite a few shortcomings and design flaws in the existing client.
Here's what I learned from building a new client atop the existing one, which is already up and running since January:
I did a lot of testing, including testing the user interface on different browsers running on Windows as well as OSX. Nevertheless a majority of support requests from our users had something to do with browser rendering issues, the print style sheet not working how it was intended, and other graphical glitches. Many of these calls I couldn't answer by myself, and I didn't include a feedback submit form on the web site itself, so more often than not I didn't have any information about the specific configuration on which the user had encountered his problems. That leads me to:
(1) If you have a database driven login system, why not collect all available information about the user's configuration.
I know, there's no perfectly reliable way to identify browsers and operating systems, but the majority of users out there use either Firefox or IE, and they almost certainly don't modify the user agent identification.
Submitting research proposals involves a lot of numbers. This means a lot of form fields. Developing the first client I thought it's enough to tell users not to format their numbers manually, and if they still did so, reminding them friendly with a message on screen. Many functions of the original client needed unformatted numbers in order to calculate totals, percentages and so on. I thought it wasn't necessary to perform regular expression string operations on these fields. I was wrong.
(2) Never assume users behave the way you think they should.
If your application needs data in a certain format, make sure you don't have to rely on the user entering it correctly formatted. I ended up using [^\.\d] (everything except "." and decimals), and removing everything else. Possibly I need a better search pattern (i.e. removing all non-decimals except "," and "." at the second to last position), we'll see.
In a web application, you have many possibilities about where to perform these string operations. Although I usually prefer to do such things server-side, before the data is written to the database, this time I decided to write a helper javascript function, because some of the operations are calculated client-side, and require well formatted numbers.
Another interesting and funny thing: I knew there would no more than 500 applications, a rather small user base. Considering the fact that we provide phone support every day, I thought it wouldn't be necessary to implement an automated password retrieval system. My thoughts were: "5% of 500 users forget their password over 3 months, that's not even 10 users per week, we certainly don't need a password retrieval system, just let them call and we look it up in the database." In the end, we had so many calls about forgotten logins/passwords, that I had to do a fix on the existing client and implement a simple password retrieval function. Some people even called twice during the 3 month application period.
(3) Users always forget their passwords.
Personally I use keychain for everything, I don't have to remember more than one password.
(3 1/2) Modern browsers (even everybody's darling Firefox) choke on and in connection with dynamic web pages.
Always use
s.
It's a web client for accessing a MySQL database, where application forms for research grants are stored. It's built atop another application I've developed earlier this year, which focuses mainly on data entry. The new client is all about processing those several hundred research grants already entered so far by applicants and features a clean, simple interface. It fetches and filters data using AJAX calls, thus reducing page load times and relying on some lazy fetching to reduce individual calls to the database. The data is then organised, sorted and analysed, providing the committee members information they need for their evaluation process.
While working on the new client, which relies on functions from the earlier application, I realised quite a few shortcomings and design flaws in the existing client.
Here's what I learned from building a new client atop the existing one, which is already up and running since January:
I did a lot of testing, including testing the user interface on different browsers running on Windows as well as OSX. Nevertheless a majority of support requests from our users had something to do with browser rendering issues, the print style sheet not working how it was intended, and other graphical glitches. Many of these calls I couldn't answer by myself, and I didn't include a feedback submit form on the web site itself, so more often than not I didn't have any information about the specific configuration on which the user had encountered his problems. That leads me to:
(1) If you have a database driven login system, why not collect all available information about the user's configuration.
I know, there's no perfectly reliable way to identify browsers and operating systems, but the majority of users out there use either Firefox or IE, and they almost certainly don't modify the user agent identification.
Submitting research proposals involves a lot of numbers. This means a lot of form fields. Developing the first client I thought it's enough to tell users not to format their numbers manually, and if they still did so, reminding them friendly with a message on screen. Many functions of the original client needed unformatted numbers in order to calculate totals, percentages and so on. I thought it wasn't necessary to perform regular expression string operations on these fields. I was wrong.
(2) Never assume users behave the way you think they should.
If your application needs data in a certain format, make sure you don't have to rely on the user entering it correctly formatted. I ended up using [^\.\d] (everything except "." and decimals), and removing everything else. Possibly I need a better search pattern (i.e. removing all non-decimals except "," and "." at the second to last position), we'll see.
In a web application, you have many possibilities about where to perform these string operations. Although I usually prefer to do such things server-side, before the data is written to the database, this time I decided to write a helper javascript function, because some of the operations are calculated client-side, and require well formatted numbers.
Another interesting and funny thing: I knew there would no more than 500 applications, a rather small user base. Considering the fact that we provide phone support every day, I thought it wouldn't be necessary to implement an automated password retrieval system. My thoughts were: "5% of 500 users forget their password over 3 months, that's not even 10 users per week, we certainly don't need a password retrieval system, just let them call and we look it up in the database." In the end, we had so many calls about forgotten logins/passwords, that I had to do a fix on the existing client and implement a simple password retrieval function. Some people even called twice during the 3 month application period.
(3) Users always forget their passwords.
Personally I use keychain for everything, I don't have to remember more than one password.
(3 1/2) Modern browsers (even everybody's darling Firefox) choke on and in connection with dynamic web pages.
Always use
s.