Why do we start in an unfinished CMS?
NewCity uses an agile development process for building your website. It’s an iterative method that focuses on collaboration. Before agile, developers would build out what they thought you’d need and spend months polishing that concept to perfection, only to hand over a completed product and find all the places where your expectations and their efforts didn’t match up.
Instead, we invite you into the design and build process early so you can act as a partner in shaping the system. This helps us prioritize what’s important for your content, your people, and your work process and design a CMS that’s a much better fit for you and your organization.
Agile process means alpha testing
During this process, we’ll be working with you simultaneously inside a highly complex functional design system that has a staggering number of variables, content relationships, and dependencies. We’re building in content types, functionalities, data integrations, and adding theming while you’re testing out the content entry experience. At this stage, it feels a bit like trying to climb a sand dune while the ground is shifting beneath your feet — things are changing constantly, and that can cause uncertainty and frustration.
No matter how comfortable you are with digital interfaces, a brand new system is always a clunky experience (it still is for me, and it’s a large part of my daily job). The navigation isn’t set up yet, the site search isn’t installed, and things don’t look like they will in the final product. But don’t worry, this exploratory testing is a normal step in an agile site design process.
Your feedback is critical to the success of this system we’re all working on together, and with your insight, we can uncover unique content patterns, custom details for your author environment, and other items specific to your content and your staff’s needs that will help us co-create a better final product.
What does the process look like? At NewCity we use a custom bug-tracking system called Frontback, written by Andy Hebrank, one of our senior web developers. It interfaces with GitLab’s issue tracker to point out design elements and code behaviors in question on both the front end and back end. We use this as a space for in-context communication between our team members and yours during this process.
What kinds of things will you see?
Functionality first, appearance second
Bear with us in the beginning stages if components look a little (or a lot) off. For the first few weeks we want to make sure the data relationships are working as expected, then we’ll go back and make things match the original designs.
Invisible front-end pieces
The text, image files, and other data you input in the back-end edit form are stable and your work is saved, but the front end design is not always ready to render it on the screen yet. Once it is, we’ll hook up the design code to your back-end data and you’ll be able to go back and see what your work looks like in the design.
Wacky spacing
Many of the changes we make during this testing process affect the way individual components react in combination with the components around them — when we make a code change to a table component to make it look good or work better in one situation, it also affects tables everywhere else across the site. For that reason, we often save spacing issues to the end so we can adjust everything in one pass.
Systemic symptoms
Because of the way styles are reused in code across the site, often what looks like a catastrophic problem affecting every page can actually be a quick fix that takes just a few keystrokes to resolve. If you see that ALL header images on ALL pages are blurry, all the text in the same type of component is using the wrong size font, or all the captions you’re typing into the back-end aren’t showing up on the front — don’t panic! But please report an issue.
Don’t worry about trying to document every instance, though. Often that one report will give us enough information to track down the problem and resolve it in all the places it appears across the site. And it’ll save you time spent filing extraneous bugs.
One-off weirdnesses
Sometimes as you’re entering content, you’ll encounter a combination of variables we didn’t foresee — maybe a background pattern on a routing component looks lovely until it’s juxtaposed with a feature component whose overlapping design throws both components out of whack. These are the types of things only large quantities of real content can help us uncover, so please point them out when you find them.
Things to keep in mind as you’re entering content
Things look different on different screens
As part of a responsive website design system, the components and their spatial relationships to each other are designed to render differently at different screen dimensions and resolutions. Monitors also affect things like colors, sharpness, and layout positioning. If your workstation uses a less-common setup and it causes things to look strange, we want to hear about it.
Stumped about a layout issue? Just ask!
Page layout — the act of applying new components and information design techniques to what was formerly a giant blob of text — is often the most challenging part of migrating content to a new CMS.
If you’ve tried a couple of ways to lay out a page and nothing seems to look right, let us know. We might have a suggestion for using existing styles and components differently, like shortening up text that’s making columns too long and throwing off the visual balance, or splitting text up between multiple components. Or you might have uncovered a situation that merits a design change that we should add to our queue for a future iteration. Either way, we can help you figure it out!
Writing good issue reports
You can help us solve problems more quickly by including the most relevant information in your bug reports. When filing an issue report, follow these guidelines:
One issue per report
It can be tempting to list multiple issues in the same bug report because they seem related by type or appear together on the same page.
All of our team members use the bug tracker, not just developers! Each issue reported will be assigned to the person who can best resolve it; sometimes, a bug may have to spend time in the hands of several people. If a single report contains multiple issues, we can’t route them to the teammate who can best address each one. Also, some issues might be resolved very quickly, while others require more discussion, so keep them separate to keep things moving along.
Describe what’s going on
An ideal issue report contains the following information:
- What you expected to see/expected to happen
- What you actually experienced
- Whether or not this issue is preventing you from doing further work
Don’t worry about typing in your browser or monitor specs
The feedback-filing software we use tells us about your viewing environment when you file an issue. We may not be able to optimize for every possible scenario out there, but we want to make sure that we get it as close to the original design as we can for as many situations as possible.
When in doubt, file an issue
Don’t be shy about filing issues on both the front-end design and the back-end editing environment — whether they’re bugs, improvement suggestions, or even new features. Because we’re cooperating in the agile development process, you’re helping to shape the end product through using and providing feedback on the system. We’re depending on your feedback to create the final product, which is most valuable to us early on in the testing phase while things are still pliable.
