User:Luccagenes



My name is Jim and I was born, raised, and retired in Minnesota, USA

Paternal grandparents were from the province of Lucca, Italy hence the username Luccagenes. To be specific my grandfather was from San Filippo, Lucca, Lucca, Italy which is just outside the walled city of Lucca, Lucca, Lucca, Italy. My grandmother is from Coselli, Capannori, Lucca, Italy which is a few miles south of the city of Lucca, Italy.

I can be contacted via the talk page

(until I can figure out another way)

Why am I here?
(from a novice's point of view)

My involvement here started with a GetSatisfaction suggestion which obviously no one would want to pursue (other than in discussion) so I guess it is up to the one that made the suggestion to see if it could possibly work (for reference see http://gsfn.us/t/4gkob). I am really out of my depth here and just trying to figure out how to use this wiki, all the while hoping my inexperience, in and of itself, is not going to be the cause of the downfall of this idea (if it won’t work that’s fine, just so it gets a fair shake).

Frustration in finding “help” on specific topics while using Family Tree and listening to others finding similar difficulties has led to the idea that a “centralized” place to find all types of learning aids might be a benefit to beginners and training experts alike. The bigger issue was that this “Help Central” would have to be accessible while one is in the middle of research or data entry and the answers had to be found quickly without significantly disrupting one’s current activities. Now, I realize that a “help central” is far from unique on the web but they are usually related to a small scope (e.g., a directory for a town) and provide various website links. I was looking for something more in that it had to have a specific front-end objective (easy navigation for the inexperienced and quick infallible access; “click to find”). Another specific back-end objective that was also desired was that the results themselves (the answers) had to be universally and directly accessible by sources inside the Help Central and to the outside world (possibly software programs). During all this the results had to be accessible for updating as necessary (like in wiki). Discussions led to the possibility of using this wiki (as well as the pros and cons of doing so); so anyway here we are.

Project development: Daily progress reports:
Below is the diagram that initiated this concept as well as another diagram as to how I am going to try to structure this project within WIKI. I realize this structural design may eat up a lot of WIKI pages at its maturity but one of the primary objectives is to be able to have an individual web address for each lookup “word” or "phrase" that is the subject of a help request. The ultimate goal (only speculatively assuming buy in from the software developers) would be to link each of these addresses to a “help” button in the software itself so that instant access could be achieved. When a wiki page is accessed it would display the subject word, a brief definition or description, and any and all web links that could direct the user to a source that has the answer. Presumably this could work on a multi-language level and could also work in areas outside the initial Family Tree user’s environment. Beyond the initial construction, the site maintenance should be fairly manageable because if someone develops a new training video and they want it included within the functionality of this system then they should and will make the edits themselves (obviously I’m making things up now as I have no idea how involved this project is going to be in the long run).

There is one question I’m not sure of (wish there was a “Help Central” for this wiki so I could look it up). The question relates to how the Index List page (as depicted in the diagram) is structured and the question is as follows: If someone selects a topic, such as “sources”, is there a way to display the contents of the sub-topic page that is listed under “sources” (e.g., the words tagging or creating) in a way that literally reflects the contents of the individual sub-topic page onto the “sources” page so the data does not have to be reproduced manually (and be constantly updated to match the sub-topic page)? Did that make sense? In other words, is there a type of internal wiki link that will display portions of one page onto another page so that when corrections are made to the primary page the changes will be reflected on the other page with the link? This is the last major structural issue that I haven’t figured out yet.

Anyway here we are (at least here I am, talking to myself) trying to figure out what’s next and hoping this experiment falls within the scope of what is allowed on this FamilySearch Research WIKI site. Hopefully there will be more to discuss later if I can find the fervor to pursue this to some logical and useful conclusion.

For anyone reading this (not sure how this works yet, I don't know if anyone even has access to this page) a final comment is that this project is being done on the fly so any input, corrections, or suggestions are more than welcome.

Luccagenes 17:14, 5 March 2014 (UTC)

Jump to March 6, 2014
Return to top of page

It has been a pretty good day as far as progress is concerned. I figured a way to bypass the technical issue mentioned earlier although the original "reflection" idea would be best. For now I am planning on having the grandchild subpage set up with three tables, the last of which will list all the sub-topics to each main word and they would be linked to their own pages. This would mean the user would have to click multiple times to get around but for now I'm stuck with that. As mentioned the "reflection" idea would be the best because then all the info would be seen on the first page.

I also figured out how to set up the Alphabetical lists page with the capability of being multi-lingual (if it ever comes to that). After a lot of searching I also found an article describing how to copy a page so I wrote up a bullet list of what to do and will include that info on the page template. There will only be one page that has to be repeatedly replicated (hundreds of times) and that is the grandchild sub-page. The primary page and the 5 child pages may get long but should remain relatively accessible by using the content box properly. I haven't gotten a notification that the diagrams had been received yet but here's hoping they did not get lost. All in all a long but productive day. Tomorrow will have to start getting the index and alphabetical lists started.

PS I happened to think up a truism that may be corny but actually sums up this project very nicely: "Normally it is easier to ask a question than look up an answer.  Soon it will be easier to find an answer and share it with others." God forbid that I stole a quote from someone but the mind is getting more feable so I just don't know if I heard it before.

Luccagenes 07:51, 6 March 2014 (UTC)

Apparently the terminology for what I had called "reflection" is actually called Transclusion. See article at http://www.mediawiki.org/wiki/Transclusion. I don't know if this is supported on this wiki but will have to find out before progressing too far.

Luccagenes 15:44, 6 March 2014 (UTC)

Update: remember some notes.

Note1: It appears tranclusion is supported (https://familysearch.org/learn/wiki/en/Transcluded) but is somewhat confusing so I will have to request some help when I get to that point. I'm concerned about what would happen if a continuous loop was accidentally created.

Note2: I want to include a reference to the user manual (+page number) within the first table on the grandchild pages. First table is for a description of the word, the second table will include the links to various sources (the answers), and the third is for links to other grandchild pages containing pertinent information. Transclusion would possibly be used to display the related info (non-editable) on the currently viewed page. Anyway, another thought was that I should request that the user manuals be added to wiki as their own page so that the reference to the manual could actually link the user to the actual page where the info is found rather than linking to an external PDF where the user would have to remember and then find that page. This is all assuming this project ever gets off the ground.

Note3: As mentioned I compiled a bullet list for making the grandchild page duplication but I will also have to make one for extending the individual tables within those pages (in case it becomes necessary). First of all I will have to tweak the formatting on the template page to lock the column widths and change fonts and cell and line spacing since the normal editor tool is somewhat restrictive. Using the tool you cannot select a table and add rows or change the font size without using heading settings (which will cause problems with the content box). The list goes on and on.

Luccagenes 16:58, 6 March 2014 (UTC)

Before I forget:

Note4: I've decided to use a page hierarchy (as mentioned earlier concerning the grandchild page) so here is the naming hierarchy that will be used once I start creating pages.

Parent:  Help Central: interface

Child1:  Help Central: interface/alpha      (aka: alphabetical lists)

Child2:  Help Central: interface/content   (aka: contents lists - topics)

Child3:  Help Central: interface/quick      (aka:primary documents and general links)

Child4:  Help Central: interface/FAQ        (aka: tricks of the trade and quick fixes)

Child5:  Help Central interface/image       (aka: image maps)

Grandchild: Help Central interface/alpha/(specific subject "word" or "phrase")

The specific "word" or "phrase" will be added after the backslash (omitting parenthesis or quote marks) and can be the English word or any multi-lingual word so each language could directly go to a page constructed in that desired language. The parent and child pages would require translation but they are being designed (at least trying to be designed) more on a logical (hopefully a universal) and intuitive manner to minimize user problems. The use of the content box which will show language selection options should be easy to navigate. My big concern for translation was the grandchild pages of which there eventually could be thousands, so making grandchild pages in multiple languages seems the most efficient. I will have to give this a lot more thought as it was only recently brought to my attention that translation is a major hurdle that has to be overcome in wiki (requires lots of peoplepower and this is only a one person effort).

Luccagenes 17:56, 6 March 2014 (UTC)

Just talked with support because I cannot get the images uploaded (no automatic email notification that they were received). Support stated that the wiki cite is down but since I'm typing here the question is how many wiki sites are there?

Luccagenes 21:03, 6 March 2014 (UTC)

Jump to March 7, 2014
Return to top of page

Sorry, will have to forget the diagrams. Wasted all day trying to figure it out but doesn't appear to be at my end. Oh well.

Luccagenes 01:24, 7 March 2014 (UTC)

I just realized the hardest part of this project is going to be determining how to address the keywords that will be used for the grandchild pages. Phrases such as "tagging sources" would have to be distinguished from "tagging photos" and so on. Or does one use the word "tagging" and reference that against "sources" and "photos". Will have to think about this for awhile.

Eventually the easiest method to use this system is going to be by utilizing the "image maps" of the actual pages but that can only be addressed after the "alphabetical list" is done since that is where the image map links will be directed to. The "index list" will not be as useful in the short term since it will only reference back to the user manual which is not currently accessable with links. The "general links" is easy but has been done before in different formats and the "FAQ/tricks of the trade" is something that will have to develope over time via user input. More later.

Luccagenes 05:01, 7 March 2014 (UTC)

Jump to March 8, 2014
Return to top of page

Started the slow job of figuring out the keywords and phrases. Copied the contents from the manual so will also have to figure out the topics (multiple keywords) too. For reference, here are a few links I will need shortly and do not want to loose (since there is not a HelpCentral for this wiki ...yet!

Table modifications: https://beta.familysearch.org/learn/wiki/en/Help:Table

Advanced Linking: https://familysearch.org/learn/wiki/en/Help:Advanced_Linking

Luccagenes 12:40, 8 March 2014 (UTC)

A question for later: Would it be possible for the users to rate (rank) the results. For example, if 4 links to various sources of the answer are displayed for the keyword "sources" is there a way to rank the usefullness of the links (good, better, best). Over the long term this would have 2 effects; first a new user would know where to look first, and secondly, developers of say video instructions would want their ranking high so better videos may get made. Will have to get back to this idea later.

Luccagenes 13:13, 8 March 2014 (UTC)

Finally got access back to FamilySearch. It appears there was a corrupt cookie related to my log in which resulted in a Bad Request error. Removed all the FS cookies and now things are fine again.

Other suggestions to keep in mind.

Add a "Quick Review" to the Tricks of the Trade section that would basically interact with the image maps so that learning the software could be done in a half hour; instead of reading a 200 page user manual.

Could also add some slideshow videos of actual pages that explain the software.

In reading GetSatisfaction today also noticed that many good ideas (tricks) and explainations of using the software too quickly get "filed" into the archives (scrolled out of view) and may help a few that are reading them but there has to be a way to log these into this system.

https://familysearch.org/learn/wiki/en/User:Fritty/sandbox/this_is_the_place. This is someone's sandbox related to using Family Tree software (user:Fritty). They have it listed under the category: "FamilySearch Family Tree Training" which does appear to exist and would be a good category eventually for the "Help Central" idea. Since they are still working on it in their sandbox (not done yet) and that wiki article is a list of training aid references and the like, I can therefore make the assumption that this idea does fit into the scope of the Research Wiki's goals. This reference will also be a good starting point for adding links as it appears to thoroughly cover all types of source material located outside of this wiki.

Luccagenes 23:06, 8 March 2014 (UTC)

Jump to March 9, 2014
Return to top of page

It is probably a mute point but I think I should add another layer to the page structure. The initial interface page should be left accessible so if other types of formats (other than a Family Tree software guide) are desirable there would be a place to attach them. Highly unlikely at this point but to restructure after the fact would be a nightmare. Better safe than sorry.

Parent:         HelpCentral:Interface

Child1:         HelpCentral:Interface/FamilyTree

Grandchild1: HelpCentral:Interface/FamilyTree/Index                (aka: alphabetical lists)

Grandchild2: HelpCentral:Interface/FamilyTree/Contents           (aka: topics)

Grandchild3: HelpCentral:Interface/FamilyTree/Library              (aka: general links)

Grandchild4: HelpCentral:Interface/FamilyTree/Collection          (aka: miscellaneous)

Grandchild5: HelpCentral:Interface/FamilyTree/Atlas                 (aka: image maps)

GreatGrandchild: HelpCentral:Interface/FamilyTree/Index/(specific subject "word" or "phrase")

Luccagenes 07:17, 9 March 2014 (UTC)

By the way, last night I did notice that a comment was left on the Talk page and it is appreciated (I will have to watch what I say here). This project has always relied on the eventual help from others at this wiki if it is to be successful but my job for now is to figure out a workable system so it is easier to get "buy in" from the community at large. Not saying I have to make the design perfect as I'm sure it will be optimized along the way (if successful) but I do have to make and prove it can be a functional system otherwise it would be just another pie-in-the-sky suggestion. So far the structure looks doable and promising so then it will just be a question as to whether or not this concept will work. In all likelyhood the original suggestion (at GetSatisfaction) will be hard to accomplish because the buy in from software developers will be a hard sell but it appears the idea of a Help Central could stand on its own feet and still be quite useful and successful.

I am still working on the keyword list (this will take a while) but I am also putting the finishing touches on the individual page designs in powerpoint before I actually start making the pages in the sandbox. I want to make sure they blend together and compliment each other while still remaining as simple as possible so that navigation through the system will hopefully require little or no language translation.

Luccagenes 15:49, 9 March 2014 (UTC)

Misc NOTE: I've been worried about how to get different languages to work in the Hep Central system but I forgot about two of them. How does one incorporate Sign language for the deaf and "audio" for the blind. After all, if this is supposed to provide universal access then all groups must be included. Maybe I am over thinking this. Just putting a note here so I don't forget about it.

Have been experimenting with Excel to see how the keywords list can be logged so they can be put in alphabetical order while still allowing them to be cut and pasted into the wiki editor tool. This will make it easier to input the initial data but may also be useful for adding different language tables since after translation they too will have to be re-sorted. If I figure out a good method it should be added to the template page as a bullet list. Review Wikipedia article on (http://en.wikipedia.org/wiki/Alphabetize) to help determine the alphabetical Table sizes that are going to be needed. Will this project ever be over?

Also have a curiosity question (although it is premature at this point) but is there a way to acknowledge contributors who eventually buy in to this project? Userboxes can only be used on the userpage (which is good) but is there something like a userbox that could acknowledge the contributor's involvement that could be put on an article page and possible (if desired by the contributor) have a link to their user page? Not so much as a byline but more as a link to others assisting with the project. I was thinking that at the bottom of the initial Help Central interface page (the parent page) that a list of contributors and the speciality (e.g., a foreign language) might be useful and rewarding. Check out (https://familysearch.org/learn/wiki/en/Template:Featured_Article) to see if this would work. The bigger question is that I am not sure what the policy is or if that type of thing is frowned upon. Check on this some more.

Luccagenes 19:44, 9 March 2014 (UTC)

Linda, Thanks for the link to the HTML lessons; I had not found that yet. It has been 15 - 20 years since I last used HTML for a website but the side by side with the Wikitext really makes it easy. Thanks again.

Luccagenes 23:47, 9 March 2014 (UTC)

Jump to March 10, 2014
Return to top of page

I submitted a help request to the FamilySearch help center to figure out why I cannot upload images (I could not find a specific help link for wiki support at the wiki site). I can upload okay to the Photos section in Family Tree but not to the wiki so I think it is a problem with my wiki account as my display name does not display correctly. Here's hoping this can be fixed.

Still plugging along with the keyword indentification and the wikitext coursework but all in all, I'm still optimistic that this project will work but I'm getting anxious to finally see the light at the end of the tunnel. It feels like I have been working on this for weeks but after I added the jump dates for the content box I realized it has only been 5 days. When will it end?

I figured out how to add additional pages to my sandbox (you know a HelpCentral project on wiki help files would have made that easier). I can now start to create the individual pages that will be needed: the parent page, the initial child page, the grandchildren pages, and the great grandchild template page. I am also glad I decided to keep the initial interface page as a general access point so that other possible future projects (like a wiki help files project) could be initiated from there without the need to restructure the page hierarchy.

Just had another thought so here is a quick note to remind me. It might also be useful if on the keyword page (the great grandchild) there was a fourth table added for each keyword that included FAQs. This way the user could check out an actual question instead of just searching for the subject to the question. At this point I am not sure if the FAQ should be entered there and then linked to the Misc section which would also contain a FAQ section (or vice versa). I will have to study the logistics of doing it either way to determine which way is most efficient as far as the linking capabilities are concerned.

Luccagenes 15:38, 10 March 2014 (UTC)

Jump to March 11, 2014
Return to top of page

Two techinical notes that I have to check on.

First, once the pages are created is it possible to put a copy of each type of page somewhere and partially lock them so that only copies can be made or only supervised editing (with concensus) is allowed so the originals do not become lost or damaged.

Secondly, it is more a curiosity question but since this project will need a lot of help to put some flesh on the bones, what happens if two people are editing the same page at the same time? Is this possible or are there safeguards that prevent a page from being opened for editing by multiple users at one time? Will have to check on this.

I finished the wikitext course and got some good ideas of things to do but the capability of the sortable table (for alphabetizing) won't work as it is actually a sort button that will alphabitize but only when the button is triggered each time after which it resorts to the original data set upon exiting. But not to fear because I did notice the table edit options are more extensive than I first thought so rows can be easily added during editing and if one thinks about it the only one that alphabetizing is going to be an issue for is me during the initial input but I can do that in excel. The rest of the time when new keywords are added (probably one at a time) the editor will just have to make sure they are entered at the correct position. Not a big deal.

I also came up with a nifty way (do people still say nifty?) to navigate the column containing the alphabetized keywords. After each of the cells that contain the headings (A,B,C,...) I will put a row that contains the whole alphabet with each letter linked (using anchors) to the appropriate heading letter so it is easy to navigate up and down the column. I'm sure this would be a big complaint if people had to scroll a significant amount of the time. In fact I should put a return to top of page button on this page.

Note: also remember to add an asterisk after the general topic keywords (like Photos) to indicate that some pages are "Special" in that they are trancluded and will display information from other pages directly on their page. This should help minimize the need for the user to bump back and forth from page to page when the keyword is more general in nature and encompass many different but related pages.

Tomorrow I should be ready to start making one of the official pages. Here's hoping that this goes easily.

PS Make that three technical notes: Is there a "restore" function or are backup copies saved somewhere for this wiki? What happens if someone accidently deletes a section from a page and then saves it; is the data gone forever? Can it be restored? I know, now I'm getting paranoid but what if?

Luccagenes 05:11, 11 March 2014 (UTC)

Jump to March 12, 2014
Return to top of page

Now, again, I think I'm ready to start constructioning some actual test pages to use as the templates. Had a few more tweaks to fingure out yesterday. Some minor name changes to the hierarchy pages to better identity their function (i.e., The Index, The Contents, The Library, The Collection, and The Atlas) since this will be the last chance to change them. Figured out how to do the specific wikitext coding I will need to copy into the edit box and have decided that besides a fourth input box on the great grandchild page for FAQs there should be a fifth box for Misc. (a "for stuff I don't know where to put anywhere else" box).

There is still one nagging subject I really want to get a handle on. How will I know if a page is still "blank" or has missing data, like I said before there will be hundreds of pages so how would the "administrators" know if something is missing, other than tediously searching through each and every page? Have to find an answer to that question. I suppose a complimentary question would be: how does one know which pages are up-to-date? Just thinking long term here on how to monitor the system to make sure it stays "relevent".

PS I added a jump to "Top of page" below.

Also, just got support to get picture uploads approved (after 29 submissions for two pictures and 2 help center requests). I have to submit the HelpCentral logo next, hope it makes it through the first time.

Luccagenes 14:31, 12 March 2014 (UTC)

Jump to March 13, 2014
Return to top of page

Although the Interface page is the simplest it probably caused the most problems. I tried to get three table to "float" in wikitext but it didn't behave right (probably because I did not know how to program it correctly). Had to settle for two tables floating side by side which is acceptable because that is all I will need for the language alphabetical tables when I get that far. Anyway, page one is almost done;. just waiting for the logo picture to get approved then that can be put in and then change the link when the next page is done. It can be found at https://familysearch.org/learn/wiki/en/User:Luccagenes/Sandbox/Interface#Top

Luccagenes 01:33, 13 March 2014 (UTC)

Worked the coding bugs out of page two although apparently I cannot link using a Sandbox address so the individual address is https://familysearch.org/learn/wiki/en/User:Luccagenes/Sandbox/Interface/FamilyTree.

Note: remember to check the displays on Internet Explorer, Google Chrome, and others (I am using Firefox exclusively).

Luccagenes 05:52, 13 March 2014 (UTC)

Jump to March 14, 2014
Return to top of page

Working on page 3, the index (alphabetical) list page, and I'm getting frustrated each time I run into a coding problem. I cannot put two tables next to each other because unless they are exactly the same size the display goes haywire and changes to the fonts are constantly messing up the table (this is where programming experience would be useful). I cannot find a Yahoo search that gives instructions specifically for the wikitext language since there are umpteen versions out there all with their special nuances (the course lessons on the wiki are useful but just too general since I have not seen any pages set up this way; I will work through it somehow since this does not need to be perfect, just functional).

I'm still not worried that this design will work but I'm starting to worry if its acceptance by the community will be too difficult to overcome. Not just with the wiki community that would have to help fill in the answer spaces, but also with the software employees who already indicated some resistance and then there is the user community at large who once exposed to the barebones package might loose patience waiting for it to reach maturity. Anyway, so much for my state of depression. They cannot reject it if there is nothing to reject, so back to work. It's time to distract myself with some good old coding problems. On a positive note, I am getting more comfortable switching between editiors and using the wikitext (see, this project may be driving me crazy but there is a silver lining).

Update: As it turns out the wikitext is awfully finicky in that the parameters for the table cell not only have to be grouped properly but they have to be in a certain order or they get kicked out. Making some progress.

Misc note: as you can see I finally got the images uploaded. It turns out that the automatic email notification has been turned off (or lost with a recent upgrade) and nobody knew about it.That is why I sent ~30 copies because the instructions said if you do not get that notification then the image is lost. Corrections to the instructions have been made by support to remove that notice and hopefully future confusion.

Luccagenes 14:51, 14 March 2014 (UTC)

Thank God! Page 3 is looking pretty good (https://familysearch.org/learn/wiki/en/User:Luccagenes/Sandbox/Interface/FamilyTree/Index). Worked out the alphabetical table format and thank God, when you add a row (above or below) using the simple editor the program copies all the parameters to the new row. This will make it easy for the editors to add keywords to the existing framework. I was afraid they would have to go into wikitext to make the changes. Looking good! So far the only time anyone will have to go into wikitext is when a new page is created (copy "all" from template to new page) or when a new language table has to be added (that is manageable). Also found that the fonts were being directed to the top of the cell because the "vertical-align:middle" parameter was missing from "style=" even though the "valign=bottom" was present in the same line. Who knew. Just have to entend the table for each letter of the alphabet, figure out how to set anchors to make navigating the table (the long table) easier, and then it can be copied as a whole for the other languages.

Linda, thanks for your last posting, good to know. By the way, I think I am going to forget about putting the two tables side-by-side since while working on it (full column width) I realized that I should leave it that way so that larger text could be used for the keywords. For some people using Family Tree there could be visual issues and it would be better to have the text too large rather than too small.

Luccagenes 20:04, 14 March 2014 (UTC)

Jump to March 15, 2014
Return to top of page

Technical Obstacle:

Before I get too involved in the modifications. Manually including an anchor seems to be straight forward but may get complicated once duplicate tables are made for other languages. I should have no problem installing the anchors to the section (the table row) by using |-id="name" but when making a duplicate table using copy and paste there will also be a duplicate section name which is not allowed when using anchors.

I could identify the row name for the letter "A" as "English Letter A" but that would require that who ever is making the duplicate has to go into wikitext and change 26+ names manually (e.g., from "English Letter A" to "Spanish Letter A"). No, (I wrote "No" but that is not what I said.) this won't work because it is not 26 times but rather 26+(26 x 26) times because each of the 26 links in the next row are calling their specific name "English Letter ?" too. The only idea I have right now is if a variable can be set up within the table itself to change the 26+(26 x 26) entries at some access point in the table (i.e., the variable equals the language name so changing "English" to "Spanish" will automatically change all the entries, therefore the anchor name would have to be "variable Letter A"). I will keep looking but if anyone has a suggestion for page 3 for allowing the user to navigate up and down the table, it would be appreciated. Maybe a totally different strategy. I will check out the variable option first. Definitely a future obstacle.

PS these UTC times are starting to rattle the brain. Here is is tomorrow already.

Luccagenes 00:55, 15 March 2014 (UTC)

In the HTML lessons you can scroll horizontally but I would need a vertical scroll and coould't find code to get that done. No luck on the "variable" idea either. What I would need is something like in Excel where you display the contents of one cell as a value in another place (not sure what that is called) but the markup language probably cannot handle that either. Will keep looking but in thinking about it it would not be 26+(26 x 26) it would only (ONLY) be 26 + 26 because each of the section names would have to be changed but only one of the A-Z rows (26 links) would require modification and then could be copied and pasted the rest of the way. Still doable if I cannot find another way.

Update: I take it all back, I found a vertical scroll bar on the Internet. Appears to work fine so I can eliminate the A-Z rows. Copying the template should no longer be a problem.

Internet example:

&lt;div style="height: 400px; overflow: auto;"&gt; &lt;!-- Html Elements --!&gt; &lt;/div&gt;

Example used in the wiki lesson is:

&lt;div style="border: 2px solid rgb(221, 221, 221); overflow-y: hidden; overflow-x: auto; padding: 0.2em; width: 99%;" id="imageContainer"&gt; {| cellspacing="1" cellpadding="10" border="1" width="1000"

Luccagenes 03:59, 15 March 2014 (UTC)

The Internet example works but cannot get the width set yet as it trucates the side of the table (I could always shrink the table a little bit). Cannot get the lesson example working yet with the x and y designations but will try some more tomorrow. I should have realized that this was doable because I am looking right at it; the editor is scrolling the text.

Another internet example (wikipedia)

&lt;div style="width: 75%; height:10em; overflow:auto; border: 2px solid #088"&gt; {| style="width: 75%; height: 200px" border="1" |- | abc || def || ghi |- style="height: 100px;" | jkl || style="width: 200px;" | mno || pqr |- | stu || vwx || yz |} &lt;/div&gt;

Luccagenes 04:59, 15 March 2014 (UTC).

Saw a nice example of a map interacting with a table on the Wikipedia site so will try to incorporate something similar for the index table access. Will use an A-Z box so clicking on a letter will advance the table to the appropriate spot (https://familysearch.org/learn/wiki/en/User:Luccagenes/Sandbox/Interface/FamilyTree/Index). This should combine several previous ideas to give very rapid access to the long index lists. Just have to get the scroll box working, add the section anchors, and link the two together. It is starting to become a functional system. Have made initial page creation for The Contents page, The Library page, The Collections page, The Atlas page, and the keyword template page but will work on these little by little.

Luccagenes 16:37, 15 March 2014 (UTC)

Added the sentence "The 5 Click Rule: Your answer should be less than 5 clicks away" to the interface page. This should be the primary objective (philosophy) for this system when information is added. Get the users the answer ASAP! Note: each subsequent page will count down the number of clicks (e.g., The next page will say "The 5 Click Rule: Your answer should be less than 4 clicks away".

Update: When I mentioned the 5 click rule to my daughter, her comment was "that's better than 6 degrees of separation" so I will add that to the site too.

Luccagenes 18:04, 15 March 2014 (UTC)

Jump to March 16, 2014
Return to top of page

Could not get anything accomplished yesterday – nothing was working for me. Surprising what a good night’s sleep and fresh eyes can accomplish. Already this morning I have gotten the scroll box to work and it looks good and will be excellent for navigating the index table (https://familysearch.org/learn/wiki/en/User:Luccagenes/Sandbox/Interface/FamilyTree/Index). Figured out how to make the internal links within the same page work using a section id=name at each alphabet row and calling it up with text ; still haven’t figured out how to manually link using the rich editor anchor icon as I cannot find the counterpart to it (how to make the link, except in wikitext). The previously mentioned example of the map at Wikipedia that linked to a table is nice and I can use something like that when the image maps get created (a much later project). I had gotten the links to work using a horizontal a-z list in a table row above the scroll box but a slight problem occurs in that when you hit the link to adjust the table position what it actually does is bring that selected row position to the top of the "display" which in turn moves the link box out of view (this would require constant readjusting for the user; unacceptable). I looked at using a sidebar for the a-z links but that started getting too complicated because the sidebar is a template and could be manipulated from outside the page. Then I thought, keep it simple stupid (see what happens with fresh eyes), so then I decided just to make a vertical a-z table for the links and float it to the left with the scroll table floated right (see Linda, eventually we would get back to the side by side tables). Looks okay as it will remain in place when the link resets the scroll table to the top of the display; a lot of this work is turning out to be just trial and error and I don’t know if that is because I’m trying weird things (which are hopefully okay with the wiki authorities) or if it is because I obviously don’t know what I'm doing.

Misc note: I changed the colors of the keywords in the index list to a lighter color (grey) so that the contributors and users have a better distinction as to which keywords have been linked or not. Hopefully that change will make it easier to quickly identify uncompleted areas

The trial and error approach for coding these pages is time consuming. Without experience the only way I could get the float on a scroll to work was to put a &lt;div&gt; inside a &lt;div&gt; which the program then rewrote but left two &lt;div style= commands in the same row. It is working but I’m afraid someone will eventually correct it and possible throw everything off. There are probably a lot of things I’m doing wrong so I also have to remember to check and see how these displays are working in browsers other than Firefox.

Fresh eyes have also discovered that mélange is not a good thing (according to Wikipedia) and nested tables should be avoided. I will have to go into the wikitext and remove the outer table on the keyword template page. It looks nice now but will work just as easily without it and that should remove any confusion by someone editing the table as to which table they are actually editing. The reason it was initially include (it wasn't due to aesthetics) was that I anticipated that multiple language sections could potentially reside on the same page and the nested boxes would keep them separate. But that leads into a bigger question related to languages.

Question concerning the alternative languages: I have absolutely no reference point to ever make such a decision but I have to ask the question. Would it be better to have translations done in the conventional way (the whole page translated from English to say Spanish) or to direct the contributors to actually create parallel keyword pages in that other language (or add parallel information sections in the same page)? For example: Since an alternative alphabetical index list for each language should be available anyway (to adjust for different alphabets and to resort based on that alphabet) should those links on the Spanish index list be directed (linked) to the translated English version of the keyword page or should the main keyword page include a Spanish section covering the same information. Alternatively, should the Spanish index list be directed to a parallel keyword page that was originally created in Spanish (which in turn would probably need a translation back to English)? I don’t know if I am explaining myself well but the point is that any of these three alternatives could get messy. I was wondering if anyone would have a feel as to which way would most benefit the wiki (less translation) as well being a benefit for the users ( translated information or information originally written in that language). I could speculate on this and how best to present it in the pages but others must have a better feel for something like this.

Update: here is a little extra food for thought on the last question. An assumption has to be made, if this project just happens to be unexpectedly successful, will the English version be the primary language which would then have to be translated into multiple languages OR could Help Central be the centralized "structure" wherein all languages could then find their own niche within that structure (no translations would be required). My vote is for the latter.

Luccagenes 19:43, 16 March 2014 (UTC)

Jump to March 17, 2014
Return to top of page

Have to do a little tweaking on a lot of the pages (only 7 test pages) and have started to add some info so one can get the “feel” of how the system might work. The index scroll table really turned out nicely so I added just a few keywords to the list (under “A” and “P”). The daily progress reports may be intermittent from now on as it is just a matter of adding some substance (putting some meat on the bones) to the system in order to get a basic functional version available for internal evaluation (obviously it is still a couple weeks away from being set loose on the public).

Apparently I cannot make an internal link to a sandbox related page so I have made the links through an external link so the progression through the pages can be experienced (I better remember to change those links after the pages are created in the mainspace). I’ve added a link to the keyword template to the first listing in the Index (just as an example link). Here is the link to the initial Help Central interface page: https://familysearch.org/learn/wiki/en/User:Luccagenes/Sandbox/Interface

Remember that the index table contains a list of all possible versions of the same “question” in the form of complex keywords (e.g., adding photos) which will have two forms: “adding photos” and “Photos (adding)”. Some may even have three or more forms but even though this will make the index list very long (but thorough), it will not increase the number of keyword pages since all of those forms of a complex keyword will be linked to the same keyword page.

And just a note, I far as I can envision minor changes in the real world (e.g., an updated user manual) should not have a significant effect on the system other than new links to new material will have to be made; the old links to a different version can still remain (although obviously outdated). For this Family Tree example, only a dramatic real world scenario like changing from the NewFamilySearch program to the FamilySearch Family Tree program would impact this particular section of a Help Central system. In that particular case a new section would have to be initiated for the new program. I have designed "The Contents" page to act as a monitor (quick visual indicator) of when new features or new revisions to the software become available after beta testing; a contributor need only add a date to the appropriate topic area that has changed (or create a new area and date it) and then possibly supply a link to the new information keyword page or possibly to an article written in the wiki. If anyone can think of a worst case scenario that might falter the system, please let me know.

Luccagenes 19:23, 17 March 2014 (UTC)

Jump to March 18, 2014
Return to top of page

Added the "Objective" section below showing a list of project objectives which were accomplished (some were inherently a part of the wiki environment). The only one left to do is to get a "last revisions" date put on the index list for each keyword as a visual indicator as to if the information is current or not. I believe this is done using templates so I will have to study this a bit. I can display the revision date on each keyword page and then have it transcluded behind the keyword, hopefully.

Also added a small table to each of the Help Central pages which will allow for easy navigation back and forth to any of the other Help Central pages.

Luccagenes 19:02, 18 March 2014 (UTC)

Finally got the transclusion to work (apparently you cannot use capital letters when naming the section). Again, who knew. Anyway, now I can add a second column to the index list which will be used to display the last revision date of the particular keyword’s page. This is the only way I can think of to get a visual indicator for the editors to keep an eye on whether the page is becoming out of date (although it tells nothing of the relevancy of the information on that page) but a least it is a means to do a quick scan of the long index list. Note: remember to add a note to users to ignore the date as it is for editors only.

Since the selective transclusion appears to work nicely, this will also work when I want to evaluate transcluding the FAQ sections from each keyword page (multiple transclusions from the same page) and put them into a FAQ section in “The Collection” page. Then the user can view the specific FAQ on the keyword page (where the editors should enter them) or they can be viewed as a group on the Collections page

That was the last major hurdle so it appears all the objectives are now met and I can concentrate on getting the keyword list together. Have a few minor aesthetic things left on various pages plus a thorough review of everything before any actual pages are created. Making progress little by little.

A different future decision will depend on how long the index list actually becomes as that will be a significant amount of pages to be created and linked. I am not concerned as to the work involved but I don’t know if this will become an issue for the wiki (too many pages). I can foresee some problem with trying to reduce the number of pages so for right now we will stick with the current plan and cross that bridge later.

PS Linda thanks for the comments, it helps to know that this might be going in the right direction. I have changed to local time (thanks again) and that’s interesting about simultaneous editing.

(but it still showed up as UTC time when it is actually 11:46 pm 18 march 2014) Luccagenes 04:46, 19 March 2014 (UTC)

Jump to 20 March 2014
Return to top of page

I've added a link and a new page as a possible example of how a "Research Wiki" entry site might look and utilize the organizational benefits of something like Help Central. Obviously this is just speculation at this point but is just used to indicate the easy expansion of this project and its usefulness in organizing large amounts of information for both new and regular users.

Again, here is the link to the initial Help Central interface page and the new link is found on this page: https://familysearch.org/learn/wiki/en/User:Luccagenes/Sandbox/Interface

Luccagenes 12:58, 20 March 2014 (UTC)

Just had a thought about a couple of good ways to TOTALLY monitor the system but first, forgive me if my writing becomes slurred as I just spent 2 huors at the dentist.

The first possiblity is that I will add another box at the end of the template (keyword) page and call it "editors notes" (e.g., Editor's Notes: this section will be externally monitored for comments. Please update this space concerning the information on this page). The editors can make notes if some or all the information is missing or something just doesn't feel or look right about the page. For the template I will include the statement that "This page is still blank". After a contributor adds their info to the page they can remove or change the info in that box, or they can add notes like "this keyword has no related links yet". When building the template page which is to be copied for each new page there will be a transclusion statement aroound that box whcih can then pull that box into a central maintenance page containing boxes for ALL the keywords. Maintenance can then be done universally on the whole Help Central system by pulling up that maintenance page to identify where problems are (either missing data OR if a particular page has been inadvertantly been left blank). Hey, this is starting to get fun now.

The second option is to go just a little bit farther with the same idea. Since all the sections on the keyword page are going to have id tags hidden in the wikitext anyway (e.g., the FAQ section so it can be trancluded into "The Collection" section and the information sections so they can be "attached" to the special topics pages) then why not bring all of them to a second maintenance page like the editor's notes page above so at one location the whole system can be visually scanned. Yes, this latter example will make for one huge page but it will be more of an archival page that will not need to be accessed much. The question I will have to get answered is: will this large of a page cause problems for the wiki. In actualality it will be a normal size page with a lot of wikitext call out codes, and should only put stress on the wiki server when it is actually being viewed. Need some other opinions on this. Right now I'm thinking that both maintenance pages might be best used in combination with each other as the "editor's note" page could be scanned routinely to track for problems that arise while the "full content" maintenance page could be scanned (say once a year) to ensure that the data remains relevant.

So the combination of the two maintenance pages above and the "last revision" date displayed on the index page itself should result in a system that can be kept up to date with tender loving care. This might work; I love it when a plan comes together.

Luccagenes 21:47, 20 March 2014 (UTC)

Return to top of page

Objectives
Provide a simple means of linking questions to answers


 * Rapid progression from question to answer (the 5 click rule)
 * Simple page to page navigation for the inexperienced
 * Access to one alphabetical index covering all related topics

Result in an individual web address for each “answer” for improve information retrieval


 * For internal use by the system
 * For access by external entities (software programs)

Provide a “structure” wherein any language can build its own support


 * Languages for each subject accessed from common page
 * Links to external multi-lingual sources from one access point
 * Minimal translation needed (entered in original language)

Provide one-stop shopping for all types of information


 * Centralized structure of collecting and accessing information
 * A variety of formats for displaying information
 * Links to related external informatio to specific keyword

A system that is easy to maintain and provides for continual growth


 * Provide a visual monitor of last modified date
 * Easy information addition by editors


 * 1)                    Adding new information to existing pages
 * 2)                    Updating existing pages to maintain relevance
 * 3)                    Minimal system maintenance
 * 4)                    Feedback from users (Talk page)


 * Expandable to other subjects (other than Family Tree)
 * Adaptable to new types of displaying information


 * 1)                    Interactive image maps and tutorials
 * 2)                    Areas of interest of patrons (The Collection)

Return to top of page

Diagrams
Uploaded: Concept Design diagram (waiting for approval)



Uploaded: Structural Design diagram (waiting for approval)

Top of page