Digital Web is running a big triple-issue today, with a book review and author interviews.
Yes, I will try to keep these at a minimum since I'm well aware it's tedious to read someone else's excitement about their new pet project... but it's the first review and there are some things to respond to, so hopefully you can afford a little slack just this once.
Some things that jumped out at me from the review that might stand for a bit of extra author's interpretation:
The book is all about the designs on the CSS Zen Garden—but not just about how different designers faced the Zen Garden challenge. It also uses the designs to take readers on a tour of everything they need to know about using CSS on a Web site. Because the HTML file stays the same, it’s easy to really zero in on the CSS and how it’s used.
Well, not quite everything you need to know about using CSS. No bones about it, this is an intermediate to advanced book, and we've taken away some of the basic lessons (there is not a single box model illustration to be found, for example) in order to skip to advanced design and integration techniques. It's about using CSS for design, not learning CSS.
I often get contacted for 'CSS design work', from which I begin a lengthy process of explaining that yes, I know CSS syntax, but CSS isn't really the point of it; the design is more important. Perhaps I'm just funny about making the distinction and it doesn't really matter, but I suppose I just suspect the 'CSS = design' mindset leads down the road to expendable, interchangeable templates that don't properly solve design problems for the client in question.
Anyway, getting back on track:
The format was easy to follow, with the information divided up into nice little bits, each so easy to digest that when I reached the end of a section, I had to stop for a moment to realize how much I’d actually covered.
Aha, it worked! The format is something like this: each design gets 6 pages. The intro page is a full screenshot and an introduction blurb, so it's a little content-light. The other 5 pages form the bulk of the actual 'information'.
It's a little deceptive because flipping through each design feels like only the briefest of explanations, until you dig in and actually start reading. Those 5 pages translate to about 6 or 7 full pages in Word, which (in most cases) were condensed down from 7 or 8 in the original draft, sometimes more. So we were forced to optimize our wording, cut the extraneous bits, and condense as much as we could. There's a lot in that small space.
The tips in the margins were excellent. Make sure you take the time to read them.
Shh, secret tip: when you have to cut a bunch of information you don't really want to cut, try moving it to the margins. (Many tips are extensions of the text in the main body.)
I would have liked the number associated with the design on csszengarden.com on each page, down in the footer maybe. It was only listed once at the beginning of the chapter.
Interestingly, in my original interior design draft there was more of a focus on the design number. I don't think I went quite as far as she's suggesting, but it did concentrate on the number more than the final design New Riders put together for us. Incidentally, there were no individual design URLs originally, there was simply a reference to the site at the beginning of the book, and that was it. Luckily I caught that and forced the change through late last year (much to the chagrin of the production team, and I don't blame them, but it had to be done).
Sometimes I felt like a subject was just touched on, but that has more to do with the breadth of topic here (everything design- and CSS-related) than a shortcoming of the book and the authors provide lots of links and resources for more reading.
Valid point, to be sure. It was a tricky balancing act, fitting everything into the format we chose and deciding where it all went. Deciding what to cut was never easy, and there were certainly areas I wish we could have explored a lot more.
Although the topic is broad, there’s a lot of detailed info here. I picked up several CSS tidbits that helped me immediately (like how to use relative positioning with absolute positioning).
I think Molly and I wrote about this particular topic at least twice each before edits. There are about 3 explanations left in the end of varying (and complementary) depth, so it looks as if at least one of them will stick.
Seriously, I don’t recommend reading it from beginning to end in one sitting.
Neither do I. I'm a big fan of books that are broken into little bite-sized chunks. I absolutely love collections of short stories, for example. So that's what we've tried to do; each design is meant to be a self-contained 'short story', allowing you to read them in any order you wish.
I do recommend reading it at the computer with your Web browser open and pointed to csszengarden.com. I used three tabs while I was reading it. One pointed to the design, one to the CSS for the design and a third to examine different graphics called out in the CSS.
Great way of doing it! Some of the topics are more conducive to viewing the source than others; many will read well without a computer at hand. But inevitably, to really dig in, you'll want to play with the CSS itself.
Thanks Karen, thanks Digital Web.
A funny standard has shown up on larger Canadian retail sites that doesn't appear in other sectors.
Question: the site you're building requires support for multiple languages. Each needs equal prominence. How do you handle this?
Due to the bilingual nature of the marketplace in my home and native land, an interesting standard has emerged amongst larger e-commerce sites in Canada. Splash pages are making a comeback, or more accurately, they never really died. What's common on the sites of large retail stores is a mostly useless intro page that forces you to choose your language. Observe:
- Canadian Tire
- Rogers Video (or the even more horribly designed Blockbuster splash, which doesn't have any visible branding until you hover, and redirects here when scripting is disabled. Whoops.)
- Future Shop
These are all retail outlets. If you take a look at other industries which must abide by the same language laws, you see something remarkably different:
There are exceptions; HBC is a retail chain that merely includes a 'français' link in the top corner. And it may be that the latter sites are serving up customized content based on IP address, though I'll never be able to test that from here.
Still, it's interesting to observe the single-mindedness in approaching this problem. In previously working with retailers that have chosen the splash page approach, I've come to learn that the choice is driven by politics. If you provide an English page with a link to the French equivalent, or vice-versa, you risk alienating a potentially large percentage of your customer base. So by presenting both on equal ground and forcing the consumer to choose, you side-step the issue and add a half-second delay to their visit to your site. Presumably the adverse reaction to a splash page that might cause some to leave the site completely is far less of a concern than the adverse reaction to not playing the language game well enough.
Incidentally, this also used to be a popular trick for retailers to force a choice between US and Canadian currency. By only providing one method of switching between currencies at the very beginning of the visit to the site, the customer would be far less liable to switch to another currency and compare. Thus, the markup built in to US prices (on top of the exchange rate benefits, when there were any) would less likely be spotted. Sometimes it was justified (extra shipping expense), sometimes it was just a cash grab. Either way, there's no reliable method of enforcing one currency or the other, and if an American ordered in Canadian dollars they would generally have had to honour the price. By taking away an easy method for the customer to compare, the problem was usually alleviated.
: Many have suggested use of the Accept-Language HTTP header to redirect automatically based on which language the user's browser is configured for. While it's not foolproof (what happens when someone is using a computer/OS in the wrong language? What if their own is set up properly, but they find themselves at an internet café that isn't?) it seems to be an elegant solution with just one caveat: make sure to provide the user with a way to change their language after the fact.
The wait is over.
Our author copies showed up today; the Zen of CSS Design is now an actual book, with real words and pictures and everything. Pretty crazy, really, to see the last six months of work packaged up into a neat ~300 page package.
The good news is that while the author's copies just showed up, it would appear they were shipped when the books were sent to the distributors. Amazon is sending out shipping notices already, and those who have design work featured in the book have even started receiving their copies. Jon Hicks and Egor Kloos both saw the finished book before I did, in fact (albeit by only a few hours).
This is all I know at the moment, so hold onto the email for now until you hear from whoever you pre-ordered with. Any further communication should be directed their way anyway, since it's thoroughly and completely out of our hands now. Thanks for your patience, it's finally happening!
Some housekeeping: a listing of where I'll be over the next month. Feel free to ignore this one if you're not the conference-going type.
Somehow I managed to pack my schedule in the upcoming weeks, so here's a quick listing of places I'll be (also now available in convenient sidebar form on most two-column pages on this site.)
Northern Voice is a brand new blogging conference happening right in my own back yard. Short notice, as it’s running in Vancouver on Saturday, February 19th, but I couldn't pass it by. No specific speaking duties here, I’ll just be one of the crowd.
Though I suppose it's possible I may be up on stage for at least a few minutes...
Next, on to South by Southwest in Austin, TX from March 11 to 15 this year. I’m pulling double-duty, on both a refresh of last year's panel, “More HiFi Design with CSS”, and an as-of-yet untitled panel on what web design might look like in ten years with Mr. Hicks, Mr. Allsopp, Ms. Free, and Mr. Bowman.
And there's also 20x2, a creative evening session billed as "Twenty Speakers. One Question. Two Minutes Each." Having the distinction of completely missing last year's, I've no idea what to expect, but I've got two minutes; should be fun.
Next up we have the just-confirmed stop at Web Design World San Francisco on March 21st and 22nd. I'll be co-presenting “The Marriage of Presentation and Structure” with Molly Holzschlag, my distinguised co-author.
For those keeping score, I'll be playing the role of Ethan Marcotte in a refresh of the WDW Boston session last fall, although I'm not quite sure I can bring myself to utter the phrase "pimp my own kool-aid".
So that takes care of the left and the middle, finally on to a stop on the right. Flash in the Can runs from April 9 to 11 in Toronto, Ontario. I’ll be holding down the CSS fort at a predominantly Flash-oriented festival as I try and dispell the 5 Myths of CSS Design.
I suspect a meetup with folks from Toronto who actually read this site will be in order.
Dean Edwards is going to need a new name for his pet project. The question is: will it still be necessary?
It's official: there will be an Internet Explorer 7. There's been a lot of activity over at the MSDN IEblog lately, so the former cone of silence covering any form of news about Internet Explorer has been lifted for a while. It's no big surprise that Microsoft is releasing an update to their flagship browser.
What is surprising, on the other hand, is that Internet Explorer 7 will be available to Windows XP users. In mid-2003 it was announced that IE/Mac had seen its last update, and IE/Win was no longer going to be available as a stand-alone product. It was largely perceived to mean the browser was now only going to see an update when the operating system did, and given Longhorn's continual slip date, this could only mean the reign of IE6 would continue for many years to come.
So why the strategy shift? Or is this even much of a shift? It was perceived that the release of Longhorn would be the next time we'd see an update to IE, but as far as I'm aware it was never confirmed. This could be right in line with the long-term plan, but something tells me it's a reaction, more than anything.
It's 2005. Internet Explorer 6 was released in late 2001, and itself a minor improvement over IE5 which was originally released in 1999. There's a whole lot of stagnation going on, and we all know what has happened in the past few years. IE security exploits have become routine, and the alternative choices are all vastly superior. The public is starting to catch on to both facts, and for the first time in a long, long while we're seeing IE's market share slipping. Given the interesting things going on in the web application space (think Google here), the future of the browser is bright. That, more than anything, is a reason to get back in the game.
The question we all want to know: any chance of rendering improvements? A minor patch for IE6 was released as a component of XP Service Pack two last year. I still have yet to hear of a single rendering difference between IE6 stock and IE6 post-XPSP2, so it was a security update with a pop-up blocker. Will Internet Explorer 7 bring anything else to the table like improved CSS2 support, or even just a mass fixing of all the outstanding bugs? About the best we can do is wait and see what the first betas bring.
I'm not optimistic, either way. No matter what IE7 gets right, the browser upgrade cycle is slower than ever. There are so many compelling reasons to stop using IE6 now, but the market has done next to nothing about it. Even if IE7 is perfect, we'll be supporting IE6 for a long time yet. I've predicted 2010 as the year we might be able to stop; even that might be wishful thinking, unfortunately.
* html, baby.
Whether you just quit your job to pursue your dreams, or you've simply had a request from a long-time client, sooner or later you're going to have to design a set of business cards or letterheads or something else that ultimately forces a trip to the printing press.
Since web geeks think in pixels and RGB, it's a daunting new world to head into unequipped. Over the years across quite a few print jobs by now, I've had to learn by trial and error. As someone used to thinking in RGB, I've looked high and low for a good resource to turn to for help in converting that knowledge to CMYK. This may not be that resource, but I figure I've amassed at least the beginnings of a how-to on the subject. Consider it non-authoritative, but hopefully useful. Most of the knowledge contained within applies to Photoshop, mainly because I've had the most trouble with it.
CMYK vs RGB
First, the basics. For anyone who hasn't owned a printer in the past decade, CMYK, or Cyan Magenta Yellow Black, refers to the colour of inks used in the printing process. CMYK inks combine in proportions to form solid colours; Yellow and Magenta with a bit of Black form a dark maroon, for example. But there are some major differences between the RGB colour model your computer display uses and the CMYK process many printing presses use, and that's where the first point of confusion often comes in.
Rule Number One, above all else in print, is that what you see on paper will not look like what you have on screen. With tweaking it may be possible to bring the two closer in line, but suffice it to say that when first printing out your work there's a very good chance you'll find yourself horrified at the outcome. Never trust what you see on screen.
CMYK isn't the final word in ink choice, it just happens to be fairly common. For business cards in particular, another potential choice is spot colour. No one says you have to print full colour, and thus use four inks. Effective business cards often use two or three, and the reason is simple: it can be quite a bit cheaper. But pulling out any of the three from the CMYK combination will produce ugly results, so spot makes use of solid coloured inks that span a wide range outside of what your standard CMYK combination is capable of. And specialized spot colours like metallic and neon shades are possible as well.
Of course, you can use more than four spot colours, and potentially combine spot and CMYK in the same printing, but once you start ranging into complicated print jobs the labour involved in producing them—and thus your final cost—quickly increases.
To further complicate things, CMYK can be printed digitally or on an offset press. The latter is a traditional printing press that requires a plate to be created for each colour of ink that prints. For CMYK, that means each of the four inks must be separated into its own plate and printed individually. As you might imagine, printing this way is more expensive due to the labour involved in creating the four plates, or separations as they're known. A digital press, on the other hand, is more or less simply a colour laser printer. It may be a touch more expensive than your garden-variety office colour laser, but the output is pretty much the same. Printing digitally is generally cheaper.
Alright, next up—once you've chosen your inks, how in the world do you work with the colours on an RGB screen? This is where I've been stuck for years, and I'm still not sure I have a solid handle on it, but it's worth passing on what I know (and following the comments on this article for advice from those who know better).
Note: if you haven't mastered the curves, levels, and channels of Photoshop, now's the time to brush up because you're going to need them (the linked articles are the first respective results I could find on Google; they barely scratch the surface, you'll want to keep digging).
First of all, we've established that an on-screen colour will not look the same printed. Again, there are major differences between RGB and CMYK, or more specifically, light-based colour and ink-based colour, that prevent this from ever being possible.
Colour management is a deep and complex science, and the best coping strategy I've found so far is to try and work around it. Pantone, which you have probably heard of, is one of a number of colour-matching systems that basically gives you a palette of numbered, pre-printed swatches to choose from that accurately represent the final colour.
The advantage is that if you use that exact Pantone number, on that exact paper, you know exactly what you're going to get. It won't look the same on-screen of course, and your software has to support it (in Photoshop for example, when you have the colour picker dialogue open, hit the 'Custom' button to get a list of different colour-matching systems and their various palettes).
The disadvantage is that you won't likely have your own set of printed swatches. An official set is pricey—a few hundred local currency for what is essentially a chunk of ink samples. You can pick up cheaper books off the shelf of your local art book store that are more approximations than accurate matches. Ideally though, your print shop will have a set on hand. If you're able to make a trip first to go pick your palette ahead of time, you can save a lot of effort later.
Working With Process/CMYK
Colour matching systems work best in conjunction with flat colour and pre-defined gradients, so the text and vector output from Illustrator or InDesign, for example, is a great use case. But what if you're working with heavily photographic material and don't have that luxury? Start throwing in overlays and other forms of colour variance, and you're going to quickly run into problems that Pantone won't help. Without having direct access to the final output device, you'll want to minimize test runs at the print shop to keep costs down (and avoid going back and forth to proof them) so you need to know ahead of time what you're up against.
If you're printing digitally, fortunately proofing is relatively simple—you have a colour printer, right? Inkjet or otherwise, these days you don't even need a high-quality printer. A $50 special at the local hardware store is more than enough. The trick is that you're not looking for high-end, ultra-accurate results; you're looking for a rough approximation to see how much the colour is going to shift on you.
What I do is build my file in RGB from start to finish, and just before I'm about to print, I save a copy of the file and convert it to CMYK, then print that. If it's a first shot, the proof will come out shockingly ugly and muddy, which means I'm on the right track. Again, this is just a rough approximation of the final colour, but it will give you a good idea of how far off the mark you are. Alternatively, Photoshop has a 'Proof Colors' setting (Ctrl + Y or Cmd + Y) which can apply the current CMYK profile and soft proof what it will look like on paper, but it generally won't shift as much as an actual print will.
Now this is where the fun starts. How do you take that horrible output and get it to match the prefect vision you have in mind (and just finished creating on-screen)? Adjustments, and lots of them. You can either go back to the RGB original and adjust elements there, knowing what you now know about the final output, or you can work directly on a CMYK copy.
What do you adjust? It depends on the output. If your blues are blowing out to a bright ugly green, it might be wise to back off the yellow and boost the black. If your reds are too grey, it's worth toning down the black and bump up the magenta. How do you adjust? Again, this is where channels come in handy. I've had luck going back to the RGB file and lightening everything globally to tone down the black. For major 4-colour corrections it's often worth it to flatten and save a copy of the file, converted to CMYK (Image -> Mode -> CMYK Color), and then apply curves or levels to each of the individual ink channels. I prefer levels for most operations, but more print-aware people will probably steer you to curves. Some selective masking to adjust the more problematic areas is often required as well.
Placing some superfluous bars of colour in the margins before you print can help cut down on the colour checks. If you know ahead of time which colours will be problematic, you can provide a range of tonal variations, mixing in varying proportions of ink. After a test run, assuming you're in the right ballpark, you simply choose a better colour from the test strip and be done with it. Doing this cuts down on the printer runs trying to nail down the precise shade.
At some point though, you'll have to get a proof from the print shop, to see how far off you were and to have a reference for further adjustment, if necessary. Printing digitally, this isn't much of a problem—they don't need to do much more than drop your file into their template and send it through the printer. Expect to have to come back later to view the result though, since they won't drop everything to get your proof done.
Printing offset on the other hand, is a bit different. Unless you have the ability to create separations yourself, which you probably shouldn't be doing anyway, the print shop will need to spend a bit more energy outputting those and running a proof. As far as I'm aware, the machine needs to be fully inked to print them too, so at this point the proof is what you're going to get, barring any unforeseen disasters. It's costlier to back out and make corrections at this point, although still possible.
Now, assuming your inkjet printer proved up to the task and the trial press run isn't too far off what you were expecting, you should be ready to give the go-ahead at this stage. If you're still not satisfied, you'll have a guide to compare against the proofs you created earlier. You'll be able to pick up spots that have changed dramatically between the two proofs, and assuming you can tell why they've shifted (basic colour theory applies here—yellow and cyan make green, red and yellow make orange, anything and black makes dingy brown or purple) you can adjust to suit. There's a certain amount of guesswork still, but armed with your set of proofs you have an effective tool for comparison, which you can use to squash all but the subtlest of colour shifts.
Working With Spot
Let's say you've decided to use spot colour, you've picked your Pantones, and now you're ready to design. What next? Now you have to start thinking in limited colours, and your software is going to play a big role; nothing you know about CMYK translates to spot. My experience is limited to Photoshop and Illustrator, but there's a relatively easy method of pulling off spot in each.
In Illustrator, create new swatches for your custom colours by clicking on the arrow in the swatch palette and hitting 'New Swatch'. In the options menu, choose 'Spot' as your colour type and adjust the sliders to approximate your colour choice. Repeat for each ink, and you now have a set of spot colours to work with. Use them as solids, adjust their opacity, or mix them together in gradients; as long as you stick to this set, your Illustrator artwork will be set up properly for the print job. Technically they don't even have to be the same colour as your final output either. Because each separation is printed as a greyscale version of the colour channel, it's unaware of any actual hue; the Pantone you choose is what actually gets printed, not the on-screen preview.
Working with spot in Photoshop is a bit less straightforward. Essentially, you need to think of each ink channel as its own independent mask, and consider the limitations that come with that. Layers are out, for example, which also makes text uneditable; building a file this way is tedious at best.
First, to understand how Photoshop works with spot. Open a photograph and convert it to CMYK (Image -> Mode -> CMYK Color), then go into the channels palette and drag one of the channels to the trash can at the bottom of the palette. Instant spot! You can view each individual channel in greyscale by making sure it's the only one with the little visible eye icon next to it, or view them all as a blended preview of what they look like combined by enabling all eye icons.
Given your subject matter though, it's probably none too attractive at this point. You'll want to adjust the ink colours, which you can do by double-clicking on any channel (the 'Solidity' option is for your monitor only, it won't affect the printed output). If you create a new channel while working in spot mode, it defaults to an Alpha channel, which you can then change to a spot channel by again double clicking, and selecting the appropriate radio button. Or just hit the arrow at the top of the Channels palette and create a 'New Spot Channel'.
Now what you'll want to do is devise a strategy to build up each of your ink channels. Rather than working on a composite whole and selecting colours for each new item, you mix your colours by adjusting the ink proportions in various channels. Darker means more ink, lighter means less.
It's a completely different way of interacting with Photoshop. Aside from layers, many of the usual tools are available to you when working in spot mode, and if you've spent time developing advanced masking skills you can adapt that knowledge and feel right at home. Otherwise, the least elegant way to work—but perhaps easiest to manipulate—is to build a set of greyscale files, one for each ink channel. Layers and editable text are usuable, but any areas that require more than one colour would need to be duplicated across both files, which makes editing tedious. You lose the ability to preview the combined channels though; the only way to get that back is to save a flattened copy of each greyscale file, then combine each in a new spot file, one channel at a time. Tedious!
Proofing spot colour is actually fairly simple; you know which Pantone colours you've chosen, so you can roughly match those in Illustrator's colour picker. Make sure to print a test strip of your swatch to make sure you're getting an accurate picture of the shift between the solid colours on screen and those on paper. Proofing in Photoshop is usually slightly more difficult due to the relative complexity of the subject matter compared to what you might be proofing in Illustrator, but the same process applies—make sure to print test swatches, keep your Pantones firmly in mind, and all but the most subtle of blends should be predictable.
Finally, I'd be remiss to point out that there are advanced colour matching systems (both hardware and software) which have been developed specifically for the purpose of colour matching between screen and printer. Should you care? Probably not—they may save time for those spending a large part of their day thinking in CMYK, but for simple jobs where the basic concept of working with CMYK causes enough doubt to spur this article, it's likely they're overkill.
One thing that might be relevant though is the Monitor Profile your software uses. For general RGB work it's best to turn off colour management; for printed work, the software needs to somehow interpret CMYK on-screen. There are colour profiles for different types of paper which depend on your geographical region; North America uses SWOP, for example.
Aside from accuracy in CMYK mode, the most useful function of having an accurate CMYK profile is the out-of-gamut warning you can pull up in Photoshop when working in RGB mode. By hitting Ctrl + Shift + Y or Cmd + Shift + Y to toggle on and off the warning, you get a layer of grey indicating spots in the file that are out of the CMYK colour range and most likely to shift dramatically. Simply by knowing these areas in advance, you have a map of which areas in your image need the most coddling, and much of your colour management issues obviate.
A few thoughts in response to the response on my response from yesterday. On convergence of content, and RSS in particular.
Yesterday we looked at the problem of information overload when too much is presented in a single feed. Some fantastic discussion has been happening here and elsewhere, so much so that a quick linkdump is in order. (Ironic? You decide.)
- Stinky Links
- Matt Haughey's piece that kicked off the discussion. To be fair, I originally misquoted him (since amended), and my writing yesterday wasn't meant as any particular sort of judgment on Matt or the others I called out by name. I had the outline written up early in January as a more general musing on the impact of combined feeds, his post threw it into sharper focus and prompted me to finish up and provide some examples.
- On hybridised RSS feeds as evidence of a need for weblog refactoring...
- Tom Coates took the ball and ran with it. A long and probing look at how all these small pieces loosely join, in practice. Some excellent musing into what all this is and how we got here.
- Requirements for a tag-aware RSS reader
Okay, I didn't see this one coming, but Brian Del Vecchio has taken the discussion and combined it with the darling discussion point of the day, folksonomies (AKA tags). Arguing for tag-awareness built into RSS readers, Brian takes it into a different realm and lays out a foundation for tagging content which has already hit the reader, to add more permanent storage and classification of useful content. Though it may be some great extra functionality, this doesn't really solve my problem.
Built-in tagging support that would fit into this particular discussion would be something that allows me to filter content before I even read it. Essentially the tags would have to act as keywords for a search, proactively applied to dish up only entries matching the terms I've chosen. But I'd have some major reservations on how you would go about building the UI for this kind of idea. Would I have to select my tags every time the reader polled remote sites? No, that's silly—what if my mood changed and I wanted to edit the saved tag list? That shouldn't be a manual process every time.
The obvious solution is to save different sets of tags as "views" of my feeds, which actively includes or excludes unread content items based on my terms. Quite serviceable and probably easy to implement (since NetNewsWire already lets you search across all your feeds), but then I'm only seeing a small portion of content that fits into those narrower terms. I'm not convinced I'd use that sort of custom view often, or even rarely. Likely there would have to be some form of category/tag support built into a feed itself, but then we'd move back into the territory of providing separate feeds for each facet; do feeds at the category level really make sense? For some, yes. It would be interesting to play with this sort of tagging idea anyway, since I'm shooting down a theoretical model that I probably don't fully understand yet.
Anyway, so here we are with this can of worms that a bunch of people have apparently all been thinking about for a while. There seemed to be consensus on here yesterday that people who read this particular site would prefer to see separated feeds; that's only a small data set though. I doubt anyone really needs to shake up what they're doing drastically at this point, as a couple of alternate feeds are pretty easy to build and should satisfy most everyone. (Incidentally, I'm finding it highly ironic that a bunch of web designers are saying we, the users, want to see your site this way. Shouldn't we know better? Then again, we're also the ones getting used to ideas like client-side CSS and RSS that allow the user to completely bypass our work anyway, so at least we're being consistent... I think.)
Tom points out that it may not be quite that easy. Due to small problems with each of the services in the chain—the lack of formatting in del.icio.us, for example—a unified feed is not the ideal it might be. In fact, a significant chunk of my aversion to these content-rich feeds is the sheer number of items; one dump of del.icio.us links, one Flickr photo, and one article a day might be my threshold. One single photo, or one aggregate view of all photos posted within a day would be roughly similar in my mind, the net result being a single new item in NetNewsWire to click on instead of the constant stream I'm getting now. That's actually not so far away, either—most del.icio.us implementations I've seen are already doing exactly that. The Flickr team is probably on this already (we're smart, us Vancouverites).
But remember that we're basing all this on only two or three services so far; what happens when someone's feed integrates those with upcoming.org events, MSN search results, and craigslist listings (all currently obtainable in RSS)? My three-item threshold just got crossed, and that's scratching the tip of the iceberg. RSS isn't just about weblogs, either. Throw in stock quotes, bank statement summaries, press releases, and all the other data you might expect companies and individuals to want showing up in their feedreaders, and we're heading into murky waters where relatively flat RSS files are replacing complex data views (dashboards, anyone?) in a way that might not make sense.
Convergence will continue until we have a better idea for sorting out all of this. I suspect Tom's final wondering of how we might re-define the weblog holds some part of the solution: Just as we're all different people with different interests, so will each site accordingly treat the technology. This site in particular has never been a personal weblog, so much as a series of articles and musings on design and the web. A bunch of camera phone pictures from the pub would never fit here. If I were to start posting Flickr photographs that support my main articles, on the other hand, I'd deem that essential content that belongs in my main feed. Integrating content pieces on a per-item choice feels like the right direction to move toward; once a site's focus is clearly defined, then it shouldn't matter what the content is or where it came from, as long as it's relevant. The task is much harder on a purely personal weblog with no defined focus, though I suspect there could be an argument for even these sites having an inherent focus whether it's observed or not.
Ultimately it's up to the author to make the proper decision for their own site of course, but it should be based on appropriate judgment of what the reader expects, too. In the end, if the readers don't like the author's choices, they can always just walk away and find another site more aligned with their preferences. Ah, the beauty of a free market.
Matt Haughey raises a valid issue about weblog content. I've been thinking along this line for a while: combined feeds annoy me.
A recent trend some folks have taken to is the splicing and pasting of various pieces of content into one main RSS feed for their entire site. Services like FeedBurner (or just plain old coding skill) seem to make it easy and practical, but there's a side effect that isn't being discussed: the impace on the reader.
Content from all over the place can show up in one feed: daily del.icio.us links, Flickr photos, sideblog items, and now and then, even the occasional post from the site owner. A few feeds pulled from my reader showcasing this convergence in action are those of Tom Coates, Leonard Lin, or even Matt himself. (Leonard has a few additional choices without the extra content, too.)
The problem I have is quite similar to what Matt describes: when new items show up in my newsreader from people I enjoy reading, I'm often mildly disappointed when it's simply a new camera phone image, or a couple of sparsely-described links to stuff I've already seen.
I'll go one further though, and say this about the practice: it's really damaging the signal-to-noise ratio of content I otherwise love. I have enough feeds in my list (120 at the moment) that anything on there has to work pretty hard to stay that way, from a useful-content perspective. When 7 new items pop up, that's 7 to manually flag as read, whether I end up reading it or not. Although NNW's Cmd + K lets me do it in chunks, make me do that extra work of unflagging items I'm not interested in enough times over the course of a week, and it might be easier for me to simply unsubscribe.
The flip side of the coin is that throwing all these items into a single feed makes for a nice appearance of continual updating. From the site owner's perspective, days may pass between new posts, but during that time an active log of interesting links is being maintained. It's one way to continually keep readers engaged in your content over time, but a case might be made that it's not necessary to do that anymore. This is RSS after all, I have a number of feeds that go silent for weeks at a time, but new content always gets read and I wouldn't even think of deleting them from my list. I'd much prefer low volume and high signal, to frequent updates with content I don't really care about. RSS is all about making it easy to follow high- and low-volume sites alike.
There's always room for experimentation, but I think in this case it's a good idea to think about the reader implications a little bit more. Give me a Flickr feed, give me a del.icio.us feed, give me a main post feed. Heck, give me a combined feed of all of it too; in some cases I and others will even prefer that, just don't make that the only option if at all possible.