Archive

Archive for September, 2010

The 20 Albums List Exercise (Via Facebook)

September 10th, 2010 No comments

My friend Sherm posted his top 20 list under the auspices of the exercise described below to Facebook and tagged me to respond. (No, I won’t include his. That’s his decision to make)

Normally these viral “post your yadda yadda” things drive me bat#$%^ but, typical of Sherm, he posited an exercise interesting enough that I responded. It’s important that it’s not the “Desert Island” list because that one just doesn’t work for me. Though, obviously, there’d be huge overlap from this list to whatever too-damned-short-a-list I had to come up with to take to the proverbial desert island.

———————————————————————————————–

– Begin Cross Post – (Numbers changed to bullets because it’s supposed to be an unordered list)

(Sorry folks, I don’t do the ‘tag your friends’ thing. Sherm and somebody else asked me to do this and the exercise struck me interesting. This took 8 minutes. Then I decided to remove some duplicates from the same artist. Another 10 minutes. I’d probably pick 80% of these if forced to redo the exercise again. Which would drop and which would add, I can’t predict. In redoing, I’d guess 80% would stay again and probably not the same 80%.)

The rules: Don’t take too long to think about it.  List 20 albums you’ve heard that will always stick with you.  20 albums that “changed your life.”  List the first 20 that come to mind in 20 minutes.  Tag 20 friends, including me, because I am interested in seeing what my friends choose.  To do this, go to the Notes heading on the left column of the Home page, paste the rules in a new note, list your 20 picks, and tag 20 friends.

In no particular order:

  • The Dark – Artsy Annoyance/Boring Contrivance (Actually an untitled tape that has a storied history with other Dark on it as well)
  • Peter Garbriel – 3
  • Nine Inch Nails – Pretty Hate Machine
  • Robert Palmer – Clues
  • Kraftwerk – Computer World
  • The Silencers – A Letter From St. Paul
  • Pink Floyd – Dark Side of the Moon
  • Led Zeppelin – IV
  • The Beatles – Rubber Soul
  • The Clash – Sandinista!
  • Machines of Loving Grace – Concentration
  • David Bowie – Ziggy Stardust
  • The Crystal Method – Vegas
  • Big Catholic Guilt – Possession
  • John Lennon – Shaved Fish
  • Eurythmics – Sweet Dreams (Are Made of This)
  • Gary Numan – The Pleasure Principle
  • O- Positive - Only Breathing/Cloud Factory (It’s one Disc so ;-P~
  • Simon and Garfunkel – Bridge over Troubled Water
  • Oingo Boingo – Good For Your Soul

Those of you who were ON some of these records and are reading this, don’t let it go to your heads…. and don’t doubt for a second doubt that, standing apart from my knowing you, the music rates.

——————————————————————————————————

– End Cross Post –

Post to Twitter Post to Facebook

Categories: Inspiration, Personal Tags:

URL shorteners, the problems, the value, a solution?

September 10th, 2010 No comments

UPDATE: Gruber Explains his method and identifies a pitfall: “What I didn’t foresee was the tremendous amount of software out there that does not properly parse non-ASCII characters in URLs, particularly IDN domain names.” In retrospect, I should have been more curious and tested his cagey domain name branding. It worked for me so I just assumed. I would have tested it had I implemented it but as a user, it worked, so what did I care? Anyway, Gruber explains more here: http://daringfireball.net/2010/09/starstruck

****UPDATE AGAIN 10.6.10**** http://benmetcalfe.com/blog/2010/10/the-ly-domain-space-to-be-considered-unsafe/ Worth a read but I distill it thus:

Don’t rely on a business relationship where you don’t have the support of a legal system you can participate in. Obviously, we live in a global economy so what matters is the word ‘rely’. Participation != reliance.

————————————————————————————

URL shorteners are extremely common tools used to make links shorter, more able to fit within artificially constrained text fields, and, in some cases, more human-readable. They can also have some other, arguably indirect, benefits in some cases including click-through tracking.

One major potential problem of course is link rot which can be a pretty staggering problem if your chosen provider completely folds up shop.

One common inducement to shorten URL’s is Twitter and the 140 character count limit on the ‘microblogging‘ site’s posts. While an argument can be made that imposing a 140 character limit enforces a tone, there’s no logical reason that Twitter couldn’t accept URLs shortened by the most basic method, an HTML embedded link:an HREF with your own descriptive text and probably claims disallowing this is a security advantage. Such a claim would ring hollow since URL shorteners themselves obfuscate the real target of a link in a way that’s actually potentially worse.

By now, some of the problems with these tools should be obvious:

  • The provider of the translation from short to long can fold up shop instantly rotting all your links.
  • The user can’t hover over the link and look in the status bar of their browser to see what the actual target is.
  • Users seeing different shortened versions of the same link aren’t given the visual cue of ‘followed’ color change in their browser for links they have already seen.
  • They do nothing to encourage site maintainers to strive for more accessible and better indexable and human-readable URL schemes.
  • They insert yet another intermediary able to track users browsing habits.
  • They are, in many cases, unnecessary layers of complexity.
  • They can pose problems for content publishers wanting to be methodical about managing their own link rot. (Do you try to ‘fix’ expired shortened URLs? Can you when you don’t control them?)
  • They have SEO implications.
  • If you need to shorten URL’s on your intranet for, for example, easier tracking, you wouldn’t want to expose, or possibly couldn’t expose the URLs to a cloud based provider for security reasons.

So, let’s for the moment, set aside all the good reasons we should be hammering on Facebook, Twitter and others to exclude the characters used for posting HREFs and the links themselves from the character counts and accept, albeit grudgingly, that there could be good reasons to implement URL shortening mechanisms. How should we do it?

We should be hosting our own URL shortening mechanisms on our own sites.

John Gruber of Daring Fireball has this down to a science. If you follow Daring Fireball on Twitter you will notice every link he posts looks like this: http://✪df.ws/g4n These links are URLs he’s shortened on a server hosted in the .ws domain and they hit short tease pages on daringfireball.net in a directory called /linked. His little tease pages don’t always do the best job of telling the user what they’ll get with a click but this is part of Gruber’s editorial voice and is clearly done deliberately. The mechanics of the user experience, however, are extremely solid:

  1. Shortened URL appears in Twitter feed. (or other microblogging site or method)
  2. Shortened URL is uniquely branded as a Daring Fireball Link (issues with scaling his branding method notwithstanding)
  3. User chooses to follow the link based on other content in the ‘tweet’
  4. User is presented with a ‘tease page’ on Daring Fireball
  5. User can, unless Gruber is being cute on his tease page, make an informed choice about whether to fully follow the link.
  6. Gruber can track the response to the tweet, and, if he wanted to be a right bastard about it, outgoing clicks from his tease page could be sent through a click-through sever script.
  7. Gruber can scan the contents of his Linked directory to manage link rot on his own site.
  8. If he’s methodical about keeping track of which URLs he posts (and I bet he is), basic log analysis of referrers on requests to files in his /linked directory will tell him where he is picking up traffic. Some more complicated analytics could tell him some things about where people had propagated his links.

I happen to usually agree with Gruber, always enjoy reading his stuff and, frankly, take a certain vicarious pleasure in his occasional willingness to be a bit brash. I happen, also, to usually like the results, when he gets cute on his tease pages but, no matter what you think of Gruber and Daring Fireball, the method he uses is the basis of a really solid approach to managing a site and integration of that site with Twitter, Facebook and other mechanisms of ‘syndication’. It puts him back into a position where he is editorially engaging with his users on his own site after he used the visibility he got himself elsewhere.

It’s pretty slick and, done methodically with a transparent editorial policy, this approach could do a lot for fixing what’s wrong with the current willy nilly grabs for presence on Twitter, Facebook etc. by content companies who are now, almost always, just diluting their own brands. I happen to bristle a bit that Gruber’s hosting his URL shortener in a .ws domain (The country domain for Western Somoa and I think it’s because it was an easy way for him to register a domain branded with his UTF-8: E2 9C AA “✪” in his very short ‘✪df’ domain name but I don’t actually know why he chose .ws.) but that’s just my old school leanings when it comes to top level domains.

So, the solution, and maybe Gruber’s already built it, or maybe it’s one of these: 10 Free Scripts to Create Your Own Url Shortening Service is to host your own URL shortening mechanism on your own site. You can implement your shortened URL’s using the “The Full Gruber” and, with some good practices of your own, (mostly) mitigate every last one of the problems cited above except maybe some of the SEO issues.  Those  you could work around with other architecture and editorial choices and which would be offset by traffic to and the well organized placement of your tease pages.

No, of course, the Gruberization of link shortening practice isn’t nearly as clean, consistent and user-friendly as actual links direct to content with meaningful descriptions but, since we’ve let Twitter, Facebook etc. co-opt our control of our own presence on the net, for now, this is a more than decent workaround.

Now, as usual, the comments I get will say “But Jon, it’s not easy enough or convenient” and, for most people, yeah that’s probably true. Hell, I am expecting to bleed from the forehead trying to work out how to automate it or will just end up stupidly manually editing my .htaccess file for every link and maintaining some static structured reference file by hand or find somebody to help me set it up here because this is hardly turn-key. The point is, what should a smart company or organization do to manage how they maintain the best most direct connection to their audience rather than, usually self destructively, try to exploit Twitter, Facebook etc. to attract an audience?

Ok, so, who wants to work with me for no money to help me set all this up for my sites and publish a how-to and/or open source package that we can convince DreamHost to make a ‘One Click Install’?

Anybody feeling that charitable? 😉

– Jon

Post to Twitter Post to Facebook

The perils of ‘easy’ tools – Basecamp

September 10th, 2010 Comments off

When you use a commercial fee-for-service provider, you will typically get service in direct proportion to your cost. When you use a free one, you get what you pay for and boy do you pay.

Now, those costs you need to assess are not just the objective costs of the service in dollars. It’s subjective cost relative to the value and importance of a service as a means of achieving a goal in the context of your other costs. You don’t hire the kid down the block to mow Fenway Park after school. You don’t hire I.M. Pei to design the toolshed you’re going to make with stuff you pick up at Home Depot next weekend.

One personal favorite example to pick on is: Basecamp and I pick on them in the context of using Basecamp as a project management tool for running web projects. For all I know, Basecamp is perfect to manage your Badger husbandry operation. I just don’t know.

Semi-Disclaimer: I have participated in projects that have used Basecamp but have never led one using it. My participation spanned the “asses the progress when called in to be Winston Wolf (Link is NSFW) and fix a Charlie Fox (also NSFW)” to just having a looksee and contributing one deliverable of many.

Now, I will admit to picking on Basecamp in part because I have had it pitched to me very badly several times. If you want to convince me a tool is right for a job, it’s important to be ready to make a cogent case for it.

The pitches I’ve gotten  have spanned these two extremes:

A very smart, content sensitive producer and overall exceptionally capable but somewhat technically naive person who was managing a project with many different stakeholders who’d been backed into Basecamp before it could really be thought through.

The other pitch from somebody who project managed by front-loading with brainstorms and went off the rails when it came to executing on time and on budget. The sort who whiled away his time in constant exploration of new tools to manage a project as a way to avoid actually taking responsibility for managing it. You know the type. One of those guys the technical staff secretly works around to make things suck less entirely out of their own dedication to the ineffable geek holy grail of ‘elegance’. The sort the team complain about but can’t go on record with complaint because the ‘upstart young innovator’ has the bosses ear? The one who you have to un-teach his bad habits from new people? Not the guy who can be a hard-case but the guy who just checks out. The one who’s never there at 1AM in a crisis, or, if he is there at the crunch, doesn’t know enough to shut up and go get pizza. The one who books a speaking engagement to overlap your launch date. You know THAT guy.

Since the last time somebody tried to be ‘that guy’ to me about Basecamp, it’s been improved some. http://37signals.com/security and http://basecamphq.com/help/general#exporting_data are both better now  but still, you are parking what could be client-sensitive data on somebody else’s server(s). You’re not able to run your own Basecamp instance to see and manipulate that exported XML.

You’re still left with (I hope) having to decide what is and isn’t appropriate to put into Basecamp from a legal and confidentiality perspective given that you don’t really control the environment and you’d be left rolling your own tools to get use from whatever you got in the XML you exported if you chose to leave Basecamp or if you want to review the specifics of the project a year from now when Basecamp has changed or might not even exist.  You can’t keep an archive of the configuration environment and the software to review the data later. Oh, and you still can’t download all your files at once and the built in version control mechanisms are scanty at best and, arguably, broken. Appending a letter to a file name is not version control unto itself.

In both cases pitched above the concerns were trumped by the “but it’s easy” argument. In the case of the first guy, the project was ultimately, mostly, successful. In the second case, Basecamp was hardly to blame for the FUBAR’d results. Easy’s good. I love easy. Easy usually comes at a price and, for some members of a team, easy is relative.

So? What’s wrong with Basecamp?

If you have a project with sensitive data, or one with signifiant business stakes, how smart is it to put your core communications in the hands of a company that, at maximum, is charging you $150 a month? No single customer is worth enough to them to do more than say if you have a problem “You can also submit a support request via email. We’ll get back to you within a few hours.” No phone support.

How smart is it to build a workflow, a whole communications infrastructure, around a toolset somebody else can decide to modify, to ‘improve’, in the middle of your project in a way that may undo some quirk you’ve come to rely on?

In the case of software project management, and a website, almost no matter how small, is a software project, there are so many aspects of project management that are outside the scope of what Basecamp offers. Issue tracking, documentation, time and billing, client approvals, rights management.. and so on.. and so on…  Now there are add-on products and some set up specifically to integrate with Basecamp. But 37signals themselves have this to say about that:

"Note: These apps and integrations are not endorsed or tested by 37signals. 37signals does not assume responsibility or liability for any issues caused by the use of third party products."

So, if you decide to put the core of your project’s operation in the hands of a provider who will promise to respond to you ‘in a few hours’ is that fast enough for you?  Is it wise to rely on a provider who offers the tool you’ll lock all the central planning information into but insists they host the application, you have to ask yourself;  Is ‘less easy’ perhaps a better idea?

Remember, whether outsourced or in-house, you’ll need to host your site, a staging/dev server, and probably a project wiki and file services (See below, for why you’d likely do at least some file hosting in-house and not only via Basecamp) and, of course, the applications your site needs on a server (Apache, MySQL, Joomla, whatever.)

Now, the host I use has, at least, 24/7 live chat and yeah, they’re cheap but also not nearly as ‘turn-key’ for use as a host for Project Management tools as Basecamp is (heck, they’re not as easy to use for anything as Basecamp is they provide services to at least nominally technical people). A hostisng provider like DreamHost don’t claim to be doing more than foundational I.T. services. There are lots of tools they do easily host that are useful for project management and, with a technical staff, you can host whatever you like (if it runs on Linux or BSD) if you pay more for dedicated hosting.   This is the host you can migrate everything from in a day and come right back up as if nothing went wrong when they tick you off.  37signals is the other host you have to pay  to host the swoopy project management system. You could choose hosting one of these (or something else) at the hosting provider you already have to pay for anyway or you can go with Basecamp .

(When I need to host a project where there’s real money at stake? I’ve used these guys:http://www.rackspace.com/index.php I can tell you from direct personal experience, there’s a human being who will bust their buts an 800 number away 24/7/365.)

Basecamp and hosting and configuring your other tools are  costs in addition to the omphaloskeptical (thanks for the word B.D.) ruminations your Project Manager will go through setting up your instance of Basecamp. That’s in addition to the money (time)  you’ll spend with the technical and social integration you’ll need to do to include Basecamp in the suite of tools you’ll use. So, cost is already becoming a subjective and complicated value.

Managing a software project demands dealing with people of a variety of personalities, disciplines and expertise. The tools they’ll gravitate to are going to differ depending on who they are and, in some cases, the tools are so tuned to their particular field you would be hamstringing them if you deprived them of those tools.

Some examples:

  • A graphic designer working on a web project is going to do most of their work an image editor (or several). Depending on your connection, the practicalities of uploading (and downloading to review) and managing versions of files that can be multi-hundred-megabytes in size when you have to up and download to a server not on your LAN can get ugly. Fast.  Even for a project running hosting those files on Basecamp you’ve still got to have to track progress in these files in parallel with descriptive information about their status entered in Basecamp. Meanwhile, you’re running a workflow on a file server (even if that File server is Basecamp because you have connectivity to do it) to track who’s working on what, where it is  and, ideally, with self documenting metadata in the multi-layered files themselves. You’re already ‘outside of Basecamp’ for a significant aspect of communication between team members and you should be.
  • Developers? They like version control. To say they like version control is the understatement of the century. The good ones are addicted to it like crack. There are LOTS of challenges in how one implements version control for a web site since the end product, as a whole, often doesn’t have a ‘build’ associated with it. Individual components don’t have milestones that necessarily track the project’s milestones as a whole on any level a general Project Manager would likely track them. Basecamp is not SVN. You’re going to need some mechanism of version control for the developers. Maybe it’s come sort of CVS-like thing on a dev server or even their own desktop(s). Maybe it’s a combination of landmark versions of the whole site for project milestones on a staging server and multiple version control repositories for the different components different members of the team are working on.  You’re going to need to have this process defined and, to at least some extent, internally documented. Again, that part happens outside of Basecamp.

(One day we can talk about a case where I hamstrung coders by depriving them of good version control. They were much less hamstrung or deprived than they thought but my mistakes there are a story for another day.)

  • Next, we have legal. Throughout any web project of substantial size, your lawyers or your company’s legal department will be reviewing rights agreements, contract terms, engagements with clients around the dreaded payment points and conditions of approval. You may have sample data for your project you need to protect on your own or your client/partner’s LAN for legal reasons. There are all sorts of scenarios where the access controls for aspects of a project necessitate not hosting things, or tracking them, at Basecamp. So, again, you’re running part of the project outside of Basecamp.
  • So you have video? The kinds of things you need to track to produce video from the high end where you have studio, grip truck, camera, audio, talent and other staff to manage to the low end where you just have a few tens of gigabytes of raw footage from DV to cut together are distinct from how you’d set up Basecamp for the rest of the web project. The ‘lingua franca’ of managing video production, while, in this example, part of the web project, is not the same as that for managing, for example, MySQL and PHP development. All that happens outside of Basecamp. (Ok, yeah, you could run a separate project in Basecamp to manage the video production but, in that case, for many projects, the reality is that most of the team won’t be accustomed to working virtually via collaboration software and are, often, in and out for the day. The people you have to manage on shoot day(s)? The freelancers? Those are gonna be hearing from you while you hold your clipboard. So, umm, why bother doing it online? Collaboration in preparation? Sure, maybe. Fair point.  But, again, you’ll have duplicated tracking and meetings to work out the details. Meetings with people who won’t be participating in the collaborative Basecamp workflow unless you wanna cover them for more than their day rate.)
  • There can be writers, third party evaluators or auditors, executives above the ‘in the trenches’ team,that are reacting to and working off what they see on your staging, development/test and production servers. All things that, depending on your project would need to be tracked outside of Basecamp.

Now, all the examples I’ve cited mean the Project Manager would need to track the milestones, to-dos and deadlines and readiness of deliverable or incremental versions for elements you can’t natively watch and manage or effectively communicate necessary details about within Basecamp. You’re gonna be havin’ some meetings.

Some of you will immediately jump up and down and say “But that’s what Basecamp is FOR you blathering idiot!” but what’s lost in that instinctive reaction is the overhead involved. Not just for the Project Manager but for everyone else on the team.

For everyone else on the team, Basecamp is additive to their workload if they are to report both within the tools and workflows of their department/disciplines and to the central Basecamp tracking under the direction of the Project Manager.

Sure, you could have a super-heroine of a Project Manager gather it all and be the one doing the data entry in Basecamp.  She can take good notes at meetings, be a disciplined like a Shao-Lin monk about looking in on the Wiki, the Dev sever, the source repository, the uploads of roughcuts to the video server, the file server where the designers stash the graphics and be sure it’s all captured in Basecamp but then all she’s doing with her time is living her life as translator to Basecamp-ese.

  • Fine when you have a huge team.
  • Fine when you can afford a super-heroine of a Project Manager (if you can even find her even in this economy).
  • Fine when the people responsible for all the legs of the project are doing a good job maintaining their own documentation of their progress so well she can just look in and check and not call another meeting.
  • Fine when you have the infrastucture to give the: Designers a file server, the developers a version control server. The video editors disc (or time to export and encode) space for review cuts and so on.
  • Fine when, despite all this, somebody, other than the Project Manager herself, needs to have a thirty thousand foot view of the project’s timeline, deliverables and dependencies on a regular basis and you can afford to have that tracked, with the multiple layers of duplication described above.

(Oh, about that 30 thousand foot view you can get when you use Basecamp?  A lot of Project Managers think a Gantt chart is a good way to get a thirty thousand foot view of a project but:  “At this time we don’t have plans to add this sort of feature to Basecamp. Sorry about that.” )

What it comes down to is this, if your project is large enough to need the super-heroine Project Manager, you need a lot more resources than even a $150/month Basecamp subscription provides  You have to ask yourself, if she really wants Basecamp and not some other collection of tools and procedures she has honed to a razor edge successfully managing her projects then, perhaps, just perhaps, she’s that guy.

Now, the next obvious question is: “But Jon you bloviating bombastic bafoon! I have a team of 2 people and I am just making a little Flash game! Why can’t I use Basecamp?” Well, sure use Basecamp but then, if you spend a lot of time setting it up, maintaining the project and ensuring you get the most from that ‘oh so pretty’ user experience you might wanna ask yourself. “Am I that guy?”

All this said, I’m sure there are countless cases where Basecamp really does help highly capable people do a better and more convenient job managing their projects. I am not saying “Don’t use it.” I am not saying “It sucks”. I am just saying, don’t let the use of Basecamp let cause or encourage you to be “That Guy.

Oh, and here’s another reason I pick on them: http://37signals.com/svn/posts/1066-web-designers-should-do-their-own-htmlcss?139

And here is somebody else’s NSFW but solid rant on why that’s utterly inane: $%& 37signals and their bourgeois bull$%^

Post to Twitter Post to Facebook