MEDFORD -- As a young high school teacher in 1982, Diane Souvaine leapt into graduate school for computer science having taken only one class in the subject.

Computers, she believed, offered an exhilarating way to apply her math skills to real-world problems. And because computer science was coming into its own in the feminist age, she also hoped it would be more welcoming to women than her undergraduate math department.

Today, Souvaine chairs the Tufts University computer science department, which has more female professors than male. But few younger women have followed in her generation's footsteps. Next spring, when 22 computer science graduates accept their Tufts diplomas, only four will be women.

Born in contemporary times, free of the male-dominated legacy common to other sciences and engineering, computer science could have become a model for gender equality. In the early 1980s, it had one of the highest proportions of female undergraduates in science and engineering. And yet with remarkable speed, it has become one of the least gender-balanced fields in American society.

In a year of heated debate about why there aren't more women in science, the conversation has focused largely on discrimination, the conflicts between the time demands of the scientific career track and family life, and what Harvard University President Lawrence H. Summers famously dubbed ''intrinsic aptitude."

But the history of computer science demonstrates that more elusive cultural factors can have a major impact on a field's ability to attract women.

As the popularity of computer science soared in the first half of the 1980s, many university departments became overburdened and more competitive, some professors argue. Introductory classes were taught in a way that emphasized technical minutiae over a broader sense of what was important and exciting about the field, a style catering to the diehard -- and overwhelmingly male -- techies rather than curious new recruits. The last thing educators, besieged by students, worried about was attracting more, so they didn't see the need to combat the image that took root in popular culture of the male computer geek with poor hygiene and glazed eyes.

''We had so much interest from so many young men for years, the attitude was 'Oh my God, how are we going to cope with these hordes of students?' not 'How do we get them interested?' " said Maria Klawe, a computer scientist and dean of engineering at Princeton University.

Though the enormous impact of computers on society makes the development of computer science at the college level unique in some ways, some scientists believe it offers a warning to other sciences as well. In fact, something similar happened in physics after World War II, when the atomic bomb catapulted the subject to preeminence in society, according to David Kaiser, a physicist and historian of science at the Massachusetts Institute of Technology. Facing a sudden and dramatic rise in enrollments, physics departments grew less intimate and coped with the crowds by teaching the subject in a more routinized and less creative way.

The percentage of women studying physics, already low, dropped dramatically and stayed in the single digits for decades. Eventually the physics bubble burst for men as well, and today a high percentage of the country's physicists are foreign-born.

Some computer scientists fear that they may be going in the same direction. They view the dearth of women as symptomatic of a larger failure in their field, which has recently become less attractive to promising young men, as well. Women are ''the canaries in the mine," said Harvard computer science professor Barbara J. Grosz.

In the wake of the dot-com bust, the number of new computer science majors in 2004 was 40 percent lower than in 2000, according to the Computing Research Association. The field has seen ups and downs before, and some think the numbers for men will soon improve at least a bit. But the percentage of undergraduate majors who are female has barely budged in a dozen years.

The shortage of new computer scientists threatens American leadership in technological innovation just as countries such as China and India are gearing up for the kind of competition the United States has never before faced.

The US economy is expected to add 1.5 million computer- and information-related jobs by 2012, while this country will have only half that many qualified graduates, according to one analysis of federal data. Meanwhile, the subject is becoming increasingly intertwined with fields ranging from homeland security to linguistics to biology and medicine.

''People who are mapping the genome are really computer scientists involved in biology," said Lenore Blum, a professor at Carnegie Mellon University in Pittsburgh.

A Globe review shows that the proportion of women among bachelor's degree recipients in computer science peaked at 37 percent in 1985 and then went on the decline. Women have comprised about 28 percent of computer science bachelor's degree recipients in the last few years, and in the elite confines of research universities, only 17 percent of graduates are women. (The percentage of women among PhD recipients has grown, but still languishes at around 20 percent.)

The argument of many computer scientists is that women who study science or technology, because they are defying social expectations, are in an uncomfortable position to begin with. So they are more likely to be dissuaded from pursuing computer science if they are exposed to an unpleasant environment, bad teaching, and negative stereotypes like the image of the male hacker.

When Tara Espiritu arrived at Tufts, she was the rare young woman planning to become a computer scientist. Her father is a programmer, and she took Advanced Placement computer science in high school. Because she scored well on the AP exam, she started out at Tufts in an upper-level class, in which she was one of a handful of women. The same men always spoke up, often to raise some technical point that meant nothing to Espiritu. She never raised her hand.

''I have not built my own computer, I don't know everything about all the different operating systems," she said. ''These people would just sit in the front of the class and ask these complicated questions. I had no idea what they were talking about."

Now a junior, Espiritu is majoring in engineering psychology, which examines how product design affects human use.

The classroom experience that turned off Espiritu had its roots in the early 1980s. The number of students receiving bachelor's degrees in computer science more than doubled between 1981 and 1984, according to the National Science Foundation. ''Undergraduates are swarming to major in computer science," NSF official Kent K. Curtis warned in 1983. Combined with the problem of faculty leaving for better-paying jobs, that meant there weren't enough professors to teach the subject. In response, ''many institutions are being forced to limit enrollments," Curtis wrote.

Many computer science departments imposed GPA requirements or tried to make introductory classes more difficult in order to weed out the multitudes, said Stanford professor Eric Roberts.

Those who were driven out were not the worst students, but those who felt more marginal, Roberts argues. They could have been men or women, but studies have shown that women generally have less previous computing experience and less single-minded passion for technology.

Introductory classes zeroed in on programming and other technical aspects of the field, rather than explaining big ideas or talking about how computing can impact society, many professors say. That approach led to a misconception among students that computer science is the same thing as computer programming. Computer scientists say that view shortchanges the field, which is far broader and more intellectually rich. It is applied math and design, they say; it is about modeling human behavior and thinking about the simplest way to accomplish a complex task.

When Souvaine joined the Tufts faculty in 1998, she was dismayed that there were few female students in the introductory course. So she and a colleague designed a new freshman seminar focused on problem-solving and real-life applications.

On a recent afternoon, Soha Hassoun, who is now teaching that class, lit up a drab cinder-block classroom with her boisterous questions. The topic of the day was how to get a computer to determine whether a particular point is inside or outside a geometric shape.

Hassoun's focus was on logical thinking, and she set aside only a few minutes for students to write their answers in computer code.

''Here's the big question. Why do we care about this?" she asked rhetorically, then went on to explain that that same method could help determine which diabetes tests are the best predictors of the disease. The class would later work on just that task.

The first time Souvaine taught the freshman seminar, there were 14 men and 14 women, and seven of each gender went on to major in the field. The number of female undergraduate majors remains low, but Souvaine sees reason for hope. About 30 percent of students now in lower-level classes are women.

On a broader level, the National Science Foundation will soon announce a new set of grants to universities, high schools, and industry groups with creative ideas for attracting women to computer science. A two-year-old organization called the National Center for Women & Information Technology has designated several schools and groups, including the Girl Scouts, to identify solutions.

A number of universities are trying to do something similar to Tufts. At MIT, where the percentage of women is much lower in computer science than in the general student body, the electrical engineering and computer science department will pilot two new introductory classes this spring. One will use robots to try to capture the excitement of the subject, and the other will provide basic background aimed at students who didn't take Advanced Placement computer science in high school.

The goal is to inspire more students like Katie Seyboth of Tufts. She loved math and science, but had never been interested in computer science before she took, on a whim, one of the school's introductory classes for people with no previous experience.

Soon, Seyboth was procrastinating on her other class work in order to do computer science assignments. Still, she found it ''really intimidating" when men used terms she didn't know and talked about complicated programs they wrote in their free time.

She believes that if she hadn't taken the ''welcoming" introduction, she would have drowned in her next class, which was all programming. If Souvaine hadn't taken her under her wing, she might not have had the courage to drop her chemistry major, she said.

Now a senior, Seyboth wants to earn a doctorate in computer science and recently interviewed for a job at Google. She was just named a finalist for a national computer science award.

''There's nothing better than watching the real potential of students like Katie being unveiled, seeing the joy and excitement they feel and the contributions they make," Souvaine said. ''And yet, had just a few things gone differently along the way, they might no longer be in the field."

source: http://www.boston.com/news/local/articles/2005/12/18/in_computer_science_a_growing_gender_gap?mode=PF

# posted by dark master : 12/19/2005 10:23:00 AM  0 comments

If you're like many Web developers, you have no idea how to ensure that your Web pages are accessible to wireless devices. Because you probably don't want to maintain Web and wireless versions of the same site or take on the overhead of Extensible Markup Language (XML) transformations, this article shows you a more practical approach to wireless compatibility. With some well-designed XHTML, a bit of CSS, and the media attribute, you can do wonders.

The days when Web pages were viewed only on Web browsers are long behind us. In fact, even the days when Web pages were viewed mostly on Web browsers are coming to an end. With hundreds of mobile devices available and millions of them in use -- most now Internet-capable -- it's almost assured that if your Web site or application is popular, it will be viewed on a mobile device. As a Web developer, the question is how far are you willing to go for wireless? Most Web developers don't particularly want to take on a second specialization in wireless development, but trends show that you do need your Web pages to be usable by wireless devices -- so what are your options?

Developers already using XML for their site or application code will probably do best to stay on that track and use Extensible Stylesheet Language (XSL) stylesheets for wireless formats. Those dependent on wireless traffic may benefit from building multiple versions of the same site. But the rest of us need less costly options -- preferably ones that let us use what we've got, rather than starting from scratch.

In this article, I'll show you an easy way to upgrade your Web pages for wireless compatibility. If you're already coding your Web pages using HTML 4.01 Strict or XHTML and styling them with CSS, then you've done more than half of the work of making them accessible to wireless devices. What's left to do, as you'll see, is a breeze.

First, a little background

The following technologies should be familiar to you if you're doing serious Web development, but just in case, here are the basics:

• HTML: Clearly, if you aren't familiar with HTML, you're not ready to start working on wireless-enabled Web pages! More specifically, you should be writing your Web pages in HTML 4.01, which pulls presentation out of the HTML and puts it elsewhere (where it belongs).
• XHTML: XHTML is the XML-compatible version of HTML, and it's important for a number of reasons. While I won't completely cover the move from HTML to XHTML, you will get the highlights.
• CSS: Cascading Style Sheets provide a modern way of styling Web pages without that presentation being stuck between your opening and closing p and table tags.

Assuming you've got a "plain vanilla" Web site, you're probably using some mixture of HTML 4.01 (the current standard) and a bit of older HTML, as well as possibly a little bit of CSS. The first thing you'll need to do is upgrade your Web pages to something a little more strict, as I'll explain below. (If you're already using HTML 4.01 Strict or XHTML you're ahead of the game -- jump to "Getting started.")

Back to top

From HTML to XHTML

If you don't already know it, HTML is on the move. The presentation HTML most Web developers cut their teeth on is nearly phased out, with newer versions like HTML 4.01 Strict and XHTML 1.0 being readily adopted by newer (and especially Web 2.0) browsers. If you're not already up on the different versions of HTML and XHTML you might want to check out an introductory article or book on the topic (see Resources). Basically, today's HTML falls into the following categories:

• Old HTML: For the purposes of this article, "old" denotes any HTML that doesn't specifically comply to one of the HTML or XHTML versions listed below. It usually has a mix of presentation elements such as font and bgcolor tags and attributes.
• HTML 4.01 Transitional : This version of HTML is the easiest to get to and looks a lot like "old" HTML. It still allows presentation elements, although they are deprecated (which means that they're being phased out).
• HTML 4.01 Strict : With this version you've started to move toward the HTML needed for today's Web. All presentation elements and attributes are disallowed, meaning that your actual HTML is all about the structure of your page, rather than how it's supposed to look.
• XHTML 1.0 Strict : This is largely HTML 4.01 Strict with just a few changes. It's pretty cutting edge stuff (XHTML 1.1 would be bleeding edge), and increasingly supported by wireless devices.

Aww, why so strict? You might be thinking, "Why go to HTML Strict, as long as I'm using CSS for all my styling and presentation?" This classic I'll discipline myself argument never actually pans out -- at least not over the long term. No matter how disciplined you are, if you can make a quick change here or there with presentation HTML, you eventually will. By moving to HTML 4.01 (and XHTML 1.0) Strict, you're restricting yourself: you can't use presentation HTML, no matter how much you might want to. More importantly, when the boss is screaming at you to get that menu changed from green to blue, you'll take the time to make that change in your CSS, not your markup.

The benefits of XHTML

If you're serious about supporting wireless devices, you need to be using at least HTML 4.01 Strict for your Web pages, and you should seriously consider moving to XHTML 1.0 Strict. Getting to HTML 4.01 Strict forces you to drop any presentation in your HTML in favor of CSS, which is the first step to good, flexible Web design. CSS is also essential if you want to build Web apps that easily support wireless devices, because you can apply one CSS set of rules for Web browsers and another for mobile devices.

After you've moved to HTML 4.01 Strict (if you're unsure about how to do that, see the Resources section for relevant links), you'll want to think seriously about moving to XHTML 1.0 Strict. XHTML is simply the most current version of markup around, and that carries with it some significant benefits:

• New browsers are sure to support XHTML and its features.
• XHTML is constantly expanding and adding new features. By moving to XHTML you'll get the benefit of its new features, some of which could help you, your site, or your customers. New features also get more attention in product development.
• When that new version of XHTML that you must have comes out, you'll be much closer to getting your current markup to that new version if you're already using XHTML 1.0 (or, even better, 1.1).

As an additional bonus, more and more wireless devices are providing support for XHTML. While that doesn't necessarily mean that these devices won't support HTML 4.01 Strict, it does mean that they're going to support XHTML specifically, and as you move to XHTML 1.1 and the new wireless modules in that version of XHTML, you're going to get significant advantages over using just HTML 4.01, even with the CSS techniques discussed in this article.

Back to top

Getting started

For the purpose of the examples, I'll assume you've upgraded to HTML 4.01 Strict or XHTM 1.0 Strict. The first step after you've upgraded your HTML is to be sure you supply a DOCTYPE for the page. Listing 1 shows the DOCTYPE for HTML 4.01 Strict.

                     "http://www.w3.org/TR/html4/strict.dtd">

 
   
   
 
 
   
 

This should be the first line in your HTML document, before the html element. You should also include the meta tag, which specifies your character set: the W3C validator (discussed below) doesn't like not knowing the encoding of your document.

Listing 2 shows the DOCTYPE for XHTML 1.0 Strict.

   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

 
   
   
 
 
   
 

IE and the XML declaration XML gurus will wonder why Listing 2 doesn't have the XML declaration, the line that starts with . Unfortunately, Internet Explorer (only the world's most popular browser) chokes on that line, so you must ensure that the first line of your XHTML is the DOCTYPE line, not the XML declaration.

You'll notice a few differences in the XHTML compared to the HTML, but you should be able to figure them out fairly easily. The biggest change is that XHTML requires you to close all your elements (use, for example, and
instead of and
), and you'll also need to add the xmlns attribute on the html element. A good book or article will guide you through these semantic details. See the Resources section for pointers.

Can you validate that?

It's one thing to say you're going to upgrade your pages to a specific version of HTML or XHTML; it's another to actually get them there. Rather than just reading some articles, making a few changes, and assuming you're done, you should always validate your files. The World Wide Web Consortium (W3C) defines all the standards being discussed in this article, and its validator tool lets you check your HTML or XHTML and make sure you're compliant.

After you have your DOCTYPE in place, surf on over to the W3C Validation Service. There you can upload your files (or paste in the source), and validate them. Figure 1 shows a successful validation; this will let you know for sure that your page meets the standard you're going for.

One at a time When you're validating and dealing with errors, fix them one at a time. The validator often reports one error, and then successive errors show up as a result of that initial error. So don't bother trying to go down the entire list; instead, fix one error, re-validate, and see if that clears up other problems (it usually will).

Making mistakes is a pain, although it's common enough, and almost always the first step between starting and finishing. In cases where your HTML or XHTML is invalid, the W3C validator gives you red error messages like the ones in Figure 2.

Figure 2. Validating XHTML and getting a list of errors

When you get messages like this one, don't worry -- just use them as a guide to fixing what's wrong with your page, and then re-validate until you get the nice green message shown in Figure 1.

Back to top

And then there was CSS...

After you've removed all the presentation code from your page (with the help of the W3C validator), it's time to add in some CSS. Like HTML and XHTML, CSS has tons of great features, but for the purpose of this article you need to follow two basic steps:

1. Move all of your CSS into one (or more) external stylesheets, ending in a .css extension.
2. Reference your stylesheets in your HTML or XHTML using a link element.

I'll take you through all the steps of moving your CSS to external files in just a second, but first let's concentrate on getting that all-important link right. Listing 3 shows the XHTML to link correctly to an external stylesheet.

                     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

 
   
   
   
 
 
   
 

Back to top

Setting up external CSS

Moving your CSS code into external stylesheets is the key to making your Web pages accessible to wireless devices. External stylesheets can be easily applied to different presentation environments such as Web browsers and wireless devices. The steps are as follows:

1. Move all your CSS into external stylesheets (that is, dump it from inline code).
2. Segregate your stylesheets into logical groupings: one for browsers, one for wireless devices, one for printing, and so forth.
3. Use the media attribute on the HTML 4.01 or XHTML link element to assign specific stylesheets to different viewers of your page.

As you're in transition to external stylesheets it's also a good idea to think about stylesheet naming. A typical CSS stylesheet is named something like lounge.css or starbuzz.css or perhaps my-site.css. There's nothing wrong with that, although -- as you'll see in the next few sections -- there's nothing particularly great about it either.

When you start to develop CSS stylesheets for each type of device you serve, you're going to want to name stylesheets according to both the site or purpose they serve (like "lounge" or "starbuzz"), and the type of device they style for. So for your core sheets, you might want to consider a name like lounge-web.css or starbuzz-web.css. This makes it very clear -- to you, to colleagues, and to that new junior programmer who just got hired and knows nothing about your systems -- that the purpose of that particular CSS stylesheet is to serve Web browsers (or at least clients that access the Web traditionally). You could even use something like lounge-browser.css if you wanted to really be specific. This may seem like overkill now, but it's about to really pay off.

Let's see what happens as I follow the steps to move from inline CSS to external stylesheets.

1. Dump inline CSS

The first thing you need to do is get any inline CSS out of your pages. Listing 4 shows a typical HTML page with CSS added to the beginning of the page.

 
 
 
 

 




 


 

 

  
 

 About

        href="http://elisabethfreeman.blogspot.com/"> Blog 

  Books 


  Photography 

  Technology 

  Noteworthy 

 


 

There's nothing particularly wrong with this page: it works great, looks good, and uses CSS for presentation instead of deprecated HTML. However, the CSS is applied to this page for every type of viewer, whether it's a printer, Web browser, mobile phone, handheld, or aural screen reader. That's the problem with inline CSS -- it's tied to the page and is thus largely inflexible. Fortunately, the switch to external stylesheets is relatively simple, as shown in Listing 5.

 
 
 
         type="text/css" href="ef.css">

 




 


 

 

  
 

 About

        href="http://elisabethfreeman.blogspot.com/"> Blog 

  Books 


  Photography 

  Technology 

  Noteworthy 

 


 

In Listing 5 you can see that a fairly small change adds a lot of flexibility. The external stylesheet can easily be applied to all the pages on your Web site or application (or all the pages in a particular section of your site), resulting in a nice, uniform look and feel. More importantly, moving all that inline CSS into external files sets you up nicely for using multiple stylesheets.

2. Group stylesheets

Lots of times you'll find that in one stylesheet you end up with hundreds -- and sometimes even thousands -- of rules. There's nothing particularly problematic about that (other than the maintenance nightmare), but using multiple stylesheets lets you break up your stylesheets a little more logically. Putting all your table-related rules in one sheet and your core HTML rules in another (for example) will make your site a lot easier to maintain, because a two- or three-hundred-line sheet is much easier to read than a single sheet that encompasses every single rule.

Things get more interesting when you decide that you want your overall site or application to have a common look and feel, but you want some pages or sections to be differentiated. For this, you might have a basic sheet that lays out the rules for all pages, and then particular sheets that add or modify those rules for certain sections. For example, consider a setup like this:

• auto-core.css: rules for an entire automotive site.
• auto-finance: rules that augment the core set, and provide a sleeker, more soothing site for customers applying for finance (make them relax so they'll spend more, right?).
• auto-maintenance: rules that add a more industrial feel, and also changes the menu system, for support and maintenance issues.

Applying multiple stylesheets

After you've set up multiple stylesheets you can simply reference more than one link element in a page. Listing 6 shows a single stylesheet for the heading section of the core site's pages.

If you wanted to work on the financing section, though, you'd want to apply both the core sheet and the finance sheet. That's trivial after you've set up external CSS and grouped your rules into multiple stylesheets. You just need to add another link element in, as shown in Listing 7.

Are you starting to see the power of external CSS with multiple stylesheets? Augmenting the rules in one sheet with another makes it easy to define different layers of styling. And, because the rules in later sheets override rules in earlier ones, you can easily pick and choose from existing rules as you create new pages or sections, or upgrade your site's look and feel. (For example, you might choose to use 80 percent of the core rules for a redesign but redefine a few rules for a new look and feel.) The result is a highly configurable site that offers a uniform look and feel and lets you define differences between logical sections.

3. Assign stylesheets to different viewers

So far, the tricks I've shown you mostly apply to normal Web development -- using the most current HTML or XHTML and external stylesheets to make your pages nice and organized. Now it's time to think about making the pages accessible to different viewers. You've already seen the basics of using the link element to link to external stylesheets (in Listing 3 and Listing 7), but here's where it becomes even more powerful. Adding the media attribute to the link element allows you to indicate the viewer type to be assigned to each stylesheet. The most common values for this attribute are as follows:

• all: is the implied value when none is specified; the indicated sheet is used for all viewer types.
• screen: says that the indicated sheet is used only for viewers looking at the page on a computer screen; you can typically read this as "browser" if it helps, as browsers are the real target of this type.
• print: allows you to specify a stylesheet suitable for printing; you usually would strip out colors and fancy images to provide a nice black-and-white printout when using this type.
• handheld: should be pretty obvious -- it allows you to style specifically for handheld and mobile devices.

Back to top

Working with different media

So, suppose you have a highly graphical site -- maybe the flashy opening section of that automotive site, with pictures of cars and descriptive text -- and you want to allow for printing. You obviously want to strip out most of the formatting, which either won't show up on a printer at all or would look terrible. So, you create a new stylesheet called auto-print.css that sets the basic font to a serif style (generally considered the best type of font for print), and focuses on the text. To ensure that auto-print.css is used for pages to be printed you would add the second link element shown in Listing 8.

 
 
    media="print" />

That's simple enough, right? Now let's say that you also want to add a wireless stylesheet into this mix, so that users checking out your automotive site from their Treos could get some useful content. Obviously, there's a lot to be said about laying out a site for wireless visitors, but for the sake of this first example, let's just say you decide to strip out all formatting for a streamlined, bandwidth-light version of your site. Listing 9 shows how you would link to a stylesheet for wireless devices.

 
 
 
    media="handheld" />

Don't forget to set the media type!

Listing 9 looks pretty good, but it presents a hidden problem. Do you remember what the media type defaults to if none is specified? It's all. So the first link, which refers to auto-core.css, is automatically applied to all viewer types. And, as you may recall, when multiple stylesheets are specified, they're combined, with rules in later sheets overriding rules in earlier sheets.

Given the current code, the printing and handheld device pages will be styled by their individual stylesheets (auto-print.css and auto-wireless.css, respectively), but they'll also take on the rules of auto-core.css. That may be what you want -- uniformity, right? -- but it's probably not. If auto-core.css adds any background images, or performs absolute positioning, or even sets the color or style of fonts, some of these styles will likely "bleed" into your printable or handheld device pages. Because you don't want to mess up an otherwise great looking page on a specific device, you need to specify the media type on the core stylesheet, as show in Listing 10.

 
 media="screen"/>
 
 

This small -- and easily forgotten!-- change will ensure that auto-core.css is applied only to browsers, leaving auto-print.css and auto-wireless.css to handle all the styling for the devices they target. The result is a better site with more specific styling for different devices. Perfect!

Back to top

Wireless design notes

After you know how to apply a specific set of CSS rules to wireless clients, you've got to do some thinking about what to show to those clients. Unfortunately, this is largely application- and page-specific work. In other words, there's no basic set of rules for making Web pages suitable for display on wireless and handheld devices.

I'll spend the remainder of the article looking at some of the basic principles and common problems you should consider when styling your Web pages for viewing on wireless devices. Before I even start on the design notes let me reiterate the essential lessons learned in the first half of this article: If you have presentation code in your HTML itself, you're in for a world of hurt; it will be nearly impossible to manage good design for different devices. Before spending hours tweaking your CSS for a handheld, make sure that your pages use completely HTML 4.01 Strict (if not XHTML 1.0 Strict) markup, and that you've correctly set the media type up on your link elements. With those things done your pages are set up to work across wireless devices, and what's left are the actual design considerations.

Slim, low, little

Wireless devices have slow network connections and little room for display. If you're serious about wireless compatibility you need to design your Web pages accordingly. The many things you can do to help wireless displays fall into three basic categories:

1. Create or style a version of your site that is slim and will fit on narrow device screens.
2. Provide low-bandwidth versions of your site.
3. Get the most important content on the initial screen of your little handheld; it's problematic to scroll down on phones.

So for example, you should consider dropping out all images in your stylesheet rules for handhelds; the less images a handheld has to load, the faster your pages will appear. If you need a small banner image, that's probably okay, but showing fancy backgrounds or stylized content just doesn't make sense on handheld devices.

But my phone supports ... Plenty of newer phones and phone-organizer hybrids support frames, Flash, Java™ plug-ins, JavaScript, and other such fancy features. If you write your code with such devices in mind, however, you leave the majority of users behind. Not everyone can afford a $500 wireless device. If you're aiming for true wireless compatibility you need to support mainstream Nokia phones as much as you do high-end devices like Treo, Blackberry, and Sidekick.

You should also avoid using frames, as well as fancy menus and scripts. If you provide menus and scripts on your screen-viewed site, be sure to set your CSS to fall-back to text versions of menus and remove scripts for wireless devices. Frames are a bad idea in any environment, so just avoid them completely.

In addition to avoiding scripts, you should assume that handheld devices aren't going to work with Flash animations, Java plug-ins, events in JavaScript like onClick or onBlur... unfortunately, the list of unsupported things just goes on and on. In general, you need to ensure your sites are simple, mostly text, and stick to a one-column design if you want to ensure good wireless device compatibility.

A tiny little window...

To address the narrow width of handheld devices, consider using the CSS max-width property, as shown in Listing 11.

body {
 max-width:  200px;
}

div#content {
 max-width:  100px;
}

div#links {
 max-width: 50px;
}

This ensures that your pages stay slim, and fit in typical handheld windows. You may also want to hide portions of your page that aren't needed. For example, if that fancy logo and footer just aren't really needed on wireless devices, use display:none; see Listing 12 for a simple example.

body {
 max-width:  200px;
}

div#content {
 max-width:  100px;
}

div#links {
 max-width: 50px;
}

#menu {
 display: none;
}

#footer {
 display: none;
}

Consider using similar rules to shrink down banner images (remember, you're removing any other non-essential images), hiding extraneous text, using text-only images, and anything else you can think of to create small, handheld-friendly displays.

The classic div problem

The classic div problem is worth knowing about if you ever need to convert a highly dynamic site to wireless-capable views. To start, take a look at Listing 13, which shows a typical div-based XHTML page. It's made up of several basic sections:

• The "header" div, for a splash image and welcome message.
• The "sidebar" div, which shows menus and links.
• The "main" div, for the basic body content.
• The "footer" div, with trademark information.

                      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">


 
 
 
 
 


 

   
 


 

   

     
   

   

     
   

 


 

   
Welcome to Cyber-Autos!

   

 


 

   © 2005, Cyber-Autos, Inc.
   

   
 


]]>

For the screen, you might float the sidebar over to the right (in fact, that's a very typical approach), meaning that the main body content appears on the left. In other words, CSS is used to position the divs on the screen, rather than their position within the actual XHTML file. That's problematic on a handheld, however, because you're not going to be able to use absolute positioning and float -- at least, not if you want to support more than the latest handheld devices.

The typical handheld device reads your XHTML from top to bottom (no surprise here, right?) but absolute and relative positioning, as well as floating divs, are dicey at best on handheld devices. So no matter what you have in your CSS, the handheld would read a page like Listing 13, and show first the header, then the sidebar, and finally the main section. To avoid this problem you may have to make changes to the structure of your XHTML. Even though you shouldn't code presentation into your XHTML, you occasionally may have to make changes to that structure that have an effect on presentation (it's a subtle difference, but a difference nonetheless).

If you looked at the div-based page shown in Listing 13 on a handheld, you'd see an image at the top (which is almost certainly unnecessary on a wireless device), then the menu and further information links, and then -- finally -- the main page content. To get around this, first consider completely hiding the header (using display: none). After you've removed the image (which really has no bearing on a handheld) you can insert text instead, or just count on the page title to do the job. Next, you might want to hide the entire sidebar section. Alternatively, you could move that div below the main content, which is where your structure does have some bearing on your content. Because wireless devices -- or devices that don't support CSS in full -- read the page in order, you should try to position important content as high on the page as possible, so it's seen first.

As a corollary, items that are temporary (like a special deal) or less important (advertisements for a sister company or division that sells tires, for example) should be placed lower on the page. They'll be below the visible screen on most handheld devices, but you can use CSS to move them nearer the top of the page -- or to different columns -- on CSS-capable viewers.

Back to top

In conclusion

Obviously, there are as many ways to handle the demands of wireless devices as there are actual devices! In many cases, you will actually be able to tailor your approach to serving wireless content to the types of phones or handhelds you're targeting. For example, if you know that you're only serving content to internal employees, and they're all carrying Blackberry or Treo devices, you may choose to get a little fancier, or just allow the devices to download an XHTML mobile application (something that's beyond the scope of this article, but referenced in the Resources section). If you're serving content to every possible phone and device, however, your solution will obviously have to be more general.

The ideas in this article are best suited to existing Web pages that need to support -- at least to the degree possible -- wireless devices with minimal changes to the pages. You can do a lot more by designing wireless sites or apps from scratch, or by creating complicated Website Meta Language (WML) or VoiceXML applications specifically for phones. The technique I've demonstrated here is for situations where you don't have the time and resources for such solutions, or where the handheld isn't the company's primary target. In these cases you can get by with just a little CSS and some well-planned page layout.

Back to top

Resources

• XHTML: The power of two languages (developerWorks, July 2002): Learn more about XHTML.
  
  
• Build quick, slick Web sites (developerWorks, September 2005): XHTML design tricks for fast-loading, responsive Web pages.
  
  
• XHTML applications go mobile (developerWorks, March 2003): Port your XHTML apps to Nokia phones.
  
  
• Developing wireless content using XHTML mobile: Create XHTML Mobile Profile documents that render on multiple devices.
  
  
• The Opera browser homepage: Includes guidelines for wireless CSS and ideas for rendering Web pages on wireless devices.
  
  
• developerWorks Wireless zone: Specializing in Web-based solutions.

• W3C Markup Validation Service: Bookmark this page and have it handy at all times.
  
  
• The W3C CSS Validation Service: Validate your CSS the same way you do your markup.
  
  
• Download Opera 7: Finally, a browser that lets you test your wireless designs!
  
  
• Download Apache Cocoon: Choose stylesheets based on the type of device accessing your page.
  
  
• Java and XML, Second Edition (Brett McLaughlin, O'Reilly Media, Inc., August 2001): Includes Brett's discussion of XHTML and XML transformations.
  
  
• XML in a Nutshell, Third Edition (Elliotte Rusty Harold and W. Scott Means, O'Reilly Media, Inc., September 2004): Includes chapters devoted to XML on the Web and to CSS.
  
  
• Head First HTML with CSS & XHTML (Elizabeth and Eric Freeman, Head First Labs, December 2005): A complete source for learning XHTML, CSS, and how to pair the two.
  
  

• developerWorks blogs: Get involved in the developerWorks community.
  
  

Back to top

About the author

Brett McLaughlin has worked in computers since the Logo days. (Remember the little triangle?) In recent years, he's become one of the most well-known authors and programmers in the Java technology and XML communities. He's worked for Nextel Communications, implementing complex enterprise systems; at Lutris Technologies, actually writing application servers; and most recently at O'Reilly Media, Inc., where he continues to write and edit books that matter. His most recent book, Java 5.0 Tiger: A Developer's Notebook, is the first book available on the newest version of Java technology, and his classic Java and XML remains one of the definitive works on using XML technologies in the Java language. source:http://www-128.ibm.com/developerworks/wireless/library/wi-css/?ca=dgr-lnxw01WirelessPages

# posted by dark master : 12/19/2005 10:14:00 AM  0 comments

ndia's IT and remote-service industries just keep on growing

ASKED for a sound-check at a function in Delhi this month, Bill Gates eschewed the “1,2,3...” favoured by ordinary mortals. “One billion, 2 billion...,” he counted. They think big, these IT moguls, and especially, these days, in India.

Microsoft later announced plans to invest $1.7 billion in India over the next four years, about half of it in adding to its existing research and development (R&D) and technical-support operations. “The only thing that limits us in India,” Mr Gates told the local press, “is the speed at which we can recruit.” A few days earlier, Intel, a giant chipmaker, had unveiled plans to invest more than $1 billion over five years, much of it in expanding its R&D centre in Bangalore. In October Cisco Systems, the world's largest maker of the routers and switches that direct internet traffic, announced its own plans to invest $1.1 billion in India.

The euphoria is confined neither to American multinationals, nor to information technology. It also encompasses India's own IT industries, and the expanding range of other back-office services that can now be performed remotely. The three biggest Indian IT-services firms—Tata Consultancy Services (TCS), Infosys and Wipro—are each recruiting more than 1,000 people a month. And to take just one example of the other services now moving to India, J.P. Morgan Chase, a big investment bank, this month revealed it is to double, to about 9,000, its staff there. Anyone who assumes J.P. Morgan will simply be doing low-level “back office” tasks in the country—a bit of data entry and paper-shuffling—would be flat wrong. One task for the new recruits is to settle complex structured-finance and derivative deals, what one insider calls “some of the most sophisticated transactions in the world”.

All these investments illustrate that a third stage of the great Indian services-export boom is well underway. In the first, firms such as TCS developed world-class expertise in software “application development and maintenance”, and their low-cost developers became the preferred partners of many Western IT firms. In the second, Indian firms and the local “captive” operations of multinationals started offering low-end back-office services that could take place a continent away—telephone call-centres, transcribing medical records, processing insurance claims and so on. In the third, in both IT and the broader spectrum of other “business processes”, ever-more sophisticated functions are happening in India.

So strong are the forces driving this shift that what seemed improbably rosy projections by NASSCOM, the Indian software- and service-industry lobby, and McKinsey, a consultancy, back in 1999, are coming true. This week NASSCOM and McKinsey produced the second full-scale update of their study. It argues that exports from India's IT industry and from “Business Process Offshoring” (BPO)—both from services “outsourced” to Indian firms and those performed by captives—are on track to reach $60 billion a year by 2010.

That would be a huge surge from the $17.2 billion in the year ending in March 2005. But it implies a compounded annual growth rate of 28%—below that achieved in recent years. Moreover, according to McKinsey's estimates, it requires India merely to maintain its present shares of the markets for offshore IT services (65%) and BPO (46%). This is because the study predicts a massive rise in the size of the overall market, estimated at present to make up just one-tenth of those services that could be sent offshore. The proportion is expected to rise as demography—a western labour shortage—becomes more pressing than protectionism.

In IT the growth in Indian exports is expected to come both from the software market, and from “traditional IT outsourcing”—such as the remote management of whole systems, a market now dominated by the big global IT consultancies. This is expected to rise from 8% of Indian sales now to about 30% in 2010, while software-development's share will fall from 55% to 39%. In business-process-offshoring, the big industries will remain banking and insurance. But rapid expansion is also expected in other areas, like legal services.

The law, in fact, illustrates how vast is the untapped potential market. About $250 billion is spent on legal services world-wide, about two-thirds of it in America, and as yet only a tiny proportion goes offshore. Forrester, a research outfit, has estimated that, by last year, 12,000 legal jobs had moved offshore, and forecast that this will increase to 35,000 by 2010. India, with its English-language skills and common-law tradition is well-placed to secure a big share of the business. It is not just a question of “paralegal” hack work such as document-preparation. Sanjay Kamlani, of Pangea3, a small Indian firm, calls it “real lawyering”—drafting contracts and patent applications, research and negotiation. His clients are both big law firms and in-house legal teams.

India's fundamental attraction has not changed since it first drew software developers: fantastic cost savings. With American lawyers costing $300 an hour or more, Indian firms can cut bills by 75%. Across the board, despite climbing rates of pay in IT and BPO, where rapid expansion has brought frantic job-hopping, India remains, say NASSCOM and McKinsey, the lowest-cost of all the main outsourcing destinations. It also has, among these countries, by far, the largest pool of employable people—those with the necessary language and technical skills. On this measure, India, which produces 2.5m graduates a year, 250,000 of whom are engineers, has 28% of the global available workforce, compared with 11% in China.

Yet the supply of talent may be the biggest constraint on the Indian industry's growth. On these latest projections, the number of people working in IT and business-process exports in India will increase from about 700,000 now to 2.3m by 2010. But on today's estimates only 1.05m suitably qualified people will graduate from college between now and then, so there will be a shortfall of nearly 500,000, with business-processing the worst affected. McKinsey's Jayant Sinha believes the education system can be fixed in time to plug the gap. A bigger worry, he says, is India's creaking urban infrastructure. IT firms in Bangalore, for example, are in revolt against the local government for its neglect of basic amenities. Yet India's IT and business-process industries will need about 14m square metres (150m square feet) of office space by 2010: “a new Manhattan”.

# posted by dark master : 12/19/2005 10:09:00 AM  0 comments