[T]he basic questions an empty state should answer are:
- What is this screen?
- Why am I seeing it?
- How can I fix this problem?
On top of this, you should aim to:
- Communicate personality. Make your app a joy to use and connect feelings with features.
- Explain the benefits. This is critical for your first-use empty states so your users know why they should care.
URI
A URI identifies a resource either by location, or a name, or both. More often than not, most of us use URIs that defines a location to a resource. The fact that a URI can identify a resources by both name and location has lead to a lot of the confusion in my opionion. A URI has two specializations known as URL and URN.
URN
A URI identifies a resource by name in a given namespace but not define how the resource maybe obtained. This type of URI is called a URN. You may see URNs used in XML Schema documents to define a namespace, usually using a syntax such as:
<xsd:schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:example"Here the
targetNamespaceuse a URN. It defines an identifier to the namespace, but it does not define a location.URL
A URL is a specialization of URI that defines the network location of a specific resource. Unlike a URN, the URL defines how the resource can be obtained. We use URLs every day in the form of http://damnhandy.com, etc. But a URL doesn’t have to be an HTTP URL, it can be ftp://damnhandy.com, smb://damnhandy.com, etc.
The Difference Between Them
So what is the difference between URI and URL? It’s not as clear cut as I would like, but here’s my stab at it:
A URI is an identifier for some resource, but a URL gives you specific information as to obtain that resource. A URI is a URL and as one commenter pointed out, it is now considered incorrect to use URL when describing applications. Generally, if the URL describes both the location and name of a resource, the term to use is URI. Since this is generally the case most of us encounter everyday, URI is the correct term.
When porting some front-end code from Drupal 7 to Drupal 8, I ran into an unexpected change in the use of jQuery.once(). In Drupal 7, you’d do this in a behavior:
Drupal.behaviors.exampleBehavior = {
attach: function(context, settings) {
$('.example', context).once('example-behavior', function() {
// Do stuff.
});
},
detach: function(context, settings, trigger) {
$('.example', context).removeOnce('example-behavior', function() {
// Undo stuff.
});
}
};
In Drupal 8, however, you can’t pass in a function to jQuery.once(), as the API for that jQuery plugin has changed. It now acts like jQuery.filter(), in that it filters out any elements that have already been processed so they aren’t processed more than once, and returns a jQuery collection. So, in Drupal 8, the example would be:
Drupal.behaviors.exampleBehavior = {
attach: function(context, settings) {
$('.example', context).once('example-behavior').each(function() {
// Do stuff.
});
},
detach: function(context, settings, trigger) {
$('.example', context).removeOnce('example-behavior').each(function() {
// Undo stuff.
});
}
};
This is a great visual example of why you shouldn’t assume that having a touch screen always equals a phone or tablet.
This seems useful. Found on the Configuration schema/metadata Drupal 8 API guide on Drupal.org, which is super useful.
