Ward directory generator

I hope this is the appropriate place for this; if not, please let me know.

In my ward we like to hand out printed directories. While many members are now using LDSTools and the directory on lds.org, it is still nice to have a paper directory to stick to the fridge. I wrote a custom script to generate these directories, making sure that they exactly fit on a single sheet of paper (double sided). It proved useful enough that I made it into a website for anyone to use. The intend is to make it simple and cheap enough to print out an updated directory that people will do it on a regular basis (we do it quarterly and hand it out with the sacrament meeting bulletin).

I'd love to have some feedback on it, especially from technically-minded people:

http://ward-directory.appspot.com/

It is free, without ads or anything like that. You will need a Google (gmail) account to log in. It does not store any private data, and uses your ward's directory data as exported from lds.org, so it honors individual members' privacy requests.

Feedback is welcome here, or my email address is at the bottom of the website.

Thanks,

Russ

russross wrote:You will need a Google (gmail) account to log in. It does not store any private data, and uses your ward's directory data as exported from lds.org, so it honors individual members' privacy requests.

How does it work? Isn't the user going to end up uploading data to a third party (non-church) website?

I started through the process and found that data is in fact, even though temporarily, placed on another server for processing. Because the data is manipulated on a third party server the data is exposed for capture by, well, who knows? Another problem is the presence of a "Save" feature on the site. This most definitely would violate Church restrictions for this type of data being stored on a third party server.

I would not recommend using this application for those two reasons.

The disclaimer, "For Church Use Only" does not even come close to the one provided by the LDS.ORG directory print feature. It says

For Church Use Only - Do not copy without permission from your local church leaders
Not to be Used for Any Commercial, Business, or Political Purpose
2011 Intellectual Reserve, Inc. All rights reserved
March 26, 2012

It is the LDS.ORG directory disclaimer that leads me to believe the use of this "service" would need local church leader approval before use since the data is derived from the source that this disclaimer covers.

RussellHltn wrote:How does it work? Isn't the user going to end up uploading data to a third party (non-church) website?

It is processed on a server, but the data is not saved there. It is only used to generate the PDF file, then is immediately discarded.

jdlessley wrote:I started through the process and found that data is in fact, even though temporarily, placed on another server for processing. Because the data is manipulated on a third party server the data is exposed for capture by, well, who knows? Another problem is the presence of a "Save" feature on the site. This most definitely would violate Church restrictions for this type of data being stored on a third party server.

The data is not saved on the server. The "Save" button only refers to your settings, i.e., the margin sizes and other configuration data.

jdlessley wrote:The disclaimer, "For Church Use Only" does not even come close to the one provided by the LDS.ORG directory print feature. It says It is the LDS.ORG directory disclaimer that leads me to believe the use of this "service" would need local church leader approval before use since the data is derived from the source that this disclaimer covers.

No such disclaimer is included on directories printed from MLS for ward distribution. Is this different? I agree with the need for local leader approval--I guess I assumed that part. I will add some text making that explicit. I would hope that no one would ever go printing our directories and handing them out without prior approval, so that didn't even occur to me.

Thanks for the feedback so far!

Yeah, that's still a though situation. We've been told we can't upload data to a third party server. While it's fine to you to use, since it's your server, for anyone else, it's third party.

If it was a app that ran completely on the local machine, it would be a different story.

jdlessley wrote:I started through the process and found that data is in fact, even though temporarily, placed on another server for processing. Because the data is manipulated on a third party server the data is exposed for capture by, well, who knows?

I've updated it to use HTTPS throughout, so everything is encrypted both ways.

We are not going to say it is OK or it is not OK. We are community users just like you. We are only pointing out the concerns we have come across in the past regarding sensitive information obtained from a Church source that ends up on a third party server, even if only temporarily. The risk is that you, and anyone who uses your service, place the Church at risk for compromise of protected sensitive, and even privacy protected, data for which the Church has responsibility. Some may argue that as long as the data is encrypted during transmission and not stored on the server it is fine. I personally would not engage in such an enterprise without getting approval from CHQ.

russross wrote:No such disclaimer is included on directories printed from MLS for ward distribution. Is this different?

There are no "directories printed from MLS for ward distribution." There are directories that can be printed from MLS, but nothing in MLS says that they are for distribution. Thus the "For Church use only" warning that is printed from MLS is adequate. But in Handbook 2, Section 21.1.15, we read that an additional disclaimer is required on ""published" directories: "The beginning of each directory should include a statement that it is to be used only for Church purposes and should not be copied without permission of the bishop or stake president." (emphasis added). The directory printed from LDS.org follows that directive, and all directories distributed by the ward or stake should do so as well.

Can you help me understand why you just wouldn't use the Print feature within Directory to print out a directory of members?

aebrown wrote:There are no "directories printed from MLS for ward distribution." There are directories that can be printed from MLS, but nothing in MLS says that they are for distribution. Thus the "For Church use only" warning that is printed from MLS is adequate. But in Handbook 2, Section 21.1.15, we read that an additional disclaimer is required on ""published" directories: "The beginning of each directory should include a statement that it is to be used only for Church purposes and should not be copied without permission of the bishop or stake president." (emphasis added). The directory printed from LDS.org follows that directive, and all directories distributed by the ward or stake should do so as well.

Thanks for pointing that out. I have added the "should not be copied" statement in the footer on each page.

johnsonth wrote:Can you help me understand why you just wouldn't use the Print feature within Directory to print out a directory of members?

Sure, I'll be happy to try. When I was called as clerk a few years ago, our ward had a directory of a type that seems to be common in our area. It was a booklet prepared by one of the young women for her YW project (YW recognition? I'm not too familiar with the YW program).

I was asked to update it. The old on had been prepared from scratch in a word processor. The young women diligently copied all of the data over from a printed copy she received from the clerk of the time. Needless to say, it was full of errors, and much of the data was out of date by the time it was published.

This was my starting point. I started by re-creating her work (since that was my initial assignment) by automatically extracting the data from the CSV export in MLS, generating LaTeX output, and producing a similar booklet. Actually publishing it would require a lot of work each time it was updated. The booklets would need to printed, covers prepared, and each one manually folded and stapled.

Someone suggested adopting a more compact format, so I wrote code to fit everything in a more compact form, with font sizes chosen automatically to fit onto a single sheet of paper. To make the font clear and readable, this required abbreviating some of the information. All but two households are in the same town with the same zip code, so it made sense to remove that part, leaving it only for the two exceptions. Similarly, our home phone numbers all share the 435- prefix, so removing that (but leaving it for non-435- numbers) reduced the clutter further. I also show last names for individuals only when they differ from the household surname, and show individual phone and email addresses only when they differ from the household data. By using the lds.org directory CSV data, I also made it so that it did not require special privileges and did not use data that was not already approved for directory publication.

All of these tweaks add up, in our case pushing the font size from a miserly 8.5 points or so up to a more generous 10 points. The result is a directory with all of the pertinent information, with privacy requests honored (since the data comes from lds.org), in a simple, compact format. Publishing an updated list is simple, since it is all automated, and printing it can be done easily in the library. No additional preparation is necessary to hand it out.

Most of this I did before the printable directory from lds.org was available (or at least before I knew about it). I have experimented with it, but the results undo most of the improvements in presentation that I made. My directory follows basic typographical conventions like using a serif font for printed work, and a typewriter font for email addresses. It does optimal line breaking and optimal column breaking. It also allows last-minute corrections. My brother prepares a directory for his ward (he is not a clerk), and his clerk is unresponsive to requests for corrections. Being able to fix errors before distributing the printed directory is therefore helpful.

I don't suggest that everyone abandon the lds.org directory, but rather I wanted to share my work with others who might have similar tastes. My intention was not to ruffle anyone's feathers, nor to create a controversy, but rather to share my efforts and hope that they would prove useful to others. I've been a little surprised by the cynical response I've received, but then I'm new to this forum and am not familiar with the general tone of conversation.

Thanks again for the helpful suggestions that many of you have offered, and for pointing out issues that I had not considered.

I've been a little surprised by the cynical response I've received, but then I'm new to this forum and am not familiar with the general tone of conversation.

\

The forum has hashed over the church's policy that we are not to upload data exported from MLS to third party servers. I'm not sure if this policy has been extended to data exported from lds.org. The cynicism you detect is due to the long standing nature of the church's policy and the frequency with which it is discussed on the forum.

That said, if you were to package your app into a system such as XAMPP (effectively packaging it as a local desktop app) it should then comply with current church policy as I understand it.

russross wrote:I don't suggest that everyone abandon the lds.org directory, but rather I wanted to share my work with others who might have similar tastes. My intention was not to ruffle anyone's feathers, nor to create a controversy, but rather to share my efforts and hope that they would prove useful to others. I've been a little surprised by the cynical response I've received, but then I'm new to this forum and am not familiar with the general tone of conversation.

Thanks again for the helpful suggestions that many of you have offered, and for pointing out issues that I had not considered.

Thanks for sharing! I've tested your generator and I see value in being able to create a ward list with this much information in such a compact format. What technologies are you using on the back end, if you don't mind sharing that information?

danpass wrote:Thanks for sharing! I've tested your generator and I see value in being able create a ward list with this much information in such a compact format. What technologies are you using on the back end, if you don't mind sharing that information?

I wanted to test the Google App Engine backend for the Go language. Go doesn't currently have any PDF libraries, so I ended up implementing everything from scratch (starting with Adobe's PDF spec). I also re-implemented some classic layout algorithms from TeX. The code is commented, but other than that documentation is limited. The full source is available online:

http://github.com/russross/warddirectory/

I hope to write more about how it works in the future (I am a college professor, and I enjoy teaching how things work almost as much as I enjoy making things), but for now the source code is all there is telling the story. I'm happy to answer any questions about it, though this may not be the appropriate forum for it. You can contact me through github, or my email address is on the directory website.

russross wrote:I've been a little surprised by the cynical response I've received, but then I'm new to this forum and am not familiar with the general tone of conversation.

I'm sorry you feel some of the responses appear to be cynical. The questions and statements are in the interest of protecting the Church and leaders who have the responsibility for the sensitive data in their charge. We have discussed and seen discussed many times desires by well intentioned members to use or publish sensitive data by means in which the Church can lose control of that data.

Making available membership data to leaders and members who need that data to perform callings or for other authorized purposes while at the same time protecting that data from unauthorized use or disclosure is difficult at best. Those of us who have been through the cycle many times are only trying to ensure that the need to have the data and the need to protect the data are both met.

The new directory takes into consideration many of the discussions that have occurred concerning display and printing of membership data. The desire is to reduce the need for home grown applications while providing leader and member needs for the information is continually addressed.

Once the data is out of the control of the Church then chances for compromise of privacy information or sensitive data becomes an issue. We want to make sure everyone is aware of every aspect of handling Church membership data.

There is one slight adjustment I want to note about nbflint's statement.

nbflint wrote:The forum has hashed over the church's policy that we are not to upload data exported from MLS to third party servers. I'm not sure if this policy has been extended to data exported from lds.org.

MLS membership data and the LDS.ORG directory data are for the most part one in the same. The Church policy is in regard to the membership data it has collected and in which it has the responsibility to protect and abide by the privacy desires of its members. Both MLS and the LDS.ORG directory contain data for which the Church has a legal obligation to protect.

jdlessley wrote:The new directory takes into consideration many of the discussions that have occurred concerning display and printing of membership data. The desire is to reduce the need for home grown applications while providing leader and member needs for the information is continually addressed.

I've been very pleased to see the progress in recent years on lds.org and with MLS. I certainly hope that we get to the point where home grown solutions are no longer called for. I don't think we are there yet.

I finally got an MLS export to be formatted the same as the LDS.ORG directory export so I could see the end result of your application using MLS test data. There are a few things that immediately caught my attention.

The first is that the font size was quite small to display all the data on a two sided single sheet. Whenever the font is smaller that 10 points those with vision issues may not be able to see the text. I believe my test data was printed in something close to 7 points or even smaller. I know that reducing the font is necessary to get all the data onto a single two-sided sheet. But I think this need unnecessarily restricts the output to an unreasonably small font. Large wards are going to have extremely small font sizes that even those with good vision are going to have difficulty using.

When going through the steps on the web site to generate an output, the customizing information came after the generation of the page. There was no mention that customization would even be necessary. It became obvious after the first run that some customization was necessary. But what exactly was the minimum customization needed for an acceptable output was not obvious. I would expect a page setup default that would permit generation of the directory without any customization.

My first generated directory had placeholder data. The most obvious was the display of "Your Ward Name Goes Here". Some instruction regarding customization needs to be included in the process description ahead of the generation button if there is not going to be a usable default without placeholders. People will be come frustrated if they have to make multiple tries to get what they thought they were going to get on the first try.

We have already addressed the disclaimer in previous posts. I would prefer the disclaimer to have the minimum as a default and not editable by the user - at least not allow removing the minimum as provided on the LDS.ORG directory printout. Having that much print in the header is clumsy. I would prefer the disclaimer to be in the footer similar to how it is done in the LDS.ORG printout.

As you can tell from my post in post #3 there is confusion just as to what will be saved when the "Save" button is clicked. An explanation as to what will be saved is needed.

jdlessley wrote:The first is that the font size was quite small to display all the data on a two sided single sheet. Whenever the font is smaller that 10 points those with vision issues may not be able to see the text. I believe my test data was printed in something close to 7 points or even smaller. I know that reducing the font is necessary to get all the data onto a single two-sided sheet. But I think this need unnecessarily restricts the output to an unreasonably small font. Large wards are going to have extremely small font sizes that even those with good vision are going to have difficulty using.

I had similar thoughts regarding the font size. Perhaps, Russ, you could provide an option to spread the generated directory to two pages (4 sides).

danpass wrote:I had similar thoughts regarding the font size. Perhaps, Russ, you could provide an option to spread the generated directory to two pages (4 sides).

That option does exist. It's under the "Page layout" section. You can also change the columns per page.

jdlessley wrote:The first is that the font size was quite small to display all the data on a two sided single sheet. Whenever the font is smaller that 10 points those with vision issues may not be able to see the text. I believe my test data was printed in something close to 7 points or even smaller. I know that reducing the font is necessary to get all the data onto a single two-sided sheet. But I think this need unnecessarily restricts the output to an unreasonably small font. Large wards are going to have extremely small font sizes that even those with good vision are going to have difficulty using.

For really large wards, fitting it on two pages just isn't practical. You either need to reduce the information included, or increase the number of pages. With my own ward, I was surprised how much difference it made to remove the city, state, and zip and clean up the addresses. I went from 7 or 8 points up to about 10 points, which I agree is a much nicer size. Part of that was cleaning up the records. I spent a lot of time verifying member addresses and fixing everything to the canonical spellings given by the post office. This abbreviates Street to St, Court to Ct, North to N, etc. With a clean data set, it is pretty easy to condense the listing data, which boosts the font size. Still, with a big enough ward even this won't do it, and more pages are necessary. I can't really see a way around that. For such wards, this tool may not be of much use.

jdlessley wrote:When going through the steps on the web site to generate an output, the customizing information came after the generation of the page. There was no mention that customization would even be necessary. It became obvious after the first run that some customization was necessary. But what exactly was the minimum customization needed for an acceptable output was not obvious. I would expect a page setup default that would permit generation of the directory without any customization.

My first generated directory had placeholder data. The most obvious was the display of "Your Ward Name Goes Here". Some instruction regarding customization needs to be included in the process description ahead of the generation button if there is not going to be a usable default without placeholders. People will be come frustrated if they have to make multiple tries to get what they thought they were going to get on the first try.

Most of the customization is a one-off process, and will probably require someone with reasonable technical know-how (especially using regular expressions). The generate button is at the top so that every time after that it is easy to kick out an updated version. As you can probably tell, I'm not great with the UI side of things. This really started as a project for my ward and those of my brothers, who are also quite technical. Then a colleague wanted to use it, and so on, so I tried to make it accessible. I don't see this as usable by an average person, at least not with my limited UI skills. I'll probably have another go at it at some point.

jdlessley wrote:We have already addressed the disclaimer in previous posts. I would prefer the disclaimer to have the minimum as a default and not editable by the user - at least not allow removing the minimum as provided on the LDS.ORG directory printout. Having that much print in the header is clumsy. I would prefer the disclaimer to be in the footer similar to how it is done in the LDS.ORG printout.

I agree. The current setup was a quick patch since I had omitted that text entirely at first.

jdlessley wrote:As you can tell from my post in post #3 there is confusion just as to what will be saved when the "Save" button is clicked. An explanation as to what will be saved is needed.

Another good point. I've thought about pulling all of the buttons into a sidebar or a floating button bar or something and clarifying what each does.

The biggest thing I need to address is making it downloadable so people don't have to transmit the CSV file to a server. I'm worried that if the issues you've mentioned confuse people, downloading a package will be far too much for an average user to handle (I doubt anyone reading this is of "average" technical ability--you are probably far more tech savvy even than average clerks). Hopefully I'll be able to find time to address all of these issues before too long. The end of the semester is approaching and getting anything done before summer gets harder and harder.

Our stake has used a perl script for several years to generate a printed stake directory. It takes the export data from MLS for each ward and generates pdf files using latex. I've posted a few pictures to show the output from this system.

stakedir1
stakedir2
stakedir3

Unlike the OP, we have at least 4 zip codes in our stake, and almost all wards span 2 or 3 zip codes. We have encoded the zip codes in a pretty simple way. There are 2 zip codes in Richland, so R2 is 99352, and R4 is 99354. One nice feature that this software has is an alphabetic directory of all the members in the stake. This alphabetic list simply shows which ward a person is in, so you can search by name to find the ward, then go to the ward page to get their contact information.

I didn't even know that they had added printing to the online directory until this thread, so I'll be looking at this for our next directory.

aebrown wrote:There are no "directories printed from MLS for ward distribution." There are directories that can be printed from MLS, but nothing in MLS says that they are for distribution. Thus the "For Church use only" warning that is printed from MLS is adequate. But in Handbook 2, Section 21.1.15, we read that an additional disclaimer is required on ""published" directories: "The beginning of each directory should include a statement that it is to be used only for Church purposes and should not be copied without permission of the bishop or stake president." (emphasis added). The directory printed from LDS.org follows that directive, and all directories distributed by the ward or stake should do so as well.

Publishing a directory -- as distinct from merely viewing it online or printing it -- also entails several more stringent requirements according to that same handbook provision:

Directories

Stake and ward directories may be published according to the following instructions:

Names, addresses, and phone numbers may be included in a directory only if they are listed in a commercial telephone directory or, if they are unlisted, if the member gives permission. E-mail addresses may be included only with the member’s permission. ...

Just because the "Names, addresses, and phone numbers" appear in the online directory, and printouts thereof, such condition does not satisfy those explicit requirements for being "published" in a directory. In fact, the new online directory now includes names of non-member spouses without permission from from anyone -- names that do not even appear in MLS directories without entering special records that require even more permission from the non-members themselves.

So regardless of the software used to format the directory to be published, it appears that there would have to be some process to research commercial telephone directories, and sometimes to ask someone for permission for opt-in. The software tool would have to be able to omit certain names that appear in the CSV download. Manual editing of the CSV seems error-prone.

To comply with the no-third-party-server rule, I have packaged it all up into a downloadable program. It gives you a .zip file (for Windows) or a .tar.gz file (for Linux), which unpacks into a single executable file. No additional installation is required. Just run the program, then point your browser at it and it should work like it did before, only now everything is running on your local machine. Everything is embedded in the executable: once installed it does not require an internet connection at all.

I have only tested it under Linux, since that is the only kind of machine I have. The Windows executables were generated with a cross compiler. If anyone is willing to test them and see if they work, I'd very much appreciate it.

I have also incorporated some more of the feedback I've received. The "Save" option is gone--saving settings is now automatic. Downloading and uploading have been renamed "Export settings" and "Import settings" respectively, and pushed to the bottom of the page. I hope it is somewhat clearer now than it used to be.

Once again, thanks for all of the feedback, and especially for alerting me to the rule about third-party servers.

Wow!

You've put a lot of work into this, thank you! (And thank you for making it run as a local service instead of sending data across the internet).

Something I used to do regularly was build a 2 sided PDF directory for our members using the downloaded CSV and some Excel formulas (you can see an idea of what the output looked like here (here is my .xlsx download).

Unfortunately with my setup, it required that people have MS Office and time to format it to print.

So your option seems great! I just tested with Windows 7 64bit (I downloaded the 64 bit version).

However, the one thing that I'm running into is I'm used to having names in our ward directory print with this format:

Last, First (ind. phone) & SpouseFirst (Ind. Phone), abbreviated street address

If any fields don't exist, I don't show them, for example:

Smith, Joseph (555-888-1212) & Emma, 123 Market Street

Unfortunately I can't get individual numbers to show with your program unless I show ALL family members.

Is there a way I could modify the code that is running on my local machine so I could change the logic that would allow me to show individual phone numbers even though I'm hiding all family members except the head of household and spouse?

Thanks~

Also, I just figured out substitution pairs, but I can't figure out how to delete a substitution pair if I accidentally added too many.

nathangg wrote:However, the one thing that I'm running into is I'm used to having names in our ward directory print with this format:

Last, First (ind. phone) & SpouseFirst (Ind. Phone), abbreviated street address

If any fields don't exist, I don't show them, for example:

Smith, Joseph (555-888-1212) & Emma, 123 Market Street

Unfortunately I can't get individual numbers to show with your program unless I show ALL family members.

Is there a way I could modify the code that is running on my local machine so I could change the logic that would allow me to show individual phone numbers even though I'm hiding all family members except the head of household and spouse?

The source code is written in the language Go. The full source is available here:

http://github.com/russross/warddirectory/

You are welcome to download it and customize it however you like. A warning is in order: this is the product of a fairly rapid development cycle, and the code is a bit messy in places. Full information about the Go language is available here:

http://golang.org/

It is an open source language that can be downloaded and used freely. Once you have the environment installed, the directory generator should build without any special effort.

The code you would be interested in is in families.go (you can browse it from the github site). In particular, ParseFamilies runs through the CSV data and extracts each family into a Family object (defined at the top of that same file), which includes a list of Person objects. ParseFamilies extracts exactly the data that is to be included. Then FormatFamilies processes the list of Family objects and formats it for printing.

To do what you described, you would need to limit the family members included to those found in the Couples field. The CSV data lists family members, but does not mark which ones are heads of household (unlike the MLS export data), so you'd have to work that out.

nathangg wrote:Also, I just figured out substitution pairs, but I can't figure out how to delete a substitution pair if I accidentally added too many.

Just leave it blank and it will be deleted. It won't "disappear" until your refresh the page, but any entry with a blank "Search for" part is ignored when the settings are saved.

Thanks! I'll have to take a look.

russross wrote:To do what you described, you would need to limit the family members included to those found in the Couples field. The CSV data lists family members, but does not mark which ones are heads of household (unlike the MLS export data), so you'd have to work that out.

Hmmm, I'm not sure about this... my CSV output has the following columns:


Family Name
Couple Name
Family Phone
Family Email
Family Address
Head Of House Name
Head Of House Phone
Head Of House Email
Spouse Name
Spouse Phone
Spouse Email

and then repeating:
Child Name
Child Phone
Child Email

So I think for my formatting to work, I'd just want to do the following:

[Family Name]
[Family Phone]
Right([Head of House Name],Len([Head of House Name]) - Instr(",",[Head of House Name]))
if [Head of House Phone] <> "" then [Head of House Phone] end if
if [Spouse Name] <> "" then
Right([Spouse Name],Len([Spouse Name]) - Instr(",",[Spouse Name]))
if [Spouse Phone] <> "" then [Spouse Phone] end if
end if

I'll dig into the code tomorrow (I actually worked on http://wardphotodirectory.codeplex.com/ written in C# and converted it to work with the new CSV output... although that project is now somewhat defunct and doesn't work on Windows 7 last time I checked).

THANK YOU~!

nathangg wrote:Hmmm, I'm not sure about this... my CSV output has the following columns:

(snip)

I'll dig into the code tomorrow (I actually worked on http://wardphotodirectory.codeplex.com/ written in C# and converted it to work with the new CSV output... although that project is now somewhat defunct and doesn't work on Windows 7 last time I checked).

You are right! I treat all of the family members the same, and eventually forgot that the heads of household are explicitly listed. That means the change you propose would be pretty easy. Instead of looping through all potential family members when processing the CSV file, set the loop to stop before the 11th field (where the first Child Name begins). That behavior could replace what is currently done, i.e., getting the HOHs from the Couple Name field.

It's a great suggestion, and an easy one to implement (the best kind!). I'll probably do it myself when I get a chance.

Thanks for pointing that out!

I've updated it to allow personal phone numbers and emails for the HOH couple. Unticking that box now simply omits the kids in the family.

Also, since it is no longer an online app, I have moved it off Google App Engine. Please note the new URL:

http://russross.github.com/warddirectory/

The old location just points to the new one, but it will disappear eventually.

Thanks.

jdlessley wrote:a third party server

Russ Ross must have changed it, because I just tried it out with no internet connection and it worked fine. My data was "temporarily stored" on another server. Anyone who's wary about trying it out...download the program and try it yourself. I think you did an excellent job Russ. I would hope that the team over the directory would eventually put some of your code/options into their directory so there would be more options with "printing" the directories on lds.org. Thanks for all your work.

One comment. Our ward uses photo directories. We would like a way to do photo directories that put a certain number of families on a page rather than the "by last name grouping" that lds.org/directory uses. Any thoughts? As far as I know when you export the data it doesn't include the picture. You have to use the print to pdf option to get them.

mohhess wrote:Russ Ross must have changed it, because I just tried it out with no internet connection and it worked fine.

See post #24.

russross wrote:I've updated it to allow personal phone numbers and emails for the HOH couple. Unticking that box now simply omits the kids in the family.

Also, since it is no longer an online app, I have moved it off Google App Engine. Please note the new URL:

http://russross.github.com/warddirectory/

The old location just points to the new one, but it will disappear eventually.

Thanks.

RussRoss,

I am impressed with the way you have tackled this whole process of getting a great idea, how you responded to valid concerns expressed by others, made changes to your program, made the source code available etc. Other people in similar situations would do well to learn from your example.

I couldn't help thinking about Clark Gilbert's keynote speech at the recent LDS Tech Conference when he talked about the principle of "disruptive innovation". OK this is not the new telephone but it is ideas like yours that will inspire further work on existing church products.

It is not always easy to settle in and get used to the "do's and dont's" in this forum but it is definitely worth sticking around and join in contributing to the work.

The reason I checked the "forum' today was because I wanted to find a place to express my desire for a different format than the single format lds.org provides.
. . . I want a more traditional format like my out-of-date MLS directory: Last name, first & first (no kids), next (2nd) column is ph num, and 3rd (last) column is address (house number, city, state, zip.

LDS.ORG directory "print" option needs to provide more options for "abbreviated" directories.

I created my first "computer" HT list in 1967 at Korat Royal Thai Air Force Base on the base supply Honywell 1080 supply computer using a card deck (2 copies), 1 deck for manually picking 2 home teachers, and 2nd deck being used for "families" on the HT route. Made myself a fresh HT list every month that was up-to-date at start of the month.

Made my 1st Ward Directory in 1970 using same manually organized card deck (organized into families) and rented 15 seconds of cpu time on IBM 360 Model 50 computers of insurance companies in Des Moines IA, each month and used my own box of green and white paper on their chain printers.

My brother then worked for the Presiding Bishopric (moved to SLC) and helped create the computerized membership system, which gave us our first "official" computer generated ward directories.
. . . Here we are 42 years later with the on-going glitch of ward clerks and others who are not responsive to member needs for directories, with the added twist, now, that the church programmers offer a single lds.org format which allows us to bypass the clerk and print at home, but in a format that many people don't prefer, so individual initiative is again brought into play. Thanks for your help, Russ Ross - you have done well.

russross wrote:You are right! I treat all of the family members the same, and eventually forgot that the heads of household are explicitly listed. That means the change you propose would be pretty easy. Instead of looping through all potential family members when processing the CSV file, set the loop to stop before the 11th field (where the first Child Name begins). That behavior could replace what is currently done, i.e., getting the HOHs from the Couple Name field.

It's a great suggestion, and an easy one to implement (the best kind!). I'll probably do it myself when I get a chance.

Thanks for pointing that out!

It looks like you already made this change ( THANK YOU THANK YOU THANK YOU!!! ).

However, in your instructions you state:

If you choose not to include all family members, only the heads of household will be displayed, and all personal phone numbers and email addresses will be omitted.

(and thus I thought the change hadn't been made yet).

Perhaps those instructions should say:

If you choose not to include all family members, only the heads of household will be displayed.

Thank you again for making the change (although I was a little excited about learning a new programming language )