I recently wrote about a hectic project I assisted in (Make a (visible) difference). That project had some major UI design and development problems. chances so happened that just now, I was called to another project with UI problems.
The interesting thing, or funny, thing about that project is that it had the same characteristics as the first one. Quite similar mistakes, the same problems and same errors.
Working on that one, the past week or so, lead me to this post. A list of "Do" and "Don't Do". I think I will find some "Under no circumstances - Don't do!".
This list isn't complete and doesn't pretend to be so. I might add stuff later if I'll remember them, and I will be happy to hear yours.
So let's get started.
Things to do
Use a CSS file.
I know this one sounds the most trivial one, but yet, you'd be surprised how many people and projects don't do that. The advantage of a CSS file, is huge. CSS files can be monitored for changes, can be documented easily inline, and separated then your source code.
Further more, a designer can do that, working on top of stub HTML file, and free your developer to do something else (and I don't mean coffee).
Use CSS inheritance.
CSS 2 (and older versions too), offer a very nice inheritance between class (CSS classes, that is). It isn't C# of course, but still, it better then writing the same lines of code over and over again.
Write default CSS classes with over-ride classes which over-ride only the needed elements.
Suppose you have a few tables, all the characteristics of all the cells are the same, besides the background. Use one class that will hold everything which is the same, and then just a few which will over-ride the one parameter which is different.
Example:
<style type="text/css">
.FormTable
{
width: 100%;
height: 100%;
margin: auto;
color: Gray;
}
.FormTableHeader
{
background-color: Black;
color: White;
}
.FormTableBody
{
background-color: Silver;
}
</style>
And here's the HTML to go with that:
<table class="FormTable">
<tr>
<td class="FormTableHeader">Title 1</td>
<td class="FormTableHeader">Title 2</td>
</tr>
<tr>
<td class="FormTableBody">Value 1</td>
<td class="FormTableBody">Value 2</td>
</tr>
</table>
Use HTML entities to differentiate styles
In the above code sample you can see that I'm differentiating between the table's header to it's "data" (or body). If I would use HTML entities (as I should, by the way) I could have saved the extra "Class" directives, and just set the style to the table. This will produce a shorter code, ad easier to read.
Another plus is that your page will now be more accessible.
Example:
<style type="text/css">
.FormTable
{
width: 100%;
height: 100%;
margin: auto;
color: Gray;
}
.FormTable th
{
background-color: Black;
color: White;
}
.FormTable td
{
background-color: Silver;
}
</style>
<!-- ... -->
<table class="FormTable">
<tr>
<th>Title 1</th>
<th>Title 2</th>
</tr>
<tr>
<td>Value 1</td>
<td>Value 2</td>
</tr>
</table>
Document your CSS file
As with any code file, there's almost no such thing as "too much documentation". Use comments to separate different segments of the file. Describe shortly where in the site (or page) this class (or classes) goes. and so on and so fourth.
Use different files for different media types.
One of the things I see many times is page that uses the "onBeforePrint" event, to hide data that shouldn't be printed and/or to display data that should.
Why do you do that? (rhetorical)
Cascading Style Sheets can be defined for different media types using the "media" attribute in the declaration. It's there. It's working. Use it(!).
Define the same class in two different CSS files. One file will be used for the screen, and the other for print. In the print version, set the "display" attribute to "none" for those elements you don't want to display, and to empty string for those you do (and of course, vise versa).
Example: I have a div that contains page numbers.
My "Print CSS File" have this:
.PageNumbers
{
font-family: Courier;
font-size:small;
}
While my "Screen CSS File" have that:
.PageNumbers
{
display: none;
font-family: Courier;
font-size:small;
}
And on the page, the declaration looks like that:
<link href="Print.css" rel="stylesheet" type="text/css" media="print" />
<link href="Screen.css" rel="stylesheet" type="text/css" media="screen" />
Be consistent
If you decide that your style are in an external file, keep the same method thru out the project. If you decide to use inline "Style" element (inside the HTML file), use the same structure on all pages. Make sure that there're no surprises, no style that went externally some how, etc. If you use inline style directives, use just them.
Things you shouldn't do
Don't repeat directives in different class
If you're using the same fonts in all of your pages, and the only thing changes is the size or color, why do you repeat it in each and every class? Just assign it in the "body" directive so it'll become the default.
Don't assign a classes with the same name to different HTML elements
In the project which triggered this post, I saw this code:
a.Link
{
font-size: larger;
text-decoration: underline;
color: black;
}
span.Link
{
font-size: small;
color: navy;
}
The problem with that, is that one can easily think that "Link" is a general class that can be applied to anything. How ever, applying it to a "div" wouldn't produce nothing.
See the item "Use HTML entities to differentiate styles" for the correct way to achieve the above.
Don't separate the CSS file to different files just to keep it short
Very very bad move to do that. It wouldn't take too long before you'd forget which file occupies which class, and where did you put it. Not long after that you'll start to write duplicate classes, and if you would be lucky you wouldn't give it the same name.
I often see something like that in the code:
<link href="StyleSheet1.css" rel="stylesheet" type="text/css" />
<link href="StyleSheet2.css" rel="stylesheet" type="text/css" />
There's no real reason to separate them. When you HAVE to do it (i.e. when you're using some external style sheet that is only used for a special control you've downloaded), give the files a logical and understandable names.
Furthermore, make sure you're not repeating class names (one way, is to prefix all the classes, in the external file, with something descriptive).
Don't use different CSS files to the same site when it uses two applications, or folders.
Another common issue. You have a huge project, you've divided it to separate applications on your server, all of them uses the same colors and styles, but you have a style sheet on each and every application.
And now comes the day when you client wishes to apply his new branding colors. Oops... Now you need to change 4-5 files.
The solution is easy: Create an application that will hold just the CSS files (and the images too, why not?). In the "link" directive just use an absolute path, instead of relative.
Works like a charm, trust me.
Another advantage you might earn, is the ability to push this application to a less secure zone, and apply caching on that one alone. You wouldn't believe the performances change you'd earn.
Don't change styles from code behind (ASP.NET)
Unless you really really need it, don't change the style from the code behind. Change CSS classes, but not styles.
I saw this line in a code behind:
lblTitle.Style.ForeColor = "#ebebeb";
Now, what's the problem here? It isn't consistent. A developer might look for all the places a certain class appear, and not for the specific color; especially if the re-work is being done after quite a while when there's no style guide to look at.
Don't over-ride the same class over and over
If you use inline styles to over-ride something in your class (i.e. fore color for unique cells), make sure you're doing it only once. Or twice, the most. If you see that you need to over-ride the same thing over and over, just write a new class for it.
Don't use StringBuilder to build HTML content (ASP.NET)
Why not use all the nice elements from the "System.Web.UI.HtmlControls"? Can't find what you're looking for? Use "GenericHTMLContol". Here's an example of how to build a small table:
HtmlTable table = new HtmlTable();
HtmlTableRow tr1 = new HtmlTableRow();
HtmlTableCell th1 = new HtmlTableCell("th");
th1.InnerText = "Header 1";
HtmlTableCell th2 = new HtmlTableCell("th");
th2.InnerText = "Header 2";
tr1.Controls.Add(th1);
tr1.Controls.Add(th2);
HtmlTableRow tr2 = new HtmlTableRow();
HtmlTableCell td1 = new HtmlTableCell();
td1.InnerText = "Value 1";
HtmlTableCell td2 = new HtmlTableCell();
td2.InnerText = "Value 2";
tr2.Controls.Add(td1);
tr2.Controls.Add(td2);
table.Controls.Add(tr1);
table.Controls.Add(tr2);
Things you should never (ever! under no circumstances) do
Do not produce styled HTML from the code behind and just write it to the page.
One of the elements on the page, refused to let go of some horrible red color it had in the background. The developers looked at the markup, and then on the style sheet, and couldn't find the place it getting its color from.
A deeper look, found a few lines that looked like that:
StringBuilder sb = new StringBuilder();
//...
sb.Append("<tr><td bgcolor=\"#ee001c\">" + pageTitle + "</td></tr>");
Since the developer didn't knew the color name, he couldn't find it. At least not easily.
Look also above, at: "Don't use StringBuilder to build HTML content (ASP.NET)".
Do not use JavaScript to control ASP.NET controls' styles (or functionality, for that matter).
For me, I think this is the biggest "never ever" rule. In the last project I found a huge JavaScript file that was in charge of some grid's functionalities, such as highlighting the background, expanding details, and even sorting.
The amount of code on that file, just to find a link inside one of the cells was unbelievable. There's no reason, not one, to do that.
Using such method decreases the chances of maintaining the site, to tiny shred.
Some time ago one of my collogues stepped into my office and asked for assistance.
The project he's working in, is a maintenance project for some commercial site that is already on-line.
The client wishes to lunch a huge campaign, and for that occasion he'd like the site to be redesigned.
Of course he want it done for yesterday, and if possible even the day before.
The problems are many: the code is massy, there's no common sense in the CSS file, there are weird combinations of inline style as well as CSS classes; Furthermore, some of the styles are hard coded in the code behind, some in JavaScript, and so on...
I was called as a "last minute help" before all hell break loose and the client goes ballistic.
The first thing I did was to redesign the first page. I've stripped it off it's styles and wrote them back using methodological CSS classes and inline override styles.
I didn't do much. Just rebuild the class, added the correct colors in the correct places, and aligned everything the way it should be. Less then a couple of hours, and I was done, with a couple of coffee breaks in the middle (I like coffee, I must say).
the impact, how ever, was huge. The client calmed down. A couple of smiles appeared on my collogue's face, and the system went to a more productive state of mind.
So, what's the point?
There are several results, or goals, you want to achieve when you modify the UI. It might be a new design, new branding, accessibility, and so on and so forth.
No matter the reason, it is always a tedious task. You always have to deal with the conflict of "What to change first?", and "Should I change the UI, or should I re-write from scratch?".
When you have no choice but to change the existing code, start with some fast and noticeable tasks. It'll give you a good idea on what else should be changed, and if the current path makes any sense.
Use tools to identify HTML elements and style (such as IE Developer Toolbar, which I plan to write about later).
Use "search-and-replace" mechanisms to replace (or remove completely) obsolete or bad style and classes definitions.
Don't be afraid (that's a good advice to any field). Remove styles, remove classes. There are millions of tools to preserve versions of your code, you can always go back. Remove a class to see if the element still inherit some CSS definitions from somewhere else.
Make a visible difference to the UI, so you'd know you're on the right path, so you will actually see a progress.
So your users or clients will see that you're making a change, you're going some where. I promise you, they will come back to see it finished.
Or - a personal history of how I became an accessibility consultant (or preacher for some).
Hello everyone, since this is my first post, I'll start by a short introduction of my self:
My name is Joe, I'm a system architect and a technological consultant.
I used to deal a lot wit banking application, architecture and security. May be "used" is the wrong term, because I still do that.
However, a year (or so) ago, I've started researching about accessibility on web site and how to do that.
Back then I was consulting one of the major banks in Israel, and one of the regulation's requirements was to have an accessible web site.
There where two incidents (or events) which gave me the drive:
First, I had a phone call from one of the bank's clients (lets call him M'), a blind man, who described me his user experience on our site.
Second, I've started teaching my mom how to use her computer.
You learn a lot from looking a a person. In M's case, I didn't really look, but the effect is quite similar.
I don't know about you, but for me, technology is a wonderful thing that can, and should, make your life better, by simplifying every day's tasks. When I look on a computer, I can see a tool, an access point, and an personal assistant, all in one.
But what my Mom sees, is a device that tiring her eyes, frustrate her, and so on.
In M's case, the effect is much stronger. Here is a tool that can save him the trouble of going on a dangerous road to the bank (have you ever tried to cross the street with your eyes closed?). But unfortunately, not only that it doesn't, it makes it more difficult and even frustrates him.
Summarizing the above paragraphs, here's a thought: remember the feeling, when your computer went crazy and you didn't know how or what to do but to format it? I don't know about you, but I had my share of those. It's frustrating, bothering, sometimes even heart breaking (all those documents that you don't know if you had backups for...) . Now, this is the everyday feeling for someone like M while trying to surf web sites which are not accessible.
So why should you make your web pages more accessible? (That is, of course, if the above didn't convince you yet)
Well, I could answer that easily with "why not?", but that's not a real answer, isn't it? There are many reasons as of why not to do it.
So I will go differently and try to answer it from different perspective, why should you do it? What is your gain?
You'll get more exposure.
Almost 20% of population needs some kind of technology aid, due to some king of deficiency.
Those 20% might not use your site currently, and just go to a different site who dose offer some kind of answer to their need.
Moreover, accessible site is useable, or at least more useable. Your visitors will stay longer, will use more functions, maybe even buy more. If the user experience will be good, they will recommend it to their friends.
Furthermore, check the next item for even more exposure.
You'll do better on search engines.
Search engines are blind. No matter how'd you look at it. Technology (search technology) is getting more and more advanced, but still it doesn't "see" you fancy flash movie,or the shinning flash title you've put on the front page.
Search engines, how ever, do read the code. They might not see the flash, but the will read its alternate text.
Further more, most search algorithms will recognize an understandable site (I.e. one who uses HTML headers to define data blocks, etc.). Such site will earn better ranking.
You might upgrade your public appearing, and be seen as more "human".
No matter how good you look towards your business partners, your customers are still everyday peoples. Most of them will hold a grudge to a company who "doesn't care enough". Just have a look at the rapidly growing budgets for "Community Aid".
People love to feel that they matter. Web users are people. There for web users love to feel that they matter.
It is sort of a trend these days.
Equality is a trend ever since the 1960's. Everybody keep talking about making the Internet a place for everyone, with no differences. So, if not for any other reason, why not just join the trend?
Last but not least, Gandhi once said: “We must be the change we wish to see in the world.”, sometimes I find my self thinking - "What kind of impact I leave? Do I make a difference?"
Well, with making my organization's web site more accessible for people with deficiencies, I make a difference.