Stand by whilst I climb up on my soap box...
I should preface this rant with a disclaimer. I've led an applicant development team, so I know a little bit about developing software. I wrote my first program back in 1974 -- a Moon Lander knock off which took about 45 minutes to load on my Commodore Vic 20 computer because it used a cassette tape drive (floppy disks were for the rich kids!) for long term storage.
I grew up learning procedural programming where everything is a subroutine, a data structure or a variable of some sort. Object-oriented programming is now the norm. Object-oriented programming looks at everything as an object with certain properties (so an object may process information like a subroutine, AND it may contain data like a data structure). Object-oriented programming makes sense, but it took me some time to make the adjustment from procedural (or linear) thinking. Perhaps that's the problem. I had the advantage of learning the logic behind procedural programming first... I don't know.
I do know that many of the current programmers are clueless about what it takes to create a good application. I have 2 examples (unfortunately, I can only point you to one of them because the other is behind a secure web site) which I've dealt with in the past 2 weeks.
The first is the time clock application used in the College of Engineering for submitting time sheets. It's called TimeTracker and the initial interface (the home screen) looks like this:
You can see 2 weeks, each with a green EDIT icon on the right side. When you select a day, say Monday for example, you then see this page:
This page allows you to enter a starting time and an ending time, along with a description of the work for ONE specific day. The last field is there because some employees may work for 2 or more units or projects and this allows payroll to differentiate the work accordingly. The problem is that most of us take a lunch during the normal 8-5 work day. How do you account for that? I'll tell you how the programmer(s) of TimeTracker resolved the problem. They make you enter a starting and ending time, then hit the save (or Enter) button icon... THEN you go to a separate screen to modify the hours to account for the lunch break. You then repeat this process for another 9 days (assuming MOST people work 10 days during a pay period).
As an aside, you will note on this secondary screen that it lists the day/date at the top of the box. That's because I made a request for them to add it! It used to have no day/date information, so you had to "back out" from where you were (back to the homepage) to see which days had already been modified if you got distracted during the process! To the programmer's credit, s/he also added the Tomorrow and Yesterday buttons to facilitate quicker navigation throughout the site.
Now, here's the crux of my issue. Don't most people (say 80% or more) work the same hours throughout the pay period? It seems logical to me (and more importantly, it should be very easy to verify with an experienced payroll professional) that most people work 8-5 Monday - Friday (or perhaps 11 pm - 7 am for the night shift). The point is that most people have a repeating schedule. Why make them enter the same time for each day? Let the user enter 8-12 and 1-5 as the "default schedule" and then apply that time to the days they specify. Then if the employee has an unusual day (say they work 6 am to noon on Friday) let them modify that single entry.
My point is that the programmers weren't in tune with how most of the employees need to use the application, so it's harder and more time-consuming than it needs to be.
UPDATE (14-MAR-2014): Another way to implement the desired result would be to setup a matrix which might look like this:
In this example, the gray and black cells are labels, the white cells accept user-inputs, the yellow cells are calculated by the application and refer to daily inputs, the pink cells are calculated sub-totals, and the green cells are combined totals.
(end of update)
Here's another example which you can see for yourself. The Daily Illini (DI) newspaper publishes the Grey Book information of salaried employees at the U of I. The Grey Book is a list of all salaried academic employees (not civil service nor hourly employees). The Board of Trustees publishes this information because it is considered "in the public's best interest" to show where State of Illinois tax monies are being spent. This has been published annually for many years. Several years ago the DI gained access to the information through a Freedom of Information Act request and they published it on their web site in an easy to use interface which allowed the user to search by: employee last name, the employee title, the unit paying the employee, the campus (Chicago, Springfield or CU), and the year (because the database included multiple years).
This was in invaluable tool for people researching salaries at the U of I. If you were a Manager of System Services, you could simply enter that job title in the field and limit the scope to the current year and you could easily find out what your peers were earning across the University (or individual campus). If you wanted to research a potential job opportunity, you could search by the Unit (a college or department, for example) and see how well your future colleagues were being paid. All in all, it was a pretty cool web site which allowed much greater productivity than actually going to the UI Library and sitting down with a physical copy of the Grey Book to do the research manually.
Unfortunately, the DI decided they needed to update their interface... I believe the update was to make it more "mobile friendly" for those trying to access data via their smart phones. I say this because the new interface (see here: http://salaryguide.dailyillini.com/ ) is very clean and minimalistic. Unfortunately, it is also MUCH LESS functional for the person researching jobs/positions.
Note the ONLY parameter you can now enter is a person's name (what if you don't know a person's full name, or the spelling, etc.). Once you enter the name (I used basketball coach John Groce as an example) and the interface returned a list 8 possible matches:
John Groce
<nnn> Gross
<nnn> Grove
<nnn> Gross
<nnn> Grossman
<nnn> Groves
<nnn> Grotrian
<nnn> Gronlund
I'm sure the application uses "fuzzy logic" (probably a phonetic search algorithm) to search for similar sounding names, but I really don't see a high probability of a match with those last 2 names.... oh well. Once I click on the name I want, "John Groce, Head Varsity Coach, Men's Basketball, UIUC" I am taken to a new analytics page which shows graphs of how John Groce's salary compares with the rest of the Division of Intercollegiate Athletics (he's in the top 1%) and the University (again, in the top 1%).
I contacted the Daily Illini and asked about their "upgrade" and received a nice reply back. It seems they have received a lot of comments about the new page and are now re-tooling the page. Unfortunately, she stressed that she (the editor with her name on the web page in question) was not allowed to make determinations about the functionality of the new site. I then asked her if the old functionality would be available in the new and improved upgrade... I never got a response to that inquiry. *sigh*
Why in the hell would you re-write a web site to make it more "mobile friendly" and limit its functionality so that it's barely more helpful than the hardbound edition of the Grey Book?? Words fail me...
By the way, here's how the Salary Guide interface used to look (courtesy of the WayBack Machine) on the Daily Illini web site. This is for 2011 salaries (Zook and Weber were tops on campus). I actually forgot that there was an additional parameter you could search on: salary range!
So much for the upgrade... thanks Daily Illini.
<getting down off my soap box now>
I should preface this rant with a disclaimer. I've led an applicant development team, so I know a little bit about developing software. I wrote my first program back in 1974 -- a Moon Lander knock off which took about 45 minutes to load on my Commodore Vic 20 computer because it used a cassette tape drive (floppy disks were for the rich kids!) for long term storage.
I grew up learning procedural programming where everything is a subroutine, a data structure or a variable of some sort. Object-oriented programming is now the norm. Object-oriented programming looks at everything as an object with certain properties (so an object may process information like a subroutine, AND it may contain data like a data structure). Object-oriented programming makes sense, but it took me some time to make the adjustment from procedural (or linear) thinking. Perhaps that's the problem. I had the advantage of learning the logic behind procedural programming first... I don't know.
I do know that many of the current programmers are clueless about what it takes to create a good application. I have 2 examples (unfortunately, I can only point you to one of them because the other is behind a secure web site) which I've dealt with in the past 2 weeks.
The first is the time clock application used in the College of Engineering for submitting time sheets. It's called TimeTracker and the initial interface (the home screen) looks like this:
You can see 2 weeks, each with a green EDIT icon on the right side. When you select a day, say Monday for example, you then see this page:
This page allows you to enter a starting time and an ending time, along with a description of the work for ONE specific day. The last field is there because some employees may work for 2 or more units or projects and this allows payroll to differentiate the work accordingly. The problem is that most of us take a lunch during the normal 8-5 work day. How do you account for that? I'll tell you how the programmer(s) of TimeTracker resolved the problem. They make you enter a starting and ending time, then hit the save (or Enter) button icon... THEN you go to a separate screen to modify the hours to account for the lunch break. You then repeat this process for another 9 days (assuming MOST people work 10 days during a pay period).
As an aside, you will note on this secondary screen that it lists the day/date at the top of the box. That's because I made a request for them to add it! It used to have no day/date information, so you had to "back out" from where you were (back to the homepage) to see which days had already been modified if you got distracted during the process! To the programmer's credit, s/he also added the Tomorrow and Yesterday buttons to facilitate quicker navigation throughout the site.
Now, here's the crux of my issue. Don't most people (say 80% or more) work the same hours throughout the pay period? It seems logical to me (and more importantly, it should be very easy to verify with an experienced payroll professional) that most people work 8-5 Monday - Friday (or perhaps 11 pm - 7 am for the night shift). The point is that most people have a repeating schedule. Why make them enter the same time for each day? Let the user enter 8-12 and 1-5 as the "default schedule" and then apply that time to the days they specify. Then if the employee has an unusual day (say they work 6 am to noon on Friday) let them modify that single entry.
My point is that the programmers weren't in tune with how most of the employees need to use the application, so it's harder and more time-consuming than it needs to be.
UPDATE (14-MAR-2014): Another way to implement the desired result would be to setup a matrix which might look like this:
(end of update)
Here's another example which you can see for yourself. The Daily Illini (DI) newspaper publishes the Grey Book information of salaried employees at the U of I. The Grey Book is a list of all salaried academic employees (not civil service nor hourly employees). The Board of Trustees publishes this information because it is considered "in the public's best interest" to show where State of Illinois tax monies are being spent. This has been published annually for many years. Several years ago the DI gained access to the information through a Freedom of Information Act request and they published it on their web site in an easy to use interface which allowed the user to search by: employee last name, the employee title, the unit paying the employee, the campus (Chicago, Springfield or CU), and the year (because the database included multiple years).
This was in invaluable tool for people researching salaries at the U of I. If you were a Manager of System Services, you could simply enter that job title in the field and limit the scope to the current year and you could easily find out what your peers were earning across the University (or individual campus). If you wanted to research a potential job opportunity, you could search by the Unit (a college or department, for example) and see how well your future colleagues were being paid. All in all, it was a pretty cool web site which allowed much greater productivity than actually going to the UI Library and sitting down with a physical copy of the Grey Book to do the research manually.
Unfortunately, the DI decided they needed to update their interface... I believe the update was to make it more "mobile friendly" for those trying to access data via their smart phones. I say this because the new interface (see here: http://salaryguide.dailyillini.com/ ) is very clean and minimalistic. Unfortunately, it is also MUCH LESS functional for the person researching jobs/positions.
Note the ONLY parameter you can now enter is a person's name (what if you don't know a person's full name, or the spelling, etc.). Once you enter the name (I used basketball coach John Groce as an example) and the interface returned a list 8 possible matches:
John Groce
<nnn> Gross
<nnn> Grove
<nnn> Gross
<nnn> Grossman
<nnn> Groves
<nnn> Grotrian
<nnn> Gronlund
I'm sure the application uses "fuzzy logic" (probably a phonetic search algorithm) to search for similar sounding names, but I really don't see a high probability of a match with those last 2 names.... oh well. Once I click on the name I want, "John Groce, Head Varsity Coach, Men's Basketball, UIUC" I am taken to a new analytics page which shows graphs of how John Groce's salary compares with the rest of the Division of Intercollegiate Athletics (he's in the top 1%) and the University (again, in the top 1%).
I contacted the Daily Illini and asked about their "upgrade" and received a nice reply back. It seems they have received a lot of comments about the new page and are now re-tooling the page. Unfortunately, she stressed that she (the editor with her name on the web page in question) was not allowed to make determinations about the functionality of the new site. I then asked her if the old functionality would be available in the new and improved upgrade... I never got a response to that inquiry. *sigh*
Why in the hell would you re-write a web site to make it more "mobile friendly" and limit its functionality so that it's barely more helpful than the hardbound edition of the Grey Book?? Words fail me...
By the way, here's how the Salary Guide interface used to look (courtesy of the WayBack Machine) on the Daily Illini web site. This is for 2011 salaries (Zook and Weber were tops on campus). I actually forgot that there was an additional parameter you could search on: salary range!
So much for the upgrade... thanks Daily Illini.
<getting down off my soap box now>
