designing for the web: a survey · 2005-08-29 · the web designers do not really need to know...

13i n t e r a c t i o n s . . . m a y + j u n e 1 9 9 8

PA W AN R . VORA design/methods & tools

AA majority of the surveys on the Web, for example, the surveys conducted by Georgia

Tech’s Graphics, Visualization, & Usability (GVU) Center [2]; Nielsen Media Research [6];

and Nua [7], have focused on understanding the profile of the users of the Internet and

the Web. As it is important to understand how users interact (i.e., read and navigate) with

Web pages in order to design usable Web pages, it is also important to understand how

Web authors (or designers) design Web pages in order to design usable Web page

development tools.

Designing for the Web: A Survey

Although the 8th GVU survey did have asection for the Web authors, the emphasis wason discovering respondents’ backgrounds,development experience, use of Java™, andother information related to Web develop-ment. The focus of this survey, on the otherhand, is on understanding the process ofdesigning and developing Web pages and tounderstand better how Web developers designWeb pages. Specifically, the survey wasdesigned to achieve the following objectives:✱ Construct Web designer profile. Who are

typical Web designers? What kind of pro-fessional training do they have? Howmuch experience do they have designingWeb pages? What types of pages do theydesign?

✱ Identify the key components of the Webdesigner’s “toolkit.” What kinds of Webdevelopment tools do they use? What dothey like or dislike about them and why?

✱ Understand the Web development envi-ronment. How much time does it take todevelop Web pages? How many pages aredeveloped in that time frame? Do Webdesigners work in teams? How manypeople participate in these teams? Do thetime available and number of people inthe team affect their selection of tools?

✱ Outline the design process. Do Webdesigners use style guides/design guide-lines when developing Web pages? Do

14

they consider bandwidth and accessibilityissues when designing Web pages? Howdo they evaluate the Web page designs forusability? How do they publish Web pagesto the Web server?

MethodologySurvey participants were solicited as follows: ✖ Announcements on newsgroups:

comp.human-factors and alt.hypertext.✖ Announcements made to the mailing lists:

UTEST, World Wide Web ArtistsConsortium, WebHCI, HumanFactors/Web conference participants,Webgrrls (Chicago Chapter),WebWomen, and Web Design.One hundred and thirty-eight people

responded to the survey over a 4-week periodfrom December 17, 1997, to January 15,1998. Like other surveys on the Internet,these respondents were self-selected, and theyresponded to the survey via❥ E-mail because the survey was included in

the solicitation message.❥ The Web (the survey was made available

at the ACM SIGCHI’s Web site; URL:http://www.acm.org/sigchi/web/survey/index.html).

❥ Postal mail.

Survey ResultsThe survey results are organized in the fol-

The May/June Design

and Methods & Tools

columns have been

combined into one as a

result of a collaboration

between the editors for

each column.

i n t e r a c t i o n s . . . m a y + j u n e 1 9 9 8

and “to help friends, family, and non-profitorganizations.” Other reasons for designingWeb pages included education, communi-cation, community building, artisticendeavors, and to make money (or toengage in a profitable activity).

Web page design experienceInterestingly, a majority of the surveyrespondents (96 of 138) had more than 2years of experience (see Figure 3), suggestinga bias toward the “expert” category of Webdevelopers. However, because the surveydidn’t ask the respondents to give an esti-mate of the number of Web pages they havedesigned or the number of Web pages they

i n t e r a c t i o n s . . . m a y + j u n e 1 9 9 8 15

lowing sections: Web Designer Profile,Authoring Tools, Web DevelopmentEnvironment, Web Page Design &Evaluation, Publishing Web Pages, andOverall Comments.

Web Designer Profile

Professional backgroundThe responses indicated that there is noprototypical professional background for aWeb designer (see Figure 1). They comefrom a variety of professional backgrounds,such as computer programming, graphicdesign, human factors, marketing/adver-tising, user interface design, and technicalwriting, and often have additional training incognitive psychology, multimedia, and educa-tion. A relatively high number of responsesfrom people with professional backgrounds inuser interface design, graphic design, andhuman factors, however, were expectedbecause these professions are well representedin the newsgroups and mailing lists fromwhich the responses were solicited.

Reasons for designing Web pagesThere was no single, dominant reason forthese individuals to be authoring Web pages(see Figure 2). “Primary job responsibility”was cited as often as “one of the several tasksrequired by job,” “hobby/personal interest,”

design in a month, it is difficult to discern their“expertise” in the area of Web page design truly.

Principal audienceWhen asked to identify principal audiences

16 i n t e r a c t i o n s . . . m a y + j u n e 1 9 9 8

for Web pages they designed, authors’responses were overwhelmingly focused oncorporate sites for customers and vendors orfor personal use by the author (see Figure 4).

Types of Web pages designedFinally, the types of Web pagesdesigned by author respon-dents are shown in Figure 5.Given that a majority of Webpages were designed for corpo-rations and personal use(Figure 4), the most commonWeb page types werework/organization informa-tion, product/service informa-tion, and personal homepages. A small percentage ofpages designed was researchpapers/reports (6.5%), whichare more likely to be for edu-cational institutions.

17

Web page editors/generatorsThere are several ways Web designers createand generate Web pages. They often use oneor more of the following (see Figure 6):✖ Text editors. Because HTML files are

ASCII text files, text editors offer themost basic way to design the Web pages.

Authoring ToolsThis section addresses the types of authoringtools used. It is divided into four subsections:Web page editors/generators, HTML(HyperText Markup Language) conversiontools, PDF (Portable Document Format) con-version tools, and graphic design tools.

i n t e r a c t i o n s . . . m a y + j u n e 1 9 9 8

a b

c d

e

Figure 6. Web Page Authoring Tools

(a) Text editor (Simple Text-back; Microsoft NotePad-front)

(b) HTML Editor (Bare Bones Software’s BBEdit-back;

Allaire’s HomeSite 3.0-front)

(c) WYSIWYG Editor (Macromedia DreamWeaver-back;

Claris HomePage 2.0-front)

(d) Site-oriented Editor (NetObjects Fusion)

(e) Database-based Editor (Vignette StoryServer)

They do not, however, offer any assistanceto Web designers, and it is the responsi-bility of the Web designers to remember,write, and debug the HTML code theydevelop. Examples of text editors areNotePad, WordPad, SimpleText, and vi.

✖ HTML editors. HTML editors supportweb designers in writing HTML tagsusing menus, toolbars, and keyboardshortcuts. They do not, however, write orhide the HTML tags from Web designers;Web designers work directly with rawHTML tags. Many HTML editors alsooffer additional functionality such asHTML validation, link verification,spellchecker, and customized menus.Examples of HTML editors are Allaire’sHomeSite, Bare Bones Software’s BBEdit,and Sausage Software’s HotDogProfessional.

✖ WYSIWYG (“What You See Is What YouGet”) editors. WYSIWYG editors worklike word-processing or desktop pub-lishing programs, allowing authors to layout pages as they want, and the editorswrite the necessary HTML code in thebackground. The Web designers do notreally need to know HTML. Examples ofWYSIWYG editors are Adobe PageMill,Claris HomePage, Symantec’s Visual Page,Microsoft FrontPage, and MacromediaDreamweaver.

✖ Site-based editors. Unlike the Web pagedevelopment tools discussed so far, whichare page-oriented, site-based editors such

as NetObjects Fusion and GoLive’sCyberStudio allow the Web designers toadd and rearrange pages in a tree-struc-tured site diagram. The navigation barsand links for the Web site are automati-cally generated for them. Site-based edi-tors also allow rapid changing of theoverall look of a site.

✖ Database-generated Web sites. Many largeWeb sites do not build each page manu-ally. They hold the web page elements(text, graphics, headers, footers, etc.) intoa database and automatically generatepages by retrieving and combining theelements as the Web browsers requestthem. Examples of database-oriented Webpage–generation tools are VignetteCorporation’s Vignette and Lotus Notes(with Domino Web server).The survey asked respondents to identify

the type(s) of Web page editors/generatorsthey had used, to identify specific productsused, and to rate, on a scale from 1 to 7 (1 =low and 7 = high), those products in terms ofsatisfaction, learning, ease of use, function-ality, and extensibility. A summary of theirresponses is shown in Table 1.

The majority of respondents (104) usedbasic text editors to design Web pages. Themost frequently reported text editors wereNotepad (42), SimpleText (17), WordPad(14), vi (11), and BBEdit Lite (8). HTMLeditors ranked second as the authoring tool ofchoice; 89 respondents reported using them.The most common HTML editors were Bare


Pawan R. Vora

U S WEST

Communications

931-14th Street,

Suite 710

Denver, CO 80241, USA

1+303-685-2023

[email protected]

Table 1. Evaluation of Web Page Development Tools (Response Scale: 1 = Low; 7 = High)

Text HTML WYSIWYG Site Database

Number ofResponses 104 89 74 29 19

Satisfaction 4.76 (1.70) 5.93 (1.06) 4.70 (1.59) 4.79 (1.45) 4.83 (1.38)

Ease of Learning 5.41 (1.91) 5.48 (1.21) 5.19 (1.45) 4.38 (1.47) 3.78 (1.80)

Ease of Use 5.40 (1.68) 5.75 (1.13) 5.20 (1.37) 4.79 (1.35) 4.06 (1.73)

Functionality 4.21 (1.82) 5.67 (1.35) 4.49 (1.57) 4.72 (1.62) 5.44 (1.72)

Extensibility 3.60 (1.95) 5.57 (1.52) 4.07 (1.66) 4.24 (1.88) 5.53 (1.23)

Bones Software’s BBEdit (38) and Allaire’sHomeSite (22). Of the 74 respondents whoreported using WYSIWYG editors, the mostcommonly named were Microsoft’s FrontPage(27), Netscape Gold/Composer (15), AdobePageMill (10), and Macromedia Dream-weaver (10). For site editors, Microsoft’sFrontPage (11) was the leader over Net-Objects Fusion (8). Finally, for database-basedWeb page–generation tool, the frequentlyused were Lotus Notes/Domino (6) and ColdFusion (4).

By examining Table 1, it is obvious thatrespondents were quite satisfied with HTMLeditors, ranking them higher with respect tofunctionality, ease of learning, and ease of usethan the other methods of creating Webpages. WYSIWYG editors probably generatedthe majority of the “negative” commentswhere their usability and effectiveness wereconcerned. Some of the comments were:

Most “WYSIWYG” editors insert too muchextraneous code for my taste.Most tools don’t support all of the currentHTML tags & keywords—most have prop-erty boxes or dialogs, but you have to use theHTML view to edit the code directly to getanything non-trivial done.Prefer writing code directly rather than using“WYSIWYG” tools because these allow morecontrol of the HTML code and do not add“redundant” code.I don’t use it [FrontPage] anymore, because itis too inflexible/automatic for my needs; e.g.it puts in tags that I don’t want, or takes outones I need, requiring lots of post-editing.The WYSIWYG HTML editors that I haveused are useless, and don’t do all the thingsthat HTML can do.From respondents’ comments, it was clear

that their annoyances stem from the one ormore of the following characteristics ofWYSIWYG authoring tools:✦ Generation of excessively redundant code.✦ Overriding (not respecting) author’s

HTML code, requiring author to useanother editor to finish the work.

✦ Not allowing authors to see and/or editthe HTML code.

✦ Not supporting all HTML tags.

The basic premise of WYSIWYGauthoring tools is that the Web designer neednot know any HTML. They often do not,however, support all the HTML tags and/ordo not allow authors to write their ownHTML code. When they do allow authors toedit the raw HTML code, the authoring toolsoften override the HTML code written by theWeb designers. Web designers, however, needbetter control over their code. This is how onerespondent commented:

Web Authoring and Web Designing toolsshould allow maximum freedom to thedesigner. I think this is the reason whyHomesite and BBEdit were successful becausethey allow maximum flexibility to the user. Ithink this is also the reason why NetObjectsFusion is doomed because the designer istrapped to the confines of the program’s rigidstructure.This doesn’t mean, however, that all Web

authors want to write HTML. It’s just thattoday’s Web authoring tools do not do a goodjob in delivering what an author needs. This isevidenced in the following comments:

As a designer, I have little interest or talent inwriting code, so I depend on a goodWYSYWIG editor like NetObjects orFrontPage to help with that aspect.Unfortunately, to date there has been noeditor that is as clean, efficient, or as versatile,as hand-coded HTML.I don’t mind doing it, but I think mostdesigners shouldn’t have to learn coding to docool things on the Web.Interestingly, WYSIWYG tools are used by

some authors to design simple pages instead oftheir proposed use for designing complexpages. As one respondent commented, “Webtools OK for simple pages, often easier, butprefer text editor for anything more complex.”

The exception was Macromedia Dream-weaver, a recent entrant into the market ofWYSIWYG authoring tools. It received sev-eral praises. Obviously, the main source ofpraise was that Dreamweaver does not over-ride the author’s HTML code and lets theWeb author use an HTML editor of choice.As one respondent indicated, “This tool givesthe user the ease of a WYSIWYG, but the

DESIGN COLUMN EDITOR

Kate Ehrlich

Senior Research

Manager

Lotus Development

Corporation

55 Cambridge Parkway

Cambridge, MA 02142

+1-617-693-1899

fax: +1-617-693-8383

[email protected]

METHODS & TOOLS

COLUMN EDITORS

Michael Muller

[email protected]

Finn Kensing

Computer Science

Roskilde University

P.O. Box 260

DK-4000 Roskilde

Denmark

+45-4675-7781-2548

fax: +45-4675-4201

[email protected]

i n t e r a c t i o n s . . . m a y + j u n e 1 9 9 8 19

control of BBEdit.”

HTML conversion toolsFifty-four respondents reported using HTMLconversion tools; their ratings are summarizedin Figure 7. The most commonly used con-version tools were Microsoft’s InternetAssistants (for Word, Excel, and PowerPoint)and Office ‘97.

Overall satisfaction with HTML conver-sion tools was fairly low (mean, 4.17; standarddeviation, 1.75), despite their being consid-ered fairly easy to learn (mean, 5.19; standarddeviation, 1.51). The main reason cited forlow satisfaction was that conversion tools,such as WYSIWYG editors, generate consid-erable redundant HTML code during theconversion. This makes the file sizes larger andthe HTML code difficult to read. In addition,it is cumbersome to change the “converted”HTML documents manually and “risky” totry and make global changes across severaldocuments at the same time.

The reason for the low value for “extensi-bility” for HTML conversion tools (Figure 7)is obvious when you consider that a majorityof respondents used Internet assistants forMicrosoft Word, Excel, and PowerPoint forconverting the documents to HTML. Thesetools convert only the documents createdusing Microsoft Word, Excel, andPowerPoint, respectively. Of course, one canalways import the documents created by other

business productivity suites in one of theMicrosoft Office products and then convertthem to HTML.

PDF toolsApproximately 25% of the respondents (34)reported creating PDF documents on theWeb. A majority of users reported usingAcrobat Exchange (14) and Adobe Distiller(8). Several people also reported using thefunctionality available in PageMaker andFrameMaker to save files directly as PDF doc-uments. Overall, most users seemed satisfiedwith the products they were using to convertdocuments to PDF (see Figure 8).

Using a combination of tools to developWeb pagesA majority of users reported that they “always”(51.4%) or “sometimes” (31.9%) used a com-bination of tools (see Figure 9).

The combination of tools used invariablyconsisted of one or more of the HTML edi-tors and graphics tools. The most commonwas a WYSIWYG editor along with a texteditor or an HTML editor. A text editor or atext-based HTML editor was seen as necessaryin order to “clean up” the code created byWYSIWYG editors. Specific reasons for usinga combination of tools are as follows: ✦ To clean up the code generated by

WYSIWYG editors or HTML conversiontools. This comment probably summarizes

the most cir-cuitous route:“For text orientedsites, I usually useInternet Assistantfor Word to con-vert text toHTML, then Iuse BBEdit tostrip out all thejunky formattingthat Word causes.Then I useDreamWeaver toformat with StyleSheets, and fine-tune the design.”



Another commentalso provides thenecessary evidence:“Pagemill is greatfor quick pages . . .but it writes sloppycode and unless youuse SimpleText orBBEdit are you ableto really program orclean code up.”

✦ To support differ-ences in the devel-opment platformand productionplatform. As onerespondent described,“I start in VisualPage on the Macbecause it’s easiest, then tweak it in atext editor and bring it over to myUNIX box. If I then need to update itfrequently, like the Weekly Seminarschedule, I update it in Composer,because it runs on UNIX and I don’thave to move the files around.”

✦ To take advantage of special featuresoffered by some tools. Several Webdesign tools offer functionality beyondcreation of Web pages, for example,spellchecker, link verifier, HTML validator,and site manager. Web page designers oftenuse additional tools just to take advantageof such specialized functionality, especiallywhen they are not integrated or poorlyimplemented in their otherwise preferreddevelopment tool of choice. One reason fordoing so is Web site management: “Oftenthe client wants to manage/add to the sitethemselves, so things are often designed inBBEdit, and then imported into FrontPagefor the ‘link management’.”

✦ To create graphics. Although WYSIWYGWeb page design tools support conversionof graphics to a Web-ready format, theygenerally do not provide sophisticatedtools for creation of graphics. Mostdesigners use dedicated graphics softwareto create the graphics and point to themwhen designing the Web pages.

✦ To handle multimedia components in a

document. Because most Web page devel-opment tools do not support creation ofmultimedia components (audio, video,animation, etc.), separate developmenttools are required for their creation.The question, of course, is this: Should

there be a tool that allows people to do all theyneed to do to develop Web pages? Maybe not!As a few respondents pointed out the relevantconcerns:

In this era, serious work in almost any soft-ware endeavor requires appropriate tools.Relying on one tool to do everything isnow the mark of (a) a trivial task or (b) anamateur. [B]ecause there is no one tool that does it all,and if there was [I] probably wouldn’t use itbecause [I] am generally not impressed withsoftware that has a bazillion functions.

Designing graphicsA majority of respondents “always” (44.2%) or


“sometimes” (48.6%) designed graphics whenthey design Web pages (see Figures 10 and 11).The most commonly reported product fordeveloping graphics was Adobe PhotoShop(90 respondents reported to using it.)Interestingly, despite it being noted as rela-tively difficult to learn (mean, 4.35; standarddeviation, 1.55), the satisfaction with AdobePhotoShop was fairly high (mean, 6.34; stan-dard deviation, 0.73). Other commonly usedgraphic design products were Adobe Illustrator(21), PaintShop Pro (7), and Debabelizer (6).

Web Development EnvironmentThere were three questions related to the Webdevelopment environment:1. What is the average time to develop a set

of Web pages?2. How many Web pages are designed in this

duration?3. On average, how many people participate

in Web development (including yourself )?

The purpose of these ques-tions was to determine ifresponses to them have anyrelation to the Web develop-ment tools used, use of an in-house Web design style guide,use of and the type of usabilityevaluation methods used, andother Web design and develop-ment variables.

As pointed out by severalrespondents, how-ever, these questionswere ambiguous andineffective in cap-turing useful infor-mation. Here aresome of their reac-tions:

[D]umb question,it depends on if Ihave to do content,and how manygraphics they want.Also what is a set?It depends on ifthere are a lot [sic]of links.

How long is a piece of string?! It depends onthe project, who’s doing the work, [and] whatthey want. . . . We recently redesign-ed our 11 top welcome and contents pages.This project took over a year from design toimplementation. I did an entire web site of11 pages for a health centre in 3 days.[D]on’t think it’s possible to answer this. It’svery dependent on what I’m developing,number and type of graphics, whether I’m cre-ating content or using stuff that’s already beenwritten, etc. . . . I’m not sure what you meanby participate. . . . I tend to do most of thecoding, but get other people to help withdesign, testing, content-generation, etc.The ambiguity in our questions is obvious

from the previous comments. Despite theambiguities, most people did respond to thequestions, and their responses are summarizedin Figures 12, 13, and 14. The responses canbe summarized as follows:✱ A majority of Web development projects


are less than 3 months withmany of them less than amonth.

✱ About 50 or fewer pages aredeveloped in this timeperiod.

✱ Most Web developmentteams have fewer than fivepeople on their team.Because of the potential mis-

understanding and corre-sponding low reliability of theresponses, however, I haverefrained from correlating thesewith the Web developmenttools used, usability testing per-formed, and other Web designvariables.

Design and Evaluation

Use of Web designguidelines/style guidesAlmost 90% of the respondentsreported using Web designguidelines and/or style guideswhen designing Web pages (seeFigure 15). Of these, about 38%used design style guides devel-oped in-house, and about 50%of them used design guidelinesavailable on the Web, as well asthose developed in-house.

Although this is encour-aging, one can only surmise theextent to which the design guidelinesare used in designing Web pages. Asimilar survey conducted by Mosierand Smith [5] for designing softwareapplications showed that although theuser interface design guidelines areconsidered generally useful, there aresignificant problems in the practicalapplication of guidelines. The mostfrequent problem for difficulty inapplying guidelines was that the guide-lines were too general and


were often not translated into specific designrules that developers can use.

Web design guidelines tend to be more spe-cific as they place emphasis on common lookand feel of the Web pages [3] and, therefore,easily implemented. For example,✘ Pages should be time stamped and dated.✘ Every page should have a title.✘ Provide WIDTH and HEIGHT

information for images.✘ Do not use “click here” or similar words

to designate a link.

Designing for faster downloadMost Web designers seemed aware of band-

width bottlenecks on the Web and the users’dislike about often long waits to downloadWeb pages; GVU’s 8th WWW User Surveyreported that 63% of the respondents wereunhappy with the speed at which Web pagesdownload [2].

Ninety-nine percent of the respondents inthis survey indicated that they always orsometimes design pages for faster download

(see Figure 16). But, as one respondentpointed out, often the clients drive the deci-sion: “[S]ome clients claim all their visitorswill be on T1’s, and thus they want mondo[sic] graphics and could care less about folkson modems.” Though designing bandwidth-heavy sites may seem justified in such situa-tions (for example, when designingintranets), I have noticed that many clientsoverlook the needs of telecommuters, whomay be using slower modems to access theWeb pages.

Designing for accessibilityThe responses to this question—Are designsoptimized to improve access to people withdisabilities?—were not very encouraging. Onethird of respondents has never consideredaccessibility when designing Web pages. Only16.7% of respondents have always designedWeb pages to improve access to people withdisabilities, and the remaining 50% of therespondents have “sometimes” optimized theirdesigns to improve accessibility (see Figure17). This is similar to what Daryle Gardner-Bonneau found when she conducted aninformal survey on UTEST (a listserver for


usability professionals) in late 1997 on Website accessibility [1]. She concluded that✦ Despite the simplicity of making Web

sites largely accessible to people with dis-abilities, very few were actually doing it.

✦ People really didn’t know much about thisproblem or the available solutions for it.Very few respondents answered Daryle’s

questions about whether and/or how theyensure that their web sites are accessible. Shecommented:

There’s a certain hypocrisy (or irony) in thefact that the professionals on this list—whichis devoted to usability—are largely ignoring asizable body of potential clients when devel-oping Web sites (at least commercial sites),especially when the solutions to accessibilityproblems are so simple, in most cases.Of course, Web designers may not

always be at fault. As one respondentpointed out,

We always use alt tags, all the easy stuff,but few clients are willing to pay foranything that’s extra work. . . . I thinkyour survey is ignoring the fact thatmost of us Web designers are customerdriven—i.e. I might want to do some-thing a certain way (like make pagesaccessible to folks with disabilities) butthe client doesn’t want to pay for that“extra” so it doesn’t happen. Also, evenwhen we want to do extensive usabilitytesting, clients always want the Website “yesterday” and don’t want to wait.Though the response rate

appears to be fairly good inthe current survey about theawareness of accessibilityissues, it is not obviouswhich design strategies Webpage authors adopt to designfor accessibility. Do theydesign a separate text-onlysite? Do they provide “ALT”text description for theimage or do they “D” tag theimages to link to a page thatcontains textual descriptionof the images? Do they avoiduse of frames, or are they

referring to some other design strategies? (Formore details on Web accessibility, see TraceResearch & Development Center Web site [8]and World Wide Web Consortium’s WebAccessibility Initiative (WAI) [9].) To under-stand the accessibility issues in more detail,especially to understand how people accom-modate special populations in their Web pagedesigns, a separate survey looking into theaccessibility issues is warranted.)

Usability evaluation of Web pagesWhen asked “Do you evaluate the Web pagesyou design for usability?” 70% of the respon-dents evaluated their Web pages for usability“all the time” or “almost all the time” (seeFigure 18). A majority of these usability evalu-


ations, however, are informal (conducted withcolleagues and people in the developmentteam) or user walk-throughs (see Figure 19).Other evaluation methods used by the respon-dents were user questionnaires and surveys,user feedback forms, remote usability testing,focus groups, and off-line testing (e.g., testingaccess speeds at 28.8 K modem, testing with avariety of browsers, and analysis of server logs).

What was encouraging was that almost halfof the respondents conduct usability testing ina controlled laboratory setup. Although sometesting is better than no testing, informaltesting does have limitation in that the user’sviewpoint is overlooked. As one respondentsaid, “Many people I work with evaluate theweb based on how ‘they’ surf; disregardinghow our typical viewer surfs.” And, mostpeople in the Web development teams are lesslikely to be typical users.

Such a highnumber of respon-dents conductingsome form ofusability tests areprobably expectedas a significantnumber of therespondents hadprofessional back-grounds in humanfactors, user inter-face design, tech-nical writing, and

marketing. Consequently, it is possible thatusability professionals, who are more likely tobe user-oriented, are overrepresented in thissurvey.

Publishing Web PagesThe final step in Web page development istransferring the Web pages to the Web server.There are three main ways to do this:1. FTP (File Transfer Protocol). By logging

into the FTP site of the Internet serviceprovider (whether internal or external)and transferring the files.

2. HTTP PUT. This method also requireslog-in, but the file transfer takes place byusing the Web’s Hypertext TransportProtocol (HTTP).

3. Directly copying the Web pages to theWeb server. As shown in Figure 20, the two most

common publishingmethods were FTP andcopying the files directly tothe server. It is not sur-prising that publishing viaHTTP was not thatcommon because fewauthoring tools support it;one reason is that currentlyit is not as secure as FTP,unless SSL (Secure SocketsLayer) is used along withHTTP.

The need for severalpeople in the Web devel-opment team to publish

the files to the server appears to be quitecommon; about 75% of the respondents haveencountered that situation either “always” or“sometimes” (see Figure 21). When severalpeople need to publish on the Web, appro-priate measures must be taken to ensure thatthe authors do not overwrite each other’s workor delete the files by mistake. Of course, withthe support of check-in/check-out of docu-ments in publishing tools, costly errors couldbe avoided. Very few Web development toolstoday support such functionality. To avoidsuch errors, team members could either handthe work to a Webmaster or a coordinator,


who can then publish theWeb pages directly to theWeb server. In almost 50% ofthe cases, however, directlycopying to the Web server isthe method of choice (seeFigure 22).

Overall Comments Offeredby the RespondentsRespondents’ commentsmade clear some of their dis-likes and annoyances whendesigning Web pages. Theircomments are summarized below.

Annoyances with WYSIWYG authoringtools

As mentioned before, most people were dis-appointed and/or frustrated with WYSIWYGauthoring tools. They tended to follow uptheir use of WYSIWYG tools with text editorsor text-based HTML editors to “clean up” theHTML code and/or to fine-tune the final lookand feel of the Web pages.

Inadequate attention paid to the audience’sneedsSeveral respondents felt that adequate attentionwas not paid to the needs of the actual users.

Far too little emphasis is placed on the designof information for the Web as it is perceivedby the target audience. . . . When too muchemphasis is placed on the technology, the sitebecomes a gadget trap for the user; similarly,when too much emphasis is placed on theartistic component, the site becomes some-thing lovely to look at but not a useful tool. Awell-researched navigational architecturebrings together the technical wizardry andexcellent, effective design to create a Web sitethat is intelligible to the user, easy to use, andas a result accomplishes its mission. This is anessential first step in the development ofexpansive and complex Web sites. (Note: theoriginal comment was in ALL CAPS.)Too many web designers fail to consider theirpotential users when designing their webpages. A good example of this designing webpages that takes remote access users (usersdialing in through a modem) several minutes

each page to download. This is as much of ausability problem, in my opinion, as poor sitemapping or outdated links.

Browser incompatibilities“Browser uniformity, browser uniformity,browser uniformity,” was a comment made byone respondent.

This was probably the most frequent com-plaint among Web designers. Designing Webpages that not just look good but work for allusers has become extremely difficult, if notimpossible. This is obvious when you considerthe use of proprietary technologies andincompatible support for HTML standardsamong different browsers. Several respondentsvoiced their complaints and frustrations aboutthese incompatibilities:

I’d like less divergence between browsers!I personally am sick of the disparate ways thatall the differing browsers “choose to interpret”HTML.The important thing is to be able to designonce, and know that it can run anywhere,and not have to change everything if the ISPchanges server platform on you, or if somecompany goes out of business.Get the browsers to agree on compatibilityissues.It seems that I spend most of my timeadjusting pages so they look even vaguely sim-ilar on a version 6.x Mac with Netscape andon a Windows95 PC running Explorer4. Ifthis were true for any other publishingindustry, the designers would have rebelledalready. MORE COMPATIBILITY!


Browser incompatibilities can make a Webdeveloper’s life from just a bit annoying tototally frustrating. The Web authors need toknow the differences in the browsers not onlyto design effective Web pages, but also to beable to make effective use of Web develop-ment tools. The authors now need to knowwhat features of a Web development tool mostbrowsers support before using them.Increasingly, Web development tools (espe-cially WYSIWYG tools) provide better sup-port for one browser over the other. Forexample, one could easily create a page withdynamic HTML using FrontPage ‘98. And,the page will work just fine when usingInternet Explorer 4.0 but will not work whenusing Netscape Navigator 4. The same is truewhen using Cascading Style Sheets (CSS),which is implemented better on InternetExplorer 4.0 than on Netscape Navigator.

Summary: Profile of a Web DesignerFrom the results, we can state the followingabout this survey’s prototypical Web designer:✖ He or she has typically more than 2 years

of experience designing Web pages. ✖ He or she designs pages mainly for corpo-

ration or personal use.✖ Web page design is his/her primary task,

one of several tasks required by the joband/or a hobby.The Web author still hand codes Web

pages using text editors or text-based HTML editors

and is disap-pointed with the

WYSIWYG Webpage development

tools. The main rea-sons for disappointments areexcessive and redundant

HTML code, limited control overthe look and feel of Web pagedesigns, and incomplete supportof prevailing version of HTML.

Although, sometimes, the Web authoruses HTML conversion tools, he or she is gen-erally unhappy with the HTML produced anduses text editors for postediting the convertedWeb pages. Also, the author designs his or her

own graphics and is very satisfied with usingAdobe PhotoShop.

Because of a variety of Web design projectsbeing worked on, it is difficult for the Webdeveloper to specify unambiguously how longit takes to develop a set of Web pages and howmany pages are developed during that timeperiod. Most of the Web page design projects,however, are very likely of very short timeperiods—less than 3 months. And, whileworking in teams of less than five people, theWeb author probably develops about 11–50pages during this period.

The Web developer uses design guidelinesor style guides when developing Web pages,and the sources of these guidelines are thoseavailable on the Web as well as those developedin-house. Although the author designs pagesthat are optimized for faster download, he orshe may not always optimize them to supportpeople with disabilities. The Web designerevaluates the Web pages he or she designs forusability almost all the time, and his or her pre-ferred methods of evaluation are informalmethods (with colleagues and people in thedevelopment team) and user walk-throughs.

To publish Web pages, the Web authoruses either FTP or copies files directly to theWeb server. And, because several people in theWeb development team need to publish onthe Web server, he or she either solicits help ofa Webmaster or publishes the informationhimself/herself.

Finally, the Web developer is quiteunhappy with the browser incompatibilitiesand feels that he or she wastes considerabletime making sure that the Web pages designedlook good on at least Netscape Navigator andInternet Explorer. Despite misgivings aboutWYSIWYG Web page design tools, the Webauthor is looking forward to tools that give thenecessary creative freedom and do not over-ride hand-coded HTML pages.

CaveatAlthough my interactions with Web designersof varied backgrounds lead me to believe thatthe sentiments expressed by the surveyrespondents are quite consistent with the gen-eral Web design community, the reader


should be careful in generalizing these resultsto all Web designers. The previous profile isbased on a small number (138) of Webdesigners who chose to respond to the survey,and in that sense, they were self-selected.Furthermore, the groups from whichresponses were solicited may be biased in favorof those with backgrounds in human factors,graphic design, user interface design, andcomputer programming. GVU’s 8th Surveyfound that most respondents had back-grounds in computer science/programming–related fields [2]. Because of these limitations,it is difficult to generalize the results to theentire population of Web designers.

Future Web Development ToolsIt was clear from the survey that most Webdesigners were unhappy with the current stateof Web development tools, so what will makethem happy? Based on the responses in thissurvey and personal experience, I will venturethe following suggestions.

Cooperation Rather than CompetitionBetween VendorsCompetition must give way to cooperationbetween vendors. I believe that today’s compet-itive products are likely to become complemen-tary working to support the deficiencies of eachother. In fact, we see this trend today.Macromedia Dreamweaver, a WYSIWYG Webpage design tool, completely supports Allaire’sHomeSite and Bare Bones Software’s BBEdit asan alternative means for developing Web pages.Similarly, NetObjects Fusion 3.0 (beta) sup-ports third-party tools such as text-basedHTML editors and includes Allaire’s HomeSite,a text-based HTML editor, as part of the FusionPackage. Both of these tools even combine thetwo modes so that a Web designer can choose towork either in WYSIWYG design mode or inthe text-based HTML mode. This allows Webdesigners to work the way they want, ratherthan adapting to the limitations and quirks ofthe Web development tool.

Increasing Support for Plug-In Architecture:Customizable Web Development ToolkitsFuture Web pages will not be built by using

only HTML. There will be increasing use ofclient-side scripting (ECMAScript: a stan-dardized version of JavaScript), DynamicHTML, CSS, eXtensible Markup Language,database integration, and yet unknown tech-nologies. Web development tools will have toarchitect their products such that to takeadvantage of newer technology all aWeb designers has to do is justplug in an upgrade moduleor a new tool to the Webdevelopment tool. Thiswill allow Web designersto create customized Webdevelopment toolkits witheach component of theirchoice; for example, seeWallop Build-IT [10]. Ibelieve that even proposingsuch an open architecture withassociated protocols (withoutactual plug-in modules) thatWeb development tool builderscan use will be a significantimprovement.

Support for Team DevelopmentFuture Web sites will very likely be severalhundreds or thousands pages large. Develop-ment teams of 1–2 people will be a thing ofpast. To keep up with their Web sites, compa-nies will push development responsibilitiesoutside of developer teams, letting otherdepartments contribute and manage Web con-tent [4]. Future Web development tools willhave to support such collaborative arrange-ments. This is not to suggest that such tools arenot currently available. Vignette Corporationoffers a product called Vignette, which is ateam-based site-production development toolthat allows writers, editors, producers, andWebmasters to collaborate in the content-development process and supports manage-ment of medium- to large-scale Web siteswithout significant performance penalties.Another tool just to enter the market is NetObjects TeamFusion, which also offers check-in/check-out facilities and allows creation ofAccess Control Lists to prevent changes byunauthorized persons.


PERMISSION TO MAKE DIGITAL OR

HARD COPIES OF ALL OR PART OF THIS

WORK FOR PERSONAL OR CLASSROOM

USE IS GRANTED WITHOUT FEE

PROVIDED THAT COPIES ARE NOT

MADE OR DISTRIBUTED FOR PROFIT OR

COMMERCIAL ADVANTAGE AND THAT

COPIES BEAR THIS NOTICE AND THE

FULL CITATION ON THE FIRST PAGE.

TO COPY OTHERWISE, TO REPUBLISH,

TO POST ON SERVERS OR TO REDIS-

TRIBUTE TO LISTS, REQUIRES PRIOR

SPECIFIC PERMISSION AND/OR A FEE.

© ACM 1072-5220/98/0500 $5.00

Improved HTML Conversion ToolsWith the advent of CSS, the conversion toolsare likely to become “smarter” and moreuseful. User satisfaction is likely to increasebecause the conversion tool can put the styleinformation separate from the main docu-ment and keep only structural HTML tagswith the main document. Of course, successof such style sheet-based conversion willdepend largely on how well (from the stylesheet perspective) the original document wasconstructed. If the original document was notcreated using style sheets, abundant andredundant HTML code may not be avoid-able. It is quite conceivable, however, tocreate a “smart” conversion tool that identi-fies the opportunities for using CSS wherenone exist. For example, the conversion toolcan identify consistencies in formatting andsuggest the possibility of creating a style-sheetbased Web page.

Future Web SurveysWith the advent of new technologies, it

will be useful to conduct a similar survey atleast once a year to track the changes in devel-opment tools and understand the needs ofWeb designers and how well they are sup-ported with the then available Web develop-ment tools. Also, it may be useful to conductmore detailed and independent surveys onareas such as Web development environment,accessibility, usability testing, publishing.

AcknowledgmentsI would like to thank the following people:

✤ Kate Ehrlich and Michael Muller forgiving me an opportunity to conduct thissurvey.

✤ Kate Ehrlich, Michael Muller, ScottIsensee, Valerie Stateson, and otherreviewers for providing useful feedback onthe earlier drafts of this article.

✤ Georgia Tech Research Center and GVUCenter for allowing me to use their ques-tion on Web page types in the survey.

✤ Keith Instone for helping me put the Webversion of the survey at the ACM

SIGCHI site.✤ Amy R. Fisher for forwarding the survey

to the Chicago chapter of Webgrrls, LindaTausher for forwarding the survey toWebWomen mailing list, StevenChampeon for forwarding the survey toWeb Design mailing list, and JueyChongOng for forwarding the survey toWorldwide Web Artists Consortium(WWWAC) mailing list.

✤ All 138 respondents for taking the time torespond to the survey and for providinginsightful comments.

References1. Gardner-Bonneau, D. (1998). Personal

Communication.

2. GVU. Graphics, Visualization, and Usability Center’s

8th WWW User Survey. World Wide Web:

http:/www.cc.gatech.edu/gvu/user_surveys/, 1997.

3. Grose, E., Forsythe, C., and Ratner, J. In C.

Forsythe, E. Grose, and J. Ratner (Eds.), Human Factors

and Web Development. Lawrence Erlbaum Associates,

Mahwah, NJ, 1998.

4. Hakhi, A. E. Content by committee – Development

tools help business units collaborate on Web develop-

ment. Information Week (January 12, 1998), Issue 664,

67–68.

5. Mosier, J. N., and Smith, S. L. Application of

Guidelines for Designing User Interface Software.

Behaviour and Information Technology 5, 1 (1986), 39–46.

6. Nielsen Media Research. Fall 1997 Internet

Demographic Study from CommerceNet and Nielsen

Media Research. World Wide Web:

http://www.nielsenmedia.com/interactive/com-

mercenet/F97/, 1998.

7. Nua. Nua Internet Surveys. World Wide Web:

http://www.nua.ie/surveys/, 1998.

8. Trace Research and Development Center. Trace

Research & Development Center: Making information

technology more usable for everyone. World Wide Web:

http://www.trace.wisc.edu/.

9. WAI (Web Accessibility Initiative). WAI Accessibility

Guidelines. Page Authoring. World Wide Web:

http://www.w3.org/TR/1998/WD-WAI-PAGEAUTH-

0203, 1998.

10. Wallop Build-IT. Wallop Software Home Page. World

Wide Web: http://www.wallop.com/.

designing for the web: a survey · 2005-08-29 · the web designers do not really need to know...

Documents