Category Archives: web design

web design

Dealing With A Large, Opinionated And Active User Community

At my current position we are lucky to have a vibrant, active, large, opinionated, and outspoken community.  Perhaps it has to do with having a writing site but most users are logical and literate in their arguments which allows us many insights into the usability of our site, potential flaws / bugs, outstanding issues with new (or even seasoned) features, and, generally, into how a user sees our site.

One of the difficulties with being a programmer or anyone that works “behind the scenes” – developing, testing, or specifying features – is that no matter how hard you try or how good you are at your job you have an entrenched opinion about the site that you work on because you have made it.  It’s impossible to fully look at it with user’s eyes so no matter how much you think about a particular feature you’re always going to miss something that a user will see.  It’s just natural that you assume certain things are logical when in fact the flow, usability, or design of a page might be extremely confusing or present a high hurdle to all, or even a subset of, your users that can render the page from difficult to use to unusable.

This is where an active community is a boon.

By engaging those users – we use a message board (built on the open source SMF software) and a blog (using WordPress) – you are able to gather information, tips, questions, and insight into the finished product in the wild.  Many times it allows us to find where copy or page flow is lacking and provide instruction to users.  We have certain community leaders (which we call stewards) that many times will use the information provided by us throughout the boards to instruct other users – propagating the knowledge for us.  Other times it allows questions to arise that we may not have thought of and allow us to schedule new features or feature updates to correct deficiencies.  Finally, we may have an instance that we did not foresee or couldn’t create in our test environment and only through exposure to users do we see bugs in the site – basically turning our community into testers.

This is an extremely powerful tool that is not always used on large, non-technical sites – where users who are naturally knowledgeable in the technology will speak up of their own accord.

So how do you empower your users and speak out to them in order to have access to this tool?

  1. Provide tools for them to reach out and communicate with you. Besides the normal help e-mail area we have public facing tools that allow users to engage us and the community for answers.  Some of the tools we use are:
    • A wiki for our help section – allowing quick searching of a large, complex living document to quickly provide answers to new users.
    • A blog for community instruction and brand building – also searchable we discuss features in new releases, reasoning behind features, and other items which are not targeted at new users necessarily but require some sort of “stickiness.”  Sometimes a blog post is moved to the wiki to become part of the living help document.
    • A community board for user-user and user-employee engagement – besides help sections where users can question logic or features we also have simply community areas where users can just engage each other, build relationships, and have fun.  This means they are not providing direct value (content) to the site, however, we’ve seen for the most part that it promotes user happiness and, indirectly, that increases productivity on the site.
  2. Have employees engage users directly. We have employees from every division practically communicate with users even though we have a department specifically created to do so.  Development members like myself, vice presidents, and even our CEO have communicated with users via our boards and blog.  This builds rapport and trust with users.  It can be frustrating at times and takes away productivity from assigned tasks but the benefits far outweigh that as our users love and respect that they can ask us questions and gain insight that they can’t from other sites – even if they realize sometimes we can’t answer them fully because of proprietary information protection.
  3. Be as transparent as possible. Let users “behind the scenes” – they love it.  Let them know why a certain feature works a certain way.  Have fun with users.  Make them a part of the team.  This is especially important in a “Web 2.0” or “user generated content” site as they really are part of the team.  Be honest with them when you can’t share proprietary information and why you can’t.  They’ll respect it.
  4. Empower motivated, hard working, driven, intelligent, and / or respected users to take control of parts of the site. One of the programs instituted where I work is our steward program.  Basically it gives users some amount of power of sections of the site.  It might be as small as a leaf channel, larger like a base channel, or in some users cases they have control over our community boards.  Does this open the door for abuse?  Of course.  But communities are self-policing and we’ve had few, if any, abuse issues.  For the most part stewards have gone above and beyond what we’ve asked them to do because they are invested in the success of the site just like we are.  If we fail, they fail.  If we succeed, they succeed.  It’s a powerful motivator.
  5. Really listen to their ideas. I’ve participated in a lot of good debate on our boards about current and future features – what users like, what they want, what they feel they need to succeed.  This is ammunition in your pocket.  When meetings are held about features the ability to say “users on the boards requested this” or “some users on the blog mentioned that this feature could really use this little extra thing” is extremely powerful. They won’t always get what they want but many times what they want is “low hanging fruit” that can be a big win.  There’s nothing like a feature that takes 2 days to build and is lauded about by the community.

Most of these should be common sense however most sites ignore their users – thinking them too ignorant or that they are not proficient enough to know what they really want.  Sometimes it’s true – users don’t always have the “big picture” vision to take your site to the next level.  However, they do have the knowledge of the nuts and bolts of your site in order to polish what you currently have.  Many times, it’s much easier and a better return on investment to improve your existing infrastructure instead of simply plowing forward with new features.  While everyone likes the “shiny new toy” if your base is not solid you won’t succeed.

Anyways, that’s my thoughts, opinions and insight after having been a part of an amazing and active community for over 2 years now.

web design

18-1

So I’ve had a couple of months to digest this one. I didn’t want to post anything until I could step back and look at the issue without confusing my thoughts. The Patriots are my home team and as such there is always a resentment when they lose. As any loyal fan I pass blame – the referees didn’t call the game fairly, we had a freak injury, the other team got away with something they shouldn’t have, etc.

In the end though, the more I think about it the more I come to the same conclusion. The Giants simply outplayed us. They wanted it more. This very thought frightens me.

The Patriots always won because they wanted it more than the other guy. They might have less talent, less speed, lack of star players – it didn’t matter. Somehow they’d pull it through at the end. My fear is that after 3 Super Bowls, after years of success, and after being labeled as the new dynasty by everyone else that they started believing their hype.

We’re used to seeing Brady with the ball, under 2 minutes on the clock, and seeing fear in the other teams eyes. They know he’s going to drive down the field. They know he’s going to pull the come back. They know that their worst nightmare is about to be realized.

The last 2 years we’ve gotten used to a different sight. Brady with the ball, under 2 minutes on the clock, and the other team stopping us.

Maybe it’s just other teams catching up. Maybe it’s parity catching up. I really hope it’s not us losing the core of our team. That hard work, blue collar, underdog philosophy that made us all proud to be Patriots fans. I’m thankful for what the Patriots have given us and for players like Bruschi. I realize we can’t win every year. But to get so close to the perfect season, to the greatest season in football history, to Mercury Morris finally shutting the hell up… and to fall short. I just don’t know.

Sadly, I find myself for the first time in a long time not wanting to watch football. Not caring about the draft. Not caring that we let possibly one of the best cornerbacks in the league go to sign an aging and (playoff) under performing wide receiver. Not looking forward to next season.

I miss that anticipation and love for the sport. I want it back. I fear it’s death on a Sunday in early February when the undefeated became perhaps the greatest disappointment in football history.

I wish I knew where we went wrong.

Random Tidbit:  Being a self-proclaimed – ok maybe publicly proclaimed – geek I found this blog post on why geeks make good lovers to be self-satisfying.  Is it true?  Find out.  Date a geek.

microformats, web design, webstandards

Microformats

I have been reading a lot about microformats recently to try and get a better understanding of them, their benefits and how they affect web standards. I’ve talked a little about them in the past but I wanted to delve more into detail.

The basic idea of microformats is to design a standard XHTML template for common items – for example a hcalendar for events. That template is then the standard for all items of that type. Since all of those items share common elements – in the hcalendar example a h3 with class = summary would be the event description – they are easily able to be encoded into XML and can be aggregated. So sites or programs could aggregate sites using microformats and parse them into easily understandable and standard (hence web standards) displays.

It opens the doors to easily sharing contact information, events, resumes and people relationships with friends, family or even across the web. There are even, already, some microformat plugins for WordPress and noted blogger and CSS expert Eric Meyer uses them for both his tags and his blog watch. I definitely need to track down a rel-tag plug-in to start getting indexed in Technorati – any suggestions?

I realized I’ve only scratched the surface here. With that in mind I’m going to forgo my usual random tidbit and list some links to sites I found filled with microformats information. Before I do, note that already there have been concerns about identity theft with things like hCards and hResumes so there are many bugs to yet be worked out. It’s a powerful tool though with lots of possibility.

For more microformats information check out the following or my microformats tag on del.icio.us:

css, web design, webstandards

Do people still use tables for layout?

1 Comment

I am surprised by how many sites still use tables for layout. This was a practice adopted during the “browser wars” because of the low acceptance of CSS – for complex designs the only method available was to use tables. This is no longer the case. Now with web standards and CSS sites can be designed as they were intended – using markup for the purposes the creators meant for them: h tags for headers, p tags for paragraphs, div/spans for non-semantic elements and, finally, tables solely for tabular data (think spreadsheets like excel). Then you use the CSS for design and layout of the site.

Getting off my “web standards” soapbox for a moment the main reasons you want to avoid using tables for layout is that they bloat your markup. This makes it difficult to change and update your site and it hurts your ratings in search engines. By using the correct tags you naturally tell search engine spiders what your content is – a keyword rich header, a content rich paragraph or a navigation list. This allows them to better match your site to keyword searches and increase your audience. You also don’t have to change multiple pages of markup when you want to redesign your site – you simply edit your CSS and never touch the markup.

There are some instances where you want to, and should, use a table.  When designing the table you still want to keep standards in mind. In the old days you would use inline tags like “align” or “valign” for td’s and “cellpadding” or “cellspacing” for the table itself. Now all of that can be done through the CSS. Simply place a class on the table – or use the containing element of the table and apply the rules that way.

For example if you have a table inside a div with class “mySite” you could vertically align the td’s simply by using the following rule:

.mySite table td { vertical-align: top }

If you had used valign = “top” on all of those elements and then later on you decided you wanted to change them to centered you would have to go back and either do it by hand or via a find and replace. Using CSS and web standards you could simply change that one rule and affect all of the elements. That is the true power of it.

In conclusion, the most important thing to remember is to only use tables for the purpose they were created for – tabular data. When using them for this also remember to use the least markup possible. No presentational elements should be present – only semantic elements like content and semantic images (one that add value like logos or photos rather than are used for display like rounded corner containers). Also, if you find yourself placing tables within tables reevaluate your markup – you’re probably using this to create layout or presentation and could get away with a single table and CSS to style it.

Random Tidbit: Having trouble selling web standards to your boss?  The Web Standards Project can help.  Plus they have probably the best example of a site using web standards in every facet – which makes sense.

accessibility, templates, web design

The age old question – fixed vs fluid (vs. elastic)

Fixed vs. flexible design is one of the main arguments of the modern web design era. Much of the argument derives from the fact that IE (Internet Explorer) did not support the min- and max-width properties until version 7. As of this date version 6 and lower are still in such high usage that you cannot count on these properties to work. So the question “fixed vs. flexible” is asked at many a new design meeting.

Fixed

What is fixed design? Fixed design is essentially defining a width on a page – no matter the size of the browser window. You can find fixed designs at sites like Helium, CNN and Yahoo. A typical fixed layout has containers, text, images and most other elements defined in pixels.

The main benefit to designers in using fixed layouts is that they have total control over the design. Unlike traditional media outlets – like newspapers and magazines – the web can be viewed through a large variety of devices from cell phones to PDAs to computer screens to widescreen HDTVs. With traditional media you always know how your page is going to appear. With the web, the same page viewed on a cellphone and a computer can appear vastly different – or even 2 computers with different screen resolutions. Fixed layouts give a designer more control over how their content is viewed. Finally, because you are defining the layout of the page you have more freedom with background images – if you notice the examples above all but CNN make extensive use of background images for design.

There are 2 main faults of fixed designs. One is that users with large screens and resolutions viewing sites with small widths have lots of wasted space. This is a bad user experience because you are dictating to the user how they should experience your site. The second is that if a user is using a smaller screen or resolution some of your design might flow outside the window – causing the dreaded horizontal scrollbar. This also creates a bad user experience.

Fluid

What is fluid design? Fluid design essentially allows the user to decide the how the page looks based upon the size of their browser window and display settings – the page “flows” (hence fluid) to fill the entire available space. Fluid designs can be found at sites like Google, Wikipedia and Reddit. A typical fluid layout has containers, text, images and most other elements defined in ems or percentages.

The main benefit to designs using fluid layouts is that they can use all of the space available to them. The philosophy is that you can’t predict the user’s setup so you want to make your design as adaptive as possible in order to increase the user experience. A fluid layout puts the control of the design in the user’s hands.

There are 2 main faults with fluid design. One is that if someone has a very large/small screen or resolution your site can appear “wonky” – extremely long/short lines of text and distorted containers. The second is that fluid design makes it extremely hard to use background images because of container distortion. They require vast amounts of testing in order to function properly – if at all. In the examples above none of the sites use background images extensively – which severely limits your design creativity.

Hybrid/Elastic

A new design not mentioned in the title goes by several names and is basically a hybrid of the two. It uses min and max width (using javascript for IE6) to try and get the best of both worlds. Basically it defines a range of values in which the design can flow – so that you still have some control over the design (like fixed) but users with larger screens/resolutions can expand the width somewhat. 456 Berea St and Digg use something along these lines.

The main benefit of hybrid/elastic is that it gets some of the benefits of both fixed and fluid – users and designers split control over the design. It’s main fault is that like any hybrid it doesn’t do either of those things as well as the original.

So which is better?

If you haven’t figured it out by now, there is no right or wrong answer. The correct choice depends on the purpose of your site and your design preferences. The sad fact is that any choice you make is going to alienate some user. The old saying is that “You can please some of the people all of the time and all of the people some of the time, but you can’t please all of the people all of the time.”

Typically if you have a site with shorter blocks of text and/or you are more Web 2.0 you lean towards a fluid design – utilizing large font sizes to lower the impact of some of it’s faults. If you have a site with long blocks of text – like a news or article/blog based site – then you lean towards a fixed width design.

Random Tidbit: Speaking of design what about Time.com’s 50 coolest websites?