Posts tagged buttons
Amazon Really Knows How To Press My Buttons
Apr 16th
I have to deal a lot with buttons at Amazon. They can sometimes cause quite a bit of irritation at work, so I decided I wanted to try to change it. Here is the proposal I wrote up for Amazon, but sadly I don’t think anyone has read it, and worst I need approval to make a change. Let me know what you think, or if you have seen similar struggles at other companies.
Amazon Buttons
The Problem with Buttons
The button making process is quite tedious at Amazon. Our buttons are image based, so every new button or change to a button needs to be created by our designer. There are many different events during a project that give our designer work of creating buttons. Our designer usually creates buttons at the start of a project, and then might add or change buttons when business requirements change throughout the project. He will also create buttons for the different locales that our project will deploy. Our team has 6 different locales and 2 have multiple languages. And generally he will make additional buttons when strings get mistranslated. For the most recent project of mine our designer has had to make 23 buttons. This causes a lot of extra work for the designer and a lot of unnecessary downtime for the developer as he waits for new buttons. There is also a high chance of error with this process. It’s very easy to forget to upload a new image for a button in our less viewed locales, or forget to update an alt attribute when the button changes. Our buttons are often inputs elements and inputs where the type attribute is equal to “image” don’t function the same across all browsers. IE will not post the name of the input to the server where other browsers do.
The Proposed Solution
I propose we fix this button plague. Instead of having our designers create button after button, they won’t create any. How? By making the button text based. Instead of having the text in the image, it will come from the HTML. The look and feel for it to be a button will be done with CSS and one sprited image for the different types of buttons.
Pros
Eliminates Cross-browser Issues
The inputs can now be of type submit or button (whatever is needed for the page) which will eliminate the cross browser issues when it was of type image.
Localization
Because the text in the HTML is what is shown to the user, we won’t have the potential of our alt attribute being incorrect. We also eliminate the potential of forgetting to upload or change images on the media server. We didn’t eliminate that we might forget to change the string in some random locale, but at least now it’s more visible to spot a mistake like this.
Time (Designer and Developer)
By removing the designer as the button creator we save significant development time. In addition to the designer just not spending time creating buttons, the developer no longer needs to fill out keystones for buttons, or wait for the button’s creation.
Performance
Using text based buttons also has performance gains. Let’s look at the gift card ordering page as an example. There are 11 buttons that are downloaded on page load. Not only do these images add a lot of weight to the page they cannot be download in parallel. For the majority of our user’s browsers; only two images can be downloaded in parallel from the same host (all 11 images are from the same host). With the text based button there are only 2 requests instead of 11; one for the CSS and one for the image sprite. The CSS will get bundled with other CSS on the page so there is actually only 1 additional request instead of 11. In addition the CSS, HTML, and image sprite, needed for a text based button is much smaller than a full button image. As a test I created a page with 11 text based buttons, and compared it to a page with 1 image based button from the gift card order page (the “proceed to checkout” button). The total size of the text based buttons was 20% smaller than that of the imaged based button. My test page was neither full featured nor optimized, but expect similar results when it is.
Test page with 11 texted based buttons
The total size for all components is 2.4K. It has 3 components which are the doc a css file and one css image.
This test page just has one image from the order page
The total size for its components is 3K
Cons
Fonts
Now this method isn’t perfect. The font on the image based buttons is Frutiger Condensed. This is not a standard system font which means we must use other fonts to mimic the look and feel. Although we can get a very close looking font it won’t be perfect. There is the possibility of using @font-face to load the needed font to the browser, but there is a performance cost.
Text Based Button Imaged Based Button
![]()
