Does design exist in a template-driven world?
Design-in-Flight is back in an all-new weblog format. The most recent feature article asks about the commodity of content, and what this means for design.
This is something I've been thinking about quite a bit lately. In an age of content management systems and blog tools, RSS and MP3, content which was once a complete package with other physical properties has now become a bunch of impersonal 1's and 0's.
Sure, mass aggregating is great if you view content as a consumer, looking to filter the wheat from the chaff. It's progress, baby. But as I'm sure has been waxed nostalgic by others far more eloquent, there's something lost when dissociating content from any context. You just don't get attached to a post sitting in Bloglines the same way you once might have clipped a newspaper article and hung it on your fridge. You don't flip through the liner notes of an album bought on the iTunes music store, the same way you would have if you had bought it on vinyl, cassette, or CD.
Particularly relevant to my own work is the question of content design vs. templating. The article leaves a dangling question: if content is this ethereal and interchangeable, what's the designer's role? An answer was briefly touched on with the mention of Apple's Widgets: styling, but not defining.
How many of us are noticing an increase in requests to design 'templates' for general content, but not custom-design specific content? I sure have. A lot of requested work these days assumes this as a baseline; when dealing with a CMS or a dynamic application, you don't get the content in advance (if it even exists yet), so it's ultimately irrelevant to the design. The goal ends up being the creation of a flexible, one-size-fits-all construction.
Is this design though? In the sense that you're being asked to solve a specific visual problem, yes. In the sense that you have full control over the rendering of the output, anyone designing for the web has been getting used to the idea of giving up control for years now. This is just one more step along that path.
So that reduces the designer to one who can make a bit of code look nice. And to a lot of clients, that's about all there is to it. I'm sure we've all had our share of the "shut up and color" type, who don't hire us beyond making sure their ugly site or application is not quite as ugly.
I'd like to think there's more to what we do than simple aesthetics, though. Lately there has been a lot more focus on Design in business and other realms than traditionally warranted. Design, that is, in the sense of it being strategic planning and problem solving of systems, interfaces, and products, which is a much broader definition than visual design.
And that's how I find my own interests shifting, too. I got into this game with no more than an image editor and the pixels to back it up, but lately my focus has been much wider. I'm reading up on databases and server-side scripting. I'm brushing up on my Unix and tweaking the web server I have running on my local machine. I'm deep in a Lou Rosenfeld book and my copy of OmniGraffle is being opened a lot more these days.
Not that I expect to rush out and start billing as a programmer or database administrator, mind you, but the exposure to these other disciplines is really helping me clarify what it is that I do, and how that fits into the complex ecosystem of talent on the web. My view of design is changing from simply making a user interface look great, to making a great user interface, and all the details that go into it. That demands a heck of a lot more than a few well-placed pixels.
So while templating is here to stay, it doesn't at all mean that demand for design talent is going away. Consider that the type of content that lends itself to a template is generally the type of content that probably shouldn't be custom-designed anyway; just as newspapers and magazines have general layouts and style guides, so too do dynamic web sites. Rapid turnover of content demands as little production as possible. More production is always nice, but it's not a necessity.
And it's highly likely that blogs and other systems that allow the average user to manage content have increased the interest in templates as well; since CSS offers the ability to use a common markup base and radically alter the look, it's easy to implement them. You could potentially make a career out of designing generalized blog templates, whereas five years ago there was no demand. But that's a brand new niche, it doesn't replace traditional design.
That's the point, I think—we're not looking at a commoditization of design talent, we're looking at an expanded market. Given the higher level of interest in design in general, the field is getting wider, and there are now simply more options.
It's time for a new digital camera, and point and shoot is so 1998.
I've been considering moving into the world of digital SLR for some time now. Though consumer level cameras have improved quite a bit since I was last in the market for one, and though my last camera (Canon A40) was really quite good at the time for what it was, my mounting frustration at its limited manual settings means it's not used much anymore. I became a little too proficient at taking mediocre photos.
The idea of an ultra-compact, feature-filled consumer camera was appealing when Mike Davidson wrote about his Casio a few months back. Lugging a full-size camera around when there are such tiny alternatives feels a little archaic. And with the high end consumer models hitting the 7 and 8 megapixel range, the resolution is almost the same anyway.
So why an SLR, despite that? There are a few potential reasons offhand, although I'm still doing my research on this one.
- Image quality. We'll start with the obvious point that an SLR's core strength is the ability to 'see through' the camera. An LCD viewfinder is nice, but I'll happily trade it for accuracy. Though it's possible to achieve depth of field in some form or another with a consumer camera, I've found the results are generally disappointing at best. (Your milage may vary.) A higher ISO rating means better shots in low light. And the ability to shoot in RAW mode is something that strikes me as important, though I have yet to actually do so.
- Lenses. Telephoto, Wide-angle, Macro, etc. And with a few other locals to pool 'em with for more choice, all the better.
- Speed. 3 to 5 FPS shooting? Holy moly. I currently get 5 SPF, if I'm lucky.
It seems to come down to a choice of quality over quantity. Yep, you'll probably take a lot more photos with a consumer level camera because you'll have it with you more often. But they probably won't look as nice as the ones you've shot with an SLR. Luckily, it's not an either-or choice for me as I already have a point and shoot camera, so the case for going with quality is looking awfully compelling.
Presuming I go this route, I'd be curious to hear about the experience of other SLR owners out there. I have a particular manufacturer and a few models in mind, but I won't mention those just yet in favour of hearing about actual first-hand experience.
I'm also curious about photo management when dealing with such large files. iPhoto, I'm quite certain, just won't cut it. What kind of software should I be looking into for organizing and cataloguing? Presumably I'll also be looking into a large chunk of Flash or SD memory, but then there's the issue of longer term storage. DVD vs. a dedicated external hard drive seems likely to be the main choice, and I'd imagine a decent catalogue application could handle either. But that's just a guess.
Taking advantage of a Quartz effect for a better online video experience (among other things).
There are no end of sites that embed video within a browser, rather than load it in your external video player of choice. Case in point—Comedy Central's Daily Show video archives. Since the video size controls of the player are often not accessible when the player is embedded, how many times have you ended up hunched over and squinting at a postage-stamp-sized video?
Sure, you could hunt down the URL of the video in question and force a download to disk. (The most reliable way I've found to do this and bypass the browser's default file handling: hand-code a direct link to the video in a static HTML file, right-click the link, Save File As.) Or if the format is QuickTime, you could always shell out $30 for the "QuickTime Pro"
extortion fee and save it direct from the player.
But if you run OS X, there's a quick hack that eliminates the petty file management either of these routes require. The first stop is your system preferences, in the Keyboard and Mouse Panel. You'll find a group called "Universal Access", and within that group is a setting labelled "Turn zoom on or off". Make sure it's checked. Alternatively, you can just hit ⌘ + ⌥ + 8 from any application to toggle this setting.
Now, at any time and within any application, you can simply press and hold ⌘ + ⌥ + = to zoom the screen inwards, and ⌘ + ⌥ + - to zoom back out. Load up the windowed video, hit the magic key combination, and use the mouse to center the video within the screen. Voilà—instant full screen. Thanks to OS X's Quartz rendering engine, the video enlarges without causing any noticable hit in frame rate.
Of course, you're not gaining any video resolution this way, and you're still going to have an enlarged mouse cursor and visible border on-screen. It's not perfect, but hey, it beats that postage stamp doesn't it?
I always leave this setting on, because universal zoom anywhere in the OS is mighty handy when you're someone who deals with pixels for any amount of time. The only gripe I have is that the anti-aliased smoothing doesn't allow me to measure pixels by sight; an option to smooth the enlarged pixels or simply enlarge the mosaic would be most welcome. Apple's a few steps ahead of me. ⌘ + ⌥ + \ toggles the smoothing setting. Thanks, Joseph.
A question on automating database population for you server-side experts.
Let's say you have a web site that you've been updating manually for a few years. Let's also say that you're sick to death of doing it this way, have finally taken the steps necessary to automate this thankless task, and now it's finally time to throw all that manually-input data into a database. For the sake of argument, let's also assume that adding the 700+ items by hand just isn't going to happen.
So then my question to you is, can you see any way of taking multiple pages of static, well-formed (and consistent) HTML like, say, this, and getting it to automatically post to a form that looks, well, like this?
I'm sure to some out there, it's the easiest thing in the world. To me, however, it's not. So, what can be done? My preference would be a single PHP file that crawls the various category pages (and the sub-pages they link to) under the 'All Categories' heading on the 'All Designs' page and either a) posts it to the form (assuming the example values aren't there in the final form), or my preference, b) stores it in logically-named PHP arrays (following the naming convention in the example function below) so that I can bypass the form completely.
Here are a few more supporting pieces of information that might be relevant to this task:
Not all fields in the new form are represented in the static data. For example, currently each submission only receives one category, whereas multiple categories exist on the form. So the script should detect which category the static data is coming from, assume a corresponding entry is in the list of categories (even though they aren't at the moment), and assign accordingly. Multiple categories can always be re-assigned later.
Fields which are considered absolutely essential/cannot be discarded/must have a value are: Name, URL (when it exists), CSS File, Submission Title, Category, Official Number (where it exists). Fields which exist in the database for other use, but don't appear anywhere in the static data (and therefore can be ignored) are: E-Mail Address, Zip File, Windows Browsers, Mac Browsers, Comments. See note about submission/publication dates below.
- The order in which the submissions are displayed in the static files is important, in that the further along in the list they are, the earlier they were submitted, and therefore the earlier they should be posted. I'll probably have to do some manual jiggering of the submission/publishing dates because I've pretty much discarded that data all along, so as much as possible, the script should try to preserve this implicit chronology. The more relevant of the two is publishing date, as it's what will ultimately determine listing order on the site.
The form flattens out the data quite a bit; in reality, this data spans multiple tables in the database. This shouldn't matter, but in case you think better this way, it might be relevant to know that the form itself basically posts to a PHP function:
save_submission($subName, $subEmail, $subUrl, $subNation, $subTitle, $subCssfile, $subZipfile, $subWindows, $subMac, $subNotes, $subStatus, $subDate, $pubDate, $subOfficialNumber, "populate");
But a separate category handler function also needs to be called:
...where $subId is the submission id just created, and $subCategories is an array of the values selected.