One thing that should be standard by now is for addresses in the USA or other countries that have ZIP or Postal codes per municipality or area, the zip/postal should be entered first and auto fill the city if it is unique. There should be very few times where "USA, 20755" doesn't give the correct location.
Back in 1992, I developed networked databases applications for macOS using Panorama. It included looking up city and state from ZIP codes. The only times I recall it getting the wrong info was in cases of recent city boundary changes.
Panorama still exists, it was so much better than Access or FileMaker.
I just implemented the USPS APIs and they all require a street address in order to succeed, due to the need for disambiguation. What I really wanted was something like you describe, because I don't always have a street address so much as a general region. All the other API offerings are way too pricey for my purposes, or look scammy. I ended up scraping Wikipedia and making a generic spreadsheet instead.
Long form articles were pretty much the norm for these types of educational content and videos were rare. CSS-tricks and smashing magazine came along a bit later with some good content also. Haven’t found video equivalents of any of it but I haven’t looked much either.
> Use the tabindex attribute to control tabbing order
In the meanwhile, the industry decided that the tabIndex has more cons than pros and should be avoided except for the value 0, for normally non-focusable targets to make them focusable and -1 for vice versa. MDN states:
> Warning: Avoid using tabindex values greater than 0. Doing so makes it difficult for people who rely on assistive technology to navigate and operate page content. Instead, write the document with the elements in a logical sequence.
It seems like this PDF is to be accompanied by a talk. Is there any video or audio file for this presentation? Otherwise it's just keywords on slides with pictures.
My least favorite form design "feature" is when they don't allow you to manually enter the date and you have to click a dozen times in a calendar to select the correct date.
Information is outdated for current day, when most users are filling forms on "tiny" mobile screens. Now you need to consider mobile keyboards covering good portion of screen, so any additional information still should be visible and not covered by keyboard. And don't forget about auto-fill, which really can save time to fill out standard forms.
I wouldn’t say it’s irrelevant but it does change the equation: when that article came out designing for 1024x768 or lower resolution was commonplace. Real-estate was at a premium but the extra width of a 1024 pixel display meant that there was a little more room for side-by-side placement of elements that would probably have vertically stacked before. There wasn’t a ton of room to work with so the guidelines were still predicated on knowing your users and their requirements.
