Implement Sticking

[Captainkirkdawson]

The use of sticky on scrollable tables has been increasing as a means of maintaining header column matching . The use in the messages index table was not the first use of sticky its the 4th or 5th. Sticky is currently only used in member pages where accessibility is not an issue. I personally like the use of the project colour as a background in the header. I also like the hover BUT I do agree that it could convey they are links. There is no reason to undertake additional work on the sticky as has been suggested UNLESS it is proposed that we use sticky in the public domain (and we likely should change the search results to scrollable with a sticky)

e1 u3 p5 c7: P16

[AlOneill]

I am clearly way behind the curve on this as I've only recently become aware of the sticky styling.

Even on Members pages, we do wrong to make anything look and behave like a link when it is not one. It is a question of Accessibility per se: i.e. it is confusing for anyone!

The basic premise is sound: it is the particular use of colour and the unnecessary focus/hover styling that concerns me.

[Captainkirkdawson]

My preference is this rather than this

[AlOneill]

I agree that the markup and essential styling of the top example is much better than that of the bottom. No contest.

However, compare these two and decide which image makes better sense. The colour change here is just for example (& maybe not the best!): the important thing is that the difference conveys the sense that the two things — here, buttons and column headings — are different in significant ways. (Rule 1 of web design: do not confuse or annoy your users.)

or

[Captainkirkdawson]

Having never professed to being an expert in anything other than annoying people we are closer to an agreement.

If we were to adopt this idea for sticky headings would we also adopt a similar background for non sticky headings. I suspect yes.

The key then is the actual colour. Would we make it the same for all apps or be app specific. How about the lighter version of the project colour?

[Captainkirkdawson]

If the headings are links then we should use the nav bar style and colours eg if we use them to sort. Then hover and focus will still be required

[AlOneill]

In response to the questions and comments above:

"Would we also adopt a similar background for non sticky headings?" Not necessarily, especially if we decide to make the sticky headings stand out from the non-sticky headings — a wish you mentioned previously.

"Would we make it [the colour] the same for all apps or be app specific?" It depends. Could go either way, or we could offer a choice across all projects. Much will depend on the agreed details of the basic sticky header styling.

"If the headings are links then we should use the nav bar style and colours eg if we use them to sort. Then hover and focus will still be required." I think of the nav bar as a one-off — especially as the sticky header styling would be seen next to (even on top of!) buttons in the Actions column which have similar styling. And we need to consider that not all columns in a table are necessarily going to be sortable — the Actions column header, for instance — and such headers should not look identical to the sortable column headers. Yes, focus/hover styles would be required, but not as you have them because they would need to target the actual link (if present) rather than the whole th element.

[AlOneill]

Whilst we are deciding on the exact details of the sticky header styles, I recommend we change the background-colour of the current style to either $navy or $dark (?name of latter; #333 anyway) and delete the current sticky header focus/hover style.

I also suggest that we make the new colour combinations AA accessible, with a contrast ratio of at least 4.5:1, so that the styles can be used on public-facing pages.

[Captainkirkdawson]

For the members we are using the project colours with no hover or focus. This is what we have on REG batch listing Passes accessibility contrast except for the use of the red error batch

[Captainkirkdawson]

What we need is a th sticky_link defined that permits us to stick the search results table; something perhaps similar to the button styling with its focus/hover rather than a link

[AlOneill]

After considering the colour possibilities, and taking into account the wish for row-striping and row-hover, I propose the following general scheme:

• White on a saturated (darker) background for the sticky header cells. Links to be shown as (white) underlined — this is the pattern for our current islet/island/banner styling. Importantly, a header with a link will look different from one without a link.

• The background colour should not be the project-colour: we could use another project's main colour, or any of navy, dark grey, green or red. (Or any other compliant, distinct and good-looking saturated colour — please suggest a colour if you can devise one that fits the bill.)

• We need to decide whether we do this as one fixed scheme across all projects, or on a per-project basis, or as a choice of a number of schemes.

• Light grey and less-saturated backgrounds for striping and row-hover: this will require the more-saturated version of the link colour when a link occurs in a table body cell, but that is not a problem.

• The stripe and hover colours need to work well with the chosen sticky header colour. This will be more difficult to ensure if there is a choice of sticky header offered.

The following mock-up summarises the essence of the proposed styles (the colours used here are just for example):

It will be much easier to set up if Members pages and public-facing pages use the same style(s).

[AlOneill]

@Captainkirkdawson On the REG batch listing example, the orange for "only Verified" is not accessible. I forget whether or not the maroon for "Locked with errors" is accessible or not. The red can be changed to our accessible red.

Also, those colours are not entirely accessible in that distinguishing one colour from another of similar saturation may not be comfortable for someone with impaired colour perception.

I wonder if it would make sense to replace one of the colours with our default text colour? But that is probably a matter for another issue entirely …

[Captainkirkdawson]

Your suggestions are interesting but a couple of question for my education and understanding.

Firstly why a different colour from the project colour?

Why cannot we not make the th sticky_link (using a different name from sticky_header) behave like a an element in a main_nav class under hover focus ie reverse colour and can be clicked and just like a button reveral

[AlOneill]

@Captainkirkdawson

1. Because not all sticky headers will be links and to use the project colour would make them all look like (main menu) links: do not confuse or annoy

2. For simplicity of use, applying the (edited) .sticky-header class to one element will automatically style a link, if present, appropriately. How the link behaves on focus/hover/active is a separate issue.

[PatReynolds]

After discussion, Navy for background. Links to look like (and not look like) links as per Alison's mock-up of Dec 10, 2019. Links will also have hover and focus on them.

Alison to set it up so the right class automatically styles the link without further intervention.

Now to be implemented.

[PatReynolds]

Found in FreeCEN scrum - realise have not touched this for 2+ years - need to understand what, if anything remains to be implemented.

[AlOneill]

@PatReynolds there is now a th.sticky-header class in our CSS — lap_and_up.css, but nothing for links AFAICT

I was meant to be implementing a version that would include automatic link styling but ran into a snag and then got distracted by other tasks. So, it is not complete. A plain link will not work — it needs the same styling, including focus and hover, as for a link in a navy isle.

BTW, I see the Accessibility label but I have no idea if there are any accessibility issues — I do not anticipate any, but would like some confirmation from a screen reader as I do not necessarily trust my judgement! But perhaps you had a different issue in mind … a year ago!?

[DeniseColbert]

@AlOneill to let us know what the CSS should be, for implementation by a developer

[AlOneill]

@Captainkirkdawson @DeniseColbert I think we might be barking up the wrong tree here. As ever, the devil is in the details.

Links go places; buttons perform actions. The "links" on the column headers on REG Search Results, for example, are for sorting the results and so should be buttons (or inputs). Is there really a need for actual links? Where would they go?

[Captainkirkdawson]

@AlOneill I have retired from new undertakings

[AlOneill]

@Captainkirkdawson I understand — just wanted to keep you in the loop as sticky-headers were your idea.

[AlOneill]

@DeniseColbert Unless anyone can suggest a legitimate use of a link in column headings, I suggest this be closed.

Whether or not we use sticky-headers on public pages, we need a better way of providing sorting actions on table columns than links — the method being developed for BMD tables looks far more suitable, once all the snags have been resolved. (Remember that links and buttons, or inputs, are two different things, with different semantics.)

[AlOneill]

New issue: At palm widths, the sticky-header styling disappears and the row-striping reverts to yellow. Deliberate or accidental?

[DeniseColbert]

In the wrong place in the CSS, in lap and up but should be in palm.

We should look to implement on search results

[AlOneill]

This is my attempt to summarise the requirements for the sticky headers distilled from the above discussion:

1. The colour to be white text on a $navy background — headers that are not sticky to look as they do now
2. There will be no links so there is no need for link styling
3. Decision on column sorting (for tables with and without sticky headers) not clear: could be a short form as per BMD tables (more likely) or could be via buttons

[DeniseColbert]

@jayto581 is going to take a look

[DeniseColbert]

We DO want sorting on results tables, however they are currently links for sorting. We will move to the system on FreeBMD2, below, which will solve this

[DeniseColbert]

@Vino-S to send @jayto581 the code snippet for table sorting on FreeBMD2 so he can look at it.

[Vino-S]

Table example in MyopicVicar code base: Physical File listing https://github.com/FreeUKGen/MyopicVicar/blob/master/app/views/physical_files/index.html.erb

Sorting code: https://github.com/FreeUKGen/MyopicVicar/blob/freebmd_development/app/views/search_queries/_count_and_tools_menu.html.erb

[jayto581]

@DeniseColbert @AlOneill A functional prototype is setup on https://test3.freeReg.org.uk/

• Please review and comment
• The changes only apply on the search query result table
• The table header will stick to the top of the page
• The buttons above the table columns are a toggle and will sort the column in ascending/descending order

[AlOneill]

Perhaps I do not understand but I was expecting the results table to look more like this but with the table header sticking to the top of the table:

Instead we have a table header that is sticking to the top of the screen. Although the buttons in the header are actual buttons rather than links disguised as buttons, that they are buttons is not obvious, especially as we tend to make links look like buttons. Is that what we asked for? If so, the colours need revising — the two dark background colours do not look at all good together, IMO anyway.

[DeniseColbert]

We're moving towards the FreeBMD2 way, Joseph is going to try to implement just the "Sort by" dropdown menu in FreeREG using info/code that Vino will send.

@AlOneill thanks for taking a look at Joseph's first pass.

[jayto581]

@DeniseColbert

• Update prototype on https://test3.freeReg.org.uk/ with these new design requirements:
• Implement the "Filter by" and "Sort by" drop down menu on FreeREG similar to FreeBMD2
• Implement scrollable table with sticking table header using CSS style from FreeCEN

[AlOneill]

@jayto581 The Filter and Sort functions are working well, as are the sticky headers. Good work!

@DeniseColbert There are a few issues that, if they persist on the production site, need addressing:

• the row striping is yellow rather than grey on a mobile-width screen (not tested on an actual mobile device)
• the "Update Results" button does not align with the other items in the row
• I cannot tab past the Donate button
• the whole table (or one of its containers) is tab-able — not sure why or how so
• there is an unhelpful left margin (or some-such) on the table (or one of its containers) which limits the available width for the table, especially on a narrower screen so that the table requires horizontal scrolling prematurely. This is compounded by the space required by the advertisement

[DeniseColbert]

@jayto581 to follow Alison's points and tidy up the prototype code, and remove navy (make it look like FreeBMD2 with REG styling).

[jayto581]

@DeniseColbert @AlOneill Update prototype on https://test3.freeReg.org.uk/ :

• Add "Show" drop-down option, similar to BMD2
• Set table header colours, similar to BMD2
• Apply sticky table header (header sticks to top of screen )
• Adjust alignment of "Update Results" button
• Fix reported tabbing around screen issue
• Outstanding issue
  • the row striping is yellow rather than grey on a mobile-width screen
  • there is an unhelpful left margin (or some-such) on the table (or one of its containers) which limits the available width for the table, especially on a narrower screen so that the table requires horizontal scrolling prematurely. This is compounded by the space required by the advertisement

[DeniseColbert]

@Vino-S Joseph's code isn't thee anymore on Test3, please could you get it back up?

[DeniseColbert]

Code back up, @jayto581 to look at update reults working for both dropdowns on one click and adding asc/desc order into event year sort.

[jayto581]

Code updated and ready for review and testing

[DeniseColbert]

Looks very much like BMD2! Joseph to explore having the Apply button show an up/down arrow depending on asc/desc order of sort

[jayto581]

Update prototype on https://test3.freeReg.org.uk/

• set sort by Event Date as default
• Event Date is set as secondary sort criteria
• Update "We found ..." text box instructions
• Add sort icon to Update Results button

[jayto581]

See test3 for updates https://test3.freereg.org.uk/cms/refinery/login

[Vino-S]

@DeniseColbert , Could you give the new changes a test, please?

[DeniseColbert]

@richardofsussex could you test this please? Let me know if you need context

[richardofsussex]

The Filter drop-down should react to the number of event types in the search. If there is only one event type (a strategy you are forced to go for, if you don't specify a county) the Filter is meaningless and should not be displayed at all. If two event types are searched for, only those two types should be presented as Filter choices.

[richardofsussex]

Incidentally, as the designs of FreeReg and FreeBMD get closer to each other, I think it becomes more important that we choose whether to have Surname(s) or First Name(s)/Forename(s) first in the search form, and apply it consistently across all three sites. (Also to decide whether it's First Name(s) or Forename(s).)

Regardless of what other genealogy sites might do in this area, we should be self-consistent.

[DeniseColbert]

Surname - First name order is planned for review upon user testing feedback in FreeBMD2

Re. Filters @jayto581 will make the changes suggested