They approached me about creating a database driven custom web application that their personnel could access online, any time, from any computer.  For each event/contract they wanted to have an easy way to store basic information like:

• event location details
• event segment schedule and fees (as in cocktails, reception, after party, etc…)
• bands and musicians for each segment
• requests and special music
• crew information
• client contact information
• contract information like dates, reference, status, terms, etc…
• payment amounts, schedule and status

click for full size view

The system is based around the color coded list of upcoming events (above). This only shows a tiny slice of the information that is collected for each event.  Here they can access printable summary sheets presenting condensed event info for specific roles like musician and band leader, a printable contract, view and edit links and links to other event specific operations like budget and the dynamic “contracting” page.  At the top we also have an event search and menu for other system features that are vital to the business.

click for full size view

A lot of time is spent on the contracting page for each event (above).  Here they select the instruments and musicians required for each event segment.  This page uses a lot of JavaScript to dynamically calculate musician fees and expenses based on which segments of the event they are working.  These numbers are hidden from users who do not have the required privileges to view sensitive financial information.

The financial data generated on the contracting page is saved and displayed on a number of different payroll reports.  There are other reports for payments, expenses, contracts, musicians and anything else the client needs in order to access important information in a useful format.

The system also includes management for contacts, musicians, rehearsals, plus user login and a multi level access permission structure.

As the client uses the system they identify areas that seem too tedious and time consuming and we work together to devise changes to help streamline their work flow.  A lot of AJAX and Javascript are used to make the user interface as friendly and efficient as possible.  The whole application is based on the Symfony framework to ensure that the code is organized and extend-able and that the system is solid and secure.

With that in place it was relatively easy to get BbPress to integrate with WordPress since they are developed by the same group. There were a number of challenges getting all 3 application to work together and be able to access each others functions when necessary. I was also able to get the whole site layout to run off of Wordpress’s template system.

SquirrelCart is a php/mysql shopping cart application, with control panel, heavy use of session variables, a lot of functions, templates, etc… pretty standard. There is almost no documentation for the code and the company does not provide any support for hacking it. I know it pretty well now though there are still occasional surprise.

Orbital is a payment gateway also known as Chase Paymentech. Their tech support was helpful but it was very difficult to get a test account from them for testing responses from their API. They normally don’t give them out to customers that are using certified shopping carts like SquirrelCart.

We needed to test Orbital’s responses with Order Motion(OM). Oribital is only authorizing the transaction and then OM completes it and controls inventory and has all kinds of fancy features. Their API is very thoroughly documented but they don’t have any quick start guides, and nothing about PHP. They run asp and both the help and control panel can only be viewed in Internet Explorer!

They did reluctantly provide some sample PHP code for the cURL request. We found that the OrderID element of the order request was required in order to match the order with the Orbital authorization. Also the authorization code from Orbital was 40 characters long and OM would only accept 30 max so they had to fix that at OM to accept more.

We also use Order Motion to retrieve inventory and past order information for the cart.

If you have questions or need help with any of these 3 solutions let me know.

EK

The fact is that the majority of websites employ very similar approaches for achieving the same goals. Years of experience have taught designers and developers that for some things there really is a best way to do them or a few standard options that cover most cases.

Unexperienced developers who are trying to break into the business will often try to please the few clients they can get by trying to follow their instructions to the letter without suggesting better approaches when appropriate. They are particularly reluctant to flat out tell the client that doing things the way they want is just not possible, not because it’s not theoretically possible, but because it would cause problems down the road.

Sites developed with this approach can turn out to be hard to navigate, inconvenient for the user or just plain ugly.

Often clients will request Flash intro’s or landing pages. If you’re creating a book or magazine then you need a cover and table of contents and a web site is similar right? Yes, but it’s not exactly the same, and you should take users directly to relevant content instead of making them wade through preliminaries. If you pick up a magazine you don’t have to first turn to the table of contents before going to an article. You can always flip to content right away. It’s not a perfect analogy but I think that it is sometimes helpful to think about these parallels.

Recently I had an experience where a client insisted on having the customers to their online store enter their credit card information in an early stage of the checkout process even though almost all online stores leave this step for last. When the customer finalizes their order their credit card information is submitted to the payment gateway for authorization and it could come back declined. The client didn’t like the fact that the customer would have to go back so many steps to revise their credit card information but this situation could have been avoided if they had not insisted in doing things differently.

Now there may be ways to do things that nobody has thought of yet that are better than current industry standard best practices. If you come across one then of course you’ll want to be the first to use it. Just make sure you aren’t fooling yourself, check out what everybody else is doing first before you decide that your new way is better.

Some sites present special cases and may require doing things differently also, just make sure an unusual approach is truly warranted before proceeding. You are doing your client a favor if you can dissuade them from setting up something out of the ordinary that will cost them more money down the road when they realize they need to pay some one to redo it with a more standard approach.

While there is a little technical jargon here I think that anybody who is at all involved with the development, or expansion of a web application needs to read this. I know exactly the kind of situation he is talking about…

“The problem is that PHP is just too easy. It tempts you to try out your ideas, and flatters you with good results. You write much of your code straight into your Web pages, because PHP is designed to support that. You add the heavier code to functions in library files, and before you know it you have a working Web application.

You are well on the road to ruin. You don’t realize this, of course, because your site looks fantastic. It performs well, your clients are happy, and your users are spending money.

Trouble strikes when you go back to code to begin a new phase. Now you have a larger team, some more users, a bigger budget. Yet without warning things begin to go wrong. It’s as if your project has been poisoned.

Your new programmer is struggling to understand code that is second nature to you, though perhaps a little byzantine in its twists and turns. She taking longer than you expected to reach full strength as a team member.

A simple change estimated at a day, takes three days when you discover that you must update 20 or more Web pages as a result.

On of your coders saves his version of a file over major change you made to the same code some time earlier. The loss is not discovered for three days, by which time you have amended your own local copy. It takes a day to sort out the mess, holding up a third developer who was also working on the file.

Because of the popularity of the application, you need to shift the code to a new server. The project needs to be installed by hand, and you discover that file paths, database names, and passwords are hard coded into many source files. You halt work during the move because you don’t want to overwrite the configuration changes the migration entails. The estimated two hours becomes eight as it is revealed that someone did something clever involving the Apache module ModRewrite, and the application now requires this to operate poperly.

You finally launch phase 2, and all is well. All is well for a day and a half. This first bug report comes in as you are bout to leave the office. The client phones minutes later to complain. Her report is similar to the first, but a little more scrutiny reveals that is is a different bug causing similar behavior. You remember the simple change at the start of the phase that necessitated extensive modifications throughout the rest of the project.

You realize that not all the required modifications are in place. This is either because they were omitted to start with, or because the files in question were overwritten in merge collisions. You hurriedly make the modifications needed to fix the bugs. You’re in too much of a hurry to test the changes, but they are a simple matter of copy and paste, so what can go wrong?

The next morning you arrive at the office to find that a shopping basket module has down all night. The last minute changes you made omitted a leading quotation mark, rendering the code unusable. You fix the problem, mollify the client, and gather the team for another day’s firefighting.

This everyday tale of coding folk may seem a little over the top, but I have see all these things happen over and over again. Many PHP projects start their live small and evolve into monsters.

Because the presentation layer-the PHP pages containing HTML-also contains application logic, duplication creeps in early as database queries , authentication checks, form processing, and more are copied from page to page. Every time a change is required to one of these blocks of code, it must be made everywhere the code is found, or bugs will surely follow.

Lack of documentation makes the code hard to read, and lack of testing allows obscure bugs to to undiscovered until deployment. The changing nature of a client’s business often means that code evolves away from it original purpose until it is performing tasks to which it fundamentally unsuited. Because such code has often evolved as a seething intermingled lump, it is hard, if not impossible, to switch out and rewrite parts of it to suit the new purpose”

There is good news though, it’s actually relatively easy to build an application using a solid framework and avoid these kinds of problems. It’s definitely much easier than dealing with nightmarish scenarios. It does take some extra effort at first, and good planning, but the result is all around satisfaction with nobody feeling that time or money has been wasted.

Many galleries have a page of thumbnails that you click to get a popup with the full size image. These are not very user friendly unless there are previous and back links in the popup. I think it’s even better to have the full size image replace the thumbnails in the main window in order to avoid opening extra browser windows.

With small galleries the thumbnails and large version could occupy the same window. In that case you could just rollover the thumbnails to see the large image (like we did on the L&O and Katered Kanines projects), though this will make the whole page load more slowly since you need to preload all the images so that the rollovers respond quickly. With these projects the large images aren’t very large so it’s not really a problem.

If you’re going to use next and back links it really helps if the next link always appears in the same spot so the user can keep clicking without moving the cursor and page through all the photos very quickly. Another thing I saw recently that was really sweet and simple is setup so the user can just click on the photo itself in order to see the next one.

There are some fancy galleries that include an automatic slideshow feature with pause and play buttons. I personally don’t like these. I’d rather just click through each image. The internet is all about interaction, not just sitting back and watching and there are some photos you want study for a few minutes and some you want to click right past. These kinds of galleries also usually have fade in and out effects which I can incorporate into any kind of gallery, not just a slideshow, if the client feels they really need that extra slickness. The fade in and out are not too distracting in my opinion and are appropriate for certain kinds of sites.

An automatic slideshow can have it’s place also, but the only place I really see these working is on a home or portal page, where there is other content for the user to browse while one section has a slideshow of current articles, or advertisers, to catch the users eye.