This paper concludes that women are not disadvantaged by their own actions; they are penalised by a scoring structure which conceals sexism and disregarded by a masculine-majority userbase. Far from programmers’ paradise, gender-biases dictate the sharing and recognition of technical knowledge on SO.
Trouble in programmer’s paradise: gender-biases in sharing and recognising technical knowledge on Stack Overflow by S. J. Brooke
Hat tip: Shannon Smith (@cafenoirdesign).
In April of 2009, in a post every web designer, publisher, or business person should read, Joshua Schachter told how URL shortening services like TinyURL and Bit.ly came to be, and why the latest ones were so addictive. (Missing from Joshua’s account of their utility is the benefit URL shorteners can provide when sharing an otherwise obscenely long link on the printed page.)
The prescient post concludes that, despite their benefits, such services ultimately harm the web, decreasing clarity while increasing the odds of linkrot and spam:
[S]hortening services add another layer of indirection to an already creaky system. A regular hyperlink implicates a browser, its DNS resolver, the publisher’s DNS server, and the publisher’s website. With a shortening service, you’re adding something that acts like a third DNS resolver, except one that is assembled out of unvetted PHP and MySQL, without the benevolent oversight of luminaries like Dan Kaminsky and St. Postel.
There are three other parties in the ecosystem of a link: the publisher (the site the link points to), the transit (places where that shortened link is used, such as Twitter or Typepad), and the clicker (the person who ultimately follows the shortened links). Each is harmed to some extent by URL shortening.
There’s more, and you should read it all.
One of Joshua’s recommendations to minimize some of the harm is that websites do their own URL shortening instead of relying on middlemen. I’ve done some of that here, via the ShortURL plug-in for WordPress. Thus I use zeldman.com/x/48 instead of a much longer URL to notify my friends on Twitter about a new comment on an oldish thread. Likewise, zeldman.com/x/49 redirects to yesterday’s big post, “Write When Inspired.”
Rolling your own mini-URLs lessens the chance that your carefully cultivated links will rot if the third-party URL shortening site goes down or goes out of business, as is happening to tr.im, a URL shortener that is pulling the plug because it could neither monetize nor sell its service.
tr.im is now in the process of discontinuing service, effective immediately….
No business we approached wanted to purchase tr.im for even a minor amount.
There is no way for us to monetize URL shortening — users won’t pay for it — and we just can’t justify further development since Twitter has all but annointed bit.ly the market winner.
The Short URL Plugin for WordPress installs automatically. It provides simple statistics, telling you how many times a link has been clicked, sets up redirects automatically, allows you to choose a custom link style, and more. You’re not limited to shortening your own URLs, although that’s mainly how I use it; you can also shorten third-party URLs, turning your site into a miny TinyURL. I’ve used this plugin for months, with nothing but joy in its cleverness and usability.
[tags]ShortURL, plugin, WordPress, plugins, joshua schachter, tr.im, bit.ly, URL, Twitter, TinyURL, web, usability, internet, links, security[/tags]
Back in 2000, CSS co-creator Bert Bos set out to explain the W3C’s design principles—“to make explicit what the developers in the various W3C working groups mean when they invoke words like efficiency, maintainability, accessibility, extensibility, learnability, simplicity, [and] longevity….”
Eventually published in 2003, the essay, although ostensibly concerned with explaining W3C working group principles to the uninitiated, actually articulates the key principle that separates great design from the muck we normally wade through. It also serves as a warning to Bert’s fellow W3C wizards not to seek the dark magic of abstract purity at the expense of the common good. Tragically for these wizards, and for we who use their technologies, it is a warning some developers of W3C specifications continue to overlook.
In his introduction, Bert summarizes the humanistic value that is supposed to be at the core of every web standard:
Contrary to appearances, the W3C specifications are for the most part not designed for computers, but for people. … Most of the formats are in fact compromises between human-readability and computer efficiency….
But why do we want people to read them at all? Because all our specs are incomplete. Because people, usually other people than the original developers, have to add to them….
For the same reason we try to keep the specifications of reasonable size. They must describe a useful chunk of technology, but not one that is too large for an individual to understand.
Over the succeeding 25 web pages (the article is chunked out in pamphlet-sized pages, each devoted to a single principle such as “maintainability” and “robustness”) Bert clearly, plainly, and humbly articulates a series of rather profound ideas that are key to the web’s growth and that might apply equally admirably to realms of human endeavor beyond the web.
For instance, in the page entitled “Use What Is There,” Bert says:
The Web now runs on HTML, HTTP and URLs, none of which existed before the ’90s. But it isn’t just because of the quality of these new formats and protocols that the Web took off. In fact, the original HTTP was a worse protocol than, e.g., Gopher or FTP in its capabilities….
And that fact shows nicely what made the Web possible at all: it didn’t try to replace things that already worked, it only added new modules, that fit in the existing infrastructure. …
And nowadays (the year 2000), it may look like everything is XML and HTTP, but that impression is only because the “old” stuff is so well integrated that you forget about it: there is no replacement for e-mail or Usenet, for JPEG or MPEG, and many other essential parts of the Web.
He then warns:
There is, unfortunately, a tendency in every standards organization, W3C not excluded, to replace everything that was created by others with things developed in-house. It is the not-invented-here syndrome, a feeling that things that were not developed “for the Web” are somehow inferior. And that “we” can do better than “them.” But even if that is true, maybe the improvement still isn’t worth spending a working group’s resources on.
In his gentle way, Bert seems to be speaking directly to his W3C peers, who may not always share his and Håkon‘s humanism. For, despite what designers new to CSS, struggling for the first time with concepts like “float” and the box model may think, Bert and Håkon designed the web’s layout language to be easy to learn, teach, implement, maintain, and (eventually) extend. They also designed CSS not to overwhelm the newcomer with advanced power at the cost of profound complexity. (“CSS stops short of even more powerful features that programmers use in their programming languages: macros, variables, symbolic constants, conditionals, expressions over variables, etc. That is because these things give power-users a lot of rope, but less experienced users will unwittingly hang themselves; or, more likely, be so scared that they won’t even touch CSS. It’s a balance.”)
This striving to be understood and used by the inexperienced is the underlying principle of all good design, from the iPhone to the Eames chair. It’s what Jared Spool would call usability and you and I may consider the heart of design. When anything new is created, be it a website, a service, or a web markup language, there is a gap between what the creator knows (which is everything about how it’s supposed to work), and what you and I know (which is nothing). The goal of design is to shrink this ignorance gap while seducing us into leaping across it.
You can see this principle at work in CSS, whose simplicity allowed us to learn it. Although we now rail against the limitations of CSS 1 and even CSS 2.1, what we are really complaining about is the slow pace of CSS 3 and the greater slowness with which browser makers (some more than others) adopt bits of it.
Note that at one time we would have railed against browser makers who implemented parts of a specification that was still under development; now we admire them. Note, too, that it has taken well over a decade for developers to understand and browsers to support basic CSS, and it is only from the perspective of the experienced customer who craves more that advanced web designers now cry out for immediate CSS 3 adoption and chafe against the “restrictions” of current CSS as universally supported in all browsers, including IE8.
If CSS had initially offered the power, depth, and complexity that CSS 3 promises, we would still be designing with tables or Flash. Even assuming a browser had existed that could demonstrate the power of CSS 3, the complexity of the specification would have daunted everyone but Eric Meyer, had CSS 1 not come out of the gate first.
It was the practical simplicity of CSS that enabled browser engineers to implement it and tempted designers to use (and then evangelize) it. In contrast, it was the seeming complexity and detachment from practical workaday concerns that doomed XHTML 2, while XHTML 1.0 remains a valid spec that will likely still be working when you and I have retired (assuming retirement will be possible in our lifetime—but that’s another story).
And yet, compared to some W3C specs in progress, XHTML 2 was a model of accessible, practical, down-to-earth usability.
To the extent that W3C specifications remain modular, practical, and accessible to the non-PhD in computer science, they will be adopted by browser makers and the marketplace. The farther they depart from the principles Bert articulated, the sooner they will peter out into nothingness, and the likelier we are to face a crisis in which web standards once again detach from the direction in which the web is actually moving, and the medium is given over to incompatible, proprietary technologies.
I urge everyone to read “What is a Good Standard?“, and I thank my friend Tantek for pointing it out to me.
[tags]W3C, design, principles, bertbos, maintainability, accessibility, extensibility, learnability, simplicity, specs, standards, css, markup, code, languages, web, webdesign, webstandards, webdevelopment, essays[/tags]
Bigthink.com/jeffreyzeldman is your BigThink channel for all your BigThink Jeffrey Zeldman needs. Now playing at that URL are three Zeldman interview clips for your pleasure:
View early and view often. Happy watching and blogging.
[tags]bigthink, zeldman, jeffreyzeldman, interviews, internet, web, design, history, journalism, online, onlinejournalism, webpublishing, opensource, webstandards[/tags]
Information Architects Japan present Web Trend Map 4 – Final Beta, a map of leading currents of web thought and commerce.
A List Apart is in, of course, along with Amazon, Apple, Wikipedia, Twitter, PayPal, and many of your other favorites. For a close-up view, see it in Zoomorama.
Via Tech Crunch by way of lmarino.
[tags]web, trend, map, visualization[/tags]
In Issue No. 274 of A List Apart, for people who make websites: a website without a content strategy is like a speeding vehicle without a driver. Learn why content matters and how to do it right.
by JEFFREY MACINTYRE
Every website faces two key questions: 1. What content do we have at hand? 2. What content should we produce? Answering those questions is the domain of the content strategist. Alas, real content strategy gets as little respect today as information architecture did in 1995. MacIntyre defines the roles, tools, and value of this emerging user experience specialist.
by KRISTINA HALVORSON
It’s time to stop pretending content is somebody else’s problem. If content strategy is all that stands between us and the next fix-it-later copy draft or beautifully polished but meaningless site launch, it’s time to take up the torch—time to make content matter. Halvorson tells how to understand, learn, practice, and plan for content strategy.
And, in EDITOR’S CHOICE, from July 31, 2007:
by BRONWYN JONES
How is it that the very foundation of the web, written text, has taken a strategic back seat to design? Bronwyn Jones argues that great web design is not possible without the design of words.
[tags]contentstrategy, content, strategy, content strategy, web, webcontent, webdesign, userexperience, writing, editorial, Kristina Halvorson, Jeffrey Macintyre, Bronwyn Jones, alistapart[/tags]
Dear New York Times Mobile Edition:
While we applaud your use of typographically correct punctuation—a cause we ourselves have long advocated—we’d appreciate it even more if you would do it like professionals. Author in Unicode, the cross-platform standard.
Please stop using proprietary Windows characters in a bumbling, amateurish attempt to generate typographically correct open and close quotation marks. It doesn’t work cross-platform. Instead of nice quotation marks, the reader sees ASCII gibberish, making content harder to understand, and casting doubt on the credibility of the excellent reportage.
For less than you spent on WordPress, buy an iPhone or two, and let your editors and producers see what they are foisting on the public.
If you don’t know how to set quotation marks, we have tutorials.
If you know how, but your CMS is wrecking things, maybe it’s time for a new CMS.
[tags]nytimes, mobile, nytimesmobile, typographically, correct, typography, web, webtype, webtypography, unicode, windows, characters[/tags]
An Event Apart, the design conference for people who make websites, has posted its San Francisco 2008 schedule. Join us August 18–19, 2008 at the Palace Hotel for two jam-packed 9.5-hour-long days of learning and inspiration with Heather Champ, Kelly Goto, Jeremy Keith, Luke Wroblewski, Dan Cederholm, Tantek Çelik, Jeffrey Veen, Derek Featherstone, Liz Danzico, Jason Santa Maria, Eric Meyer, and Jeffrey Zeldman.
[tags]sanfrancisco, aeasf08, aneventapart, design, webdesign, UX, web, conference, conferences[/tags]