Slashdot Mirror

I still remember Douglas Bowman's blog post about why he left Google.

You mean this one? While I suppose the data-driven mindset of Google does have its problems (as well as its advantages), I don't really see the relevance to the GP's claim of evilness in choosing a subtler background color for ads.

What balls?

Well, of course they want participation. Participation means more information.

Google should focus on making their search engine better while thinking up the next big thing. Unfortunately, Google is so engineering-driven that it has a hard time understanding people. Even the use of "+1" comes off as mathematical and robotic. Grandma doesn't want to "+1 something".

Engineers often have trouble seeing their own work objectively, and they're afraid to apply human intuition in place of sampling data (e.g., the infamous 41 shades of blue). Google needs to change its culture so that it places greater emphasis on design and human interaction rather than technical impressiveness.

If Page was taking Steve Jobs' advice, the 20 percent perk would be eliminated completely and Page would be walking around instructing people what the consumer wants.

The present Google operation is so engineer-centric that they're afraid to even decide what color blue they should use without submitting it to the Cloud for arbitration. The point isn't that the Cloud would give you a bad result, but that their internal groupthink is so strong that they can't even tolerate individual decision-making. Somebody wanted to make a CSS border three pixels wide, and he had to make an empirical case with evidence and metrics. This isn't about agility, it's ideological and engineers trying to stake out a higher moral ground than creatives or commercial interests.

The whole "eliminate middle management" and "bottom-up" "agile" approach is totally valid in a lot of circumstances, but to be honest I think the open source movement and the whole "cathedral and the bazaar" mentality has totally politicized any conversations about business management. Developers have been blowing their own smoke for so long that they've basically constructed an internal value system where if a product requires marketing, it's not worth making, and if a project requires management, it's not a good project to do, and if the customer doesn't like the deliverable (cuz there weren't any PMs advocating for him) the customer should RTFM.

The consumer isn't even part of the equation, it's really just a semantic battle over who gets to claim to be the more honco technologist. Google makes tons of money, and Google gives the outward appearance of making money in the "right sort of ways," the ways that most people have made prior commitment to support, so Apple making lots of money is challenging. But it's not a mystery in a business sense, nor even really in a technological sense. It's a moral problem people have, and they use terms like "agility" and "innovation" to frame the moral debate.

What does 'more polished projects' mean exactly? Who has always done the polishing and development? It wasn't management and I've often found their direction is a coin flip.

Engineers are way too fast with the "I don't understand this, therefore it must be stupid, arbitrary and redundant" judgement.

Aside:

Not having that BS middle management means we get paid more although we have more responsibilities but those responsibilities were already foisted upon us when something went wrong anyway!

I don't think you understand elasticity of wages. Not having middle managers doesn't mean you get paid more, it means your firm charges the customer less -- laying off programmer middle-managers doesn't suddenly make programmers in demand or curtail their supply, it's actually the opposite, because all those PMs and partner engineers are looking for work and can probably do your job too, and would be happy to take less than you to do it.

This might have the knock-on effect of making your firm more competitive and keeping you more consistently employed, but the marginal gain of eliminating redundancy does not accrue to the remaining employees. There's a reason the guy that's paid with stock options does the firing: he's the one with the unbounded upside.

People make what complaints about both MS and google? Your first post seemed to imply "Company X are evil because not all of their products are successes", which I've still never seen said about either company, and I still don't see any logic in.

I didn't even use the word "evil."

Microsoft is often criticized by analysts for having too many employees and an unfocused product line. Too many products, too many updates, too many platforms, too many frameworks. They often make research lab announcements about things that never see the light of day. They have their hand in game consoles, mobile phones, music players, tablet PCs, and so on. However, their core business is still Windows and Office. This is why they're often criticized.

They're also criticized for having no cultural taste and a cumbersome hierarchy that gets in the way of their development process. They hold dozens of meetings for pointless things.

Google is doing the same thing. They're putting out a lot of side products that do nothing, which dilutes the brand and the platform they're trying to build. And Google's lead designer left Google because he said working at Google was frustrating. Google actually ran focus group tests on 41 shades of blue. This is the kind of stuff you hear about at Microsoft and laugh at (such as when the Microsoft developer posted on his blog about the lengthy design process behind the Vista shutdown menu).

Google and Microsoft are both giant, bloated corporations looking out for themselves. Google just happens to have a different market than Microsoft that affords them the ability to offer services for free in exchange for valuable advertising space. That's the only reason Google uses some open standards.

As said; yes it's closed source, but closed source isn't a problem -- closed standards and vendor lock-in are.

Which is what Google uses. They only use open standards when it suits them, such as to sell web advertisements or collect user information.

Yes, I know this, and I still don't care.

And that was my point about Google fanboys.

Their company could explode and their products rot, but as long as I've stuck with open standards, I'm free to switch to an alternative.

It's interesting that you think you're free to switch to an alternative if all your data is kept on Google servers. If Google explodes, your Gmail is gone forever, your bookmarks are lost, your RSS feeds destroyed, your YouTube subscriptions evaporated, and so on. "Cloud computing" is putting all your data in the hands of a self-serving company that wants to make money. Again, people on Slashdot mock Microsoft for lock-in and money interests, yet Google is even worse because they discourage you from local copies of your data.

At the time it was created, an ad-supported webmail service with IMAP access was pretty new. Also, their IMAP interface doesn't have any ads (or at least didn't last I checked, it has been a year or so since I tried it).

Gmail didn't even have IMAP until October of 2007. They were forced to implement it when other web mail services began to offer it as a service. They're fine with allowing you to access via a desktop client, because they still index your email and deliver relevant ads when you use other Google sites such as the search engine.

[Stuff you say is off topic snipped]

Just as I thought. You don't actually know what "speaks open protocols" means. Google's propietary search engine isn't speaking any open protocols other than the HTML it spits out at you.

I also mentioned Wave, which is a standard that nobody already used. I then went and attempted to do your research for you, looking for closed google specs to cite

What particularly drivs me batty is that they just hired Douglas Bowman as Visual Design Lead in May. He's been at the head of the XHTML/CSS progression/revolution for years, including the Wired News redesign in 2002.

I understand that it takes some time to get settled into a new workforce, so Bowman might not have had the time to get around to working on Blogger that much yet. According to his blog, he appears to have spent the first half of this year working as a contractor on Google Calendar. I just wonder, why wouldn't the Blogger team have waited until their Design guy/standards-compliance guru was free before rolling out this beta?

Many CSS users want to be able to take a heading or a short piece of text in the HTML and use CSS to replace it with an image. Users with graphical browsers should see the image. Users with text-only browsers should see (or hear) the original text. Search robots should also see the original text. (They often don't treat alt tags the same as normal text.)

One popular way to do this is Fahrer image replacement. This technique uses a piece of HTML like this

<div>
<span>Hello world!</span>
</div>

div {
background-image:url("hello_world.gif");
background-repeat:no-repeat;
height:35px;
}

The problem with Fahrer image replacement is that several screen reading programs don't pick up the replaced text. Many other image replacement techniques have been devised.

Which image replacement techniques do you think are okay to use? Which, if any, do you consider abuse of CSS?

It only conjecture, but in general, common knowledge:

http://www.econsultant.com/google/i-want-to-improv e-my-google-pagerank.html
http://www2.jeffcroft.com/2004/aug/09/google-page- rank-and-the-epicenter-of-hold-em-t/
http://www.stopdesign.com/log/2004/05/28/cost.html

Back when the most recent MSN redesign was launched, it didn't initially work in Internet Explorer on the Mac, and that was way back in January. If Microsoft's web developers don't even bother testing in it, then I don't think it's too important to them.

Insightful? Creating table-less XHTML compliant websites is easier than mucking around with tables. And you end up with cleaner, easier to maintain sites that work nicely across pretty much any modern browser. And converting a table driven design is even easier.

Read up and learn

Just to expand on your stats there, ESPN switched to XHTML/CSS a while back and are now Saving 2TB of bandwidth every day . And those traffic numbers are from 2003. Not to mention the file size savings inherent in properly formed HTML (as opposed to Tag Soup a la Slashdot).

What a coincidence - Most web designers* I know haven't a clue how CSS should be used in real world situations today. Check out e.g. Designing with web standards by Jeffrey Zeldman - IIRC, he argues that as long as CSS support is as broken as it is today, the transitional approach of tables for layout and CSS for other styles is perfectly justifiable for businesses which do not care about SEO and blind people.

Also, there are plenty of examples(1, 2, 3) of how to make a table-free site look just as good as one with tables.

*These are not primarily web designers, but creators of data-driven web interfaces who use e.g.

<TD ALIGN="LEFT" WIDTH="10%" NOWRAP BGCOLOR="#000099"><FONT COLOR="#FFCC00" FACE="Verdana, Arial" SIZE="-2"><B>&nbsp;</B></FONT>&nbsp;</TD>

A List Apart and StopDesign are sites that have great resources and tutorials, well worth a look.

Bleah, corrected URL. http://www.stopdesign.com/log/2005/01/31/msn-goes- css.html

They've mostly converted msn.com to xhtml strict with stylesheets. It ain't the prettiest thing but it's a step forward when it comes to web designs.

http://www.stopdesign.com/log/2005/01/31/msn-goes- css.html/

If every webmaster would stop implementing fixes and hacks to support non-standard browsers...

Start with the stricter, more compliant browsers that (usually) render things how they're supposed to render. Get everything working there. Then, double back and create a few "patches" for IE. Development is much faster this way. It may be counter-intuitive to initially avoid the browser that represents the majority of your traffic. But the process is much more fluid and efficient if you don't become accustomed to -- or depend on -- IE's relaxed rendering behavior. Start with IE, and you may start with bad code that takes much longer to fix for other stricter browsers.

You have raised some interesting thoughts which I haven't given much consideration in the past, the idea of the Content Type. Serving up a content type of xhtml+xml for XHTML documents makes sense from a technical point of view, but as you pointed out leads to some very undesirable effects in the browser (as does the declaration atop the page).

I appreciate this conversation and the opinions you've shared, I am learning that not everyone is a supporter of the W3C and their current direction (this is new to me). I am thinking I've had a jaded view through the last year or two because I'm a daily visitor to sites such as Mezzo Blue, Stop Design, A List Apart, etc...

I'd equate it to listening to Air America Radio exclusively or using Fox News as your news source, you become a little out-of-touch with what's really going on.

Clearly you aren't a web developer.

Most of the web developers I know (and I know a lot) started out using tools like Dreamweaver and GoLive etc, which now output decent XHTML, but now they are starting to move toward XHTML and CSS in their designs (which are some of the best on the net, might I add), and they're switching to using text editors exclusively for writing the code, plus your standard graphics programs for the images. I do the same.

The great thing about XHTML is that is separates the content from the design, which in turn makes your code beautiful and easy to write and maintain. I was looking at an XHTML page I had written the other day, and I thought, gee, I could just put this up as plain text and people would still understand it. It was free of all that contextual crap (tables, font tags, one-pixel spacer images) that heavily-designed HTML pages of two years ago were full of. So no, a text editor is not just for writing static text. I use mine for every aspect of the design process, though, admittedly ConTEXT is not notepad, it's pretty close. And I would contest that the sites I develop aren't crappy looking.

You may be able to design sites with a tailored WYSIWYG HTML editor, but you usally have little control over how everything fits together, and it results in messy code that is hard to understand. If that works for you, then fine, great. All I can say is that you better "know some of this stuff" and how to do it without your XHTML editor -- learn it in notepad -- and then, once you see what was output by your editor, and if you have any respect for the XHTML standard and the ideals that the W3C had in mind when they thought of it, I have a feeling you won't go back.

Just wanted to say that I absolutely agree with you on this one. A good desiner's eye would make any site more usable. Fonts, colors, font spacing, paragraph spacing, paragraph width, etc etc all affect how usable the page is -- a nice looking page just makes the whole experience more pleasing. Heck, it's why people put art in their homes. It's why we have "interior decorators" and "landscape artists" -- yes, our home would be more functional if instead we spent all that money on useful things like changing around the lightswitches or buying new appliances, but in the end, the beauty of the home plays as large (if not larger) a role as the usability in the overall experience. I for one would absolutely hate to live in a house without plants, without good-looking furniture, without some art on the walls (even just my own photography) -- it would be bland and boring, regardless of how usable it is. The best homes I've seen balance utility and design incredibly -- the best web designers do the same thing to the same effect. Jacob Nielsen has only half the picture.

The fact is, all the IE moaning is a BIG MYTH.

Sure, IE has some quirks (did you know that you can turn most of these off using the proper DOCTYPE?). But it's not a "pain in the ass" to develop for.

The biggest quirk is that IE (when not in standards-compliant mode - see above) calculates "size" differently than other browsers (and the standard).

You so absolutely do not have a clue what you're talking about.

Box-sizing differences are easy; it's well known, well defined, and very easy to take into account in advance.
No, the real problems with IE are that every single new largescale design runs into more and more really obscure problems, all interacting with each other. If you clear: left and don't want to run into the IE bug where that effects too much, in various situations you need to prevent that by (for example) setting height: 1%. Fairly straightforward still, and one of the common hacks. However, if this is happening in a document where you have _any_ relatively positioned and or z-indexed content, plus some other factor which I haven't yet been able to narrow down (lack of time), then suddenly completely unrelated content disappears and/or becomes unclickable.
If line-boxes touch a floated element, they get a 3 pixel "jog". The workaround for this involves setting a width or height - but hey, that leads to problems with the previous fix and/or the box-sizing which wasn't much trouble before.

And this is but a very minor and limited view of the problems I'm running into daily. And don't even get me started on weird interactions with DOM manipulation, selectors which _should_ work even in IE, but refuse to be utilizable for changing some css properties (but not others), etc, etc.

How about absolutely positioned content utilizing percentages not being reflowed upon resize? Yes, we've reached the stage where we're writing onresize scripts again - I so was thinking we'd reached the end of _that_ with the demise of N4.x

It's called The IE Factor, and any competent web designer will need to calculate in days of frustration for any larger than average project.

Good HTML means separating content from presentation as far as oossible.

Er, no. It means separating structure from presentation. See Douglas Bowman's piece on the topic and Eric Meyer's reply.

If you're really smart, you'll name them after what they represent { and are more meaningful than and

You're kinda defeating your own purpose with that. Much better to use a semantically meaningful emelent like address or similar and style or add classes/IDs to that. Just using a bunch of meaningless spans obviates the advantages of using a structural markup language in the first place.

Zeldman didn't do Wired's re-design. That was Douglas Bowman.

Hehe, Slashdot's not really a shining example of web accessibility, but it's a good place to ask for help none-the-less.

The first stops for help (as someone's no doubt pointed out already) should be:

Section 508

Mark Pilgrim's excellent "Dive Into Accessibility"

The W3C's web accessibility guide

The UK Disabled Rights Commission website, paying particular attention to the superb Interactive Demos (e.g. Inaccessible Website Demo).

Buy these books:

Constructing Accessible Websites

Building Accessible Websites

Oh, and a copy of Zeldman's Designing With Web Standards for good measure.

Write your pages using validating HTML or XHTML, and style the pages using CSS.

Validate your webpages using the W3C Validator and your CSS using the W3C CSS Validator. Use Watchfire's Bobby to validate your pages, and aim for AAA rating (also note that Bobby has some helpful hints when it does find errors).

Other excellent resources (in no particular order):

http://www.webstandards.org/
http://www.w3.org/WAI/References/QuickTips/
http://www.mezzoblue.com/
http://www.meyerweb.com/
http://www.simplebits.com/
http://www.whatdoiknow.org/
http://www.stopdesign.com/

Don't forget to use ALT tags!

I'd take advice like that with a pinch of salt, as the person dispensing it clearly demonstrates no understanding of the basic structure of an HTML document.

There is no such thing as an "alt tag". There is an alt attribute, which is a completely different thing.

The page is accessible if it can be properly viewed and navigated using a text-based browser (i.e. Lynx).

That's a dangerous assumption. Take guiltless image use as an example. Works fine in lynx, but fails miserably when you use a browser that renders CSS but does not display background images.

Website accessibility is a complex topic, and there's no way you can automatically test something like this. The best you can do is provide hints on what to look for.

I'm not particularly inclined to trust Cynthia, as the report document produced uses font sizes set at 12px and 10px verdana (!), and gives horizontal scrolling at 1024x768.

One tool I have found to be of high quality is Accessibility Valet.

If a site displays well on IE but poorly on Mozilla, it is often the case that the designers of the site focused on developing for IE and gave much less thought to being a standards-compliant site.