Laptop Web Design

Client projects and tech blog posts about Laptop

Web 2.0 tools have changed the boundary lines between techies and program staff in many nonprofits over the past few years. At least, they should have, though I know of various organizations that haven't made the conceptual leap to the new roles.

OLD SCHOOL: Webmaster

Let me explain by talking about my own changing work role. Even a few years ago, I was a paid staff webmaster. You could divide my work into two large categories. The first was techie: I managed server accounts, set up required databases, designed sites. I got into the HTML code, the PHP, the Javascript, CSS, etc.

The other was content: when program-oriented staff had new material they wanted on the website they would email it to me or walk it over. I would put in my work queue, where it might sit for weeks if it wasn't an organizational priority. When it came time to add the material I would boot up Dreamweaver, a relatively expensive program that was only accessible from my laptop and I would put the material onto the website. Needless to say, with a process like this some parts of the website never got very much attention.

At some point I start sneaking in a content management system for frequently-changed pages. This seemed very hackish and not good at first but over time I realized it greatly speeded up my turn-around time for basic text content. But the organizations I worked for still relied on the old model, where staff give the webmaster content to put up.

NEW SCHOOL: Web Developer

Nowadays I'm a web developer, a freelancer with an ever changing list of clients. I typically spend about a month putting together a site based on a content management (like this) or automatic feed system (like I did for Philadelphia's William Penn Charter School). I do a certain amount of training and while I might add a little content for testing purposes, I step back at the end of the process to let the client put the material up themselves. I'm available for questions but I'm surprised about how rarely I'm called.

Here's two examples. Steadyfootsteps is a blog by an American physical therapist in Vietnam. When we started, she didn't even have a digital camera! I gave her advice on cameras, started her on a Flickr account, set up a fairly generic Movable Type blog with some custom design elements and answered all the questions she had along the way. She went to town. She's put tons of pictures and embedded Youtube videos right in posts. Here's a non-techie who has contributed a lot to the web's content!

Penn Charter is a school that was already on Flickr and Youtube but wanted to display the content on their website in an attractive way. I pulled together all the magic of feeds and javascripts to have a media page that showcases the newest material.

They're very different sites, but in neither instance does the client contact me to add content. They rely on easy-to-use Web 2.0 services: no specialized HTML knowledge required.

NEW TOOLS, OLD MODEL

I got an email not so long ago from an old boss who manages a monthly magazine. Her site has been radically rebuilt over the years. Dreamweaver is out and content management is in. They use Drupal, which my friend Thomas T. of the Philadelphia Cultural Alliance tells me won the recent popularity contest among nonprofit techies. This is great, a definite step forward, but what confused me is that my old boss was asking me whether I would be interested in returning to my old job (the successor who oversaw the Drupal upgrade is leaving).

They still have a webmaster? They still want to funnel website material through a single person? Every staffperson there is adept at computers. If a physical therapist can figure out Flickr and Movable Type and Youtube, why can't professional print designers and editors?

My hourly rate ranges from two to five times what she'd be likely to pay, so I turned her down. But I did ask why she wanted a webmaster. Now that they're on Drupal it seems to me that they'd be better off switching from the webmaster to the web developer staffing model: hire me as a freelance consultant to do troubleshooting, staff training and the occassional special project but have the regular fulltime staff do the bulk of the content management. I'd think you'd end up with a site that's more lively and updated and that the cost would about the same, despite my higher hourly rates.

I've heard enough stories of places where secretaries have come out of the shadows to embrace content management and have helped transform websites. I'm the son of a former secretary so I know that they're often the smartest employees at any firm (if you walk into an office looking for the expert on advanced Excel features you'll surely find them sitting right there behind the receptionist desk).


FINALLY: WHAT'S UP WITH DRUPAL?

I'm trying to join the bandwagon and use Drupal for a upcoming site that will have about a dozen editors. But there's no built-in WYSIWYG editor, no little formatting icons. Sure, I myself could easily hand-code the HTML and make it look nice. But I don't want to do that. And it's unrealistic to think I'm going to teach a dozen overworked secretaries how to write in HTML. The interface needs to work more or less like Microsoft Word (as it does in Movable Type, CushyCMS, Google Docs, etc.)

Most Drupal sites I see seems from the outside like they're still old school: staff webmaster through whom most content funnels. Is this right? Because if so, this is really just an institutionalization of the content hack I did six years ago. Can anyone point me to lively, active Drupal sites whose content is being directly added by non-techie office staff? If so, how is it set up?
Categories: Drupal , Practical 2.0 , Web Design
Tags: Css, Dreamweaver, Drupal, Flickr, Javascript, Movable Type, Penn Charter, Philadelphia, Php, School, Web 2.0, Web Developer, Youtube | Edit

Last weekend I found myself with the scenario no solo web designer wants to be faced with: a dead laptop. It was eighteen months old and while it was from Hewlett Packard, a reputable company, it's always had problems over overheating. Like a lot of modern laptop makers, HP tried to pack as much processor power as they could into a sleek design that would turn eyes on the store shelf. They actually do offer some free repairs for a list of half a dozen maladies caused by overheating but not for my particular symptoms. When I have a free afternoon, a big pot of coffee and lots of music queued up I'll give them a call and see if I can talk them into fixing it.

Once upon a time having a suddenly dead computer in the middle of a bunch of big projects would have been disaster. But over the last few years I've been putting more and more of my data "in the cloud," that is: with software services that store it for me.

Email in the Cloud

I used to be a die-hard Thunderbird fan. This is Firefox's cousin, a great email client. I would take such great care transfering years of emails every time I switched machines and I spent hours building huge nested list of folders to organize archived messages. About a year ago Thunderbird ate about three months of recent messages, some quite crucial. At that time I started using Google's Gmail as backup. I set Gmail to pick up mail on my POP server and leave it there without deleting it. I set Thunderbird to leave it there for week. The result was that both messages would be picked up by both services.

After becoming familiar with Gmail I started using it more and more. I love that it doesn't have folders: you simple put all emails into a single "Archive" and let Google's search function find them when you need them.You can set up filters, which act as saved searches, and I have these set up for active clients.

Why I'm happy now: I can log into Gmail from any machine anywhere. No recent emails are lost on my old machine.

Project Management in the Cloud

I use the fabulous Remember the Milk (RTM) to keep track of projects and critical to-do items. Like Gmail I can access it from any computer. While messing around setting up backup computers has set me back about ten days, I still know what I need to do and when I need to do it. I can review it and give clients renewed timelines.

An additional advantage to using Remember the Milk and Gmail together is the ability to link to emails. Every email in Gmail gets its own URL and every saved "filter" search gets its own URL. If there's an email I want to act on in two weeks, I set up a Remember the Mail task. Each task has a optional field for URLs so I put the the email's Gmail URL in there and archive the email so I don't have to think about it (part of the Getting Things Done strategy). Two weeks later RTM tells me it's time to act on that email and I follow the link directly there, do whatever action I need to do and mark it complete in RTM.

Project Notes in the Cloud

I long ago started keeping notes for individual projects in the most excellent Backpack service. You can store notes, emails, pictures and just about anything in Backpack and have it available from any computer. You can easily share notes with others, a feature I frequently use to create client cheatsheets for using the sites I've built. Now that I use Gmail and it's URL feature, I put a link to the client's Gmail history right on top of each page. Very cool!

Another life saver is that I splurge for the upgraded account that gives me secure server access and I keep my password lists in Backpack. There's a slight security risk but it's probably smaller than keeping it on a laptop that could be swiped out of my bag. And right now I can log into all of my services from a new machine.

Keeping the Money Flowing from Clouds

The latest Web 2.0 love of my life is Freshbooks, a service that keeps track of your clients, your hours and puts together great invoices you can mail to them. I'm so much more professional because of them (no more hand written invoices in Word!) and when it's billing time I can quickly see how many unbilled hours I've worked on each project and bang!-bang!-band! send the invoices right out. Because the data is online, I was able to bill a client despite the dead computer, providing my exact hours, a detailed list of what I had done, etc.

Others

Calendar: I always go back and forth between loving Google Calendar and the calendar built into Backpack. Because I can never make up my mind I've used ICal feeds to cross-link them so they're both synced to one another. I can now use whichever is most convenient (or whichever I'm more in the mood to use!) to add and review entries.

Photos: Most of the photos I've taken over the past four years are still sitting on my dead laptop waiting for me to find a way to get them off of the harddrive. As tragic as it would be to loose them, 903 of my favorite photos are stored on my Flickr account. And because I emailed most of them to Flickr via Gmail most of those are also stored on Gmail. I will do everything I can to get those lost photos but the worst case scenario is that I will be stuck with "only" those 900.

Your Examples?

I'd love to hear how others are using "the cloud" as real-time backup.

Categories: Practical 2.0 , Windows to Mac
Tags: Calendar, Flickr, Freshbooks, Gmail, Hp, Laptop, Remember The Milk | Edit

Via 37Signal's Signals vs. Noise blog I came across a fascinating post written by Brian Fling of Blue last year on pricing a project. I'd like to talk about it and to explain my own philosophy. First a extended quote from Brian:

I find it funny... in a sad sort of way, that we often start out our partnership with bluffing, no one saying what they are really thinking... how much they are willing to pay and how much it should cost... Though every book I've read on the topic of pricing says to never ever ballpark, I have a tendency to do so. If they can't disclose the budget I typically try to start throwing a few numbers from previous projects to help gauge the scope of what we are talking about, call it a good faith effort to start the discussion... While this is very awkward part of the discussion it is almost always followed by candor. It's as if once someone starts telling the truth, it opens a door that can't be closed.

I completely agree that candor is the only way to work with clients. Maybe it's the Quaker influence: we reportedly pioneered fixed pricing back when everyone haggled, with the philosophy that charging true costs were the only honest way of doing business. My official rates and contact page includes my list of "typical costs" -- essentially these are the "ballpark estimates" that Brian talks about.

When I put together estimates I base it on my best-guess informed estimates. I start by tabulating the client's requested features and determining how I'll achieve them. I then estimate how long it will take me to implement each feature and use that to determine a first-guess for project cost. I then compare it to past projects, to make sure I'm being realistic. I know myself well enough to know I always want to underestimate costs--I usually like the project and want to make it affordable to clients!--so I do force myself a reality check that usually ends up adding a few hours to the estimate.

When I put together my official estimate I try to guess where potential bottlenecks might happen. Sometimes these are technical issues and something they're more social. For example, a client might be very particular about the design and the back-and-forth can take longer than expected. If I think anything like this might happen I mention it in the estimate. Sometimes as we work through the details of a feature I'll learn that the client wants some enhancement that we hadn't talked about previously and which I didn't factor into the estimate.

When I do see a particular part of the work taking longer than expected I flag it with the client. I try to keep them informed that this will add to total costs. In many cases, clients have been happy to go with the extra work: I simply want to make sure that we both are aware that the estimate is changing before the work happens.

I charge by the hour rather than on a per-project basis since I find it to be a much more open business model. Brian Fling's post agrees:

The problem [with per-project billing is that] one way or another somebody loses, either the client pays too much, meaning paying more than it's market value, or the vendor eats into their profit... One benefits to hourly billing is the client is responsible for increases of scope, protecting the vendor and the customer. If the project is completed early the client pays less, protecting the client. This puts the onus on both parties to communicate regularly and work more effectively.

I have very little overhead: a home office, laptop and DSL. This means my rates are very competitive (one client described it as "less than plumbers and electricians charge, more than the kid who mows the lawn"). Being very careful with estimates mean that I often communicate a lot with clients before I "start the clock." I've often worked with them a few hours before the estimate is in and we're moving forward and of course some of this un-billed work doesn't result in a job.

Putting together fabulous websites is fun work. It's very much a back-and-forth process with clients, and it's often impossible to know just what the site will look like and just how it will work until the site actually launches. Half of my clientele have never had websites before, making the work even more interesting! It's my professional responsibility to make sure I work with clients to foresee costs, dream big, but most of all to be open and honest about costs as the process unfolds.

Categories: MartinKelley.com , Practical 2.0
Tags: Blog, Budget, Good Faith, Partnership, Philosophy | Edit

Search

As Seen In

EBook

Shortcut cover
Web 2.0 Mash-Ups & Niche Aggregators (O'Reilly Media, 2008, $9.95): Order here.

Social Networks

Other Sites

Archives