Google just recently posted an article talking about their opinion on dynamic vs. static URLs. In short, Google is saying that dynamically created URLs from a content management system, i.e. URLs that contain information talking to a database such as:

/media_review.php?user_id=25&article_id=315

should be left as is instead of rewriting them to look cleaner (static):

/media-review/bruce/dnc-ratm-concert/

Here’s a direct quote from their blog post on the topic:

Does that mean I should avoid rewriting dynamic URLs at all?
That’s our recommendation, unless your rewrites are limited to removing unnecessary parameters, or you are very diligent in removing all parameters that could cause problems. If you transform your dynamic URL to make it look static you should be aware that we might not be able to interpret the information correctly in all cases… …if you’re using URL rewriting (rather than making a copy of the content) to produce static-looking URLs from a dynamic site, you could be doing harm rather than good.

The problem is that Google seems to be making a recommendation on what is best for their search engine crawling and not what is best for the user or web usability in general. There is no debate, URL rewriting makes websites easier to use. It makes people understand what they will be looking at when they visit a link, and in general provides clearer information than dynamic URLs. For instance, here on our blog you can see all of my posts by going to http://blog.imulus.com/bruce the url is clear and easy to understand. If you want to see all my posts for a certain category you can do this http://blog.imulus.com/bruce/css. This functionality makes logical sense. Websites with extremely complicated URL calls can utilize rewriting to help their viewers better understand where they are on the site. And in regard to marketing materials — the time I see a company willing to use a url with ?id=237 at the end for a marketing or advertising campaign will be my first.

The fact is this, URL rewriting is an extremely useful tool (ironically Google’s blog post about dynamic rewrites uses rewriting for the URL). And while certain rewrite schemes may hide data that Google would like to parse, that doesn’t mean people shouldn’t use rewriting. The idea that a usable standard should be changed just to make Google’s web crawling better is ludicrous. Google throughout their history of search has continuously accommodated for changing website methods. By stating that URL rewrites are improper Google is taking a strike at one of the best standards to come out of Web 2.0. They’re suggesting a machine’s readability is more important than a human’s. And guess what: they’re dead wrong.

We run across a lot of discussion whether the stage of wireframing a website is important or not. Should you avoid the process of wireframing and just dive into design? What is the purpose of wireframes and why many designers and developers implement this stage as part of their planning tool?

Wireframes are an essential tool of communication that provide a rough guide to website structure. Their purpose is to give guidence to general layout, navigational elements, and content structure to designers, developers and clients. The stage of wireframing is achieved after the process of sitemaps has been approved. At this time, you should have in your hands a site structure in a hierarchical style. Here at Imulus, we take time at a wireframe stage in order to run the design and developing stage smoothly. Only an educated client will understand this process if explained. Sure, all clients would like to see their website redesigned in 24 hours…that would require a lot of java. We take time to explain to our clients why this stage is important to us and to them as well. They will understand.

Our designers will work through the wireframe stage to completion and then will sit down with our developers to discuss the many possibilities. This opens different perspectives which are always handy to get everything on track. For example, when it comes to talking about some special functionality feature for the site, it is a good thing that developers know this ahead of time and see what’s expected. They can see what problems they can run into and how to solve them ahead of time. It is too late if this got avoided when the design is already in development. As for the designers, it is easier to have a wireframe in hand. You get the idea where things are supposed to be, and start to visualize the design. Try to have some fun with wireframes. OK, sure, they can get boring sometimes especially when it comes to some revisions but that’s all because you’re anxious to start the designing and developing. Also, you don’t have to adhere strictly to what the wireframe is showing. We have run across many times where the wireframe was showing one thing, but in the design stage we have changed it. It’s all right to change the wireframe in the design stage as long as the purpose and direction is not lost. My advice is to spend whatever time necessary to complete the wireframing stage; it will make your job easier in the design stage, and will save headaches to developers, as well as to clients.

A book recommendation to follow on a wireframing stage: Web Redesign 2.0 | Workflow That Works by Kelly Goto & Emily Cotler

XML sitemaps are a default for Web development at this point, yet I’m amazed about how many sitemaps are done improperly because developers use sitemap generators which either return partial or inaccurate coding. For the longest time we used http://www.xml-sitemaps.com/ and repeatedly ran into formatting issues with Google Webmaster Tools.

After trying a slew of various editors I think we’ve found a winner. XMLEcho isn’t the quickest option in the World but it certainly produces clean and accurate sitemaps. Creating an account is simple and quick, plus the service gives you the option to create sitemaps of unlimited size… best of all, it’s free!

Nice job XMLEcho!

Tonight Jason Fried from 37signals spoke at the Oriental Theater in east Denver. He discussed everything from client deliverables to the 37signals four-day workweek. In essence, Jason’s talk boiled down to three key points:

1. Don’t work on hard problems. Break them down and keep things simple.
2. Avoid distractions (open office environments, meetings, e-mail, etc.) get a site or product out of your head and into production ASAP.
3. Deliverables are bullshit, clients don’t care, the end product is what matters.

First off, I want to say I have great respect for 37signals and their impact on the industry. Having the chance to talk with Jason about issues such as: stopping IE6 support, disregarding Photoshop in the design process, and scaling with growth, was an absolute treat. Clearly the team at 37signals is one of the most innovative and talented in the industry.

However, I think 37signals dominance in the web products field has distorted their ability to critique the client-based approach. And while I don’t have knowledge to speculate specifically on day to day client interaction, I do have a few things to offer from a developer perspective.

Team chemistry is important.

First, people working from home all the time can be harmful to the group chemistry. Jason and team do a huge amount of work via telecommuting. Relying on campfire, screen sharing, and video chat interactions for the bulk of their communication. They feel this helps minimize distractions and keep people productive.

I’m not sold this is the way to go. I think it’s hard to truly feel connected and dedicated to your team if you don’t spend real time with them. When’s the last time you became really good friends with someone without spending some serious face-to-face time with them? For me it’s never happened, not once. And as great as chatting online is, it’s not the same as being in the same room and hashing things out. You miss the subtle face gestures, the inside jokes, the bantering, and the all around comradery that happens in the workplace. Part of the reason Imulus does great work is because we have dedication to one another. Even on days when I’m completely out of wack mentally I still find myself focused on helping the team. Why? Because I’m relied on to help create the great stuff we build. And I trust those I work with to do the same. As ridiculous as our office gets sometimes in the end we get shit done and we do it for each other and ourselves.

Deliverables have a purpose, it just needs to be refined sometimes.

Second, I don’t buy that all deliverables are bullshit. Just as some companies like to skip Photoshop (37signals) and go straight to coding, and others (Apple) like to make mockups pixel perfect it’s impossible to say that one solution is better than the other. Yet, we can agree that certain processes work better for certain people as well as certain projects.

Let’s talk about the way we work. Imulus’ basic approach is to offer the client a timeline, design brief, wire frame, and mockup of the final interface. Now, it’s important to realize that we haven’t always done it this way. In fact, for some time before I came to Imulus the wireframe process was basically nixed. What was the result? Instead of 5 hours spent reworking things in the wire frame process, 25 hours was spent reworking things in the development process. Look, we aren’t naïve, we recognize that clients change their mind and get new ideas all the time. However, we’ve found that most of this re-thinking takes place in the wire frame stage. And therefore we save hours of coding changes by altering the approach up front. In essence, if you’re building a car and the frame is faulty, why wait until the upholstery’s getting put on the seats to fix it?

Still, we know it’s a strong possibility that some of our deliverables are blown out of proportion. And as most firms do we will continue to collaborate and narrow down our inefficiencies. However, we have found that some deliverables are an extremely important step, and just because some projects or companies don’t require them doesn’t mean they aren’t important.

In conclusion

Clearly 37signals has clout and track record to support the way they work. And regardless of how that alters the Imulus process we love hearing about it. It’s phenomenal that they have so much passion behind what they do. I hope over time we can refine our own process to the point they have. Until then it’s great hearing a second opinion about things.

Over the past few weeks we’ve had our lead developer here at Imulus on vacation in Mexico. Initially there was some concern around the office that with him gone his day to day tasks would be a major time sink for the rest of us.

However, as the past few weeks have gone by I’ve come to the conclusion that missing a big piece of the puzzle every now and then is more of a positive than a negative. Not that we don’t want John to come back, or that we won’t be faster as a team once he returns. But more that the best way to force people to learn is to throw them into the water and make them swim. I.E. having John out may make us slower in the interim, but in the long run it will make us faster because each developer will be even more capable than before.

This trial by fire attitude is what makes people better all around, and consequently worth more in the long run.

So here’s my advice: if you’re used to having someone around that can help you get through tasks or problems stop asking them for help once in a while. Sacrifice some time, lose a few hours to the problem, and have faith that learning it on your own will be worth it in the long run. Both for your self value and the company’s. Having a tutor is great, and having a cohesive team is even better. But realizing the value in self growth is essential. It makes the process faster and less distracting for everyone in the end.