user interface posts - idmontie's Portfolio

"use strict";
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = {
    a: "a",
    blockquote: "blockquote",
    code: "code",
    h2: "h2",
    li: "li",
    p: "p",
    pre: "pre",
    ul: "ul",
    ...props.components
  };
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "Accessibility problems usually have recognizable solutions. A button needs an accessible name, text needs sufficient contrast, and a modal needs sensible focus management."
    }), "\n", _jsx(_components.p, {
      children: "The implementation may be wrong, but the path toward fixing it is usually understood."
    }), "\n", _jsx(_components.p, {
      children: "Then there are toasts."
    }), "\n", _jsx(_components.h2, {
      children: "What is a Toast"
    }), "\n", _jsx(_components.p, {
      children: "A toast is a small, temporary message that appears in response to an event or user action. It might confirm success, report an error, or tell the user that an asynchronous operation has completed."
    }), "\n", _jsx(_components.p, {
      children: "In Gmail, when you delete an email, the user is given a toast notification that allows the user to undo the action."
    }), "\n", _jsx(_components.p, {
      children: "In some systems, an action is asynchronous, and a toast is used to notify the user after the action has completed without blocking the user on a screen/form to wait for the result."
    }), "\n", _jsx(_components.h2, {
      children: "Why toasts are difficult"
    }), "\n", _jsxs(_components.p, {
      children: ["Dialogs have ", _jsx(_components.code, {
        children: "<dialog>"
      }), ". Buttons have ", _jsx(_components.code, {
        children: "<button>"
      }), ". Forms have ", _jsx(_components.code, {
        children: "<form>"
      }), ", ", _jsx(_components.code, {
        children: "<input>"
      }), ", and ", _jsx(_components.code, {
        children: "<label>"
      }), ". Toasts have… ", _jsx(_components.code, {
        children: "<div>"
      }), "."]
    }), "\n", _jsx(_components.p, {
      children: "For example, here is an HTML-only modal example:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        children: " <dialog id=\"hello_modal\" class=\"modal\">\n  <div class=\"modal-box\">\n    <h3 class=\"text-lg font-bold\">Hello!</h3>\n  </div>\n</dialog>\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "Native elements provide browsers and assistive technologies with semantics they already understand."
    }), "\n", _jsx(_components.p, {
      children: "The main issue is that there doesn’t exist any basic HTML element that perfectly encompasses a toast. Any implementation of a toast ends up being a custom implementation for whatever system implements it."
    }), "\n", _jsx(_components.p, {
      children: "Then there is the large amount of usability issues:"
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsx(_components.li, {
        children: "On large screens, toasts end up going unnoticed."
      }), "\n", _jsx(_components.li, {
        children: "On any page with visual clutter - for example a page with a map on it that contains map controls for zooming, searching, etc - a toast can often be lost in the visual clutter."
      }), "\n", _jsx(_components.li, {
        children: "A toast is often distracting. If the toast automatically dismisses itself, then the user only has a short period of time to read or interact with the message. If the toast does not automatically dismiss, it distracts the user from their flow by requiring them to dismiss it."
      }), "\n", _jsx(_components.li, {
        children: "If a user is using any screen magnification software, the toast can go unnoticed since it might be outside of the magnification window."
      }), "\n", _jsx(_components.li, {
        children: "A toast appearing is typically disconnected from the action that was taken, meaning the user may not understand the relationship between the toast and action that triggered it."
      }), "\n"]
    }), "\n", _jsx(_components.h2, {
      children: "What do we do about it?"
    }), "\n", _jsxs(_components.p, {
      children: ["The next question is of course: so what do we do about it? Can we make toasts accessible for users? Primer - the component library created by GitHub - has decided that ", _jsx(_components.a, {
        href: "https://primer.style/accessibility/patterns/accessible-notifications-and-messages/",
        children: "toasts were not worth the effort"
      }), ":"]
    }), "\n", _jsxs(_components.blockquote, {
      children: ["\n", _jsx(_components.p, {
        children: "Toasts pose significant accessibility concerns and are not recommended for use."
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "The accessibility problem with toasts isn't merely that screen readers can't announce them. It's that the entire interaction model assumes the user will notice a temporary piece of UI appearing somewhere else on the screen."
    }), "\n", _jsx(_components.p, {
      children: "For simple actions, the Primer documentation suggests to simply have a banner on the next page after a form submission with any additional information for successful states. The user successfully created an issue? Redirect to the issue. Need to provide feedback after a complex action? Use a banner at the top of the resulting page with the message."
    }), "\n", _jsxs(_components.p, {
      children: ["There are also many discussions on YCombinator, such as ", _jsx(_components.a, {
        href: "https://news.ycombinator.com/item?id=46135145",
        children: "this one"
      }), " where users argue about how useful toasts really are."]
    }), "\n", _jsxs(_components.blockquote, {
      children: ["\n", _jsx(_components.p, {
        children: "Toasts are a great way to lose information."
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "On Couchsurfing, we had a similar experience with toasts. We implemented toasts to alert the user that they needed to turn on Geolocation permissions to use certain features. We rendered the toast correctly, it had sufficient contrast, and assistive technology would announce it properly. None of that mattered though because users simply wouldn’t notice it. Toasts would get lost in the clutter of controls on our pages with maps on them."
    }), "\n", _jsxs(_components.p, {
      children: ["But if a toast is really required, the package ", _jsx(_components.a, {
        href: "https://github.com/emilkowalski/sonner",
        children: "Sonner"
      }), " offers a Toast implementation that is as accessibility friendly as it can be. Emil Kowalski, a design engineer, created the Sonner toast library and wrote a ", _jsx(_components.a, {
        href: "https://emilkowal.ski/ui/building-a-toast-component",
        children: "nice blog post here"
      }), " that describes the animation and API of the implementation, but the real important part of the toast implementation is how it renders the toasts, which roughly looks like:"]
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-html",
        children: "<section\n  aria-label={ariaLabel}\n  tabIndex={-1}\n  aria-live=\"polite\"\n  aria-atomic=\"false\"\n>\n  <ol tabIndex={-1}>\n    <li tabIndex={0}>\n\t    {content}\n    </li>\n  </ol>\n</section>\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "Each section helps with accessibility as follows:"
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsxs(_components.li, {
        children: [_jsx(_components.code, {
          children: "aria-label"
        }), " provides screen readers with an accessible name for the section"]
      }), "\n", _jsxs(_components.li, {
        children: [_jsx(_components.code, {
          children: "tabIndex={-1}"
        }), " takes the section out of the keyboard navigation flow"]
      }), "\n", _jsxs(_components.li, {
        children: [_jsx(_components.code, {
          children: "aria-live=\"polite\""
        }), " means that any changes within this node will wait to alert the user until their current action is complete"]
      }), "\n", _jsxs(_components.li, {
        children: [_jsx(_components.code, {
          children: "aria-atomic=\"false\""
        }), " means that assistive technology will only announce the changed portion of the region, rather than presenting the entire region again."]
      }), "\n"]
    }), "\n", _jsxs(_components.p, {
      children: ["Another implementation that is very accessibility aware is the ", _jsx(_components.a, {
        href: "https://react-aria.adobe.com/Toast/useToast",
        children: "React Aria library"
      }), ", which creates markup similar to:"]
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-html",
        children: "<div\n\trole=\"region\"\n\ttabindex=\"-1\"\n\taria-label=\"1 notification.\"\n>\n\t<div\n\t\trole=\"alertdialog\"\n\t\taria-modal=\"false\"\n\t\taria-labelledby=\"title\"\n\t\ttabindex=\"0\"\n\t>\n\t\t<div\n\t\t\trole=\"alert\"\n\t\t\taria-atomic=\"true\"\n\t\t>\n\t\t\t<div\n\t\t\t\tid=\"title\"\n\t\t\t\tslot=\"title\"\n\t\t\t>\n\t\t\t\tToast is done!\n\t\t\t</div>\n\t\t</div>\n\t</div>\n</div>\n"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["Which as we can see is slightly different than the Sonner implementation. Mainly that no section is used, but the div is marked a ", _jsx(_components.code, {
        children: "region"
      }), ". It also uses the role ", _jsx(_components.code, {
        children: "alertdialog"
      }), " ."]
    }), "\n", _jsx(_components.h2, {
      children: "Did we solve it?"
    }), "\n", _jsx(_components.p, {
      children: "Just looking at two implementations shows the problem with toasts - because they aren’t standardized into HTML, every implementation looks slightly different. In the end, that means that if we care about accessibility, we are mainly working around the constraints of HTML to provide a semantic and understandable toast component. And, even if we do implement a toast that is good enough, we still have to worry about the user experience of interacting with a toast."
    }), "\n", _jsx(_components.p, {
      children: "The two implementations also didn’t answer some of the main UX concerns when using toasts: did the user even see the toast? Did it disappear before they finished reading it? Did the user even understand the message, let alone which action caused it?"
    }), "\n", _jsx(_components.p, {
      children: "There are plenty of sites that use toasts though. My early example was Gmail, and that is used by millions of people around the world. Even Apple uses toasts. What is a notification on the Mac desktop if not a toast? We also have mobile notifications on Android and iOS devices that are basically toasts for different apps to get your attention."
    }), "\n", _jsx(_components.p, {
      children: "Toasts have their place, but they require considerably more thought than their simple UI suggests. The next time you reach for one, ask your team: is there a better way to convey the same information?"
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, {
    ...props,
    children: _jsx(_createMdxContent, {
      ...props
    })
  }) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>Accessibility problems usually have recognizable solutions. A button needs an accessible name, text needs sufficient contrast, and a modal needs sensible focus management.</p>
<p>The implementation may be wrong, but the path toward fixing it is usually understood.</p>
<p>Then there are toasts.</p>
<h2>What is a Toast</h2>
<p>A toast is a small, temporary message that appears in response to an event or user action. It might confirm success, report an error, or tell the user that an asynchronous operation has completed.</p>
<p>In Gmail, when you delete an email, the user is given a toast notification that allows the user to undo the action.</p>
<p>In some systems, an action is asynchronous, and a toast is used to notify the user after the action has completed without blocking the user on a screen/form to wait for the result.</p>
<h2>Why toasts are difficult</h2>
<p>Dialogs have <code>&lt;dialog&gt;</code>. Buttons have <code>&lt;button&gt;</code>. Forms have <code>&lt;form&gt;</code>, <code>&lt;input&gt;</code>, and <code>&lt;label&gt;</code>. Toasts have… <code>&lt;div&gt;</code>.</p>
<p>For example, here is an HTML-only modal example:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code> &lt;dialog id=&quot;hello_modal&quot; class=&quot;modal&quot;&gt;
  &lt;div class=&quot;modal-box&quot;&gt;
    &lt;h3 class=&quot;text-lg font-bold&quot;&gt;Hello!&lt;/h3&gt;
  &lt;/div&gt;
&lt;/dialog&gt;
</code></pre></div>
<p>Native elements provide browsers and assistive technologies with semantics they already understand.</p>
<p>The main issue is that there doesn’t exist any basic HTML element that perfectly encompasses a toast. Any implementation of a toast ends up being a custom implementation for whatever system implements it.</p>
<p>Then there is the large amount of usability issues:</p>
<ul>
<li>On large screens, toasts end up going unnoticed.</li>
<li>On any page with visual clutter - for example a page with a map on it that contains map controls for zooming, searching, etc - a toast can often be lost in the visual clutter.</li>
<li>A toast is often distracting. If the toast automatically dismisses itself, then the user only has a short period of time to read or interact with the message. If the toast does not automatically dismiss, it distracts the user from their flow by requiring them to dismiss it.</li>
<li>If a user is using any screen magnification software, the toast can go unnoticed since it might be outside of the magnification window.</li>
<li>A toast appearing is typically disconnected from the action that was taken, meaning the user may not understand the relationship between the toast and action that triggered it.</li>
</ul>
<h2>What do we do about it?</h2>
<p>The next question is of course: so what do we do about it? Can we make toasts accessible for users? Primer - the component library created by GitHub - has decided that <a href="https://primer.style/accessibility/patterns/accessible-notifications-and-messages/">toasts were not worth the effort</a>:</p>
<blockquote class="border-l-4 border-gray-300 pl-4">
<p>Toasts pose significant accessibility concerns and are not recommended for use.</p>
</blockquote>
<p>The accessibility problem with toasts isn&#x27;t merely that screen readers can&#x27;t announce them. It&#x27;s that the entire interaction model assumes the user will notice a temporary piece of UI appearing somewhere else on the screen.</p>
<p>For simple actions, the Primer documentation suggests to simply have a banner on the next page after a form submission with any additional information for successful states. The user successfully created an issue? Redirect to the issue. Need to provide feedback after a complex action? Use a banner at the top of the resulting page with the message.</p>
<p>There are also many discussions on YCombinator, such as <a href="https://news.ycombinator.com/item?id=46135145">this one</a> where users argue about how useful toasts really are.</p>
<blockquote class="border-l-4 border-gray-300 pl-4">
<p>Toasts are a great way to lose information.</p>
</blockquote>
<p>On Couchsurfing, we had a similar experience with toasts. We implemented toasts to alert the user that they needed to turn on Geolocation permissions to use certain features. We rendered the toast correctly, it had sufficient contrast, and assistive technology would announce it properly. None of that mattered though because users simply wouldn’t notice it. Toasts would get lost in the clutter of controls on our pages with maps on them.</p>
<p>But if a toast is really required, the package <a href="https://github.com/emilkowalski/sonner">Sonner</a> offers a Toast implementation that is as accessibility friendly as it can be. Emil Kowalski, a design engineer, created the Sonner toast library and wrote a <a href="https://emilkowal.ski/ui/building-a-toast-component">nice blog post here</a> that describes the animation and API of the implementation, but the real important part of the toast implementation is how it renders the toasts, which roughly looks like:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-html">&lt;section
  aria-label={ariaLabel}
  tabIndex={-1}
  aria-live=&quot;polite&quot;
  aria-atomic=&quot;false&quot;
&gt;
  &lt;ol tabIndex={-1}&gt;
    &lt;li tabIndex={0}&gt;
	    {content}
    &lt;/li&gt;
  &lt;/ol&gt;
&lt;/section&gt;
</code></pre></div>
<p>Each section helps with accessibility as follows:</p>
<ul>
<li><code>aria-label</code> provides screen readers with an accessible name for the section</li>
<li><code>tabIndex={-1}</code> takes the section out of the keyboard navigation flow</li>
<li><code>aria-live=&quot;polite&quot;</code> means that any changes within this node will wait to alert the user until their current action is complete</li>
<li><code>aria-atomic=&quot;false&quot;</code> means that assistive technology will only announce the changed portion of the region, rather than presenting the entire region again.</li>
</ul>
<p>Another implementation that is very accessibility aware is the <a href="https://react-aria.adobe.com/Toast/useToast">React Aria library</a>, which creates markup similar to:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-html">&lt;div
	role=&quot;region&quot;
	tabindex=&quot;-1&quot;
	aria-label=&quot;1 notification.&quot;
&gt;
	&lt;div
		role=&quot;alertdialog&quot;
		aria-modal=&quot;false&quot;
		aria-labelledby=&quot;title&quot;
		tabindex=&quot;0&quot;
	&gt;
		&lt;div
			role=&quot;alert&quot;
			aria-atomic=&quot;true&quot;
		&gt;
			&lt;div
				id=&quot;title&quot;
				slot=&quot;title&quot;
			&gt;
				Toast is done!
			&lt;/div&gt;
		&lt;/div&gt;
	&lt;/div&gt;
&lt;/div&gt;
</code></pre></div>
<p>Which as we can see is slightly different than the Sonner implementation. Mainly that no section is used, but the div is marked a <code>region</code>. It also uses the role <code>alertdialog</code> .</p>
<h2>Did we solve it?</h2>
<p>Just looking at two implementations shows the problem with toasts - because they aren’t standardized into HTML, every implementation looks slightly different. In the end, that means that if we care about accessibility, we are mainly working around the constraints of HTML to provide a semantic and understandable toast component. And, even if we do implement a toast that is good enough, we still have to worry about the user experience of interacting with a toast.</p>
<p>The two implementations also didn’t answer some of the main UX concerns when using toasts: did the user even see the toast? Did it disappear before they finished reading it? Did the user even understand the message, let alone which action caused it?</p>
<p>There are plenty of sites that use toasts though. My early example was Gmail, and that is used by millions of people around the world. Even Apple uses toasts. What is a notification on the Mac desktop if not a toast? We also have mobile notifications on Android and iOS devices that are basically toasts for different apps to get your attention.</p>
<p>Toasts have their place, but they require considerably more thought than their simple UI suggests. The next time you reach for one, ask your team: is there a better way to convey the same information?</p>

Accessibility problems usually have recognizable solutions. A button needs an accessible name, text needs sufficient contrast, and a modal needs sensible focus management.

The implementation may be wrong, but the path toward fixing it is usually understood.

Then there are toasts.



## What is a Toast

A toast is a small, temporary message that appears in response to an event or user action. It might confirm success, report an error, or tell the user that an asynchronous operation has completed.

In Gmail, when you delete an email, the user is given a toast notification that allows the user to undo the action.

In some systems, an action is asynchronous, and a toast is used to notify the user after the action has completed without blocking the user on a screen/form to wait for the result.

## Why toasts are difficult

Dialogs have `<dialog>`. Buttons have `<button>`. Forms have `<form>`, `<input>`, and `<label>`. Toasts have… `<div>`.

For example, here is an HTML-only modal example:

```
 <dialog id="hello_modal" class="modal">
  <div class="modal-box">
    <h3 class="text-lg font-bold">Hello!</h3>
  </div>
</dialog>
```

Native elements provide browsers and assistive technologies with semantics they already understand.

The main issue is that there doesn’t exist any basic HTML element that perfectly encompasses a toast. Any implementation of a toast ends up being a custom implementation for whatever system implements it.

Then there is the large amount of usability issues:

- On large screens, toasts end up going unnoticed.
- On any page with visual clutter - for example a page with a map on it that contains map controls for zooming, searching, etc - a toast can often be lost in the visual clutter.
- A toast is often distracting. If the toast automatically dismisses itself, then the user only has a short period of time to read or interact with the message. If the toast does not automatically dismiss, it distracts the user from their flow by requiring them to dismiss it.
- If a user is using any screen magnification software, the toast can go unnoticed since it might be outside of the magnification window.
- A toast appearing is typically disconnected from the action that was taken, meaning the user may not understand the relationship between the toast and action that triggered it.

## What do we do about it?

The next question is of course: so what do we do about it? Can we make toasts accessible for users? Primer - the component library created by GitHub - has decided that [toasts were not worth the effort](https://primer.style/accessibility/patterns/accessible-notifications-and-messages/):

> Toasts pose significant accessibility concerns and are not recommended for use.

The accessibility problem with toasts isn't merely that screen readers can't announce them. It's that the entire interaction model assumes the user will notice a temporary piece of UI appearing somewhere else on the screen. 

For simple actions, the Primer documentation suggests to simply have a banner on the next page after a form submission with any additional information for successful states. The user successfully created an issue? Redirect to the issue. Need to provide feedback after a complex action? Use a banner at the top of the resulting page with the message.

There are also many discussions on YCombinator, such as [this one](https://news.ycombinator.com/item?id=46135145) where users argue about how useful toasts really are.

> Toasts are a great way to lose information.


On Couchsurfing, we had a similar experience with toasts. We implemented toasts to alert the user that they needed to turn on Geolocation permissions to use certain features. We rendered the toast correctly, it had sufficient contrast, and assistive technology would announce it properly. None of that mattered though because users simply wouldn’t notice it. Toasts would get lost in the clutter of controls on our pages with maps on them.

But if a toast is really required, the package [Sonner](https://github.com/emilkowalski/sonner) offers a Toast implementation that is as accessibility friendly as it can be. Emil Kowalski, a design engineer, created the Sonner toast library and wrote a [nice blog post here](https://emilkowal.ski/ui/building-a-toast-component) that describes the animation and API of the implementation, but the real important part of the toast implementation is how it renders the toasts, which roughly looks like:

```html
<section
  aria-label={ariaLabel}
  tabIndex={-1}
  aria-live="polite"
  aria-atomic="false"
>
  <ol tabIndex={-1}>
    <li tabIndex={0}>
	    {content}
    </li>
  </ol>
</section>
```

Each section helps with accessibility as follows:

- `aria-label` provides screen readers with an accessible name for the section
- `tabIndex={-1}` takes the section out of the keyboard navigation flow
- `aria-live="polite"` means that any changes within this node will wait to alert the user until their current action is complete
- `aria-atomic="false"` means that assistive technology will only announce the changed portion of the region, rather than presenting the entire region again.

Another implementation that is very accessibility aware is the [React Aria library](https://react-aria.adobe.com/Toast/useToast), which creates markup similar to:

```html
<div
	role="region"
	tabindex="-1"
	aria-label="1 notification."
>
	<div
		role="alertdialog"
		aria-modal="false"
		aria-labelledby="title"
		tabindex="0"
	>
		<div
			role="alert"
			aria-atomic="true"
		>
			<div
				id="title"
				slot="title"
			>
				Toast is done!
			</div>
		</div>
	</div>
</div>
```

Which as we can see is slightly different than the Sonner implementation. Mainly that no section is used, but the div is marked a `region`. It also uses the role `alertdialog` .

## Did we solve it?

Just looking at two implementations shows the problem with toasts - because they aren’t standardized into HTML, every implementation looks slightly different. In the end, that means that if we care about accessibility, we are mainly working around the constraints of HTML to provide a semantic and understandable toast component. And, even if we do implement a toast that is good enough, we still have to worry about the user experience of interacting with a toast.

The two implementations also didn’t answer some of the main UX concerns when using toasts: did the user even see the toast? Did it disappear before they finished reading it? Did the user even understand the message, let alone which action caused it?

There are plenty of sites that use toasts though. My early example was Gmail, and that is used by millions of people around the world. Even Apple uses toasts. What is a notification on the Mac desktop if not a toast? We also have mobile notifications on Android and iOS devices that are basically toasts for different apps to get your attention.

Toasts have their place, but they require considerably more thought than their simple UI suggests. The next time you reach for one, ask your team: is there a better way to convey the same information?

Toasts Are Harder Than They Look

"use strict";
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = {
    a: "a",
    code: "code",
    h2: "h2",
    input: "input",
    li: "li",
    p: "p",
    pre: "pre",
    ul: "ul",
    ...props.components
  };
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "This post was originally on a blog I started for creating web applications. This post goes into User Interface design for web applications."
    }), "\n", _jsx(_components.p, {
      children: "User Experience is one of the most important parts of web applications."
    }), "\n", _jsx(_components.p, {
      children: "The following are tips and questions to consider when working on your web application user interface."
    }), "\n", _jsx(_components.h2, {
      children: "Test for Consistency Between Browsers"
    }), "\n", _jsx(_components.p, {
      children: "Are there tests for consistency with:"
    }), "\n", _jsxs(_components.ul, {
      className: "contains-task-list",
      children: ["\n", _jsxs(_components.li, {
        className: "task-list-item",
        children: [_jsx(_components.input, {
          type: "checkbox",
          disabled: true
        }), " ", "The ", _jsx(_components.a, {
          href: "http://en.wikipedia.org/wiki/Gecko_%28layout_engine%29",
          children: "Gecko"
        }), " engine - i.e. ", _jsx(_components.a, {
          href: "http://firefox.com/",
          children: "Firefox"
        }), "."]
      }), "\n", _jsxs(_components.li, {
        className: "task-list-item",
        children: [_jsx(_components.input, {
          type: "checkbox",
          disabled: true
        }), " ", "The Webkit engine - i.e. ", _jsx(_components.a, {
          href: "http://www.apple.com/safari/",
          children: "Safari"
        }), "."]
      }), "\n", _jsxs(_components.li, {
        className: "task-list-item",
        children: [_jsx(_components.input, {
          type: "checkbox",
          disabled: true
        }), " ", _jsx(_components.a, {
          href: "http://www.google.com/chrome",
          children: "Chrome"
        }), "."]
      }), "\n", _jsxs(_components.li, {
        className: "task-list-item",
        children: [_jsx(_components.input, {
          type: "checkbox",
          disabled: true
        }), " ", _jsx(_components.a, {
          href: "http://www.opera.com/",
          children: "Opera"
        }), "."]
      }), "\n", _jsxs(_components.li, {
        className: "task-list-item",
        children: [_jsx(_components.input, {
          type: "checkbox",
          disabled: true
        }), " ", "IE Browsers - take advantage of the ", _jsx(_components.a, {
          href: "http://www.microsoft.com/Downloads/details.aspx?FamilyID=21eabb90-958f-4b64-b5f1-73d0a413c8ef&displaylang=en",
          children: "Application Compatibility VPC Images"
        }), "."]
      }), "\n"]
    }), "\n", _jsxs(_components.p, {
      children: ["For IE Browsers, there is a Github project call ", _jsx(_components.a, {
        href: "https://github.com/xdissent/ievms",
        children: "ievms"
      }), " which provides Virtual Machines with IE6, IE7, IE8, IE8, IE10, and IE11."]
    }), "\n", _jsxs(_components.p, {
      children: ["Also consider how the same browser will render your site on differnet operating systems. Consider a service like ", _jsx(_components.a, {
        href: "http://www.browsershots.org/",
        children: "Browsershots"
      }), " or ", _jsx(_components.a, {
        href: "https://litmus.com/",
        children: "Litmus"
      }), "."]
    }), "\n", _jsx(_components.h2, {
      children: "Do your Positive, Negative, and Neutral Buttons look different?"
    }), "\n", _jsxs(_components.p, {
      children: ["Image from ", _jsx(_components.a, {
        href: "http://uxmovement.com/buttons/how-button-color-contrast-guides-users-to-action/",
        children: "UX Movement"
      }), "."]
    }), "\n", _jsx(_components.p, {
      children: "Have your Positive Action buttons and your Neutral and Negative Action buttons look distinctly different.  Notice that in the above example, not only are the colors different, but one is bordered and ther other is filled in, making it accessible to those with color-blindness."
    }), "\n", _jsx(_components.h2, {
      children: "Test for Mobile Consistency"
    }), "\n", _jsx(_components.p, {
      children: "Are there tests for consistency with:"
    }), "\n", _jsxs(_components.ul, {
      className: "contains-task-list",
      children: ["\n", _jsxs(_components.li, {
        className: "task-list-item",
        children: [_jsx(_components.input, {
          type: "checkbox",
          disabled: true
        }), " ", "Android phones and tablets"]
      }), "\n", _jsxs(_components.li, {
        className: "task-list-item",
        children: [_jsx(_components.input, {
          type: "checkbox",
          disabled: true
        }), " ", "iOS phones and tablets"]
      }), "\n", _jsxs(_components.li, {
        className: "task-list-item",
        children: [_jsx(_components.input, {
          type: "checkbox",
          disabled: true
        }), " ", "Screen readers"]
      }), "\n", _jsxs(_components.li, {
        className: "task-list-item",
        children: [_jsx(_components.input, {
          type: "checkbox",
          disabled: true
        }), " ", "Search engines"]
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "For more information, check out Mobile and Developer Tools."
    }), "\n", _jsx(_components.h2, {
      children: "Do you have a staging environment?"
    }), "\n", _jsx(_components.p, {
      children: "Can you deploy updates without affecting your users?"
    }), "\n", _jsx(_components.p, {
      children: "Testing and staging environments are important for being able to test features, architecture, etc without breaking the user's session."
    }), "\n", _jsxs(_components.p, {
      children: ["Have an automated way of deploying approved changes to the live site. Consider using a version control system with an automated build system (something like ", _jsx(_components.a, {
        href: "http://maven.apache.org/",
        children: "Maven"
      }), ")."]
    }), "\n", _jsx(_components.h2, {
      children: "Are errors handled in a friendly matter?"
    }), "\n", _jsx(_components.p, {
      children: "Users should receive easy to read error messages."
    }), "\n", _jsx(_components.p, {
      children: "Users should never see:"
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsx(_components.li, {
        children: "Out Of Memory errors"
      }), "\n", _jsx(_components.li, {
        children: "Raw 404 pages"
      }), "\n", _jsx(_components.li, {
        children: "Stack Traces"
      }), "\n"]
    }), "\n", _jsx(_components.h2, {
      children: "Is user info crawlable on public pages?"
    }), "\n", _jsx(_components.p, {
      children: "Try not to have users' email in plain text on public facing pages.  They might get spammed."
    }), "\n", _jsxs(_components.h2, {
      children: ["Is the ", _jsx(_components.code, {
        children: "rel=\"nofollow\""
      }), " attribute on user-generated links?"]
    }), "\n", _jsxs(_components.p, {
      children: ["Avoid spam by putting the ", _jsx(_components.a, {
        href: "http://en.wikipedia.org/wiki/Nofollow",
        children: "nofollow"
      }), " on user generated links."]
    }), "\n", _jsx(_components.h2, {
      children: "Does your site have built in rate limiting and velocity checking?"
    }), "\n", _jsx(_components.p, {
      children: "Any user actions should have rate limiting and velocity checking built in.  This is also a security issue."
    }), "\n", _jsxs(_components.p, {
      children: ["Look into ", _jsx(_components.a, {
        href: "http://blog.codinghorror.com/rate-limiting-and-velocity-checking/",
        children: "Coding Horror's post on rate limiting and velocity checking"
      }), " for more information."]
    }), "\n", _jsx(_components.h2, {
      children: "No inline styles"
    }), "\n", _jsx(_components.p, {
      children: "All CSS should be in stylesheets."
    }), "\n", _jsx(_components.h2, {
      children: "Accessibility"
    }), "\n", _jsx(_components.p, {
      children: "Check to make sure your website is navigable from screen readers."
    }), "\n", _jsxs(_components.p, {
      children: ["If you are using ", _jsx(_components.a, {
        href: "http://getbootstrap.com/",
        children: "Twitter Bootstrap"
      }), ", look into the ", _jsx(_components.a, {
        href: "http://paypal.github.io/bootstrap-accessibility-plugin/",
        children: "Bootstrap accessibility plugin"
      }), "."]
    }), "\n", _jsxs(_components.p, {
      children: ["If you are using ", _jsx(_components.a, {
        href: "http://foundation.zurb.com/",
        children: "Foundation"
      }), ", look into how ", _jsx(_components.a, {
        href: "http://zurb.com/article/1337/foundation-now-helps-you-build-accessible",
        children: "Foundation is built around accessibility"
      }), "."]
    }), "\n", _jsx(_components.p, {
      children: "For more on accessibility, see the full page on Accessibility."
    }), "\n", _jsx(_components.h2, {
      children: "Are you using HTML5?"
    }), "\n", _jsxs(_components.p, {
      children: ["If you can, start out by using HTML5.  If you do so, remember to include the ", _jsx(_components.a, {
        href: "http://en.wikipedia.org/wiki/HTML5_Shiv",
        children: "HTML5 Shiv"
      }), " (or Shim) so that IE version before 9 can use HTML5 elements."]
    }), "\n", _jsxs(_components.p, {
      children: ["Look into ", _jsx(_components.a, {
        href: "http://html5boilerplate.com/",
        children: "HTML5 Boilerplate"
      }), " or ", _jsx(_components.a, {
        href: "http://www.initializr.com/",
        children: "Initialzr"
      }), " for an HTML5 boilerplate that comes with the HTML5 shim, normalize.css, and Modernizr."]
    }), "\n", _jsx(_components.h2, {
      children: "Consider Using Normalize.css"
    }), "\n", _jsxs(_components.p, {
      children: ["Consider reseting the browser style sheets or using ", _jsx(_components.a, {
        href: "http://necolas.github.io/normalize.css/",
        children: "normalize.css"
      }), " for consistency between browsers."]
    }), "\n", _jsx(_components.h2, {
      children: "Are you using Semantic HTML?"
    }), "\n", _jsxs(_components.p, {
      children: ["Recent HTML standards discourage the use of the ", _jsx(_components.code, {
        children: "<i>"
      }), " in preference for the ", _jsx(_components.code, {
        children: "<em>"
      }), " tag. Other HTML5 tas to consider using are:"]
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsx(_components.li, {
        children: _jsx(_components.code, {
          children: "<article>"
        })
      }), "\n", _jsx(_components.li, {
        children: _jsx(_components.code, {
          children: "<aside>"
        })
      }), "\n", _jsx(_components.li, {
        children: _jsx(_components.code, {
          children: "<details>"
        })
      }), "\n", _jsx(_components.li, {
        children: _jsx(_components.code, {
          children: "<figcaption>"
        })
      }), "\n", _jsx(_components.li, {
        children: _jsx(_components.code, {
          children: "<figure>"
        })
      }), "\n", _jsx(_components.li, {
        children: _jsx(_components.code, {
          children: "<footer>"
        })
      }), "\n", _jsx(_components.li, {
        children: _jsx(_components.code, {
          children: "<header>"
        })
      }), "\n", _jsx(_components.li, {
        children: _jsx(_components.code, {
          children: "<main>"
        })
      }), "\n", _jsx(_components.li, {
        children: _jsx(_components.code, {
          children: "<mark>"
        })
      }), "\n", _jsx(_components.li, {
        children: _jsx(_components.code, {
          children: "<nav>"
        })
      }), "\n", _jsx(_components.li, {
        children: _jsx(_components.code, {
          children: "<section>"
        })
      }), "\n", _jsx(_components.li, {
        children: _jsx(_components.code, {
          children: "<summary>"
        })
      }), "\n", _jsx(_components.li, {
        children: _jsx(_components.code, {
          children: "<time>"
        })
      }), "\n"]
    }), "\n", _jsx(_components.h2, {
      children: "Redirect after a POST"
    }), "\n", _jsx(_components.p, {
      children: "After a user POSTs data, redirect to a success page, to prevent a refresh from submitting data again."
    }), "\n", _jsx(_components.h2, {
      children: "Use Progressive Enhancement"
    }), "\n", _jsx(_components.p, {
      children: "Allow graceful degradation of your website."
    }), "\n", _jsxs(_components.ul, {
      className: "contains-task-list",
      children: ["\n", _jsxs(_components.li, {
        className: "task-list-item",
        children: [_jsx(_components.input, {
          type: "checkbox",
          disabled: true
        }), " ", "Basic content should be accessible to all web browsers"]
      }), "\n", _jsxs(_components.li, {
        className: "task-list-item",
        children: [_jsx(_components.input, {
          type: "checkbox",
          disabled: true
        }), " ", "Basic functionality should be accessible to all web browsers"]
      }), "\n", _jsxs(_components.li, {
        className: "task-list-item",
        children: [_jsx(_components.input, {
          type: "checkbox",
          disabled: true
        }), " ", "Sparse, semantic markup contains all content"]
      }), "\n", _jsxs(_components.li, {
        className: "task-list-item",
        children: [_jsx(_components.input, {
          type: "checkbox",
          disabled: true
        }), " ", "Enhanced layout is provided by externally linked CSS"]
      }), "\n", _jsxs(_components.li, {
        className: "task-list-item",
        children: [_jsx(_components.input, {
          type: "checkbox",
          disabled: true
        }), " ", "Enhanced behavior is provided by unobtrusive, externally linked JavaScript"]
      }), "\n", _jsxs(_components.li, {
        className: "task-list-item",
        children: [_jsx(_components.input, {
          type: "checkbox",
          disabled: true
        }), " ", "End-user web browser preferences are respected"]
      }), "\n"]
    }), "\n", _jsxs(_components.p, {
      children: ["See ", _jsx(_components.a, {
        href: "http://en.wikipedia.org/wiki/Progressive_enhancement",
        children: "Progressive Enhancement"
      }), " for more information."]
    }), "\n", _jsx(_components.h2, {
      children: "Validate Forms"
    }), "\n", _jsx(_components.p, {
      children: "Going along with Security, make sure to validate all form input on the server side and give useful errors back to the user.  Once proper form security handling has been implemented, add in client side validation.  You can use HTML5's simple validation to add a small layer of responsive validation:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-html",
        children: "<input id=\"username\" placeholder=\"John Jones\" required>\n"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["You can use the ", _jsx(_components.code, {
        children: "required"
      }), " attribute to let users know on the client side before they submit their form that a field is required."]
    }), "\n", _jsx(_components.p, {
      children: "You can use the new input type to help with input validation as well:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-html",
        children: "<input type=\"email\" required>\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "You can mark invalid input with CSS as well:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-css",
        children: "input:required:invalid {\n  background: red;\n}\n"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["Checkout ", _jsx(_components.a, {
        href: "http://basicuse.net/articles/pl/textile/html_css/form_validation_in_html5",
        children: "Form Validation in HTML 5"
      }), " for more information."]
    }), "\n", _jsx(_components.h2, {
      children: "Use CSS Animations over JavaScript Animations"
    }), "\n", _jsxs(_components.p, {
      children: ["You can now use CSS animations instead of relying on JavaScript.  You can read more about CSS animations on the ", _jsx(_components.a, {
        href: "https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Using_CSS_animations",
        children: "Mozilla Developer Network"
      }), "."]
    }), "\n", _jsx(_components.h2, {
      children: "Look at Little Big Details"
    }), "\n", _jsxs(_components.p, {
      children: [_jsx(_components.a, {
        href: "http://littlebigdetails.com/",
        children: "Little Big Details"
      }), " contains design inspiration from the point of view of the users."]
    }), "\n", _jsx(_components.p, {
      children: "For more websites about UI, look at our developer tools list."
    }), "\n", _jsx(_components.h2, {
      children: "Responsive Grids"
    }), "\n", _jsx(_components.p, {
      children: "Having a responsve layout is great for creating one application that looks good on mobile and desktop devices.  A Responsive Layout can be achieved by using popular frameworks like:"
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsx(_components.li, {
        children: _jsx(_components.a, {
          href: "http://getbootstrap.com/",
          children: "Bootstrap"
        })
      }), "\n", _jsx(_components.li, {
        children: _jsx(_components.a, {
          href: "http://semantic-ui.com/",
          children: "SemanticUI"
        })
      }), "\n", _jsx(_components.li, {
        children: _jsx(_components.a, {
          href: "http://foundation.zurb.com/",
          children: "Foundation"
        })
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "and more."
    }), "\n", _jsxs(_components.p, {
      children: ["You can also create a custom grid if the above frameworks are too large for you to use.  Check out ", _jsx(_components.a, {
        href: "http://jordanlev.github.io/grid/",
        children: "this tutorial on Minimal Responsive Grids"
      }), "."]
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, {
    ...props,
    children: _jsx(_createMdxContent, {
      ...props
    })
  }) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>This post was originally on a blog I started for creating web applications. This post goes into User Interface design for web applications.</p>
<p>User Experience is one of the most important parts of web applications.</p>
<p>The following are tips and questions to consider when working on your web application user interface.</p>
<h2>Test for Consistency Between Browsers</h2>
<p>Are there tests for consistency with:</p>
<ul class="contains-task-list">
<li class="task-list-item"><input type="checkbox" disabled=""/> The <a href="http://en.wikipedia.org/wiki/Gecko_%28layout_engine%29">Gecko</a> engine - i.e. <a href="http://firefox.com/">Firefox</a>.</li>
<li class="task-list-item"><input type="checkbox" disabled=""/> The Webkit engine - i.e. <a href="http://www.apple.com/safari/">Safari</a>.</li>
<li class="task-list-item"><input type="checkbox" disabled=""/> <a href="http://www.google.com/chrome">Chrome</a>.</li>
<li class="task-list-item"><input type="checkbox" disabled=""/> <a href="http://www.opera.com/">Opera</a>.</li>
<li class="task-list-item"><input type="checkbox" disabled=""/> IE Browsers - take advantage of the <a href="http://www.microsoft.com/Downloads/details.aspx?FamilyID=21eabb90-958f-4b64-b5f1-73d0a413c8ef&amp;displaylang=en">Application Compatibility VPC Images</a>.</li>
</ul>
<p>For IE Browsers, there is a Github project call <a href="https://github.com/xdissent/ievms">ievms</a> which provides Virtual Machines with IE6, IE7, IE8, IE8, IE10, and IE11.</p>
<p>Also consider how the same browser will render your site on differnet operating systems. Consider a service like <a href="http://www.browsershots.org/">Browsershots</a> or <a href="https://litmus.com/">Litmus</a>.</p>
<h2>Do your Positive, Negative, and Neutral Buttons look different?</h2>
<p>Image from <a href="http://uxmovement.com/buttons/how-button-color-contrast-guides-users-to-action/">UX Movement</a>.</p>
<p>Have your Positive Action buttons and your Neutral and Negative Action buttons look distinctly different.  Notice that in the above example, not only are the colors different, but one is bordered and ther other is filled in, making it accessible to those with color-blindness.</p>
<h2>Test for Mobile Consistency</h2>
<p>Are there tests for consistency with:</p>
<ul class="contains-task-list">
<li class="task-list-item"><input type="checkbox" disabled=""/> Android phones and tablets</li>
<li class="task-list-item"><input type="checkbox" disabled=""/> iOS phones and tablets</li>
<li class="task-list-item"><input type="checkbox" disabled=""/> Screen readers</li>
<li class="task-list-item"><input type="checkbox" disabled=""/> Search engines</li>
</ul>
<p>For more information, check out Mobile and Developer Tools.</p>
<h2>Do you have a staging environment?</h2>
<p>Can you deploy updates without affecting your users?</p>
<p>Testing and staging environments are important for being able to test features, architecture, etc without breaking the user&#x27;s session.</p>
<p>Have an automated way of deploying approved changes to the live site. Consider using a version control system with an automated build system (something like <a href="http://maven.apache.org/">Maven</a>).</p>
<h2>Are errors handled in a friendly matter?</h2>
<p>Users should receive easy to read error messages.</p>
<p>Users should never see:</p>
<ul>
<li>Out Of Memory errors</li>
<li>Raw 404 pages</li>
<li>Stack Traces</li>
</ul>
<h2>Is user info crawlable on public pages?</h2>
<p>Try not to have users&#x27; email in plain text on public facing pages.  They might get spammed.</p>
<h2>Is the <code>rel=&quot;nofollow&quot;</code> attribute on user-generated links?</h2>
<p>Avoid spam by putting the <a href="http://en.wikipedia.org/wiki/Nofollow">nofollow</a> on user generated links.</p>
<h2>Does your site have built in rate limiting and velocity checking?</h2>
<p>Any user actions should have rate limiting and velocity checking built in.  This is also a security issue.</p>
<p>Look into <a href="http://blog.codinghorror.com/rate-limiting-and-velocity-checking/">Coding Horror&#x27;s post on rate limiting and velocity checking</a> for more information.</p>
<h2>No inline styles</h2>
<p>All CSS should be in stylesheets.</p>
<h2>Accessibility</h2>
<p>Check to make sure your website is navigable from screen readers.</p>
<p>If you are using <a href="http://getbootstrap.com/">Twitter Bootstrap</a>, look into the <a href="http://paypal.github.io/bootstrap-accessibility-plugin/">Bootstrap accessibility plugin</a>.</p>
<p>If you are using <a href="http://foundation.zurb.com/">Foundation</a>, look into how <a href="http://zurb.com/article/1337/foundation-now-helps-you-build-accessible">Foundation is built around accessibility</a>.</p>
<p>For more on accessibility, see the full page on Accessibility.</p>
<h2>Are you using HTML5?</h2>
<p>If you can, start out by using HTML5.  If you do so, remember to include the <a href="http://en.wikipedia.org/wiki/HTML5_Shiv">HTML5 Shiv</a> (or Shim) so that IE version before 9 can use HTML5 elements.</p>
<p>Look into <a href="http://html5boilerplate.com/">HTML5 Boilerplate</a> or <a href="http://www.initializr.com/">Initialzr</a> for an HTML5 boilerplate that comes with the HTML5 shim, normalize.css, and Modernizr.</p>
<h2>Consider Using Normalize.css</h2>
<p>Consider reseting the browser style sheets or using <a href="http://necolas.github.io/normalize.css/">normalize.css</a> for consistency between browsers.</p>
<h2>Are you using Semantic HTML?</h2>
<p>Recent HTML standards discourage the use of the <code>&lt;i&gt;</code> in preference for the <code>&lt;em&gt;</code> tag. Other HTML5 tas to consider using are:</p>
<ul>
<li><code>&lt;article&gt;</code></li>
<li><code>&lt;aside&gt;</code></li>
<li><code>&lt;details&gt;</code></li>
<li><code>&lt;figcaption&gt;</code></li>
<li><code>&lt;figure&gt;</code></li>
<li><code>&lt;footer&gt;</code></li>
<li><code>&lt;header&gt;</code></li>
<li><code>&lt;main&gt;</code></li>
<li><code>&lt;mark&gt;</code></li>
<li><code>&lt;nav&gt;</code></li>
<li><code>&lt;section&gt;</code></li>
<li><code>&lt;summary&gt;</code></li>
<li><code>&lt;time&gt;</code></li>
</ul>
<h2>Redirect after a POST</h2>
<p>After a user POSTs data, redirect to a success page, to prevent a refresh from submitting data again.</p>
<h2>Use Progressive Enhancement</h2>
<p>Allow graceful degradation of your website.</p>
<ul class="contains-task-list">
<li class="task-list-item"><input type="checkbox" disabled=""/> Basic content should be accessible to all web browsers</li>
<li class="task-list-item"><input type="checkbox" disabled=""/> Basic functionality should be accessible to all web browsers</li>
<li class="task-list-item"><input type="checkbox" disabled=""/> Sparse, semantic markup contains all content</li>
<li class="task-list-item"><input type="checkbox" disabled=""/> Enhanced layout is provided by externally linked CSS</li>
<li class="task-list-item"><input type="checkbox" disabled=""/> Enhanced behavior is provided by unobtrusive, externally linked JavaScript</li>
<li class="task-list-item"><input type="checkbox" disabled=""/> End-user web browser preferences are respected</li>
</ul>
<p>See <a href="http://en.wikipedia.org/wiki/Progressive_enhancement">Progressive Enhancement</a> for more information.</p>
<h2>Validate Forms</h2>
<p>Going along with Security, make sure to validate all form input on the server side and give useful errors back to the user.  Once proper form security handling has been implemented, add in client side validation.  You can use HTML5&#x27;s simple validation to add a small layer of responsive validation:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-html">&lt;input id=&quot;username&quot; placeholder=&quot;John Jones&quot; required&gt;
</code></pre></div>
<p>You can use the <code>required</code> attribute to let users know on the client side before they submit their form that a field is required.</p>
<p>You can use the new input type to help with input validation as well:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-html">&lt;input type=&quot;email&quot; required&gt;
</code></pre></div>
<p>You can mark invalid input with CSS as well:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-css">input:required:invalid {
  background: red;
}
</code></pre></div>
<p>Checkout <a href="http://basicuse.net/articles/pl/textile/html_css/form_validation_in_html5">Form Validation in HTML 5</a> for more information.</p>
<h2>Use CSS Animations over JavaScript Animations</h2>
<p>You can now use CSS animations instead of relying on JavaScript.  You can read more about CSS animations on the <a href="https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Using_CSS_animations">Mozilla Developer Network</a>.</p>
<h2>Look at Little Big Details</h2>
<p><a href="http://littlebigdetails.com/">Little Big Details</a> contains design inspiration from the point of view of the users.</p>
<p>For more websites about UI, look at our developer tools list.</p>
<h2>Responsive Grids</h2>
<p>Having a responsve layout is great for creating one application that looks good on mobile and desktop devices.  A Responsive Layout can be achieved by using popular frameworks like:</p>
<ul>
<li><a href="http://getbootstrap.com/">Bootstrap</a></li>
<li><a href="http://semantic-ui.com/">SemanticUI</a></li>
<li><a href="http://foundation.zurb.com/">Foundation</a></li>
</ul>
<p>and more.</p>
<p>You can also create a custom grid if the above frameworks are too large for you to use.  Check out <a href="http://jordanlev.github.io/grid/">this tutorial on Minimal Responsive Grids</a>.</p>


This post was originally on a blog I started for creating web applications. This post goes into User Interface design for web applications.

User Experience is one of the most important parts of web applications.

The following are tips and questions to consider when working on your web application user interface.

## Test for Consistency Between Browsers

Are there tests for consistency with:

- [ ] The [Gecko](http://en.wikipedia.org/wiki/Gecko_%28layout_engine%29) engine - i.e. [Firefox](http://firefox.com/).
- [ ] The Webkit engine - i.e. [Safari](http://www.apple.com/safari/).
- [ ] [Chrome](http://www.google.com/chrome).
- [ ] [Opera](http://www.opera.com/).
- [ ] IE Browsers - take advantage of the [Application Compatibility VPC Images](http://www.microsoft.com/Downloads/details.aspx?FamilyID=21eabb90-958f-4b64-b5f1-73d0a413c8ef&displaylang=en).

For IE Browsers, there is a Github project call [ievms](https://github.com/xdissent/ievms) which provides Virtual Machines with IE6, IE7, IE8, IE8, IE10, and IE11.

Also consider how the same browser will render your site on differnet operating systems. Consider a service like [Browsershots](http://www.browsershots.org/) or [Litmus](https://litmus.com/).

## Do your Positive, Negative, and Neutral Buttons look different?

Image from [UX Movement](http://uxmovement.com/buttons/how-button-color-contrast-guides-users-to-action/).

Have your Positive Action buttons and your Neutral and Negative Action buttons look distinctly different.  Notice that in the above example, not only are the colors different, but one is bordered and ther other is filled in, making it accessible to those with color-blindness.

## Test for Mobile Consistency

Are there tests for consistency with:

- [ ] Android phones and tablets
- [ ] iOS phones and tablets
- [ ] Screen readers
- [ ] Search engines

For more information, check out Mobile and Developer Tools.

## Do you have a staging environment?

Can you deploy updates without affecting your users?

Testing and staging environments are important for being able to test features, architecture, etc without breaking the user's session.

Have an automated way of deploying approved changes to the live site. Consider using a version control system with an automated build system (something like [Maven](http://maven.apache.org/)).

## Are errors handled in a friendly matter?

Users should receive easy to read error messages.

Users should never see:

- Out Of Memory errors
- Raw 404 pages
- Stack Traces

## Is user info crawlable on public pages?

Try not to have users' email in plain text on public facing pages.  They might get spammed.

## Is the `rel="nofollow"` attribute on user-generated links?

Avoid spam by putting the [nofollow](http://en.wikipedia.org/wiki/Nofollow) on user generated links.

## Does your site have built in rate limiting and velocity checking?

Any user actions should have rate limiting and velocity checking built in.  This is also a security issue.

Look into [Coding Horror's post on rate limiting and velocity checking](http://blog.codinghorror.com/rate-limiting-and-velocity-checking/) for more information.

## No inline styles

All CSS should be in stylesheets.

## Accessibility

Check to make sure your website is navigable from screen readers.

If you are using [Twitter Bootstrap](http://getbootstrap.com/), look into the [Bootstrap accessibility plugin](http://paypal.github.io/bootstrap-accessibility-plugin/).

If you are using [Foundation](http://foundation.zurb.com/), look into how [Foundation is built around accessibility](http://zurb.com/article/1337/foundation-now-helps-you-build-accessible).

For more on accessibility, see the full page on Accessibility.

## Are you using HTML5?

If you can, start out by using HTML5.  If you do so, remember to include the [HTML5 Shiv](http://en.wikipedia.org/wiki/HTML5_Shiv) (or Shim) so that IE version before 9 can use HTML5 elements.

Look into [HTML5 Boilerplate](http://html5boilerplate.com/) or [Initialzr](http://www.initializr.com/) for an HTML5 boilerplate that comes with the HTML5 shim, normalize.css, and Modernizr.

## Consider Using Normalize.css

Consider reseting the browser style sheets or using [normalize.css](http://necolas.github.io/normalize.css/) for consistency between browsers.

## Are you using Semantic HTML?

Recent HTML standards discourage the use of the `<i>` in preference for the `<em>` tag. Other HTML5 tas to consider using are:

- `<article>`
- `<aside>`
- `<details>`
- `<figcaption>`
- `<figure>`
- `<footer>`
- `<header>`
- `<main>`
- `<mark>`
- `<nav>`
- `<section>`
- `<summary>`
- `<time>`

## Redirect after a POST

After a user POSTs data, redirect to a success page, to prevent a refresh from submitting data again.

## Use Progressive Enhancement

Allow graceful degradation of your website.

- [ ] Basic content should be accessible to all web browsers
- [ ] Basic functionality should be accessible to all web browsers
- [ ] Sparse, semantic markup contains all content
- [ ] Enhanced layout is provided by externally linked CSS
- [ ] Enhanced behavior is provided by unobtrusive, externally linked JavaScript
- [ ] End-user web browser preferences are respected

See [Progressive Enhancement](http://en.wikipedia.org/wiki/Progressive_enhancement) for more information.

## Validate Forms

Going along with Security, make sure to validate all form input on the server side and give useful errors back to the user.  Once proper form security handling has been implemented, add in client side validation.  You can use HTML5's simple validation to add a small layer of responsive validation:

```html
<input id="username" placeholder="John Jones" required>
```

You can use the `required` attribute to let users know on the client side before they submit their form that a field is required.

You can use the new input type to help with input validation as well:

```html
<input type="email" required>
```

You can mark invalid input with CSS as well:

```css
input:required:invalid {
  background: red;
}
```

Checkout [Form Validation in HTML 5](http://basicuse.net/articles/pl/textile/html_css/form_validation_in_html5) for more information.

## Use CSS Animations over JavaScript Animations

You can now use CSS animations instead of relying on JavaScript.  You can read more about CSS animations on the [Mozilla Developer Network](https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Using_CSS_animations).

## Look at Little Big Details

[Little Big Details](http://littlebigdetails.com/) contains design inspiration from the point of view of the users.

For more websites about UI, look at our developer tools list.

## Responsive Grids

Having a responsve layout is great for creating one application that looks good on mobile and desktop devices.  A Responsive Layout can be achieved by using popular frameworks like:

- [Bootstrap](http://getbootstrap.com/)
- [SemanticUI](http://semantic-ui.com/)
- [Foundation](http://foundation.zurb.com/)

and more.

You can also create a custom grid if the above frameworks are too large for you to use.  Check out [this tutorial on Minimal Responsive Grids](http://jordanlev.github.io/grid/).
