Closed FreeUKGenIssues closed 9 years ago
Sherlock21
commented
9 years ago We should not be having a Church name like: Castle Baynard (St Benet Paul Wharf (Aka St Benet Welsh Church)) [Transcript]. omit the AKA part. [Transcript] comes from the record type code & should be a distinct element - not necessarily in a field of its own, but with a space after the church, and permitted to wrap at that space.
Sherlock21
commented
9 years ago The point about WHY Surname First. The search results in FindMyPast come in Surname First then Other Names. Ancestry do it first names then Surname. FMP's format looks better in my view. If we could reduce the height of the colour blocks, and reduce the height of each record row, ours would then look at least as good as FMP. - in my opinion of course
Issue reported by Rob Hoare at 2015-04-17 01:17:30 UTC Time: 2015-04-17T01:13:34+00:00 Session ID: Problem Page URL: []() Previous Page URL: http://www13.freereg.org.uk/contacts/new Reported Issue: I've been testing out this new design, and I have one main problem to report and a few comments.
Problem: some search results, especially on narrow screens, have columns that fall off the page. This can make the "Details" column unreachable.
One reason is the "Location" on the search results page has a non-breaking space between each word (to make it appear on one line, up to the square brackets).
This forces the table that encloses it to be wide (to fit in the wide Location column, as it can't be wrapped).
So for many results, the screen is too wide for the page. Parts of the Location column, and often the whole of the detail column, fall off the page. This means there is no way to get to the detail record - it's unusable. (the table can't be scrolled horizontally). An example would be a result containing a location like Castle Baynard (St Benet Paul Wharf (Aka St Benet Welsh Church)) [Transcript].
It's not just a problem with a long Location name. For narrower screens (like a large phone or tablet in portrait mode), the wide padding around each table column can mean no part of the location (or details column) is even visible.
The pinch-to-zoom seems to be disabled as well (no excuse for that), so the user can't shrink the page to see the missing columns (if they somehow guess they are there). Altering text size on desktop doesn't seem to help either.
There appears to be a stylesheet for really narrow screens (under 571px), and one for other widths, so for the limited number of mobiles which are still that narrow, it sort-of works as the table layout is different.
The stylesheets need to be reworked into a mobile-first fully responsive design, rather than just assuming that anything under 571px is mobile, and anything above that is wide. That worked briefly in the early days of "mobile friendly" designs, but not now. Soon, if not already, most users will be using a mobile device (on my main site it's already over 70%).
A responsive table (with a similar look to your "mobile" one) could appear based on a media query, basically anytime the full table wouldn't fit, whatever the reason.
In a related issue, the text in results is very thin and light. The opposite of what is needed for readability. The search results for example have nice readable column headings, then faint results. It would make sense to reverse this. Losing some of the layers of boxes surrounding things, and less padding, would allow the text to be larger, or allow more text on the screen. The average age of those researching genealogy is higher than most web users, they have poorer eyesight. Clarity is more important than subtleness.
With all those surrounding boxes, the search form fields are very narrow on anything other than a wide screen. Even with the "mobile" version of the stylesheet, with just one box per row,the two layers of surrounding boxes makes the search fields narrow (only 1/3 of the width of the screen: 17mm of a 55mm wide screen). On a screen wider than 571px but still narrow (like many tablets) the four little boxes in a row with lots of blank space around them doesn't look very good.
Also on the "mobile" version, the results table doesn't actually fit on the screen (on my test phone), it has to be scrolled horizontally to read it. This is probably a symptom of the way the stylesheets use pixels all over the place, rather than a fluid design using percentages or ems for widths.
The "database contents" page about a place are a mess on "mobile" stylesheet, the list of churches partially overlaps the main table (and partially falls off the page).
On the good side, none of this is really hard to fix, getting rid of the non-breaking spaces in the Location, making the table padding a bit smaller and the table responsive when needed, using readable font weights, and using something like Bootstrap or (better) one of the more lightweight mobile-first responsive stylesheet frameworks would go a long way.
Minor points:
On the search forms, is there a reason (other than legacy) why surname is asked for first, rather than the more widely used (and modern) firstname then lastname? On the search results, the query is shown firstname, lastname (the opposite of the form), so there's no consistency.
Is the limit of 3 counties only for performance reasons? Seems very arbitrary for users.
The "hold ctrl" instructions for the "county" field are a bit Windows-centric (on touch screens, it works without that).
Centering the names, dates, etc in the columns in search results page makes them hard to scan visually. Looks neater if left aligned (maybe right aligned for the date).
"A date range and record type must be part of your search if you do not select a county." - although I understand the aim is to limit expensive queries, requiring the date range serves no purpose (since if a user wants any date, they can enter a range of years from 1000-3000).
Using "back" from a search result throws away the selected place. (for example search for a name at a place, find there are none, then go back to add the "nearby places"check box - the place has gone!). Actually it's worse than that, the entire list of places has gone, the county has to be unselected then reselected to get them back. ("revise search"works OK, but most people use the back key).
Finally, an (even more!) trivial point: on the "about this search" page, when a county was not specified, the word "all" is missing after "search:" (where the list of counties would be, after Location).
Sorry about all these comments, I do realise a new version is a lot of work!
Rob