How to Get Perfect UX by Setting Up Your Forms for Dashlane

Originally published:August 25, 2021|Last updated:February 2, 2023|Jan Hettenkofer

Whether you're an administrator responsible for the maintenance of an internal service, a developer working on a web app, or any other type of person owning an online service or website that processes its users' personal information, you probably care about security. We assume that you already have as airtight a setup in place as anyone can aim for, but in reality, you're only ever as secure as your least-secure employee. That's why many companies choose to use a password manager like Dashlane to help mitigate this risk and, should the worst happen, enable their employees to change their passwords quickly and easily. But again, if an employee doesn't use your provided password manager, or it doesn't play well with the sites and services you maintain, it leaves you more vulnerable than you would otherwise be. 

In this article, I'm going to introduce you to a tiny change you can make to your website to make Dashlane integration faster and even more reliable. As a bonus, this technique might even help you drive up conversion on your e-commerce site.

Dashlane is able to correctly fill out most login, contact, or payment forms on the web by analyzing the page's content and markup. This process is based on a machine learning-powered analysis engine and a set of rules that determine the behavior when encountering a given type of field or form. On most sites, this only takes a few milliseconds. However, the time spent is proportional to the complexity of the document.

On a minority of sites, Dashlane simply does not have enough information to come to a conclusion about what to fill. Maybe the markup does not contain any keywords that could help our model decide that it's looking at a password field, or maybe the structure of the page is sufficiently different from what we have available to train this model that it is unable to pinpoint which is the field for the contact email and which is the field for the user handle. In most cases, we can fix these issues by adding the page to our data set. But what about sites we do not have access to? Or what if you are currently developing a site and you want to make sure it works perfectly together with Dashlane from day 1?

In order to guarantee that Dashlane interprets your forms correctly, you can use the data-form-type attribute. This little helper is defined in our public specification of Semantically Annotated Web Forms (SAWF for short). I invite you to skim through it before continuing on to get a feeling for how this might work.

Back already? Alright, let's work through an example:

A simple login form might look like this:

Nothing spectacular going on here, just the basics. Dashlane would likely be able to infer the classifications of the form and its fields without any issue, but to make absolutely sure that our users can be logged in in under a second, let's help Dashlane along a little. First, we'll label the username field as such by adding the data-form-type="username" attribute. We'll do the same for the password field with data-form-type="password"`. With that, the kind of data that is supposed to be filled into those two fields is now clear.

As you read in the spec, we can also label the form: To that end, we'll add the data-form-type="login" attribute to our form element. This is important for the surprisingly complex logic behind Dashlane's autofill behavior. In short, Dashlane chooses a different kind of behavior to match user expectations and keep our users' data safe depending on the type of form we are looking at.

With these, our markup should now look like this:

Often, login forms allow users to sign in with either their user handle, email address, phone number, or any one of a number of identifiers. This can be represented by using multiple labels on a single element:

In this case, Dashlane would choose one of these three identifiers from the user's vault to fill into the field.

Sometimes, a field has some special meaning that isn't purely about the data that it expects to be filled with. A common example are forms used to change passwords: They contain three password fields, one of which is to be filled with the user's old password and two which expect the user's new password. We'll see how we can specify this behavior in this example:

Once again, if this form did not have data-form-type attributes, Dashlane would know how to fill a form with such explicit labels. However, we want to guarantee that this is always the case, so let's label it correctly.

At the moment, the way the data-form-type attributes are set in this form is actually breaking Dashlane's behavior: it would fill all fields with the user's current password, i.e. the one we want to change away from. We can change this by adding the new and new,confirmation extra values to the second and third fields, respectively. The result looks like this:

With a form like this, Dashlane will automatically fill the first field with the user's old password and suggest a strong new password that will be filled into the second and third fields when the user accepts it. That's the second-fastest way we know how to change a password, allowing your users to stay safe with ease.

new and confirmation are what the SAWF spec calls extra values of the data-form-type attribute. This is in contrast to values like password and username.

In spec-speak, a data-form-type MUST have one or more values and MAY have one or more extra values. The extra values MUST belong to a category of extra values that is compatible with at least one of the associated values as defined under Guideline 3 in the specification. Values and extra values MUST be specified as a comma-separated list.

The order of values and extra values is currently of no significance, but this might be subject to change in the future. Therefore, we recommend you list them in decreasing order of relevance.

Payment forms deserve special attention since mislabeling them can have truly catastrophic consequences for user experience. They are also noteworthy in that they are often found in contexts that are hard to work in for password managers. On the flip side, a well-implemented payment form means that your customers can fill in their payment details in one click with Dashlane instead of having to type out that credit card number manually - and what business could say no to an easier checkout experience?

The following will serve as our example payment form. It is already correctly labeled with data-form-type attributes. If it looks overwhelming, don't worry: we'll go through this step by step.

In the above form, we can really see the expressive power of combining values and extra values. Let's step through the parts of this form one by one.

This datum is split across four inputs for the four blocks of the credit card number. We do not recommend structuring your payment forms like this (a single input is much more user friendly). This layout was only chosen to illustrate the usage of the part extra value.

We use payment,credit_card to specify that these fields are to be filled with a credit card number from the user's vault. We also add part to specify that this number is meant to be split across its natural boundaries—into four blocks in the case of a credit card number. Again, this split is not best practice; we just want to show how you can label fields expecting partial data. If you absolutely need to split form fields into parts, make sure this split always follows these commonly known boundaries and that the fields corresponding to the individual parts are successive siblings in the DOM.

Akin to what we see in many payment forms on the web, the expiration date is specified as a pair of selects, the first for the month, the second for the year.

Note how it is the <select>s that are tagged with data-form-type, not the <option>s. As for the values of this attribute, it's a doozy. Let's break it down:

After the heroic effort of the dates, this one is simple:

Some forms might expect to be filled with unstructured data that a password manager cannot provide, e.g. the message field in a contact form, comments, delivery instructions—you name it. To make 100% sure there is no mixup, you can label them as data-form-type="other", and Dashlane will leave them alone.

Keep in mind that we only recommend using this for data Dashlane definitely cannot fill. Specifying other on fields that can be filled by Dashlane will create a frustrating experience for our shared user base and also end up making them less secure.

It's OK to not label a field at all if you believe it could be filled by a password manager but there is no fitting value for the data-form-type attribute in the specification. Once this capability is added to Dashlane, we will update the specification - and until you update your site, our semantic analysis will figure these fields out with its 92% or better f-score.

I hope I could show that this change is painless to make and has the potential to drastically improve the experience of our shared user base as well as bolster the security of your online service.

Jan Hettenkofer

Jan is a Software Engineer at Dashlane who has developed the foundational tooling that powers Dashlane's new machine learning analysis engine. During his multifaceted career, he has implemented an online video editing service, designed the brand identity of a restaurant, and created advertising photographs for a Parisian start-up.

Read more