Adam Banks on Flash:

Flash is a technology that emerged from 1990s multimedia and appeals to developers, especially developers who aren’t really developers and are hoping they can get away with it.

I’m going to be smiling for the rest of the day now.

About a week ago, a design acquaintance of mine mentioned Clients From Hell on Twitter. Although I consider myself very lucky on balance, with the vast majority of my clients being great, everyone in the industry has horror stories to tell. Clients From Hell is a place for anonymous contributions, and had me transfixed and also laughing at stories that mirrored some of my own experiences: clients who think that because they could really do something themselves, they shouldn’t have to pay you to do it for them; people who want you to design something despite not being able to supply any kind of brief; unrealistic businesspeople who want the moon on a stick for next to nothing.

But having followed this blog for a few days via RSS, I’ve become increasingly uncomfortable with it. Horror stories are all very well, but I’m under the impression that some of these clients from hell have had the misfortune to deal with designers from hell.

Part of the problem of the blog is that there’s no context. So while it’s amusing to laugh at the ‘stupid client’ who said “the unicorns don’t look realistic enough”, that statement could make perfect sense. Unicorns are fictional, but they’re basically horses with a horn. Was the response to the unicorns in the design simply down to them not looking like horses? If so, that’s pretty efficient criticism from the client, not something to joke about.

Elsewhere, design snobbery is rife on the blog, and that’s quite depressing. If anything, it shows how many designers take their knowledge for granted and don’t take the time to explain the obvious to clients (or at least ensure they understand certain things). There are several posts ridiculing clients who respond to ‘lorem ipsum’ placeholder text negatively, but outside of the design world, who knows what this is? If you don’t make your clients aware that the text in mock-up designs is gobbledygook, how are they to know something hasn’t gone wrong?

And so it goes: a client wants a “darker black”, which is something almost everyone in the print industry must have said to printers at some point; another can’t find the shade of blue they want in the Photoshop colour picker—a hugely complex visual device for someone who’s not used it before; someone asks a designer to innovate by adding Flash animation to an email newsletter—not an outlandish request for someone not involved in web technology on a day-to-day basis; a banner is measured on-screen by someone else, which makes perfect sense if you’ve never worked with pixels in a design package; and one comment is from a client saying an iStockPhoto watermark doesn’t add anything visually, but were they informed that stock images, until purchased, are watermarked?

A designer’s job isn’t just to design—it’s to communicate. But this doesn’t just mean communicating the client’s message to an audience—you must also communicate with your client, and ensure they understand what you’re doing and what’s technically feasible. Laughing at someone who doesn’t share your technical knowledge doesn’t make you a great designer—in fact, it rather makes you the opposite.

TechRadar reports Adobe’s firing more shots at Apple regarding Flash on iPhone. The arguments, made via an irritating, patronising ‘skit’ suggest 1) Apple is really stupid because Flash doesn’t run on iPhone, and; 2) Adobe is really great, because it can get Flash to run on iPhone.

However, important points are missed:

• The Mac version of the Flash plug-in sucks balls. It’s the main source of Safari crashes on the Mac desktop, and the sandboxed plug-in still crashes regularly on Snow Leopard. The likelihood is, on the basis of the Mac version, the Flash plug-in could also suck balls on iPhone. Worse, with iPhone being relatively underpowered compared to desktop Macs, a Flash plug-in would wreck Safari’s stability and speed.
• Adobe’s mostly crowing about standalone Flash apps. There’s a whole world of difference between Flash apps on iPhone and Flash working within a browser that has its own overheads. (Note also that Flash apps don’t have access to OS X for iPhone UI components, and so many of them are a mess in terms of interface.)

I very much hope reporters don’t start moaning in unison that since Flash apps run on iPhone, so too should the plug-in—but I’ll bet they will. In the meantime, perhaps if Adobe rewrote its Mac Flash plug-in so it was even remotely comparable to the Windows one, Mac users and Apple itself wouldn’t be quite so hostile towards the technology.

On the 5th, Network World ran the article Three Reasons Why iPhone Won’t Get Adobe Flash. The reasons were: Apple doesn’t want Flash on the iPhone, the iPhone is created so it won’t support Flash (the article cites Apple not allowing plug-ins for mobile Safari), and Apple is betting on a different standard (HTML 5).

Funny that they missed out the most likely reason: Flash on the Mac—specifically the Flash plug-in—sucks.

On Leopard, the Flash plug-in is so unstable that Apple sandboxed browser plug-ins in Snow Leopard’s Safari. Interestingly, I’ve had one Safari crash since upgrading to Snow Leopard, compared to at least one per hour on Leopard. The Flash plug-in process, however, keels over with alarming regularity.

Also, put a PC next to a Mac and run some complex Flash content. Watch in horror as a knackered old PC outperforms a shiny new Mac—something that just doesn’t happen elsewhere.

Apple might be a huge control freak, but it’s proved plenty of times in the past that it will let other companies into its play-pen. However, said companies have to prove themselves worthy. I have no doubt that if the Flash plug-in was an amazing piece of Mac engineering, Apple would—at least now the App Store is hugely successful—allow Adobe to create the equivalent for iPhone and iPod touch. But since the Mac version of the plug-in is such a buggy, sluggish pile of garbage, why would Apple let the Flash plug-in anywhere near the mobile version of Safari, where it could at a stroke create the impression that Apple’s handheld platform and browser are slow, bug-ridden and unstable?

One of the reasons I like Mac OS X on Intel is because it provides the best of all worlds for a web designer. You use a Mac to build and test stuff, get a built-in Apache server, and you can run Windows—in a window.

However, if you want to run multiple websites and also test them in the virtual machine, you have to jump through some hoops. They’re not very difficult hoops, but if you’re not hugely technically minded, it pays to have some advice. So, here’s how I got everything up and running on my new Mac earlier today. Note that I’m using Windows XP and so your mileage may vary for other flavours of Windows.

1. Create folders within ~/Sites and bung your websites in them.
2. Install VirtualHostX. This $19 app saves faffing about with your Mac hosts file, doing the heavy lifting for you. For each site, click ‘Add Host’, type in a domain (such as reverttosaved.site) and define a local path (as in, the relevant folder within ~/Sites).
3. Click ‘Apply Changes’ and VirtualHostX will do its thing. At this point, you should be able to view multiple sites in Mac browsers, using the defined domain names.
4. Open System Preferences, click Sharing and make a note of the IP address under ‘your computer’s website’.
5. Launch VMware Fusion and ensure it uses bridged networking for your VM. (Virtual Machine > Settings > ‘Connect directly to the physical network’.)
6. Go to C:\WINDOWS\system32\drivers\etc and open the hosts file in Notepad.
7. For each domain, type the IP address from step 4, then a space or tab, and then the domain (e.g. 192.000.1.99 www.reverttosaved.site) on its own line. Save the hosts file.
8. Go to Start > Run, type cmd to open a command-line window. Type ipconfig /flushdns to flush the DNS resolver cache.
9. You should now be able to access your domains via browsers in your Windows VM. Note that steps 6 through 8 need repeating for any additions to VirtualHostX, so it’s worth sticking a shortcut to hosts on your Windows desktop.

All this might be obvious to you, in which case, well done, Mr Geeky Pants. For me, it was a little journey of discovery, and so I hope this quickfire tutorial might help you if you’re not used to mucking about with hosts files.