Confession: I actually don’t know why you need Symphony. I don’t even know who you are, or why you’ve got this book in your hands. Maybe your boss or your client is asking you to use Symphony for a project. Maybe someone’s built you a Symphony-powered website and you’ve got to learn how to run it. Maybe you’re a freelancer or a hobbyist standing in a bookstore and wondering if Symphony could be a helpful addition to your toolbox. Or maybe you’re an agency lead or project manager evaluating Symphony alongside other content management systems like Drupal or ExpressionEngine, or even frameworks like Django or Ruby on Rails or that homonymic doppelgänger of ours, Symfony.
Whoever you are, what I do know is that you’re probably involved in building or running websites or web applications, and there’s a good chance you’re wondering if, or how, Symphony can help you do it better.
There are tons of reasons to use Symphony. Well, maybe not literally tons, unless you etch each reason into the side of a cast iron bathtub. But if you work within an organization or corporation, for example, you’ll appreciate Symphony’s ability to conform to your own internal structures and workflows. If you run an agency, you’ll love being able to use the same system for every project, reducing build times, training costs, and other kinds of overhead. If you’re a designer, you’ll salivate over the control and flexibility afforded by Symphony’s standards-based templating layer.
Whoever you are, though, I think one of the most compelling reasons to use Symphony, one that really sets it apart, is actually not that easy to quantify or explain. It has to do with how the web is evolving, why you need to be thinking several steps ahead, and how Symphony’s unique philosophy and development approach make it a smarter choice with each passing day.
Maybe managing content on the web was never simple.
Or maybe my memory’s just hazy because the web wasn’t yet my profession and I didn’t fully understand it. I do seem to recall a time, though, when websites were essentially just made up of pages, and whether you ran a multinational corporation or a high school poetry club, the only real difference was how many pages you had… the pages themselves, the basic units of content, were more or less the same. You’d simply compose them and then post them for the world to see, like flyers in a shop window.
Granted, I’m no internet historian. But in my experience, managing content on the web today is a radically different kind of endeavor than it was eight or ten years ago. The web has changed, evolved, and so too has the content that comprises it. Whether you’re a freelance web developer, an agency, a hobbyist, or a corporate employee, what you need from a content management system today—and what you’ll need from it tomorrow—is changing just as quickly.
The web has come a long, long way since the days of serving mostly static pages. Along with the rapid evolution and increased capabilities of the web’s technologies have come significant shifts in the way we use the web in our everyday lives. Lots of attention has been paid, for example, to the shift from merely consuming information on the web to producing, repurposing, and interacting with content. It’s part of the broader phenomenon that has been labeled “Web 2.0.” But for all the hype behind the term, Web 2.0 is a signpost, not a destination, and our uses of the web have continued to evolve.
Today, we expect the web to be much more than simply “interactive,” we expect it to be intelligently so. When we post a video on Youtube, for example, we expect the web to do more than just display it. We expect it to be searchable, embeddable. We expect people to be able to comment on it, share it, add it to playlists, transcribe it, remix it, and so on. We expect the web to understand the content itself and how we want to use it.
Websites, on the whole, seem to have evolved along a similar path. As we seek more interactive web experiences, our websites have gone from being mere collections of pages—each corresponding to a static file on a server—to being dynamic, data-driven applications in their own right. It is not uncommon nowadays for even small websites to have rich interfaces for browsing and interacting with their content.
And websites themselves are only part of the puzzle. Today’s web is a landscape of multilayered ecosystems that go beyond websites, domains, or even protocols. Terms like “blogosphere” and “social web” come to mind—ecosystems that have to do with the nature of content rather than its origin or location. In fact, it’s even beginning to appear as though the web is outgrowing the browser itself. We now experience it as a platform that powers desktop applications, mobile applications, APIs, and much more, in addition to websites. We’re no longer talking about a virtual realm that we visit from time to time while sitting in front of our computers. The web is seeping into our lives, insinuating itself into other forms of media, entering public spaces, and taking over our phones, televisions, and other devices.
These fundamental changes—in the way the web is architected and in the ways we use it—are reflected in the changing nature of web content itself. For starters, the things we publish and share on the web are increasingly granular. The web is no longer made up just of flat pages, but of discrete objects like blog posts, videos, reviews, status updates, location check-ins, and the like. And because they’re inherently meaningful (rather unlike pages), these sorts of granular content have become the building blocks of intelligent interactions on the web.
Just think about how search has been transformed over the last few years. Where before search engines like Google and Yahoo simply crawled huge indexes of pages and spit back matching documents, they can now deliver content-aware search results that are far more useful. Type in a couple of airport codes and get flights and ticket prices. Enter the name of a household appliance and see matching products from stores all over the web. And it gets even more granular than that, with the spread of markup-enhancing formats for identifying discrete bits of information like phone numbers, addresses, ratings, and more. The more intelligent the web becomes, the more useful it is to break content down into these finer and finer bits. In fact, many observers see in this trend the web’s next signpost. “Web 3.0,” they say, will be a semantic web in which ever more meaningful data is infused into the content itself.
And the more granular and meaningful content is, the more portable, too. As the web extends itself beyond websites and even beyond browsers, content is increasingly likely to be used and consumed outside of the context in which it was created. Web content today is not just disaggregated, it’s truly diasporic. On the one hand, we’re publishing more content in more places—Facebook activity, Flickr photos, Gowalla or Foursquare check-ins, Last.fm playlists, and innumerable comments, “likes,” votes, and so on. On the other hand, we’re also seeing our content disseminated far beyond our own reach and the reach of our traditional websites. Our Twitter updates are being pulled into all sorts of applications and devices, and are even being printed in books and on t-shirts. Our blog posts are being read everywhere from feed readers to Kindles. Our podcasts are being loaded onto mp3 players, and our videos are streaming directly to television sets. Wherever you look, you can see that web content is powering much more than websites these days.
Naturally, the tools we use to manage that content are evolving as well. Content management systems themselves were born in the era of the page-based web. Their job was to enable you to quickly and easily update your website’s pages and publish them. In fact, you can see traces of these origins in many CMS user interfaces today, their appearance and behavior still mimicking those of desktop file browsers. As the web has evolved, though, we’re asking our CMSs to do much more than update and publish static pages.
We’re asking them to manage all kinds of new content. One very obvious example is the blog post, and several new content management systems have actually been built (and continue to be built) for this very purpose. But our web content needs are many and varied, and are expanding rapidly every day. Creative agencies are managing things like portfolios, inquiries, and testimonials. Corporations are managing staff profiles, annual reports, press releases. Publications have got authors, issues, articles, and even artwork. And these are just three fairly simplistic examples. Then you’ve got online stores, NGOs, political groups, universities, doctor’s offices, governmental bodies, sports teams, book publishers—the list goes on and on (and on)—all with their own unique content needs. And we individuals may have the most diverse needs of all. We’re managing everything from writing and photography to family trees to recipes and reading lists and travel itineraries and beyond. And even when we use purpose-built tools or services to manage our most specialized content, we’re still very often asking our CMSs to work with it in some way.
We’re also asking them to do more than publish our content onto static websites. We’re asking them to power interactions. Even the simplest websites these days are often browsable and searchable; they’ve got content archives, category views, and RSS feeds. They accept comments, votes, and ratings. We want our CMSs to be able to facilitate a sort of conversation with our users, to guide them along specific journeys, to allow them to create and manage their own pieces of content, and to remember them and what they’ve done.
Finally, we’re asking CMSs to integrate with the myriad other tools and services that we use on the web. We want them to post tweets when we add content, or to pull from the streams of activity we’re generating around the web when we listen to music, share photos, bookmark websites, and so forth. We want them to allow us to interact with web feeds and APIs. In short, we want them to think beyond themselves. We want them to help us manage our content on the web as it is becoming, not the web as it was.
Obviously, even for the most ingeniously-engineered and forward-thinking content management systems, the challenges are many.
To begin with, if the web’s content is becoming increasingly granular, CMSs need to be able to handle all kinds of new, unique content. And the reality is that we can’t always predict what that content is going to be, or what shape it will have. It isn’t enough anymore to have some sort of one-size-fits-all container (e.g. the “page”) into which to dump various kinds of content. Today, CMSs need to be able to elegantly manage carefully-designed objects with very specific characteristics that they cannot assume or predict beforehand.
What’s more, CMSs need to allow us to build interactions around our content. They increasingly need to be able to power full-fledged web applications rather than just static websites. But again, much of this isn’t predictable. If you can’t know what kinds of content you’re going to be dealing with, you can’t know how people will want to use it and interact with it, especially since we find new ways to use things all the time.
Another challenge is that CMSs can’t always foresee where they’ll need to be able to extend their reach. Websites themselves are now just one vector in an online presence. Our CMSs have to account for the fact that we increasingly want to post, share, and disseminate our content all over the web—on websites that it doesn’t necessarily know about, in formats it may not have heard of, and on devices that might not even exist yet! In short, the web changes fast, and the tools we use to manage content on the web need to keep pace even when they can’t yet see over the next horizon.
In this tumultuous landscape, it’s important to know that we’re using tools that will adapt with us as new challenges arise. We don’t want to have to hack or customize a CMS to meet our changing needs. We don’t want to have to bend or break our plans because our tools are limited. And we don’t want to have to completely rebuild every few years because our strategies have evolved. What we want, essentially, is a CMS that’s future-proof.
But this isn’t always an easy thing to gauge, especially since we often don’t know what our needs are going to be a year or two down the line. We want flexibility, yes, but lots of CMSs call themselves “flexible” and “extensible.” Lots claim to be using tomorrow’s technologies today. How do we know if a system is engineered and developed in a way that makes it ready for whatever the web throws at it? How do we know if it’s a system we can trust?
One question to ask is, “How are they solving problems right now?” Any CMS worth your consideration is evolving all the time. Their developers are constantly making decisions—about priorities, about approaches, about what sacrifices they’re willing to make—and the sum of these decisions is what I would call a development ethos. Every software project has one, whether it’s made explicit or not. It’s what guides a project’s developers as they set about making improvements and solving new problems. Understanding a CMS’s development ethos is your best bet for predicting if and how they’ll evolve and adapt to the challenges of a changing web.
Of course, every CMS is unique, with its own history, its own reasons for being, its own talented group of developers. But because all CMSs are built for roughly the same purpose—managing content and content-driven sites on the web—it’s possible to identify broad similarities in approach. In my experience, regardless of their particular focus, their unique history, their size, or their popularity, the vast majority of content management systems have a development approach that I’d call “feature-focused.”
Feature-focused CMSs are conceived and architected primarily as collections of content management features. Of course, “features" is one of those slippery words that can really mean almost anything, so I’ll elaborate. The “features” I have in mind arise out of the need to manage particular kinds of content in particular ways, and have two defining characteristics:
Take a moment to think about the various kinds of content management needs that have emerged in the last five or ten years, beginning with things like forums and polls and continuing through to blogs, wikis, comments, tagging, and so on. A feature-focused CMS engineers solutions to each of these problems directly, and whether they’re included in the core platform or as pluggable extensions, the system is more or less a collection of these sorts of features. It has a forum, a calendar, a blog, a wiki. It has a polls feature, a tags feature, a menu feature. It addresses every content need head-on by providing a feature that solves exactly that need.
These features are designed to be fully-integrated solutions, meaning that everything—from how its content gets captured, to the interactions it supports, to the way it is displayed on the front end—all of that is baked right in. The user rarely has to do more than activate the feature and specify a few preferences.
Take an image gallery feature, for example. There are lots of things to consider when implementing an image gallery. When you upload an image into the system, what kinds of information can be attached to it? A caption? A source? A smaller “thumbnail" version? How will they be managed and organized? By tag or category, or grouped into collections or albums? And are they displayed on the front end in a dedicated image gallery area, included in other pages as slideshows, or somewhere else?
A feature-focused system answers all of these questions for you. It defines how the content is captured, managed, and displayed. It might even go so far as to provide the markup, stylesheets, and JavaScript for the front end. The priority is on delivering fully articulated features that require minimal work and decision-making from end users, something that can be really convenient, but only as long as these features are implemented in a way that closely matches your needs.
But when you’re thinking long-term, and you’re aware of the shifting sands that underlie the web, this feature-focused approach starts to look a little worrisome.
For starters, these kinds of features are crafted to address specific content needs. But as we’ve seen, web content is continuing to evolve in ways that are not easy to predict. Every time your needs change, every time your boss or client catches wind of a new “must-have” trend, you’ll be left either cramming new square content into an old round hole, or waiting for someone to implement the new feature you so badly need.
What’s more, even if the feature is implemented, you can’t necessarily trust it. Features in the sense outlined above are basically monolithic, engineered from top to bottom to work in a very particular way. You’re constrained, in other words, by the decisions and assumptions made by the people who built the feature. So what happens, then, when your boss or your client has a change of heart, and wants the blog to act more like a magazine? What happens when you realize that you don’t like “tagging” and want to use a more traditional category structure instead? What happens when you want to manage image galleries, but want to use your own markup?
Features can seem “powerful” and “easy to use” precisely because they don’t require you to make your own decisions, but then guess what? You can’t make your own decisions. Someone else has made a whole bunch of assumptions on your behalf, assumptions you now have to live with. And the more complex a feature is, the more assumptions it’s had to make.
Anyone who’s ever built a website using a system like this knows the feeling of running into walls, of wishing they had a bit more control, of cursing the sun, moon, and stars because making even mundane changes feels like trying to move mountains with a teaspoon.
And if you’re a developer, you know there are other drawbacks too. When your solution to emerging content needs is to build new features, it doesn’t take long for the system to begin to bloat. It starts taking up more and more space, its code becomes harder and harder to maintain. The user interface starts to clutter and crowd because every new feature needs to have a place. This is not the kind of system you want to rely on in the long term, because it’s the kind of system that spreads thin and starts to fray at the edges. Old features are neglected in favor of new ones. New ones roll out too quickly and become error-prone. And the developers, as hard-working as they are, just have too much ground to cover.
At the end of the day, feature-focused CMSs aren’t “bad.” Their developers aren’t any less capable or well-meaning than any others. And often, when your requirements are just right, they’re actually good, useful tools. But they’re constraining. They make it painfully difficult to be creative and innovative, and to try new ideas. They may be fairly good at delivering what you need today, but tomorrow, you’re on your own.
There’s another way of doing things though. A different kind of development ethos. Given a content problem, this approach doesn’t address it head-on. Instead, it pulls the problem apart, trying to figure out what it’s made of. It begins with the idea that every large, specific need is actually a collection of smaller, more general needs. Integrating a Twitter feed into your site, for example, is a large, specific need. But what it consists of, really, is the need to pull in content from an external source and to allow that content to be templated within in your system. Solve these smaller problems and you’ve solved the bigger one. And many, many other big ones.
I think of this approach as being focused on functions rather than features. It’s concerned with what simple things the system itself can do rather than what complex, prefabricated solutions it has. It wants to make it easy for you to solve your problems rather than trying to solve them for you.
Take our image gallery example from earlier. A function-focused system wouldn’t be concerned with engineering a complete, ready-to-go gallery feature. It would be breaking the problem down into smaller pieces: the need to manage a new kind of content, the need to define what data gets captured by that content type, the need to create structures for grouping or otherwise organizing it, the need to display that content on the front end. It would make sure the system had all of these fundamental capabilities, so that in the end its users could create any type of gallery they wanted.
Focusing on functions means engineering a system that is inherently capable. It means being preoccupied with the basics—functions that help people create and manage their own kinds of content, build their own interactions, architect their own front ends. When new needs and challenges arise, this approach asks what core capabilities are missing or need improvement. This way, rather than piling on tons of complex, narrowly-defined features, it selectively adds broader functionalities that make the system as a whole more powerful while at the same time keeping it lightweight and flexible too.
As I noted above, there’s probably not a CMS in existence that doesn’t call itself “flexible.” But focusing on functions cultivates a level of flexibility that few other systems can offer—the flexibility to make every decision for yourself, to be creative when solving problems, to experiment. Rather than constraining you, this kind of system is obsessed with doing the exact opposite—giving you all the tools you need in order to do whatever you like.
This means you can add all sorts of new content as the web evolves. It means you can keep dreaming up new kinds of interactions, new paradigms for how a website can look and act and feel. It means, in short, that your CMS is indeed future-proof.
Symphony is one of these rare CMSs. It sets itself apart by having a coherent development philosophy that is resolutely focused on the system’s core functions and capabilities rather than on specific content features.
As a platform, it is more principle-driven than most. Its development team, along with its wider community of developers and contributors, tries to adhere steadfastly to a set of core tenets like simplicity, modularity, and transparency (among others). And the system is carefully designed to allow users themselves to be principled and to follow best practices.
There are three particular aspects of the Symphony approach that I want to point out here because I think they make Symphony especially well-equipped to deal with the demands of a rapidly evolving web. Odd as it may sound, all three have to do with a sort of... calculated humility—an understanding of what we don’t (or can’t) know, and a willingness to recognize when someone else knows better than we do. Taken together, I think these three concepts demonstrate why Symphony might be the most flexible, future-ready content management system there is.
The more assumptions you make, the more likely it is that you’re going to be wrong. And when it comes to things that are supposed to be useful—like software—the more they’re wrong about how we want to use them or what we’re trying to achieve, the less useful they turn out to be. This is especially true on the web, where nearly everything is a moving target and, let’s face it, we’re already likely enough to be wrong as it is.
For example, not everyone wants to put all their content into articles or blog posts, or into a complex hierarchy of pages. Not everyone wants to organize or display their content in the same way, or sort it in the same order, or deliver it in the same format.
And even when users do want something predictable like a blog post or an article, not everyone wants it to be made up of the same pieces. Sometimes it’ll be the usual: a title, a body, a date, an author, and so on. Sometimes it won’t. Some people will want to include things like subtitles, epigraphs, or postscripts. Some will want to include a writing prompt they used, or meta information like what they’re listening to or where the post was written. There will even be people who want to art-direct each post individually, giving it its own stylesheet and assets.
The point is, we humans are a creative bunch, and there’s really no telling what we’re going to cook up. Symphony understands this, understands that every assumption it makes would be an anchor weighing you down. So it tries not to make any at all.
Of course, there are some givens. It’s a web content management system, after all, so it trusts that you want to manage content on the web (go figure). But beyond that, Symphony tries not to predetermine much of anything, including:
This “make no assumptions” approach means that Symphony doesn’t act as though it knows better than you. Whether you’re an employee working under very strict content requirements and workflow demands, a project manager who knows exactly what you need to accomplish, or a designer or developer with very precise methods to your craft, few things are as frustrating as tying to use a system that insists you do things its way rather than your own.
Symphony is comprised of a bunch of modular components, each providing a basic, core functionality. One of these, for example, allows you to build new content structures. Another allows you to query your content, or to fetch it using detailed criteria. These components are like building blocks from which you can craft your own content solutions. You could say, for instance, “I want to manage real estate listings. Each listing will have an address, a price, a set of photos, and a flag to indicate whether it’s on the market. Then on my home page I want to grab the most recent ten listings that are on the market, with the most recent at the top. And here’s how I want to mark them up…”
Each and every part of that solution would be completely configurable. So you could go back and say, “Actually, I need to add some stuff to my listings: lot size, square footage, number of bedrooms, amenities, etc. I also want to fetch 25 listings for the home page now instead of 10, and I want the user to be able to choose how they’re sorted.” The power lies in making each building block basic, modular, and independent, so that they can be continually reconfigured and remixed to yield unique solutions that accomplish exactly what you want, every time.
Providing you with these kinds of tools, and trusting you to be able to find ways to solve your problems, means that Symphony is always ready to cope with new challenges. It also means that, rather than playing catch-up with web trends, Symphony's just as likely to be leading them, because it leaves room for imagination and empowers smart, creative people to do what they’re best at.
When smart, creative people do what they’re best at (and they’re not all Symphony users, believe it or not), they make the web a better place. They invent useful technologies, establish best practices, and continually expand the boundaries of what’s possible. Symphony happily stands on the shoulders of these giants, as they say, by enthusiastically adopting and advocating open web standards.
Perhaps the most important and obvious example is Symphony’s use of XML as its native data-handling language. XML is a widely-used data format officially recommended by the world’s web standards body, the W3C. Every XHTML page there is, every RSS and Atom feed, and nearly every API on the web—all are XML. The oceans of open source and commercial documentation written in DocBook? XML. Millions of other business documents, scholarly articles, and government datasets? XML. Newer word processor files like ODF and DOCX? XML. The million-plus ebooks that Google, Apple, and others have stocked up in EPUB and other formats? Those are XML too.
Symphony’s fundamental components are designed from the start to handle XML, because when the system passes data around, that’s the format it itself uses. What that means is the entire smorgasbord of content that I just listed above, and every other XML-based format, can be immediately recognized and handled by Symphony. Natively.
In order to template all of this content, Symphony turns to another XML-based W3C standard: XSLT. XSLT is a powerful templating language that can transform source XML into nearly any format imaginable. This means that in addition to outputting (X)HTML pages, it can output RSS-or-Atom-flavored XML, SVG, and even non-XML formats like CSS and JavaScript, CSV, PDF and more. Again, natively. And unlike most other CMSs, Symphony’s template language is a fully open standard, not some proprietary jumble of made-up tags. Instead of memorizing some specialty language and half-coding your templates in a procedural programming language like PHP, with Symphony you use a powerful, consistent, rule-based language that is just as useful outside of Symphony as it is within.
Embracing XML and XSLT means that Symphony already, natively, plugs right into all the dynamic, diasporic content that is at the heart of the evolving web. You don’t need any fancy plugins or parsers or converters. You don’t need anyone to build a “feature" for all those feeds and APIs you want to interact with. All you need is Symphony.
So now that you’ve got a sense of what it is that makes Symphony truly unique, how do you know if it’s right for you and your next grand endeavor? After all, every project has its own unique requirements and constraints, and as flexible and powerful as Symphony is, no system is right for every situation. The (admittedly presumptuous) title of this chapter is “Why You Need Symphony,” but there might be times when you don’t need Symphony. For instance:
That said, in the vast majority of situations Symphony is likely to be one of the most capable and elegant tools you’ll find. Here are just a few of the many things Symphony can do for you:
There are CMSs that are great for building enormous, complex, high-demand websites, but for smaller projects these same systems turn out to be bulky, bloated, and unwieldy. Then there are CMSs that gracefully handle small sites with limited content and dynamism, but break down when those sites need to adapt or expand. Few systems can do both well, but because of Symphony’s modular architecture and unique development philosophy, it is one of those rare CMSs that can run a megasite as cleanly and elegantly as it can a tiny one.
Symphony’s been used to build everything from personal blogs and portfolio sites to social networks to high-delivery websites that host thousands of videos, receive bandwidth-choking traffic, and process millions of interactions. What’s more, a Symphony site is easy to scale as needed, it can go from small to big and back again, because the system is made up of swappable, removable building blocks. With Symphony, agile, iterative development is a breeze.
Symphony can even power full-fledged web applications. Just as there’s a basic Symphony component for fetching your content and channeling it to your user-facing front end, there’s also a component for accepting input from your users and channeling that back into the system. Combined with the tremendous amount of flexibility you have when architecting a front end in Symphony (more on that in Chapter 6), these make it possible to create all kinds of advanced interfaces and interactions.
The reason Symphony is so versatile is that it’s actually a hybrid of sorts between a web development framework and a CMS, combining the raw capabilities of the former with the ease-of-use and conveniences of the latter. In fact, many agencies and freelancers, once they’ve gotten a taste of Symphony, actually make it their exclusive development platform. It’s just that flexible. There isn’t a project that comes their way—however large or small, however simple or complex—that they don’t think Symphony can handle. And they’re probably right.
Your data is increasingly spread out all over the web. Maybe you’re posting status updates on Twitter. Maybe you’re uploading photos to Flickr or Facebook or Picasa. Maybe you use a bookmarking service like Delicious, or take notes with a tool like Evernote. You use these tools because they’re great at what they do, and because they are embedded in broader social ecosystems. But it’s still your data, and because these sites (and basically all others) have feeds or XML APIs, Symphony can put it back in your hands. You can fetch it dynamically and aggregate it for display, or you can actually import the data right into your own site. Either way, Symphony can help you begin to reclaim all of the content you’re generating around the web every day.
In corporate or organizational environments, Symphony can also make your life a lot easier by facilitating communication among other disparate applications. In this sort of environment, it’s fairly likely that your company or client has already-existing systems for managing their information. Maybe it’s an intranet. Maybe it’s a CRM application, or a custom database. As long as it’s got a simple web services layer or API, Symphony can talk to it, helping you improve the flow of data throughout your organization and avoid situations where the same content is fragmented or duplicated across multiple systems.
I worked on a project, for instance, where most of the content that was going to drive the website was already being managed in an internal CRM. Rather than having to build a custom front-end to the system, or having to keep duplicate versions of all that content, we were able to use Symphony to grab data directly out of the CRM. This meant that employees could go on managing their information just as they had before, and anything that was suitable for display on the website could get pulled out and templated by Symphony.
And this works both ways. Because Symphony has a granular data model, and because XSLT can output almost anything, your data will never be trapped. If you decide a few years down the line to use another tool, or to move your data into some external archive, you can just have Symphony fetch your content and transform it into whatever format you need. In fact, in Part 4 of this book, we’ll do exactly that, using Symphony to build a simple application API.
Whoever you are, using Symphony will give you all the control you could ever ask for—over strategies, over workflows, over site architectures and user journeys, over markup, and just about everything else you worry about from day to day. Here are some examples of how using Symphony can put you in the driver’s seat:
You’re a developer. You’re good at designing systems and architecting websites. You know what you want, and you know what you’re doing. Symphony stays out of your way, letting you craft exactly the tool you need and nothing more—no cruft, no fluff, no headaches. Symphony will support whatever agile, iterative workflow you prefer. Its file-based project architecture means your entire build can be easily version-controlled. And if you find yourself building lots of websites with similar requirements, you can just create the scaffold once and Symphony will let you package it up as your own installable flavor of the CMS (we call them ensembles). Neat, huh?
You’re a designer. Your markup and your CSS are sacred. You’re trying to craft beautiful web experiences and the last thing you want to do is deal with some system’s sloppy output. Well, guess what? Not a single byte of code gets output by Symphony unless you write it. Top to bottom, you’re the master of this domain. And you’ve got at your disposal all of the tricks that XSLT has up its sleeve too—you can organize and reuse snippets of code, enforce rules for sanitizing user-created content, make your designs dynamic and responsive to user input, and much more. The system can even do on-the-fly image manipulation, meaning you can ensure pixel-perfect images in your designs, even when they’re user-added.
You run an agency. You command large specialized teams and manage several, maybe dozens, of projects. With Symphony, you’ll have one system that can meet virtually all of your needs. This means you can train your staff once, quote more reliably, build faster, deploy easier, and maintain with less effort. Because Symphony’s so modular, and all of a project’s key structures can be easily version-controlled, you don’t have to be stuck in a linear development path where each team waits for the one before. All kinds of work can be happening simultaneously, and iteratively, saving you loads of time. And should you ever need it, there’s round-the-clock commercial support available too.
You’re an editor or producer. You care about your work and the integrity of your content. If your company or organization’s website is powered by Symphony, you can define everything from exactly how your content is captured and stored to the editorial and moderation workflows it will go through. From a system as simple as an approval flag to one as complex as a multi-tiered review and editorial process, Symphony can be set up to accommodate your exact needs.
You’re a systems administrator. Maybe you work for a government agency or a university. You have to deploy and support a lot of websites, but their requirements can vary drastically. For maintenance and documentation purposes, you want the convenience of using a single CMS. For performance and usability purposes, you want the benefits of custom-built systems. With Symphony, you get both. You get a CMS where each build is essentially a custom CMS.
You’re a highway bandit. You block roads with large, impassable objects and then descend from the woods to steal from those who land in your clever trap. You actually don’t need Symphony to put you in the driver’s seat—you have your own means of getting there. In fact, you’re probably in a driver’s seat right now, in a car that you stole from the very nice person to whom this book once belonged. Shame on you.
Every day, the web is evolving, growing, changing shape. Every day it’s reinventing itself.
If you’re reading this book, chances are that you’re somehow part of this process. And if you are, you know how difficult it’s become to keep pace with the web as it evolves. Its content is changing, the way we use it is changing, and every time we turn around there are new needs, new demands, new challenges.
The tools we use to craft the web are evolving too, or at least they should be. But when so much about the future of the web is unpredictable, we want more from our tools than just change. We want reliability. We want to know that they’ll be able to handle whatever comes their way. We want tools that we can trust.
In the world of content management systems, one of the most prevalent strategies for keeping up with the web’s shifting currents is to pack the system with features that address all the needs of the day. But this approach is shortsighted, and these systems often end up being unnecessarily restrictive and cumbersome. Users are forced to adapt to the way the features are built, and when they want to do something innovative or creative, usually have to wait for the system’s features to catch up.
Symphony, on the other hand, focuses on function, on providing you with the basic tools you need to creatively solve your own content problems. This results in a system that’s inherently more powerful, and yet still nimble in the face of new demands and changing needs. With Symphony, you get a CMS that doesn’t make any assumptions about what you need to do or how you want to do it. You get a CMS that’s modular, that allows you to craft exactly the tool you need, in exactly the way you want. You get a CMS that leverages the web’s most powerful open standards, putting ever more possibilities at your fingertips.
If you need to build or manage a website, and you want a CMS that’s smart, elegant, and future-proof, you need Symphony.
You need Symphony today because it’s versatile enough to gracefully power any kind of website or web application. Because it can help you manage your content more efficiently than ever before. You need Symphony today because no matter who you are, it will help you do what you do better, faster, and smarter. Because it will empower you to try new approaches, to think boldly and creatively. You need Symphony today because it’s powerful enough and flexible enough to allow you to adapt to whatever the evolving web has in store.
In short, you need Symphony today because you need Symphony tomorrow.