UNIT-1 (WEB ENGINEERING)

Role of Information Architect!

Information Architect is a person who creates the structure or map of information which allows other to find their personal paths to knowledge. Need of Information Architect Each building serves its purpose uniquely. Architecture and design of a building depends upon the purpose, location, users, finance etc. if we start constructing a building without deciding its design and architecture the constructors will have problems in constructing it, users will have problems in using it and the purpose for which the building was constructed will never be achieved. Similarly websites are resource of information. Each website serves its purpose uniquely. If website is developed without any planning about design and architecture then developer may have problems in organizing the information and maintaining it, users may have problems in using the website in searching and accessing the information. These problems may be like time consuming search, time wastage in loading of web page due to improper formats used and difficulty in browsing due to the use of improper keywords. So information architecture is necessary: 1).For producer so that any updation in the information can be done efficiently within time. 2).For any website to be commercially successful because if user are facing difficulty in searching and navigating the information then they will not use the website again. 3).Because unorganized information cant be converted into knowledge. Main Job of information Architect The main jobs if the information architects are given below. An information architect 1).Clarifies the mission and vision for the site, balancing the needs of its sponsoring organization & the needs of its audiences. 2).Determines what content and functionality the site will contain. 3).Specifies how users will find information in the site by defining its organization, navigation labeling and searching systems. 4).Maps out how the site will find accommodate change and growth over time. The Consumer's perspective Users want to find information quickly and easily. Poor Information Architecture makes busy users confused, frustrated and angry. Because different users have varying needs it is important to support multiple modes of finding information. From the consumers perspective there can be two modes of finding information.

$H@nU $iddiQue

Known item searching: Some users know exactly what they are looking for. They know what it is called and know it exists. This is called known item searching. Casual Browsing: Some users don't know what they are locking for. They dont know the right label. They casually browse or explore the site and they may learn that they have never even considered. If you care about the consumer, make sure that your information architecture supports both modes. While attractive graphics and reliable technologies are essential to user satisfaction, they are not enough. The producer perspective If you are producing an external website the users can be actual or prospective customers, investors, employees, business partners, media & senior executives. If you are producing an intranet the employees of your organization are the consumers. The cost of designing and implementing the architecture is the cost of time spent: 1).In deciding categories of various users. 2).In arguing over the main areas of content and functionality that the site would include. 3).Redesigning. 4).In maintaining the information space on increase in information. The role of information Architect is to minimize their cost. If information Architect doesn't take care of producer s perspective the burden will be on the site's user to understand how to use and find information in a confusing, poorly designed website. The site maintainers wouldn't know where to locate the new information that the site would eventually include, they had likely to quarrel over whose content was more important and deserved visibility on the main page and so on. Who should be the information Architect? An insider who can understand the sites sponsoring organization. Advantages 1).Organizations information is in safe hands. 2).No extra cost, so cost effective. 3).Insider knows the most about in organization's processes and how to get things done within that organization. Disadvantages 1).Knowledge of an insider may be too specific. 2).Insider may lack the political base required to mobilize cooperation from others in the organization. 3).Insider gets diverted from his original duties.

$H@nU $iddiQue

Someone who can think as an outsider and be sensitive to needs of sites users. Advantages 1).No biased behavior is expected from an outsider. 2).We have a choice for outsider so we'll choose according to our needs so he'll act more efficiently than insider because he'll be the specialist of his field. Disadvantages 1).Extra cost. 2).Outsider doesn't have minute details of 'organization so he needs information. 3).Passing secret information of the organization to an outsider can be dangerous. Outsider can be from a variety of fields like: Journalism: Journalists are good at editing and organizing information. They have rich knowledge base. Graphic Design: Graphic Design is much more than creating pretty pictures. It is geared more towards creating relationship between visual elements and determining their effective integration as a whole. Information and library science: People from this background are good to work with searching, browsing, and indexing technologies. Marketing: Marketing specialists are expert at understanding audiences and communicating a message effectively to different audiences. They know how to highlight a positive feature and how to suppress the negative ones. Computer science: Programmers and computer specialists bring an important skill to information architecture. Especially to architecting information from the bottom up. For example often a site requires a data base to serve the content; this minimizes maintenance and data integrity problems. Computer scientists have the best skills for modeling content for inclusion in a database. Balance Your Perspective Whomever you do use as an information architect remembers everyone (including us) is biased by their disciplinary perspective. If possible try to ensure that other disciplines are represented on your web site development team to guarantee a balanced architecture. Also, no matter your perspective the information architect ideally should be solely responsible for the site's architecture and not for its other aspects. It can be distracting to be responsible for other more tangible aspects if the site, such as its graphic identity. In this case the site's architecture can easily, it unintentionally, gets relegated to secondary status because the architect is concentrating, naturally on the tangible stuff.

$H@nU $iddiQue

Collaboration & Communication!

The information architect must communicate effectively with the web site development team. This is challenging since information architecture is highly abstract and intangible. Besides communicating the architecture verbally documents (such as blueprint diagrams) must be created in ways that can be understood by the rest of the team regardless of their own disciplinary backgrounds. Need of Team In the early days of the web, web sites were often designed, built and managed by a jingle individual through sheer force of will. This webmaster was responsible for amble g and organizing the content, designing the graphics and hacking together any necessary CGI scripts. The only prerequisites were a familiarity with HTML and a willingness to learn on the job. People with an amazing diversity of backgrounds suddenly became webmasters overnight, and soon found themselves torn in many directions at once. One minute they were information architects, then graphics designers, then editors, then programmers. Then companies began to demand more of their sites and consequently of their webmasters. People wanted more content better organization, greater function and prettier graphics, tables, VRML, frames. Shockwave, Java, and Actives were added to the toolbox. No mortal Webmaster could keep with the rising expectations and increasing complexity of the environment. Increasingly, webmasters and their employers began to realize that the successful design and production of complex web sites requires an interdisciplinary team approach. The composition of this team will vary, depending upon the needs of a particular project, available budget and the availability of expertise. However most projects will require expertise in marketing, information architecture, graphic design, programming and project management. Marketing The marketing team focuses on the intended purposes and audiences for the web site. They must understand what will bring the right people lo the web site and what will bring them back again.

ORGANIZING YOUR WEBSITE PARAMETERS

The organization of your web site involves several factors, including how you have your information organized, how you have your XHTML and graphics files organized, and how you want your visitors to navigate around your site. Let's look at each of these factors. Organizing Information Organizing File site Navigation
$H@nU $iddiQue

ORGANIZATION OF YOUR INFORMATION Second-generation web sites are organized around the concept of "layers". Visitors advance through your web site and delve into greater detail about your theme as they go deeper into the layers. In contrast, third-generation sites are organized around the concept of metaphors in which the visitors experience the site as if it were the "real-world". This course focuses on second-generation sites. Structure of Layers The first layer is your home page that introduces your web site and catches the attention of your visitors. The second layer contains the pages that are linked from your main navigation bar. These pages give additional detail about your theme but are still general in nature; they also give links to pages in the third layer. Third-layer pages give more detail about your theme. If your visitors advance this far, they are seriously studying your web site. Because this depth of study takes time, third-layer (and higher) visitors often become return visitors.

Depending on your theme and how much information you want to provide, your site might have four or five or more layers. Each layer is designed to increase the interest of your visitors in your theme and hence the motivation of your visitors to remain at your site and to return to your site.

There are different ways that you can organize your web site and still have your site "layered". Think of your site as a story, and organize the material in a way that enhances the telling of your story. This is a fun chance to be creative!

Layers Affect Loading Times

Make your home page short such that it loads quickly--your readers will appreciate it! Keep the page short by restricting it to a motivating but short introduction to your web site, links to the rest of your site. Write and illustrate the introduction such that it captures the attention of your visitors and motivates them to go to the next layer. By having a "layered" site, you will have many small pages instead of a few large pages. This allows your site to be loaded in small segments, and this will make for faster reading of your site by your visitors. Most people don't mind waiting a few seconds for a page to load, but they won't wait longer than 10 or 15 seconds!

$H@nU $iddiQue

Avoid Dead End Pages

We hope that visitors will use our home page as the doorway to our web site, but any page that can be indexed by search services or e-mailed by friends might be used to enter our site. Thus, be sure that every page has a link to your home page and links to related pages.

=========================================================================

========> ORGANIZING YOUR FILES <====== Your site will contain quite a few files that must be grouped together in some manner. This grouping must be compatible with the hard-disk layout of both your development system and the web server hosting your site. This means that the grouping of your files can not involve the names of hard disks, because your development system will have different hard disks than the web server. Instead, the grouping must be relative to itself, as I will next explain.

Directory Tree
It is appropriate to have several folders in which you keep the files that make up your web site. These folders comprise a small "directory tree". Your home page should be the "root" of this tree, and the rest of the folders should be children off the home page. That is, all of the folders that contain your files should be inside the folder that contains your home page.

Common Example A common arrangement for small sites is to have one folder that contains all of the pages (the HTML files). This folder is the main or root folder of the site. The name of the folder is part of the URL for the site. Inside that folder is a second folder that contains all of the graphics files. The name of this folder is not part of the URL.

HTML Links
This arrangement allows for a simple way to link files together. The links between HTML files consist of just the names of the files being linked since all of the HTML files are in the same folder. That is, the links are relative to the folder containing the home page. For example, the link to a file called plane.htm would be just the name of the file, plane.htm <a href="plane.htm">Text that is visible on the screen</a>
$H@nU $iddiQue

Since the graphics files are in a different folder, links from the HTML files to the graphics files contain the paths to the graphics files. Since the graphics files are in a folder that is inside the main folder, the paths are just the name of the graphics folder and the names of the graphics files. For example, for a file called glasses.gif that is in a folder called graphics, the link is the name of the folder followed by the name of the file; a slash (/) separates the two names:
<img src="graphics/glasses.gif" />
[alt, height, width parameters omitted]

These two links are relative to the web page containing the home page.

File Name of Home Page

Your home page is the initial screen that appears when your site is accessed. Name the file containing your home page index.html, because that name is the default name used by web browsers. Actually, you can call it anything you want, but then you will have to include the name of the file in the URL for your web site. If you name the file index.html, you won't have to include the name in the URL.

Watch Out for WYSIWYG Editor Bad Links

Some WYSIWYG editors create bad links to graphics and web pages by putting your hard-drive paths in the links. These links don't work, because web servers can't access your hard-drive to fetch the files. If you have graphics that don't display in your browser, click on View and then on Source (in the browser Menu bar) and examine the <img src> tags to see if they contain your hard-drive paths. If so, return to your editor, go to the HTML mode and modify the links to have the proper relative paths, as explained above.

=======> SITE NAVIGATION <=======

Web sites should provide convenient ways for visitors to locate pages within the sites and to move from page to page. This movement is known as "site navigation". METHOD OF NAVIGATION Method of site navigation have proven successful. Traditionally, web sites have had a "home" page that linked other pages in the site. These sites are "second generation" sites and are the ones focused on in this course.

$H@nU $iddiQue

A new method of navigation that is based on metaphors is becoming popular. Instead of a home page, these sites are built around a theme that is appropriate for the site. The site for Jimtown Store, for example, is built around the metaphor of a country store.

Navigation Bars

Size of Navigation Bars Even though navigation bars are important parts of the site, they detract from the message of the site because they take up space on the monitor screen. This means that navigation bars should be kept as small as possible while still being able to perform their functions. Because of this, it is common for the text in the bars to be smaller than the text in the pages. In addition, the number of rows of links in a bar should be kept to three or less, if possible. Icons As Links Icons, as well as text, can be grouped into navigation bars. The icons should have alternate text descriptions of the links to provide text links to accompany the graphics links. One common practice is to place square brackets around the alternate text descriptions of icons that are links. For example, an icon acting as a link to a What's New page might have the following alternate text description in its XHTML element.
alt = "[What's New]"

Icons that are used as links should be placed in tables to keep them neatly aligned into bars. Even better is to use CSS.

Text-Only Navigation Bars Because some people surf with graphics turned off, or use browsers with no graphics capability, it is customary to have text-only navigation bars in addition to graphical bars. As explained above, text-only bars can consist of alt tags that are part of icons that are used as links. Text-only bars can also be created as "stand alone" navigation bars (i.e. not associated with icons). These "stand alone" bars usually have either vertical lines or square brackets that separate the links, as shown in the following example. The bars are usually placed at the bottom of the pages, and a small font size is used.
Home | What's New | Site Map

Navigation Bars On Long Pages Most pages are long enough that browsers place vertical scroll-bars on the pages. To make navigation easier by avoiding the need to scroll to the top of pages to access the navigation bars, it is traditional to have nav bars at both the tops and the bottoms of the pages. Since vertical navigation bars can't easily be placed at both ends of the pages, some sites have Top links at the bottom of the pages to make it easier to return to the top of the pages. Other sites have horizontal text-only bars at the bottom of the pages to supplement the vertical bars that are near the top of the pages.
$H@nU $iddiQue

Navigation Bars are Hierarchical Because second-generation web sites are hierarchical in structure, their navigation bars should also be hierarchical. That is, The content of the bars should vary with the hierarchical position of the bars. You might want, for example, your navigational bars to give links to pages that are in the same hierarchical level as the page being viewed. Or, you might want the bars to give links to pages that are in the next lower level. Regardless how you organize the content of your navigation bars, you should always have a link to your home page in each bar.

NAVIGATION SYSTEM
When we have lards amount of information then to organize the information space we divided the information space into groups and label them. To look for any information atom we need to search for its link information its group. This is done using browsing/navigation user can get lost in the information space but a well-designed taxonomy may reduce the chances that user will become lost. So generally Navigation Systems are beneficial if information is organized using the hierarchy model. Complementary navigation tools are often needed to provide context and to allow for greater flexibility. Navigation and Searching Navigation and Searching both are used for finding information. Navigation searches for the information to be found by moving between links available. But information searching we give the information about the information to be found as text to the search engine and search engine does the task of finding information for users. We can search for a phrase but can't navigate.

Types of Navigation Systems!

Embedded/integrated Navigation Systems Embedded Navigation Systems are typically wrapped around and infused within the content of the site. These systems provide context and flexibility helping users understand where they are and where they can go. Embedded Navigation Systems can be further divided into three categories: Global (site-wide) Navigation System: By definition, a global navigation system is intended to be present on every page throughout a: site. It is often implementing in the form of a navigational bar at the top of each page. These site wide navigation systems allow direct access to key areas and functions, no matter where the user travels in the site's hierarchy. Most global navigation systems provide a link to the home page. Many provide a link to the search function. Local Navigation Systems: Local Navigation Systems enable users to explore the immediate area. Some lightly controlled sites integrate global and local navigation into a coexistent unified system. A user who selects business sees different nevi anion options than a reader who selects sports, but both
$H@nU $iddiQue

sets of options area presented within the same navigation framework. These local navigation systems and the content to which they provide access are often so different that these local areas are referred to as sub sites or sites within sites. Sub sites exist because (1) areas of content and functionality really do merit a unique navigation approach (2) due to decentralized nature of large organization different groups of people are often responsible for different content areas and each group may decide to handle navigation differently. Contextual Navigation system: Some relationships don't fit neatly into the structured categories of global and local navigation. This demands the creation of contextual navigation links specific to a particular page, document or object. E.g. Words or phrases within sentences are represented as embedded or inline hypertext links. On an e-commerce site, these See Also links can point users to related products and services. In this way contextual navigation supports associative learning. Users learn by exploring the relationship you define between items. They might learn about useful products they didn't know about. Supplemental/ Remote Navigation System These navigation systems are external to the basic hierarchy of a website and provide complementary ways of finding content and completing tasks. These navigation systems provide users with and emergency backup. Some of the examples of Remote navigation Systems are Sitemaps: In a book/ magazine, the table of contents presents the top few levels of the information hierarchy. It shows the organization structure for the printed work and supports random as well as linear access to the content through the use of chapter and page numbers. In context of websites a sitemap provides a board view of the content in the website and facilities random access to segmented portions of that content. A sitemap can employ graphical or text based links to provide the user with direct access to pages of the site. A sitemap is the most natural for websites that lend themselves to hierarchical organization. But for a small website with only two or three hierarchical levels a sitemap may be unnecessary. Site Indexes: Similar to the back of book index found in many print materials, a web based index presents keywords organization phrases alphabetically, without representing the hierarchy. Unlike a table of contents indexes are relatively flat, presenting only one or two levels of depth. Therefore indexes work well for users who already know the name of the item they are looking for. Large complex Websites often require both a sideman and a site index. For small sites, a site index alone may be sufficient. A major challenge in indexing a website involves the level of granularity. Methods to create index are 1).For small sites create content to inform decisions about which links to include. 2).For large sites, use controlled vocabulary indexing at the document level to drive automatic generation of tie site index. Guides: Guides take several forms including guided tours, tutorials and micro portal focused around a specific audience topic or task. In each case, guides supplement the existing means of navigating and understanding site content. Guides typically feature linear navigation but hyper textual navigation should be available to provide additional flexibility.
$H@nU $iddiQue

Rules for designing guides: 1).The guide should be short. 2).At any point, the user should be ably to exit the guide. 3).Navigation should be located information the same spot on every page so that users can easily step back and forth through the guide. 4).The guide should be designed to answer questions. 5).Screenshots should be crisp, clear and optimized with enlarged details of key features. 6).If the guide includes more than a few pages, it may need its own table of contents. Uses of Guides 1).Guides often serve is a useful toil for introducing new users to the content and functionality of a website. 2).Guides can be valuable marketing tools for restricted access websites enabling you to show potential customers what they will get for their moneys. 3).Guides can be valuable internally, providing an opportunity to showcase key features of a redesigned site to colleagues, managers and venture capitalists. Linking between Navigation and searching: Searching is loosely linked with integrated Navigation Systems and tightly linked with Remote Navigation systems.

Designing Elegant Navigation Systems!

Designing navigation systems that work well is challenging. Youve got so many possible solutions to consider and lots of sexy technologies such as pop-up menus and dynastic site maps can distract you from whats really important: building context, improving flexibility, and helping the user to find the information they need. No single combination of navigation elements works for all web sites. One size does not fit all. Rather, you need to consider the specific goals, audience, and content for the project at hand, if you are to design the optimal solution. However there is a process that should guide you through the challenged of navigation system design. It begins with the hierarchy. As the primary navigation System, the hierarchy influences all other decisions. The choice of major categories at the highest levels of the website will determine design of the global navigation system. Based on the hierarchy, you will be able select key pages or types of pages that should be accessible from every other page on the web site in turn, the global navigation system will determine design of the local and then ad hoc navigation systems. At each level of granularity. You design of the higher order navigation system will influence decision at the next level. Once you have designed the integrated navigation system, you can consider the addition of on or more remote navigation elements. In most cases, you will need to choose between a table of contents, an index, and a sitemap. Is the hierarchy strong and clear? Then perhaps a table of contents makes sense. Does the hierarchy get in the way? Then you might consider an index. Does the information lend it self
$H@nU $iddiQue

to visualization? If so, a sitemap may be appropriate. Is there a need to help new or prospective users to understand what they can do with site? Then you might add a guided tour. If the site is large and complex, you can employ two or more of these elements. A table of contents and an index can serve different users with varying needs. However, you must consider the potential user confusion caused by multiple options and the additional overhead required to design and maintain these navigation elements. As always, its a delicate balancing act. If life on the high wire unnerves you be sure to build some usability testing into the navigation system design process. Only by learning from users can you design and reline an elegant navigation system that really works.

DESIGNING Searching INTERFACE FOR WEBSITE Systems!

Need of searching systems 1).As the amount of information on the website increases it become difficult to find the required information. If the navigation systems are not properly designed and maintained then to find the required information searching systems are required. 2).If your site has enough contents and users come to your site to look for information then site need searching systems.

3).Search system should be there on your site if it contains highly dynamic contents e.g. web based newspaper. 4).A search system could help by automatically indexing the contents of a site once or many times per day. Automating this process ensures that users have quality access to your website's contents. Searching your website Assuming you have decided to implement a Searching system for your website. Its important to understand how users really search before designing it. Users have different kinds of information need: Information scientists and librarians have been studying users information finding habits decades. Many studies indicated that users of information systems are not members of a singe minded monolithic audience who want the same kind of information delivered information the same ways. Some want just a little while other wants detailed assessment of everything there is to know about .the topic. Some want only the accurate, highest quality information; while others do not care much about the reliability of source. Some will wait for results while others need the information yesterday. Some are just plan happy to get any information at all, regardless of how much relevant stuff are really missing. Users needs and expectation vary widely and so the information systems that them must recognize, distinguish and accommodate these different needs. To illustrate let's look at one of these factors in greater detail: The variability information users searching expectations.
$H@nU $iddiQue

Known item searching Some users information needs are clearly defined and have a single correct answer. When you check the newspaper to see how your stock information amalgamated shoelace and aglet is 'doing (especially since the hostile Microsoft takeover attempts), you know exactly what you want that the information exists and where it can be found. Existence searching However some users know what they want but do not know how to describe it or weather the answer exists at all e.g., you must want to buy shares information Moldovan high start-ups and that carries no load. You are convinced that this sector is up and coming, but do fidelity and Merrill lynch know this as well'. You might check their Webster, call a broker or two, or ask your in the know aunt. Rather then a clear question for which a right answer exists, you have an abstract idea on concept, and you dont know whether matching information exists. The success of yours search depends as much upon the abilities of the brokers, the websites, and your aunt to understand your idea and its contexts as whether the information (information in this case a particular mutual fund) exists. Exploratory searching Some users know how to phrase their question, but don't know exactly what they are hoping to find and are really just exploring and trying to learn more. lf you ever considered changing careers you know what we mean you are not sure that you definitely what to switch to chinchilla farming, but you have heard it is the place to be, so you might informally ask a friend of a friend who an uncle in the business. Or you call the public library to see if there's a book on the subject, or you write to the chinchilla professionals association requesting more information. In any case, you are not sure exactly what you will uncover, but you are re willing to take the time to learn more. Like existence searching, you have so much a question seeking answer as much as an idea that you want to learn more about. Comprehensive Searching (Research) Some users want everything available on a given topic. Scientific researchers, patent lawyers, doctoral students trying to find unique and original dissertation topics, and fans of any sort fit in to this category. For example if you idolize that late great music duo Milli Vanilli, you'll want to see everything that has anything to do with them Single and records, bootlegs, concert tour plasters, music videos, fan club information, paraphernalia, interviews, books, scholarly articles, and records burning schedules. Even casual mentions of the band, such as someone's incoherent ramblings information a web page or Usenet newsgroup, are fair game if you're seeking all there is to know about Milli Vanilla so you might turn to all sorts of information sources for help friends, the library, books stores, music stores, radio call in shows and so on There are many other ways of classifying information needs. But the important thing remember is that not all users are looking for the same thing. Ideally, you should anticipate the most common types of needs that your site's users will have and ensure that these needs are met minimally; you should give some thoughts to the variations and try to design a search interface that is flexible in responding to them.

$H@nU $iddiQue

Designing the Search Interface!

Concept of Searching system There are two models of searching systems: 1).In the first and older model user express their information need as query that they enter in a search interface. They may do so using a specialized search language. 2).In the second model users express the information need information the natural language like English. After this step Queries are matched against an index that represent the site's content and a set of matching documents is identified.

Designing the Search Interface With so much variation among users to account for, there can be no single ideal search interface. Following factors affect choice of search interface: The levels of searching expertise users have: Are they comfortable with Boolean operators. Or do they prefer natural language? Do they need simple or high powered interface? What about a help page? The kind of information the user wants: Do they want just a taste or are they doing comprehensive research? Should the results be brief, or should they provide extensive detail for each document? The type of information being searched is it made up of structured fields or full texts? Is it navigation pages, destination pages, or both? HTML or other formats? How much information is being searched: will users be overwhelmed by the number of documents retrieved?

Support Different Modes of Searching Use the same interface to allow users to search the product catalog, or the staff directory, or other content areas. Are non-English speakers important to your site? Then provide them with search interfaces in their native languages. Including language specific directions, search commands and operators, and help information. Does your site need to satisfy users with different levels of sophistication with online searching? Then consider making available both a basic search interface and an advanced one. Simple / Basic search interface A simple search interface was required; because at limes users wouldn't need all the firepower of an advanced search interface. Especially when conducting simple known item searches. A simple search
$H@nU $iddiQue

box is ideal for the novice or for a user with a pretty good sense of what he or she is looking for. Mammal filtering options are provided including searching for keywords within little and abstract fields, searching within the author field or searching within the publication number field. These filtering options provide the user with more power by allowing more specific searching. But because the labels keyword, Author, And publication Number are fairly self explanatory. They don't force the user to think too much about these options. Advanced search Interface We needed interface that would accommodate this important expert audience who were used to complex Boolean and proximity operators and who where already very used to the arcane search languages of other commercial information services. This interface supports the following types of searching: Fielded Searching Author, keyword, Title, Subject and ten other fields are reachable. A researcher could, for example find a dissertation related to his or her area of interest by searching the subject field, and learn who that doctoral student's advisor was by reading the abstract. To find other related dissertations, the researcher could then search the advisor field to learn about other doctoral students who shared the same advisor.

Familiar Query Language Because many different query language conventions are supported by traditional on line products, users may be used to an established convention. The effort to support these users is made by allowing variant terms. For the field Degree Date the user can enter either ddt, ''da'', ''date'', ''Yr '' or year. Longer Queries More complex queries often require more space than the single line entry box found in the simple search interface. The more complex interface supports a much longer query. Reusable Result Sets Many traditional online information products allow searchers to build sets of results that can be reused. In this example, we've ANDed together the two sets that we've already found and could in turn combine this result with other sets during the iterative process of searching. Because this advanced interface supports so many different types of searching we provided a substantial help page to assist users. For users of common browsers, the help page is launched if a separate browser window so that users don't need to exit the search interface to get help.

$H@nU $iddiQue

Searching and browsing systems should be closely integrated As we mentioned earlier, users typically need to switch back and forth between searching and browsing. In fact users often don't know if they need to search or browse in the first place. Therefore, these respective systems shouldn't live in isolation from one another. The search/browse approach can be extended by making search and browse options available on the search result page as well, especially on null results pages when a user might be at a dead end and needs to be gently led back to the process of iterative searching and browsing before frustration sets in. Searching should conform to the site's Look and feel Search engine interfaces and more importantly, retrieval results, should look and behave like the rest of your site. Search Options Should Be Clear We all pay lip service to the need for user documentation, but with searching it's really a must Because, so many different variables are involved with searching there are many opportunities for things to go wrong on a help or Documentation page consider letting the user know the fallowing: What is being searched? Users often assume that their search query is being run against the full test of every page in your site Instead your site may support fielded searching or another type of selective searching. If they're curious users should be able to find out exactly what they are searching.

How they can formulate search queries What good is it to build in advanced querying capabilities if the user never knows about them? Shows off the power of your search engine with excellent real life examples. In other words make sure your examples actually work and retrieve relevant documents if the user decides to test them. User options Can the user do other neat things much as changing the sorting order of retrieval results? Show them off as well! What to do if the user cant find the right information It is important to provide the user with some tricks to handle the following three situations:

I'm getting too much stuff I'm not getting anything I'm getting the wrong stuff

$H@nU $iddiQue

For case (a), you might suggest approaches that narrow the retrieval results. For example if your system suppers the Boolean operator AND, suggest that users combine multiple search terms with an AND between them (ANDing together terms reduces retrieval size). If they are retrieving zero 'results as in case (b), suggest the operator OR the use of multiple search terms the use of truncation (which wife retrieve a term's use o variants), and so on. If they are completely dissatisfied with their searches, case(c), you might suggest that they contact someone who knows the sites content directly for custom assistance, it may be a resource intensive approach, but its a far superior last resort to ditching the user without helping them at all.

Choose a search Engine That Fits Users' Needs At this point, you ideally will know something about the sorts of searching capabilities that your sites users will require. So select a search engine that satisfies those needs as much as possible for example, if you know that your sites users already very familiar with a particular way of specifying a query such as the use of operators, then the search engine you choose should also support using Boolean operators. Does the size of your site suggest that users will get huge retrieval results? Be sure that your engine be supports techniques for whittling down retrieval sizes, such as the AND & NOT operators , or that it supports relevance ranked results that list the most relevant results at the top will users have a problem with findings the right terms to use in their search queries?

Display search Results sensibly You can configure how your search engine displays search results information many ways. How you configure your search engine results depends on two factors. The first factor is the degree of structure your content has. What will your search engine be able to display besides just the titles of retrieved documents? Is your site's content sufficiently structured so that the engine can parse out and display such information as an author, a date an abstract, and so on? The other factor is what your site's users really want. What sorts of information do they need and expect to be provided as they review search results? When you are configuring the way your search engine displays results you should consider these issues: 1) How much information should be displayed for each retrieved document? To display less information per result when you anticipate large result sets. This will shorten the length of the results page making it easier to read. To display less information to users who know what they're looking for, and more information to users who aren't sure what they want.

$H@nU $iddiQue

2).What Information should be displayed for each retrieved document? Which fields you show for each document obviously depends on which fields are available in each document, what your engine displays also depends on how the content is to be used. Users of phone directories for example want phone numbers first and foremost. So it makes sense to show them the information from the phone number field on the results page. Lastly, the amount of space available on a page is limited: You can't have each field displayed, so you should choose carefully and use the space that is available wisely. 3).How many retrieved documents should be displayed? How many documents are displayed depends on the preceding two factors: If your engine displays a lot of Information for each retrieved document, you'll want to consider a smaller size for the retrieval set, and vice versa. Additionally the user's monitor resolution and browser settings will affects the amount of information that can be displayed individually. 4).How should retrieved document be sorted? Common options or sorting retrieval results include:

In chronological order. Alphabetically by title, author, or other fiends. By an odd thing called relevance.

Certainly, if your site is providing access to press releases or other news- oriented information, sorting by reverse chronological order makes good sense. Chronological order is less common, and can be useful for presenting historical data. Alphabetical sorts are a good general purpose sorting approach (most users are familiar with the order of the alphabet). Alphabetical sorting works best if initial articles such as a and the are omitted from the sort order (certain search engines provide this option). Relevance is an interesting concept; when a search engine retrieves 2000 documents, is not it great to have them sorted with the most relevant at the top, and the least relevant at the bottom? Relevance ranking algorithms are typically determined by some combination of the following; how many of the query's terms occur in the retrieved document; how many times terms occur in that document; how close to each other those terms occur and where the terms occur.

Always provide the user with feedback When a user executes a search, he or she expects result. Usually a query with retrieves at least one document, so the user's expectation is fulfilled. But sometimes a search retrieves zero results. Let the user know by creating a different results page especially for these cases. This page should make it painfully clear that nothing was retrieved, and give an explation as to why, tips for improving retrieval results and links to both the help area and to a new search interface so the user can try again.
$H@nU $iddiQue

Other Considerations You might also consider including a few easy to implement but very useful things in your engine's search results: Repeat back the original search query prominently on the results Page As users browse through search results, they may forget what they searched for in the first place remind them. Also include the query in the page titles; this will make it easier for users to find it in their browser's history lists. Let the user know how many document in total were retrieved. Users want to know how many documents have been retrieved before they begin reviewing the results. Let them know: if the number is too large, they should have the option to refine their search. Let the user know where he or she is in the current retrieved set. It's helpful to let users know that they're viewing documents 31-40 of the 83 total that they've retrieved.

Always make it easy for the user to revise a search or sort a new One. Give them these options on every results page and display the current search query on the revise search page so they can modify it without reentering it.

Conceptual design !
Blueprints What do you mean by blueprint? Blueprints are the architects tool of choice for performing the transformation for chaos in to order. Blueprints show the relationship between pages and other content components and can be used to portray organization, navigation and labeling systems. They are often referred to as sitemaps and do in fact have much information common with those supplemental navigation systems. Both the diagram and the navigation system display the shape of the information space information overview, functioning as a condensed map for site developers and users, respectively High -level Architecture blueprints High level architecture blueprints are often created by information architects as pat of a top down information architecture process. The very act shaping ideas in to the more structure of a blueprint forces you to become realistic and practical. During the design phase, high level blueprints are most useful for
$H@nU $iddiQue

exploring primary organization schemes and approaches. High level blueprints map out the organization and labeling of major areas. Usually beginning with a bird's eye view from the main page of the website. Creating High -Level Architecture Blue prints These blueprints can be created by hand, but diagramming software such as Visio or OmniGraffle are preferred. These tools not only help to quickly layout the architecture Blue prints, but can also help with site implementation and administration. Some Important points: 1).Blueprints focus on major areas and structure of site ignoring many navigation details and page level details. 2).Blueprints are excellent tools for explaining your architectural approaches. 3).Presenting blueprints information person allows you to immediately answer the questions and address client concerns as well as to explore new ideas while they are fresh in your mind and the client's. 4).As you create blueprint it is important to avoid getting locked into a particular type of layout. 5).If a meeting isn't possible, you can accompany blueprints with descriptive test based documents that anticipate and answer the most likely documents.

Keeping Blueprints Simple As a project moves from strategy to design to implementation, blueprints become more utilitarian. They need be produced and modified quickly and often draw input front increasing number of perspectives, ranging from visual designers to editors to programmers. Those team members need to be able to understand the architecture. So its important to develop a simple condensed vocabulary of objects that can explain in a brief legend

Architectural Page Mockups!

Information architecture blueprints are most useful for presenting a birds eye view of the web site. However they to not work well for helping people to envision the contents of any particular page. They are also not straightforward enough for most graphic designers to work from. In Fact no single format perfect job of conveying all aspects of information architecture to all audiences. Because information architectures are multi dimensional, it's important to show them information multiple ways. For these reasons Architectural page mockup are useful tools during conceptual design for complimenting the blueprint view of the site mockups are quick and dirty textual documents that show the content and links of major pages on the website. They enable you to clearly (yet inexpensively) communicate the
$H@nU $iddiQue

implications of the architecture at the page level. They are also extremely useful when used in conjunction with scenarios. They help people to see the site in action before any code is written. Finally, they can be employed in some basic usability tests to see if users actually follow the scenarios as you expect. Keep in mind that you only need to mockup major pages of the web site. These mockups and the designs that derive from them can serve as templates for design of subsidiary pages. The mockups are easier to read than blueprints. By integrating aspects of the organizational labeling, and navigation systems in to one view they will help your colleagues to understand the architecture. In laying out the content on a page mockup, you should try to show the logical visual grouping of content items. Placing a content group at the top of the page or using a larger font size indicates the relative importance of that content. While the graphic designer will make the final and more detailed layout decisions you can make a good start with these mockups.

Design Sketches!
Once you've evolved high-level blueprints and architectural page mockups, you're ready to collaborate with your graphic designer to create deign sketches on paper of major pages in the web site. In the research phase the design team has begun to develop a sense of the desired graphic identity or look and feel. The technical team has assessed the information technology infrastructure of the organization and the platform limitations of the intended audiences. They understand what's possible with respect to features such as dynamic content management and interactivity. And of course the architect has designed the high-level information structure for the site. Design sketches are a great way to pool the collective knowledge of these three teams in a first attempt at interface design for the top level pages of the site. This in a wonderful opportunity for interdisciplinary user interface design using the architectural mocks ups as a guide; the designer begins sketching pates of the site on sheets of paper. As the designer sketches each page questions arise that must be discussed. Here is a sample sketching session dialog: Programmer: I like what you're doing with the layout of the main page, but I'd like to do something more interesting with the navigation system. Designer: Can we implement the navigation system using pull down menus? Does that make sense architecturally? Architect: That might work but it would be difficult to show context in the hierarchy. How about a tear|way table of contents feature? We've had pretty good reactions to that type of approach front users in the past. Programmer: We can certainly go with that approach from a purely technical perspective. How would a tear away table of contents look? Can you sketch it for us? I'd like to do a quick and dirty prototype. These sketches allow rapid iteration and intense collaboration.

$H@nU $iddiQue