You are currently browsing the category archive for the ‘Design’ category.

I like documenting the previous work that I’ve done, so I’m posting some of the pages from that I worked on. Much credit needs to go to Colin Felton, Karen Chu, and Maria Waters, the designers at PlayFirst, for the exceptionally attractive designs they came up with. Sadly, pictures don’t do justice to the full experience since much of a UI is how it reacts as you using it, but I don’t feeling like doing a video, and the site is already changing, so I’m a little late.

Front Page of PlayFirst (Dec 2009)
The global nav, which includes the left sidebar, was all coded up by myself. Not shown is that there could be a popup when hitting this page that would display a marketing video to users who hadn’t seen it. Big game launches would use this feature, but since it was slightly intrusive (as popups are), we only used it for promoting the best quality games.
Front Page of PlayFirst (Dec 2009)

All Games Page
The All Games page listed, of course, all the games for sale. There was a feature to include an image with a link at the top of the page for promotions. This could be a rotating set of images that would change each time you hit the page. Next to the front page, this was the second most hit page, and that kind of exposure could drive traffic for important new releases.
All Games Page (no hover)

The fun feature I built on this page was a pop over for the game images. It would seamlessly display more information over top of an image that you hovered over. This could include game description, pricing, buy/download buttons. These would open as you hovered over an image, and go away as you hovered away. As you might notice between this and the above image, the popup image was perfectly aligned with the main page image giving it neat effect when it faded and out.
All Games Page (with image hover)

There were a number of things to consider while doing this feature. First, you only want one loading and opeing at at time, and you don’t want one opening if you scroll and hover over while scrolling. Popup placement was a changing target too if you scrolled any as the popover still needs to render perfectly over top of the image even if it moved a little. On performance, when you’re tracking hundreds of potential target images to activate the effect, that’s an event that can drag on performance if done without consideration (one key to the solution being event delegation). For this page, I had to make performance adjustments as there were over 700 game images on the page, and even though the popup was an AJAX created popup (created on hover), the hover over and off effects needed to immediately load and reloading each time perfect on top of the image even after scrolling some.

Another feature that you can’t see on this page without using it is partial image loading. The 700+ games are in a table that is filtered with javascript as you select categories on the left sidebar, or type in a title in the title filter at the top. The page needed to re-render the images instantaneously, but also only load the minimum number of images for the viewport. As you’re seeing only 12 or so of the 700+ possible images at any one time, I’d only load those plus a few extra for when you scrolled. And then, as you scrolled, new images would populate themselves just outside of the viewport, so you’d always see something, but the page wouldn’t get slowed by trying to render so many images, including when you filtered them by category, title, or some other criteria. (Obviously, people with javascript wouldn’t see these features, but the page would still work).

Detail Page
The game detail page was completely redesign and I did all of the implementation work for this very important page. There’s a slideshow of game images, and possibly a link to a game trailer. The buttons, try it, buy it, buy with PlayPass, would change depending on the game’s status (pre-release, in beta, live, etc.), and the user’s membership status with the site. The tab selection would change as not all games would have all the tabs. I made the tabs with AJAX enabled content loading. For SEO purposes, there were uniques pages with URL for each tab view, but if you had javascript on, then the content would fade in place of the content for the previous tab.
Game Detail Page

Another view of the detail page. This time with a non-PlayFirst game.
Game Detail Page (non-PlayFirst game)

Not all of the pages that I touched, or features I worked on, but these were the key ones that I had a lot of impact on. Overall, I helped reduce page load times by up to 45%. Average load time for the site dropped from ~6 seconds to ~4 seconds. The main reason for this was optimization of the thousands of images used on the site. Use of sprites for buttons and other elements helped smooth over interactions and such. Lots of fun, but I’ve moved on.


I really like my job, but there’s one aspect that’s starting to getting me worked up. I’m the UI guy at work. I didn’t start that way, though. I moved into the position because I’ve grown tired of super heavy technical work (the honeymoon is over), and I’m moving myself to tasks that I enjoy more as well as find engaging while learning to improve myself. If I wasn’t doing this at work, I’d still be reading up and learning about it anyway.

The problem is that no one really sees me that way (or the key people have yet to fully acknowledge it), and I keep hearing about how the guys before me, who still work for the company, should have a look at what I’ve designed and critique it. No, even worse, design a piece within what’s already been started, without any knowledge of what’s been done, why it’s been done, where it’s all going, or what the application as a whole really does even from a business perspective (let alone a design perspective). AND! they aren’t actual designers on top of it.

This is definitely an angst post that’s built up a little over time. I still need to work on how others perceive me, and I have to change how that is from how it was. Never an easy task, but in the meantime, I get the group think problem.

The art critique is rarely an event that’s enjoyed by those being critiqued, especially in college sessions where the art professor doesn’t go easy on freshmen. However, at work, it becomes the group think that we all know and hate. Committees that turn out crap.

The meetings my company have are generally above average. We make good progress, and solve problems that take more than one person’s limited base of knowledge. On average, we’re not performing group think, and we do a good job at this outside of design. Design, however, never really had a champion. Someone to lead the way. I’ve finally picked up the reins, and I’m not about to let group think ruin the small progress I’m making at turning our decade old, flagship application, into a modern, slick-yet-comfortable tool.

Design is one of those areas you just can’t have a teams of people contributing. You have to have an executioner, a king, a monarch who calls the shots. You still have to remain open to ideas, and accept the critique for what it’s worth. I find more often, when dealing with non-designers, you really have to work at digging deeper to understand the underlying problem they’re incorrectly trying to solve through design terms.

People want to speak your language, and because art and design are so accessible to all, everyone thinks they’ve got a clue. But they don’t. They don’t know how to convey meaning through contrast and texture, typography and spacing. I certainly don’t think I’m perfect, but I’ve set a path, and I’m not about to let others change that path.

So, I’ll endure the near useless “design critique.” I know it will be useless, but the boss will still think the others A) have any time to actually do work on this product, and B) have any clue what they’re doing. They won’t speak up about what I’ve done with anything of value because they lack both basic design knowledge, specific business knowledge, and they lack the time to process anything from an outside point of view to say anything of meaning.

Yes, they know how to write HTML and CSS, and not enough of Java to be a real coder, but that doesn’t make a designer. So, I’ll cut the heads of any ideas that aren’t appropriate, and define myself in the new role I’m playing. They don’t realize they’re invading my territory, so I’ll be nice, but as time passes, I can’t let their group think hold me back from taking part in the art critique that should really happen. Since this is currently in house dev work (clients on the horizon the in next few months), my coworkers are my clients, so I must treat them similarly. But, as I don’t let clients bowl me over, I can’t give coworkers the easy out for being familiar to me. They’ll be happier in the end that I didn’t sacrifice the application for ideas they half thought through and half considered a valid idea.

I’ll be posting “Judicium Dei – Trial by Coding (Part 3)” – the finale, soon enough, but here’s something else in between then and now.

Composition drives meaning and intention. Features by themselves lack meaning and intention. Selling software that lacks good composition is like sending a monkey with a bikini into a swimsuit contest, funny as it may look and including all the key “features”, it won’t win. While sales people love features (as they can be tangible points on a checklist), lots of nice features don’t make good software when they could code another feature instead.

A developer at work was showing me some neat CSS featurettes online. He was exclaiming how cool each was, and how nice they looked, and how we could throw something similar into our software. I definitely agree that many were cool, and some looked nice, but they definitely don’t deserve to be in our software just because they look neat on someone else’s website. Unless you’ve only got one pony pulling the carriage, you can’t drive development by any single or even group of features as they still all need to go in the same direction.

Unless you can put all of those features together, fluidly, coherently, and intuitively, you’re doing a disservice to those who use your software. Having software that’s been well composed means having someone who’s taken time tying together the bigger picture while also fine tuning the little details. You must be the curator for the art gallery, the editor for the writer, the PR manager for the monkey with a bikini. Software communicates in many small, almost silent, ways, and while no specific tweak will make or break a piece of software, a tide of small perfections that all have the right direction, through meaning and intention, will communicate tons of information, and that’s well worth a decent amount of time and effort.

For example, the main project I’m working on has two key users, managers and administrators. 95% of the users are company managers who have a relatively simple process in front of them. The administrators, however, are our only interface, they’re paying for the product, and they’re the ones giving us feedback as we customize the system for their processes. The admins understand the manager’s processes, and they’re basically super managers (no capes included). So, we have to build a system that’s on the surface simple and fast for the majority of users while being powerful and detailed for administrators. In essence, these are two different messages being communicated to two different users under one roof.

Both processes are data heavy, but the administrators require much more data that interacts in much more complex ways. The managers get a simplified version of this while still being data heavy itself. The first order of composition is providing a single point of interaction for the managers to do the bulk of their work. Now, there are some peripheral functions and pieces of data that support their process, and those need to be quickly accessible for them. However, if you just put those pieces on the page, then you’re distracting from the main function by eating up screen space and cluttering up the visual composition with more objects. Yet, if you hide these on separate pages, then you’re slowing down a simple process, and forcing users to do extra mental paging in order to flip between the key pieces of information.

My solution is a page with “drawers.” The middle section of the page contains the content where the work will get done. The top and bottom contain the extra features and information that will be used, but less often. When the user’s mouse is over the main section, the other sections hide themselves like closing drawers, but with handles showing that you can hover over to open them up. When you hover away from a drawer, they close again, or you can click to keep them open if you’re at a point in the process that you need them always accessible. At this point, the bulk of the users have what they need right in front of them without any extra clutter, but they also have a few other key pieces within arms reach.

That’s part of the high level composition, which should make use of the 6 tools of designs: size, position, color, shape, texture, and orientation to fully convey the appropriate meanings and intentions. Yet, there’s still plenty of fine tuning required. The drawers for instance are activated by hovering the mouse. CSS handles this easily and in a standards compliant way, but it feels too harsh. The very instant you hovered over a drawer, it popped open. But, if you’re just moving the mouse around describing something on page to another person, then you’ll very likely hover over a drawer meaning to open it. So, I added a delay on the hover using javascript, and if it was just a quick mouse over, then the drawer wouldn’t pop op on you. It takes a small amount of work to perfect, but that’s time lots of people would consider a waste when they could code another feature instead.

Putting that one fine tuned aspect along side many others (highlighting user changes on the page, providing good contrast, giving proper emphasis from important to less important sections, etc.), you can get a smooth, friendly, and yet powerful application, but all that little detail work can add up to a decent amount of development time. If you don’t, then you’re left with lots of rough edges that detract from use, and inhibit the basic functions of the user. Additionally, add in the second layer of administrator functions where everything needs integrate smoothly without hindering the existing managers functions, and you’ve got a complex problem to solve. Without proper consideration for all the moving parts along with good attention to detail, you’ll end up with a monkey in a bikini when you want a beautiful babe with a sexy bod.