Salle Pleyel

Project management – UX design – Front-end development

The latest redesign of this prestigious concert hall’s website.


The historical Salle Pleyel in Paris was given to manage by the Ministry of Culture to the Cité de la musique in 2006 after complete renovation.
In 2013, it meant 226 concerts to produce and sell tickets for, and with a prestigious hall that hosts internationally acclaimed artists and orchestras, the biggest challenge here is to facilitate sales within highly constrained timeframes.

As usual, we developed internally the website, but the graphic design was from Mosquito.

Interesting facts about this project

Subscriptions from hell

When you manage a website like this one, you face fanatic customers.
We are selling concert tickets but also seasonal subscriptions. And the later sell fast, especially the cheapest one for young adults.
But selling those online is very tricky:

  • first, you don’t want to give away all the seats for very prestigious (and expensive!) concerts to the subscriptions, so you have a quota
  • still a lot of people want them and will be there waiting for you to open the sale, at the booth and online
  • you have to guarantee the seats to the users while they are making their selection (and with over 200 concerts to choose from, this takes time, even when they already know what they want, because there might already be reached quotas)
  • lastly, you will face upset customers because they will not all get what they want

Of course, we have a vendor who is in charge of our ticketing system, Secutix, and it’s not a small one. They even got the gig to sell the tickets for the next European soccer championship in 2016.

Still, until 2014, they couldn’t manage the subscriptions online.

So, Xavier Cognard and I, had to come with something for the sales team. Let’s be clear from the start here: they did the heavy lifting, but all together we figure out something with our own resources.

It basically meant that on a given day, customers would rush on a page to make wishes for their subscriptions. Yes, wishes, because we couldn’t guarantee the seats: we didn’t have access to the ticketing system. So we would make customers select concerts in a form and then send their request as an email to the sales team. Meanwhile, we would monitor the demands and close subscriptions for concerts as the day went by.
The next day, the requests were treated chronologically and the team had to call back the customers if their wishes couldn’t be granted. How I didn’t want to do that job.

Still, with a system that you could find almost too simple and servers that are all managed internally, we were able to sell and to sell a lot.


I developed this carousel after the graphic concept of Mosquito. I considered it like a necklace: each concert is a pearl sliding on a string.
Each pearl position is calculated from the angle with the ellipsis, plus a size to simulate the depth along with a z-index to manage which pearl is in the front of the others and finally an alpha value for transparency.
(I even put the shape and orientation of the ellipsis as variables, just in case, but never had to change it or reuse it)
The information and image displayed in each pearl was integrated from an XML file generated dynamically, piece of cake!

At first, the carousel is supposed to show you the next event.
Except if that concert is not the highlight of the day OF COURSE.
Again, we had a general rule and exceptions, so if the next event was not that important (sorry but I’m not making the call here little pearl) the carousel would automatically slide to the next “important” concert.
Dirty little secret right there.

Finally, a struggling little UX problem: you have arrows on the left and right of the page to browse the carousel. Which arrow are you going to click to get to the next concert? The left arrow, because you want the carousel to rotate this way, or the right because you want the next right pearl to be on top?
Experience and user testing showed me that there’s no right answer to this question: some people think one way, some the other.
At one point, I even thought about determining the action of each arrow by the first one clicked, but it would have been quite weird, right ?


The home page tag-cloud is made in Flash with Actionscript 3. The words are chosen every beginning of the season by the head of communication and reflect a certain image of the upcoming events.
For some diplomatic reasons, the tag-cloud has to be randomly reconstructed every time you load the page, so certain words are bigger or smaller each time and the beauty of it is that: random is fair.
Well, that’s the theory.
Practically, things are a bit different: color and place are random but putting a tag like “Pop” to a size 42 will not result to the same size as the tag “Orchestre de Paris”. So I had to come up with an algorithm that would give a random number between limits depending on the number of letters in the tag.

The second problem was placing the tags in the cloud. I used a strategy that is usually used in video games: the cloud is actually a very simple tile-based game.
The first tag begins its journey at the top left of a rectangular zone. It goes down a tile at the time if it can, then it goes right, again a tile at the time until it can’t any more because it’s touching something else, then stops. The second appears at the top left and so on…
I also had to define invisible obstacles so the words won’t appear on the logo on the right, or on the carousel.
A nice little example of object-oriented programming.

Technical specifications

This website was made with HTML, CSS, Javascript, jQuery, Flash (Actionscript 3) and ASP.NET.
The information system behind it is our home made champion Euterpe.

Some screenshots

A quick update

This website was recently replaced due to the opening of the Philharmonie de Paris in January 2015. It’s a €400+ million project, including a philharmonic concert hall and exhibition spaces, and I was part of the team that designed its digital presence, but that’s a different story…