I have spent a lot of time building this application.
At first, I thought of it primarily as a website.
Pages had to work. Navigation had to work. Images had to load. Forms had to submit. The database had to return the right information.
But somewhere during the process, the project became something larger.
I realized I was not simply building pages.
I was building a publishing system.
And more importantly, I was building a place where different parts of life could remain connected.
From a website to an application
There is a point in almost every serious web project where the distinction between a website and an application becomes obvious.
A website can be a collection of documents.
An application has relationships.
Users.
Authors.
Posts.
Stories.
Articles.
Media.
Tags.
Search.
Profiles.
Authentication.
Analytics.
Discovery.
All of those pieces have to work together.
That is what Wildwood gradually became.
The technology underneath it
The application is built on technology I know well and enjoy working with:
- ASP.NET Web Pages
- Razor v3
- WebMatrix.Data
- SQL Server 2017
- Stored procedures
- Parameterized SQL
- Structured media and tagging
- Server-rendered HTML
It is not the newest stack in the industry.
That has never bothered me.
Technology becomes valuable when you understand it well enough to make it do what you need.
I know how Razor behaves.
I understand the database.
I can follow a request from the browser through the page, into a stored procedure, through SQL Server, and back into the interface.
That level of visibility matters to me.
The database became the backbone
One of the biggest changes in the application has been the evolution of the database.
Early versions of a project can survive with direct SQL scattered through pages.
As an application grows, that becomes harder to control.
I began moving more responsibility into stored procedures and establishing clearer contracts between Razor and SQL Server.
Instead of every page deciding independently how an Article should be retrieved, there is now an Article procedure.
The same is true for Stories.
The application now has procedures for creating, retrieving, updating, deleting, publishing, tagging, and counting engagement.
That may sound like an implementation detail.
It is actually one of the things that made the application begin feeling coherent.
Posts, Stories, and Articles needed to become different things
One of the most important architectural decisions was separating Posts, Stories, and Articles.
Originally, it was easy for those concepts to blur together.
A post could become long.
A story might be displayed like a post.
An article could end up using fields designed for something much shorter.
Eventually I decided each format needed its own purpose.
Posts
Posts are immediate.
They work well for photographs, observations, updates, short essays, and moments.
Stories
Stories are more personal and narrative.
They have room for experience, memory, perspective, and a beginning that can lead somewhere.
Articles
Articles are structured long-form work.
They can explain, teach, document, organize information, and explore a subject in greater depth.
Once those became separate systems, the rest of the site began making more sense.
Long-form publishing changed the application
Adding dedicated long-form fields was another turning point.
Stories now have a short Excerpt for cards and discovery while the complete story lives in BodyContent.
Articles use a short Description for summaries while the full article also lives in BodyContent.
That sounds obvious in hindsight.
It solved an important problem.
The display copy no longer has to carry the entire story.
A homepage can remain concise while the underlying content can be as substantial as it needs to be.
HTML became part of the publishing model
I also wanted long-form content to be capable of real structure.
Not just one enormous block of text.
Headings.
Paragraphs.
Lists.
Blockquotes.
Emphasis.
Sections.
That meant allowing HTML inside long-form content.
The database stores the complete markup, and Razor renders the trusted content as part of the article or story page.
That gives me a much more useful publishing system than a simple text field ever could.
The homepage had to evolve too
As the content architecture changed, the homepage could not continue treating everything as a Post.
The new homepage can pull a genuine published Story for the lead presentation.
It can surface Stories as Stories.
Articles can appear in their own discovery area.
Posts can remain the faster social and photographic stream.
That distinction makes the homepage more editorial.
It also makes the application more honest about what each piece of content actually is.
Discovery became its own problem
Once there is enough content, publishing is only half the problem.
The other half is helping people find something worth reading.
That led to work on:
- For You
- Trending topics
- Tags
- Contributor discovery
- Search
- Recent media
- Featured Stories
- Featured Articles
I wanted discovery without turning the site into visual chaos.
That has been one of the recurring design goals.
Show enough.
Do not show everything at once.
The interface became quieter
The visual design has changed repeatedly.
I experimented.
I removed things.
I reduced font sizes.
I simplified color.
I moved toward white backgrounds, stronger photography, cleaner editorial hierarchy, and less decoration competing with the content.
I wanted the interface to get out of the way.
The photograph should feel important.
The headline should feel important.
The story should feel important.
The interface should support those things rather than demand attention for itself.
Then the branding started changing
The technical work eventually created another question.
What exactly was I building?
A tree site?
A personal publishing platform?
A photography site?
A journal?
A social application?
An editorial publication?
The answer turned out to be that it could contain pieces of all of them.
But it needed one idea large enough to connect them.
That is where the new branding began.
LIFE.
The word is intentionally simple.
LIFE.
It is difficult to find a subject broader than that.
Life includes technology.
It includes people.
It includes trees.
It includes health.
It includes work.
It includes grief.
It includes recovery.
It includes photographs.
It includes places.
It includes everything we build and everything that changes us while we are building it.
That made it the right word.
The red thread
The red thread became the visual language connecting the idea.
A thread is simple.
But it can carry a lot of meaning.
It connects one point to another.
It can disappear around a corner and still continue.
It can become tangled.
It can stretch.
It can cross enormous distances.
And sometimes you only understand where it has been when you look backward.
That feels like life to me.
LIFE. A longer story ahead.
That became the central statement.
People. Ideas. Places. Stories.
The supporting language came naturally:
People.
Because people are ultimately what make stories matter.
Ideas.
Because a platform should create room for thought, learning, experimentation, and disagreement.
Places.
Because place becomes part of memory and identity.
Stories.
Because stories are how we connect those things across time.
And then the line that connects them:
People. Ideas. Places. Stories. Always connected.
Same thread. Different horizons.
This may be my favorite part of the new identity.
Same thread. Different horizons.
The application can change.
The subjects can change.
The people can change.
The visual style can evolve.
The technology can eventually evolve.
But there can still be continuity underneath it.
The same thread.
The branding mirrors the architecture
That is what makes this more interesting to me than simply creating a logo.
The branding actually mirrors the way the application works.
A photograph can become a Post.
A Post can lead someone into a Story.
A Story can introduce an idea explored more deeply in an Article.
An Article can connect through Tags to another subject.
A Tag can lead to another contributor.
A contributor can lead to another photograph.
Everything can connect without everything becoming the same thing.
That is exactly what a thread does.
Building it has meant rebuilding it
Another thing I have learned is that software rarely emerges fully formed.
I have rebuilt pages I thought were finished.
I have changed database schemas.
I have changed stored procedures.
I have removed layouts that once seemed like good ideas.
I have rewritten navigation.
I have changed routes.
I have encountered compiler errors, SQL dependency problems, column-length problems, and database assumptions that turned out to be wrong.
That is not evidence that the project failed.
That is software development.
The application becomes better because each problem exposes another assumption that can be improved.
The new database schema is part of that maturation
The newer database structure represents that progression.
Stories have their own CRUD procedures.
Articles have their own CRUD procedures.
Long-form bodies are separated from summary fields.
Published timestamps are explicit.
Engagement counters have defined places.
Tags have dedicated relationships.
Pages call stored procedures with known contracts rather than reinventing the query every time.
That gives the application a much stronger foundation for whatever comes next.
Authentication and analytics evolved too
Even the less visible parts of the application have changed.
Authentication now runs through a defined verification procedure rather than letting individual pages decide how credentials should be checked.
Visit tracking has moved toward a persistent visitor identity rather than treating every request as completely unrelated.
Those are not things most readers will ever see.
They are still part of building a real application.
I want the platform to feel human
This matters more to me than any particular technology.
I do not want Wildwood to feel like a database wearing a website.
I want it to feel human.
Someone should be able to arrive because of a photograph and discover a story.
Someone should be able to arrive because of an article and discover the person who wrote it.
Someone should be able to follow an idea through several different formats.
The technology should make that possible without continually announcing itself.
Photography is central to it
The new branding also reflects how important photography has become to the project.
An image can introduce a story before a reader has processed a single sentence.
It can create mood.
It can give a page identity.
It can hold meaning that does not need to be explained completely.
That is why the newer design gives images more space.
The visual language and the written language should support each other.
Why this image represents the project
The image accompanying this article brings many of those ideas together.
There is a monumental spool of red thread.
The thread runs from my hand through a long architectural space and eventually toward the horizon.
The words are simple:
PEOPLE
IDEAS
PLACES
STORIES
ALWAYS CONNECTED
And then:
LIFE.
A LONGER STORY AHEAD.
SAME THREAD. DIFFERENT HORIZONS.
That is more than a campaign image to me.
It is almost an architectural diagram of what I want the application to become.
The platform does not have to choose only one subject
This was another important realization.
A publication does not have to reduce a person or a community to one subject.
I can write about software.
I can write about recovery.
I can write about trees.
I can write about photographs.
I can write about people I have loved.
I can write about something I learned yesterday.
If there is an underlying perspective connecting those things, they can belong together.
The thread provides that continuity.
The site is becoming a record
The longer I work on it, the more I think of Wildwood as a record.
Not simply a feed.
A record of people.
A record of ideas.
A record of projects.
A record of photographs.
A record of things learned the hard way.
A record of change.
That is one reason I care about building the database correctly.
The content should survive redesigns.
The application may change completely someday.
The stories should remain.
Software is temporary; the content should not be
This is a useful distinction.
Layouts are temporary.
CSS is temporary.
Frameworks are temporary.
Even database technology eventually changes.
Content can outlive all of those things.
A strong publishing architecture respects that.
It stores the story independently enough that another interface can present it years later.
That is increasingly how I think about the platform.
There will always be another version
I know myself well enough to know this is not the final design.
There will be another page I want to improve.
Another query I want to simplify.
Another stored procedure I want to tighten.
Another layout I want to rethink.
Another idea I have not had yet.
I used to see that as evidence that the application was unfinished.
Now I see it differently.
A living application should be unfinished.
It should continue changing because the needs around it continue changing.
A longer story ahead
That is ultimately why the new statement feels right.
LIFE. A longer story ahead.
It applies to the application.
It applies to the brand.
It applies to the people who will eventually contribute to it.
And it applies to me.
This project contains pieces of where I have been.
But it is pointed toward what comes next.
There are more photographs to make.
More pages to build.
More stories to write.
More people to meet.
More ideas to explore.
More places to see.
More mistakes to make and fix.
More versions of this application that do not exist yet.
That is not unfinished business.
That is the future.
The statement
LIFE.
A longer story ahead.
People. Ideas. Places. Stories.
Always connected.
Same thread.
Different horizons.
That is the new brand.
But it is also the simplest explanation I have found for the application I have been building.
Different kinds of content.
Different moments.
Different people.
Different horizons.
One continuing thread.
