When I talked about the pain points of major versions, most people probably jumped right to the look and feel of their sites. (Like I mentioned before, the term “skins” is being retired in favor of the more appropriate “themes” term.) After all, SMS and Nova have gone through major changes to how the look and feel of the sites is handled. SMS 1 started by using spliced PSD files before switching to HTML and CSS in SMS 2. Nova used the same tools, but things changed significantly by offering the ability to skin each section independently.
With Nova NextGen, I felt it was important to address some of the problems that have become apparent with the way theming works in Nova. Yes, there will be a whole new theme system to learn, but I think it’s a better way to build site themes. I’m also committed to getting early previews of Nova NextGen into people’s hands, so there will be more than enough time for theme developers to get familiar with the new way of building themes before the final release. I suspect theme developers will have a wide range of themes available on AnodyneXtras on day one.
Less Code Duplication
The biggest pain point in Nova 2 with theming is the duplication of code. So much duplication! If you want your admin, main, and wiki sections to have the same look and feel, you’re essentially doing the same thing 3 times. Sure, you’re probably copying and pasting, but there are enough differences that it’s a pain in the ass to go through the process. On top of that, it’s a major time killer. The way it should work is that you write your code once and Nova uses it, no matter where you are in the system. And that’s exactly how Nova NextGen will work.
While there’s nothing inherently wrong with the theme structure in Nova 2 (it’s self-explanatory and that’s important), there may be a little too much happening. For example, what’s different about the wiki versus the admin section versus the rest of the site? The answer is: not a whole lot. In Nova 2, minus a couple of minor tweaks, the three different sections are identical.
After realizing this (a long time ago actually), my goal was to significantly simplify the structure of a theme. What came out of it was a single required folder: design. Everything else is at the discretion of the theme developer.
The Base Theme
One of the biggest questions I’ve had to ask myself in the past about a new feature is if has any special user interface requirements. If I need a new class in the stylesheet, I need to weigh that feature very carefully because it’s something that impacts theme developers. Since Nova 2 skins are entirely independent of the system, any changes in the default skin need to be added to every skin. Ugh. I’ve actually nixed entire features in Nova 2 because of the burden it would put on theme developers. When I sat down to start designing Nova NextGen’s theming system, that was priority numero uno to fix.
The result of that work is a base theme that lives inside the Nova core that every skin pulls in. That means if a new feature needs new styles, I add them to the base theme and without changing a single line in your themes, you’ve gained those styles. (Sure, you may need to tweak colors or styles, but generally speaking, there won’t be anything that’s broken, just stuff that doesn’t fit in exactly with your theme.)
When it comes time to build out your theme, Nova NextGen relies heavily on the cascading part in cascading stylesheets. Don’t like the color of the page header and only want to change that? Your skin could literally be a single line that changes the color of the page header class by overriding it and giving it the color you want. Using tools like Firebug for Firefox or the Chrome Developer Tools, you can precisely identify the classes you want to target and write styles just for those classes. This means you don’t have to duplicate tons of boilerplate code to get your theme to look right, because the base theme is included by default.
Certainly the learning curve here will be understanding how to identify the pieces you want to theme, but once you’ve learned how to do that, I think that theming will be a much cleaner process than it’s ever been before. It also has the added benefit of making skin much smaller since they won’t need to have a ton of duplicated code all over the place.
Overriding Everything (Just About)
The biggest change that comes with overriding is the order in which seamless substitution checks things. Moving forward, Nova will check the override first, then the skin, then the core (previously, the skin occupied the first position). It made more sense to me that the override be a true override. Jon Matterson and I had talked about this a while back and we both felt that the override was a little deceptive since the skin had precedence over the thing that was supposed to be the override.
The Theme Class
In Nova 2, much of the work of building a theme is handled in the controller and in ancillary classes. It works, but it isn’t very flexible and it certainly doesn’t allow for theme developers to tweak (or even completely change) how their theme is put together. Theme developers have been at the mercy of how I set it up originally. That’s going to change.
Theme developers will have the option of creating a Theme class that can either extend from the base Theme class or implement the necessary interfaces (Themeable and ThemeableInfo). Inside this class is the guts of how a theme is put together. If you want to change how the navigation is built up, you can make those changes in that class, so Nova will use your theme’s alterations, but only for your theme. (There are currently no plans to allow for extending or overriding the base Theme file as doing so could create wide ranging issues and break the whole system.) This should give theme developers infinitely more flexibility to have their themes built up how they want.
In addition to the Theme class, more and more of Nova’s components will use partials, small bits of code stored in their own files. Partials mean that HTML won’t be hard-coded into classes any longer (like Nova 2’s Nav class). Instead, a small PHP file has all the necessary markup. And, you guessed it, partials can be overridden on a theme-by-theme basis.
User Interface Toolkit
The biggest challenge when building a foundation for people to theme off of is trying to figure out everything that people might want to do. That leads to a lot of code that needs to be maintained (which means more stuff that can break). With previous versions of Nova, it led to a lot of stuff that worked for the base skins, but not for much else. Without documentation about those styles, it fell to skin developers to figure out what was there and what they could use. Of course, with it all living in each skin, there was the ability for a developer to totally change it.
In recent years, there’s be a significant rise in the number of CSS frameworks, or user interface toolkits, that provide a lot of basic functionality and even add some components to use in sites. The most popular toolkit (and one that’s seen some limited use in Nova) is Bootstrap. Currently, it’s one of the most watched repositories on Github. There are a lot of things to like about Bootstrap, including responsive utilities, common components, a robust grid system, and more. There have also been others that have popped up since then, like Semantic UI.
I’m still in the process of evaluating what are the best options for a user interface toolkit, but what I do know now is that there will be one and it’ll be at the heart of all the themes that Anodyne builds. I’ll be storing the toolkit within the core (or referencing a CDN if it’s available), so when a decision is made, everyone can learn that toolkit and be familiar with it for their own skins. These really are fantastic tools, so I want to make sure Nova NextGen is taking advantage of all the work that’s been done on them so far.