Festival Explorer started as a map.
That sounds obvious. Festivals have maps. You arrive, you want to know where the stage is, where the bar is, where the toilets are and, with increasing urgency as the day progresses, where you left everybody.
So: map.
Except the more I worked on it, the less I was drawing a map and the more I was building a way into the festival's actual data.
That sounds like a small distinction until you build around it.
Then it changes almost everything.
A picture of a place is not the place
Festival maps are often illustrations, and there is nothing wrong with that. In fact, I like them. A good illustrated site map can be much more useful and much more in character than dropping a generic road-map style underneath an event and covering it in pins.
But artwork and geography should not become the same thing.
I wanted the things shown in Festival Explorer to have real coordinates underneath them. A stage should not merely be an icon that somebody placed where it looked visually balanced. It should correspond to a real position. The same goes for an entrance, a zone, a facility, a vendor or a route.
Once that is true, the presentation can become much freer.
A stage can be drawn as a tent, a huge structure, a hand-painted block or, if all restraint leaves the room, an enormous purple mushroom.
The artwork can change.
The place does not.
That separation — presentation above, spatial truth below — ended up being much more important to me than the visual treatment itself.
Then the stage started knowing things
The point where the idea really changed was when I stopped thinking of the stage as a point and started thinking of it as a place already connected to everything else Music Kite knew.
A stage has a location.
It also has a schedule.
A vendor has a location, but it may also have a profile, opening information or other event-specific context.
A festival area can be a visual shape and still be a real object that contains other things.
A facility can appear in the artwork without being baked permanently into the artwork.
And because the event schedule already exists elsewhere in the platform, Festival Explorer does not need to invent another copy of it simply because the user is looking at a map.
That is where the feature stopped feeling like mapping.
The map had become another way to ask questions of the product.
Where is this?
What is happening here now?
Who is playing here later?
What is nearby?
Which area contains this place?
Those are not really drawing questions.
They are event questions with a spatial answer.
The value is in the relationship
I get quite excited when a contained technical solution connects to something that already exists elsewhere in a system.
Festival Explorer did that repeatedly.
What mattered was not putting objects on a background image. It was connecting the same underlying location to schedule data, performers, vendors, facilities, areas and other live information.
I remember looking at the direction of it and thinking: this is going to be a game-changer. It's going to be amazing.
That is considerably more enthusiastic than my normal software vocabulary, which tends to peak somewhere around “pleasing”.
But there was a genuine conceptual shift.
I thought I was building a navigation feature.
I was actually giving the rest of the product a relationship with physical space.
People make location much more serious
Then you add people.
Once a device knows where somebody is, it becomes technically easy to imagine putting them on the same surface.
Technically easy is not the same thing as sensible.
An identifiable person's exact location is personal data. The useful version of a location feature is not “Music Kite tracks everybody at a festival”. That would be dreadful.
The useful version is narrower: somebody deliberately chooses to share their position with an authorised person in the appropriate context, and that person can understand where they are relative to the same site.
That means consent, audience and privacy have to be part of the architecture before the little dot becomes attractive on screen.
The renderer should not get to decide who is allowed to see the data simply because it knows how to draw it.
Again, the relationship matters more than the picture.
I nearly let the visible thing own the system
Maps are particularly dangerous from an architecture point of view because they are impressive.
You move something. Draw a boundary. Animate a layer. Add depth. Suddenly the visual system feels like the feature itself.
It is very tempting to let the renderer become the place where truth lives because that is the bit everybody can see.
I do not want that.
The spatial model should exist independently of whichever map or scene happens to render it this year.
Festival Explorer can use calibrated artwork and a bounded event scene. A wider geographic discovery map can use a completely different renderer. Both should still agree on where the underlying place actually is.
That separation has a very practical benefit: I can throw away a visual experiment without throwing away the geography.
I have thrown away enough experiments to appreciate any architecture that makes that cheap.
Festivals are temporary geography
A festival is a strange mapping problem anyway.
It is not quite a town, not quite a building and not quite a normal outdoor map.
It appears.
A field becomes a neighbourhood. A tent becomes a destination. A temporary gate becomes an entrance everybody needs to understand. A row of traders becomes somewhere people arrange to meet. Paths move. Areas open and close. Stage names mean everything for a few days and almost nothing for the rest of the year.
It is temporary geography.
That is another reason I like bespoke presentation for it. The map can exaggerate the things that matter. A stage can have personality. Temporary structures can be shown clearly without pretending they belong on a permanent world basemap.
But the fun presentation still has to stay aligned with reality underneath it.
Otherwise you have an illustration pretending to be navigation.
A map becomes an interface when position starts answering questions
I think the point where a map stops being merely a map is when the position itself becomes a route into other information.
If all I can do is look at a marker, I have a map.
If the marker represents a real place, can tell me what is scheduled there, connects to the artist playing there, understands which area contains it and can participate in private location rules, then it is doing something broader.
“Spatial interface” sounds slightly grand, which is usually a warning sign, but it describes the shift reasonably well.
The map is not the source of truth.
It is one way of seeing and interacting with truth that exists elsewhere.
That gives the design a lot of freedom.
Festival Explorer can feel like the festival rather than a generic mapping product wearing a wristband.
A wider discovery map can behave like a proper continuous geographic surface.
And both can still agree on where the stage is.
I thought I was solving the wrong category of problem
This is the bit I enjoy most about building things.
You start with something that has an obvious category.
“We need a festival map.”
Fine. Build a festival map.
Then you get far enough into it to discover that the category was hiding the real problem.
The problem was never really drawing the festival.
It was connecting the product to physical space in a way that stayed useful even when the drawing changed.
That is why this feature held my attention after I understood the implementation.
The first answer made the room bigger.
I thought I was building a map.
I ended up building another way for Music Kite to understand place.