MacBook Air Announced Without Pony. Bloggers Demand Pony.

The (ever) Daring Fireball and Paul Boutin at Slate are lamenting the fact that the newly announced Mac sub-notebook doesn’t have some manner of cellular EVDO type of use-anywhere-networking-just-like-the-iPhone support. A quote:

Like me, Boutin was hoping for ubiquitous wireless networking. The more I think about this, the more certain I am that it’s just silly that my phone always has a network and (as of yesterday) knows where it is, but my Mac doesn’t.

While, yes, it may in fact be technically feasible to incorporate a cellular card into a skinny little laptop and offer the same clever network switch-a-roo technology that is in the iPhone, that doesn’t mean it’s a good or profitable idea.

To rebut this point: It’s a laptop, not a phone! Do you need your TV to geo-locate? How about your printer? Maybe your microwave?

To rebut in a slightly more classy fashion, Consider the two following use cases:

1. You are in a new or unfamiliar location, perhaps walking or driving. Perhaps you’ve missed a turn out in the ‘burbs. You realize “oh foo, I don’t know where I am any more.” You need directions.
2. You suddenly realize you’re in a strange coffee shop, using your laptop, and realize “oh foo, I don’t know where I am”. You need directions.

I’m going to wager that case 1 is the most common. I can remember at least a few times I’ve been in just that predicament. This is why the iPhone has a Google Maps application with a location feature.

If case number 2 is happening to you often enough to consider a laptop upgrade, perhaps you need to switch to decaf.

Paul Boutin, in his article, posits the scenario where he’s riding shotgun in a car, and wants to help the driver with directions, so he wants to dig around in his bag and boot up his laptop instead of picking up a cellphone and calling for directions. This strikes me as an edge case.

I think that is what Apple thinks too. Yeah, they could do it. But why?

There are hard-core super road warriors who need connectivity everywhere. But these guys are (a) a small market and (b) are purchasing “pro” versions of laptops and plugging in whatever wireless provider’s card they need.

There’s a laundry list of other reasons why this is a dumb idea for this particular computer:

• Who will the provider be, Sprint? ATT? Should Apple standardize on one provider, or provide generic hardware? If so, who supports what? Can Apple guarantee that fickle telecommunications companies won’t pull the plug on hardware support in a year?
• What hardware standard do you support? Do you hope for 3G? Do you use Edge? Do you put a giant chunky card-slot on your sleek, whisper thin computer that only 1 out of a 100 owners will use?
• See above, the target customer for this computer doesn’t want this.
• Data connections over cellular networks suck, yes even 3G is only as good as a good dial-up connection.
• The MacBook Air sports 5 hours of battery life. How’d you like to make that 3?

I see three big markets for the MacBook Air, in descending order:

1. People with one beefy machine at home or in the office who want a second, small computer for traveling, giving presentations, or otherwise using on the go
2. Students. This laptop will fit in your TrapperKeeper along side all 18 of your chemistry books. (When I mentioned the Air to my wife she remarked “oh, what I wanted a year ago.”)
3. People who don’t need or want a beefy computer, and want something small and light that looks nice and isn’t complicated (Hi Paris!).

Hosting Provider Makes Point. Point Missed.

It started here:
http://blog.dreamhost.com/2008/01/07/how-ruby-on-rails-could-be-much-better/

And went here:
http://www.al3x.net/2008/01/shared-hosting-is-ghetto.html

Link number one – the author, a tech at Dreamhost (where I host my web sites), writes a constructive article detailing the difficulties they encountered in trying to support the Ruby On Rails framework. Also, he articulates his opinion that if the Rails community could standardize their hosting and deployment practices – or at least provide a set of best practices that can be easily repeated – and make it easy to deploy in shared hosting environments, it would really benefit Rails developers (to provide cheap hosting environments for learning and development) and help promote Rails as a technology.

These are true statements, with which I agree completely. (They are also born out by tales of woe I’ve heard myself from folks who tried to manage their own Rails environment, on their own servers.)

Link number two: Rails dude gets snippy and calls shared hosting a ghetto (in reference to an article by an ex-Rails developer) and misses the point entirely. This second article makes points about how Java and Python have stayed away from shared hosting (not entirely true). He then proceeds to discuss his preference for the “nightmare” of setting up his own server versus the nightmare setting up a shared server (pick your poison, I suppose).

He concludes by incorrectly identifying a popular hosted PHP application as a Rails app and trying to argue that shared hosting wouldn’t make him any money. Oh. Well then. Point made, I guess.

Dallas Kashuba at the Dreamhost blog is correct. Rails is very troublesome to host and deploy. This problem – regardless of whether the hosting is in the shared hosting ghetto or in your personal server farm – is still a problem and a deal-breaker for a lot of people. It certainly was for me. Getting all snippy doesn’t change that fact.

The Michael Barrett Professional Opinionâ„¢ is that Ruby on Rails is all sizzle and no steak. The development problems it solves are only solved if you’re starting with a fresh, clean, empty database; have no legacy systems or data to integrate to, and have lots of time to babysit a server.

Call me when RoR reaches version 3, 4, or 5. Maybe we’ll try again.

When I kissed RapidWeaver goodbye, and re-familiarized myself with WordPress, I didn’t want to spend time customizing a web site design…I just wanted to fix the problem of me not posting very often. I discovered the Ideal Website theme – which is pretty nice looking but the HTML which is ultimately generated is pretty much tag-soup (nee Crap). Also, oddly, the website advertising the theme boasts all this “openness”…but the license that ships with the theme is fairly restrictive…silly, dubiously legal, software boilerplate legalese which only sort of applies (How much can you really copyright an open source template API and standard HTML implementation if you’re just giving it away?). Needless to say, I don’t want to be encumbered by that noise. I might want to change the typeface or something.

So, with the holidays in full pause, I had time to rework things. I’m reusing a very old background image from one of this site’s previous incarnations along with my classic logo. I did steal one idea from the Ideal theme…the contact form at the bottom of the page. That’s a clever idea really. Why should that be a separate page? As I continue to tweak things, I may make that collapsible so it’s only visible when needed…but I like not sending a visitor off to another page to ask me something.

I’m taking advantage of the nifty Blueprint CSS framework to simplify my layout needs. The framework is really quite nice, I’ve been using at work for quite a while now. It greatly simplifies your page layout work, and also makes it simple for me to do more ‘designed’ blog posts by taking advantage of the framework’s existing CSS class names.

The layout is based on a simple vertical grid, with classical proportions: 8x5x3. The center column (5) appears as whitespace wherever more focus is desired (viewing a single post or page, for example). Type is set on an 18 pixel baseline grid which gives everything a nice rhythm and makes it easier to read.

As I continue to tweak this, I’d like to:

• Integrate some bolder color in an effective fashion
• Gracefully hide or show elements on the page as they are needed via JavaScript
• Add a comments policy and a contact policy (just in case)
• Finally get some portfolio on line

The flickr question

Flickr sucks. I spent a few hours playing with it…It’s slow. The tools don’t work very well (e.g. odd, useless error messages with raw xml strings. Great. Thanks.). I decided that if I want to share photos with people I’ll use Google’s picassa, and otherwise I’ll just post any worthwhile pictures in the blog.

And here are some honeymoon pictures.

Flickr’s service is the most obvious, whitest, elephant in the room – just sitting there, begging for e-peanuts (enuts?), hoping to serve my pics up to the disinterested masses. Obviously lots of people use flickr and sing its web 2.0 praises. I have a number of flickr feeds bookmarked for regular perusal. There’s some great stuff there. But I’m still gun-shy about using it for my own site.

Here are my pros and cons:

• Pros
  1. Flickr provides an easy recovery or backup if I lose my images or all my hard drives suddenly go belly up.
  2. I could share photos in and out of the context of my site (e.g. more options for reaching an audience)
  3. All the cool kids are doing it.
  4. Flickr provides many methods to upload photos (email, phone, traditional upload) which means I could easily pop a pic online for somebody pretty much anyplace, anywhere, anytime.
  5. There are many tools, plugins, apis, etc which allow Flickr content to be integrated into your web site.
• Cons
  1. flickr.com is blocked by many corporate firewalls (at least mine). If I’m using my site for self promotion, that can become a roadblock.
  2. Flickr’s search features make it very easy for some lazy, dishonest art director to steal your pictures and use them without attribution. (no. really.)
  3. What happens when Yahoo (flickr’s owners) decide to become evil? Do they own all your pictures? Do they claim copyright? Do they start selling your pics back to you?

Clearly the only solution is to noodle around with the service and see if I like it or not, and see if the wacky fun webbiness outweighs my concerns. Film at eleben.

So I made the switch-a-roo and dumped MS Office of my system (safely archived on the original install CDs).

Above you see a sliver of the Terminal, Activity Monitor (‘cuz it’s neat), Coda, Numbers, Pages, and NeoOffice.

NeoOffice is there to do “heavy lifting” in case I run across some Office-y type function I can handle with Numbers or Pages. You know serious things like printing one mailing label in the middle of a sheet. You know. Hard core functionality.

I’ve also moved Abouthalf to WordPress.

I’ve been using WordPress on BluePlate Bachelor for quite a while and I finally decided to make the switch.

WordPress has two big pluses over RapidWeaver.

1. It’s not platform specific
2. It imports and exports a variety of formats.
3. One can edit a theme inline and on-the-fly
4. It doesn’t bug me to upgrade every time I launch it

Four. Four big pluses.

I am using the nifty “Ideal Website Theme” from InformationArchitects.jp.

I like the clean simplicity of the design, I like the placement of archives as links at the bottom and other features. I figure this was a nice palette cleanser while I figure out how I want Abouthalf to work in the future.

WordPress is a nice product for an end-user to work with. As a developer, I look at some of the plug-in code and shudder. WordPress is a very typical PHP application, and all that that implies. This is not relevant though. The blogging/writing interface is nice and clean, and I can export my data, or dig it out of my database however I want, meaning I can change my little mind any time I want.

Speaking of horrible PHP code, I’ve been working with the Zend Framework over the past few days, writing a ‘back office’ for a shopping cart.

It’s very nice. No really. It de-crappifies a lot of the problems with PHP application writing. The framework is PHP 5 only, which some my deride, I applaud.

The framework has a lot of the features that you mind find in Cake or Ruby On Rails. A Object-Relational-Data system, a controller object with view objects, a “Front Controller” class if you want to implement a full application.

I tried noodling around with CakePHP a few times. Went through the docs, tried the blog tutorial, tried it again. I always found it very counter-intuitive, and counter PHP.

One problem I find with CakePHP is that while it’s powerful, you can’t leverage any piece of the framework by itself easily. For example. Say you’ve got an existing web site…and you want to add on one simple data entry form. Cake wants you to build a whole app. While you hypothetically could extract its implementation of ActiveRecord, it wouldn’t be easy.

With Zend Framework you have the option of using only bits of the framework in a decoupled fashion.

So, for example, if your data-entry form only has one view, and one action, and it’s the only form you’re making, then you can just use the Zend_Db and Zend_Table classes and be done with it. If it gets slightly more complex, you could – at any time – add in a controller object – and then add in add in a view object when and if you need to. Nice.

In the past week I’ve found it to be easy to under stand and work with. The documentation on the individual components is pretty solid…however you may need to hunt for a good “putting it all together” tutorial. I’ve found two good ones by the same guy:

• http://akrabat.com/zend-framework-tutorial/
• http://akrabat.com/zend-auth-tutorial/

Coming soon I’ll detail how I used the Zend_View class in coordination with the Zend_Mail class to send notification emails from within a controller action method.

If you don’t, it is a great opportunity to see the best salesman of our time in action.

http://events.apple.com.edgesuite.net/s83522y/event/index.html?internal=g4h5jl83a

You’ve heard the old phrase “He could sell [stereotype] to [ethnicity]“. Well he could.

In all seriousness, if you care about information design and the art of communication, watch his presentation.

This is probably the only time you’ll see the CEO of a company get real applause — but more importantly watch his slides carefully.

• There are no bullet points
• There is no point in the presentation where he reads from the slide
• Almost every slide is a strong, simple image or graphic
• Text is minimally used and always underscores important-to-remember facts (like sales totals or battery life)

Steve Jobs uses Apple’s Keynote instead of the ubiquitous Microsoft Powerpoint. But that doesn’t matter. Skilled hands can create garbage in any software environment. The real magic here is that he has a script, and the slides are his accompaniment. His slides are like Dean Martin. They aren’t a crutch, they back up what he’s saying, so what he’s saying becomes the focus.

Notice all the little touches to the presentation. For example when he demonstrates a product, the slide reads “Demo” in an informal italic typeface. This indicates to the audience “go watch Steve now”.

Since this presentation is about iPods, music is liberally used throughout the presentation. However music is treated like a reward for a task. When Jobs demos searching for and purchasing a song in the iTunes WiFi store, he rewards the viewer with 10 or 15 seconds of John Lennon (and his iconic visage displayed on the large virtual iPod screen).

If you have a presentation coming up, do yourself a favor. Spend an hour watching this presentation, take notes, and steal some ideas.

http://stevenpoole.net/blog/goodbye-cruel-word/

It’s a nice read, though it’s basically a love letter to the new brand of hipster full screen anti-word processors like Writeroom and Scrivner. (These products seem nice for someone who a.) gets to use a Mac at work and b.) must crank out X number of words a day. I am neither of these people. But I would gladly try out Scrivner the next time I had a big giant piece to write, like maybe a big project proposal)

Poole writes about how MS Word has gotten bigger and bigger and more and more cluttered over the years. He writes about how hard it has become to actually write with Word any more.

This resonated with me pretty hard. I have been facing the same kind of decision.

I am using the 30 day iWork trial at home and I find that Numbers meets all of my personal and business spreadsheet needs. I don’t do any serious number crunching at home. I’m not an accountant (ahem: There’s no accountin’ for me anyways. thank you.)

I need a spreadsheet for the three following tasks:

• Clean up data for importing into a database
• Simple home number crunching – like “what’s my bank account going to look like at the end of the month”
• Creation of invoices for my freelance work.

Numbers does all this very well — and in fact does things like invoicing better because the result is so much more graphically pleasing. (I’ve tried purpose built invoicing tools. These are typically overkill for my kind of work, and you’re basically paying for a custom Excel template wrapped up in a wonky format anyway. That’s dumb. Oh, and Quicken sucks.)

My word processing needs are equally small. I need to:

• Write a letter
• Print an envelope
• Write a résumé
• Write up some short multi-page documents like a project proposal (which Pages has a nice template for)

So, basically I need about 1/3 of MS Office. I haven’t used Excel or Word in about a month or so, and I’m strongly considering just removing it from my computer altogether.

Pages and Numbers does everything I need it to. I don’t really need PowerPoint or Keynote. I suppose I might someday, and if I do great. (But I generally believe that PowerPoint is for marketing knobs and for real use*)

Another reason for me to move to iWork (or even NeoOffice) is that Microsoft isn’t going to have a Universal Binary version of Office until 2008. Then, if I’m lucky, I’ll have the opportunity to pay $300 for an upgrade that will run at normal speeds on my machine. Thanks, no.

In fact, there has only been one compelling reason for me to upgrade MS Office ever. The first version I purchased was for Mac OS 9. I bought an upgrade when a version for OS X shipped. That’s it. I think I’ve missed two versions maybe. I don’t know. The upcoming universal binary would have been the next compelling reason, but I won’t be doing that. iWork is universal binary of course, is available yesterday, and costs $79. An updated MS Office doesn’t exist yet, and will undoubtedly cost at least $300.

My only lingering doubt about yanking Office off my computer is that I know, I just know, somebody somewhere is going to send me some wonky Office document that Pages won’t open or something, and I’ll need office to use it. However, I do have NeoOffice installed — I can probably safely bet that if it won’t open in Pages, it will open in NeoOffice. And if it doesn’t open in either I could just request that they send it again in plain text format.

*disclosure – at work I advocate all “wireframe” or user interface documents be made in PowerPoint and hopefully saved to PDF instead of that horrible thing called Visio. People have Acrobat or PowerPoint on their machine. The lowly analyst who inherits the UI document can edit a PowerPoint file…but they may or may not have Viso and may or may not know how to use it.

I saw the news that the rock-n-roll software developers at Panic were releasing a web design tool, called “Coda“, so I checked it out, ran the demo, and bought it an hour or two later.

I have spent about 12 hours working with it, and I’m very pleased. Coda is the quintessential Mac app, the iPod of IDEs.

Coda looks and feels wonderful. It’s very natural to use, and takes no time to start using effectively. I mean no-time. It is a highly learnable app. You open it up and there you are. You know what to do by looking at it. Coda is a brilliant piece of user interface design. For that matter it’s nicely designed all the way around. Even the name “Coda” is a clever double entendre.

A coda in music is a sort of summary of a piece. Like a big finish. Coda, the app, summarizes many aspects of web design into one tool

Also the word “Coda” (said out loud with a nasal Boston accent) sounds enough like “coder” to emphasize the nature of the tool — HTML up front, CSS up front, no WYSIWYG nonsense (I mean why fake the output when you can just look at the output in a server? Duh.)

Coda takes all the critical parts of web design and development and stitches them together into one tool.

Typically the workflow of a web developer uses the following tools:

• Coding tool/text editor (for writing HTML, CSS, JavaScript, PHP, Ruby, etc.)
• Web Browser (or three) for previewing how the design/development is going so far
• FTP application to move updates to the web server
• Command Line interface (to manage a database, version control, muck around with Apache’s configuration, etc)
• Even yet another browser window open to do research

Coda does a pretty good job of providing all of this in one application window. In practice, I still need to crack open another browser or tool for this and that (I prefer CocoaMySQL to the command-line) and I run Windows in Parallels so I can browser-beat while I’m working). In general though, it reduces my desktop clutter and the accompanying mind clutter that comes with it.

The net result is I only have 2 or 3 apps open instead of 5 or 6.

The Coda workspace has three main elements, a file browser (which shows your local site, and the remote site) and two layers of tabs.

One row of tabs allows access to individual files, while the top row of tabs is your “view”

For any tab open, you can switch its view to any other view. Any tab may be split into frames, and each frame can have its own view.

This means you can have a tab split into two views, one showing your HTML, and another showing the preview (rendered by WebKit), Or you could split your tab three ways, and have your code, a preview, and a reference book open. Or you can just create a new tab (Command+T) which defaults to an empty HTML file…switch it to preview, and type in the address of your local dev server and see the site live. It’s very flexible.

The text editor view is based on Subetha Edit. It has just enough bells and whistles to make you productive without burdening you with learning a giant tool.

The obvious comparisons will be to TextMate and BBEdit. This is wrong.

BBEdit is a Mac Text Editing Platform — meaning that while, yes you can use it out of the box, it’s designed to be scripted, tweaked, and customized for all those random jobs you need a swiss army program for.

TextMate is a code editing beast which can handle any flavor of code you throw at it, and can be infinitely tweaked for your particular coding habits.

Both are great*, but overkill for websites. The issue isn’t how well they handle code, they do it very well. The issue is that BBEdit and TextMate are conceptual islands which you have to leave each time you want to see the results of your work.

As for text editing, Coda auto-completes your HTML tags, auto-completes your PHP functions, and auto-matches your quotes and brackets, then it just gets out of your way.

If you need a super powerhouse app to manage your code, Coda isn’t your tool. Coda is there when you want to make a web site, not author forty five new classes to go into your ever growing home grown code vault.

And that’s the key. Coda is iPod-esque in that it trims out everything you don’t need to get the job done. This enhances its usability and enhances your ability to focus on the task at hand.

I found working in Coda to be far more productive. I could see everything I was working on, I didn’t need to bounce around to get to other ‘views’ of my work, which left me more focused and productive (and less likely to get distracted by some goofy web site on the way)

Coda organizes projects into “sites” which allow you to specify your local working directory, a remote FTP directory, and a remote terminal shell if you wish. Everything but the local directory is mandatory. (Coda will open and edit any old file you point it to. You don’t have to stick it in a ‘site’)

Coda provides a ‘live’ preview of your site — which generates a tiny little actual thumbnail of your web site. Slick.

My only gripe is that Coda doesn’t allow you specify a local web server for previewing PHP (or other server side languages). I work around this by opening a new tab, and just browsing to my local server. Easy enough, but it would be nice to have your preview be smart enough to run PHP files off a local server.

Coda is very inexpensive. The promotional price is $79, but it appears it will bump up to $99 in the future. $99 is cheap.

I was waffling about whether or not to upgrade my aging copy of Dreamweaver to the next version — after trying Coda out, Dreamweaver will not be getting upgraded.

At full price it’s half the cost of a Dreamweaver upgrade, and it does all the important things Dreamweaver does.

Dreamweaver has many more features, but exponentially more bloat. I would argue that the “features” are actually “crap”, but that’s another topic. The only thing I’ve used Dreamweaver for in years is having a decent HTML/CSS editor with a file manager and an FTP program. Coda has this in spades.

Tha’s right. You heard me. Coda is a Dreamweaver killah. Expect Macrodobe to come up with a look-a-like in 2008.

* I own and run both BBEdit and TextMate regularly. They are must-haves for any developer on a Mac.

http://www.oddlaa.com/extras

This is a well executed illustration, and probably will help a lot of folks out. However if you’re doing “web design” completely in Photoshop or Illustrator you will encounter at least three major problems.

Number one: If you are making complete*, presentation ready, design comps in Illustrator or Photoshop, you are lying to your client.

There I said it.

While it’s necessary to use tools like Illustrator or Photoshop (or whatever) to make highly polished graphics for the web, if you are doing all of your design work in a graphics program you are basically making something that can never be truly executed in HTML/CSS.

The slick fonts, the pixel-precise layout, hairline borders, nicely tracked and kerned typography, the assumption that everything will fit nicely on a page…all lies.

The mockup you show your client essentially becomes part of your design contract. When you present a mockup, and the client approves, you are basically promising to deliver what you showed them. Unless you have a very savvy client who understands the difference between Photoshop and a web page, you are setting them up for disappointment, and setting yourself up for a headache.

Client: “That doesn’t look like what you showed me.”
Your Dumb Ass: “Well there are differences in capability between web browsers and blah blah blah blah zzzzzz snore ramble.”
Client: “Yes, but that doesn’t look like what you showed me.”

Only present mockups in HTML/CSS. Get a cheap hosting account. Put your comps online. Carry a laptop to meetings, and run them off your computer.
If you need to sketch or develop in Photoshop or Illustrator, fine. Do it. But don’t create a painting in Photoshop then lie and call it a web page.

If you present work exclusively in HTML/CSS you can do a number of things.

• You can present an accurate picture of what you’re developing to your client. No surprises.
• You can resolve potential browser display problems before you get to the client
• You can create a standard set of markup from the get go…saving work later (or just use a standard markup template each time)
• You can put the comps up on a web page, and let the client look at them at home, pass a link around to their colleagues. You know. Take advantage of the internet.

If you are making purty pictures in Photoshop, you have to cut up your graphic into web-able chunks, and write all the HTML anyway. This means you’ll probably have to make an intermediate graphic file to support your specific needs — like backgrounds for tabs that allow for expansion, or a template for header graphics that may change from page to page. Why do more work than you have to?

Number two: Safari’s browser chrome is Apple’s intellectual property. (And IE’s chrome is Microsoft’s intellectual property, and Firefox’s chrome is Mozilla’s intellectual property, etc)

Why are you stealing from Apple? Why are you putting someone else’s creative work in your portfolio? Also, unless you’ve got a hip client, they’re running Windows and probably Internet Explorer. Why are you showing them a browser they don’t recognize?

Why are you showing your client a picture of a web browser at all? It’s 2007. If you are making a web site for somebody, they know what a web browser looks like. You don’t need to stick a picture of a web site in a picture of a web browser. Design in HTML/CSS and put it on the web, and ta-da it will be in a web browser automatically when they look at in their web browser.

If you need to put a picture of your web design into print, or on a web page (and you can’t just link to a comp somewhere) leave out the browser chrome altogether. Your portfolio will have a title that says something like “web design” — or better yet you’ll actually have a description of the project which will indicate that it was a website and not something that only looks like a web site.

Number three: Pictures of web sites do not tell the entire story.

Chances are very good that your web design will include at least some level of interactivity.

• Maybe your navigation highlights when you move the mouse over it.
• Maybe you have a handsome (standards compliant) drop down menu.
• Maybe you have a form or two with some nice AJAX-y elements.
• Maybe you want to show how the design holds up at different screen resolutions, or how the type scales easily.
• Maybe you’ve designed a really nice print stylesheet.

While you can show all of these things in a picture, you’ll need many images to do it even marginally well.

It’s far less work, and tells a much better story to your client, to say “now click here” than to say “in this picture we show the initial state” [flip flip] “and in this picture we show the active or clicked state” [flip flip] “and in this picture we show the blah blah”.

Now, if you are the type of person who feels like their hands are cut off unless they have Photoshop open, this advice is going to be hard to swallow. I suggest — as a form of therapy — to do your designs the stupid old fashioned way, then convert them to HTML before showing them to your client. That way you’re only wasting time.

Sooner or later someone will demand a printout. It’s unavoidable. In that case you should still do all your work in HTML/CSS then screen capture the results. Place the screen capture on a page, scale it down so it doesn’t look to jaggy, and include a URL underneath it that points to the real thing. That way you’re indicating that the real thing is available elsewhere, and this print out is just the merest shadow of the actual glory of your design.

* I don’t mean prototyping. If you’re doing prototyping, it’s nice to have a paper version that people can scribble on in meetings. But doing a final design isn’t a prototype.