Web Design Ethiopia

Following are design flaws and constraints frequently encountered in page layout:

• Misalignment for foreground and background images
• Changing gutter sizes at the left edge of the browser
• Overlapping foreground images not allowed (although there are several tricks to get around this, such as using an image as a table cell background, using style sheets, or drawing them as a single image)
• Font size differences from system to system, machine to machine, and browser to browser
• Dynamic restructuring of pages not thoroughly tested

Dynamic Font Sizes and Line Spacing
Keep in mind that in the development of a web page, the fonts displayed on the screen are dynamic: they have the ability to increase and decrease in size.

This can affect your layout, the spacing in between items, and line-spacing on the page. What looks nice on Netscape and the MacOS may look completely different on Internet Explorer and Microsoft Windows.

What about Whit Space?
Is white space useful or not? There are a few key ideas to keep in mind when thinking about whether or not to use white space within your page.

While white space can be wasted space, it can also effectively support and organize the structure of the elements within the page. For example, setting a “New” section apart from the rest of the page makes use of white space to support the user.

However, you’ll want to keep in mind that if you use line-spacing within your text, you run the risk of font changes multiplying the white space. While vertical white space can be useful for differentiation between content sections, horizontal space is at a premium – gratuitous use of horizontal white space is a no-no.

Report This Post

Usability inspection is inexpensive, can be completed in as little as a few minutes, and can happen at any state of design. Inspection is really just looking at a web site to see what problems there might be.

Although the inspection can be performed by relying solely on your own expertise at identifying problems, it is usually more effective and more objective if you use a checklist designed for the purpose. Guidelines on a checklist are derived from designer experience, user testing and other user studies, core psychological principles, and problems that crop up again and again.

A usability inspection is sometimes known as an expert critique, but that makes it sound harder than necessary. While it’s certainly true that an expert evaluator will find more problems and more serious problems than a novice, even a beginner can do a practical, useful inspection.

A usability inspection is also sometimes known as a heuristic evaluation, where heuristic means that the evaluation is based on practical rules of thumb that work well most of the time. However, heuristic evaluation is often interpreted as a specific type of usability inspection with a specific set of 10 guidelines, which we’ll review below.

Limitations of Usability Inspection
Usability inspection doesn’t actually involve users in the evaluation process. As a result, even if you’ve identified a problem, you can’t be certain that it reflects an actual problem for a user or that your solution won’t be worse for the user. It’s good to have the design rationale on hand when you find a problem.

The designers may have had to make some difficult design tradeoffs and may already have identified the problem you’ve spotted. You don’t want to reverse their decision and end up making something else worse than they’d already anticipated.

In practice, there will be a set of problems you find that will be obviously wrong, and you should make those a high priority. Some other problems will seem to violate a guideline but at the same time seem appropriate in context. In those cases, you should either find a new solution that seems right from every perspective or hold off on the change and mark it as a problem to look for during user testing.
 

Report This Post

The most important step in any usability evaluation is to go back and fix the problems that were identified. Don’t just write up a report and leave it on the shelf – a usability evaluation must first identify the problems and then suggest practical solutions to improve the usability of the site.

A report that vaguely states that the navigation is confusing will be worthless. Instead, it needs to state specially how the navigation might be improved. Then the developers need to return to the code and fix the problem.

In some cases, fixing the problem will be simple, and in others it will take considerably more time than the testing itself. For this reason, when you are estimating the budget for usability evaluation, make sure you’ve included an ample budget for making the fixes.

After you’ve made the fixes, ideally you want to reevaluate the web site to verify that the fixes actually improved the usability. This type of testing, known as regression testing, applies to testing in general.

In principle, you should continue reevaluating and fixing problems until no major usability problems are identified. In practice, this is usually relatively quick for small, simple web sites.

For complex problems, you may only be able to afford to continue iterating until a minimal level of usability is achieved, and may have to postpone further improvements for a later version of the site.

When to Do Usability Evaluation
You can evaluate a web site through usability inspection, walkthroughs, or user testing at almost any point in the design cycle. In the optimal situation, you will evaluate the site periodically during development to verify that the design is staying on track.

Report This Post

In the first months of your release, you will undoubtedly receive several emails from users of your web site. Kudos, gripes, and bug reports are the most common. These may arrive in several different ways: emails, form data, snail mail, phone calls, feedback through your sales channels and business partners, and press coverage of your site.

Like the quality assurance measures that need to be taken in the development and distribution phases, it is just as critical to establish a method for dealing with user comments. These are extremely informative usability data.

There are several things you should do when dealing with customer feedback: develop a triage for tracking the level of severity, record the type of error, respond promptly (even if it is just responding to the user’s query to say you will be working on it later), and track the changes.

You should develop a triage of customer feedback similar to that used in your quality assurance process. If your site is large enough, and you are getting a significant amount of communication, you may want to develop a database to help oversee the communication process.

In addition to the level of severity, you should categorize the feedback into the type of problem that it reports, such as typo, content, bug, invoicing, billing/shipping, technical, or customer service.

Knowing the level of severity along with the areas where the problems occur allows you to form action items for each problem. Be sure to prioritize your responses to these incoming problems and establish a method for tracking changes and responding.

Report This Post

Once your site has been up for a while, you can begin to investigate the use of the site. Studying the use characteristics of your site will help to inform future design decisions. Use studies differ from user testing in that they are more analytical and look at patterns of use. Also, they represent actual usage characteristics, not simply data generated from a lab setting.

Be cautious when interpreting this data. Without a clear description of use, it can sometimes be misleading to interpret the raw data. For example, suppose you see that a particular page gets 65 percent of your hits. You might think to yourself, “Wow, this page must be the users’ favorite; it must be very useful.”

In reality it may be that your navigational structure forces the majority of the users to go through that page in order to get the information they are truly searching for. This is a theme that will be repeated throughout this section. It is the relevance that matters, not the raw numbers.

Analyzing Your Hit Logs
An in-depth analysis of your hit logs can reveal a substantial amount of information. The logs can tell you about overall hits, conversion rates, entrance pages, search terms used to reach the site, effects of design changes, general growth over time, peak times, demographics, and system down-time.

Each of these is worthy in its own right, but it is the overall picture that the logs provide that is the most informative. A thorough investigation of your hit logs will give you an understanding of how your current site is being used and help suggest a direction for future design.

Overall Hits
It’s important to keep in mind that the goal of your site is not overall total hits, but rather relevant hits. For example, if you’re selling products, it’s much better to have 20,000 hits on your front page and 5,000 hits on your Products page than to have 300,000 hits on your front page and only 1,000 on your Products page.

Or, if you are selling parts for a car that is only sold in Europe, and you are getting 80 percent of your hits from people in the U.S., then you aren’t attracting the right target audience. While overall hits can be a good indictor of the visibility of your web site, it is very much a mere surface detail; the real meaty information lies in the relevance of those hits.

Conversion Rates
Conversion rates can be very revealing about the quality of your web site. Conversion rates tell you haw many people go from one place to another place – in other words, whether users are actually penetrating and moving through your site, or whether they are just looking at one page and leaving for greener pastures at a competing site.

This type of analysis can be particularly useful if you have some sort of linear or sequential operation such as a purchasing system. In this hypothetical purchasing system, which runs across several web pages, note the major drop that occurs after the special offer.

This might be telling you something – perhaps that special offer isn’t worth it. You’ll want to compare the number of people who accept the special offer (page 2) with the number who remain to enter the billing and shipping information (page 3), and then judge whether the extra value of the special offer is worth the loss of up to 4,500 customers.

However, the analysis is not that simple, because you still need to compare the results without page 2 – perhaps you would lose the same number of people in a different part of the transaction.

Entrance Pages
Hit log analysis can also reveal the pages from which users are entering your site. This is extremely useful information. If 90 percent of your users aren’t seeing your home page, then is it really worth spending thousands of dollars to make the home page look nice?

Entrance pages can also tell you what your users find valuable in your site. For example, we have determined that one of our web sites. Usability First (www.usabilityfirst.com), has a large proportion of its users entering directly into pages in the Groupware subsection of the site.

This tells us that perhaps the subspecialty is ore interesting to its specialized market than the overall set of pages is to the rest of the users.

Search Terms Used To Reach the Site
Hit logs can reveal the search terms used by users to reach your site. This can shed light on which keywords are working and which are misleading and can also suggest additional terms that you may not be using. However, this information doesn’t tell you who isn’t finding your site because the search terms didn’t lead them to you.

Analyzing users’ search terms can demonstrate which of your metatags and description terms users are matching; reveal users’ search terms that you don’t have in your metatags and description; and suggest new content areas or new pages that might be useful.

Analyzing Design Changes
Analyzing your hit logs over time can provide you with information regarding design changes and general growth over time. It can also establish peak times, help estimate spikes, locate orphaned pages, and demonstrate major traffic patterns. To analyze the impact of design changes, you can look at the logs before and after the changes have been implemented to reveal possible ways in which the changes have affected use.

However, you also need to consider other unrelated but simultaneous changes over time. In other words, you can’t be sure that it is your design changes that have affected the use. Rather, it could be general changes over time.

For example, if you make changes to the home page to include a top-level link for “Usability” and then your Usability page gets twice as many hits over the next six months, you can’t necessarily conclude that it was this design change that caused the increase in traffic. Instead, it could just be that the general public has become more interested in the topic and therefore the traffic has increased as a result.

Once way to test the impact of a design change is to make the change for a set period of time and then revert to your previous design. If the traffic increases following the change, then decreases again when the change is removed, then you have more reason to believe the traffic increase wasn’t due to an external factor. While this tactic is not recommended for any site that survives purely on the basis of increasing traffic, it can provide better evidence that a specific design change has affected the traffic.

A more reasonable way to examine the effect of a design change is to look very closely at the exact time of implementation. If you made the change on Monday at noon, and your traffic tripled at exactly that time (and stayed at three times the previous amount), that should be a good enough indication that the design change is working. However, if your number of hits is small or the degree of change is relatively minor, such as 10 to 20 percent (which is still a nice increase), then it’s hard to be certain that the increase really was stimulated by your design change.

Watching General Growth Over Time
Log analysis can provide you with basic information about the growth of your site over time. If you have multiple sites to compare, you can get a better idea of how well each is doing. Some sites may grow exponentially, while others may peak and stay at a consistent use level.

In addition to looking at growth rates across sites, you can compare different sections of a single, large site. For example, large corporate sites may compare the differences in use across divisions. Some way grow from month to month, while others may stay static.

Establish Peak Times
Hit logs are useful for seeing when your web site is used the most and to establish peak times. There may be trends across the time of day, day of the week, or months of the year. This knowledge can be useful for scheduling maintenance times. It may also be useful for scheduling maintenance times. It may also be useful for determining when to make revisions.

Peak times may vary tremendously across the time of day. For example, in the United States many sites are fairly inactive in the late evening and early morning (EST). However, the Usability First site has fairly even use throughout the 24 hours. This is most likely because Usability First is used widely outside the U.S.

Finding Orphaned Pages
When analyzing hit logs, you may find a page or two that rarely gets hits. It could be that these pages are just not interesting or important to the users. However, if you think these pages are important, then there may be something else at work. Often you can find orphaned pages, pages that aren’t consistently linked to the rest of the site, or links that are hard to find in the page layout.

Finding Extremely Popular Pages
Hit logs may also reveal where your most popular pages are located. These pages can then be used as a measuring stick against the rest of your pages. Better yet, your may use these pages to drive users to other important but less popular areas of your site. You can use them to guide the direction of your site. Hit logs can also help to determine which areas might be candidates for expansion in new popular sections.

Determining the Value of a Page from Hit Logs
Beware not to overvalue the data from your hit logs. As with most data, it is what it is. Taking too much meaning from the data can lead you down the wrong path. Always keep the following in mind:

The Number of Hits Does Not Always Reflect the Value of the Page to a User.
You can’t automatically assume that because a page gets five times as many hits as the rest of your pages that it is the most valued page on your site. It could be quite the opposite: users may hate the page!

It could be that your navigation forces them to go through that page in order to get to where they want to go. In this case, you would have an inflated number of hits, and you can’t determine the value from that number alone.

Similarly, because a page gets only a few hits doesn’t mean its value is low. The page might contain information for emergency data restoration. You would hope this page doesn’t get used often, but when it’s needed, it’s probably the most valuable page on the Internet to the individual using it!

Demographics
Hit logs can provide you with several forms of information about who has visited your site and what type of software they’re using – their operating system (PC, Mac, Linux, Unix, Palm, etc.), their browser and version, their IP address, which, like a domain name, can suggest their affiliation (.com = business; .edu = education; .gov = government) and country – without really guaranteeing that they fall into a specific demographic.

Beware! You may be missing an entire group of individuals (say, Lynx users) because the users simply aren’t out there or aren’t interested in the site. However, it may be that they are interested in the site, but it doesn’t work well with their browsers.

System down Time
Your server logs can also indicate how frequently your server is available, and at what times the server has been down. Your web site can become unavailable for a variety of reasons: system crashes, regular system maintenance, network outages, power outages, incompatible software upgrades, expired security certificates, accidental changes to server settings or file permissions, and so on.

No one guarantee 100 percent server uptime or web site availability, but a variety of contingencies are handled by professional hosting companies, such as backup servers, backup network connections, backup power supplies, appropriate software testing platforms, and systematic maintenance procedures. Episodes of server outages should be recorded and tracked by the hosting company in order to continually measure performance and evaluate steps for improvement.

Typically, availability goals for servers are based on a weighted availability metric, where outages during peak times are considered more severe than outages in low-traffic times. Thus, regularly scheduled system maintenance should be scheduled for off-peak times.

In summary, there are several keys to analyzing your hit logs: be sure to keep in mind the relevance of each page, look for numbers that are meaningful to the goals of your web site, and beware of making false assumptions.

Report This Post

Query-based search engines generally work by comparing a user’s query against an index that cross-references web pages. Although each search engine behaves slightly differently behind the scenes, there are some common traits across most systems.

Matches are often based on the number of times that a search term appears in your document, weighted by the length of your document (shorter documents with the same number of matches are better) and the overall frequency of the word (rare words are weighted more heavily than common words).

There are several ways to increase the chances that your web site will appear in search listing: be sure that your pages include HTML, text, include <alt> tags for all your images, include metatags on every page, and follow good writing practice.

Make sure your pages include text! Without text, the search engines will have little from which to gauge the content of your page. The only information about your images that crawlers can get is from the names and <alt> tags. So be sure to include relevant <alt> tags that mention something about the content of your images, not just that they are images (e.g., <alt = “this is a picture” >).

While some people will tell you that it is best to have huge pages full of text in order to receive the best rankings in a search index, this is not always the case. Some indexes divide by the number of words, and thus more words will actually decrease the quality ranking associated with a match.

Responding To Problems
When you find problems with a live site, it is critical that you address these problems right away. Major or minor errors in a live web site lead users to perceive that site as unreliable or unprofessional. Misspellings can damage users’ trust in your site as much as broken functionality can. It is imperative that you address all problems as soon as they are noticed.

A quick response to problems should also become part of your quality assurance process. You should be sure to include time immediately after the launch to take care of any potential snags you may have missed in your user testing and earlier quality assurance measures.

A checklist like that in Form 11-5 can augment your quality assurance procedure to allow for rapid verification that a site remain stable as minor updates occur. (Download from http://www.mkp.com/uew/.)

Of course, when large-scale updates occur, the complete quality assurance procedure should be repeated. And for large, regularly updated sites, a custom checklist can address specific problems that are known to occur as well as include content-specific guidelines and other recurring administrative procedures.

Begin Maintenance Schedule
A regular maintenance schedule should be developed well in advance of your launch, but here is where you put it into action. You should include procedures for regular maintenance and slack time for unexpected maintenance.

Be sure to develop a maintenance schedule that covers the following: updating time-sensitive content (e.g., what’s new! items, interest rates, sale prices, submission deadlines, etc.), fixing unexpected or newly found errors and bugs, and running functionality tests of new releases of browsers, server software, and all changes and updates that have been made.

Plan Major Updates and Revisions
In addition to small changes, bug fixes, and client requests, it’s very likely that you’ll need to make major updates and revisions at some point. Major updates generally consist of functional changes, major interface revisions, and large-scale redesigns that require the effort of a substantial percentage of the original design team.

Revisions and changes to the web site should be driven by a combination of marketing needs, functionality innovation, and user performance measures form the current site. In other words, a redesign doesn’t need to happen just because someone decides the site needs a new look.

While this may be the impetus, and indeed where the cash comes form, when you plan updates make sure you have thoroughly investigated current use and problems with the current interface.

Throughout all of your basic maintenance procedures, you should be recording all problems and changes that either are too insignificant to change in the current version or require too much effort to be done on a regular maintenance schedule.

These problems can then be addressed when developing an update schedule for your web site. In addition, you should consider major functional changes and large-scale revisions and updates.

Report This Post

Once your site has made it to the playing field, be sure that it has everything it needs to come out on top. Get your site noticed, keep it up to date and well-maintained, and respond quickly and efficiently to any errors.

Web Site Promotion: Getting the Users to Your Site
Having a highly usable site includes making access simple and straightforward. Even if your site works great – that is, your user tests have shown that users almost always find what they need, the ordering process is easy and intuitive, and the site gets raves from those people who have seen it – users still need to be able to find your site when surfing the Internet. If the site can’t be found, it won’t be used.

Directories and Search Engines
Users search for sites in several different ways. Occasionally users know exactly what they’re looking for; other times they are simply surfing the Web for something of interest.

More commonly, they have a general idea of what they are looking for, but use the search process itself as a means to clarify and elaborate their questions. If your goal is drive traffic to your site, you need to understand the users’ approach to searching.

To make the most out of search engines and directories, consider first how people use the sites, and second, how the different search engines are structured and respond to queries.

Directory or Categorical Web Indexes
When a user has a good idea of what he or she is looking for, a categorical index (or directory) is generally a good tool. For example, Yahoo! and dmoz.org  provide structures that facilitate searching by providing preexisting categories within a common framework. However, while this is great for the user, it can make the web site promoter’s task more difficult.

There are several things you can do to enhance the prominence of your site. Place your site at the most detailed level possible. Thoroughly review the possibilities and place your web site within the most common areas. (The number of categories you can select varies across directories; for instance, Yahoo! allows you to place a site in two places, whereas dmoz.org only allows you to suggest a site for one category.)

Carefully consider where your target audience is most likely to be looking for sites like yours. What keywords do they use? What group of sites do they expect to see you among? Describe your site so that it addresses the information needs your users have as they browse.

If you have appropriately focused subsites, consider submitting different sections of your site in different search categories. However, if you do this and if the subsites are not sufficiently different, you may end up not being listed at all in the indexing site as a punishment for breaking their rules and regulations (limiting you to only two listings, for instance).

There are many different directories in cyberspace, and there is no way to guarantee you are listed on every single one. In addition, adding your URL to the directories is a labor-intensive task. It’s a good thing there are tools to help. However, we still recommend making your own submissions to the major players (e.g., Yahoo!) yourself. This is the only way to ensure that the information is accurate and that you have chosen the right category for your site.

Report This Post

During the launch stage, several steps need to be completed. These are as follows:
• Perform final domain name check to ensure DNS routing is working.
• Copy files over from staging area.
• Perform final check of functionality.
• Review postproduction checklist.
• Once the site is online, be sure to get final approval before going public.
• Coordinate with marketing on the expected launch time.

Domain Name Check
It’s imperative that you check to make sure the domain name routing to your site is working properly! This should be done at the very least a week in advance of taking the site up. Once you have checked to make sure the routing is working properly, you’ll want to test it one last time before actually launching the site.

Final Check of Functionality
Once the site is located in its final resting place (i.e., moved over from the staging area), be sure to perform a functionality test before going live. This includes testing any interactivity or events that require back-end processing. Be sure to test email addresses, forms, ordering processes, database interactions, and download time, to ensure adequate responsiveness.

Review Postproduction Checklist
Once the site is up and live, review the postproduction checklist before actually announcing the launch, making sure that everything has been addressed. Review the site to make sure that nothing has been affected by any last-minute moves.

Get Final Approval
Make sure that you have final approval from the primary stakeholders before allowing the web site to be accessed publicly. This will save you from any last-minute embarrassments and will ensure that the site has been reviewed and has received the attention of those who ultimately make the decisions.

Coordinate the Launch with Marketing
Develop a comprehensive marketing schedule for your web site. Tight integration between launching the site and marketing is needed to get the quickest results possible out of your site. A site without marketing will not have users, and marketing without a site gives the users nowhere to go.

In addition to luring new customers, marketing your site will help current customers locate your web site. To make this happen smoothly, the last month of development should be tightly coupled with marketing efforts. As is the case in any portion of the development phase, be sure to mention any delays or changes to the initial launch schedule as early as possible. Don’t wait until the launch date to inform those in charge of marketing that the site won’t be ready for another month!

There are several arenas where you can advertise your web site. Be sure to include the URL in email signature files and in all printed ads and alternative advertising mediums, and incorporate the URL into all other advertising materials. Announce your web site in appropriate newsgroups and mailing lists, purchase banner ads and internet advertising, and arrange for press releases to coincide with the launch.

Report This Post

Once you have passed your formal testing procedures and have met all of the predefined exit criteria, you need to verify one last time that everything is in place and ready to go. Checklists are a wonderful way to make sure that you have all of the bases covered.

The Postproduction Check List
A postproduction checklist (Form 11-3; download from http:/www.mkp.com/uew/) allows you to quickly and decisively test the HTML quality on a page-by-page basis. (We call it postproduction rather than quality assurance because it includes a set of steps that should be taken before launch but that aren’t testing related.)

For large sites (greater than 50 pages or so), testing can be quite a daunting task, and several days (or even weeks) should be scheduled for postproduction. However, on smaller sites, postproduction can usually be completed by a single person is a few hours.

Final Approval for the Launch
In many client relationships, it is critical to get final approval before going live. Review your code testing and postproduction before showing the final site to the client. Quite simply, you want to be sure that you, rather than they, find the bugs.

This isn’t to say that the client won’t get a glimpse of the site in its final stages, but you should be sure to complete all your testing before presenting what is considered the final, launchable product. At the same time, you should involve your client in the testing process as appropriate. For example, when testing requires domain knowledge, the client may be able to provide invaluable verification.

It is advisable to have the client sign off on a final approval form. While the client should have already approved the basic look and feel of the site in earlier sign-offs, this is the time for the client to note any errors on the site and to proofread the site. Any major changes requested now by the client may require additional charges. Of course, the client should have agreed earlier to the test completion criteria for quality assurance.

Many design firms use forms like Form 11-4 to secure final approval. (Download from http://www.mkp.com/uew/.) This form is not just for external clients; the same one (perhaps slightly modified) can be used internally as well.

In that case, instead of shipping the form to the project leader from your client team, it would be given internally to whomever is in change of the project. This process protects the designer and ensures that the proper individuals have seen and are satisfied with the project.

Report This Post

Develop a formalized system for recording and making bug fixes. You can either record the errors and changes in a database (for larger projects) or simply keep forms and checklists of the required changes.

Whatever you do, you must keep a record of the changes. Why? Having a history of the changes you’ve made and why will keep you from going in circles, making changes and then changing them back.

It also provides you with details of who found the problems and who made the corrections. While it may seem like an unnecessary extra effort at the time, you’ll appreciate it a year later when you encounter a similar bug.

You’ll have the error recorded and know who fixed it and how, saving you repeat effort. In addition, documentation will provide you with data that can be used to examine the efficiency of your processes and give you a baseline for measurement and estimation of future projects.

The Problem Report and Resolution Form (Form 11-1; download from http://www.mkp.com/uew/) can be used to track problems. While using this detailed form may not be cost-efficient for everyday HTML problems, it is appropriate for complex system such as database-driven portions of sites. You can also track this information in a database.

The Problem Summary Report (Form 11-2; download from http://www.mkp.com/uew/) lists all outstanding problems (any that haven’t been resolved) for quick reference. Totals at the bottom allow for quick status checking about the number of problems of each type.
Who Needs To Make The Fixes?

There are a couple of reasons you need to take the bug report back to the person who originally made the mistake. The first reason is to make the person aware of his or her mistakes so similar mistakes will be prevented in the future. Second, that person will have a better idea than anyone else of how the changes may affect the rest of the site.
 

Report This Post