Home Teaching Reporting Usability Problem in 3.1.2

Discussions around using and interfacing with the Church MLS program.
TuckerHST-p40
New Member
Posts: 3
Joined: Thu Dec 17, 2009 3:37 pm
Location: Holladay, UT USA

Home Teaching Reporting Usability Problem in 3.1.2

Postby TuckerHST-p40 » Thu Dec 17, 2009 3:57 pm

I'm the HPG secretary in my ward and went to enter home teaching results for this month and was surprised to see that the form was different from prior months. Apparently, this is due to changes in 3.1.2 (from the about box: 3.1.2_16920).

Specifically, the form now displays phone numbers and email addresses for all home teachers and families (see attached screenshot - w/ids obscured).

While, IMO, this is superfluous information in a form intended to simply capture the data, the biggest problem is that _every_ companionship now requires scrolling, which is distracting enough to interfere with the thought process of transferring from paper to the screen. If I were to guesstimate, I would say it doubles the amount of time required and triples the chance of human error.

Although it may have seemed like a good idea at the time, perhaps this feature should have been left on the whiteboard? Or at least, usability tested before release?

Best wishes to the dev team.

-scott
Attachments
MLS Usability.jpg
(86.46 KiB) Downloaded 109 times

User avatar
aebrown
Community Administrator
Posts: 14693
Joined: Tue Nov 27, 2007 8:48 pm
Location: Sandy, Utah

Postby aebrown » Thu Dec 17, 2009 4:27 pm

TuckerHST wrote:the form now displays phone numbers and email addresses for all home teachers and families (see attached screenshot - w/ids obscured).
...
While, IMO, this is superfluous information in a form intended to simply capture the data, the biggest problem is that _every_ companionship now requires scrolling, which is distracting enough to interfere with the thought process of transferring from paper to the screen. If I were to guesstimate, I would say it doubles the amount of time required and triples the chance of human error.


This does seem to be a programming error. It appears that each companionship on the "Enter Home Teaching Visits" is on a separate panel, the height of which is calculated. As long as there is no e-mail address, the calculation is correct and no scroll bar is necessary. But if there is an e-mail address, the height of the panel doesn't change, but the height of the information on the panel increases, so a vertical scroll bar becomes necessary. It looks to me like all that is needed is to adjust the calculation of the panel height so that the increased row height due to the presence of an e-mail address is taken into account.

I would disagree somewhat with your claim that the information is superfluous. Some wards print this form out and HT district supervisors then use it to contact home teachers to get their home teaching reports. Having the contact information right there can be very helpful.

But you are certainly correct that requiring scrolling just to check off home teaching visits is awkward. And because some of the checkboxes are not visible unless you scroll, it's much easier to overlook one of those hidden checkboxes during data entry.

I don't think there's a problem with the feature per se, but rather the calculation of the panel height needs to be corrected as I described above. I would also note that the problem was introduced in MLS 3.1, when individual e-mail addresses were added, and the problem persists through 3.1.1 and 3.1.2.

TuckerHST-p40
New Member
Posts: 3
Joined: Thu Dec 17, 2009 3:37 pm
Location: Holladay, UT USA

Postby TuckerHST-p40 » Thu Dec 17, 2009 4:44 pm

Alan_Brown wrote:I would disagree somewhat with your claim that the information is superfluous. Some wards print this form out and HT district supervisors then use it to contact home teachers to get their home teaching reports. Having the contact information right there can be very helpful.


Well, reasonable people can disagree. I would ask you to consider that there are already two other reports to fulfill that need -- the Blank Home Teaching report, which includes the phone numbers and email addresses (exactly where you want them), and the Home Teaching Companionship report, which does not include that data (but perhaps could). We have used both those reports for manually collecting data, which we then enter into the computer.

IMO, that screen needs to accomplish its first objective well, and not worry so much about what it can also do (be printed), particularly when there are already 2 other ways to do that.

If the typical workflow was such that the screen was open while the phone calls were being made, I could be persuaded otherwise. But until MLS is a web app, HT reporting is necessarily a batch operation. You already have the data when you sit down. So it needs to be good at that, first and foremost.

Thanks for being so on top of this forum and for your thoughtful response!

-scott

User avatar
aebrown
Community Administrator
Posts: 14693
Joined: Tue Nov 27, 2007 8:48 pm
Location: Sandy, Utah

Postby aebrown » Thu Dec 17, 2009 5:15 pm

TuckerHST wrote:I would ask you to consider that there are already two other reports to fulfill that need -- the Blank Home Teaching report, which includes the phone numbers and email addresses (exactly where you want them), and the Home Teaching Companionship report, which does not include that data (but perhaps could).


That's a pretty good point. None of the reports is ideal for collecting information, however, in my opinion.

  • The Blank Home Teaching Report doesn't show the past few months visit record, yet it's helpful when gathering HT reports to see what's been happening the last few months so that the supervisor can see recent trends and include that in his discussion with the home teachers.
  • The Companionship Report solves that problem, but then doesn't include any of the contact information, which makes it less than optimal when a supervisor is in the mode of contacting home teachers to get their reports.
  • The Enter Home Teaching Visits screen solves both those issues
But only the companionship report lists the district supervisor, and none of them organize the list by district. Your only choice is to filter by each district in turn so you can print a report for each district.

TuckerHST wrote:But until MLS is a web app, HT reporting is necessarily a batch operation. You already have the data when you sit down. So it needs to be good at that, first and foremost.


I will definitely agree with that. Whatever other uses the Enter HT Visits screen may have, it should be optimized for efficient and accurate data entry.

In any case, I have reported this bug, so hopefully it can get fixed soon. Thanks for your thorough report. I know it takes extra effort to generate a screen shot (particularly when you have to redact personal information), but it's very helpful in clarifying the issue.

rmrichesjr
Community Moderators
Posts: 1038
Joined: Thu Jan 25, 2007 11:32 am
Location: Dundee, Oregon

Postby rmrichesjr » Sun Dec 20, 2009 9:35 am

Alan_Brown wrote:...

I don't think there's a problem with the feature per se, but rather the calculation of the panel height needs to be corrected as I described above. I would also note that the problem was introduced in MLS 3.1, when individual e-mail addresses were added, and the problem persists through 3.1.1 and 3.1.2.


Alan_Brown wrote:...

In any case, I have reported this bug, so hopefully it can get fixed soon. Thanks for your thorough report. I know it takes extra effort to generate a screen shot (particularly when you have to redact personal information), but it's very helpful in clarifying the issue.


Yes, many thanks to TuckerHST for the screenshot and to Alan_Brown for reporting the bug.

Rather than focusing on the matter of calculating the panel height, I would suggest that an alternative, perhaps better, solution might be to use a panel other than a scroll panel for the block representing a companionship and their assigned families. In my experience, it seems many of the Java AWT and Swing components want to do sizing from the bottom up. In MLS, the outer container being a fixed size dictates that sizing be done from the top down. Somewhere in between, that conflict makes things interesting. I would suggest that the panel representing a companionship should size itself in the vertical direction, and that using a scroll pane for it is not beneficial--just in case an MLS developer reads this thread.

This discussion has shed some light on a slightly annoying behavior I had noticed on the 'Enter HT Visits' screen. I don't remember with what version it started, but lately I had observed that the scroll wheel had no effect if the cursor was inside the panel that represents a companionship. Now, it makes sense. The inner scroll panel (with no scroll bar visible) was receiving the events that would cause scrolling, so the outer scroll panel wouldn't see them.

However the developers resolve this, let's hope we get the fix sooner rather than later. I hope it is prioritized fairly high. If it is as bad as the screenshot appears, I will probably be waiting for the fix before entering any more visits.

User avatar
aebrown
Community Administrator
Posts: 14693
Joined: Tue Nov 27, 2007 8:48 pm
Location: Sandy, Utah

Postby aebrown » Mon Dec 28, 2009 2:16 pm

Alan_Brown wrote:In any case, I have reported this bug, so hopefully it can get fixed soon.


Indeed, this was fixed very quickly -- it is no longer a problem on MLS 3.1.3. The panels are now sized correctly so that no scroll bars appear -- each panel is visible in its entirety.

russellhltn
Community Administrator
Posts: 20763
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

Postby russellhltn » Mon Dec 28, 2009 2:26 pm

Alan_Brown wrote:Indeed, this was fixed very quickly -- it is no longer a problem on MLS 3.1.3.


Pure speculation on my part, but I wonder if that's the seed for the latest problem - it doesn't handle certain display issues correctly.
Have you searched the Wiki?
Try using a Google search by adding "site:tech.lds.org/wiki" to the search criteria.

User avatar
aebrown
Community Administrator
Posts: 14693
Joined: Tue Nov 27, 2007 8:48 pm
Location: Sandy, Utah

Postby aebrown » Mon Dec 28, 2009 2:33 pm

RussellHltn wrote:Pure speculation on my part, but I wonder if that's the seed for the latest problem - it doesn't handle certain display issues correctly.


Since I discovered that the "An Error Occurred" bug is a result of division by zero (see MLSLOG.TXT), I wondered this myself. It's certainly conceivable that recalculating panel heights could involve division, and if the fix was made hastily, there might be situations where that division would be by zero.

I considered that thought to be too speculative to mention, but since you brought it up, I'll add my two cents.

russellhltn
Community Administrator
Posts: 20763
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

Postby russellhltn » Mon Dec 28, 2009 2:43 pm

My speculation is based more upon what's affected and that it seems to change for different wards. That and the fact that things usually don't break all by themselves. :) The fix might not be at fault, but it uncovered a issue with another module.
Have you searched the Wiki?

Try using a Google search by adding "site:tech.lds.org/wiki" to the search criteria.


Return to “MLS Support, Help, and Feedback”

Who is online

Users browsing this forum: No registered users and 1 guest