kottke.org posts about web development
Khoi Vinh has a new book coming out next month called Ordering Disorder: Grid Principles for Web Design.
“Ordering Disorder” is an overview of all of my thoughts on using the typographic grid in the practice of Web design. The first part of the book covers the theories behind grid design, the historical underpinnings of the grid, how they’re relevant (and occasionally irrelevant) to the work of Web designers — and a bit of my personal experience coming to grips with grids as a tool.
The second part of the book, which makes up its bulk, walks readers through the design of a full Web site from scratch, over the course of four projects.
Vinh did the art direction for the book himself, so it’s bound to be purty (and grid-y). The perfect early holiday gift for the web designer in your life.
Dan Catt has written part one of a users guide to websites. It explains why sites with “social” features are so difficult to scale beyond a few hundred users and the necessary compromises made that piss off the sites’ vocal power users. Excellent stuff.
That cool “user-who-did-x-also-did-y” feature was calculated whenever you visited your homepage. This worked for the 500 initial users (the site’s builders and their friends) but started to take too long when they hit 1,000 users.
The site solved this by caching (storing the results for an amount of time) the calculations. The users complained that they were being shown incorrect data because everyone they knew was doing stuff all the time and it wasn’t updating fast enough.
The site solved this by invalidating (removing the stored results so they need to be recalculated) the cache whenever anyone did anything. The site hits 5,000 users and the cache is being invalidated every sodding second … the homepage takes too long to load.
The site solves this by writing their own custom code for managing off-line tasks and puts everything into a task queue to be processed.
98% of users accept that the section that used to be called “What your friends are doing right now” gets changed to “What your friends have recently been doing”. The other 2% of users throw a tantrum and accuse the site of being run by useless gibbering idiots.
Dark Patterns are UI techniques designed to trick users into doing things they otherwise wouldn’t have done.
Normally when you think of “bad design”, you think of laziness or mistakes. These are known as design anti-patterns. Dark Patterns are different — they are not mistakes, they are carefully crafted with a solid understanding of human psychology, and they do not have the user’s interests in mind.
For instance, Privacy Zuckering is a dark pattern implemented by Facebook to get users to share more about themselves than they would like to. (thx, @tnorthcutt)
Want to see the state of the art in web design using web fonts and Typekit? Check out Lost World’s Fairs. It’s all good, but Frank Chimero really knocked it out of the park with the 1962 Atlantis World’s Fair. With HTML5 and web fonts, experimentation with web design seems open and fun again; reminds me of the 90s a bit.
So, every time I post one of these HTML5 games or apps (like The Game of Life), I got tons of email from people who say that it could be done much easier or better in Flash. Which is probably true. But I post these experiments because I’ve been using HTML since 1994 and I love it. It’s simple (or can be), open, can be edited with any old text editor, and increasingly capable. Oh sure, HTML can be maddening at times, but I’m fascinated and happy to see it maturing into something that has so much functionality.
A letter from Steve Jobs about why they don’t allow Flash on iPhones, iPods, and iPads. (Notice he specifically uses the harsher “allow” instead of the much softer “support”.)
Though the operating system for the iPhone, iPod and iPad is proprietary, we strongly believe that all standards pertaining to the web should be open. Rather than use Flash, Apple has adopted HTML5, CSS and JavaScript — all open standards. Apple’s mobile devices all ship with high performance, low power implementations of these open standards. HTML5, the new web standard that has been adopted by Apple, Google and many others, lets web developers create advanced graphics, typography, animations and transitions without relying on third party browser plug-ins (like Flash). HTML5 is completely open and controlled by a standards committee, of which Apple is a member.
Jobs sort of circles around the main issue which is, from my own perspective as heavy web user and web developer: though Flash may have been necessary in the past to provide functionality in the browser that wasn’t possible using JS, HTML, and CSS, that is no longer the case. Those open web technologies have matured (or will in the near future) and can do most or even all of what is possible with Flash. For 95% of all cases, Flash is, or will soon be, obsolete because there is a better way to do it that’s more accessible, more open, and more “web-like”.
Typekit launched today (details here).
This will change the way you design websites. Add a line of code to your pages and choose from hundreds of fonts. Simple, bulletproof, standards compliant, accessible, and totally legal.
I haven’t had a chance to play around with this yet, but hope to soon. And hey, you can use Silkscreen with Typekit.
Mark Pilgrim explores the question: why do we have an IMG element in HTML?
Why not an element? Or an element? Why not a hyperlink with an include attribute, or some combination of rel values? Why an ![]()
element?
What Pilgrim doesn’t touch on was how that IMG tag drove adoption of Mosaic. Having images embedded right into web pages was like Dorothy stepping out of her house and into the lush color of Oz. (via waxy)
Really inspiring design by the folks at the newly launched The Bold Italic. It’s webby and magazine-y at the same time, but not overly so. Looks great on the iPhone too. Jealous. (via @timoni)
Jeff Veen has a look at how Typekit protects fonts served through the service.
To that end, our Javascript is minified and the fonts themselves are represented as Base64 encoded strings. You may see right through this, but the vast majority of web users wouldn’t know what to make of it.
Those Base64 encoded strings are then placed right into the CSS file. And even better than that, the fonts are split up into multiple files and recombined using the CSS font stack. Pretty clever stuff.
Adobe has discontinued HomeSite. Nick Bradbury, HomeSite’s creator, has some parting thoughts.
Sometimes in this blog I’ve made disparaging remarks about HomeSite, but that’s not because I disliked it. It’s just that it’s hard to look at something you created so long ago without seeing all the mistakes that you’ve learned not to make since then. I’m actually very proud of HomeSite, and very thankful that it enabled me to quit my job and work at home. And, funny enough, HomeSite is also what paid for the home I’m living in now.
All of my web stuff up until mid-2002 was done in HomeSite…it’s where 0sil8 thrived and kottke.org was born. I still haven’t found a piece of web authoring software that feels as comfortable as HomeSite did back then.
Jakob Nielsen says: stop masking passwords in web input forms.
Usability suffers when users type in passwords and the only feedback they get is a row of bullets. Typically, masking passwords doesn’t even increase security, but it does cost you business due to login failures.
Sing it, brother. It’s even worse on the iPhone…even with the last letter thing that it gives you, I still mistype passwords all the time.
Typekit is an upcoming typeface hosting service which will provide vetted fonts that you can include in your site’s stylesheet using the @font-face mechanism.
That’s where Typekit comes in. We’ve been working with foundries to develop a consistent web-only font linking license. We’ve built a technology platform that lets us to host both free and commercial fonts in a way that is incredibly fast, smoothes out differences in how browsers handle type, and offers the level of protection that type designers need without resorting to annoying and ineffective DRM.
What a great idea. And web entrepreneurs pay attention, this is how to make a compelling online property: take an idea that everyone loves in theory but doesn’t use in practice because it’s a pain in the ass (in this case, embedding type on the web) and offer a hosting service to solve that problem. YouTube did this with videos, Blogger/Blogspot, TypePad, & Wordpress did this with blogs, Flickr did it with photos, etc. etc.
I added a new feature to kottke.org over the weekend: live updating on the home page. If you leave kottke.org open in your browser (with JavaScript on) and I post a new link, the page will display a message urging you to refresh to view some new posts. The page title changes too, so if you have it up in a tab, you can tell at a glance if something’s new. Right now the page checks for new posts every ten minutes, but that could change depending on server load, etc. Thanks to Twitter Search and Tumblr for the inspiration.
As promised, the redesign of this site started last week is still in motion. I’ve just made a bunch of small tweaks that should make the site more readable for some readers.
- Fonts. In response to a number of font issues (many reports of Whitney acting up, the larger type looking like absolute crap on Windows), I’ve changed how the stylesheets work. Sadly, that means no more lovely Whitney. :( Mac users will see Myriad Pro Regular backed up by Helvetica and Arial while PC users will see Arial (at a different font-size). In each case, the type is slightly smaller than it was previously. I’m frustrated that these changes need to be made…the state of typography on the web is still horrible.
- Blue zoom border. Oh, it’s staying, but it’ll work a bit differently. The blue sides will still appear on the screen at all times but the top and bottom bars will scroll with the content. I liked the omnipresent border, but the new scheme will fix the problems with hidden anchor links and hidden in-page search results and allow for more of the screen to be used for reading/scanning. It breaks on short pages (see: the 404 page) and still doesn’t work quite right on the iPhone, but those are problems for another day.
- Icons. Updated the favicon and the icon on the iPhone to match the new look/feel.
- Misc. Rounded off the corners on the red title box. Increased the space between the sidebar and the main content column.
Thanks to everyone who offered their suggestions and critiques of the new design, especially those who took the time to send in screenshots of the problems they were having. Feedback is always appreciated.
The design of kottke.org has been mostly the same since 2000…a garish yellow/green bar across the top and small black text on a white background everywhere else. (See the progression of designs since 1998.) People absolutely hated that color when I first introduced it1, but it stuck around — mostly out of laziness — and that pukey yellow became the most visible brand element of the site.
Two days ago, I refreshed the design of the site and, as you may have noticed, no more yellow/green. The other big changes are: bigger text set in a new font, a blue “zoom” border around the page, and the addition of titles to the short posts.
(A brief nuts and bolts interlude… For most of you, the site will look like this. If you’ve got Myriad Pro on your machine — it comes free with Acrobat Reader and Adobe CS — it’ll look like this…this is the “intended” look. And if you’re a fancypants designer with Whitney installed, you’ll get this rarified view, which I did mostly for me. On IE6, the site will be legible and usable but somewhat unstyled. If you’re not seeing something that looks like one of the above screenshots — if the text is in all caps, for instance — please drop me a line with a link to a screenshot and your browser information. Thanks!)
The blue “zoom” border is the biggest visual change, and it’s an homage to what is still my favorite kottke.org design, the yellow zoom from 1999. I like that kottke.org is one of the few weblogs out there that can reach back almost ten years for a past design element; the site has history. In a way, that border is saying “kottke.org has been around for ten years and it’s gonna be around for twenty more”. At least that’s how I think about it.
I’ve already gotten lots of feedback from readers, mostly via Twitter and email. There were a few technical issues that I’ve hopefully ironed out — e.g. it should work better on the iPhone now — and a couple which might take a bit longer, like the border messing with the page-at-a-time scrolling method. Some people like the changes, but mostly people don’t like the new design, really dislike the blue, and generally want the old site back. This is exactly the reaction I expected, and it’s heartening to learn that the old design struck such a chord with people. All I’m asking is that you give it a little time.
My suspicion is that as you get used to it, the new text size won’t seem so weird and that blue border will likely disappear into the background of your attention, just as that hideous yellow/green did. A month from now, your conscious mind won’t even see the blue — chalk it up to something akin to banner blindness…brand blindness maybe? — but your subconscious will register it and you’ll just know where you are, safe and sound right here at good ol’ kottke.org. And if that doesn’t work, we’ll tweak and move some things around. Design is a process, not a result, and we’ll get it to a good place eventually, even if it takes twenty years.
[1] I wish I had access to my email from back then…everyone hated it and wanted the old design back. Before landing on the yellow/green color, I tried the golden yellow from the previous design, a blue very much like the blue in the current border, and then red. I think each color was live on the site for a few days and my intention was to just keep switching it around. But then I got bored and just left the yellow/green. Gold star to anyone who remembers that short phase of the site. ↩
Ecommr is a collection of interface and design elements from ecommerce sites. I wish there were a bit more context around each screenshot (e.g. which interface element is the focus and what’s novel about it) but it’s a good start.
Video visualizations of how the HTML rendering engine underneath Firefox’s hood renders mozilla.org, a Wikipedia page, and Google Japan.
A wonderful (and wonderfully long) post by Dan Hill on how he and his team thought about and executed the Monocle web site.
None of what follows is rocket science, and it’s not the place to look for thoughts on 2.0/3.0, social software, or urban informatics. That would be in the accounts of different projects. But if you’re interested in the honest craft of website work, almost deliberately old-fashioned ‘classical’ web design — and how to ally this with innovation in magazine publishing — the following should provide a decent account of several of the key decisions in this particular project.
Dan’s thoughtful approach should be required reading for anyone building media web sites.
Frank Bruni, the food critic for the NY Times, wrote yesterday about the difficulty of getting a reservation at David Chang’s new Momofuku Ko restaurant. Ko’s online reservation system is the *only* way of procuring a seat at the tiny Manhattan restaurant…no walk-ins, no friends of the chef or celebs getting preferential treatment. It works more or less like Ticketmaster’s online ticketing: you select the number of guests, it shows you the available reservation times (if any), you click on a time, and if that time is still available when you click it, only then does the system hold your choice while you fill in some information.
It’s a simple system; seats for dinner are released on the site a week in advance at 10am each day and the people that click on their preferred times first get the reservations. Ko takes only 32 reservations each night and the restaurant is one of the hottest in town, which means that all the reservations are gone each day in seconds…sometimes in 2 or 3 seconds. Just like Radiohead tickets on Ticketmaster.
Except that diners are not used to this sort of thing. One of Bruni’s readers got irritated that he got through to the pick-a-time screen but then when he clicked on his preferred time was told that the reservation was already gone. Someone had beaten him to the punch. So he emailed the restaurant for an explanation. The exchange between the restaurant and the snubbed patron should be familiar with anyone who has done web development for clients or any kind of tech support.
In a nutshell, the would-be patron said (and I’m paraphrasing here), “your system is unfair and broken,” and the folks at Ko replied, “sorry, that’s how the internet works”. The comments on the post are both fascinating and disappointing, with many people attempting to debunk Ko’s seemingly lame excuse of, well, that’s how the internet works. Except that’s pretty much the right answer…although it’s clearer to say that that’s how a web server communicates with a web browser (and even that is a bit imprecise). When the pick-a-time page is downloaded by a particular browser, it’s based on the information the web server had when it sent the page out. The page sits unchanged on your computer — it doesn’t know anything about how many reservations the web server has left to dole out — until the person clicks on a time. An anonymous commenter in Bruni’s thread nails the choice that a web developer has to face in this instance:
This is a multi-user concurrency problem that all sites with limited inventory and a high demand (users all clicking the button all at the same time) have to deal with. It’s not an easy problem to solve.
The easier method (which the Ko site has chosen) is to not “lock” a reservation slot until the very end. You submit your party size and the system looks for available slots that it knows about. It shows you the calendar page, with the available slots it knows about (if any). This doesn’t update in real time because they haven’t implemented it to know about the current state of inventory. This can be done, but it’s more complicated.
The more complicated method is to lock a reservation slot upon beginning of the checkout process, with a time out occurring if the user takes too long to finish, or some other error occurs (in other systems this can be a blacklisted credit card number). If this happens, the system throws the reservation slot back into the pool. However, you need to give people a mechanism to keep trying for ones that get thrown back into the pool (like a “Try Again” button).
Building something like this not impossible (see Ticketmaster) but requires a much more real-time system that is aware of who has what, and what stage of the checkout process they’re in - in addition to total available inventory. Building a robust system like this is not cheap.
Even then, you might get shut out. You submit your party size, everything is already gone, and you never get to the calendar page. It just moves up the “sold out” disappointment to earlier in the process.
A subsequent commenter suggests using “Web 2.0” technologies (I think he’s talking specifically about Ajax) but as Anonymous suggests, that would increase the complexity of the system on the server side (unnecessarily in my mind) while moving up the “‘sold out’ disappointment to earlier in the process”. Plus, that sort of system could put you “on hold” for several minutes while the reservations are taken by the folks in front of you until you’re told, “too bad, all gone”. I’m not sure that’s preferable to being told sooner and may result in much more irritation on the part of potential diners.
In my opinion (as a web developer and as someone who has used Ko’s reservation system from start to finish), Ko’s system does it right. You’re locked into a reservation by the system only when you’ve chosen exactly what you want. It favors the web user who’s prepared & lucky and is simple for Ko to implement and maintain. That the logic used to produce this simple system takes three paragraphs to explain to an end user is irrelevent. After all, a restaurant dinner is easy to eat but explaining how it came to be that way fills entire books.
This might seem too inside baseball for most readers — the number of people interested in new NYC restaurants *and* web development is likely quite small, even among kottke.org’s readership — but there’s an interesting conflict going on here between technology and customer service. What kind of a problem is this…technological or social? Bruni’s correspondent blamed the technology and much of the focus of the discussion has been on the process of procuring a reservation. But the main limiting factor is the enormous demand for seats; tens of thousands of people a week vying for a few hundred seats per week. The technology is largely irrelevent; whatever Ko does, however well the reservation system works or doesn’t work, nearly all of the people interacting with the restaurant are going to be disappointed that they didn’t get in.
It’s been awhile since the last conversation about gender diversity at web conferences. Here’s a particularly high profile example of more of the same: Google’s just-announced Web Forward conference appears to have a single woman speaker out of 38 total speakers.
Lampoon of an hilariously crappy maintenance request web app at University of Pennsylvania.
Yes, I know that it says “Search Criteria Required!” at the top of the screen, in red letters, with an exclamation point. But that’s just to fool you into thinking that search criteria are required. In fact, the only thing that’s required (or even permitted!) for you to do at this point is to click on the large button labelled “Insert” at the top of the page.
New web site for Hoefler & Frere-Jones, the noted and celebrated typeface designers, including a weblog. Subscribed. Oh, and the browser fonts of choice for the meticulous duo? “Lucida Grande, Lucida Sans, Verdana, Georgia, Helvetica, Arial” (thx, jonathan)
An interview with Paul Ford about the work that he’s been doing at Harper’s, specifically putting the magazine’s entire archives online. “It’s obviously a lot for one person working alone to bring hundreds of thousands of pages online while writing, editing blog content, programming a complex, semantic web-driven site, and providing tech support for an office.”
Stuff from Steve Jobs’ WWDC keynote this morning: new version of Safari for Mac *and* Windows (downloadable beta), developing for iPhone can be done with HTML & JavaScript…just like Dashboard widgets, new Finder and Desktop, and Apple’s web site is completely redesigned.
Update: From the reaction I’m hearing so far, it’s difficult to tell what was more disappointing to people: Jobs’ keynote or The Sopronos finale. Also, a Keynote bingo was possible (diagonally, bottom left to top right)…no report yet as to whether anyone yelled out during the show.
Update: TUAW is reporting that someone in the crowd yelled “bingo” 35 minutes into the keynote, but if you look at the card, a bingo was only possible when the iPhone widgets were announced towards the end. Disqualified for early non-bingo! (thx, alex)
Newer posts
Older posts
Stay Connected