But what happens when a client has nothing to submit — no photos, no taglines, no logos, no text, no identity? …Obviously a project can begin without all the materials, but it’s far from ideal. In the absence of photos and text, you can help the process along by quizzing the client about their industry, business philosophy or desired audience. In this sense, you’re getting a feel for “content” even without materials.

In response to it, I posted a comment about classic mistakes that clients make. I’m reposting my comment here:

If my client is empty-handed, unsure even of the idea of their site, then I feel the best option is to talk to them, to help them clarify their thoughts. Sometimes I feel like a therapist, listening as the client pours out their hopes and dreams and fears and worries.

We’ve acquired 3 new clients this summer. In all 3 cases, I was brought in at an extremely early phase, before the basic idea of the site was decided. I do not mind sitting in on brainstorming sessions. So long as the client can pay me for the time I spend at meetings, I enjoy helping them avoid mistakes.

For instance, one mistake is the behavior pattern I would describe as “too much brainstorming”. If I’m in meeting with the client for the 3rd time and the meeting is still a pure brainstorming session, I warn the client that they are at risk of wasting a lot of money on simply trying to figure out what they should do. I once saw a substantial fortune wasted on what turned out to be a 2 year long brainstorming session.

I’m sympathetic to the argument that the opposite is also true: it is crazy to risk a vast fortune on an idea that you have not thought about carefully, so a prolonged period of testing the permutations of an idea can certainly be justified if the project seems likely to be huge. So, as I said, I don’t mind sitting in on the brainstorming sessions, so long as the client can pay me. I feel especially helpful when the client suggests something that I know, from previous experience, is a terrible idea. Certain thought patterns are traps, they always fail, yet they are quite common among clients considering their first web project. Among those traps:

1.) If I (the client) build it they will come (also know as, “If I have a clever idea, I won’t need a marketing budget, because the site will get mentioned on TechCrunch/Newsweek/The New York Times”).

2.) Feature-itis: “If I add in all the good features from all the popular sites, then my site will be as popular as all those other sites combined.”

3.) I can/should be all things to all people.

4.) If one person offers a single piece of off-hand, poorly thought-out, casual feedback, we will immediately re-design the entire site to comply with their feedback. And then tomorrow, when someone else offers some casual, poorly thought-out feedback, we will do the same. And then the next day…

5.) Flash is more dazzling than anything that HTML can offer, therefore our whole site should be built in Flash.

6.) Things that move or blink grab my attention, therefore if everything on the page moves or blinks, we will have a truly attention getting site.

7.) Text is boring.

8.) Images are always better than text.

9.) I (the client) am over the age of 35/40/45/50 therefore people will think I’m out-of-date and too old to be starting a web business. I will prove my youthfulness by only using the most bleeding-edge technologies.

10.) Bleeding edge technologies are always more interesting than older technologies such as text.

11.) Users prefer cutting-edge technologies over older technologies such as text.

12.) The more creative/unusual the interface, the more interested people will be.

13.) If my site starts off with a narrow focus, then its prospects for growth will be limited. People will pigeon-hole it and I won’t be able to add new content channels later.

14.) I can spend my money at an unsustainable rate because 6 months from now my site will be bringing in a profit.

15.) I have a lot of money right now, therefore I am a genius web entrepreneur (the money may have come from inheritance, good luck selling a house at the peak of the housing boom, or perhaps thrift at a younger age - none of which confers the business skills needed to run a business, online or off).

I could go on. I’ve seen many mistakes, and I’ve seen a few successes, or, at least, glimpses of successes. When a client comes at me empty-handed, I talk to them until an idea takes shape and seems concrete enough that construction can begin.

I do think it is wise to try to get to something concrete as fast possible (as per 37Signals). It might be impossible to get the whole idea mapped out quickly, but sometimes small parts of it can be made solid. I think it is wise to have the graphic designer try to put visuals on anything that can be agreed upon as unlikely to change.

I also liked an earlier post that you (Darren) wrote, over at Sitepoint, about working toward a single mockup for the front page (rather than offering 3 different versions of the front page). I do think that getting the front page into a concrete form greatly helps getting the whole project solid.

Compiling your first script

This script takes a source PHP script called in.php, and outputs a compiled PHP script called out.php

<?php

$fp = fopen(”out.php”, “w”); // Create the destination PHP file (in this case called out.php)

bcompiler_write_header($fp); // Write a bcompiler header in the destination file

bcompiler_write_file($fp, “in.php”); // Compile the contents of the source file and place in destination file

bcompiler_write_footer($fp); // Write the bcompiler footer in the destination file

fclose($fp); // Close the destination file

?>

Often it is late at night, when there is neither a 12-step meeting to attend nor anyone awake to phone, that the craving for a drink is strongest.

And it is times like these when Ginger Bauler goes online to reach out to others recovering from addiction, finding solace in their tales of success and providing encouragement for those trying to break the shackles of dependency.

Bauler, who used to manage a research laboratory in Charlottesville, writes a blog about her struggles with alcoholism and her quest for sobriety on The Second Road — a new online support community for drug and alcohol addicts started by Charlottesville residents.

Writing about her battles enables Bauler to become “accountable” for her recovery, she says. And meeting and keeping in touch with those dealing with similar experiences gives her strength.

“I develop these relationships with total strangers, but with whom I’m completely connected because of this disease,” said Bauler, who has become a managing editor of the site.

The Second Road is the brainchild of local documentary filmmaker Melissa Shore, who partnered with Chip Ransler, owner of a digital publishing firm, to launch the site in November. By late May the social networking site had 225 members and more than 1,400 different people had visited it in a recent 10-day stretch.

Each member of The Second Road has his or her own profile page, similar to sites such as Facebook and MySpace, where they can post information and display customized features. The site also includes a series of blogs, chat groups, a “sharing wall” for inspirational quotes and testimonial videos from recovering addicts.

Shore, who grew up watching family members battle addictions, noticed that there was a gap in services for people in recovery and a need for round-the-clock services.

People in recovery do not always have access to meetings or counseling services, and some may have no one to turn to in times of crisis, Shore realized. That is especially true in rural communities, where social services either might not be readily available or are far away.

“There are hours of the day when you can’t or don’t feel comfortable reaching out for help,” Shore said. “The beauty of the Internet, of course, is that it’s 24-7.”

The site has won praise from many in the local mental health community as a vital tool to help round out recovery services.

“The concept is absolutely brilliant,” said Jeff Gould, administrator of the Charlottesville/Albemarle Drug Court. “This type of online recovery network is just perfect for people who can’t get to meetings.”

Beth Elliott, a retired social worker who advises the site’s creators, says that members are using The Second Road to implement the treatment plans they develop with counselors, through making lists and blogging about their successes and missteps.

Are we all doomed to go through this painful process when we are successful?

We seem to take it for granted that dealing with scalability is complex. When we start a new application it’s hard to know whether we’re ever going to be successful to the point where the investment in scalability is worth the effort. At this initial stage the important thing is time-to-market. We want to get our idea out there as quickly as possible. This is a reasonable desire as indeed most projects don’t take off.

Now imagine what would happen if dealing with scalability wasn’t that difficult. That would have change the entire decision making process, and would enable Twitter and many others to start with a scalable architecture from day one, avoiding this painful process.

So the question is what would is required to simplify building a scalable application to the point in which it is as simple as building it for a single machine?

From my experience, most challenges have already been faced by and dealt with others - so the first thing that I did was look at how others (not necessarily in the same industry) addressed this issue.

In this case, storage virtualization is a good example. At first, we used local disks. Local disks tend to get filled-up quite fast. It was very hard to deal with this problem as it required replacing the disk with a bigger one every time full capacity was reached. IT had to go through this process for every user and every application — very painful and costly. The solution came in the form of NAS and SAN, or network-attached storage. Instead of using a local disk, use a virtual disk that resides somewhere on the network. The user and the application don’t need to be aware of it, because they use a local disk driver that virtualizes the network devices to make them look as if they were just another local disk. The application scales but hasn’t changed as a result. We can add and remove devices as we wish with no changes to the application. Later on, if there is a more cost effective solution available, we can easily replace the devices.

We can apply the same concept of virtualization to the middleware stack — namely the data, the messaging and the processing — with the same degree of simplicity. The application interacts with a “proxy” that hides the details of how a message or update operation is routed, how fail-over is handled, how data is partitioned and so on.

With services such as Amazon EC2, and other cloud environments, this can be made even simpler, as we can have a pre-configured image and hardware ready for deployment. All we need to do is just deploy our business logic. (See an EC2 example here).

With today’s frameworks architectures, we don’t have to go through the same painful experience. We can build scalable architectures from the get-go. I would even argue that it takes less time to build applications with this approach than the traditional client-server approach.

I suppose Sam Ruby likes Erlang for these same reasons - automatic concurrency.

I do think that Shalom is under-estimating the degree to which emotions, self-esteem and uncertainty combine to ensure conservative choices that may be painful later on. His example of disk-virtualization is a fine representative - none of the start-ups I’ve worked with have choosen to use Amazon S3, even though they all might benefit from it later on, and it is relatively simple to use. But a lot of people starting a new venture will collect together people they like working with, and the entrepreneur who gets the project going will make use of the skills that his/her team already has, rather than asking them to learn a new skill, like amazon S3.

The incident last year started when Radical Behavior interviewed Alex Payne, who was one of the developers at Twitter. Alex said:

By various metrics Twitter is the biggest Rails site on the net right now. Running on Rails has forced us to deal with scaling issues - issues that any growing site eventually contends with - far sooner than I think we would on another framework.The common wisdom in the Rails community at this time is that scaling Rails is a matter of cost: just throw more CPUs at it. The problem is that more instances of Rails (running as part of a Mongrel cluster, in our case) means more requests to your database. At this point in time there’s no facility in Rails to talk to more than one database at a time. The solutions to this are caching the hell out of everything and setting up multiple read-only slave databases, neither of which are quick fixes to implement. So it’s not just cost, it’s time, and time is that much more precious when people can[’t] reach your site.None of these scaling approaches are as fun and easy as developing for Rails. All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both.It’s also worth mentioning that there shouldn’t be doubt in anybody’s mind at this point that Ruby itself is slow. It’s great that people are hard at work on faster implementations of the language, but right now, it’s tough. If you’re looking to deploy a big web application and you’re language-agnostic, realize that the same operation in Ruby will take less time in Python. All of us working on Twitter are big Ruby fans, but I think it’s worth being frank that this isn’t one of those relativistic language issues. Ruby is slow.

David Heinemeier Hansson, the inventor of Rails, had an extremely defensive response:

Rails makes the act of developing such a pleasant experience that when you need to follow the same scaling path as every other shared-nothing stack, the contrast can feel stark. And perhaps it’s a natural reaction to feel a need to blame something for that contrast, however natural it is.

[…]

Second, when you work with open source and you discover new requirements not met by the software, it’s your shining opportunity to give something back. Rather than just sit around idle waiting for some vendor to fix your problems, you get the unique chance of being a steward of your own destiny.

[…]

Once the stress of having to deal with that in the moment subsides, I’m convinced that the team will grow beyond the blame game, get their hands dirty as full participants in an open source community, and contribute back their advances to the framework.

Gluttonous had what was, by far, the best reaction to David’s post:

The conversation shifts from where bottlenecks come from when scaling Rails to “you’re saying it’s Rails’ fault, but it’s not”. This is where we start to slide down the slippery slope. It’s easy to argue about blame. David pulls out his “I’m not a vendor, I don’t owe you shit” speech, and says that because of the beauty of open source, Twitter is in charge of their own destiny.

He’s absolutely right. He’s also a big jerk about being right. David seems to imply that Twitter has been sitting on their hands, doing nothing, refusing to solve their own problems, and not contributing back to the community. This is false. It’s also completely beside the point.

Early in the discussion we started to imagine blame where it didn’t exist. Alex never says that Rails should support doing 11k requests a second. He simply said it doesn’t, which is something no one will dispute.

So, we’ve moved into rough territory, but someone goes and does something nice (Woo hoo!). Dr Nic writes a plugin to use multiple databases with Rails. Way cool. Really way cool. Awesome job Nic. This is the part of open source that I love, when people help each other just because it’s an interesting problem and they’re a nice person. Hugs and kittens all around.

DHH tosses down an ”I told you so”. David, what are you doing man? Yes, Dr Nic is awesome, and yes, Ruby is wondrously hackable, and yes, Rails allows plugins easily, BUT why do you keep beating this dead horse? No one said anything about a critical flaw. No one said Rails is inherently flawed and can never be adapted for high traffic sites. Just the opposite is true! Alex and the other guys at Twitter are those who are pushing Rails further than it’s ever gone. These are the pioneers. They’ve gotten to the hard part, and they’re still going, despite the difficulty. Really, does anyone think that sites at that load are running out of the box copies of Rails? It’s just not the case. That’s ok. The fact that Rails can be modified is one of its strengths. There’s no need to be defensive here. That’s the big problem we all need to face.

People often say that DHH has a big ego. That is no crime in itself - in some situations, having a big ego is healthy and even useful. But this behavior - where someone points to a weakness that needs to be improved, and their remark is interpreted as an attack that needs to be counter-attacked - is a major problem. This is the kind of behavior that cripples organizations, leads to pointless in-fighting and turf wars, and saps the energy out of projects.

The solution? People (especially those in leadership positions) should welcome attacks. That way, even when no attack actually exists, as in this case, the original speaker will still get a welcoming response. There are 3 advantages to maintaining a welcoming attitude to attacks:

1.) When an attack really does exist, a welcoming response will often soften the attitude of the person making it.

2.) An open attitude to criticism can not be demonstrated in the face of praise, it can only be demonstrated in the face of criticism. Every product or idea, no matter how good, will have some flaws, and so it is important to be open to negative feedback.

3.) Welcoming attacks saves you from the embarrassment of reacting in a defensive way, when, in fact, no one was ever attacking you.

At times, the rant is almost incoherent:

Alright people, time to get a huge grip on reality’s collar and hold on tight.

Ruby on Rails is not a mother fucking industry!

Jesus fucking christ on a goddamned pike you absolute mother fucking donkey dick sucking morons get a fucking grip!

You are not in an industry. You are a bunch of people barely scraping by in a tiny little sector of a moderate sized piece of the economy. Gaming alone makes you all looks like the pathetic little crumbs I brush out of my toaster when it smells bad.

He makes a few good points though:

Where I work the company is willing to blow huge amounts of money on a consulting firm or hardware, but ends up firing people when times get tight. It’s a universal mass hysteria that paying $100 – $200 per hour for a group of consultants is preferable to simply hiring good employees. At the rates companies pay these consultants they could hire 4 full time employees.

Consultancies used to provide a service by managing the entire project so you didn’t have to do much. Now with Agile and Pair Programming the consulting firms can dupe clients into helping them make the sausage, provide little to no services, yet still charge insane rates. What’s impressive is these consulting firms somehow charge rates that are 5 or 6 times what they pay their employees.

…

Let’s take ThoughtWorks as a classic example of the hysteria. They decided to get into the Ruby on Rails game and went full bore. I was telling people right when Rails came out that doing it for internal projects at big companies would be a huge money maker. Nobody believed me, and now rather than all my smart friends working on cool applications for big money I have ThoughtWorks fucking up my party.

Before you continue this part of the rant ask yourself a question:

How did ThoughtWorks go from 0% Rails business to 60% Rails in just a few short months, but somehow didn’t hire that many top notch Ruby guys? Remember, if 60% of your business is Rails then 60% of your people need Rails training or else you have to hire more people. If they didn’t hire any more people than that means…the people they had were retrained. With two week training courses. Huh? How does that make them experts?

What happens if you do that is you have a group of former C# and Java guys running around writing shitty Ruby code and training on the client’s dime for huge fees.

Some of the post seems to border on libel:

In the two projects I’ve taken from ThoughtWorks I found mountains of horrible, horrible code. They of course try to pull the classic “there’s many ways to do everything in programming” but this time they kind of get caught because Ruby on Rails means stay on the Rails. There is an established best practice way to build web applications with Rails and that’s the entire point of the system. When ThoughtWorks fucked up these projects they did it in such a completely deviated way that it was impossible to defend.

Additionally, the people they placed on these projects were not well trained at all, had no idea about simple Ruby idioms let alone good design, and spent more of their time drinking and having fun than actually getting shit done. At the last project they actually had bottles of Pedialyte in the fridge to help with their hangovers after wild nights partying.

You see this happen all the time at dinner parties or events. Things are great until one or two people announce the intention to leave. If those folks are fun and entertaining, there’s an immediate realization that the quality of the experience is about to go down. And yet more people announce their intention to leave, and so on, until you are left with the party hosts and a big mess ;-)

Advanced discussion: Social Network Death Spiral
Now let’s do a more advanced discussion using the concepts above - for some new readers, this discussion might completely be incoherent ;-)

Let’s consider a specific scenario where a social network could easily start to “Death Spiral” - here’s some set up on the scenario:

• You have a bunch of users, let’s call the total number N
• The total number of users in the ecosystem, called the carrying capacity, is variable C
• These users all individually require some utility value on a site, let’s call this V_required
• Then there’s a retention %, called R, which depends on two factors:
  • If the utility value for users is satisfied, that is, V > V_required, then R close to 100%
  • If the utility value drops under V_required, then R is crappy, closer to 0%
• And to borrow Metcalfe’s Law, the value of the network is calculated at V = N^2

So the scenario is that as the total users for the application reaches the carrying capacity, you basically hit a point of maximum saturation - this is defined by the ratio N/C. Sometimes this ratio can also be referred to as the “efficiency” of a user acquisition process, which relays how many people you actually acquire versus the universe of all users. (Obviously you want this to be as large as possible)

Once you hit the carrying capacity and acquire all possible users, N is at the highest point, and thus the network value is also at its highest point, V = N_max^2. Similarly, because the network value V is at its highest, the retention reaches its highest point as well.

The question in this scenario is, at any point during the growth of the network, does the network value V exceed the required value of the site, which we call V_required? Does the network break through the critical mass of value?

If so, retention should be great, as defined by the explanation above. In fact, maybe you reach V_required early on during the growth of the site, which makes the acquisition process much more efficient. Early on, maybe the userbase wasn’t sticking, but a critical mass threshold is met, and suddenly the entire userbase sticks, which creates a long-term creation of ad impressions and company value.

However, if you don’t reach the required value in the network, then you’re pretty much screwed. Then the retention sucks, since the users aren’t finding value, and some percentage of them will leave. This will then remove more value from the system, causing yet another round of users to leave. This continual loss of users is a death spiral that collapses your network in fine Eflactem’s Law style.

A very interesting variation of this is when you apply Metcalfe’s Law not to the entire network of users, but rather think of a social network as a loosely grouped set of connections. In that case, some local networks might have achieved critical mass, and if they are big enough, they will be retained. However, if the smaller networks around any given group start collapsing, then sometimes even the large networks will get pulled down with them.

Over the last 3 years, people on our team have helped launch sites such as The Second Road, Monkeyclaus, Accumulist, Danforth Diamond and iHanuman.

The last few projects we’ve taken on have initially ranged in price from $40,000 to $80,000. As these are ongoing projects, I imagine their total costs will eventually be much higher.

The technologies we’ve developed for our clients include:

1.) Ajax based chat rooms for The Second Road. These have some unique features, including their permanence and unique URLs for each post to the chat rooms. The permanent URLs are an idea we borrowed from 37 Signals Campfire product, which is probably the best chat room service on the market. The accessibilty of past transcripts is meant to foster group identity and evolution over time.

2.) Ecommerce for digital products on iHanuamn. This system, built from scratch, allows the staff at iHanuman to enter videos and MP3s into the dataase, which then become available to iHanuman’s customers. The products are grouped into “albums”, allowing the yoga teachers to group together teachings that they feel must be taught as one connected course.

3.) Aggregation and syndication of RSS and Atom feeds. Bluewall uses some PHP scripts we developed, which tap into the functionality of such services as Yahoo Pipes, so as to offer custom aggregation services to people with an acute need for large quantities of high quality information on specific topics. We worked with Vijith Assar on this project. He is something of a Yahoo Pipes specialist, and we recommend him for that.

4.) WordPress customization. For sites such as the The Second Road blogs or Art Of The Possible, we pull together the 3rd party WordPress plugins that we determine our clients need, and also modify them as required to acheive the client’s goals.

5.) Social online networking. For The Second Road site, we created ways for members to sign up and create profile pages, link to friends, and share their stories with others (or they can keep a private journal that no else can see).

We do not take on projects that we estimate to be less than $10,000, as such projects merely require the simple production of standard web elements, a task we’ve no special competitive advantage at doing. For projects that cost less than $10,000, we suggest you contact Charmed Works, which is a highly competant web design company.

For very large corporate contracts, you might want to contact Huge, which is in New York City (Brooklyn). We have a close friend (and previous co-worker) who works there and who tells us that Huge is a leader in innovative techniques for keeping large scale projects organized.

Many times, clients who are new to the web are puzzled why the work is so expensive. We do what we can to educate our clients about the costs involved in this work. However, we also suggest that anyone who wants to work with us should get multiple bids. We recommend that you talk to Category4, the most successful web design company in central Virginia. We’ve also worked with Greg Herrington, who is an extremely talented computer programmer, with his own consulting business. We’ve also worked with Chris Clarke, who has done fantastic work on a number of large, complicated web sites. For design, we strongly suggest you talk to Darren Hoyt, who is one of the best designers in the world. You owe it to yourself to talk to all of them.

In the past we confined our activity to programming and design, but we were frustrated to see good ideas fail because our clients either had no quality content, or they had no strategy for promoting the good quality content that they had. More recently, we’ve begun lining up writers and videographers to produce content for sites, and, where the client needs help, we’ve begun to manage the promotion of the content online. We live and breathe the web, so our clients can focus on the other aspects of their business.

We strongly advise an incremental approach to web development. The best way to control a project’s costs is to build in phases. Each phase needs to be planned, and the plan must then be followed. Too much creative brain-storming, while a site is in the middle of construction, can lead to fantastic cost overruns. We have had clients who started off with ambitious schemes which, once launched, required more management resources than the client had to give, thus leading them to scale back. We advocate the opposite approach: start small and then scale up. These remarks are especially relevant for clients who may not have a depth of experience on the web.

In the past we’ve worked with both the PHP and Ruby computer languages, but in the future we hope to mostly use Ruby On Rails, as it is an innately superior technology. Many of the tasks that we labor to make functional in PHP are handled for us automatically in Ruby On Rails. We currently use Ruby on the backend for the scripts that automate tasks on our webserver. However, we recognize that each site is unique and requires a different mix of technologies. Whether your site needs HTML, Flash, CSS, Javascript, Ajax, Ruby, Java, Perl, Python, PHP, MySql, MS Access, MS SQL Server, Quicktime or more, we can find the people who have the skills you need. With our vast network of professional ties, we stand ready to pull together the designers, programmers, writers, videographers, animatiors, photographers, illustrators, marketers, office managers, project managers and other supporting staff who can make your project a success. We’ve had success with quick-forming agile teams that mobilize to get your website out to its target audience.

Close Out Sale!

Nope, not going out of business, just retiring my camera.

It will soon be replaced by one fierce cine-aesthetic machine. But until then (mid-June), I’ll be giving my 720p HD camera the hurrah she’s earned, staying busy as can be before setting it adrift to the video happy hunting grounds.

At this point I’d like to welcome you all to join me in this production. Many of you have worked with me before, and maybe you’re due for another fine commercial. Many of you have thought about retaining my services, but to all of you, there’s an opportunity here. An opportunity to get the same creative service, at prices unseen since I started.

Let’s get busy!

This is a really great company, and the work they do is amazing. Check out this demo reel:

Here is more about the company:

Piraeus Picture Co. is a fresh video enterprise with the heart of cinema.

We offer our clients the very best in creative solutions for all their video needs. Our well-known video production house has created many award-winning and eye-catching films, commercials, EPK’s, documentaries, and webspots.

The focus of Piraeus is to help its clients reach their audience with hands-on personal service. We know how to market through out-of-the-box visual imagery and creative narrative.

Whatever service you need, Piraeus can meet your requirements offering the very best in all facets of video production:

• TV commercials, from infomercials to :30 spots
• Webspots and web strategy
• Cinema Quality Films
• High Definition
• Music Videos
• Television or web-based programming
• Documentary-style footage
• Event shooting (workshops, lectures, corporate functions and parties)
• Video presentations for organizations, large and small
• Stills from video for print and display media

With Piraeus Pictures, you are guaranteed to have your media craft in the best professional hands. In reaching your audience with a more cinematic and artistic approach to video production, their response will be more personal and deeper than with the average local TV spot or late-night infomercial.

Piraeus helps you to connect quickly AND DIRECTLY with your audience. We want your audience to never forget your pitch—and the visual experience.

Piraeus’ eye-catching films, video, and webspots will provide a channel for such a connection and strengthen your brand for years to come.

Wherever you may want to sail, Piraeus Pictures helps you catch the wind.

You can reach Johnny St. Ours here:
Johnny St.Ours
PIRÆUS PICTURE Co.
434.293.9976
PiraeusHD.com

The business model is straightforward: many people fall in love with a particular yoga teacher, and they want a way to follow that teacher, even when separated by time or geography. Often, people will go somewhere far away, to attend a weekend yoga workshop, or perhaps they go to a month long retreat. When they get home, how do they continue to learn what that teacher has to teach? This web site aims to fill that gap.

I was the lead programmer on iHanuman. I learned some important lessons while building that site, and so I think if I had a second chance to build such a site, I could do a much better job.

For instance, there are some technical issues that can be improved. iHanuman was written in PHP, which does not support Unicode - the lack of that support makes it difficult to support text from other languages. iHanuman has had sales in Spain, Sweden, India and other countries. International language support is important. Therefore I propose that the new site be written entirely in Ruby on Rails. Since Rails supports Unicode, foreign language support will be easy.

Another lesson I’ve learned, both from iHanuman and The Second Road, is that finding a good team of writers is crucial. It’s writers that initially pull people to a site, build traffic, and draw the attention of other web sites, who then might link to you. It’s important to hire writers who already have weblogs with established audiences. One thing I’ve learned is that when you hire such writers, and they start writing on your site, they bring their audience with them. Thus, hiring such writers is the quickest way to jump start an audience for your new site. For a site that focuses on yoga, it would be important to hire writers who have already proven their passion for yoga, spirit and health. They’d need to already have reputations for writing well about these topics.

iHanuman cost about $50,000 to build. The new site could be build for somewhat less. I was a major part of the costs of iHanuman but for the new site I’d be willing to work for free, in exchange for equity in the final business. Also, a great deal of money was spent building the video player that is in use on that site, but the same player (or somehting similar) can now be used for free.  [UPDATED: 05-01-08 - I’ve new information about this. The Flash player I’m thinking of is not free. However, licensing it, or something like it, would only cost a fraction of what it cost to develop it in the first place.]

I think to launch such a site would cost about $25,000. Some of that would go to design work, and some of that would go to hiring good writers, and a small portion of that would have to pay for a staffer who would actually add in the videos to the database.

Three things would have to come together for the new site to be successful:

1.) The right tech team (design/programming)

2.) The initial capital

3.) Someone with deep connections inside the yoga community

I believe I can take care of #1. Over the years I’ve worked with many talented designers and programmers, and I feel confident I could pull together the right team.

The ideal investor would solve both #2 and #3 but such individuals are rare, so I assume that #2 and #3 will be answered by different people. iHanuman was blessed with the dedicated committement of two people who both work as yoga instructors. The new site would need to be pushed forward by someone with a similar kind of energy.

The aim of any new site should be, simply, to be the best yoga site on the web. It should be a site that pulls together the best writers and the best videos. It should be a site that is broad enough to encourage discussion on all related fields: health, mind, body, spirit. The team that built iHanuman doesn’t seem interested in promoting it. The site has been up for 8 months now and nothing has been done with it. It makes a few sales a week, but I believe it has a vast, untapped potential. If you’re interested in seeing the creation of a site that captures the full potential of becoming a yoga mecca online, please contact me:

lkrubner at geocities.com [of course, replace the “at” with “@”]

I right-click on the Desktop. From the context menu that appears, I choose “New”, then “Folder”. Then I type in the name of the new folder. Then I hit “Enter”.

Explorer becomes unresponsive while it creates the new folder. Counting slowly, I am able to count to 48 before Explorer comes back to life. 48 seconds to create a new folder. On a Mac, circa 1991, using System 7, I recall this same task taking from .5 seconds to maybe 2 seconds when things were bad. On a Unix machine, circa 1980, my guess is that the mkdir command took about .1 seconds to execute.

I am recreating a folder that I just deleted, and perhaps there is some kind of memory of the old folder that is causing problems. Whatever the reason, this is bad programming.

Windows Vista is a unmitigated disaster. No one should buy this product ever. And no company should be legally alowed to sell it.

The illusion of agreement:

“We should build a house!”

“Yes! A house!”

But what kind of house do they mean?

The interface as a spec: including stories inline:

Sometimes designing the static states takes more time, and doesn’t quite represent reality, as well as a brief note about how the functionality works. The key is to make this note in context — right next to the interface element its describing. The combination of real visuals and a brief contextual note shrink the chances of misunderstanding to near zero.

Designing an interface: from sketch to screen

The screen mostly followed the sketch, except for the controls in the upper right and the description field. That’s fine, because at step two those details Didn’t Matter. Coding the real thing, I found room for all three of those pieces in the top-right, and that worked better.

Thinking and sketching took me 10 minutes. Creating the real screen and updating the code can take two or three hours. That lopsided pattern, with short make-believe-time on the left and long build-time on the right, is always a good sign that you’re making progress. Ideas and paper are necessary, but they’re destined for the trash bin. So burn through them and focus on the good stuff.

Our Stories should be an experience rich site. It should offer an engaging environment that compels users to explore and connect emotionally to the storytellers. But it doesn’t offer this at all. Instead, it offers what looks like any other Google design. It’s plain, minimalist, and it’s focused entirely around the information and not the experience.

Google apparently thinks it has hit upon the secret formula to all successful websites - simple, minimalist designs that offer information in a concentrated form. In reality, this formula only works for certain classes of sites, of which the original Google website was the par exemplar. Google fails when it attempts to build a site that needs a philosophically different approach. As Hoekman explains:

 If Google’s goal here was to create emotional connections, they should definitely have considered something other than the business-as-usual, sterile design work that has become Google’s signature. Granted, some of the site’s pages are geared towards showing people how to conduct interviews for the site, and those pages are probably best left alone, but the main attraction here is an environment of storytelling, not another Google search results system.

…Design is meant to communicate content. With the right design, you can always meet your goals much more effectively. If you want emotional connections, design something that encourages them. If you want people to take action, design to encourage action. Don’t let your usual design style get in the way of doing something great.

Does anyone remember the name of the graphic artist who did this poster? I’ve a Joan Baez biography somewhere but it is buried in a box because I recently moved. I need to look the artist’s name at some point.

I assume that:

“Create a signature that automatically added to your emails”

is suppose to read:

“Create a signature that is automatically added to your emails”

I always find it surprising to find typos on a major site like Yahoo.

Btw, if you want CSS rules to apply to unknown elements in IE, you just have to do document.createElement(elementName). This somehow lets the CSS engine know that elements with that name exist.

This could be a viable strategy for using HTML5 and styling the results in IE, even if IE does not support certain tags.

I think its fine to print debugging information to the screen when a website is under development, but on a live site, I think the error messages should try to be more helpful. Perhaps the error message can suggest the average speed it takes the site’s sysadmins to fix problems of this time. Or the error message can suggest that the visitor go get the page out of the Google cache. Even the cutesy error message that Stikipad used was more reassuring than this.

Upon submitting the form, I got the following error message:

This is, of course, an example of bad user interface design. They should not allow me to choose a date which they themselves forbid. It is confusing that their form should offer a date which is, in fact, not allowed.

I won’t use a hosted web service like Typepad or weblogs.com. It’s too easy for them to decide that you’re ‘violating’ terms of service, and next thing you know, all your weblog entries are gone. I saw this with wordpress.com in the recent events that caused so much discussion: in fact, I would strongly recommend against using wordpress.com because of this–the service is too easily influenced by public opinion.

I don’t use either my Yahoo or Gmail mail accounts. Regardless of whether I can get a copy of my email locally, if I decide to not use either account I have no way of ‘redirecting’ email addresses from either of these to the email address I want to use. (Or if there is a way, I’m not aware of it.) Getting a copy of my data is not an exit strategy–it’s an export strategy. An exit strategy is one where you can blow off the service and not suffer long-term consequences. A ‘bad’ email address is definitely a long-term consequence*.

A few months ago we started using Stikipad to get ourselves organized. We started using the site under conditions that were close to an emergency - we had a web site that was past its deadline, and we were trying to regain control over a situation that had become chaotic. We began to post bug reports and notes to ourselves. Stikipad was useful to us as an easy-to-use online notepad, which we could use informally. It helped that it also had certain wiki features - it kept track of who made each edit, and it allowed us to revert changes when we made mistakes in editing.

Since then, we’ve started listing all the hours that we work on there. This data is vital for when we send out invoices to our clients. Also, all of the long, complicated to-do lists, for each project we’ve been working on, are all on there. We did not realize how important the site had become to us - we’d set up a quick, free account as a simple way to organize one project, but our use of Stikipad has grown so that lately it has been central to the way we schedule our time.

For the last three days, when we go to the site, the only thing we get is this error page:

The whole entire site has been down. You could not start a new account, nor reach any of the pages on our account, nor even reach the “Support” page. We all kept trying, at different times during Friday, Saturday and Sunday. There was no way into the site.

The site just came back to life tonight. But we are planning on giving it up. We feel we can’t trust it anymore. There has been no word on the Stikipad blog about what just happened. Their silence does not inspire confidence in us.

Stikipad does have an export option, which we could use religiously to keep our data safe. I blame myself for not already automating a daily download of this data. I’m fixing this particular oversight tonight. All the same, Stikipad can’t value our most vital data to the same extent we can, so it is perhaps best if we keep that data on our own server, and make the multiple backups of that data which we feel is needed.

Sprint, the No. 3 wireless carrier behind AT&T (T) and Verizon Wireless (VZ), has struggled since it merged with Nextel in 2005. The $70 billion merger, engineered by Hesse’s predecessor, Gary Forsee, was supposed to create a wireless behemoth that could steamroll the competition while pushing boundaries in wireless.

Instead, Sprint stumbled as it tried to blend starkly different cultures of the two companies while trying to reconcile their incompatible wireless technologies.

Sprint wound up alienating customers, who bolted by the thousands. Sprint’s dismal performance eventually cost Forsee his job. Hesse, a former AT&T executive with long ties to wireless, was recruited from a Sprint spinoff, Embarq, to replace him.

Dawson says it’s not too late to save Sprint, a grand name in global telecommunications. “But they need to make some big changes and do it quickly.

“The challenge for them is to figure out how to save the Nextel customers,” and move them to Sprint’s network “rather than let them walk out the door,” Dawson says.

Actually, they should worrry about losing their Sprint customers. I’m a Sprint customer, and I’m frustrated that their automated bill paying service keeps telling me “You do not have an account with Sprint.”

That means that my 5000 photos are gone. Those I can upload. But all the people I’ve linked to are gone (I’ve spent a few hours trying to reconnect with those I can remember). Anyone who watched my photos via their contacts has lost me (and I’ve lost much of my audience). All the photos that were marked by others are gone. All the groups which I participated in by contributing illustrative images are gone. All the titles, tags, geotags, view counts and comments are gone. All the descriptions and stories and dialog with others in is gone.

My document, my story, my part of the community, is gone.

But the whole social media movement that we can’t ever stop hearing about is asking us to contribute content to their websites; we’re building the value for them. YouTube wouldn’t sell for $1.65 billion without our videos. Flickr has our photos. LiveJournal has our stories and pictures.

But is it ours? Do we know who owns it? If the data is on our hard drive, we know where it is, we may even take the trouble to back it up (I’ve got an external backup at work, at home, and online). But if the data is on someone else’s site, how can I keep a copy of it? It may be against the site rules for you to do that, in fact, as the high profile Scoble story demonstrated.

On the TSR site, we are still cleaning up the rough edges. Laura Denyes, the lead designer on this site,  is transforming the rough and ugly forms. After enhancing the clarity and improving the use of space, we hope to leave the user with a better experience. You can see Laura’s work in this before and after image:

I’m fascinated by how U.S. teens build intricate models of which friends are available via mobile and which aren’t. Teens know who is on what plan, who can be called after 7PM, who can be called after 9PM, who can receive texts, who is over their texting for the month, etc. It’s part of their mental model of their social network and knowing this is a core exchange of friendship.

Psychologically, all-you-can-eat plans change everything. Rather than having to mentally calculate the number of texts sent and received (because the phones rarely do it for you and the carriers like to make that info obscure), a floodgate of opportunities is suddenly opened. The weights are lifted and freedom reigns. The result? Zero to a thousand text messages in under a month! Those on all-you-can-eat plans go hog wild. Every mundane thought is transmitted and the phones go buzz buzz buzz. Those with restrictive plans are treated with caution, left out of the fluid communication flow and brought in for more practical or content-filled purposes (or by sig others who ignore these norms and face the ire of parents).

1.) This is a nice list of commands for user management.

2.) Plesk makes normal system administration a nightmare. It sets up its own config files that override the defaults for most of the software on a Linux system. While Plesk makes some tasks easy for non-technical people, it makes normal system administration (where you ssh to the server) a real pain. You can follow some tutorial exactly, like the directions for adding a user on this page, and your work has no effect. Last night I was able to set up a user account, but was not able to set a working password. Turns out the passwords were controlled by Plesk.

[Added later:] Okay, I’m an idiot. I was trying to create a user account like this:

useradd -groot -Gadm,wheel,psacln -s/bin/bash -p947364 -d/home/lawrence -m lawrence

The helpful tech staff at RackSpace wrote (in reply to my question) that this command expects the password to be encrypted. So the correct way to add a user (at least on a RackSpace server running RedHat Linux) is as follows:

1.) ssh to the server using some non-root account

2.) after you log in, su to root

3.) run the above command without the password

4.) then run this command:

passwd lawrence

5.) then type in the password you want for the user “lawrence”

I’ll post it here so I can find it later. I’ve promised myself that one day, I shall be able to write all kinds of shells scripts. I’d like to be able to automate any kind of activity that we need to have happen on the server.