AlanHogan.com

Qwest Customer Service: Terrible

Wed, 21 Oct 2009 20:22:18 -0400

What would you do if your broadband service with your DSL company ended when you moved several months ago, and out of the blue the following landed in your e-mail inbox?

Notice: Changes have been made to your Qwest® customer profile.

Our records show you recently made these change(s) to your customer profile, either by contacting a Qwest representative, or through your MyAccount page at qwest.com.

Email Address Changes
*The e-mail address you provided for us to reach you.

For Qwest account ending in:7503

At Qwest, we value the security of our customers’ information and are sending this notice as a confirmation. As long as this change was made intentionally, no action is necessary. However, if you feel this change has been made in error, please contact Qwest immediately at 1 866-450-6152(Residential) or 1 800-603-600(Small Business).

Thank you for helping us maintain the security of your account.

[Marketing pitches comprising the rest of the email have been redacted.]

Well I certainly hadn’t made the change, so I called Qwest at the number provided. After being asked irrelevant questions by their friendly and persistent automaton, I was transferred to a real live human operator. I explained the situation.

He asked me a few times if I was sure I hadn’t changed my email address. After finding my old account number and reading it to him, along with my name and address, he informed me my old customer number had been re-assigned to a new customer and I “had probably nothing to worry about.”

“‘Probably’ isn’t good enough,” I replied. After all, they hand sent an email designed to alert me of suspicious activity. I hardly wanted my old account to be used to pay for someone else’s Internet service. He then assured me it was a completely new account (without, to his credit, divulging any personal details of the new customer).

At this point it was now clear the alarming email I received should not have been sent and my time was therefore wasted. I asked the representative to ensure this would not happen to other Qwest customers in the future. He refused to do so, saying there was nothing he could do. I did not, of course, expect that he would roll up his sleeves and fix this bug in Qwest’s system, so I clarified by asking that he tell a superior about the problem to ensure it would be taken care off. “I am sure there is nothing they can do, either,” was his hopelessly pathetic, unempowered, uncaring, self-defeating reply. I insisted he try and was promptly put on hold, at which point I hung up, having had enough.

I fault both the Qwest representative and Qwest itself here. The representative clearly didn’t care if the problem was ever resolved, though it would end up wasting more customers’ time and costing his employer money in unnecessary calls to customer support. The Qwest company itself evidently has a corporate culture of apathy and does nothing to empower or educate its representatives to help get real problems solved.

That’s the lesson to be learned here: Tell your employees to do whatever it takes to solve the problem at hand. Tell them what to do when they don’t think anything can be done.

In the past I have had difficulties with Verizon, AT&T, and Cox as well. Is there no decent telecommunications company?

Github Issue Linker

Sun, 06 Sep 2009 03:46:00 -0400

The plugin and what I use it for.

The Plugin

GitHub Bug Linker is a simple Wordpress plugin that looks for numbers with pound signs in front of them and links them to issues in your GitHub repository.

There is a lot of room for improvement:

Doesn’t acknowledge other syntaxes for linking to issues that GitHub supports (like repo/#1).
Doesn’t ignore numbers in <code> or <pre> blocks (straight regexp find/replace).
Would be fantastic if it used the GitHub API to check the status of linked issues and cross off closed issues.

This plugin is based on EHT Mantis and is released under the LGPL.

Download GitHub Issue Linker from its Wordpress Plugin page.

Killer App: Dev team wiki/documentation

I have paired this plugin with a few other Wordpress plugins to create a darned good (programming) project documentation system:

Members Only to keep anyone but team members from seeing documentation¹
Markdown for Wordpress and bbPress because
- it disables Wordpress’s annoying over-processing of content and
- it allows us to use Markdown, my favorite quick markup/wiki syntax (also used on GitHub for everything but their wiki)
Email Users so team members can alert others to new and updated pages
WP to Twitter to populate our private, internal Twitter feed with new and updated documents
highlight.js to automatically highlight any <code> pasted into the content
One of the “Link to Post” plugins to make linking to other doc pages simple

It’s a pretty great system, in my opinion.

Yes, Wordpress allows individual pages to be marked as private, but then they donât show up in the nav, and neglect could expose sensitive information. ↩

Snow Leopard Problems

Thu, 03 Sep 2009 19:56:16 -0400

I installed Snow Leopard less than 48 hours ago. So far, these are the ostensible bugs which I have bumped into:

Upon installation, my system hung on first boot-up. A hard reset took care of that.
Once or twice, my desktop icons were nowhere to be found.
Google Gears doesn’t work in Safari all of a sudden. I had to Google how to uninstall it before Gmail would load.
(Update: Not a Snow Leopard bug, more in a bit.) The top half of my (laptop’s built in, not external) monitor occasionally flashes black for a millisecond. This occurs at seemingly arbitrary times and blackness lasts just long enough to be noticeable and annoying. (I like to imagine that it contains a subliminal message — “IGNORE THIS FLASH” — and I am immune to its effects.)

Update (2009-10-31): It turns out that my MacBook Pro, which has two video cards, has a problem with one of them. (Apple will probably fix this when I ask them to.) Installing Snow Leopard must have switched my setting to use the problematic low-power card. Switching to the beefier card (via System Preferences) has resolved this issue for now.
Spotlight sporadically won’t find the application I was searching for, such as iChat, Keychain Access, or System Preferences. This is important because Spotlight is my app launcher, and now it’s not reliable for that task. Not fixed in 10.6.1. Update (2009-10-31): This problem hasn’t happened for a while. My Spotlight index was rebuilt, so if you have this issue, try rebuilding your Spotlight index.
The “Calculate All Sizes” option fails on some folders of a network drive of mine — even on folders with no more than 8 files. (Added 2009-09-07)
I realize it was not officially supported, but it was possible to back up to a network drive (without an AirPort Base Station) via Time Machine in 10.5 Leopard, but now on Snow Leopard, backups have been hanging indefinitely. (Added 2009-09-07)
Sometimes switching Spaces via the keyboard has left the spaces indicator on my screen after I let go of all the keys, and then I could not use my (MacBook Pro’s built-in) keyboard until I logged out and then back in. (Added 2009-09-08) Update (2009-10-31): This hasn’t happened for a while, either; maybe the 10.6.1 update fixed it. Not sure.

You can imagine that some of these quirks are damned annoying.

Still, there have been some really nice little improvements, like the dock & Exposé integration. I think the net change is positive, but boy am I ready for Apple to release 10.6.1 with a few bug fixes! Update, September 11, 2009: I just upgraded to 10.6.1, and some of these issues are still not resolved. I am updating the list above when I know for sure that an issue has or has not been resolved.

Finally, I’d like to note that some of these things could well be caused by third-party apps. That said, it’s clearly the OS upgrade that triggered these problems. Apple, you’ve let me down.

Pasting Unformatted Text on OS X

Thu, 30 Jul 2009 21:21:14 -0400

One of the few default settings that genuinely annoy me on Mac OS X is the tendency for Apple software to retain source formatting when copy and pasting. This can be particularly annoying in Keynote (since pasted formatted text is incredibly small) and in Mail.app.

There are two solutions.

Set Command-V to paste unformatted text all the time:

Simply follow this tip which sets a system-wide keyboard shortcut for Command-V to trigger the menu item “Paste and Match Formatting.”

May not work in all apps, but it should work in most. When it doesn’t, you can use the first tip.
Manual workaround each time:

Use the “Paste and Match Formatting” menu option, or the following keystroke sequence:

Paste into Spotlight search, select it, copy it (unformatted), then paste. This even works for multi-line text.
1. Command-Space (or whatever you have Spotlight set to).
2. Command-V for paste. (The text is now unformatted).
3. Command-A to select all.
4. Command-C to copy that unformatted text.
5. Command-Space to close Spotlight. (Focus returns to whichever app you were in previously.)
6. Command-V to paste unformatted text.
It looks like a lot of work but it is actually very, very quick for me. (I type in Dvorak, but I don’t think that makes a big difference here.)

Nielsen, Password Masking, and the iPhone

Tue, 14 Jul 2009 23:52:29 -0400

This is my reaction to the recent password masking debate Nielsen ignited. Summary: A checkbox to show the password is acceptable (perhaps ideal), but showing passwords by default or using the iPhone-style solution on websites is a bad idea.

Introduction

Recently, respected and influencial usability guru Jakob Nielsen stated that “[u]sability suffers when users type in passwords and the only feedback they get is a row of bullets,” which “doesn’t even increase security, but it does cost you business due to login failures.” This is probably one of his most popular recent alertboxes due to its very controversial nature. Most of the reactions I have heard have been very negative, as Nielsen ridiculously dismisses out-of-hand the potential for shoulder surfers to oversee passwords (“a truly skilled criminal can simply look at the keyboard and note which keys are being pressed”). That is, of course, rather naÃ¯ve. Why not say, “A truly skilled criminal would add a keystroke logger,” or “A really determined bastard could waterboard victims for passwords.”

His final suggestion is to stop masking passwords but to provide a checkbox to enable masking, if so desired, in cases of high security (e.g. bank websites). I find this completely unacceptable for reasons Nielsen himself has enumerated in other contexts.

Regardless, Nielsen does make some good points in his alertbox.

Constraints, concerns, and observations

Nielsen: Being able to view your password instils a sense of confidence and allows the user to ensure they entered it correctly.
Nielsen: Users spend most of their time on other websites.
Those who can’t touch-type have more trouble with passwords then those who can (assumed by myself; should be self-evident).
Nielsen: Users skim, and they read in an F-pattern.
Nielsen: Users have a harder time entering passwords confidently on mobile devices.
Nielsen: …but it’s still not easy on desktops and laptops.
Good mobile devices deal with observation 5 (e.g. iPhone).

All masking, all the time

Pro: Eliminates shoulder surfing.

Con: Doesn’t allow users to check they entered the password correctly.

iPhone style password masking

This is the style popularized by the iPhone, though they probably did not invent it. As Gruber succintly put it:

The iPhone strikes an interesting middle ground here — it shows you each letter youâve typed in a password field for a second or so before turning it into a bullet.

At most one character is revealed at a time. This applies not just for iPhone apps but also for web pages viewed in Mobile Safari.

Some have made attempts to implement this on websites with JavaScript hackery. I think this is an absolutely horrible idea, though innocently conceived. Go ahead, though, try it out if you aren’t familiar with the iPhone.

If Apple thought iPhone-style password masking were ideal for the desktop, as well as for the iPhone, they would implement it on the desktop. They do not.

If someone types fast enough shoulder surfers cannot see the password, then they are typing too fast to get the benefit of confidence that Nielsen described.
If someone types slow enough to get the benefit of confidence, then they are typing slow enough for shoulder surfers to catch the password.

The implementation would be extremely difficult to get right on the Web. I have not seen, and (since the above items make this solution less than ideal anyway) do not expect to see, an implementation that gets it right. A solution would need to prevent plaintext passwords from being shown when JS is off and in all browsers. It should also allow editing a password from the middle, because that’s how it works on the iPhone and in normal password boxes. Those of us with lots of HTML experience can imagine how very difficult that would be to implement. It should not break “wand” or auto-fill browser functionality. Also, going “back” a page in (any and all!) browsers should not show a plaintext password.

Lastly, in the case that browser and/or operating system manufacturers change the way password boxes work (say, with a built-in toggle mode, or iPhone-style on mobile devices), JavaScript methods like this will override that and possible break the password box completely for those users.

Verdict: a bad idea in theory as well as in practice.

Providing a checkbox to enable masking (masking off by default)

Thinking about observations 2, 3, and 4 from above means that any websites with password masking off by default — even if they have a checkbox to enable it — can and will catch users off-guard; some will enter their password before realizing it wasn’t masked. It will be seen. It is irresponsible to pretend this doesn’t matter. Consequences can range from, yes, bank passwords being seen to a friend overseeing a Facebook password and setting an innappropriate status message that the user’s family or boss sees.

Con: Shoulder surfers will still view passwords.

Con: Going “back” reveals the password.

Verdict: Terrible idea.

Providing a checkbox to disable masking (masking on by default)

As I mentioned before, Apple does not enable iPhone-style masking on the desktop. What they often do instead (e.g. when entering network passwords) is provide a toggle (in the form of a “view password” checkbox) so that users may optionally view their password as they enter it.¹ This is a great idea and is much easier to implement than the iPhone-style password masking.

Pro: Enables users to check their password entry if and only if they are confident no one is watching.

Con: If care is not taken to convert the plaintext back to a masked password box on form.submit and page.navigate (i.e when users leave the page), going “back” will reveal the password.

Verdict: Take care of the problem mentioned in “con” but this is by far the best solution.

Conclusion

Masking by default and providing a mechanism to view passwords at will is the best solution.

It should be kept in mind that there are a lot more password-related concerns to keep in mind; consider enforcing strong passwords for users and use encryption, password salts, and hashes server-side.

Windows (XP, at least) does the opposite: When joining — not creating, but joining — a network, it forces users to enter a masked password twice. ↩

The Anti-Competitive Google

Tue, 14 Jul 2009 19:18:05 -0400

Google is betting that the Web is going to continue be a very strong platform. They are betting that web apps will provide a large chunk of our productivity and pleasure, where traditional desktop programs used to.¹ With their strong hand in HTML5, their open-source Gears browser extension, and the drafting of the Wave protocol, Google is loudly proclaiming the Web to be an open environment that no one entity should control. Their actions, however, belie this vision in favor of anti-competitive corporate strategies.

Google’s public vision for an open web

Google has indicated they believe in the Web as an open, popular platform in which anyone who implements the open, published web technologies (HTML, CSS, JavaScript, maybe Gears) — which other companies can help shape and define — can have a browser that can run any web apps and view any web sites crafted to those same standards. (Contrast this with Microsoft, whose past strategies pushed Windows Internet Explorer-only technologies like the insecure ActiveX API and VML, and who would still to this day have us use Silverlight, which does not run on all platforms or browsers, and Web Clips and other IE-only tech).

Google has made the following statements to lend credence to that position:

We are working on (and an employee of ours is controlling) the HTML5 specification, a collaboration between major browser vendors, reducing or eliminating the need for awkward and closed plugins like Flash or Silverlight; this makes the Web an open playing field, and any device and any operating system can now have the full web experience without Adobe or Microsoft’s consent.²
We are writing a protocol called Wave to power the next generation of Web communication and synchronization, and we won’t control it; it will be email or HTTP, a specification anyone can implement without our consent or help.
We wrote Gears and made it open-source, so all browsers (not just ours! cough, cough, Microsoft) may run web apps with features that once only native apps could have, and to speed up certain kinds of sites.
- In the meantime, we released Gears as a plug-in for popular browsers such as Safari and Firefox.
- We built Gears into Chrome, and hope other browsers include it by default in the future.
We believe the Web is going to be so powerful that we announced plans for an OS based on Chrome (WebKit) and Linux (Just like Palm’s Web OS.)

Inconsistencies and other anti-competitive red flags

Let’s examine a couple ways Google has betrayed their publicly stated vision with contrary actions:

Google has a policy of not supporting or testing their web apps in Opera. Opera is a browser that has driven much web innovation (inventing not only tabs but Chrome’s new start page, to name a few) and always supported open Web standards (such as the effort to write HTML5, and in fact, their CTO invented CSS). Opera has very few inconsistencies with other websites.

The problem is so bad that Opera users can’t add Gmail events to Google calendars, and the emails that Opera users send in Gmail suffer collapsed line breaks so that the paragraphs run together. It’s been like this for years.

While I have called on Opera to step it up and fix these issues themselves to enhance their own market share (low market share is a vicious cycle for browsers and other platforms, because low market share means fewer developers support it, which inclines users to avoid it), I would argue that for Google to create and ignore these problems is anti-competitive. (I have discussed this before.)

How is this anti-competitive? It means that a company who makes the world’s best webmail says, “We choose to force 100% of the people who like our webmail to use one of the browsers on our list, and not Opera. In faaact, you will get the best experience in our own browser, Chrome.” What got Microsoft into trouble was throwing its dominance in one software category (OSs) around to dominate other markets (browsers, office suites, media players). To cite market share as a reason to avoid supporting Opera is a cop-out because of the vicious cycle I mentioned above: When you’re a big dog and a trendsetter with lots of cash, you better do the right thing and play fair.

Why is not supporting Opera inconsistent with an open web strategy? Because claiming to support an open-standards-based Web that works on all browsers, including Opera, with whom Google is working on HTML5, but not actually supporting that very open-standards-compliant browser just doesn’t make sense.
Seemingly dropping support for the Gears Firefox plug-in

As I write this, it has been a full 2 weeks since Firefox 3.5 officially launched (on June 30, 2009). There had been completely public betas and release candidates (the last of which, per Mozilla policy, became the stable 3.5 release, bit-for-bit) available for some time. And yet, to date (July 14, 2009), Google has not updated their Gears plugin for Firefox 3.5 (which, among other things, enables offline Gmail and speeds up WordPress publishers’ experiences).

You might be thinking, dear reader, that it could take significant time to update the plugin for Firefox 3.5.Â You would be mistaken, though quite understandably: Users have taken the open-source code, tweaked it, and compiled it to work with Firefox 3.5 on Windows, Linux, and Mac OS X. (This didn’t solve the problem, because Firefox does not know about these unofficial, untrusted fixes and can not/should not make them available via its add-on update routine.)

So it’s not that the upgrade takes too long. Google knew ahead of time Firefox 3.5 was coming and its users showed that the fix is fairly trivial. It’s just that Google is dragging their feet. Because they aren’t replying to users, no one knows why. (Does Google hate their customers? Or are they just arrogant?)

But users have their suspicions. One wonders, and I join him, if this isn’t a deliberate (and shady) attempt to get Firefox users to switch to Chrome. Is it? What other reason could be at play? The only alternative I can think of is just developer laziness and an incompetent manager or two. Then again, many people at Google use Firefox, and there is no way this issue could have gone unnoticed.

How is this anti-competitive? Why is it internally inconsistent? Google says it wants an open, interoperable, Web with a diversity of browsers all supporting the same open standards and ideally with enhancements like Gears (which is, remember, open source) that make for a better experience. But by denying Gears support for Firefox, they are pressuring Gmail users to switch to Chrome; using one product to artificially support another is anti-competitive and any attempt to homogenize browsers toward one (Chrome & the WebKit engine) betrays the vision of the open Web.

True feelings about the open web

I wish I could summarize Google’s true position, but the contradictions here are too great for an outsider like me to resolve. The least we can conclude is their actions are considerably less benevolent than Google would have us believe.

Let me know if you have anything to add.

This article can be shared as http://alanhogan.com/gac

Hence the Chrome OS initiative. My reaction is between the unthinkingly obsessive Arrington-style “OMG this will be big” and the piffling “won’t be anything” response from others: I think Chrome will be just what it is planned to be, a competent entry for netbooks. That is, no, it won’t ever gain much if any traction on traditional personal computers; but if done well, it could provide a smooth (if limited) experience on small, cheap devices used mostly for email and casual surfing. ↩
Sounds a lot like what Apple’s gung-ho true-web-technology push, as they embrace HTML5 wholeheartedly in Safari, extend CSS in innovative and backwards-compatible ways (transitions, gradients, transformations), make WebKit (the core of Safari) available for anyone to use for pretty much anything (from Chrome to Palm WebOS to NetNewsWire), and reject plugins (as they should be able to do!) on the iPhone. The inconvenience of missing Flash, in my view, is not a poor reflection on Apple but on everyone who has used Flash as if it were a Web technology. It is not. It does not integrate well with the rest of the webpage and needs drawn in a separate pass from the rest of the rendering engine, unlike pure web technologies like HTML text, images, SVG, and even <canvas>. You couldn’t apply a JavaScript event to a Flash movie component. You can’t style Flash text with CSS. You can’t (really) link to a “page” or view on a Flash site. You can’t middle-click a Flash link to open it in a new tab. Flash is its own little island. It’s not the Web. ↩

The Arrogance of Google (and the effect on its users)

Tue, 14 Jul 2009 19:18:05 -0400

Google seems to be letting its arrogance dictate a position of indifference towards customers. I argue this is not a wise move.

Google arrogantly thinks their customers have nothing to say.

It would seem Google bloody hates their users.

How else can you explain they way they make feedback and dialog between users and themselves darn near impossible? Even using a solution like GetSatisfaction.com would be many steps ahead of their current mix of help pages (typically lacking any sort of “contact” link) and groups (in which users are supposed to guess at Google’s intentions and/or solve each other’s problems). I say GetSatisfaction would be quite an improvement because it not only smartly attempts to consolidate multiple questions about the same thing into one page/discussion with a keyword matching algorithm based on questions users type, but critically, it provides the company (Google, in this case) a means to designate an official reply or status at the top of the page. Compare this to scrolling and paging through up to hundreds of posts in Google Groups, hoping you can skim fast enough and well enough to see which, if any, posts are from someone claiming to be a Google employee.

Again, the technology is there. Google has money. So the only reason they would be treating their customers so badly is that Google is so arrogant that they don’t think their users matter.

I don’t just mean users of, say, Gears, or even Gmail. Even customers generating revenue for Google, those using AdWords and Checkout, can’t get a real human to help them out.

The value of listening to customers

I’m sure many others have stated the value of listening to customers much better than I, but here is a quick list of benefits from my experience:

They catch bugs and regressions that developers miss.
They can have great ideas for your product (and are frustrated they can’t share them).
- 425Walker has one for Google’s Blogger service.
- I had a number of ideas for Gmail back in 2005, some of which were eventually implemented; but I never was able to actually suggest them to Google.
- Update (July 15, 2009): As @JamesGecko points out, there actually are suggestion boxes for Gmail and Blogger (in fact, I have used the one for Gmail in the past). However, not only are they hard to find, but apparently no one ever receives personal feedback (is anyone listening?).
They can help you decide which features to implement. (Prime example: UserVoice)
They won’t feel like your company is a giant, unfeeling corporation if you actually talk to them.
Problems can pop up for a particular user, and if these are not taken care of, that user can complain very loudly and/or the service is less functional for them. Additionally, these users’ problems may illustrate an edge case or bug your developers overlooked.
- Example: When Twitter Search didn’t index my tweets due to a simple server-side caching issue, my pleas for help went unanswered for half a year, coming back with robot-generated replies and frustrating me to no end until @tiger graciously helped me out. In the meantime, I began to resent Twitter’s central authority, yearning for a distributed alternative. I also avoided #hashtags altogether as they were pointless; no one could find me on Twitter Search even if they searched for a hashtag I used. Presumably their caching mechanism needed improved.
- Example: Google Calendar’s ICAL feed, which I ensured was not being cached, contained recurring events which I successfully deleted from the web interface; no one at Google ever replied to my requests for help. Obviously, though, there was a bug in their system which made using it highly annoying for me, as I had to ignore events that should have been deleted.

As my last example makes clear, Google could use the feedback of its users.

The cost of listening to customers

Assuming not too much weight is lent to users’ feature requests, the only real cost of listening and replying to them is money (in terms of staff).

Google has plenty of cash.

Google not so feel-good anymore

It seems to me that problem of ignoring users (like their anticompetitive tendencies) is contributing to an overall trend of increased distrust of Google and and increased perception of them as another faceless big company. I hope to write more about this in the future. If anyone has seen data showing the trends I expect, or disproving them, please let me know.

Update (July 15, 2009): Just today, Ani reported that Google’s public perception of being “reliable, distinguished, and the best quality” slipped below Microsoft’s in a British survey.

This article can be shared as http://alanhogan.com/arrg

Import the iPhone User Agent into the Firefox plugin User Agent Switcher (download)

Wed, 20 May 2009 15:11:58 -0400

You can import this XML file into your User Agent Switcher plugin for Firefox so you can view and test the mobile or iPhone version of a site. The user agent string is the one described in this tip. (After installing User Agent Switcher, restart Firefox and go to Tools • User Agent Switcher • Options and click “Import.”)

Also of note is that the iPhone Simulator (part of the iPhone SDK from Apple) does include Mobile Safari and can actually navigate to your local development site (e.g. localhost:3000 or any other server running on your computer), not to mention the Web at large.

If this becomes painfully out of date, let me know by my contact form or twitter.

Student film festival tips

Wed, 29 Apr 2009 10:23:15 -0400

I’m not a film student. But I’m the guy who mutters about how annoying your mistakes are while attending the student film festival — and I’m the guy who can’t stop talking about how great your film was when you get it all right.

These are some tips to keep me happy.

I swear a bit in here, but you film students are used to that. Mom, skip to my next blog entry.

Spend more time writing your script than creating a logo for yourself.
- Read your script out loud.
- Don’t be afraid to rewrite your whole script. No cut-copy-paste superficial editing: rewrite the whole damn thing. After your first draft, you will have a better idea of what you are trying to say, and your next draft will let you really focus on saying that.
- You had better have a great point or make me laugh. Nothing is worse than a film with no point. I don’t give a shit if you used a camera angle you never used before.
- I’m serious about revising. Otherwise, you might end up like the poor sap who was laughed at by the whole theater for simultaneously attempting to reveal crucial plot information at the beginning of the film and pretending that no one knew that information and “suspensefully” building up to its disclosure at the climax.¹ It’s idiotic, but even an idiot would avoid this mistake once he/she decided he/she wanted to go for suspense and rewrote the script to eliminate the giveaways.
Seriously, about your logo. Don’t over-do it.

You can create a cutesy “X Productions” name and logo² for yourself if you really want, but if your film focuses on it for more than 2 seconds, I start choking on your delusions of grandeur. At 5 seconds, I throw up and can’t finish my oversalted bag of popcorn (no butter, if you’re buying to thank me for my brilliant and frank advice).
Ask friends for feedback on for script. Have them focus on plausibility and dialog (or humor, if that’s what you’re going for).
Lighting matters.

Don’t half-ass it. Keep your color balance consistent. And if your dialogue indicates it’s 3 A.M., don’t let me see light shining through the goddamn window.

Oh, and back-lighting is nearly always bad. When done well, it can really make your film shine; typically, though, it just makes it hard for us to see your actors. Which leads us to our next tip:
Do not use effects because they’re cool.

In web design, we have a maxim that no design element should be used without a purpose. I imagine the same rule works for effects of all kinds in films. What does it do? Nothing? Take it out!
Spend a lot of time editing.

Boring parts suck. Wow, you zoomed out from the detailed close-up to a wider action scene? Great, but if you take 30 seconds to freaking zoom out, I’ll pass out from a lethal case of boredom. Stop wanking while thinking about how classy your zoom-out is and cut to the chase already. If the audience is all aware of your camera work, you’re doing it wrong; they are missing your message.

Long speeches suck. You should have edited your drafts enough to prevent that, but for a documentary that isn’t exactly how things work — so play the money quote and skip the rambling.
Get feedback on your edited film, then edit it some more.

Your friends have eyes that haven’t already seen this on-set, in rough cuts, or the script. Use those eyes. Ask them what parts didn’t make sense. DO NOT dismiss their concerns, as your ego will ask you to. Figure out why your friends were confused. Was dialog ambiguous? Did it contradict something visually? Fix it.
Soundtracks are hard.

I am impressed by how well-done many of your soundtracks are.

Tips: Use music that suits your film, not just your taste.
Don’t use a song if the lyrics don’t fit.
Don’t layer a song with lyrics over dialog.
The only default font you can use for your title and credits is Helvetica. If you haven’t studied typography, you probably shouldn’t pick anything besides the following ridicule-safe fonts:
- Helvetica (Arial works as a substitute. See Helvetica the movie if you have any doubts)
- Gotham (Though you should be aware this is now associated with Obama, at least when used in all caps)
- Gill Sans (for credits/scenes; great readability, but ugly for titles)
- Futura / Century Gothic / Neutra (for a modern feel; titles only, not credits)
- Large, beautiful, classical (not edgy) serifs
If all else fails, just remember to never use any of the following:
- Copperplate
- Times New Roman
- Comic Sans (seriously.)
- Courier or any other unforgivably ugly monospace or typewriter font
- Bank Gothic (tempting since the pros use it, but it’s the most over-used film font since Trajan, and it’s wide as all hell anyway).
Also avoid “pure” (fully saturated) red, yellow, green, and blue (#ff0000, #ffff00, #00ff00, and #0000ff, respectively) for text. You’ll look like an amateur. Less-saturated colors, black, or white will do fine. We’re here for the movie, not to ooh and ahh over the fact you figured out how to change the font color for no bloody reason.

An uncommon font that directly relates to your subject is usually excusable, but let me stress that while it is a boring, vanilla choice, you can never go wrong with Helvetica.

Seriously, I cannot vote for you at the film festival if you use Comic Sans, and I will laugh out loud if your title is set in Curlz.
Do not over-compress your movie or edit at a low resolution.
Your film should not look like someone is playing a YouTube clip on the big screen.
Hope (or double-check well ahead of time) that the projectionist will show your film with the proper aspect ratio. Nothing is worse than all your hard work being ruined by the fattened look of your 4:3 actors being shown in 19:6. Yes, this happens, and it makes jerks like me want to walk out.
My friend and film editor Erica points out that you should cross-fade your tracks just a bit to avoid blipping. (Added July 14, 2009)

If I forgot something, let me know.

Good luck.

Update: Sarah Gonzalez at CAGE added these items to her outstanding collection of film festival tips.

Oh, and his/her dialogue was tacky, canned, and unoriginal, and the plot was altogether weak, and the apparent message was exaggerated, and it wasn’t funny. All of those things
would benefit from revision, but the attempt at suspense was the kicker. ↩
Where X is your initials, a pun, or an in-joke, no doubt. ↩

Bookmarklets: a la Instapaper & limit page width

Wed, 29 Apr 2009 10:21:54 -0400

I wrote this first bookmarklet (or favelet) to make reading online as pleasurable as reading articles in Instapaper, the iPhone app that lets you read long web pages later. The second is a weaker byproduct of that effort. Drag either to you bookmark bar.

à la Instapaper

Modeled after the divine reading experience that is Instapaper for iPhone, this sets your page for maximum readability. Narrow columns help you read faster because your eyes never need to check where the next line starts.

Disables all style sheets, sets text to black on white Georgia in the default font size, forces a narrow column for readability, and specifies a comfortable line-height of 1.4em. It does not force <pre> or <code> elements to be in Georgia.

(Updated 2009-05-04 to work better with <iframe>–using pages.)

narrow page

Just tries to force the page to be narrow. Doesn’t work nearly as well as the “à la Instapaper” bookmarklet.