Help get this topic noticed by sharing it on Twitter, Facebook, or email.

New glitches appear in the website every week while previous ones get fixed, bad user experience

Recently on Yammer I was on a post where another user was reporting the website being slow, and lamented that the website has always been causing him trouble. I chimed in with several comments to agree. Although for me it was not slowness that was the main issue. It was random things being broken every week and then fixed with something else broken. Some employees replied, but until this stops happening and is better acknowledged I do not feel anything is really resolved about this issue. This has been going on for me since the website was introduced a few years ago. See the Yammer post for reference: https://www.yammer.com/familysearchgr...

I decided to actually record a video next time I experience a random glitch. In this video I talk about the glitch I found today and the fact that I find a different random one pretty much every week which is almost always fixed by the next week, but it is still frustrating that this is sort of my life on the site (I just know this is the way it is). Don't you think it should be more stable? https://youtu.be/PWcWymYlYuM

This particular problem will probably be fixed soon if it is not already fixed, so I am not so much asking for a reply about this particular glitch as I am hoping for FamilySearch to acknowledge that every week about I find something else broken and it is not a fun thing to experience as a user. I doubt they can stop this from happening because every time a feature is tweaked or something is migrated there is a chance for another glitch. They change the site every day, making it better, which means this will also make more errors happen. That is the nature of frequent change in the technology world I suppose. Mostly I just want FamilySearch to acknowledge that this poor user experience happens. So many other users tell me they never have trouble with the site like I do which sounds weird to me. It happens that something is broken for me every week. Almost seems like I am cursed. :)

I really love the site and I am a strong advocate for it unlike some other frustrated users. However, I wish FamilySearch would acknowledge my problems more and apologize. Most of the replies I get just say it works well for them and to fix anything they need tons of data from me and proof of the issues. Honestly, I do not report every issue because it is even more of a burden on me to have to report each one. Usually they are fixed within a week or so.

Again, I love that FamilySearch staff are all so dedicated and want the experience to be good. I know they work very hard for users like me. I just want this experience to be acknowledged.
2 people like
this idea
+1
Reply
  • In fairness, there are plenty of times when a FamilySearch employee comes to this forum, acknowledges the glitch and returns to advise when it has been fixed.

    However, regardless of whether or not these glitches are acknowledged, there are far too many of them. There seems such a hurry (I assume, like most employees, the developers have deadlines to meet) to get these updates released that they are obviously not fully tested for their "side effects".

    There has been one present over the last few days whereby an "Unknown person" page is appearing following a change. Clicking on "back" seems to take you back to the person before last whose page you were on. I have not reported it as, like many of these glitches, it seems intermittent and will probably be resolved in a couple of days.
    • I think the unknown person glitch is related to bandwidth, or at any rate to page load issues: it seems to be the default or first step that eventually resolves into the actually-desired page -- except when it doesn't, because it gets stuck there. There's a similar intermittent problem in image browsing, where hitting the arrow either doesn't do anything, or it goes to the blurry view of the next page but never "clears up" like it's supposed to. I think both of these behaviors boil down to a problem in the back-and-forth between the FS servers and our browsers.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated

  • That is true. FamilySearch staff go out of their way to help and be responsive.

    Thanks, it helps to hear from other users who acknowledge that glitches regularly occur so I do not feel like it is only happening to me.

    I just saw profile pictures are not loading at the moment too.
    • PS. This seems to mostly be in the cases where there were images like headstones that were originally classified as a photograph and then reclassified as a document thus taking them away from showing up as a profile image, but the system still has some code there that wants to load an image if there if not a replacement profile picture. I'd suppose the team already identified this bug, but just in case it helps this is the situation it appears to be: there was a photo, but it was changed to a document or the tag was removed for any reason and no replacement photo is present.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated

  • I appreciate when users post issues (and good things) that occur on FS. I'm really sensitive to user experience problems so I agree, and to me extends further to data: bad data=bad experience, and bad experience=bad data.

    Most glitches are, glitches - a page refresh or hit that mouse button again is a common fix for many programs. Any time you have connectivity involved (receiving/sending data), plus through a browser, computer, router, service provider,... just increases the number of links in the chain that can hiccup. As for the teams, they need to usually have a repeatable steps to reproduce to analyze what is happening. So those intermittent problems are a chore for everyone. 
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated

  • Michael, we appreciate you taking time to report issues, and especially as fellow users, we understand your pain when breakages seem to be so common. I would like to briefly speak to the complexity of maintaining "the website":

    I am on a team with ten other web developers, maintaining an active codebase of over 500,000 lines of code, spread across 40 repositories, which is only responsible for the part of the website that you see at familysearch.org/tree. There are over 50 other web developers across more than a dozen other teams, each of which is responsible for sizable codebases, and most teams deploy new changes a half dozen times a day. Now, not only do each of our pieces of the website need to function on their own, there are numerous pieces of cross-cutting functionality. There are thousands of unit, component, and acceptance tests in place to do their best to ensure that the site remains functional. However, the site does not remain static--we are constantly adding features and functionality, and fixing what issues we run into along the way. Unfortunately, every time a line of code changes, there is the potential for breakage, despite our very best efforts to coordinate across multiple disparate teams, limit risk, and thoroughly test our changes before releasing them.

    Now, further compounding the issue is the fact that there are over a hundred other engineers who are also making improvements to the massive databases that drive the entire site, and to the infrastructure that ties everything together.

    As you noted already, the takeaway is that while we work as hard as we can to provide better and better tools to assist you in your genealogical endeavors, there is no feasible way to have the combined efforts of literally hundreds of engineers across millions of lines of code never have any unintended side-effects.

    That being said it may be worth reiterating:

    #1: We do pay attention to issues posted in this forum and do our best to address them.

    #2: We are all on the same side--everyone here wants the site to consistently work well, just as you do.

    #3: Engineers are human, too, so there will be mistakes. We feel bad when they happen. We generally learn from them, though, so hopefully they will not be the same ones over and over.

    #4: We really appreciate and depend on users like you, who care enough to take the time to let us know when something goes terribly wrong.

    Until the next bug, we remain faithfully yours.

    - The Engineers
    • I teach online college courses in which the content is managed by a complex set of design and development teams, including many hands of those who are less familiar with the course I teach or the topic I teach (including some being student employees who may possibly be even more prone to make mistakes). This is a small example comparatively to what you are doing. As the one teaching who is assigned to represent the course content I get to have a lot of say in what changes we decide to make, but we are limited to only 10-20 hours of work to make changes typically in a semester. The limits help ensure we do not all go too crazy, but also mean some things improve slowly. I love the university I teach for, but am not convinced that we have a perfect system. I understand why there are many hands involved, but I know that if I was more in control on the course content that the rate of error would be lower. Each semester over the course of a few years I have been submitting requests to get typos or errors in the course fixed. Often when a fix is implemented the student or designer who makes the change actually causes a different typo or formatting error. Obviously having so many hands involved causes more problems and perpetuates the situation of poor quality. At the same time the turn-over rate for online instructors is relatively high with many new ones being hired each year. There practically has to be a system in place so that the burden of maintaining course content does not fall on the instructor alone. So even though I am confident I could keep the course in better shape sometimes if I did not have to have student employees make some of the changes, there are many new instructors who are not trained in how to make the changes and would not be capable of doing so. So it forces us practically into a situation where many of our courses perpetually have typos or errors no matter how much work we put into them. So from this personal experience I really do understand a little bit of what you are talking about.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated

  • 1
    Clif, I appreciate the time that you took to write out the scale of the beast that we're dealing with. It gets to be quite difficult for us to understand the size of the issue, so this helps. I know it's a pain and not what developers signed up for, but communication can only help.

    I worked in IT and from my viewpoint, there's zero way that major changes get implemented with no resulting bugs. It's what happens afterwards that matters and there have been occasions when I was personally embarrassed by "my" bugs - not the fact that I'd designed or coded that bug, but by the tolerant reaction of my users, who I'd taken a great deal of care to keep up to date after the discovery of said bug. Communication does help.

    At the same time, there are some themes that worry me and the phrase "most teams deploy new changes a half dozen times a day" is a concern that has been fixed on several times by those of us with IT backgrounds. I took some time to accept it, but did feel that there were lots of advantages to reducing the frequency of enhancement change implementation, such as the ability to properly document configurations and just think about the risks of changes.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated

  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated

  • Clif

    Without the benefit of an IT background, I was going to make very similar comments to Adrian. As he has had experience in this field, I now feel free to do so.

    To satisfy users who have become a little fed-up of these constant glitches following updates, can you please explain why it is really necessary (to repeat the phrase) to "deploy new changes a half dozen times a day"?

    Perhaps I cannot comprehend the complexities of programs such as Family Tree, but I just cannot see how it would not be better to gather all the updates (revised code, etc.) together, test thoroughly in a beta environment, then for the teams to coordinate in releasing all the changes into the "live" program on a far less frequent basis.

    My experience has been related to user testing, whereby when changes were made to the company's machinery maintenance program a dozen people sat in a room for several days doing everything possible to make the new version crash! Obviously there is no comparison in scale with that package and Family Tree, but I have to ask - what is the urgency for these updates if the program has been functioning quite well before a glitch occurs? Unless they are desperately needed, please try to hold back on this (literally) constant change and make minor updates only when absolutely essential.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated

  • In the aerospace industry it was found that cost & schedule would always exceed all expectation, and the product often didn't work. One of the identified causes was that as the customer watched the project progress, he would add more desired features. The engineers would then have to incorporate the changes but before they got that done new desired features would be added. The phenomenon was called "the moving target".

    Solution: Write a specification detailing the product's size, shape, and operation. Print copies for all parties to read and redline. Incorporate all redlines and reiterate until everyone agreed this is what we are building and it should cost yea much and be done in so much time. All parties would sign a contract: this is what the engineers will build and the customer will pay for.

    Then the engineers go to work toward a stationary target and proceed to build it with sanity and order. The result almost always worked perfectly (at least at the company I worked for, that was our ideal) and altho cost & schedule were usually overrun, it was only by a percentage, usually not exceeding 50%.

    If the customer suddenly decided it should have this additional feature or function, the engineers would point to the specification and just simply refuse. This was a great and holy thing.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated

  • 1
    Nearly a decade ago, Jim Greene talked with us about the effort to develop and release FamilySearch and specifically, Family Tree (at that time, newFamilySearch (nFS) was still being released and it had been discovered that the program simply could not scale to meet the needs of a single, collaborative, and open-edit tree).

    Note: I have removed a major description of the evolution of man's involvement with the religious aspects behind FamilySearch FamilyTree.

    Jim Greene explained that Family Tree was then developed and released as much as possible to overcome the shortcomings of nFS which was hampered by the technology of the time. We (and the industry) were still learning and the computer technology was still being developed.

    As to the transition from nFS to FT, what should be done? Stop everything while all the previously completed work was moved onto the new platform and bugs worked out, or let it continue rolling down the road at sixty miles per hour, accommodating as much as possible the patrons of the system?

    The latter was the only choice really available. So even though it was released slowly to the membership of the church and selected groups of genealogists, it was still like changing all four tires and the engine while continuing full speed ahead.

    I'm not sure that we are even at release 1.0, but I suspect that we are. It has taken a decade to get this far and now newer technology has necessitated reworking the entire system.

    Some parts are still running "old clunky code" and parts of that code are part of the older nFS system and cannot scale. The scaling issue to a major concern, which is why you will see complaints about the temple portion of Family Tree. Non-members are not impacted, but what they do with the tree does impact the system and because the numbers of people that use FamilySearch are growing significantly each month, scaling is requiring a lot of resources to accommodate. That's one reason why important areas look to be ignored, unless major bugs are discovered (such as the one involving the GEDCOM problem), the rework of those areas remain down the list of priorities, tackling the underlying supporting routines that need immediate attention. For those involved with the computer industry, remember the .dll battles of earlier operating systems (pre Windows XP)? The same thing is involved in Family Tree.

    What this means is that stopping the process, to put together an extensive "specification detailing the product's size, shape, and operation", reviewing it, revising it until it is finalized, and then using that as a guide, simply will not work. Again, it is the dilemma of does FS bring everything to a halt, or do they continue to work on a functional product, revising the various interconnected parts as they are doing today, releasing portions of the code and hoping that those sections do not adversely impact other sections?

    The only viable solution is to continue running the car down the interstate, now with increased speed, and continuing to work and improve various parts of the vehicle. It is a good idea, but we are not dealing with a new product, but one that has evolved over one hundred and fifty years and continues to evolve as society itself evolves and the definition of family continues to change, even from a legal point of view.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated

  • I assume the daily updates involve minor tweaking of the code(s). I believe this is what Michael was referring to in his original post. Then there are the "Monday" updates - again these do not usually seem to produce any noticeable enhancements - i.e. new features being created in Family Tree. Finally, there are major updates, where changes really are noticeable - and usually notified to us, via the Blog or a newsletter.

    All these types of update can produce some conflict within the program, but the main argument I am pushing is - if at all possible - to update the code only when absolutely essential. Unless the system would otherwise collapse, or become very unstable, surely making changes a number of times in a day is just counterproductive. As I have asked earlier, why not "save up" any required updating and (after testing, where possible) release the updates much less frequently?

    This possibly shows my ignorance of how a program like Family Tree is maintained - if so, please can Clif (or anyone) tell me why this idea could not work. Are most "comparable" products subject to the same updating routines, or are many tweaked far less often than Family Tree and still manage to meet the needs of their users?
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated

  • Thanks, Tom for reposting the car analogy from so long ago. It still applies, today, except now the car has been running so long that many of the parts in the car are no longer in production, and so if we want to maintain the car long-term (which we do), we need to upgrade those (perfectly functioning) parts and systems to their modern analogs. Oh, and fluids are running low.

    Paul, you are correct that the vast majority of daily updates are very benign in nature: updated wording, shifting an element a few pixels, better handling of a specific error, adding a link, etc. The decision to remain agile, regularly releasing small changes comes in the wake of us having done exactly as many of you had suggested, with the entire organization coordinating one single massive release every four months. Nobody knew what caused any particular issue, because literally every team's code changed at the exact same instant, and the next four months was used to track down the issues caused by the last release.

    As I stated above for everyone questioning our basic reasoning skills, we have as many safety nets in place as possible (automatic static analysis and linting run on every commit, required structured code reviews for every change, automated builds that run unit, component, and acceptance tests, regular cross-team coordination meetings, and server monitoring and automated alerting). On my team alone, I would guess that these checks keep 75% of potential issues from making it out the door and onto your screen. The remaining 25% are unfortunately the operating cost of an agile environment. However, the ability to instantly break something, also means the ability to instantly fix something. Just five years ago, using the suggested monolithic release model, you would have had to wait three months before a fix was deployed for an issue you reported...note that the OP found that most issues were fixed within a week.

    This will be my last response to this thread, as I feel the OP's original desire has been met: the experience has been acknowledged, as well as explained.

    'Till next time,

    - The Engineers
    • "Nobody knew what caused any particular issue, because literally every team's code changed at the exact same instant, and the next four months was used to track down the issues caused by the last release."

      Point taken and an excellent argument. If indeed the qualification for going into the daily continual updates is a (intended) benign change, then that seems fine to me. Without knowing that before, I had to be naturally suspicious.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated

  • Clif

    I know it should have been commonsense, but I do now accept the argument that updating too many things together (as illustrated above regarding the last major release) can make it much more difficult to identify which of these caused the resulting problem/bug/glitch, or whatever term you want to use for something going horribly wrong after an update!

    I was only looking for a reason for the application of constant updates and thank you for your explanation. If a certain amount of glitches are unavoidable, it's obviously best to have a system of updating that both keeps these at a minimum and makes detection of the causes as easy as possible.

    Thanks for your response and all your work.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated

  • I don't quite see the connection between having a written specification, and how often you release new bugs. Is there in fact a written specification?
    • Woody I suspect there are written items but things change so fast and frequently that sometimes what one person does walks on top of another. Todays software is very different from what you probably worked with in the Aerospace industry. There are multiple servers interacting with multiple users throughout the world. Each accessing multiple data bases. Because of these interactions it is almost impossible to think of every interaction which can result in something that appears to be a bug. I have programmed very large simulation models which took huge amounts of computing time and we used some of the methodologies you discussed. But if was a completely different type of software than is being used in Family tree. From discussions I have had with some of the FamilySearch developers - there are many factors "behind the screen" that we do not see or understand which create these issues. Myself, I do not find them much of an issue with doing what I need to do. It reminds me of Hardware failures in the "Old Days" when the computer was down or needed a reboot so I could not use if for several hours. Not something I can really worry about or fix.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated

  • The thing that rescues this situation...

    - and from the descriptions given here, and also from familiarity with FamilyTree's performance, this whole thing is a huge sack of ill-fitting parts mostly designed by amateurs, with a fundamental paradigm from the Mormon frontier, where folks have an immensely practical outlook but don't know how to model reality on a computer very accurately -

    ...is that it's all being guided by an army of people on the other side who are not limited in the same ways we are. So where we'd say if this system keeps working it would be a total miracle, well, that's exactly what's going on.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated

  • I think we should give credit to what the folks at FS have done.

    There are very few products that have to deal with collaborative writing of data and the scale. We are talking about 1.2 Billion persons, 14 Billion relationships between them, 1.3 Billion Sources, 6 billion indexed records.

    There are 9.6million users doing 5 million page views per day and 125 million transaction per hour. 

    In many ways FS is the pioneer in large collaborative data. Their expertise comes from companies like Amazon, Google. And FS is non-profit. Yes, its not perfect and like any endeavor it relies on skill, a little luck, lots of perseverance, and guidance.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated

  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated

  • Em qualquer sistema de TI, há e sempre haverá problemas, seja em sites ou softwares, que já é de costume as tais atualizações de versão tipo o MS-Windows, desde a sua primeira versão até a sua última, foram corrigidos problemas e novos problemas surgiram. Resumindo, isso faz parte do projeto, sempre haverá alterações, correções e modificações, assim que funciona, como disseram, todos nós somos humanos com seus erros e acertos. O importante ressaltar é que estamos evoluindo, crescendo e isso chama-se progresso. Parabéns a todos que idealizaram o site e com certeza vão conseguir na prática o que um dia foi idealizado na ideia inicial de termos a chance de unir todos numa enorme árvore.
    • Google translation:
      In any IT system, there are and there will always be problems, whether in websites or software, that it is usual for such MS-Windows type version updates, since its first version until its last, have been corrected problems and new problems emerged.

      In short, this is part of the project, there will always be changes, corrections and modifications, so it works, as they said, we are all human with their mistakes and correctness.

      The important thing is that we are evolving, growing and this is called progress. Congratulations to all who idealized the site and certainly will achieve in practice what was once idealized in the initial idea of ​​having the chance to unite everyone in a huge tree.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited indifferent, undecided, unconcerned sad, anxious, confused, frustrated