pixels and digital bits

Saturday, June 24th, 2006

Tutorial - CSS Overlapping Arrow Buttons

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:

The HTML as follows:

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!

Friday, June 23rd, 2006

Animator vs. Animation

Animator vs. Animation if you work with Flash, you’ll love this! The animation comes to life and DESTROYS the screen using tools from the toolbar!

Tuesday, June 20th, 2006

about da*sey

Daisey Traynham is the buzz behind Firefly Multimedia, Inc. The wind beneath the firefly’s wings. She makes pixels glow…

She’s a veteran web designer and user interface developer who has done work for Motorola, Sharp, JBL, Roland, Oakley, Time Magazine…

Daisey telecommutes around the world from her cozy studio in Berlin, Germany.
Her main gig, with Art & Logic, keeps her on her toes with web standards, usability and compatibility. Her experience as a programmer helps steer the technical direction, while the artistic side keeps creativity and originality in the limelight.

Daisey is also a singer in the dynamic duo, Heavenly Noise and the up and coming Smile Rays. Along with her musical contributions, she is also responsible for websites, cd packaging and marketing/promotion materials.
My studio is your studio…
Design for your eyes and ears.

Monday, June 19th, 2006

reFresh Jacksonville

ReFresh Jacksonville is having their next meeting on June 29, 7:00 - 9:00pm, 1903 Hendricks Ave.

Sunday, June 18th, 2006

from crayons to pixels…

I consider myself lucky to have known since childhood what I wanted to be when I grew up. Granted, they didn’t have web designers back then… but I knew whatever it was, it was going to be colorful and visual and creative.Music and computers were omnipresent throughout my childhood. My parents were in a band, so since I can remember, there were always keyboards and speaker parts and cables and computer chips and guitars and dismantled rhythm units laying around - somewhat like a retirement home for anything musical and digital.

Being in the band led us to travel around the country in a motor home until I was 14. Because we were never in one place for more than a couple of weeks, my mother home-schooled me. If we were studying science, we’d go outside (in whatever town we were in) and find bugs and leaves and flowers. We would make big colorful poster-board charts mapping out the different types of clouds or even the strategically placed lines of the Periodic Table. History lessons always consisted of a trip to the local museum. We would check off states in our Atlas as we traveled through them studying their state flags, indigenous animals, landmarks, cities and cultures. She taught me everything in the most fascinating way. I had a hunger to learn because it was fun and it felt good.

Since she relied on imagination to make creative visuals for the subjects she taught me, one of the things that seemed to blanket over everything else… was arts & crafts.

I realized early that this was something I thoroughly enjoyed. It came natural. My mother nurtured this spark from day one and lavished me with art supplies. I’ve owned only a few dolls in my childhood… but I’ve had countless easels, marker sets, smocks, crayons, paints, pads of paper, etc. It was wonderful!

March 1st, 1982 — MTV had it’s “I want my MTV” video campaign. I was glued to the television not believing my eyes! THAT was it! At that point, I decided I was going to do whatever it took to go work for MTV.

I have yet to work for MTV, but only because my goals changed and I never truly pursued it specifically. As I bounced around in the graphic industry I would continuously find another facet that I hadn’t explored yet. Slowly but surely, I’m scratching them all off my to-do list. Who knows… one day music video production might just find its way back on my list. I hope so.

Years later, when I was 14, the “band” broke up.

Suddenly I found myself in a real school with real kids! With huge chalkboards and a library and an entire art department! I was so excited about bouncing ideas around with other kids… and having classes and a locker to call my own.

However, I’ll always wish I could have graduated from Mom’s University.

After high school, I had a barrage of jobs in various sign shops. I realize now that it was at that point when the technical and the creative split. There was the CAD software and the green pixilated monitor on one side of the shop, and the colorful vinyls and plastics, exacto blades and paints on the other side. Oddly enough, later in my life, the split between technical and creative actually caused me some heartache. We’ll get to that in another article because there’s a lot to be said about the “great divide”.

Years later, I was being more and more drawn to computer graphics. In the early 90’s I got my first computer and started laying out logos, brochures, and the obligatory posters, flyers and business cards for every person I knew. I found myself pulling in enough work to survive, so that’s what I did for about a year.

Back to school. I signed up for whatever art and computer classes were available at the community college hoping to be “taken to the next level.” On the first day of my pre-requisite computer class, I found myself sitting there in disgruntled disbelief. I was being told that my mouse was a mouse and my monitor was a monitor and this little square thing, this is called a floppy disk. Class… can we say floppy disk?

You’re kidding, right?

Unfortunately, he wasn’t kidding.

So I quit school and got a job as editorial designer/illustrator for a local alternative magazine. One of the sections I laid out and pasted up weekly was the classifieds. I saw more and more ads related to computer programming and web design. By this point, I had done a couple of HTML sites for people and even had one of my own (everything centered with blue lines around all of my linked images) so I wanted to know more. The book store became my best friend. For me, a hot date on a Friday night meant my boyfriend and I geeking out in the computer section of Barnes ‘n’ Nobles. It was true love.

In fact, my first official web design job was working with Matt. We learned together, pushing each other to learn more. We were both contractors for a computer consulting agency; sometimes working on projects together, sometimes not. This was a great way to get experience because each separate project was a little universe onto itself. Coming out of a completed project meant you were updating your resume with all of the new technologies you’ve mastered along the way.

Being a people person, I was eventually drawn to positions where I could lead and direct web design studios. I wanted to take what my mom taught me and apply it to my job. Beyond imaginative brainstorming, organizing and keeping schedules on track, I was also the liaison between, what seemed like, extreme opposites. On one hand, was my fun and creative team in the back room with the black lights and music blaring. On the other hand, were the suit and tie corporate officers who just wanted it all done on schedule and under budget. I was the mediator.

Creative people are a strange breed. Sometimes inspiration for a great idea will come flying out of nowhere. Maybe the syrup on your pancakes this morning made a shape that would make a great navigation system. Or while sitting around flipping through magazines you might see a shape or a color that completely changes your mood. Or sometimes, the answers will come to you in your dreams.

Sometimes, I would take the whole team to lunch or to my art studio and line the tables with paper and crayons and markers and say “okay, draw what this project tastes like to you, close your eyes and just taste it.” In the beginning, while holding back their instinctive chuckles, my team thought I had a few screws loose; but they soon came to understand I was trying to open their minds, encouraging them to color outside the lines and to be free. A couple of invigorating and extremely productive days later, we would come back to the office with dozens of designs taped to the wall for the CEO to choose from.

It never failed; they would always choose at least one solid layout.

Viva la dot-com craze! It was fun while it lasted, that’s for sure! The long hours, the promises, buzzing around high on life (and carafes of coffee) with visions of stock options and early retirement, fame and fortune. I’ve built up several amazing companies, only to see them fold before my very eyes. It was heart-breaking, but it was worth the experience and I wouldn’t trade it for anything in the world.

A year ago, I found a wonderful gig telecommuting for an international software engineering company that’s been around for over 10 years. I was looking for freedom and stability; and I found it. I have a “virtual” office that I log into every day and I have about 50 co-workers that I’ve never met face to face. From one extreme to the other: office hours to no hours, neon lights to candle light… from crayons to pixels.

I have many experiences that I would love to share. Stories that might make your next project a little easier, or ideas that might help you present your designs in a way that the calculator toting business men will understand… and agree with. I hope to share my experiences in hopes of not only documenting them, but also to share a piece of myself with others in the web design community.

We’re all in this together.

We’re all here to learn from one another.

We’re all web designers because it’s what we love to do.

Sunday, June 18th, 2006

Designing Web Interfaces for Handheld Devices

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.

Sunday, June 18th, 2006

Optimize Your User Interface — The Compression Manifesto

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.