How is built this photo blog?

This article will cover a little part of what happens behind the scene of Lanuit.Paris

• Which tools, skills, knowledge are needed?
• Which choices, directions linked have been taken and why?
• Is this a suitable strategy for your project?

It will try to cover the global vision of this project and the main development principles I’ve applied.
A vision to link photography and internet technologies dedicated to “content” websites.
Everything is not necessary relevant for your situation. It depends on your context, needs and roadmap.

Some statements could appear extreme or describing situations as caricatures. I did it on purpose. I’ve tried to enhance contrasts to support my message.

This article is a bit technical.

Best practices, photography and user experience at the core

Lanuit.Paris, is based and built on top of two pillars with respective sets of skills, techniques, and tools:

• Photography
  • Being able to capture and create beautiful pictures using adequate camera/hardware
  • Use standard softwares (LightRoom/DXO, Photoshop or Gimp) to edit and retouch when needed
  • Read documentation. Be inspired by the work of others. Explore.
• Publish content on the the Internet:
  • Publish and share high-quality photographies and content
  • Create a performant website for the visitors, quick, widely compatible (smartphone, tablet, computer)
  • Build a website in a flexible way, easy to maintain and modify
  • Use adpated and up-to-date tools and technologies which fit the needs
  • Follow the best practices on all level (technical, seo, etc)
  • Grow an audience

An anti-logical method to build the project

The most common way when you start from scratch and to build a blog like this is to shortlist and select a framework that provides the maximum of features you could imagine. To be sure to be covered, for the future. To not miss a thing.

Starting from a solution “out-of-the-box” and assuming it will fulfill magically, without any effort, your needs, and follow the standards. Choosing the the silver bullet and preferably for free.

I did the exact opposite (except for the free part).
I’ll try to explain why and how.

Work and build iteratively. Tackle complexity step-by-step. Learning while building

This website is basic and does not embed any specific intelligence.

It’s does need any e-commerce feature or a complex application that needs computing on an application server.
This does not need a “dynamic” backend in Php, Java, .Net, Go, NodeJs.

Instead of starting from a fully integrated solution and use 5% of the super-power, I decided to start from a minimal scope of features that I can manage safely and make it grow.

For those reasons, I decided to not use Joomla, Drupal, WordPress even if they had some core features that could fit my actual needs.

My technical goals and constraints were the following:

• a canvas, layout, modern and flexible “templating” (standard, open-source, responsive, mobile first)
• a flexible tool to manage URLs, taxonomies, categories, tags, a multilingual version
• having the capacity to obtain an immediate feedback, being able to test and measure impacts of my modifications locally on a standard laptop
• being able to push to production from a standard version control software (CVS)
• use standard mechanisms from version control softwares to rollback (version N-1) in case of problem
• being independant from a specific infrastructure, operating system, complicated technical components, framework to maintain and update
• Don’t manage an N-Tier architecture, launch the project locally exactly the same way (tools, versions) as in production (systematic approach)

Instead of using a system that needs to be installed, and most of the time relies on a database I used a different solution and approach based on GoHugo: a static site generator.

No database, no module to install: text files, images and folders

GoHugo is a lightweight application, easy to setup and run. It’s available on all platforms Windows, Mac OS and Linux.

The architecture of a project does rely on text files (configuration, template and content) and directories only.
The tool is coded in GoLang but no speficif skill or knowledge of this language is mandatory to use and run it.

The “templating” language does use a specific syntax that requires a couple of days to learn and practice.

The documentation is clear and straightforward. The main principles are clearly detailed. The forum and community are active and helpful.

All the sources are fully accessible in text files, a simple text editor is needed. Colored syntax is a plus.
Many free softwares are available. I use “Visual Studio Code”.

You can guarantee the security of your entire project and sources by using a control version software (Git for example).
This way it’s easy to modify the code, test, compare, make mistakes, rollback.

The generation chain is fully transparent and totally deterministic.
You have a total control on the render of your website.
Without surprise, you’ll find your modifications in the final code and on the screen.
It does take less than one second to generate a blog like thine one (approx 400 pages) and 1 minute to put it online.

The result of GoHugo’s execution is a full internet website statically written.
It can be hosted by a majority of technical hosting partners using standard softwares and packages.
I use Netlify to host this website.

In this scenario, features are not directly packaged and plug-and-play

You cannot click and install functional features in a control panel like carousels, rollover, contact forms.
You’ll need to learn to find, select basic bricks to build your own LEGO.
You’ll need to build a set of basic techincal skills. The difficulty is moderate.

For example, you’ll have to:

• understand and follow SEO recommendations
• know how to build an efficient URL
• use the correct hierarchy of titles in HTML (h1,h2,h3)
• understand media-queries to load efficiently your images on mobile phones

It’ll be up to you to follow best practices in HTML, CSS and maybe Javascript.
Many sources of relevant documentation and tutorials do exist to help you.
You’ll have to follow the impact of your latest modifications in LightHouse (performance indicators), be careful to the weight of your pages, etc…

You’ll be in a position where you’ll have to understand in detail what you build and put the focus on constraints that have a direct impact on your project.

Is it more or less efficient to do all of this than using a solution “out-of-the-box”?

It depends on how you want to spend your time and energy.
Magic solutions, running by themselves do not exist. One time or another, technical skills will be needed,simply because they’re (hidden) part of your product.

Let me give you some insight and talk about real implementations based on IT experience

I used extensively CMS frameworks (WordPress, Drupal, Joomla) during the past years (project implementation, maintenance, module development, migrations).

The maintenance part dedicated to the integration of a framework is always underestimated.
Either you want it or not, you’ll have to take external constraints in consideration and manage technical specificities that are not necessarily aligned with your goals.
By definition, often afterwards.

Examples of questions I had when I decided to create this photo blog/site:

• Why should I understand how to administate and update a database when my focus should be to create beautiful pictures and improve the user experience?
• Do I need a database technical component to create a catalog of images embedded in Internet pages?

You’ll notice that modules are interesting but can become incompatible between them after multiple upgrades. They can simple abandoned as well.

You’ll notice that your system does become obsolete quickly if you don’t take care and keep up the rhythm.

You’ll notice that the way “the developer” thought the system, the template, the module does not fit entirely with your constraints, ideas.
In order to make this more suitable for you, you’ll need to modify it.
And to modify it, you’ll need to understand code patterns, follow code standards linked with the framework you use, maybe rewrite an entire module.
All of this, often, without any easy way to test before the production. Most of the time you don’t have a stage/test platform.

You’ll have to invest time and energy in a painful process. Most of the time, it’ll be frustrating.
The “But why, does not it work like that? It’s not logical” syndrom will reach you.

You’ll need to invest time and energy in domains or actions you have not identified as part of your critical path.
You’ll have to modify your project, twist and adapt your needs to fit the framework capacities.

This customization can also be a concern when you use a platform like wiz.com, 500px.com, duda.com or slickpic.com.

Depending on the level of customization you would like to have, you’ll need to ask for a quote or subscribe to additional services.
The question of “do it yourself” versus “order custom development” and the cost linked with it will take an important place.

The more technical layers you add (products or partners) in your project, the bigger is the place for uncertainty, hidden parameters and impacts that you don’t directly manage.
Leading to a paradox: a lack of flexibility.

The conclusion of all this is that in both scenarios, you’ll need to choose on how to to invest your time, energy, or money and which skills or knowledge you need to acquire or improve to release your project.

Choose your battles, focus your efforts on what does really matter for you!

In my example, my project is simple.
I made the choice to be as closest as possible to the product I need to publish.
I tried to avoid intermediates (partners and frameworks) and GoHugo seemed to be a good choice so far.

We talk here about basic layers and bricks of the Internet: HTML, CSS, Javascript, image format.
This is the case for a majority of blogs online nowadays.

Many pieces of code (“snippets”), examples, tutorials are freely accessible on W3Schools or HTML5UP!

Most of the time, a copy/paste is a good start to both create, test and move on step-by-step.
The path between the prototype and the final product can be short if you decide to go on iteratively.
Iterations between releases can be small and quick.

If one day the scope does grow. If more advanced features are needed, like an authentication page, a cart a checkout, it’ll be the time to find adapted solutions.
The idea is always to make it grow step-by-step and add the only mandatory level of complexity linked with the new constraints.

Is it not slower and less performant to adopt such a strategy?

I’m not sure about that.
It depends on your resources (time, money) but not only.
I’ve always thought that “learning” was part of the journey.
Keep a capacity to learn and adapt are important components in a project.
It’s more valuable to handle a smaller perimeter and ask relevant questions to make it grow.
More little steps, more often is more secure than a giant step coming with a lot of uncertainty.

If you have questions, if you would like to discuss about this article, about this project or about your project, feel free to send an email to photo@lanuit.paris