Jump to content


Photo

Javascript & Website Tree


  • Please log in to reply
18 replies to this topic

#1 baluo

baluo

    Advanced Member

  • Members
  • PipPipPip
  • 41 posts

Posted 30 April 2019 - 08:00 PM

Hi,

 

I am currently _trying_ to create a family tree Website. 

 

It all seemed to be working fine, until I realised the following issues:

-- special characters are not displayed properly (i.e. ü for ü, which appears quite often in this family tree)

-- more importantly:

it seems, the Javascript embedded in the "RootsMagic 6 Style ... using xml and Javascript" (why not RM7??) are not processed properly by my modern browsers.  Only Firefox produces a proper pedigree and names listing, but then on the other hand no links in the navigation to the Gedcom file (despite activated in the dialogue) and no Help link.  Safari, on the hand, shows the Help link (no link to *.ged file), can produce a pedigree page from a direct link, but looses it after a few more swaps between people, and shows no name list. Google Chrome and Opera simply show -- an empty RM page, links not working.

 

In all cases, before you ask, Javascript has been activated.

 

In my utter frustration I tried the RM6 HTML option. 

Apart from poor HTML code, it works, of course, but when I choose "PedigreeCharts" for the youngest person in the database, I seem to be getting just her family or so -- as I am not a family member, I am not sure what I have there. 

 

I have also tried  to upload the ged file into other programs, but seem to be losing too many event details -- at least the error pages are long ...

 

Pretty frustrating for a Newbie ...  Any advice from the experts?

 

G



#2 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3532 posts

Posted 30 April 2019 - 09:02 PM

If you stay inside of RM, there are three options for producing Web pages. All of them have problems. It will be interesting to see if there are any improvements in this area of RM when RM8 is released.

  • Pre-RM6 web pages. These have been around in RM since it's dawn. They are pure static HTML and don't use any JavaScript. They have kind of an old-fashioned and clunky look and feel. I actually kind of like them, but most RM users seem to prefer a more modern look and feel. They have some advantages. One advantage is that they are fully indexed by Google and other search engines, so anything you publish online in this format can be found by other researchers using search engines in browsers. Another advantage is that they support a number of different reporting formats that mimic what you can print on paper. Another advantage is that they can be published anywhere that Web pages can be published. Another advantage is that you can publish a subset of your data without having to drag and drop a subset of your database into a new database. They have some disadvantages. One disadvantage is the aforementioned old-fashioned and clunky look and feel. Another disadvantage is that you have to find a place to publish them if you want them published on the Internet. Another disadvantage is that they have been deprecated and therefore are not likely to be supported in future versions of RM.
  • RM6 Web pages. Don't be bothered by the name. They first appeared in RM6 and are still available in RM7. They have some advantages. There is only one format, but it really is a pretty good format. It has a modern look and feel and it's pretty easy to navigate. Another advantage is that they can be published anywhere that Web pages can be published. Another advantage is that you can publish a subset of your data without having to drag and drop a subset of your database into a new database. They have some disadvantages. One disadvantage is that they cannot be indexed by Google or other search engines, and hence your pages can't be found by other researchers using search engines in browsers. Another disadvantage is that you have to find a place to publish them if you want them published on the Internet.
  • MyRootsMagic. These Web pages have much the look and feel of the RM6 Web pages (and obviously vice versa!). However, they load a copy of your RM database onto the Web, and they can only be loaded to the RM servers. Hence, there are advantages and disadvantages. The biggest advantage is surely that RM provides a certain amount of free disk space to host the pages. For most users, this makes the facility much easier to use than anything else they could do. And the pages can be indexed by Google and other search engines. The disadvantages are that a whole database has to be loaded. If your database is too big, you have to make a subset. The amount of free space is very limited, and there are no options to pay to increase the space nor can the pages be hosted anywhere else than on the RM servers.

There are non-RM solutions to hosting your data as Web pages. I think there are several such solutions, and two that come to mind immediately are TNG (The Next Generation, not to be confused with TMG or The Master Genealogist) and GedSite. Over the last year or two, I have become confirmed GedSite user. It meets my personal needs much better than any of the RM solutions. Your mileage may vary.

 

Jerry



#3 Trebor22

Trebor22

    Advanced Member

  • Members
  • PipPipPip
  • 183 posts

Posted 01 May 2019 - 02:17 AM

I think Jerry has covered all the points about the various options except perhaps RM8 - I am under the impression the RM6 and before type website options are not due to be included in RM8, may be worth keeping in mind when choosing which you want to go with. Or have I got this wrong Renee?



#4 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6215 posts

Posted 01 May 2019 - 03:54 AM

I can't speak to the quality of the coding of any of the three sites but it is well known that different browsers behave and render differently. Moreover, local JavaScript is deemed by some (Chrome for sure) as a security issue requiring special override by the user.

Jerry's comparison is very good but I would qualify that for Google indexing. I don't think there is any difference between that for RM6 and the RM7 database upload. One is pre-generated JavaScript and XML; the other is generated on the fly. Google claimed some years ago that it started indexing some JavaScript pages but could not handle all constructs. I think the two RM sites' pages are so similar that both can (not) be indexed.

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#5 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3532 posts

Posted 01 May 2019 - 07:20 AM

Jerry's comparison is very good but I would qualify that for Google indexing. I don't think there is any difference between that for RM6 and the RM7 database upload. One is pre-generated JavaScript and XML; the other is generated on the fly. Google claimed some years ago that it started indexing some JavaScript pages but could not handle all constructs. I think the two RM sites' pages are so similar that both can (not) be indexed.

 

I confess to a certain fuzziness on this point. The basic problem is that search engines are usually indexing static HTML pages and do not or cannot index pages that are generated dynamically. Both the RM6 pages and the RM7 pages (MyRootsMagic pages) are generated dynamically, but they use very different programming to accomplish the dynamic generation.

 

However, I'm pretty sure that when the RM7 style pages came out, it was announced that the RM developers had done something to make the pages able to be indexed and searched with search engines. You can certainly include metadata on a Web site that is not a part of the static HTML that displayed on the page and where the metadata is seen and indexed by search engines. That's one of the ways that commercial sites are able to play games to get their sites higher in the list of hits when you do a search, and that's why sometimes you can search for a string and the search engine will bring up a page that doesn't include the desired string. I may not be remembering correctly, but I think the RM7 pages do something with the metadata to make the pages able to be indexed and the RM6 pages do not.

 

Jerry



#6 baluo

baluo

    Advanced Member

  • Members
  • PipPipPip
  • 41 posts

Posted 01 May 2019 - 09:08 AM

HI all,

many thanks for your comments.

 

For now, I have not uploaded the websites (HTML and JS) onto a server but zipped them and sent them to the person who requested them.  I added a ged file and a tiny little Gedcom Viewer, GedView108, for travel purposes. 

 

But this does not solve the fundamental issue of JS not working in browsers other then Mozilla.  My hunch is that there is a simple programming conflict stopping the other browser to allow JS to be executed.  I am not a programmer, so this is at best a guess.  But it surprises me that there seem to be no other such comments. Or I did not see them.

 

And if Chrome is known for considering JS a security risk (which it is, but still too many websites require it), I think an RM7 update should solve such issues.  Also, what puzzled me additionally was the character length of the folder path that initially stopped RM7 to execute the establishment of both website formats.  (The subfolder was embedded deep in the file structure.  When I used a higher up folder, processing the request was on the fly ...)  For a Newbie like me this was quite frustrating.

 

> "RM7 websites"

Is that referring to the RM7 server storage offer?  I looked into it as well but then stopped the process because of the terms of use which included my agreement that RM would own, and could use, uploaded material.

 

> RM7 style pages

what is that?

 

Many thanks again, G



#7 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6215 posts

Posted 01 May 2019 - 09:18 AM

The Chrome security guard you ran up against blocks executing JavaScript from local files. There has been prior discussion on it in this forum, including on the workaround, e.g., at http://forums.rootsmagic.com/index.php?/topic/19052-generate-files-for-a-website-xmljava-nothing-displays/?p=93383 

 

Edit: no update by RM can change Chrome's security. Of course, RM could completely drop the feature of generating files for a website locally...


Edited by TomH, 01 May 2019 - 09:21 AM.

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#8 robertjacobs0

robertjacobs0

    Advanced Member

  • Members
  • PipPipPip
  • 267 posts

Posted 01 May 2019 - 11:40 AM

Jerry mentioned the GedSite program. I use it myself. Its output can be as simple (and simple to make) or as elaborate as the user wishes. See www.gedsite.com which explains the program and provides links to sample sites.



#9 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8414 posts

Posted 02 May 2019 - 02:30 PM

It's a browser security issue, and not a RootsMagic website issue. Once the website is uploaded the browsers will display the pages. 


Renee
RootsMagic

#10 baluo

baluo

    Advanced Member

  • Members
  • PipPipPip
  • 41 posts

Posted 03 May 2019 - 06:01 PM

Good morning to all.

 

I just wanted to let you know that I have uploaded the set of JS files to my web server, and the result is varied, without testing in detail:

Browsers showing the website: Fire-/Waterfox, Google Chrome, Opera, Vivald

Browsers __not__ showing:  Safari, IE

 

__Oh__, I just discovered that if I shut down in IE all security settings, it displays the website ...

 

All browsers seem to have problems displaying special characters properly.

 

As the website is private, unfortunately, I can't share a link at this point of time.

 

My experience so far in essence:

-- offline:

- only my MOZ browsers displayed the JS website properly

- a storage folder "too deep" in the filing system (i.e. beyond 256 char of length of path) blocks the display

 

-- online

- all browsers need to have there security settings low or off

 

Renee's comment seem to be correct, although not quite helpful for users not aware of the JS/security issues behind the system.

 

Anyway, many thanks again for all your advice and help, I much appreciate it.

G



#11 cj1260

cj1260

    Member

  • Members
  • PipPip
  • 26 posts

Posted 09 May 2019 - 11:33 AM


".... I think there are several such solutions, and two that come to mind immediately are TNG (The Next Generation, not to be confused with TMG or The Master Genealogist) and GedSite. Over the last year or two, I have become confirmed GedSite user...."

 

 

 

Jerry - I too have begun to look at both GedSite and TNG. Both look promising. I was just wondering if there were certain features/functionality that pushed you towards GedSite instead of TNG?

 

Thanks.



#12 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3532 posts

Posted 09 May 2019 - 05:34 PM

Jerry - I too have begun to look at both GedSite and TNG. Both look promising. I was just wondering if there were certain features/functionality that pushed you towards GedSite instead of TNG?

 

Thanks.

 

Initially, I just thought GedSite was much easier to deal with. It "basically" just makes static HTML pages (about which a bit more in a moment), and I already have a Web site hosted at godaddy.com that works just fine with GedSite's static HTML pages. I can easily transfer my RM data to GedSite via GEDCOM. GedSite makes the static HTML pages on your local hard drive from which you can burn them to a CD or publish them on the Web or whatever. As I said, I publish to my already existing site at godaddy, but GedSite supports a low cost publishing option of its own. You can use it or not, depending on your needs. You may not wish to publish anywhere online and instead you may wish just to burn the static HTML pages to CD to distribute to family members.

 

TNG instead stores your data as "data" instead of as HTML pages (you can load your data into TNG via GEDCOM or you can type it directly into TNG). Having stored your data, TNG then generates your HTML pages dynamically upon request. On it's face, the dynamic generation of the HTML pages is an advantage (and is strongly advertised that way by TNG). but I'm really just more comfortable with static HTML pages. And in particular, TNG has to run from a Web site, and the Web site has to support PHP (easy to do) and the Web site has to support MySQL (perhaps not so easy). Because of these requirements, you can't simply burn a TNG site to a CD and share it with a family member.

 

Another early consideration was that GedSite would import RM's sentence templates and use them when generating its static HTML. I never got as far as seeing how you controlled sentences with TNG. To be totally honest about it, in the bitter end I decided to set up my sentence templates in GedSite rather than importing them from RM. There were subtle nuances that worked better for me if I defined my sentence templates in GedSite. It appears that about 99.99% of RM users simply use their RM sentences in GedSite, so I'm an outlier. Your mileage may vary.

 

The final straw was that I could attach media images of documents (death certificates, census pages, whatever) to facts tor to citations or to both in RM and then GedSite could display such evidence in either or both places on the HTML pages generated by GedSite. For example (and this is a long term complaint of mine about RM because it can't do it), I could attach a photo of a headstone to a burial fact in RM and GedSite could display the photo along with the same burial fact on my HTML pages generated by GedSite. This is just so wonderful. I've been looking for years to put all my evidence front in center in my "reports" and GedSite makes it possible for HTML pages. I don't know whether TNG does this or not, but it works great for GedSite.

 

Even though GedSite makes static HTML pages, it does use a little JavaScript. For a GedSite page to be rendered as designed by the GedSite author, your users have to be running on a computer which has JavaScript installed and on a browser that has JavaScript enabled. As the creator of your pages, you have no control whether your potential users meet this requirement. GedSite uses JavaScript for two things: 1) for a Search box (so your users can "search" for individuals by name, and 2) to display images in a special HTML page called a Light Box. So if one of your users doesn't have JavaScript installed and enabled, they will not have access to these two features. As a "user" of my own GedSite-generated pages, I can tell you the following. I never use the search box anyway. Instead, I find people in a name index - much better than searching, I think. And I despise the Light Box mechanism for displaying images with the intensity of a thousand suns (and my "users" don't like it either), so I found a trivial (and not supported by the author) way simply to disable the Light Box even if the user has JavaScript installed and enabled. Indeed, I think GedSite actually works better for the most part if your end user doesn't have JavaScript installed and enabled.

 

In its discussion of loading "data" vs. static HTML, the TNG Web site strongly supports loading the "data" as being much better. I equally strongly disagree but there are advantages and disadvantages either way. One concern with static HTML is that each person in GedSite gets their own "page" when you view the site. But GedSite is able to batch a large number of such "people pages" into a single HTML file. The default is 50 "people pages" per HTML file and the number is under your control as the author of your site. I have not found this to be problem at all. RM's old pre-RM6 Web pages generated static HTML. RM's newer RM6 style Web pages and MyRootsMagic Web page load "data" and generated the Web pages dynamically. I again think the static HTML approach is much better and I think that RM is kind of going in the wrong direction. I suspect I am in the minority with this view.

 

Jerry



#13 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 207 posts

Posted 09 May 2019 - 10:50 PM

Jerry,

I can run a PHP/MySQL/Apache website off a thumb drive with ease using XAMP for Windows. It can be shared with people if they have a little computer sense. I do this when I do presentations at family gatherings or for clients when I’m not sure if the location has good or any internet access.

I also ran my local GEDCOM based genealogy website off a small usb drive with XAMP before I purchased my Synology Server a few years back.

I love the ability to generate web pages from my database, along with adding and correcting information on the fly vs having a static page. But I do agree that static websites and html based documents are much easier to share for the general population.

#14 Trebor22

Trebor22

    Advanced Member

  • Members
  • PipPipPip
  • 183 posts

Posted 10 May 2019 - 01:24 AM

. I again think the static HTML approach is much better and I think that RM is kind of going in the wrong direction. I suspect I am in the minority with this view.

 

Jerry

Just in case votes count, I also think RM is heading in the wrong direction in this respect.

However I'm also inclined to the view whichever route RM takes it is unlikely to match the websites  of GedSite (or similar products) where producing  good websites is its primary business.

Its just one of those areas where I suspect I will always do better outside RM :-)



#15 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3532 posts

Posted 10 May 2019 - 06:21 AM

 

Its just one of those areas where I suspect I will always do better outside RM :-)

 

I think it's a hard problem for developers of genealogy software to decide just what is the mission of said software. I think the mission needs not to stray too far from genealogy itself. For example, I think it's hard and probably unwise for genealogy software to try to be better word processing software than Microsoft Word (or similar product). I think it's hard and probably unwise for genealogy software to try to be better graphics software than Adobe Photoshop (or similar software). I think it's hard and probably unwise for genealogy software to try to be better spreadsheet software than Microsoft Excel (or similar software). And it goes on and on with mapping and geocoding, DNA analysis, ebook publication, Web site creation, mobile apps, etc. Genealogy software does need to get into to many of those areas I've mentioned (and surely many others), but at the same time it's very difficult for genealogy software to excel at all those areas and still be true to its core mission of genealogy. So what are developers of genealogy software to do?

 

Also it occurs to me that the development costs of products such as TNG and GedSite can be amortized across the entire base of genealogy software users, whereas for RM or for any of its competitors the development costs of similar features can only be amortized across RM's or any of its competitors's own individual user bases. So there will always be areas where an add on function will do better outside of RM or any of its competitors than within the core genealogy product.

 

Jerry



#16 cj1260

cj1260

    Member

  • Members
  • PipPip
  • 26 posts

Posted 10 May 2019 - 12:44 PM

Jerry -

I appreciate you taking the time to write such a lengthy reply regarding your views about GedSite and TNG.

Your point about static pages is well taken. While I wouldn't have a problem spinning up a server with a PHP/MySQL stack, the ease of handing out a thumb drive to non-technical cousins with simple static pages would certainly be a plus.

Your comment about putting your evidence (i.e. media files) front and center is also one of my biggest reasons for looking at this type of software. I think my relatives would enjoy 'discovering' these original documents when looking at the family tree almost as much as when I first found them.

Once again, thanks for sharing your experiences. Greatly appreciated!



#17 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3532 posts

Posted 10 May 2019 - 07:36 PM

Your comment about putting your evidence (i.e. media files) front and center is also one of my biggest reasons for looking at this type of software.

 

As Robert already said in this thread, you can go to www.gedsite.com to see some sample sites, including Robert's. Several of those sites have extensive photo galleries - including Robert's. And several of those sites were created using GEDCOM from RM.

 

The focus of my site is a little different, mainly to put the evidence front and center. You can see it at http://www.jerrybryan.com/gedsite/  What has been published so far on my site includes only eight people, but many more people are coming. I'm probably not going to publish again until I get about 100 people completely ready for prime time with all the media files the way I want them. You have to look at the surname index to get to the people pages. For a couple of people, I do have some head shot type photos, but for most of the people all I have online is the images that are the evidence.

 

One more thing - on my site you can click on GPS coordinates for the burial and be taken to a live Google map of the cemetery with a pin placed on the exact coordinates of the specific grave site. Both RM and GedSite support geocoding, but neither method of geocoding really meets my needs when it comes to placing pins on live Google maps to that level of detail. Instead, I use a little trick in RM that places the GPS coordinates and the Google Maps link into the GEDCOM which I send to Gedsite where GedSite turns it into the link you see.

 

Jerry



#18 cj1260

cj1260

    Member

  • Members
  • PipPip
  • 26 posts

Posted 11 May 2019 - 08:28 AM

 

....The focus of my site is a little different, mainly to put the evidence front and center. You can see it at http://www.jerrybryan.com/gedsite/  .....

 

 

 

Jerry -

 

Nicely done!

I like the direction that your heading in with your site and the way you are putting all the documentary evidence in plain view.



#19 robertjacobs0

robertjacobs0

    Advanced Member

  • Members
  • PipPipPip
  • 267 posts

Posted 11 May 2019 - 09:25 PM

That's a great site, Jerry. It should appeal to the more serious and scrupulous genealogists among us. As you've seen, I went in a different direction, in part because I felt the site had to appeal to my more elderly users, many of whom were not as much interested in documents as they were in pictures and stories. Now I've gotten into the more elderly class myself I wonder if I made the right choice.

 

Very nice work! Please accept my congratulations.

 

Robert