Create a Website for a Photographer

Today, I am going to write about my project to get SeeShoot.com off the ground. It is a bilingual website to promote myself for photo gigs, and to promote those around me.  In general, I want it to be a useful site.

I had started using a free website and free-software product called “heritage.io”. I found that to be both in line with my philosophy, my technical approach, and my needs. I had also used Picassa and Flickr.  These public services are handy.  Somehow they do still leave me reticent.

I am starting from a blank HTML site I wrote to get the basic idea off the ground.  This original website is visible here : http://www.seeshoot.com/old/. This website had the following sitemap in English and in French with skeletal content:

  • Portfolio
  • Serivces
  • 3D
  • Links
  • Contact

I had then perused multiple websites for a template to reuse and found one called “Aurius” to my liking [1].  The Aurius template has a sitemap of Portfolio, Blog, Contact, About (and Home).  I had spent time building a portfolio of portfolios on this template, but fell victim to the content suggestions behind it, losing sight of the content that was important to me.  The template also suggested a lot of social media presence I simply do not have for this activity.[1][http://templatecreme.com/list/aurelius/](http://templatecreme.com/list/aurelius/)

Well I first had published the website in English.  I was more keen on publishing other photographers’ photos than my own.  I noticed I was both working my needs to the template and my template to the needs.

I had the logo made by a very competent professional from fiver.com.  It integrated well into the template, although the horizontal space at the top seems a little to much for my tastes.

As often is the case, I spent considerably time tweaking the CSS to my needs. The template had movie-sided images, and I wanted square ones, etc. I had to make more horizontal space and find a solution in order to get the language link to show up.

Recently, I met up with a French business consultant Jean-Christophe Laleu. As an exchange of services, I was to help him get a web-agency activity off the ground, and Jean-Christophe was to help me with SeeShoot.com. I thought I was going to provide the technology know-how, and Jean-Christophe business insight. As it would turn out, Jean-Christophe may have helped me on the technology-side (unexpected to me).

My needs for seeshoot.com (some of these are to co-incide with the needs of the Teatime / On the Street Mag Club) are as follows :

  1. Publish photos in albums
  2. Re-arrange and rate photos
  3. Comment photos and manage comments on photos
  4. Manage with minimal work
  5. Manage with minimal computer usage
  6. Version work
  7. Integrate with existing website template
  8. Manage users and groups
  9. Manage access to items

So, I had put the following technological choices on the table (exclusively, or as a mix) :

  1. DjangoCMS
  2. DotCMS
  3. Pyramid
  4. WordPress
  5. LogicalDoc
  6. MoinMoin
  7. Refinery CMS
  8. Ruby on Rails
  9. Heritage

Jean-Christophe came back to me with the following suggestion :

  1. DjangoCMS
  2. Refinery CMS & Ruby on Rails
  3. WordPress

My programming environment was Apache SSI (Server-Side Includes) of PHP files. This is a simple technology where the filenames end in “.shtml.”  My goal was to start modestly, and add technology as needed. I would take the template files and add tags such as <!—#include virtual=”/some/file.php?var=val” –> in the .shtml page and program anything dynamic in the included PHP page. One advantage to this is that Dream Weaver can show transparently the include virtual calls.

I was confronted with two technical realities. First, PHP is messy. For example, I was reminded that including files was not straightforward (more than one way to skin a cat). Second, for PHP to be clean, one would need Zend Framework (or similar).  Zend Framework was too onerous for the current needs, especially because I was not sure I wanted to stick with the technology.

Jean-Christophe’s reasoning was interesting. Pyramid, a most beautiful and refined technology from my point of view, was seen as a “micro-framework” to Jean-Christophe. Django CMS, in it’s presentation on it’s website, was very impressive to Jean-Christophe. Jean-Christophe has experience in Refinery, and would perhaps like to use it in his own projects to come. WordPress is a standard.

I wanted to finish translating SeeShoot.com into French, and was confronted with the unexpected local architecture question of developing the multi-lingual part of the website in a DRY (do not repeat yourself) manner.

In my discussion with Jean-Christophe, the most viable option to me seems Django : the original Django Project — “for perfectionists with deadlines” — and not Django CMS. Django CMS is already a framework on top of a framework, and that does not reassure me. Python is still an elegant language. Django has endured the test of time. I also know a very good French web agency who does Django whose name escapes me right now. It strikes me as a robust, modular set of libraries I can use.

Even though we found the perfect solution on a medium-term viewpoint, the worst enemy I could face right now was changing technological solutions too rapidly. So, reluctantly, I decided to go the route of finishing what I started before embarking on the new technology. I need a current website in production before working on a new one.

Here is the solution I found:

  1. each language had its own subfolder (en and fr)
  2. the sitemap is the same in each subfolder
  3. common resources (non-localized images and photos) are at root folders
  4. each .shtml file either includes the /en/ or /fr/ version of the _header.php file passing a GET variable for the current section with for example <!–#include virtual=”/en/_header.php?page=blog” –>
  5. the _header.php file does HTML layout, includes a /include/classes.php file with Menu and MenuItem classes, and instanciates a Menu with the language specific local in a $menu variable
  6. _header.php uses the $menu object.

Well, half way though the development, I was afraid I was programming something that I would not keep, although it seemed elegant enough. The result was that I did not take care to document it. It works.

Putting the multi-language infrastructure in place incited me to translate it. SeeShoot in now in French and in English.

Back to business (needs), my goal is to obtain a photo gig for this New Year, and SeeShoot.com is not yet geared to help me to that end. Strangely enough, the old website was more helpful in that area. It seems as if I took one step back. To complicate things even further, it seems as if the old portfolio is no longer accessible. Here are the potential action items:

  1. transpose old sitemap onto new website
  2. transpose old web content onto new website
  3. find and republish old portfolio
  4. develop new portfolio
  5. publish a visible note with the request for a gig for a New Year’s event
  6. publish a page for the New-Year’s event prospection
  7. brainstorm for something of the best of the old and the best of the new
  8. move on the Django project for a new version of the website

And that brings me to today. There are two basic categories of effort : maintain the old website and develop the new underlying technology. If I learned correctly from the previous version upgrade of this website, I will go forward while better maintaining the good parts of this current seeshoot.com website.  With regard to my current predicament, I guess I will sightly revamp the new website with some of the old content and set up an events and portraits portfolio (with some video if I have the time and effort).