Implement striping of search results

[Captainkirkdawson]

It has been suggested we do striping of alternate records? Test showed yellow unacceptable.
Do we find alternate. If so how do we deal with suggestion that different record types are striped in a different colour? death/burial dark gray; marriage green and birth light magenta

[PatReynolds]

FreeCEN #325 has a smilar discussion.

[Captainkirkdawson]

But only in terms of alternate records; How would we do that with record type colouring as suggested in BMD2 #83; furthermore as asked in *# does record type row colouring work?

[richpomfret]

Agreed on prototyping this for FR.

[PatReynolds]

First priority: getting hover to work nicely on FreeREG
Second priority: seeing if this could be combined with striping
Third priority: seeing if coloured foregrounds could be implemented for the Baptism/Marriage/Burial field.

[PatReynolds]

Having both striping and differentiating record types is impossible to make accessible.

Suggestion that we experiment with a striping in pale grey, with a pale blue hover (Pat thinks that the kind of pale blue should relate to the Navy) and @neslihanu is asked to consider other colour use that will indicate record type but is not a stripe (have to keep the word, of course, for those who are not seeing the colours).

[neslihanu]

@PatReynolds please correct me if I'm wrong; stripe colouring (green-gray-red) on FreeBMD is not for indicating different record types, it (change of shade) is for indicating the entries are not contiguous. Sorry, I did not understand your request.
How do you do this on current FreeBMD website ? There is a green/gray/red stripe on the Surname area of the search result.

I don't think we need striping for differentiating record types as we already use "record type" area in the search results list. We may consider different UI design for the list.

[Captainkirkdawson]

@neslihanu what we were talking about was the basic green orange and grey colouring associated with the record type in the search results page.

[PatReynolds]

Oh, bother. thank you for reminding me about non-contiguous vs contiguous records, Neslihan, and apologies for the resulting confusion. (FreeBMD2 issue FreeUKGen/FreeBMD2#83) for where we decided to follow this implementation.

Striping is suggested to be a pale blue alternating with normal background, to help researchers see in straight lines, whereas for FreeBMD, paler/darker background to surname (not whole line) cjanging that means that the entries are not contiguous.

FreeBMD note on this:
What does "entries are not contiguous" mean?
On the search page the legend says a "Change of shade means entries are not contiguous". What does this mean and what causes it?
Where there are other entries in the index between consecutive entries in the search results there is a change of shade. This can arise for the following reasons:

The search criteria themselves produce non-contiguous entries, e.g. all the entries registered in a particular district
The data between the entries has not yet been transcribed
It has not been possible to automatically determine that transcribed pages are consecutive; we manually correct these where we find them.

Barrie clarified on slack (t4 July) his as ""there are results that are not shown because they only match part of the search criteria". In other words, if you search for Alcock marrying Brown, it will show you that there are Alcocks who married people other than Brown, which are not shown.

NB also use of Bold in surname (to indicate double keying - not, I think, needed here, and italics to indicate that the District may not be correct - needed, I think.

Non-contiguous results are not shown in other projects.

I think we need to go with colour coding for type, and shading for differentiation between lines, and come up with another way of indicating non-contiguous data.

[neslihanu]

Please have a look for below designs (please ignore the content I've just copied and pasted the text). We can use horizontal lines or Zebra stripe to help users keep their place while reading. Also for indicating the entries are not contiguous (change of shade) and record type, I thought we can use a very simple design and use an elipse for this purpose. I don't have any about the title of it now, so I just put ? now.

And I belive we should not use red-green-gray colors for the elipse as a color blind person will not be able to see any differences.

[PatReynolds]

Hi @neslihan what is the (i) column?
We like the eclipse colour column as a solution. What is the (?) at the top of it?
There is no need to include the % in the date (this will be in a different page, and users referred to it by the Help (What to do if you think a record should be there, but isn't).

To consider: colour coding the event name (e.g. Marriage) much as FreeBMD1 colour codes the Surname.

[neslihanu]

Actually I thought the elipsis indicate the record type and non-contiguous records
(the change of shade --- such as dark green vs light green)
(i) is not a column it is an info icon next to the text. But you are right it looks like a new column :)

? -- as I mentioned before, we should find a header/title for the elipsis to explain what they are ... like Name, Surname etc.

[PatReynolds]

Thanks, @neslihanu my poor eyes were not picking up the different greens!
For header/title, how about 'Type? What do you all think?

One for the developers, could the ellipsis have a darker border for non-contigulous Perhaps having light and dark green next to one another would make them more visible?

[Captainkirkdawson]

@neslihanu ; I was initially confused when you called it an ellipse as it looked like a circle to me!
BMD1 colour codes the surname according to the record type with light/ dark according to contiguous.
So rather than have a separate something in a column. could we not do the same or similar. Either colour the name or record type. That permits use to stripe as well

[PatReynolds]

In sum: does it help or hinder some users to have alternate stripes in tables?

[PatReynolds]

"The results of the three studies conducted to date suggest that the safest option is to shade the alternating, individual rows of your table with a single color. Taking this approach is likely to ensure that:
task performance is better, or at least no worse, than with other table styles, and
the aesthetic sensibilities and subjective preferences of the majority of your users are catered for.
If zebra striping of this type cannot be done easily, then ruling a line between each row may be the next best option."
https://alistapart.com/article/zebrastripingmoredataforthecase/

[user comment on https://alistapart.com/article/zebrastripingdoesithelp/] "My guess is your usability testing didn’t take into account the high percentage of the population with small-large amounts of dyslexia.
I can tell you that zebra stripes are the only thing that keep me sane when reading tabular data, and I’m only moderately dyslexic. It’s very important to use Zebra stripes for other kinds of users with disabilities, especially people who have vision problems.
However we’ve found in our usability testing, and in my person preference that putting a border around each row in addition to zebra stripes (ALA iTunes) takes away all the benefits."

[DeniseColbert]

This type of thing is to be implemented: https://user-images.githubusercontent.com/46780491/72273871-0db5e080-3623-11ea-84c0-9a5ff4d69893.png

[AlOneill]

My feeling is that it has to be either zebra stripes or the hover effect: both is overkill and generates too much flickering as one scrolls. My vote is for zebra stripes.

Also, if we continue to use zebra stripes, then it should be the same colour for all screen sizes and the colour should be neutral or something close to neutral — at present it is yellow (ugh) on narrow screens.

[DeniseColbert]

Deployment planned by midday of 7th Dec

[DeniseColbert]

@Vino-S will check that striping is consistent on mobile devices/narrower screens before deployment

[DeniseColbert]

@Vino-S to check narrower screens and close if OK

[DeniseColbert]

Done, closing