suggestion-make pop-up boxes movable

LegacyUser

David Roderick McLean said: When editing (auditing) a person page, I would like to be able to move the edit pop-up box.

Often the information I want is actually behind the box. If I could drag the box away to see the information on the person page it would be helpful to me.

Example:

LegacyUser

Paul said: Better still - as has frequently been suggested - please remove the boxes altogether, by reverting to the original display and thus allowing for consistency within FamilySearch. A dreadful feature when it comes to needing to view several records on a page at the same time.

(I wait in dread of pop-up boxes suddenly appearing in the Sources sections in Family Tree, too. That would completely mess-up my being able to compare, say, opening multiple census records and scrolling between one and the others. )

LegacyUser

Justin Masters said: This has been suggested before. Search for modal windows

LegacyUser

FamilySearch Moderator said: Thanks for this request. It is a common one and hopefully new designs will address this.

LegacyUser

Paul said: Thanks for showing there is a difference in the meanings of pop-up windows and modal windows. Is what FS uses a sort of hybrid of the two? I'm thinking of the arrows that let you move on to the next / previous record without having to shut the window. Reading definitions of modal windows gives the impression you are completely fixed on the record (in the window) until you close it.

LegacyUser

Justin Masters said: Modal windows is the "technical name" for windows that pop up (typically for alerts or actions that need to be taken) that do not have "handles" for resizing, moving, etc.

So for the term hybrid... I suppose that's true, since there's some degree of functionality within the window other than just a "Okay" or "Do this action".

It's encouraging to see that there may be some design changes that address this.

I know it's really an impact to people with single screens. Not as bad for people with dual screens, who can open a person page on the other screen to see "under" the pop-up window... but this shouldn't be the workaround for this. One could at least make it semi-transparent. :-) Or have a slider or mouseable region where it disappears and you can see under/through it.

LegacyUser

Paul said: Thanks for the additional clarification, Justin.

LegacyUser

Jeff Wiseman said:

Reading definitions of modal windows gives the impression you are completely fixed on the record (in the window) until you close it

That is exactly right Paul. Modal windows were SPECIFICALLY designed for applications where you need to totally take control of the screen and lock out everything else in order to force you to make a decision on something before you can do anything else.

Most of the uses of modal windows at FS do not require this. They are being used in a fashion that they were never designed to be used for. Therein lies the problem.

LegacyUser

Ken G Moyer said: I have to agree with all the above comments. I to, would like to be able to move the window around as I like to compare the new against the old info and I would like to see the 'black' background to be a lighter shade to make the underling info easier to read. Thanks, Ken Moyer

LegacyUser

Jeff Wiseman said: Ken, that's just a way of modifying a Modal window so that you can get around the fact that it's modal. The real solution is to just STOP using modal windows for applications and features that don't NEED a modal type operation.

Login windows can be modal. "Are you Sure?" type windows can be modal. But windows where you a composing a significant amount of text almost ALWAYS NEVER have a requirement to be modal. Therefore, they should NOT be implemented in a modal window.

LegacyUser

Tom Huber said: There are areas where the modal window is a really bad move -- specifically when working on a person's family section and clicking on a pencil icon -- previously in the couple area, one could open the area in its own screen. The worst part about its use here is that the window disappears if one accidentally clicks outside the window while editing it. There is no option to save the edit--the window just closes.

LegacyUser

Tom Huber said: There are areas where the modal window is a really bad move -- specifically when working on a person's family section and clicking on a pencil icon -- previously in the couple area, one could open the area in its own screen. The worst part about its use here is that the window disappears if one accidentally clicks outside the window while editing it. There is no option to save the edit--the window just closes.

I complained about this the first time I saw that the option to open the "fly-out" in its own page was gone and that was acknowledged.

It appears that FamilySearch has no intention of abandoning this horrible method on its site.

LegacyUser

Tom Huber said: The removed comment (by me) was deleted (by me) and copied into my reply, below.

LegacyUser

Jeff Wiseman said:

There are areas where the modal window is a really bad move...

Exactly right. That is when it is used ANYWHERE that the application it is being used for is NOT MODAL in nature!

When you reach for a tool to pound in nails, you DON'T use a screwdriver, even if it IS sitting much closer to you than the hammer is!

I've not actually done any programming for websites, but I have to assume that there is some kind of technical convenience in using modal windows which has been the impetus for their significant increase on the website. Never the less, in nearly all cases that I've seen, they are plainly the wrong tool for the job.

LegacyUser

Justin Masters said: I'm not a web developer (and I didn't sleep in a Holiday Inn Express last night), so I want to give my "opinion" and be understood to be just that.

I don't know what the decision process was behind the use of modal windows for doing "complex data input" operations, and perhaps it grew from an original operation. There may be behind-the-scenes optimum operations where values are passed to a modal window, and data recalled back that are "easier" to process than attempting to do so through the opening of a separate window in a stateless environment.

If you stop and think about it, having a NEW tab open up for more "proper" data entry does not force the original tab that spawned it to refresh. It would violate a number of security principles to allow one tab to "back-effect" a prior tab.

One example to this kind of operation (or lack thereof) is the process of evaluating a source from the personal page. When you do choose to attach a source, a new window is opened. People mentioned in the source are attached to the people within FamilyTree. If you chose to close that window with a browser control ("X") in the corner, you'll return to the original person's tab, with NO information updated. (It's as it was shown at the state that it was rendered). In fact, the method by which I THINK you're supposed to go back to the original page, is via the person's link in the upper left corner. But that changes as each person rotates into the "primary position".

Contrast that with a "modal window" like the entry of updated vital information. When that window is closed, SOMETHING is triggering a refresh of the page (info is updated, perhaps the "Research Help" portion is updated (sometimes not a good thing) and available sources changed.

So, it's possible that a modal window was the BEST option for being able to get a window updated... the side effect is that it covers over other information on the page.
And by coding standards, modal windows don't have handles or controls to move it.

LegacyUser

Jeff Wiseman said: Right. So why would you break the normal workflow on a feature just by implementing it in a way that was easier, or more convenient to code?

Yea, I have no doubt that there was some kind of advantage to it, but it interferes with the normal workflow of using the site when it is used in NON-MODAL situations. I can't remember the number of times I've got locked into a modal window and then realized I didn't have everything written down on paper before I went there. I also have had times where after quitting out of the window to go foraging for data and then returning to the window, I've gotten most of the way through and then realized I had forgotten something else. Thus I've had to throw away everything and start over again. You can mitigate some of this by doing all of your text work in an outside text editing app so at least you don't have to remember what you had to throw away.

It didn't use to be this way.

As far as the refresh issue goes, it is a side effect of using a browser since doing so adds all kinds of race conditions to the application that the designers have deal with (and they are complicated to resolve. Sometimes the only solutions have side effects that are highly undesirable). This isn't only limited to data entered in modal windows.

LegacyUser

Justin Masters said: I wonder if it's worthwhile to assist in the stateless aspect of the various displayed pages if personal pages have each vital field with a 64bit timestamp invisibly embedded with it, and when you're working across multiple tabs, any edit to a field, also gets a new time stamp upon saving that vital info. Any other previously rendered pages (with their earlier time stamp) and a change to that field there alerts you to the fact that it's not the latest version when you try to save that info.

It also may introduce a lot of overhead in handling / passing data related to a timestamp value and "arbitration of state". It might also complicate any 3rd party tool that attempts to update a field that someone happens to be working on elsewhere.... so... never mind. :-)