Friday, December 29th, 2006
Yes, I’m still working on the music sharing site. I’m finally in Code Land vs. Photoshop, which always comes as a perfectly-timed change of pace.
This tutorial will come in a series of steps, since the player control panel is a combination of a few different controls.
First, let’s focus on the big juicy play buttons.
Download the demo.
Create your HTML code like so: (each “BTN” will eventually be replaced by the play, back, next and pause icons)
<div id="playerControls">
<a href="">BTN</a>
<a href="">BTN</a>
<a href="">BTN</a>
<a href="">BTN</a>
</div>
Next, create your horizontal button strip. This image will contain all 3 states of the button: normal, hover and select. An individual button, in this case, is 31 x 31, so the 3-state button strip will be 31 x 93.
I chose to make the button background transparent to avoid any weirdness once overlayed on the brushed metal background.
Name this image “btnBackground.gif”
Now you’re ready to apply the CSS styles to the anchor tags.
<style type="text/css">
<!--
#playerControls a {
display:block;
float: left;
width:31px;
height: 31px;
margin: 3px 9px 3px 0px;
padding: 0px 0px 0px 0px;
background: url("btnBackground.gif");
}
-->
</style>
Basically, what we’re doing is making each a href link a 31 x 31 container, using the button strip as the background and clipping the image to ONLY show 1 button at a time, depending on the button’s state.
Now your anchor tag should look like a button.
Let’s add the hover property:
<style type="text/css">
<!--
#playerControls a {
display:block;
float: left;
width:31px;
height: 31px;
margin: 3px 9px 3px 0px;
padding: 0px 0px 0px 0px;
background: url("btnBackground.gif");
}
#playerControls a:hover {
background-position: -31px 0;
}
–>
</style>
This will scoot the background image over by 31px to reveal the middle button image when you hover over it.
Nice! Except the buttons are naked! We need to create the icons to drop on top of these button backgrounds.
Again, we want to stick with transparent images so it doesn’t override the button action happening below it. I made the icon overlays the same dimensions as the buttons, to avoid having to fiddle with inner padding and margins.
Once you make your transparent icon overlays, you’re ready to plug them into the href tags, as follows:
<div id="playerControls">
<a href=""><img src="btnBack.gif"></a>
<a href=""><img src="btnPause.gif"></a>
<a href=""><img src="btnPlay.gif"></a>
<a href=""><img src="btnNext.gif"></a>
</div>
Refresh and voila! Fancy hovering CSS buttons - using minimal images, which is always a good thing.
One finishing touch is to add the selected state.
<style type="text/css">
<!--
#playerControls .select {
background-position: -62px 0;
}
–>
</style>
Next… the CSS/javascript slider.
Saturday, June 24th, 2006
As a User Interface Designer for Art & Logic, Inc. I’m always playing with icons, knobs, dials, sliders, led’s… and buttons.
Buttons, buttons, buttons.
I was recently asked to create arrow buttons for a step-through type of navigation. At first, from a CSS standpoint, it seemed like trying to fit a triangle peg in a square hole. But with a little creative maneuvering I was able to work it out. I’m sure there are many ways… but here’s my approach.
Here is an example of the finished menu, complete with hover and active styles:
I set up the menu using CSS list styles, like so:
li.buttons { float: left;}
ul.menu {
list-style-type: none;
font-family:Verdana, Arial, Helvetica, sans-serif;
font-size: 10px;
padding: 5px;
margin: 0px;
}
.menu a {
margin: 0px;
height: 20px;
padding: 0px 0px 0px 0px;
float: left;
display: block;
text-align: center;
text-decoration: none;
color: #000;
background: #ccc;
}
.menu a:hover {
background: #dddddd;
}
The HTML as follows:
<ul class="menu">
<li><a href="#">Thing 1</a></li>
<li><a href="#">Thing 2</a></li>
<li><a href="#">Thing 3</a></li>
</ul>
At first I thought I could simply stick an arrow separator between each button, but had problems with the button edges showing through the negative space of the transparent gif. It wasn’t perfect.
So, instead, I split the arrow separator into two graphics: arrowL and arrowR
I added the images to the left and right of each <a> tag’s button text. This exposed a few image spacing and position problems, so I assigned the stepArrow style.
<li><a href="#">
<img src="arrowR.gif" align="absmiddle" class="stepArrow">
Thing 1
<img src="arrowL.gif" align="absmiddle" class="stepArrow">
</a></li>
I also included align="absmiddle" to vertically align the text/image.
The stepArrow CSS is as follows:
.stepArrow {
position:inherit;
display:inline;
margin-top: 0px;
margin-bottom: 0px;
}
And that’s it! You could probably get creative with the separator shapes and do some fun things with it, but it’s a foundation for how to create seemingly overlapping buttons.
If you found this helpful or have other ideas about how to approach this, please let me know!
Sunday, June 18th, 2006
Fast food.
Express checkout lanes.
PDAs.
What do these things have in common? They all cater to the person on the go. Convenience is an essential need in people’s lives today, and computing is no exception. PDAs allow the freedom of getting your information ‘to go’ — hold the ketchup please. Two and a half million PDAs were shipped in 2002, and as this number increases, the demand for handheld compatible web interfaces grows.
Designing an online application for handheld browsers isn’t just about making a tiny version of an existing interface. There are some fundamental points to consider in regard to organization of content, navigational hierarchy, and optimization of graphics. Challenges that have already been overcome in the desktop world have reared their heads again in the new realm of handheld browsers. We are encouraged to question the existing practices of interface design and explore new ways of presenting content.
The standard screen size of a handheld is 160×160 pixels, minus title and scroll bars, leaving only 150×140 pixels of usable screen real estate. When designing on such a small canvas, every pixel counts. Rather than using large, detailed imagery, we need to rethink the purposefulness of graphics used in a PDA design. Handheld users sync their information on the fly and don’t want to be bogged down waiting for large graphic files to download. So, for example, easy-to-read, high-contrast icons might be more effective than larger, more intricate icons with labels such as home, contact, search, etc.
Designing for handheld browsers requires a minimalist approach, not only aesthetically, but programmatically as well. When building HTML for handheld devices, keep the coding as simple as possible. It’s best to stick to basic HTML: avoid nested tables, frames, image maps, styles and scripts, or at least provide an alternative in case they are not supported. Because there are so many types of PDAs (iPaq, PalmPilot, Cassiopeia and Visor to name a few) it’s best to test your application on as many handheld devices as possible. If you don’t have access to the actual devices, you can download one of the many emulators that are available online.
When designing for limited screen space, it is vital to present your content as efficiently as possible. Decide what information is absolutely essential and organize it in a way that is easy to navigate. Keep page length to a minimum and try to avoid horizontal/vertical scrolling, as the scrollbars not only take up space, but also make the page less user friendly.
If possible, do not present more than one topic per page. It’s best to provide links within the content so the user can drill down for additional details. When developing for handhelds, it’s preferred to have a deeper hierarchy rather than larger pages. Also, keep in mind that you’re developing for a “mobile” device, meaning the users may be unable to focus their full attention on the screen. Present the content as obviously and simply as possible. Be sure to provide easy access to a site map or table of contents so the user can get re-oriented if they get lost.
There’s a bit of artistry in designing graphics for handheld devices. Because there’s no room for large imagery or superfluous graphics, each pixel has to have purpose. Basically, if the image doesn’t have specific meaning or help the user understand the topic, then don’t use it!
Because most PDAs lack the ability to display color, it’s important to use high-contrast images that translate well onto grayscale displays. It’s best practice to check your design in grayscale from time to time during the design phase. Create images in the colors and size for which they’re intended; if a device has to convert and scale the images, quality is reduced, and the results are often unpredictable. It’s best to avoid detailed graphics with smooth curved lines (anti-aliased) because these do not translate well. Straight lines and simple colors are the key ingredients to well-designed mobile device images. Simple icons can save a lot of screen real estate. Rather than using common words such as “search,” “home,” “submit,” “back,” and “next,” using icons to represent these will leave more room for content.
So, you’ve created a simple and elegant design for your PDA web interface… now what? Although handheld web interfaces are written in HTML, it’s important to stick to industry standard tags. As a general rule of thumb, keep your layout as simple as possible. Avoid complex and nested tables, as they not only take time for the browser to render, but also take up valuable screen space sometimes resulting in horizontal/vertical scrolling.
Keep in mind that not all PDA users choose to download images. This means two things: one, don’t rely on images to convey your message, and two, if you do use images, be sure to use informative ALT tags. Tagging an image with a description such as “red thing” is not as effective as stating what that icon represents.
HTML’s original purpose was to present content. Of course, after years of experimentation and pushing the limits of the markup language, desktop web interfaces now contain interwoven tables and pixel perfect placement of elements. Don’t try this on a handheld. It won’t work. At this stage in the PDA world, design is strictly about presenting information in a clear and efficient way. Similarly, not all handheld devices and browsers support CSS and JavaScript. If you want to ‘wow’ your audience with bells and whistles, entice them to visit your full web interface in desktop format, but keep your PDA version simple and utilitarian. Otherwise, you will lose them if your handheld interface doesn’t work because of unsupported tags and attributes.
There are more and more kinds of PDAs on the market each year. This would seemingly make testing a bit difficult unless you have one of each make and model. Fortunately, there are PDA emulators that can be downloaded to your desktop; these look and act just like the real thing. The Palm OS Emulator (POSE) is an especially good one, because PalmPilot has the smallest screen size and is a good gauge of how your content will display on other handhelds. http://www.palmos.com/dev/tools/emulator
Although web development for handheld browsers introduces challenges already overcome in the desktop world, it’s exciting to explore new solutions and creative ways of tackling content publishing. It’s inevitable that future communication devices will become smaller and smaller to fit the fast-paced and convenient lifestyles we lead — it’s up to us, as developers, to keep up.
Written by
Daisey Traynham for
Art & Logic, Inc.
Sunday, June 18th, 2006
One of the primary concerns when designing a user interface for embedded web applications is keeping the file size as small as possible to fit in the prescribed memory constraints. There are two aspects of the user interface to consider when optimizing: the images and the presentation code.
Images for the web are most effective when they load quickly and are high in quality. To ensure image quality, it is best to stick to the 216-color non-dithering palette. This 6×6x6 “cube” contains six hues for each of the RGB colors; red, green, and blue. A web-safe CLUT (Color Lookup Table) is used to corral an image’s colors into the cube’s 216-color palette.
Whenever possible, images should be created using the web-safe palette from the very beginning. However, you can convert an image to the web- safe palette, with varying results. You can also create a custom palette with exact colors to reduce the image size even more. In some cases, this palette can be reused across images by using GIF’s multiple images feature.
There are two compression methods: “lossy” and “lossless.” Lossy compression removes unnecessary and redundant information from the image, resulting in a significantly smaller file size, but altering the image in ways that are barely noticeable to the user. Lossless compression preserves all image information, so that when rendered to the end user it is identical to the uncompressed version. Generally there is a trade-off between compression and quality: Lossy compression results in smaller files; lossless compression produces higher quality. The choice of file format depends mostly on the kind of image; lossy formats like JPEG are intended for photographic images, while lossless formats like GIF and PNG are better for sharp edged, illustrative images.
GIF (Graphics Interchange Format) supports interlacing, transparency, animations, and multiple images. Created by Compuserve in 1987, it is the oldest graphic file format on the web. GIF is best for illustrative images, with large areas of solid color, or detailed pixels. It supports up to 8 bits per pixel, which allows a maximum of 256 colors (2^8=256 colors). Using the LZW compression method, the original image is losslessly saved at a much smaller file size than the original.
The LZW (Lempel-Ziv Welch) algorithm works on rows, scanning for horizontal redundancies. Therefore, an image with horizontal lines will be compressed better than an image with vertical lines.
LZW compression creates a ‘data dictionary’, which represents linear redundancies in the image data. The first time a pattern of uncompressed bits appears, it is added to the dictionary. The next time that pattern appears the information is referred to and represented by what is already stored. For example:
| A | B | B | A | A B | B A | A B |
becomes:
0110232
where:
0 - A 1 - B 2 - A B 3 - B A
LZW is patented by Unisys, and, a license must be obtained to use this compression algorithm. These licensing fees are included in the price of most imaging applications. However, for open-source graphic programs such as Gimp it is difficult to acquire the license to use LZW. To overcome this inconvenience, the lossless PNG format was developed.
The PNG (Portable Network Graphic) format uses the Deflate compression method. This method is similar to LZW, but it scans for vertical redundancies as well as horizontal, which further compresses the file (an additional 10-30%).
The PNG format improves on GIF’s interlacing, transparency, color handling, and multiple images. It also adds alpha and gamma channels.
JPEG (Joint Photographic Experts Group) is a lossy compression format, which creates a map of high and low frequency information within the image. The chosen quality setting at which the file is saved determines how much of the high frequency information is thrown out, therefore compressing the file. JPEG supports 24-bits of color, up to 16.7 million colors (2^24=16,777,216 colors).
Keep your eyes out for the wavelet-compressed JPEG2000 and PNP graphic file formats! Coming soon to a ’save as’ near you!
Granted, images take up a huge chunk of the allotted memory, regardless of how much you compress them. And you wouldn’t want to put your freshly optimized graphics in a page filled with HTML clutter. So let’s touch upon a few ways to optimize the presentation code to speed up the loading of the page as well.
Rather than the image ‘pushing’ its dimensions into the code, let the code allocate space for the image. Not only does it speed up page loading, but it also conforms to the W3C’s XHTML standards. You can do this by stating the height and width of the image in the img tag as follows:
src="image.gif" mce_src="image.gif" height="10" width="10" alt="image"
CSS (Cascading Style Sheets) let us repurpose bits of code. Similar in concept to the compression methods discussed above, we can store data once and then refer to it as needed throughout an application. The color, size, style, and position can be applied to a particular class to prevent cluttering your HTML page with redundant code. Now you can replace a repeated long string of font, table or image attributes with:
class = "myClass"
Not only does CSS clean up the presentation code and improve page loading time, but it also makes the application easier to maintain. You can change the styles by adjusting one line of code, rather than potentially thousands throughout the entire application.
If, upon accessing a page, the first thing the user sees is the main content, then the loading of images and navigational elements isn’t as noticeable. However, HTML is a linear language and reads from top to bottom, similar to the way a browser interprets the code. CSS lets the page appear to load faster by specifying the order in which data is drawn on the screen.
So, for example, if the core content code is at the top of the HTML page, regardless of its actual layout positioning within the page, it will load first. The browser is still interpreting the HTML from top to bottom, but by being able to position where the code presents itself allows you to give the user what they’re looking for right away. The page can be compartmentalized and loaded in whatever order makes most sense to the user.
Another way to minimize the load time is to use HTML aliased text whenever possible, so as to avoid using images for text headers, blurbs, navigation, etc. If you must use text in images, remember that aliased text only requires one color, where as anti-aliased text consists of a gradation of colors between the font and the background. These intermediate colors increase the image file size.
As you can see, there are many ways of compressing elements within the user interface without sacrificing quality. Saving a few hundred bytes here and there may not seem like a big deal, but it adds up in the long run. Optimizing the user interface not only keeps the application within its allocated memory range, but also ensures that your application lives up to end user expectations of speed and quality.
Written by
Daisey Traynham for
Art & Logic, Inc.
Tuesday, December 13th, 2005
From crayons to pixels…
Wow Web Designs - 2001
51%
Wow Web Designs - 2001
The 12-step Commute
Wow Web Designs - 2002
Optimize Your User Interface - The Compression Manifesto
Art & Logic Resources - 2003
Designing Web Interfaces for Handheld Devices
Art & Logic Resources - 2003
Automated Web Photo Galleries
Wow Web Designs - 2001
Daisey Traynham
RSS 2.0 Feed
del.icio.us
Digg it
reddit
Technorati
Simpy