User:Luccagenes/Archive01Edit This Page

From FamilySearch Wiki

HelpCentral Logo.jpg

'This section from March 5, 2014 to April 4, 2014 has been archived to this page along with the diagrams and the objectives list.'













United States flag.png This user lives in the United States.
Flag of Italy.png This user is of Italian ancestry.
Flag of Denmark.png This user is of Danish ancestry.
Animation6.gif This user is of Swiss ancestry.
Flag of England.png This user is of English ancestry.
HelpCentral Logo2.jpg FamilySearch Family   Tree               Help Central HelpCentral Logo.jpg
HelpCentral Logo2.jpg FamilySearch ResearchWiki               Help Central HelpCentral Logo.jpg

Contents

Why am I here?

(from a novice's point of view)

My involvement here started with a GetSatisfaction suggestion [about Family Tree but this could also be useful for the wiki] 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:

<div style="height: 400px; overflow: auto;">
<!-- Html Elements --!>
</div>

Example used in the wiki lesson is:

<div style="border: 2px solid rgb(221, 221, 221); overflow-y: hidden; overflow-x: auto;
padding: 0.2em; width: 99%;" id="imageContainer">
{| 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)

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

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  [[#name|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 <div> inside a <div> which the program then rewrote but left two <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.

Update: I've added the extra box to the template page but decided to call it the "Editor's Box" and I've added the appropriate Editor's note on the page to describe its function.  In the process of doing this it struck me that the so called Editor's box maintenance page will also have a function possibly more advantageous than the original intent.  This page can be used by the contributors themselves wherein they can go there to scan for pages that have not been filled in yet or that need updating as noted in the Editor's Box.  The ultimate effectiveness of this will of course depend on how diligently those Editor's Boxes are maintained.

Update2: Remember to include a wikitext code to quickly take the contributor from the Editor's Box maintenance page over to the appropriate keyword page if they are scanning and find a page they want to update.

Luccagenes 21:47, 20 March 2014 (UTC)


Jump to 21 March 2014

Return to top of page

I just looked at the notes from the March 20th Community Wiki Support Meeting and while I appreciate the exposure and any suggestions that result from it, I do have to clarify one point in the writeup.  The statement "user is working on his thoughts to streamline the Wiki" was recorded in the meeting minutes but I would wish to make it clear that my intent was not to come to the wiki saying do this, it is a better way to run the wiki.  The original "project" objective was to just build an interactive "user's manual" (for lack of better wording) to enhance the use of the FamilySearch Family Tree software based on repeated requests to find a better way of finding answers.  I just don't want my intentions to be misconstrued.  

This project (this experimental project) is still far from being proven but so far its development and complexity are exceeding anything I could have anticipated.  Consequently, its potential usefulness and versatility are also going beyond what I could have imagined (all the while still realizing that it is still unproven and just an idea recorded on "a piece of paper").  The "wiki" test page linked to the Help Central interface is just an example and I hope it is not interpeded as an attempt to suggest that it should be done that way.  Again, I am only using it as an example and in that light I have probably been giving it more thought than I  should in reference to how it could potentially be designed.  Again, it was never my intent to come here with the idea of streamlining the wiki; sorry if I left that impression.

Luccagenes 17:00, 21 March 2014 (UTC)

I will adjust the minutes (as I was the one who wrote them) accordingly. My intention was to let others know you were working with a new thought process for the wiki. My apologies if I caused any stress.

Linda R Chappell 19:11, 21 March 2014 (UTC) (delete my comment if you want to)

I wasn't too stressed (just a tiny bit), I just wanted to make sure that the statement wasn't misunderstood by others.  I have no idea what the mood of the meeting was toward this project.  If one day it is successful and possibly adaptable to the wiki (I know it would work for the wiki help files based on the trouble I had in finding what I was looking for) then I would gladly assist but something that big is way over my head.

Luccagenes 20:22, 21 March 2014 (UTC)


I have just decided that this cannot be accomplished in the 4 weeks time that I had initially allowed myself. If I had stuck to the original simple concepts, maybe, but this is getting way too complex with the addition of the dual maintenance system, the visual date indicator, the multi-lingual aspect, the transclusion techniques, and finding all the little quirks in the software; to say nothing of my slow learning curve with the wiki and the coding. Not saying I have any regrets as everything discovered so far is turning this into a system with a lot of potential, all I’m saying is that it will probably take 6-8 weeks before it is ready to go “public”. At that point I can then solicit help back at GetSatisfaction when it is time to start filling in all the blank spaces (the answers). That will be the make it or break it event. That will put it after tax day so that is probably a better time to ask for volunteers (between tax day and the summer vacation season). Thank goodness I didn’t include the image map section in the original 4 week timeline as that will take another 6-8 weeks after all of this part is said and done.

I have uploaded an updated version of the Help Central Logo which was cropped to remove the white right and left borders on the picture (that was the way Powerpoint made it, what can I say and at that time I can claim ignorance). By the way, why doesn't this editor have a spell checker? or did I miss it somewhere?

I’ve also been noticing a few inconsistencies from page to page concerning things like how the content boxes are configured and the wording of the captions, headlines, and links (just little things that make it look un-professional). Will have to keep an eye out for them and fix things as I proceed.

I did come across an interesting page which had an example of how to copy pages wherein they used the “nowiki” function to leave a copy of the actual code on the page itself so the editor could just copy/past into the new page. That would reduce the method I had originally thought of by half the work. Before it gets to that point I have to make sure the template page is perfect because I would hate to make corrections to two to three hundred pages.

NOTE: see if an actual “wiki template” can be made for the my whole template page. I have my doubts because what will happen to the entered text if the “template” is readjusted outside the page itself? Check on this.


Luccagenes 02:54, 22 March 2014 (UTC) Hey stupid clock, it is still the 21st here in Minnesota.


Jump to 22 March 2014

Return to top of page


NOTE: Just a thought for a future page that might fit into the wiki training arena; make a page (or a category) called “shortcuts: copy and paste” which would provide examples of different parts of a page that could then be copied/pasted into the user’s page. For example, have a ready-made table that the user could copy and paste into their page so they would just have to modify the text. This would work for say a banner, or a userbox, or an access other pages table, or a fancy scroll table, or table that is set up to be transcluded, or the code commands to do the transcluding, or a ready-made full page example template, or a standardized section of a page template, or different examples of wiki templates, or… You get the idea, and then as people use them and make them more elaborate they could add their fancier version back onto the page for the next person to play with. You would not need to become an expert in wikitext/HTML coding if you didn’t want to but could if you did want to. Since one could potentially end up with hundred of variations I may have to setup specific “shortcut” pages for various types of display examples. Interesting. Update: the code for the shortcut should be displayed on the page itself (using nowiki) so one does not have to go into wikitext to try and locate exactly where the displayed item is.

Somewhat related to the above, I am trying to get the “contents” page fleshed out today but was thinking about the example mentioned earlier where the copy of the actual code was left on the “displayed” page so it could be copied/pasted to make a copy of that page. I will have to experiment with this when I find the time (not project critical) but could one use that same idea to then highlight (colored text) in the spots that would require changes to adapt an existing code to function in another manner.

Specifically, could I set it up so my current English version of the scroll table had the coding displayed on a page where I could then highlight all the small coding changes that would have to be made to make the table ready to function as a Spanish or an Italian scroll table? This might make it possible to use said technique as a “replacement” technique to the “using a variable” concept I was looking for much earlier but apparently the markup languages (wikitext) cannot do. You currently have to use a programming language (e.g., Java) to use the variable concept but this might get around that. I will have to create another sandbox page to play with this idea and use it to relax the brain when I feel bogged down with all these Help Central issues. All I would have to do is display the code on a page, highlight the variables (different colors for different types of variables), copy that displayed (non-functioning coding), paste it into a new page, change all the highlighted words (e.g., change the word “English” to “Spanish”), open the wikitext function to remove the initial and final “nowiki” commands, and then save. This might result in a new scroll table that is set up for Spanish and could function on the same page as the original English version since the internal ID commands would now be distinct from the other table.

But will the color coding commands mess this up? I don’t think so; will have to try this. But will the colored text transfer to the new page when the paste command is performed?  May have to make the changes before the copy command or go into the wikitext on the source page and copy to a new page before making changes.  Either way, this would be much easier than trying to adjust a “working” code while trying not to miss even one little change that must be made if the final table is to function properly.

Luccagenes 15:24, 22 March 2014 (UTC)

While filling in some of the "Contents" page I realized that I will have to add yet another box to the template page for "screen shots" to be included with each keyword page.   Two issues have to be clarified concerning this (I thought I won't have to worry about this until the image map part of the project was underway); first, is there a copyright issue in taking a screen shot of a software programs page, and secondly, how does one take a screen shot without displaying someone's pedigree on the screen?  I know there is a "dummy" wiki family being tested on the beta site but other than that a "fake" three generation family would have to be created (e.g., John Doe, son of Dan Doe and Janet Jones, marries Jane Smith,  daughter of Sam Smith and Joyce Jones, and have three kids: Doris Doe, David Doe, Daniel Doe).  I will have to get an answer to the first before worrying about the second.

Luccagenes 00:46, 23 March 2014 (UTC)


NOTE: Just added the screen shot box to the template page and a "Jump to this page" link for when a contributor is scanning the editor's boxes on the maintenance page they can jump to a keyword page of interest. But if I use the [[{{PAGENAME}}]] code for that link, will the pagename from the page that is being transcluded be called up or will the current maintenance page that it is displayed on be called up? I will have to watch out for this when actual pages start getting made.

Luccagenes 01:39, 23 March 2014 (UTC)


Jump to 24 March 2014

Return to top of page


I'm almost done filling in the contents page but it is very frustrating (the long keyword index list is going to easier than this one).  First the chapter by chapter listing is enormous so I figured I better make a "condensed" version which is still enormous.  Then I decided to make a list by topics (screen pages, subjects, and functions) which is turning out much nicer but now there are 3 different formats in "The Contents" page.  To top it off, the reference manual I am using is from Oct 2013 and there are a lot of changes to the program since then (so those changes are not properly represented in the listings).  Like I said before, this will obviously not be perfect and the contributors, if there are any,  will have to make the corrections that I've missed.  This is starting to wear me down anyway so I just have to get it done and not worry so much about the details.  It is much more fun working on the pages than filling in the pages so once I get this page finished and the index list completed then I can have fun making several hundred pages and over a thousand links (? hurray ?).  Excuse my attitude, its been a long day.

Luccagenes 00:07, 24 March 2014 (UTC)


Jump to 25 March 2014

Return to top of page

The good news is I finished entering the info into the contents page (still have to play with the indent values) but I realized that I should be able to just copy all the sections and dump them into excel and sort them as keywords. By eliminating duplicates and rewording I should have the keyword list virtually done. Not sure how to then dump that info into the index table as the column headers will get messed up (maybe just copy and paste sections).

A different problem is occurring where I am trying to transcluded the last revision date onto the index list (as a monitoring visual indicator). The date showing up is Mar 23 (today in Mar 24) but I did not remember editing that page yesterday. After checking the history I found the last revision was Mar 22 so why is it showing the 23rd? It is transcluding fine as I have a test section on the same page which is also a day off. I will have to try to remember not to touch that page today and see what happens tomorrow. What exactly does “REVISIONDAY” mean? The only thing I can think of is that the history shows a time of 20:20 on the 22nd but does not show the UTC symbol which shows up on this page with a signature. If the 20:20 is Chicago time (central, which is what I have the preferences set at) but the REVISIONDAY is recording UTC time (a 5 hour difference, making it the 23rd) that might explain it. Tomorrow will tell when I check it again. I still do not know why the UTC time is displaying on this page when I have it set for central time in the preferences.

Just to relax, I have been playing with a “Shortcut01” page created in my sandbox to determine if I can get the idea of a shortcut (mentioned earlier) to work. The most important example is the scroll table which has to have the ability to be duplicated several times on the same page (for the multi-lingual aspect to work). Each of the multiple tables would need unique “id=” labels to get the “navbar” to properly function so I have to find a way to visually ensure that all the “English” descriptors are change to  “Spanish” descriptors. I can put the code to display on the page using “nowiki” but the resulting display (code) is jumbled together with no spacing so it is difficult to read. Still, if I copy the displayed text and paste it into the wikitext code it works fine so that is good. The next problem is to mark each “English” phrase in red so the next editor can see which words have to be replaced by the word “Spanish” or “Italian”. A long story short, I can get the text to color but only by repeatedly inserting the nowiki command around each font color change and to get the jumbled text to read line by line I have to do that same thing with the nowiki command again over and over for each line. The multiple nowiki commands is not a problem, the problem is that if I then paste it into wikitext it displays garbage. Do not know why yet but I’m constantly getting closer and closer to getting a “shortcut” to work. What do they call that, when the “short”cut is actually the “long” way around (at least for me but will hopefully make the multi-lingual option an easy possibility on the same page).

I'm still not satisficed with "The Contents" page layout so I added yet another box which will break the subject matter down into "features" like Family Tree, Photos, Stories, and so on.  I will have to let the contributors decide which is best and then we could possibly eliminate some of them.
Luccagenes 03:13, 25 March 2014 (UTC)


Have gotten the shortcuts to work so now it will be easy to make a unique duplicate for each language. One less thing to worry about.

Luccagenes 05:19, 25 March 2014 (UTC)


The "shortcuts" page really is turning out nicely and will really be a time saver.  I will be able to change the appropriate code information using either the rich editor or wikitext in minutes (clearly highlighted in the rich editor).   This will allow multiple copies of the same table to reside on the same page and still function properly with its own unique ID coding for each language.

In fact, I think I will shortly make this into an actual page for easier access and may start a series of "shortcuts".   This first one will be Shortcuts001 as I cannot imagine that I would need more than 999 spots in the future.  Will have to think of something clever to put on the 007 shortcuts page.  Anyway, here is the link to the current shortcut page in my sandbox (almost done), https://familysearch.org/learn/wiki/en/User:Luccagenes/Sandbox/Shortcut01

Luccagenes 14:41, 25 March 2014 (UTC)


I think I found the problem with the "last revision" transcluded result that I had mentioned earlier.  It was not an issue with the UTC times.  What apparently is happening is that when the "last revision" time and date are requested using transclusion what it actually does is takes the "magic" word REVISIONDATE and moves the actual magic word to the new page where it then finds the last revision date for that new page it has been moved to.  I thought the date displayed (the text) on the initial page would be transfered in the tranclusion but this is not so (I confirmed this by adding REVISIONTIMESTAMP which gave more detail).

I posted the following note on Charles' talk page requesting assistance as the only things I can find have to do with "substitution" and "ignoreinclude" but I cannot figure out how they work.  The latter one sounds like what I need ("Gets the value for the variable at the actual page that the variable lives on" as quoted from the Wikipedia site) but I do not know if this is supported with this version of wikitext and experimentation has not been successsful so far.

Note left for Charles:

Hello Charles, I got your name from Linda Chappell,

I am working in my sandbox on a project called HelpCentral and have run into a coding issue I cannot resolve or the coding cannot do what I am requesting. I want to transcluded the “last revision” date of a page (Page 1 below) to display in a table cell on Page 2 (coding below). I noticed it was not behaving correctly and at first thought it was a timing issue with the UTC dates being different from US central time as the day was one date later. Just recently I think I determined the real problem which appears to be that the displayed “last revision” date is the last revision date for page 2 (even though I am transcluding from page 1) as I tested it by re-saving page 2 and the display instantly changed to the current date. I confirmed this by adding the REVISIONTIMESTAMP code and it is indeed NOT transcluding from page 1.

Do I have the coding wrong or is it behaving as it should and therefore it cannot do what I need it to do? If the latter is the case, do you have any alternative suggestions?

Page # 1 (https://familysearch.org/learn/wiki/en/User:Luccagenes/Sandbox/Interface/FamilyTree/Index/Template)

<onlyinclude>{{#ifeq:{{{transcludesection|lastrevision}}}|lastrevision| {{REVISIONYEAR}}  {{REVISIONMONTH}}  {{REVISIONDAY}}  }}</onlyinclude>

Page # 2 (https://familysearch.org/learn/wiki/en/User:Luccagenes/Sandbox/Interface/FamilyTree/Index)

{{User:Luccagenes/Sandbox/Interface/FamilyTree/Index/Template|transcludesection=lastrevision}}

Thanks, Luccagenes
Luccagenes 01:30, 26 March 2014 (UTC)



Jump to 26 March 2014

Top of page


Getting very frustrated and discouraged with this project right now (is this a total waste of time since I don't even know if the users of Family Tree will even like or use the finished product).  Spent the last two days trying to figure out how to get the "last revision" date transcluded to another page.  Have played with "ignoreinclude" and with "includeonly subst" but no luck.  The "includeonly subst" did reference that this might have to be done inside a "template" so now I will have to look into that aspect and learn how to make a template, with no guarantee it is going to work anyway.  The thing I hate about the Internet is that there is a lot of garbage out there.  For both the aforementioned functions I found several Internet hits each but they both always led back to a single vague source (no actual instructions on how to use it) that was presumably transcluded everywhere else.  This is getting very annoying especially if after all this I find out it is not allowed or cannot be done. Gee, I wish there was a way to find a quick answer.

Luccagenes 19:06, 26 March 2014 (UTC)


I'm putting the project on HOLD for awhile.  Hit another brick wall as I tried to test putting the Editor's box onto another page using the transclusion example described in Wikipedia and it didn't work.  Do not know if something is wrong with the coding, if that coding is not supported by this wikitext version, or if this is only a problem because I'm working off the main namespace (there appear to be limitations on what one can do in the sandbox).  I just don't know enough about everything to get any further and I'm starting to burn out.  Will have to take a break before I totally scrap this project. More later, maybe.

Luccagenes 23:08, 26 March 2014 (UTC)


Jump to 27 March 2014

Top of page


Okay, I finally went to two of the WebEx meetings and sure enough, now I have more work to do (I shouldn’t open my mouth). The meetings were interesting concerning the revamping of the home page and getting the wiki “up to date”. I will have to check out Yammer but in the second meeting it didn’t sound like one needs an invitation so we will see; from Caleb it sounds like SalesForce will start trail run in about a month (if approved) with full use in 2-3 months at which point the migration from Yammer could begin. The discussions in the second (contributor’s) meeting were also very interesting concerning the simplification of the page design for the Utah and Illinois pages (I will have to keep this in mind when designing my sandbox pages), as well as the discussion on the metrics and how to test the pages (Utah and Illinois) side by side with the old pages to determine if the new pages are drawing in new users.

As I mentioned, I opened my mouth and mentioned the idea of a “world cities” scroll table to get the user to his destination with one click. Of course, I had to promise Giuseppe that I would pull something together to demonstrate the idea for next Thursday's meeting. I was thinking that I would pull together a small sample (all the cities and townships in Minnesota!);  it turns out there are even a couple ghost towns included.   I am just pulling the information off Wikipedia into Excel after which I can copy them back into the scroll table. Surprisingly most of the items already have links to other Wikipedia articles so this will actually be a functional table. But the next question is how to incorporate (and highlight) the content of the Research Wiki in such a table? Since I believe the Research Wiki has a “Counties” project underway I was thinking that the second column in the scroll table could possibly be used to include the FamilySearch icon for links that refer specifically to this wiki so when we include a second link (same name in the table) those links would give the option to select either link for items that can be found in both wikis (possibly also color highlighting the line to this wiki). Just a thought. Also, in playing with this idea I came to the conclusion that it would not need the keyword pages that are necessary for the Help Central Family Tree project since each link could go to existing pages but that would still leave the option open if it was determined that a keyword (general access) page would be beneficial.

I think I will just expand the test page I made for the Research wiki as it turns out the revisions for the new wiki homepage pretty much reflect the way I had set up the page (the subgroups: Beginners, accessing resources, and giving back) although the wordings were slightly different. It was also questioned whether or not the scroll type table would be useful on the counties pages but I was thinking (at least for this Help Central aspect) that I will break the suggested one table idea down to two levels. From the Research Wiki main page in Help Central the user can click on the “Research Assist” link and will then be brought to a scroll table listing the countries of the world with subgroups of regions, states, and provinces. Then, for example, after the selection of the desired state (MN) the user would be brought to a State scroll table with subgroups by counties which in turn would have subgroups of cities and townships. Let’s see if this can be done by Thursday.

Before the first meeting I asked if anyone else was having issues with the wiki editor lately as one of my pages was severely corrupted last night just before the wiki went down for about an hour. Even though the editor showed everything was good, it turns out the preview button showed a corrupted display which apparently was what was saved (the brackets in the wikitext reverted to code which displayed a bracket but the gibberish code corrupted the code itself). Anyway, this morning the problem was still evident but at least the good code is now being saved even though the preview is showing garbage. I believe it was Charles that indicated they were changing the system over to the new version of wikitext so that must have been why it shut down last night.

By the way, I did get the transclusion to finally display but only after I removed the excess onlyinclude commands that are necessary to distinguish multiple sections on the page. You can only transclude the whole page but only the portions inside the onlyinclude code will appear. I did find something new that I tried (called a "section" command) to distinguish multiple sections but the wikitext kicked it out.   If the new version was indeed being installed I will have to try it again as it may now be supported. All in all, I did get it to work but something is still not right with the “last revision” date being transcluded but again maybe things will be different with the new version.

Luccagenes 21:46, 27 March 2014 (UTC)

Jump to 28 March 2014

Top of page


I did it again, made the assumption that pulling together a list of Minnesota cities was going to be easy.  After 7 hours of copy/paste from Wikipedia I finally had my list but it is worthless (at least in the short term).  I assumed I could copy/paste from Excel back into the wiki but I cannot find a way.  None of the avenues will  let the previous link information survive the transfer (not a copy/paste into the editor or into the wikitext itself nor using the Excel converter program listed in the help files) so the only way to do it is by hand, first the text would have to be transferred or typed in and then the link would have to be re-established inside the wikitext editor.  Oh well, at least I have the names and links for over 3800 cities in the great state of Minnesota; I never realized there were so many actual communities out there plus there are probably over 100 ghost towns listed.  Obviously now I will have to pare down the demo for Giuseppe because without previous acceptance, I am not going to re-establish 4000 links (I may have been stupid to pull together the list before testing an example but I am not stupid enough to continue this task).  I will concentrate on the style more than the substance to try to get the idea across with just a few established links to make the point.  More later.

Luccagenes 15:30, 28 March 2014 (UTC)


Okay, the Research Wiki pages are almost done as it went faster than I thought since I did not have to load 4000 cities and re-establish all those links. This will serve as a demo for Giuseppe of how Help Central could be used for this wiki. If you go to the Interface page and follow the Research Wiki link it will take you to a Research Wiki main page where you can select the "Research Assit" link which will take you to a scroll table of “Countries: Regions/States/Provinces”.    Use the navbar to go to “U” for United States (example) and then scroll down to Minnesota (example). From the MN links use the Help Central “go to county and city search” to get to page 3 where there is another scroll table. Be sure to try the browsers “find” function on page 3 by typing in the name Anoka.

I’ve decided not to add a sort button (sortable table) because I honestly do not see its usefulness in this application as the “find” function works so beautifully and the table would have to be revamped significantly. By using the “find” function, this means that even if the individual state tables get to be 10,000-30,000 entries long (remember that each entry title could have 1-5 links or more associated with it but most will have one) it will still be easily searchable. This will become even more important with the country table as it could potentially grow to over 50,000 entries; the only question is will this large of a table cause problems for the server or will it be too hard to load into the display efficiently. As a side note, it was brought up at the meeting that maybe a table like this would be better on the counties pages but technically that is very easy to do using transclusion while still keeping the original in a centralized location (Help Central).

Sorry, but this demo only has a few demonstration links that were re-established but hopefully you will get the feel of it (style over substance?). Now I have to get back to work on the original project before I forget about it (tempting).
Luccagenes 00:24, 29 March 2014 (UTC)


Jump to 29 March 2014

Top of page


I started a test to see what would happen if a really large scroll table was created basically to see if there is a maximum sized file the server would accept and to see if there were any problems when the table was displayed or used. I could not find any references as to the maximum size page that would be allowed: all I found was a note in the Guiding Principles page that stated that large file sizes should be discussed but there was no actual discussion.

Anyway, since (in my prejudiced opinion) the two new tables added to the Help Central Research Wiki pages, the experimental pages, look pretty nice so the next question I imagined that Giuseppe would ask is: are there any technological problems when working with a table that large? To answer that question I created yet another page where I could keep doubling the number of rows in the table (exponentially) to get up to a table with over 10,000 rows. Based on the Minnesota example if I have 3500 city names (rows) and each name could have 4 extra rows with links in them, then that is roughly 17,500 rows for a single state. The resulting USA section (x50) would be 875,000 rows. The resulting “world cities” I don’t even want to think about (even though that would probably be several years away).

The good news is that I have so far gotten up to almost 5000 rows and the table performs flawlessly and takes less that a second longer to load to the screen. It takes a little longer to save it and I initially had some trouble during the doubling process as the server destroyed the page (saved a blank page) when I doubled from 2800 to 5600. By increasing at a slower rate I have gotten up to almost 5000 and this rate would be more representative of actual use. Maybe it was a problem with too large of an increase all at once. I still have to find out if this file was causing Myra problems while she was patrolling. Anyway, taking a little break to see if Myra’s Firefox problems go away before starting to increase the size of the file again.

Heard back from Myra and she is having trouble accessing my sandbox related page specifically and not others she is patrolling. It could be a Firefox issue as I have had similar problems if I have too many tabs open at once. Will have to keep an eye on this to make sure this is not a reoccurring problem for everyone when a large table is present.

Luccagenes 23:38, 29 March 2014 (UTC)

Okay, I think I found the page size limit; it is 1,000,000 bytes which may be an arbitrary limit set by the programmers as to when the transfer rate starts slowing down during uploading and downloading.  In thinking about it some more the example of a USA table needing 875,00 rows is not even a concern as the demo is already set up for individual state scroll tables.  With the large number of communities in a state (the MN example had approximately 3800) there may be a possibility of pushing the limit once links and pictures are added to the table (this would have to be watched closely as I do not know how representative MN is; some othe might be much more). 

The world scroll table might actually be fine too since for the USA there would only be 50 or so subheadings with possibly 4 links each for a total of 200 rows.  With 244 countries currently listed and giving each 200 rows that would equal 49,000 entries or rows (which is a worst case scenario since a small island nation is not going to have 50 subdivisions like the USA.  If it were to become a problem then the world table could be subdivided by continent and then everything would be fine.  The scroll table itself performed flawlessly even at 909,000 bytes (almost 5000 rows with just a few links and pictures) so performance is not the issue, it is more a question if the browser has issues or if older computers with slow internet connections (like mine) will become the problem over time.  Anyway, I think I have enough information for Thursdays meeting so we will see if this even gets off the ground then.

Luccagenes 04:20, 30 March 2014 (UTC) 


Jump to 30 March 2014

Top of page

Found a slightly better way of displaying the cities information that will hopefully put less stress on the server (less page size). Instead of wasting valuable real-estate by having each city on its own table line, all the subgroups like townships could be on a single table line. This would shift the byte costs more toward the actual information and less into the table structure (fewer lines). As it turns out it also makes the table easier to read which is a definite plus when scanning such a large table, but everything still remains searchable using the browser “find” function. The indentations can still be used to distinguish more structured communities (cities) to the less structured like a CDP (census designated places). The image of the FamilySearch logo can still be inserted where necessary to distinguish the Research Wiki’s entries from those of Wikipedia or others (see the first entry example in the counties table to see this layout). The overall result is that any and all cities in the world will be able to be located via this type of two tier system.

Concerning the other project (I vaguely remember the other project), the compiling of the actual keyword list for the Family Tree project has to be finished and I still have to do the final page design modifications before real pages can be made.  Oh, also have to figure out this stupid transclusion thing so I can get the maintenance system to work.  Since I cannot find any "instructions" of how to use that function, I will have to search Wikipedia to find examples to study.   I could be wrong but it appears that all the transclusion on this wiki is done using templates, which won't work for what I want it to do.   I do not want to put specific common information on several pages, I want to pull specific information from several pages to a common page.   Anyway, I believe I have enough of the overall design finished and since this project is taking its toll I will not worry about having everything perfect but will explain to the contributors that if they want this to succeed they should correct and change anything they feel appropriate (which is after all what this wiki is all about).

Luccagenes 16:14, 30 March 2014 (UTC)


Just cannot seem to leave it alone. Found another way to reduce the byte cost. The possibility of reducing the table to one column instead of two would help immensely. This is more of a style and usability question so I will seek the opinions of others as to which is easier to scan and then read.   To demonstrate, in the counties table two columns are used for the first example (Aitkin) and one column is used for the second example (Anoka).   I am leaning toward the one column and I definitely like the cities format in the Aitkin example (much easier to read).

Update: Yet another question: If it is decided to proceed, should the tables be made as a template that could potentially be included on the Counties pages (a question raised at the meeting) or should they be set up so they can be transcluded to the other pages?  It could go either way so are there any advantages to one over another? A template might help reduce the page sizes and would probably be easier for others to access when adding to other pages.  More thought needed.

Luccagenes 18:16, 30 March 2014 (UTC)


Jump to 31 March 2014

Return to top of page

I’m beginning to think I will never get back to the original project again (my original time table had me finishing up about now). I added two more pages to the Research Wiki test pages but please realize that this is all speculation and may be corny so if you have suggestions or comments please be sure to throw your opinion into the discussion (start a talk page on the pages in question; discussion is good). I expanded the wiki main page with a link to “Research methods” that goes to a page I’m calling “Step by step” which would be the starting point for beginners. The learning process for someone new to genealogy should be approached using baby steps so they don’t get overwhelmed and discouraged or they just start collecting tons of data with no plan of what to do with it (me 20 years ago and still today). They should be taught how to set goals and milestones and how to enjoy their accomplishments.   I also added a link to “Research Input” which goes to a page I’m calling “Giving back” where one would get quick access to the learning materials about being a contributor; so they can also find articles such as the on-line coursework and a Help Central section on finding specific answers quickly.  These are just thoughts rolling around in the old noggin and I’m just using these pages to write down ideas so again, your suggestions/corrections/improvements are more than welcome.

On a slightly darker note, I may have to totally rethink the design on how to physically construct the pages for the original (Family Tree user’s manual) project. Playing with the “large test file” was eye opening as I not only broke Myra’s computer from half way across the country but it made me more conscious of how big these pages are actually getting. I did not realize when I started that I was doing anything unusual as far a page construction was concerned but these pages are getting big faster than I would like. With an upper limit of 1,000,000 bytes before the server kicks me out I figure a usable maximum range would be 400,000 to 600,000 bytes (even though the scroll table performed flawlessly at 900,000 bytes, the load time was noticable).  With at least one of my pages approaching 200,000 even before any real data has been entered, this could be a crisis. The optimum page size, I would guess, would be between 10,000 and 250,000 before the transfer rate of the file is discernable by the user and starts showing up as a concern in the server. At around 100,000 I believe I can see a slight difference in the download times on my slow DSL connection.  This creates a problem for the current page design in that my intentions to include "stuff" involving the multi-lingual aspects would at least quadruple the page sizes. This is a problem! It might also be the answer to the page size issues AND to my problems with transclusion. That is why I have to rethink this before going any farther.

My problems with transclusion have been that I can get it to work when using it like the templates use it but that requires accessing a page under the “template” category or by using the “onlyinclude” function which can only be used once per page otherwise things get messy. That brings me to the first question: Does an imported template increase the size of the page by the size of the template or just by the size of the code used to call the template? This should be easy to figure out but I'm assuming it does not increase the page size (I cannot imagine it would; it will affect the server usage though). This could be the answer to both dilemmas (which is probably why the wiki was designed that way but I was too stupid to realize it; the perils of being a novice in this day and age). So anyway, enough of this kicking myself in the behind, if I create each of the scroll tables as a template for the wiki “world cities” project this would give a little more wiggle room for expansion of the page size. This would also allow the counties pages to use the scroll table on their own pages as a template if desired.

This could also solve all the issues on the original project in that first, each of the alternative language scroll tables (of the keyword list) would be separate templates thus removing the burden from the original page, and secondly, I could break down my current pages (where there are 5-15 tables on them) so that each table was a separate template that was transcluded back to the desired page with the result that both issue would be resolved (large page size and transclusion problems). If this is the solution there is one MAJOR drawback; splitting out all the tables on my Family Tree primary pages will result in about only 30 or so templates but if there are 5 tables on each keyword page and there are three hundred keywords, that is 1500 additional template pages; I do not even want to think about the effect of multiple languages as each one would double that.

The second question that needs to be answer in the short term is: if two templates (e.g., English and Spanish scroll tables) are transcluded to the same page, will the navigation bars on the tables behave separately or will I still be required to have separate ID labels in the coding for each one (because they are on the same page)? If I cannot find someone with the answer that means I will have to make another test page to find the answer myself. Since I have had little luck finding answers written down somewhere, I guess that is the next thing I have to do. Hope I don’t break Myra’s computer again.
Luccagenes 17:46, 31 March 2014 (UTC)


Jump to 4 April 2014

Return to top of page

Okay, at least now I know what to do next. Talked with Charles for almost a half hour after the meeting and the basic conclusion is that I cannot do any of the transclusion coding that I wanted to; it is not possible with this wiki. Besides the fact that I just wasted the last week trying to figure this out, this means that templates (hundreds of them) will be the only other option available. He said the transclusion of the revision date will not work either so I will have to elimate that attempt.   See how a Help Central for the wiki would have saved me time and stress, if only.  I asked Charles if I was going to get into trouble if I make 300 pages and two times that (600) associated templates and he said that that in and of itself is not a problem. He did question if my original project was just going to “take” the users off of the wiki (through the links) and the answer is technically yes but presumably it would bring just as many new users into the wiki as well. I mentioned that Linda was the one that suggested that something similar might work for this wiki in which case it would not take the users off the wiki; he seemed more agreeable to that premise.

At the morning meeting I showed the demo of the “world cities” but Giuseppe and the others had no comment, other than Linda (Thank you Linda). Therefore I can only assume there is limited or no interest in this idea and it should not be pursued any further. Since I have all the data for MN anyway in an Excel spreadsheet I might eventually pull that info into a scroll table along with the countries information already in the demo, put those two tables on a couple of templates, and be done with it. If anyone wants to pursue it farther they can but I’m assuming that people have noticed how much work would be involved (with no one around to do it). So that they say, is that.

I did make a comment at the meeting that the “Research Wiki” has limited (if any) hits on an Internet search but it was concluded at the meeting that that was because I was working with Yahoo as the search engine as Charles did a check using Google and reported that it showed up at the top when he used the search word “genealogy”.   After the meeting, while trying to confirm this I switched to Google and I was correct.  Searching “genealogy” and “learn genealogy” in Google brings up the FamilySearch records and FamilySearch Learning Center, respectively, near the top of the list (this must have been what Charles was reporting) but there was no direct reference to the “Research Wiki” at least for the first 3 pages or 30 hits. Of course, you can find the wiki through FamilySearch but it is not obvious (it is not initially visible on their homepage) and you have to look for it hidden in a drop down menu. It was 6 months before I ever noticed it there and I never clicked on it for the next 6 months because all it said was “wiki” and I had no idea it was even called the Research Wiki until I actually came here.  If they are happy with that, so be it; my point was made, that is all I can do. I am still getting confused because sometimes FamilySearch and Research Wiki are treated as the same thing (like above) but at other times I seem to hear that they are two distinct entities.

For now, I will concentrate on the original project by designing the template pages that will be needed but in the short term I do not see any point in going too far until the new wider pages are available. ALL the pre-existing pages would require fixing at that time and I’m not going to go back to readjust 1000 pages. Anyway, I still have that nagging feeling lately that this project will not get the needed assistance to fill in the “blank” pages from the Family Tree users which would definitely kill the project.   It would take me personally (by myself) over a year to fill in the blanks with no guarantee is would be accepted anyway.  So if the initial reception fails, the project fails. We will have to wait and see.

Since the wiki is undergoing such significant changes (new home page revisions and the request to update articles and remove outdated pages) there is little point in developing a Help Central for the wiki at this time (too many unknown variables).  I will keep it in the back of my mind and rethink it again when and if the initial project is successful.   Obviously, if the original project is unsuccessful then it would probably fail for a wiki application too.

As far as the new wider pages are concerned, Charles did mention something about “absolute positioning” that can be used in the wikitext coding so if I can figure that out it might be worth starting to make pages before the wider screen is available. The scroll table’s current design might survive the changes if I can lock the navbars together with the table. The existing setup using float left and float right will split the table from the navbar when the screen changes size from the current 640 pixels to over 1200 pixels so we are definitely in a wait and see mode.

There was no time at the second meeting to bring up a couple points I wanted to ask questions about so I will post them here instead. I noticed a couple things with the new revisions to the home page:
1) There is an icon on the picture which states that further info about this image can be found by clicking here. I have noticed this before for many images and it was evident here as well. When you are taken to the image page the image is displayed but ends up behind the right sidebar menu. Some do and some don’t. Do not know if anything can be done about it other than do not put the icon on the page (just clicking the image does the same thing anyway); just don't draw attention to it by using an icon.

2) I was curious about the policies associated with the translation links. Even though the home page is revised the translation links obviously go to the home page that is not revised. Is there some notification process that one is supposed to implement to tell others that the translation is no longer effective? Just curious.

Not sure if those two items are what should even be brought up at this meeting as it sounded like the normal discussion related to existing page issues and the like and not minor technical issues. Not sure what subjects are supposed to be discussed at either of the meetings and I thought it funny when it was stated that information/interactions had been negatively affected when they split the original meeting in two but now the first meeting is again split in two. Will have to figure out which of the two meetings, if any, is most worth attending, at least until I can get my original project done. Then there is still the question of Skype, Yammer, or SaleForce. That’s all for now and it will probably be awhile before the next update. And finally, I just noticed how long this update was, oops; a lot said about nothing.

Luccagenes 03:47, 4 April 2014 (UTC)

Continued back on user page.



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)

HelpCentral Concept Design.jpg

Uploaded: Structural Design diagram (waiting for approval)

HelpCentral Structural Design.jpg

Top of page




  • This page was last modified on 22 July 2014, at 23:44.
  • This page has been accessed 147 times.