February 5, 2009 at 15:41Decorative and significant elements in the design of interfaces
- Transfer
Translation of the article " Distinguishing decorative from meaningful elements in UI design ".
As interface designers, we want our work to look good and be understandable. Each element on the screen should caress the eye, and at the same time, interfaces are not just objects. They should work. Interfaces should provide information and clearly indicate possible directions for action. These two sides - sex appeal and functionality, attractiveness and simplicity, design and significance - they often coexist with an experienced designer. But there is still a danger of a conflict between how it should look like and how it will be perceived by the user ( they would only be about customers, not to think about people ... - thought aloud per.) I recently drew attention to this kind of contradiction between design and value on the GitHub service .
After you log in to GitHub, a general navigation menu will appear on the right side of the header. The navigation block is framed by a rounded rectangle:
Look at the rectangle that links the entire block together. It has a light blue background, and around it is limited by a gray frame. Border and background are decorative. They stylize the block and enhance visual appeal. To help you see the decorativeness of these elements, I whipped up a comparison between the original version (top) and the new version without a border and background (bottom):
Both options are pleasing to the eye and the functionality in them seems the same. You have the right to say that the difference between them is rather aesthetic. But there is one more thing. The decision to combine links is much deeper. A decorative container actually changes the meaning of links and, as we will see later, leads to a problem for GitHub. To understand the reason, we first need to look at how the combination of elements affects the perception of design by the user.
When you put a link inside a container, you are assuming a link between the container and the link. Technically speaking, you make one part of the other. As a more familiar example, take a look at the editing links that you often see in web applications: The two editing links are combined by their respective containers. The user expects that the “edit” top link is for editing the “Michael Bluth” record, since the link is in the same cell as Michael’s name. The edit links themselves are the same. The difference is in the containers.
So how does this relate to navigation on GitHub? Link issue (“repositories: all"). GitHub hosts thousands of open repositories, open to anyone and everyone. And at the same time, each user can have their own repositories. And just here we find ambiguity in the design of their navigation.
When the navigation block is framed, the “all” link appears to be enclosed in the framework of the active user. By link, you expect to see all repositories that belong only to this user. Compare this with the frameless version. It is not so obvious here whether the link “all” leads to the list of Michael’s repositories or to the main list of absolutely all repositories.
At first, the frame around the GitHub navigation box looked exclusively as a matter of style. We now see that aesthetic decisions can also affect the understanding of design by the user. In the case of GitHub, the expectations created by framed links do not match the actual behavior. When you click the “all” link, you don’t get on the list of repositories of the current user. Instead, you find yourself in the main list of public repositories for all users. It turns out that in order to see the list of repositories of the active user, you need to click on his name next to the avatar. Wisely!
How could we change the design to eliminate confusion?
[..] - the first version of the "redesign" proposed by the author of the article is omitted, as it is frankly bad, especially compared to the following, - approx. trans.
You can save the decorative frame of the original and use “authorship” in order to “outweigh” the obvious logic: This option uses 2 links - “all” (“all”) and “mine” (“mine”) - for sharing between the main list of all repositories and a list of repositories that belong only to the active user.
GitHub is a great service. And I know that I find fault. But at the same time, the design of user interfaces is a delicate matter. As designers, we must be aware that sometimes when we design for the eyes, we can forget about design for the brain. I hope these examples help you better feel the line between decorative elements and elements that change the meaning of your interfaces.
As interface designers, we want our work to look good and be understandable. Each element on the screen should caress the eye, and at the same time, interfaces are not just objects. They should work. Interfaces should provide information and clearly indicate possible directions for action. These two sides - sex appeal and functionality, attractiveness and simplicity, design and significance - they often coexist with an experienced designer. But there is still a danger of a conflict between how it should look like and how it will be perceived by the user ( they would only be about customers, not to think about people ... - thought aloud per.) I recently drew attention to this kind of contradiction between design and value on the GitHub service .
Basic GitHub Navigation
After you log in to GitHub, a general navigation menu will appear on the right side of the header. The navigation block is framed by a rounded rectangle:
Look at the rectangle that links the entire block together. It has a light blue background, and around it is limited by a gray frame. Border and background are decorative. They stylize the block and enhance visual appeal. To help you see the decorativeness of these elements, I whipped up a comparison between the original version (top) and the new version without a border and background (bottom):
Both options are pleasing to the eye and the functionality in them seems the same. You have the right to say that the difference between them is rather aesthetic. But there is one more thing. The decision to combine links is much deeper. A decorative container actually changes the meaning of links and, as we will see later, leads to a problem for GitHub. To understand the reason, we first need to look at how the combination of elements affects the perception of design by the user.
Containers change the value of merged items
When you put a link inside a container, you are assuming a link between the container and the link. Technically speaking, you make one part of the other. As a more familiar example, take a look at the editing links that you often see in web applications: The two editing links are combined by their respective containers. The user expects that the “edit” top link is for editing the “Michael Bluth” record, since the link is in the same cell as Michael’s name. The edit links themselves are the same. The difference is in the containers.
So how does this relate to navigation on GitHub? Link issue (“repositories: all"). GitHub hosts thousands of open repositories, open to anyone and everyone. And at the same time, each user can have their own repositories. And just here we find ambiguity in the design of their navigation.
When the navigation block is framed, the “all” link appears to be enclosed in the framework of the active user. By link, you expect to see all repositories that belong only to this user. Compare this with the frameless version. It is not so obvious here whether the link “all” leads to the list of Michael’s repositories or to the main list of absolutely all repositories.
At first, the frame around the GitHub navigation box looked exclusively as a matter of style. We now see that aesthetic decisions can also affect the understanding of design by the user. In the case of GitHub, the expectations created by framed links do not match the actual behavior. When you click the “all” link, you don’t get on the list of repositories of the current user. Instead, you find yourself in the main list of public repositories for all users. It turns out that in order to see the list of repositories of the active user, you need to click on his name next to the avatar. Wisely!
suggestions
How could we change the design to eliminate confusion?
[..] - the first version of the "redesign" proposed by the author of the article is omitted, as it is frankly bad, especially compared to the following, - approx. trans.
You can save the decorative frame of the original and use “authorship” in order to “outweigh” the obvious logic: This option uses 2 links - “all” (“all”) and “mine” (“mine”) - for sharing between the main list of all repositories and a list of repositories that belong only to the active user.
GitHub is a great service. And I know that I find fault. But at the same time, the design of user interfaces is a delicate matter. As designers, we must be aware that sometimes when we design for the eyes, we can forget about design for the brain. I hope these examples help you better feel the line between decorative elements and elements that change the meaning of your interfaces.