Recently I’ve been doing a heap of work improving the lovely Lizzy C’s business website. She is a melbourne photographer specialising in portraits, commercial and wedding photography. A lot of the improvements have been focused on restructuring the website to improve the user experience but also to improve the ability for us to see what visitors are looking at and what their intentions were.
The other thing I’ve done for her is a integrating her ShootQ CRM with her website. This takes the form of a WordPress plugin which you can download at WordPress.org.
It’s a common problem, there’s a young kid on your team who thinks he is a great architect. He wants to replace the simplest include with a new whizbang inherited menu system or add 3 layers of abstraction to the database access layer, or replace the beautifully crafted error reporting system with exceptions. When quizzing this “architect” he has a reason for every possible change, these are those classic excuses and reason.
- Security. “This will stop any possible security breaches in the future,” he says. Little does he realise that including one extra file into your system isn’t a security risk and probably never will be.
- Performance. “We will do this and this and this, and then cache it all in memory. It will be faster than the existing system,” he says. Sure this might be faster, but the difference between 5ms execution and 8ms execution is irrelevant. Chances of him actually having done the profiling and being able to improve the performance gains are minimal.
- Future proofing. “This will put us in a great position to make changes in the future.” Which changes? You know those unspecified, unrealised and unkown changes that we may or may make sometime in the future.
- Outdated. “There’s a new better way to do that exact thing.” There is a new way to do it, there is a new way to do anything and everything, but is it better? Is it worth holding the project back a week to modernise the codebase? Probably not.
- That’s ugly. “But this code is ugly”, he pleads. Is a 3 line hack better or worse than a leaky abstraction?
I’m sure you know of more, what are they?
Update: This comes across as very bitter. Perhaps “bad programmer” isn’t the right word. Try “inexperienced”. Working on systems, refactoring them and improving them is obviously our job as programmers, yet sometimes you need to take a step back and think. The first design or system we think of is very rarely the right one, it doesn’t matter how much experience you have.
I’ve been working with Google Analytics a fair bit recently, setting up goals and investigating the use of the Events API on a few sites. There isn’t much about Analytics I don’t like, it works as expected and has features you didn’t even know you wanted. I have 2 things I would love to see implemented, first of all, testing of goals. Currently the recommended way of testing if your goal is configured correctly is by using the Top Content report. This works fine, by it is pretty annoying you can’t test this right there on the configure goals page.
Second, I would love to see functionality wherein you could set milestones on the timeline of Google Analytics. This could mark when a new feature was implemented or when a style change was made, this would really let you visualise changes in browsing behaviour and how they relate to site modifications. In my work’s case, we would also be able to show clients really well the results of optimisations we have made. The display should work in a really similar manner as the news articles on Google Finance.
So we have finally launched the Oz Experience website. Amongst many other things this is the first website we have launched which contains the travel planner originally built by the talented Ondra Medek. Anyway the point is we have written a whole heap of software for this launch and the easiest to package up and send out to the rest of the world is the latest updates to Control.Modal.Dialog.js. I have simplified the API a whole heap and generally made it do a lot more with a whole heap less code.
At the same time, I’ve spent about 3 minutes setting up Xebidy’s Code Library, we are planning on releasing more and more of the code we are writing internally to the world under Open Source licenses and hopefully Bootstrap will be one of those. Sadly, other things tend to get in the road, like clients.
Update 4/06/2008: We have released a new much better version of this. It still lives at the same place.
It has been mentioned a number of times recently (though I can’t think who, probably John Resig) that building API’s is hard and I can’t help but agree. While it’s definitely challenging, I think it can be an extremely rewarding thing to get right. Developers really do feel the benefits of having a well thought out APIs with productivity gains and less headaches.
One of my new favourite bloggers, the Graveyard Barista has hurt his shoulder working, I’ve only been working in a bar for about a month now but I know how much it sucks to hurt something so integral to your job. For me, it’s cutting your fingers, you have your fingers near alcohol and limes all night and when you cut your finger you are in for a great deal of discomfort all night. Reading Humble Pie, Gordon Ramsay mentioned that chefs learn how to cut with both hands so that if they cut their hand they can still work. So I’ve been doing exactly that, pouring drinks, squeezing limes, cutting limes and anything else that I would normally do with my right hand, switch it over. It feels really wierd to start with, but you get the swing of it.
This is a bit of a brain dump about something that’s been bugging me for weeks, it doesn’t have a great deal of coherence to the idea yet.
I’ve been working for the last few months on the excellent Silverstripe CMS and the framework Xebidy has developed on top of it called Bootstrap. We are releasing the source of Bootstrap (not soon enough) and plan to support it as a plugin or alternative input system for Silverstripe. Anyway, the point is these systems are really based on pure content management systems – every piece of data entered into the system is purely for displaying on the page. Everything is written expressly for the webpage and rarely will be used for any other purpose. This is what most people expect they are getting when you tell them they are getting a CMS, I’m not sure it’s the best way to run a content heavy website.
What I’m suggesting is to move to a more data centric management system. Rather than creating pages and putting information on the page about a product, we should create a product in the system and let the webpage display that in a properly formatted page. This way, things such as product reviews, tags and comments are attached to the product itself, rather than to the page. Now, let me say I’m aware that a lot of websites are built in this manner, (I’ve worked on them before) however it isn’t a viable option on a smaller level.
There are a few reasons for this, firstly building the site around the companies products can be a very difficult process, first of all the designer/architect needs to have quite an intimate knowledge of how each product relates to each other and the company which can take a great deal of effort, time and money. Secondly, this approach can be limited in flexibility, obviously adding new products shouldn’t be a problem, but what happens if there is a new class of product or the company moves into selling services. The website will not necessarily have been designed with these things in mind and then the database will need to be adapted to the new structure.
I think to solve these problems, a new type of CMS needs to be designed (or an existing one adapted) which lets the web manager develop and adapt the database for themselves. I’m not quite sure how that would work, but it could leverage some of the existing web apis (GData & Pipes for example) to pull together the data.
My Goodness! In the course of my work I came across this cool picture of a Guinness. How cool is Flickr?
Today I woke up at 8:45 in the morning, and due to the fact that I’ve been asked to get in to work earlier (read: before 9) I rushed out of bed, jumped on my bike and got to work as fast as I possibly could. Turns out, when I was setting my alarm clock last night I must have set the actual time an hour forward. I was extremely disorientated when I got to work a good half hour before I left.