If I do a search on Google, by my understanding, it will affect the ordering of results both for me, and the rest of the world, very slightly, depending on the results I click on. This is to adjust to the 'feedback' - me scrolling down to the third result vs. clicking on the first one.
However, if this single click is enough to tip the balance, or I keep a search result page open during a major algorithm change, how does Google know what results to show when I click to change the page? E.g if the algorithm shift means that a result previously on the bottom of the first page has now moved to the top of the second page, if I click to move onto the second page, will Google just reload the results and show the result again, even though I've just seen it?
In general, what is the best practice for this? Is this even something that needs to be accounted for?
Related
In our PSI data we are seeing some pages with outrageous CLS numbers which we cannot reproduce or make sense of. In fact, here is an example of one page that has 2.52, but I did not even think it was possible to get over a score of 1.0, which would be a complete shift of everything on the screen, am I right? And is there some problem with the data/chrome, because this is not an isolated incident...our site pages suddenly started suffering terrible CLS data about a month ago and we are bewildered, in Core Web Vitals area of GSC.
Look in the Field Data at the CLS...2.52, but the lab data is .044. PSI Link
Why the difference between lab data and field data?
CLS in the lab tests (synthetic tests) is purely for initial page load and above the fold.
CLS in the field data (real world) is measured from the second the first (well technically second) paint event right until page unload.
So if there are layout shifts happen as someone scrolls the page those keep adding to your CLS.
How can I have a CLS greater than 1?
Imagine you scroll the page and the scroll bar suddenly appears, that would shift the whole page. Now CLS is based on the percentage of the page that moves. So if the whole page shifted to the left by 10px you would get a Layout Shift of almost 1 (think of 1 as 100% of the visible page, 0.5 would be 50% of the visible page moved etc.).
Let's assume that as you scroll the page further the scroll bar suddenly disappears, the whole page now shifts to the right by 10px. This would result in an additional Layout Shift of almost 1.
Now you have had two Layout Shifts of almost 1 - your Cumulative Layout Shift would be almost 2.
I have simplified how layout shift is calculated but I think the principle is easier to understand with the above example.
Real User Metrics (RUM) are the way to capture these sorts of issues.
As for CLS data suddenly changing, I would recommend using something like the web vitals library to pipe the data to either a custom backend or to your analytics so you can see if this is a specific device, screen size etc. causing it.
Spotting Issues with Developer Tools
To see layout shift regions, go to Developer Tools - > Rendering -> Check "Layout Shift Regions" and then load the page a few times, resize it etc.
The only thing I could see is that your mobile menu has some very strange layout shift regions that are particularly bad at large screen sizes. Other than that there is a massive shift when the page loads but that shouldn't take it over 1.
I know the problem is on desktop but I can't remember if they put tablet data in the desktop or the mobile field data...if it is desktop then you may have your answer!
I have created a webpage using Backbone.js and Marionette.js that mostly consists of a bootstrap accordion view that displays a list of items when the accordion header is clicked. Each item can also be clicked, which will show a hidden div of detailed information that pertains to that particular item.
I would like to make this site accessible to people who might not be using a mouse (Maybe they're visually impaired and using a screen reader? Maybe they just don't like clicking things? Either way.) I'm thinking that this would mean being able to press the Tab key to get to the accordion, pressing Space or Enter to open the accordion, Tabbing down (or down arrow key?) through the list items, and then using Space or Enter to show the selected item's hidden div.
I'm finding it difficult to find information on how to add a feature like this, since searches like "How to make an accessible website that can be used without a mouse" mostly turns up blogs on what a developer should do to add accessibility to a page, and not much on how to do it.
Currently, the page doesn't really respond to any keyboard buttons. Any tips or resources you could share would be extremely appreciated. I've been fiddling with ARIA role tags, but I'm either not doing it right or it's not the answer here.
You have to use tabindex
https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement.tabIndex
Screen readers automatically read whatever element is the activeElement
My question is about focus management for web accessibility. When we launch a popup/dialog, does focus always need to go to the first focusable element for accessibility reasons or is it acceptable to set focus on an element that we think the user is more likely to want to work with?
For example, if a dialog starts with an input field and a cancel link followed by a dropdown and we think the user would most likely want to work with the dropdown when the dialog loads, is it ok to set focus on the dropdown element? In this case, how would the user know about the previous focusable elements existing on the dialog? But, if the dropdown is where 80% of the users will want to be when the dialog is launched, it doesn't make much sense placing focus on the initial input field...
thoughts?
Based on my research and what public opinion is: http://webaim.org/discussion/mail_thread?thread=5435 it seems like where the focus goes for a modal dialog/popup would depend on the usecase. For example, it makes sense to set focus on the search input field for www.google.com although there are preceding elements that the user can interact with -- this maximizes usability for screen reader and keyboard only users. But, in general the focus needs to go to the first element the user can interact with -- depends on the scenario.
I would caution against setting focus to anything other than the first form element or headings/content that introduce the form. See WCAG 2.0 Focus Order:
If a Web page can be navigated sequentially and the navigation
sequences affect meaning or operation, focusable components receive
focus in an order that preserves meaning and operability. (Level A)
While the case you present is I think an edge case, I think the focus order rules still apply. If you think that most users will want to interact with the select why not put it first in the form rather than set focus to an element in the middle of the form?
It's currently impossible for a user to tell if clicking on something will load something in their current page or take them to a new page. I feel that this is why many sites use hoverable dropdown menus, so that they don't have to click anything. This can be messy, though, if you don't intentionally hover over something and forms the habit of hovering over things and expecting a result.
There should be a standard way to identify links as external or internal. Maybe a little hover effect or symbol used in the link?
Is there anything like this, and if not, should there be?
I believe by "internal" you mean that the link does some javascript thing, and does not load a new page.
I think an effective way to indicate an immediate action is by using a button style, rather than a standard looking link. A blue underlined link somehow seems much more likely to jump to a new page than something that looks like a button.
Give the button an appropriate label and/or symbol that indicates an instant action. For example, a button that expands a section open might use a little triangle that rotates as the expanding happens.
You can also establish a consistent style for "internal" actions, use a particular color or style for links that don't take the user to a new page. Sometimes I use blue for normal links and a shade of purple for internal ones.
In general, I find it isn't that important to specify. If a user sees a link or button that like it will get them what they want, they will click it. It is up to you as the designer of the website to decide if the most appropriate action is a new page, or an action on the current page. Unless the user is going to lose some work they have done, going to a new page shouldn't be a problem. If it really took the user by surprise, they can always go back. In my experience, users don't worry about it either way.
I need to design a web form which landlords can use to add rental listings. There are 8 mandatory text boxes and 2 optional text boxes, 11 drop-down lists, 12 checkboxes and one large text area. Any suggestions about how to arrange them in a way that is clean, and uncluttered? My concern is, if the form looks lengthy, they may not want to fill it. So far I have divided the elements on the page into sections, however the page still looks cluttered.
I would suggest that you use 2 pages instead of 1. On the first page, show the 8 mandatory text boxes and follow them with an additional checkbox which makes the 2 optional text boxes appear on being clicked. This means that the user will opt-in for the optional checkboxes making it more acceptable and natural to her. Next, place a submit button which would take the user to the second page.
Put all the 12 checkoxes and the text area on the second page. On page 2, tell the users very clearly that this is the last page they need to fill. They will be less disinclined now since all they need to do is to place a few more clicks.
You may want to split the process of getting all of this data from the user into multiple parts. Conventionally, that would be multiple pages of forms. The problem with that is that it's annoying for the user to have to watch their browser reload the whole page as they move through the form.
A more popular methodology now is to use AJAX to present the larger form in multiple pieces without having to reload the entire page.
In both cases you will need to keep state between each page load or AJAX request so that the back button behaves sanely and the user's previous input reappears as they move backwards (and forwards) through the form.
Unless you have some kind of nifty state-keeping mechanism already written that is generic enough to work for any given form set you may decide to use, welcome to the pain in the ass that is web development.
How about a wizard-style layout?
Break the sections out into separate pages, so components are submitted separately. Make it clear how many sections there are, and how far through the form the user is. Be careful to track the user's progress either in the session, or by keeping state in the form.
This approach makes giving error messages a bit less threatening to users (you never show them the error message "Please correct the following 34 errors").
Edit: Having seen the current form layout, I actually think what you've got at present is very clear, and nicely done.
Do submitters have account profiles that you can use to populate the contact details? If so, I would drop the contact details from the form for creating a listing, and add a review screen that shows all of the information, and gives links for specifying alternative contact details or amending other information. Users then see one screen, plus a review screen with a big "Publish This Listing" button. Amazon's order process uses a good review screen.
Breaking the input into multiple sections is a good idea.
I also like to make most of the input fields invisible, and make them visible as more information is entered. I start with the most important info to be entered first (e.g., name), and as each item is entered, I make further input fields visible. I also give focus to the next logical field that the user is expected to enter as he goes along.
You can use other tricks like highlighting the next field to enter (i.e., changing the background color or surrounding borders of the input field label) to make it even more obvious to the user.
Grouping related fields into separate boxes (with visible borders) may make the info seem less cluttered, too.
This approach makes it look less overwhelming to the user, and makes it more obvious to him what he needs to enter, from start to finish.
Frankly, 33 fields on a single page does not sound all that long for describing a rental listing, especially when 23 of the fields (checkboxes and dropdowns) can default to the most common values. With your current layout, the form almost all fits above the fold. That ain’t bad.
I’d be very cautious about splitting it into separate pages (e.g., as a wizard). First of all, that will take the user longer, because now you’re adding navigation and re-orientation time. Second of all, it will seem to take longer; the user will be like, “Geez, I have fill out a multi-page form?” Thirdly, users can’t tell how much work is expected of them when some of it is hidden on other pages (or by AJAX tricks). Some will not fill out the form at all assuming the worse. Others will abandon it part-way through because they either didn’t plan enough time for it, or just got tired of hitting Next indefinitely. You can mitigate this last problem by saying up front how many pages there are, and showing the user’s progress through them, but that just accentuates the fact that it’s multi-page, and therefore “long.”
IMO, all it needs is some lighter graphic design. I’d drop the “reverse video” section titles and the green background on alternating sections and make it all white. Use color and/or bold text for the section titles. You can combine the Property Description section label with the field label to reduce clutter and redundancy. Consider putting the Pets and Parking fields on the same line as Laundry then spreading the Unit Details fields out vertically so the mis-alignment of the fields is not so noticeable. Alternatively, size the Unit Detail fields so that they are better aligned. Maybe you can drop the “How do you want to be contacted?” field. I’d expect that if users don’t want to be contacted by one of the means, they simply don’t fill out that field.
Other than that, be sure your users understand the importance of these fields –why filling them out helps them find the right renters. Users don’t mind filling out a lot of fields if it’s clear that each benefits them. It’s when users feel like they're disclosing a lot of data to benefit you that they get resentful and reluctant. The importance of the fields you have seems self-evident to me, but maybe you should include a link that explains the purpose and value of the fields.
Finally, make sure there’s not too much clutter and competition from the “standard” page elements (e.g., sidebar menus, legal information).