Static Windows inhibit work and cost time in Family Search

LegacyUser

Tom Huber said: There has been a trend (most recently represented in the Search Results page) of opening a static -- meaning cannot be moved -- window over an existing window.

This has long been a problem with sending a person a message and more than once I have had to close the message and open an external app to compose my message. I believe this has been brought up a number of times, but it has never been addressed.

Now we have the static details window that opens over the search results, instead of inline. Again, it effectively hides the search results when it is preferable (for me at least) to open the results in their own tab.

While this can still be done, the old method of click on the name to expand the results for that person and then click on the name to collapse the results for that person was many times more useful. Now, we have to dismiss the window.

Please move away from static windows in FamilySearch. They cost us time and extra effort, sometimes even requiring that we open a separate application as is the case with the message static window.

LegacyUser

Juli said: There is only one excuse for the existence of immovable obscuring-type popup windows, and that is to convey urgent error messages that must be dealt with before any further action can be taken.

NONE of FamilySearch's applications of immovable popups even remotely fits this description.

FS's usage should be deprecated and shamed as badly as frames or the use of tables for page layout. Immovable popups _always_ obscure exactly the thing you're trying to work on, and require workarounds like always having things open in duplicate. They're like hammers with a hinge midway along the handle: either you hold it near the head and lose the leverage, or you try it with two hands (with a helper risking life and limb holding the nail).

LegacyUser

Carolyn Wheeler said: Amen!!!

LegacyUser

Jeff Wiseman said: Exactly. They are NOT being used for what they were designed for. With that one exception, modal windows always create handicaps.

However, the fact is that there has been significant complaining and significant REASONS given to avoid the inappropriate application of these things over the past several month. When you consider the recent addition of their use in even more inappropriate places tells me that the mind's that prioritize these things at FS are already made up, and these are here to stay (meaning further complaints will be ignored as not being important).

I suppose that there might be some compatibility and/or bandwidth benefits that are presumed and being attempted by the decision makers, but the loss of real functionality on the website because of these modal windows is ridiculous. It's getting to the point that I can't even function without having to always have a separate text edit window sitting open on the side

LegacyUser

Jeff Wiseman said: And why is it that when you first log into FS you still don't get one of these windows that pop up and have a brief blurb on how this is a shared tree and EVERYONE has write access to it?

THAT would actually be a CORRECT use for a modal window!

LegacyUser

joe martel said: Yes, there are problems with how some UI is used, misused. Just so you know this is a recent article confirming Juli's reply. It doesn't discuss how the popup should be used in the context of contributions, which is where the greatest disruption in user workflow is happening. Can't say when the pendulum will swing back: https://www.nngroup.com/articles/popups/?utm_source=Alertbox&utm_campaign=f5239197b7-Popups_AttentionEconomy_ConfidenceIn_20190701&utm_medium=email&utm_term=0_7f29a2b335-f5239197b7-40269809

LegacyUser

Jeff Wiseman said: Thanks for that info Joe! Great article on Popup usage. In fact that site has a wealth of information on product usability.

From the very first sentence of that article:

From conducting decades of user research, we know that people dislike popups and modals

This is really NOT a new thing! Research and information on how to build User Interfaces "Correctly" has been around, and has been available to engineers for decades.

You would be surprised at how many UI type discussions that have recently been on Getsatisfaction.com that would probably have never come up if simple usability principles had been followed.

Much of this type of information has been around as long as (or longer than) the engineers that should be using it. In some places that I have worked, they have employed "User Interface Engineers" who are familiar and specialize in the use and engineering design with these principles.

Since I have been aware of usability issues in the design of products for many years myself, continuing to see blatant violations of UI design 101 kinda makes me crazy :-)

LegacyUser

Juli said: As a concrete example of how the immovable popups impede usability on FS: I'm trying to add some parents based on an indexed birth record. The register entry gives ages and specific birthplaces for the parents, but those details have not been indexed. Despite having a bachelor's degree in mathematics, I'm horrible at remembering numbers, so I wanted to look up the parent's age. The first time I tried, I hadn't gone back to the source yet to tag it to birth (in addition to the name and sex that was all that Source Linker would allow), so there was no source in the obscuring window to look at. So I canceled, added the tag (lost track of how many extra clicks that involved), and went back to edit the birth -- but discovered that the source display in the obscuring window does not include the Notes field (where I had put a full transcription of the record).

With the proliferation of obscuring popups and separate panes, working in FamilySearch's Family Tree has become a series of workarounds around workarounds. Has _nobody_ at FS studied user interface design and theory?

LegacyUser

Robert Wren said: Joe, thanks for posting that excellent article!!

I eagerly anticipate the ideas to be applied to FSTree, so I will no longer have to cancel a half written FS mail, because I can't access the underlying page which contains the info that I'm trying to write about.

PLEASE urge the decision to implement this as a priority. This isn't the first time this has been suggested in this forum.

LegacyUser

Jeff Wiseman said: Has _nobody_ at FS actually tried using the system after these "improvements" have been made?

At one point we really didn't have these issues to work around. Not sure what is going on but from an outsider's view, you get a distinct impression usability entropy marches on...

LegacyUser

Tom Huber said: Just a quick note. Here in the United States, it is Independence Day week and in many instances, people take the week off. Joe and Ron appear to chime in almost any time, so they may respond, but as far as the rest of the Family History department that is connected with FamilySearch development, I don't expect much in the way of responses.

Or fixes...

Hopefully, I'm wrong, but most people do like vacations.

LegacyUser

Adrian Bruce said: "Despite having a bachelor's degree in mathematics, I'm horrible at remembering numbers" - an aside - people always think that we're good at arithmetic. Nooo... Why do you think "we" invented algebra? To avoid doing real sums and remembering real numbers!

LegacyUser

Juli said: Adrian: ayup. Mathematicians invented algebra and calculus to avoid doing arithmetic. :-)

LegacyUser

David Newton said: They even had to come up with imaginary numbers to avoid dealing with the real numbers. Unfortunately that just made things more complex.

LegacyUser

Juli said: THWACK!

LegacyUser

David Newton said: What's wrong? I'm naturally good at making exponentially bad jokes so I get a slice the comedy pi. You just have to circle round to get to the worst jokes. It's simply a sine of the times.

LegacyUser

Tom Huber said: I'm not sure she was thwacking herself or you in her response. I got the joke and happen to fully agree.

LegacyUser

Jeff Wiseman said: Tom: I think that was the sound of her palm hitting her forehead!

David: "You just have to circle round to get to the worst jokes. It's simply a sine of the times"

THWACK!

LegacyUser

Juli said: The rule in our house is that punsters get thwacked.

LegacyUser

David Newton said: I make sure my humour has an integrated approach. It differentiates me from others. In reality it's the smallest changes which turn things from just bad to truly terrible.

I guess I'm just too set in my ways for some people. Their jokes have no intersection with mine so any attempt at a union of contributions is pointless.

LegacyUser

Tom Huber said: Juli added a new discussion that mentions this problem: https://getsatisfaction.com/familysea...

LegacyUser

Adrian Bruce said: Just as an aside, FS isn't the only guilty party - I just tried to set up a filter / mailing rule in my GMail in the browser and (as often happens) its attempt at the condition for a rule was meaningless - so I attempted to replace it with a criterion based on the email address - except the box covers the email and it can't be moved so I have to close it down, copy something and start again. Who knows maybe it might be better if I used Google's own browser but I refuse to be treated as a child.

And GMail doesn't add horizontal scroll bars if you narrow the browser window too much... Hmm - (tongue in cheek) wonder where FS learnt its UI techniques?

LegacyUser

Tom Huber said: Yeah, it is an ongoing problem, not only with FS, but also other sites.

Back in the earlier days of the internet, the programmers did not have the automated tools that are being used today and wrote relatively tight code. The tools bloated sites badly and they still do.

FS is impacted by that bloated code and is in the process of rewriting the code that is currently being used in production. The problem is that whatever tools are being used, certain elements are not followed as they should be.

Yeah, this is yet another gripe about FS not having/using any kind of style guide for the site elements. I'm not sure they will ever follow good programming advice and standardize their own site, but continue to allow whatever development team to "do their own thing" with regard to how the pages they design work.

I'm tracking this particular issue because it needs to be resolved. We need the ability to not have a form into which we write information be static, but be movable, perhaps to a second monitor (and yes, I run with two monitors, one being an extension of the first). But with a static form, there is no way I can see what is behind that static form.

In some cases, that is not a problem, but in the instances here, the static form is a problem and will continue to be a problem.

LegacyUser

Jeff Wiseman said: Right! It needs to work the way it used to.

(Wait a minute! That comment really sounds familiar...)

LegacyUser

Adrian Bruce said: So does the bit in brackets.... :-)

LegacyUser

Paul said: This certainly backs-up the theory that the programmers are not active in research of their genealogy! My worry is they might adopt a similar practice in the Sources section, so - instead of being able to keep a number of sources open at the same time (e.g. to compare contents of two different sets of census records) we might have to click on an arrow to get to the next record, once one is opened! Sounds silly, but anyone examining how the two features work will see it is unreasonable to delay reverting to the way things used to work when viewing search results. (The "Messages" problem needs to be looked at, too!)

LegacyUser

Adrian Bruce said: An interesting point there. Do the designers of the User Interface realize the necessity to have multiple windows open at any one time? Or do they imagine that the system is so self contained that we can deal with one window at a time, gathering all the information that we need to have, just from that one window?

Disturbing. Like you get the ability to dismiss a possible duplicate immediately you are told the name. Without you even open up the other guy's profile.... No. We need multiple windows open at once.

LegacyUser

Jeff Wiseman said: Adrian,

Regarding your questions.

1. I believe that complete Use Cases are not being fully developed (if at all) before the code modifications are performed. This would reveal things (such as the improper dismissal of duplicates before being able to actually look at them before they got into the software. This is an example of a decades old problem in software engineering where a group "Doesn't have the time or resources" to create detailed and traceable requirements for the design to be based on, but apparently they DO have the time to fix mistakes and redo the design multiple times until they get it "correct".

2. As far as windows goes, I know that FS tries to keep the function of the mobil app and the browser interface (as used on desktops) similar in operation as much as possible. You can create a mobil app that supports multiple windows, but you can't easily put them side by side when doing comparisons. However, the concern for operation of the mobil apps would have the capability of influencing the desktop operations significantly--especially if the engineers developing it don't have a really good idea of what the details of required Use Cases should be.

LegacyUser

Adrian Bruce said: Jeff - your point about the mobile apps is a good one. I confess that I have very little feel for how I would like these tasks to look on a smartphone. And zero idea of how the code-base on the 2 platforms can be aligned. So alignment is not, I am sure easy.

(Theoretical and possibly heretical question: Is strict alignment worth it? How can you even start to answer that question unless you have an optimised workflow / use cases on both platforms in mind?)

Incidentally, I was really impressed with the look of the Android app for FS - it felt a much nicer and well balanced design than the browser version! So I'm not anti-smartphone...

LegacyUser

Jeff Wiseman said:

Is strict alignment worth it? How can you even start to answer that question unless you have an optimised workflow / use cases on both platforms in mind?

Exactly! The set of use cases on a mobile phone is DIFFERENT than those from someone using a desktop. Furthermore, since the Design Constraints (also something that should be formally defined as part of the requirements) are quite different between the desktop and the different mobil apps, Use Cases that are THE SAME for the different platforms are guaranteed to have different designs to some degree or another. Adding the design constraint that they all must have the same "Look and Feel" further exacerbates the problem.

There are significant trade-offs in making the interfaces all similar, the cost of which is the reduction in optimization for the platform based on its required use cases. A desktop typically will have more Use Cases than a tiny screen mobil device will. Are you going to cripple the required desktop Use Cases in order to support a common "Look and Feel" with the mobil apps? Priorities can always get scrambled when they have not been documented as the traceable path forward.

And by the way, that was NOT a heretical question :-) It is a typical engineering question that comes up very frequently in many areas of industry. And you are correct. Without a complete structural requirements analysis documented with the corporate assigned priorities, you CANNOT answer that question with any reasonable degree of reliability.

Without this type of thing in a company's formal engineering process, they are doomed to continual churn on their products until the cows come home.

LegacyUser

joe martel said: I'm hesitant to mention this but I like this discussion and would like to give my approach.
My main methodology is called Contextual Design. One aspect that I lean on in my design and analysis is to first decide what intents/purposes this feature should facilitate (from user inquiry).

I create a User Environment (UE) that's kind of like a house blueprint. Each room has intent(s) and the tools necessary to accomplish that work. And those rooms that are related in workflow are close to each other (Kitchen and Dining room). So in the product UE each room is represented as a Focus Area - a place where the user focuses on getting that job done. You can run workflow - use cases - scenarios against the UE to see if it falls apart somewhere.

The UE is UI-agnostic, meaning I'm not worrying at this level about specific UI and platforms.  The UE is also technology vague. Work is still the same work. It's like the Genealogy Workflow I showed here a couple weeks ago. 

Once I've tested with users the high level flow and function of the UE (say with a paper prototype) and fixed it, then I can start thinking about what this house is really going to look like. This is the UI, colors of paint, flooring, light switch placement. Now the platform comes into play and mobile app with its tiny screen and lack of multiple window support may cause fragmentation of Focus Areas or loss of functionality. Web client has to consider it lives in different Operating Systems and browser environment. Also, you have to consider diversity of your user. It rapidly gets very complex. But eventually this UE get implemented by various engineering teams for the multiple platforms.

At FS and every other producer of software has to consider all these variables. Some do it better than others. Some have a huge set of functionality (like FS) compared to very focused products. Keep the ideas coming though.