Web Indexing - divide large batches
I currently am working on a batch that will have over 1200 names extracted. With all the fields completed that will be about 9000 fields filled. This is the second time have a batch like this. Both times when I get to the 600th name the application starts to bog down. If I type too fast then the second field ends up appended to the first. For example, when I type the Surname - TAB - type Given Name, then part of the given name will be appended to the end of the surname because the application does not keep up. It is very frustrating and leads to errors.
No problems with this for smaller batches. Just when I get over 600 names.
Seems to me that if the application cannot be tuned to be more responsive to large batches, then the batches should be divided.
splitting upAlthough you did not say so, it sounds like you are working on the US—City and Business Directories projects and I suspect that you are using Table Entry mode.
These projects are notorious for causing the indexing tool to bog down, especially when working on the batches in Table Entry mode. In this mode, the larger the number of entries in the batch the slower the tool responds. I know that Table Entry mode should be ideal for working on batches where the information is presented in tabular format but it has the problem of bogging down as more entries are added. Although it may not be as convenient as Table Entry mode Form Entry mode does not seem to have the same problem with large batches.
FamilySearch has been promising for several years now to fix Table Entry mode. But so far we have seen no indication of progress toward that.
As far as a splitting the batches that would be difficult since they were generally photographed two pages per image, splitting them would require a lot of man power.1
As J C has mentioned, Form Entry mode is essentially immune to the effect of the number of records to be indexed/entries to be completed in a batch. I use it almost exclusively for that and other reasons, along with Column Entry mode when appropriate, and Table Entry Mode for QC sometimes.
Still, as I know that retired computer programmer J C also believes that with some serious programming effort (better memory management?, awareness of what actually needs to be displayed at any given time?), the engineers should be able to make a huge improvement in the responsiveness of the Table Entry mode for all-sized batches. This is important enough to tackle with priority, I believe, because the current inefficient state of that mode makes impracticable other needed improvements to Table Mode such as being able to hide and/or reorder Fields, adjust the width of Fields, and perhaps be able to fit a whole table (width-wise) on a screen at one time (“fit-to-screen”). There is no good reason why perhaps the best mode to index a type of batch needs to be rendered effectively unusable. Please fix Table Entry mode - it is worth the effort1
If we can clic up numbers of vote the engineers would probably consider Brian's idea.
Thank you for sharing your idea-0
The older computers just do not do well with the directories. As those computers are retired and replaced there will likely be fewer issues with large batch.
Table entry does cause more issues for indexers than the other forms with the directories from what I have seen. I am not fond of that method but am curious why it is preferred for some doing the directories?0
I don't do directories, partly because table entry mode is so sluggish in high record count batches and other reasons as well. but I can say that from using table entry mode on the New York Land Grant projects that it makes it much easier to spot duplicate entries and to make sure that the information is entered in the correct fields. I would imagine that being able to see the bigger picture may be one attraction for those who use it for doing directories, however its increased sluggishness as the record count rises would probably make me consider not using it if I did work on the directories projects.1
I use the column entry option when I work on the larger projects, including the NY Land Grant and the US Directories batches. I end up with a very sluggish computer at about 250 records. I wonder if the programmers can add a "every box blank" option at the end of the column, where the boxes would autofill if I click on it. Not being a programmer, it seems to me that it would be similar to the auto populated checkbox for "reviewed every record" in the reviewing mode. Seems quite silly and time-wasteful to sit here and individually fill in "blank" in every box in some of the fields, whether there is sluggish response or not. Now that I have an 800-record batch nearly done, and in the third opening of the batch due to time constraints during the other openings, I am finding that it is taking about 20-30 seconds per entry to even see the result on the screen. Thanks for talking about Form Entry mode; I'll have to see if that works for me.1
@gmacdowell, Although it is not as convenient as what you suggest would be, there are two methods that can be used to populate multiple fields with the Blank indicator. For best results either of them should be used before you start entering information into the fields. The first method is to use the keyboard shortcut or horizontal toolbar icon to Mark the entry Blank (PC: Ctrl-Shift-B, Mac: Cmd-Shift-B, 5th icon from the left on the horizontal toolbar). Do this in every entry. The second method is to use the Mark the entry Blank shortcut or toolbar icon on the first entry then use the Copy text from the selected field to all following matching fields shortcut or toolbar icon (PC: Alt-Shift-D, Mac: Option-Shift-D, 6th icon from the right on the horizontal toolbar) in every field in the entry.
Typically I use the first method when there are more fields in the entry than there are entries in the batch. When there are more records in the batch than there are fields in the entry I use the second method.
There may be reasons that FamilySearch does not want to make it too easy to mark all of the entries blank.1
it is still very inefficient, time-consuming and frustrating to use Table Entry Mode on a still-large 300-Entry or 600-Entry Directory Batch (vs a 1200-Entry one). It’s not just the loading, but every step is agonizingly slow.
Edited (thanks Jay): Try Form Entry Mode using the Ruler to keep track of where you are. I like to have the image on the left and the form on the right so that I can read the image info across left to right and index it top to bottom. It seems more natural to me. Move the form to the right side of the image using the 3 dots at the top right of the form.
Start out by rearranging the the Fields so that Directory Place and Directory Date are at the bottom if they don’t come that way. Fill them in on the first Entry (with values or Ctrl+B). Use the copy to all like fields tool (6th from the right) to propagate to all the Directory Entries in all the provided blank Entries and you’re off to the races. Just focus on the names until you run out of them. If you’ve had to add Entries beyond what was provided, go back and propagate the Directory Place and Date Fields again to be sure that all Entries get their proper values. On the other hand, if you were provided with more blank entries than you needed, then in the first unneeded Entry, re-blank the Directory Place and Directory Date Fields and use the copy to all like fields tool to blank those Fields in the remaining unneeded Entries. Then use the trashcan to Delete “all blank entries.”
You might devise an even more efficient approach for yourself, including perhaps using Column Mode part of the time. But Table Mode is just not worth the trouble for large numbers of Entries, IMO.0
John I think you meant: Try Form Entry Mode0
Thanks Jay. I sure did. I changed it.0