Paul Smith, Technologist
Bio
Paul is an Internet communications specialist with more than eight years' experience developing for the Web. His particular area of expertise is creating communication solutions based on open source standards and software.Articles
-
Puppies as Economic Indicator
Indicator Recent Activity Dow Jones -40% YTD Consumer Confidence -31% in Oct 08 US Jobs -240,000 in Oct 08 Shiba Inu Puppy Cam + 3.4 million views Editor's note: Here's a graph compiled by Todd Moy that suggests a negligible correlation between the DJI and Google searches for "puppies".
-
Jargon-free Advice for Web Designers
1) There are things you can do in Photoshop that you can't do for Web. (So be mindful)
2) There are things you can do for Web that you can't do in Photoshop. (Be really mindful of that one)
3) It'll look different in the browser. It'll look different in my browser than in your browser. The client will be using a different browser altogether.
4) Design for fingers on mice as well as eyeballs. You know how when you're cooking, aroma is just as important as taste? Same thing.
5) Users want useful.
6) Google's home page is an example of extraordinary Web design.
7) People looking at a magazine ad are passive. People watching a TV show are passive. People using your Web page are active.
8) Watch out for Flash, it can sometimes turn engaged users into passive observers.
9) Be unconventional! Just remember conventions sometimes take shape for good reasons.
10) The user came to this page to do something. Help them.
-
Using Django QuerySet Refactor, Newforms-Admin, Trunk and Pre-Autoescape on the Same Laptop
Note: This little how-to works great for me and the way I work. I use a Mac laptop to develop Django sites which have a life as a production site somewhere else. If you work another way (like in Windows, or with Apache for development instead of Django's dev server, or if you work straight off the production server), this might not help directly, but I hope it helps get you started on finding a way to solve this little annoyance on your own.
So I do a lot of Django development on my laptop. I have a bunch of Django sites which I built over the course of the past two years or so - most of which I have to go back and work on a little every now and then. Because they've been developed at different times, most go back to before the new QuerySet refactor merge, and a few go back to before the Autoescape revision. I'm also looking at building my next site with the newforms-admin branch.
I'm using subversion to check out the latest versions of Django. I usually check it out into /usr/local and then make a symbolic link to it in Python's site-packages folder. Because some of my sites raise errors when I run them with versions of Django released after they were written, I find myself changing the revision number of my laptop's Django occasionally (and by occasionally, I mean way too often).
To get around that, I figured out that I can do this little trick. Now, in my /usr/local I have all the different versions of Django I'm likely to need. Like so:
django/
django-newforms-admin/
django-pre-qsr/
django-pre-autoescape/
django-myclient/The one called just django/ is the latest trunk revision... the one I usually use. The others are the revisions (or close approximations of the revisions) that I used when I made some of the older Django sites on my laptop. Each of these folders contains a folder called "django".
In the manage.py files for each of my sites where I can't or don't want to use the latest trunk revision, I just drop in a couple of lines right at the top:
import sys
sys.path.insert(0, "/usr/local/django-myclient/")
This drops the path to my preferred Django rev onto the start of the sys.path list, and Python uses the first django module it finds in it's path. Now whenever I use manage.py's shell, dbshell or runserver commands, I'm using the Django rev number I need without having to fool around with svn update each time I need to work on a different site. -
Speaking in Klingon, Part 2: The French Menu Syndrome
Communicating complicated ideas with others can present a lot of challenges - especially when you don’t share a common language to build on. In my role as a technologist at Capstrat, I can assure you that the toughest part of my work isn’t doing technical stuff, but rather creating understanding between technologists and non-technologists. You have to be able to communicate about technology so you can communicate with technology.
But how do you do that without all the techo-jargon mumbo jumbo? Should you even try? In my work, I’ve stumbled across a common bear-trap which I call the French Menu Syndrome. It goes something like this:
Suppose you run a fancy French restaurant. You’re going for discerning diners and elegant haute cuisine. You hire classically trained French chefs from Paris, and give them the equipment and ingredients they need so you can offer the best in fine French dining. Authenticity is the key.
The French chefs construct a painstakingly-crafted menu of carefully chosen, wonderfully creative and enticing dishes. The menu is like poetry; a sonnet sung in honor of fine French cooking. You welcome your guests and proudly present them with the menu your chefs have so lovingly authored. There are some raves, but you’re surprised when the majority of your guests aren’t as impressed as you thought they’d be.
Your fancy French chefs composed their opus in French (naturellement). But it turns out there are lots of folks who like French cooking and fancy French restaurants who don’t actually know any actual French. No problem - we’ll just translate our menu into English, and that way people will know what to order.
Except that most of the French dishes have proper names that don’t translate into English.
OK, no problem again. We’ll just include a little description of the dish in English alongside the name, and all will be well.
Except now, your guests are just as confused by all the cooking jargon, and some of the ingredients don’t translate cleanly either. Turns out that around here, not everyone knows the difference between a bechamel and a bearnaise.
In an effort to embrace your full audience, you eliminate anything that could potentially be confusing. Before you know it, you’ve changed the name of your restaurant from “Chez Jacques” to “Jack’s Place” and your menu reads like, “Beef cooked French-style in a creamy sauce with veggies. Yum!”
Hold on a sec, wasn’t the whole idea here to be fancy and authentic? Didn’t someone mention discerning diners? Come to think of it, those rave reviews have dried up and the discerning diners don’t seem to come around any more. Not only that, but now your fancy French chefs shout curses at you (at least you think they’re curses) whenever you get near the kitchen.
Even at a strategic communications agency, we get caught in this same paradox when we’re not careful. Our government relations, graphic design, PR, video production and technology teams have all occasionally had our respective varieties of jargon end up in front of people who need our services, but only understand those services in layman’s terms. Even worse, we sometimes create communications in broad, general terms that leave our clients’ in-house experts (like their internal IT teams) with too many questions - not least of which is, “do these guys have the chops to do the work”.
So where’d we go wrong with our fancy French restaurant? At what point do we stop looking for baseline common denominators? How do we satisfy our discerning diners who expect authenticity without narrowing down our clientele to just a few fickle foodies?
If you’re running a fancy French restaurant and you’re not in Paris, how about this: throw away the menus. Hire chefs who can also come out of the kitchen and meet guests. Invest in some really fancy, really talented, super-knowledgeable fancy French waiters. Don’t compromise on authenticity, but realize that the biggest part of your task isn’t being authentic, it’s helping your guests experience and appreciate the joy of fine dining. You may not win over the Golden Corral crowd that way, but c’est la vie.
The point is that there’s no shortcut. There’s no menu in the world that can connect with each guest and gauge their respective comfort levels with french and cooking jargon like a person can - any more than a single proposal, project plan or statement of work can serve as a one-size-fits-all channel for communicating an idea or a solution that has some kind of specialized expertise behind it. That’s why when you work with Capstrat, you’ll probably end up face-to-face with the graphic designers, user experience designers, web developers and other specialists who’ll be working on your project.
And they’ll speak English.
-
Speaking in Klingon, Part 1: When in Llanfairpwllgwyngyll...
Many years ago I was traveling in the UK, and found myself in a little pub in Wales making friends with some locals. Wales is an awesome place to visit, but if you don’t know any Welsh, the place-names can be tough to work out. They look like unpronounceable jumbles of consonants - some of them might as well be in Chinese. After a few drinks, I built up the courage to ask my new Welsh friends, “so what’s up with the way y’all spell stuff?”
The answer, they told me, was that centuries ago it made it a lot harder on English invaders when they couldn’t actually say the names of the places they intended to invade and occupy. Basically, they were telling me, they spelled stuff that way to intentionally screw with English-speakers. And it’s a plan that clearly works on modern-day invaders as well.
I’m not sure whether that’s actually true or just what they tell tourists in the pubs. But I’m reminded of this because I’ve been reminded so often recently of how difficult it can be sometimes to communicate with clients and colleagues about technology.
I belong to the technologist tribe. I spend at least a little time out of every day doing technical stuff, writing computer programming code, and discussing technology with fellow tribespeople. At the risk of dating myself, I’ll just say I’ve been at this for quite a while. So if you’ll take my word for it, I’ll let you in on a little tribal secret. All this technology stuff isn’t even a tenth as complicated as you think it is. No really, it’s not that hard. What’s hard is talking about it.
Everything hard about technology is in the language: learning about technology from manuals and experts, describing it to people who are unfamiliar with it, asking for what you want, understanding what you’re being asked for - all of it really, really hard.
As someone who’s been in the tribe for a while, I can tell you that becoming a productive technologist is a lot less about the ones and zeroes than it is about simply learning how to communicate with fellow technologists, especially when it comes to teaching it to those who know less than you and learning about it from those who know more than you.
Communicating with people who don’t know any of the ones and zeroes stuff is an even bigger challenge. They need technologists to build technology for them, but they don’t have the language to ask for what they want in a concise way. Sometimes they have a hard time describing what they want in a vague way. How big a problem is that? Try this experiment: think of a popular song. Now find someone who knows how to play guitar or piano. Describe the melody, but don’t tell them anything else about the song you’re thinking of. Do it without reciting lyrics, humming or using any musical jargon. Unless you can get creative about how you communicate with your friend, then it’s not a question of whether you’ll succeed, but who’ll be first to get too frustrated to continue.
With that same kind of barrier between technologists and non-technologists, it’s not surprising that folks who are decidedly not in the technologist tribe can often get frightened, confused, frustrated and even a little pissed off when confronted with Klingon-sounding technical jargon. There might even be the slightest suspicion it’s not Klingon, but Welsh: that technologists’ language is intentionally obfuscated and dense, crafted to keep the magic within the tribe.
For the most part, that’s not true. But what is true is that both technologists and non-technologists are complicit in perpetuating a communication barrier that extends beyond just acronyms and technical terms. You have to be patient (and creative) if you’re going to get your ideas across that barrier. Understanding how and why the miscommunications happen, and how we’re each complicit in making them happen is key to getting there.
So why do technologists use so much jargon? Wasn’t the word “blog” jargon just a short while back? How and when do we get ourselves into these language-barrier predicaments, and how do we get ourselves out of them? In the next couple of articles, I’ll discuss some of the specific challenges we technologists face in discussing technology with our colleagues, our clients and each other, and how to overcome the urge to reject anything and everything that sounds like Klingon (or Welsh).
-
Is PBS Still Relevant?
Charles McGrath, in his Feb 17 New York Times article, points out that while National Public Radio's listenership is growing, PBS television, he believes, has seen it's best days, and may perhaps be no longer relevant or necessary.
I couldn't disagree more.
We now live in a climate where local printed newspapers are in sharp decline, and where the cynical irony in Fox News Channel's name and slogan goes unchallenged. Even my parent's nightly network news broadcasts have devolved into 15 minutes of entertainment interspersed between 15 minutes of drug company commercials. In this climate where journalistic integrity and high standards are the exception rather than the rule, it seems to me that shows like the News Hour with Jim Lehrer, NC Now, and Frontline are now more important than ever - certainly not less.
Despite years of siege by politicians who seem to prefer the tractibility and journalistic abdication prevalent on Britney-obsessed cable news outlets - and make no mistake, their issue with PBS is the news - PBS television remains one of the only places to get trustworthy news on television.
As McGrath points out in his article (the title is sharper than the content of the piece itself), the answer to whatever woes PBS television may be facing is more public funding, not less. It seems miraculous to me that PBS can, on pennies, continue to do what Big Corporate Media seems unable to do with all it's billions of dollars. In truth, perhaps the absence of billions is the secret of PBS' success. But while we wait for more public funding for PBS television, that miracle has an earthly foundation.
-
Yahoo and Microsoft
Microsoft lodges unsolicited bid to purchase Yahoo. Here's my perspective as a person first and as an interactive developer second.
Yikes! OK, well I don't search with Yahoo anyway, so...
But see, I trust del.icio.us with my bookmarks, I trust Flickr with my pictures, I would trust Yahoo as an OpenID provider, and I've included Yahoo-written JavaScript code (YUI) in my work. I'm not so sure I trust Microsoft with those things.
-
CMS Complexity
This is one of those weird ideas that, for some reason, is really really easy to understand, seems really intuitive, and yet is realy hard to articulate without a graph.
Nevertheless, no truer memes were OmniGraffled:
-
In Memoriam: Dev2
DEV2: 1999 - 2008
Dev2 passed away this morning. Developers were unable to revive the nine-year-old former desktop computer after a routine reboot, which was precipitated by a planned move from the dynamic media cave to the server room.
Cause of death has been reported as, "catastrophic hard-drive failure", although it's unclear whether a full autopsy will be performed.
Although sudden hard-drive failure is not uncommon in computers of dev2's advanced age, authorities have named Broadcast Producer Anson Burtch - dev2's long-time roommate - as a "person of interest" in the incident.
The computer that eventually became known and loved simply as "dev2" came to Capstrat (then Capital Strategies) in 1999 as a powerful cutting-edge desktop computer running Windows98, and served with distinction until it was replaced a few years later. In 2002, dev2 got a new operating system (WindowsXP) and a new lease on it's career when it became the first desktop machine for a bright new Capstrat employee named Donna Jackson. By 2004, however, dev2 was quickly approaching obsolescence, and was relegated to the role of "intern desktop".
The aging computer had a close scrape in 2005, when it was selected for retirement. But just as it was to be hauled off to be recycled, it was rescued by Capstrat developer Paul Smith, who brought the machine back into active service with a new look (Linux!), and a new name, "dev2".
Between 2005 and 2008, dev2 was an integral part of the growing Interactive team, and served as staging point and launch pad for some of the team's biggest successes. With the recent introduction of newer processes and technologies, however, dev2's role has steadily declined.
Dev2 has already outlived most of it's peripherals, but is survived by many devoted users.
-
Corporate Blogging: A Compelling How-Not-To
Last week on their Internet Explorer blog, Microsoft celebrated the first anniversary of Internet Explorer 7's release by putting out a post touting IE 7's rapid uptake and tightened security.
Predictably, when this hit the blogwaves some experts jumped in to question a few rather dubious claims in the post. But the real news happened a few screens down in the comments section, where a deluge of scorn and frustration was heaped on the Internet Explorer team by the general public - the regular people who use and build the Web.
Microsoft is widely regarded as being pretty good at advertising and marketing it's products, but they've occasionally been conspicuously unable to perceive irony in their messages. Microsoft proclaimed they were fighting for their "Freedom to Innovate" in response to the U.S. Department of Justice's anti-trust action a few years back... action launched of course because Microsoft's monopolistic practices were squishing innovation . But it's one thing to ignore what your customers are asking for, then brazenly lead your marketing with, "We Heard You". It's quite another to bring that kind of thinking over to your corporate blog where unhappy customers are free to call you out.
Why were users upset? Well, consider that in the time since IE 7 was released...
Firefox went 2.0, and released beta versions of 3.0. Scores of extensions - a la carte features Firefox users add in to customize their browsing experience - have been improved or newly released this year.
Safari released 3.0 Beta, including a new version for Windows that feels lighter, faster and smarter than IE 7.
The strangely overlooked Flock released a 1.0 version. While IE 7 finally adds the same level of RSS support other browsers have had for years, Flock gets social media right, and is a glimpse of what IE might look like three versions from now.
Opera has committed support for next-generation technologies like HTML 5, SVG and future versions of JavaScript, while IE is still struggling to fix buggy, incomplete support for decade-old standards.
...And for the people who either want to or have to use IE, watching Microsoft let a year go by with no new improvements highlights lessons un-learned - not something to celebrate.
A special variety of animosity came from Web designers and developers who can't ignore IE because of it's broad market share, but are growing weary making Web pages for 2008 that have to work in browsers from 2001 (IE 6), and are frustrated with lack of progress in IE 7. Microsoft realizes it needs these people - what could MS have been thinking when they provided the time, place and catalyst to turn them into an angry mob? They might as well have handed out the pitchforks and torches!You can learn from your customers with your corporate blog. When it's time for a mea culpa, your corporate blog might not be a bad place to put it out there (hint, hint). Your corporate blog can be a very powerful weapon in your communications arsenal, but as with any weapon, it's never a good idea to point it at your own foot.
All Articles