Static Windows inhibit work and cost time in Family Search
Comments
-
Tom Huber said: I think we all have our own, perhaps unique only to us, approaches, Joe. For me, I prefer to use a double-screen system and three separate trees.
One is my local tree, under the control of Ancestral Quest. I have my own citation format that follows an older bibliographic format that I use with it. Each citation that I create, I try to incorporate at least one image and because this is my private tree, I don't worry about copyrights or any other legalities, including privacy laws. The resulting record is not only complete with where the record is found, but also contains a copy of the pertinent material (which is legal, since it is not a complete document and falls under United States "Fair Use" elements of the U.S. Copyright laws.
My second tree is located on my Ancestry account and also contains my living individuals. It is a public tree, but Ancestry does not reveal any information (including name) for the living persons.
My final copy is part of the massive FamilySearch Family Tree. It is the last to be populated fully and contains minimal records of living persons (at this point, not even necessary since my parents' generation is all deceased and I use my Ancestral File database to track my children and their families.
Operation is relatively straight-forward with my AQ tree on my laptop's 17" screen and everything else accessible on my big 24" monitor that is an extension of the laptop's screen.
Copying and pasting is relatively easy between the various elements.
When I post something new to this forum, it may be because I have run into a problem and missed whatever is needed to take care of the problem. Someone (usually a regular) is able to resolve a lot of my issues. But there are some, like the static windows that open for sending messages, seeing search results, and so on, continue to be problematical and have resulted in reduce usability for the site.
Sometimes, it takes getting used to a new user interface. A good example of this is the new U.I. for Find a Grave. Ancestry bought out the site a while back and came up with a new User Interface. I think I've got the hang of it, but there are still some issues (that may or may not have existed with the old U.I.). Find a Grave has a user forum, so I may post my concerns over there and see what happens.
Going to what we've been told about the programmers getting four hours a week to work on their own family's history, I suspect that not many of them have ever sent a message to another user. Otherwise, they would understand the frustration that (I believe) all of us have with the fixed window, trying to remember what we wanted to say. Or, for that matter, the fixed window that blocks out the search results screen. Those are both research-related elements that are most widely accessed by users doing advanced research.
So, my question to Joe is whether or not he has sent many messages through FamilySearch to others who are working on his line and have made a mess of things? That quickly illustrates the frustration that we have with the current window and yes, that is a User Interface issue that is specific to the task at hand. Comparing it to the house, it is when I realize that I have the wrong type of paint and need to stop what I'm doing and go to the local paint store / department to find the right paint for the job.0 -
joe martel said: Plenty of messages. Most turn out very well. Yes, the UI is cumbersome and I have explained this in other threads as well.0
-
Tom Huber said: Bumping this issue for the beginning of a new FS work week. I appreciate Joe's responses. What I would like to know if there are any plans to get away from static windows?
Static windows are a real bother where they appear. At least with the search results we have the option of opening the entry in its own tab or window (right-click on the name in the results).0 -
Brett said: Tom
I understand, the "Static" Window in the "User Messaging" of "FamilySearch"; and, the reason for your post, which, like many I totally agree with you.
Please excuse my ignorance; but, a question if I may.
There are a lot of comments above, to wade through.
Are the "Static" Windows, that you refer to, similar to (or the same as) these infernal "Fly Outs" - especially, that now are the only available work space, rather than the option to open a work page/screen, that have recently appeared for, both, the "Couple" Relationship; and/or, the "Parent-Child" Relationship?
Or, are the the "Static" Windows, that you refer to, totally different to the infernal "Fly Outs"?
I know that 'Joe MARTEL' advised us in this Forum that the "Fly Outs" are now the way that "FamilySearch" is heading; but, I just wish that "FamilySearch" would RETURN the option to work in a full page/screen, rather than those infernal "Fly Outs", if we so desire.
Just curious.
Brett0 -
Tom Huber said: Those flyouts are also static in nature, so the same problem exists with them, in my opinion. And yes, "infernal" is a good adjective to use in describing them.
Like lumping together change logs by event / fact type being a major mistake, so is the use of flyouts.
They are a pain and can easily be closed by clicking off the flyout while attempting to use them.
Bad, bad design decision.0 -
Brett said: Tom
'Thank You'.
I thought as much.
The Designers and Programmers may like the "Fly Outs" (and, other "Static" windows) that they have foisted upon us; but, many of us Users/Patrons DO NOT.
It is unfortunate that the Designers and Programmers, can; and, do, dictate what us Users/Patrons WANT and NEED.
It is too bad (in fact, very unfortunate) that the Designers and Programmers DO NOT remember that it is the Users/Patrons who SHOULD be "Driving", both, the Design; and, Operation, of the "System".
Brett0 -
joe martel said: So a quick survey. Regarding, pop-ups, modals, flyouts, static, modal, dialog boxes ... whatever you want to call them, for this discussion, "overlay".
If I had an overlay that I could configure when designing a page or workflow what would be the different attributes? And what are the guidelines when to apply an attribute or not?
Attributes:
A1. Moveable
A2. Obscure/gray the background
A3. Maximized (takes up the entire application window)
A4. ... ?
A5. Can create a new tab/window with this focus.
Guidelines:
G1a. If the background information is not needed to be seen by the user then the overlay is "Not Moveable" and "Obscures background" (This is a common practice in UI to not overload the user with distraction and clutter and noise when accomplishing some work)
G1b. If the information needed by the user to accomplish/analyze or dismiss the overlay is behind the overlay then the overlay must be "moveable" and "Not obscure background".
G1c. If the necessary info is replicated in the overlay then it may be "Not moveable" and "Obscuring"
G2. If a situation occurs where the overlay can't be Moveable (mobile apps) then the overlay must replicate the information needed by the user to accomplish the overlay task.
G3. Maximiazed should be rarely used (When?) because it causes loss of context by the user.
G4. An overlay is used when a User has a subtask to accomplish, and after the overlay is accomplished they are back where they came from?
Just thinking out loud.
0 -
Adrian Bruce said: Joe - thanks.
Some comments off the top of my head.... (No promises these are all or even the most important)
G1a "If the background information is not needed to be seen by the user ..."
It is quite difficult to see how that situation actually arises. After all, we were *there*, we are now *here*, so there must be some context to bring us from there to here and therefore something about *there* that is still relevant to here. Or maybe I could summarise it by saying that my gut reaction is that we get too many G1a.
G4 "after the overlay is accomplished they are back where they came from" Interesting - I was cursing (mildly) the relationship flyout earlier today, so this is in my mind. I was dealing with a couple relationship and wanted to see and work with a source that I wanted as a Relationship Source.
The sequence went:
- Profile of husband;
- Click to show Couple Relationship flyout;
- Locate the source (already on the Couple Relationship);
- Click View Source
(To get the best view of the Source that I'm now viewing, I need to manipulate scroll bars on *2* windows. Confusing. Doesn't this mean that the Source View is really too big for this set-up?)
- So I decide that the Source record is too big for this window, so I click View again to take me to a Source View Edit of that Source;
- After I've contemplated the larger view, I click "Go to: Couple Relationship"
- This doesn't go back to the Couple Relationship which is on the flyout but to the original profile where I started.
This seems to convey a couple of lessons.
1. Your G4 rule (which seems sensible to me) has been broken by this sequence - presumably because I've broken out of the flyout and can't get back in??????
2. Some of the stuff is just too big to fit comfortably inside a flyout. So there needs to be some sort of Guideline about sizing in there - not necessarily the size of the initial flyout, but of what goes on it...0 -
Adrian Bruce said: Yeah - the Couple Relationship flyout itself first appears with its title obscured and the lower parts obscured. I manipulate one slider to see the Title and another (the one on the flyout) to see the lower parts. Confused?
It's just too big to start with, isn't it!!!0 -
Tom Huber said: I realize this is a little old, but I'm going to add to Joe's last comments (and thank you very much for joining this discussion).
I think that most of us (me, at the very least) would prefer to see some of these open in their own window or tab. The Couple relationship flyout is a good example. There are instances where I have found it to be almost completely unusable because of its fixed width (and now way to slide the area to one side or the other. In the past, we could open that in its own window and that made it eminently more usable that it is now.
So, if anything, I would opt for the flyouts to optionally open in their own window (much like the search results modal window does now). By being able to right-click on the name in search results, I have the option to open that entry in its own tab or window. I cannot do that with the family flyouts.0 -
Brett said: And, the "Parent-Child" Relationship.0
-
Juli said: No, 'Not Moveable' and 'Obscures Background' overlays should be reserved for one, and only one, use: an extremely important error message that MUST be dealt with before the user can continue. That is the ONLY acceptable use of a modal window. EVERY OTHER USE should be moveable, resizeable, and most importantly, openable-in-a-new-tab-instead.
(Note that in terms of workflow-prevention, 'Obscures Background' and 'Maximized' are exactly equivalent.)0 -
Tom Huber said: Absolutely, Juli.
Joe, this whole thing is about what we see in a browser window. Mobile Apps for iOS and Android, have by necessity, be different. They should never be confused with the browser app.
On G3 -- NO, no, no! We do not want a maximized window to replace the existing window. We need it to be opened in its own new tab or new window. That is the way the original couple relationship area worked and we need that back.
On G4 -- Why an overlay at all? Juli is correct, the only time an overlay should be used, which includes the modals now being used, is when there is an extremely important error message that must be dealt with before the user can continue.0 -
Adrian Bruce said: Not necessarily just an error message, which implies no input other than "OK" but also any critical step that absolutely must be completed and - importantly- needs zero reference to anything that's gone before. Logging on is the classic example of a modal screen with input that must be completed.0
-
joe martel said: Just an update.
There is work to revamp the UI technology for the site and part of the work is to consider a new set of UI components. Core to that are "overlays". There are different overlays depending on the use: Whole screen, Dialog, Quick, slide-out side, Help tips, Menu, status. They each have their use.
The dialog overlay is probably the closest to the application discussed above. It's purpose is to collect input from the user to continue the task on the parent page. So that wouldn't open a new page/tab since it is subordinate to the parent page. Many times the user may want to refer to the parent page for the input (say a message to another user about the ancestor page they're on). I would like the default for these dialog overlay to be moveable and very little background greying.
These are in design and some pages will start to incorporate the new components. But this will take time. And adjustment as testing and user behavior findings come in.0 -
JT said: A1 !!0
-
Juli said: Adrian, except there's absolutely no reason to make a login screen immovable, and there's very little reason to obscure the page behind it. (Some people think it's "less confusing" that way, but if you can't tell apart the login screen and the page behind it, perhaps the design department needs a whack upside the head with a clue-by-four.) The only requirement for a login screen is that it must remain in front of the page it's associated with, preventing interaction with said page until login is successful.0
-
Juli said: If the purpose is to collect information from the parent page, then WHY in heaven's name would you want it to be any kind of overlay? Why not collect the information where the information _is_, on the parent page?
I'm sorry, but I do not see any value in overlays. They _always_ impede workflow, no matter what. Some are simply worse than others.0 -
Adrian Bruce said: That's perfectly true Juli. I was answering as if we were talking about modal dialog boxes, rather than these new fangled overlay beasties.
Oh dear. I have to say it.
These overlays are solutions in search of a problem, I fear.0 -
Tom Huber said: Maybe we need to put together a list of overlays that we see bothersome.
I'm going to start with:
1: Couple relationship -- while a quick view (basic flyout) is permissible and okay for breaking apart a relationship, any changes beyond the relationship itself really need to be made in their own tab or window, not an overlay or modal flyout.
The only permissible would be this area of the flyout with the ability to open the entire relationship area in its own tab or window:
The above is with Harriet being the person's page. The same Remove or Replace would appear for her if this was Philander's page.0 -
Tom Huber said: 2. Child-Parent Relationship. The same applies. The only time this would be permissible as a flyout would be for breaking apart the relationship of the child to either or both of their parents and declaring the relationship of either or both of the parents to the child. Otherwise, we should have the option to open a child's relationship page in its own tab or window:
There are also some redundant elements in this area that need to be cleaned up. The reason statement for the child, The Edit and + Add relationship, and the Last Change By - They are unneeded in a flyout where the only actions are to deal with relationships. Of the redundant elements, the Edit should stay, but the +Add relationship needs to go.
0 -
Tom Huber said: The other option in #2 above would be to replace the Edit with Edit Relationship Type on its own line. There is no need for a + in that situation. Right now, aside from presenting the last contributor, the Edit (with contributor) and the + Add Relationship (currently missing contributor) are essentially the same. What is missing is the change history (there is no way to get to it).0
-
Paul said: This feature continues to be intensely annoying. Having to close the static widow ("overlay"?) before returning to the search results page impedes the natural flow of attaching a source, then going directly back to add the next, etc. But wherever it appears it causes extra work.
Surely the engineers can see the introduction of this feature has not been an enhancement to any process, so it needs to be scrapped at the earliest opportunity?0 -
Jeff Wiseman said: There MIGHT be a bit of convenience in the programming of the web pages, But that is no excuse for using the wrong widgets for the application. It's like using a screwdriver for a hammer.0
-
Juli said: According to my sister the web programmer, popups, especially modal ones, require way more programming than a simple "open in a new tab" link. So it's not a case of being more convenient, but a case of seriously incorrect thinking.0
-
Tom Huber said: I honestly don’t know why FamilySearch is so reticent about getting rid of the modal windows. It seems like this (and othe badly dissed ideas my users) have become a matter of pride by FamilySearch management— they really need to let us users know if they are not going to address this issue.0
-
Brett said: Tom
As I have suggested in other posts ...
"Family Tree" of "FamilySearch" NEEDS to be DRIVEN by the Users/Patrons; and, NOT, by the Designers and Developers/Programmers/Engineers.
New developments in "Programming" DO NOT need to be implemented UNLESS they, IMPACT; and, are REQUIRED, to enable a "System" to work.
"Change" just for the sake of "Change"; because, of the whims and preference, with regard to New developments in "Programming", is NOT necessary.
Brett
.0
This discussion has been closed.