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. 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.

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” 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)

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/index      (aka: index 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/alphabetical/(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)

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. The easiest method 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)

Diagrams
Uploaded: Concept Design diagram (waiting for approval)

Uploaded: Structural Design diagram (waiting for approval)