Sitecore is built to be versatile and accommodating to the needs to web designers and their teams. With the wide arrange of tools, suites, modules, and third-party integrations it can be easy to get lost in creating a cost-efficient solution that still offers your team the resources they need. Luckily, Sitecore.com is well equipped to help you answer those questions. I would recommend starting here, if this is of particular interest to you

Going into any talk you may have, whether with your team members or Sitecore Experts, it’s good know what your needs are in advance and even better to have them mapped out well

The same is true when it comes to development in Sitecore. That’s exactly what I’ll be discussing (perhaps, ranting is more appropriate?) in today’s blog post: Planning

Developers Playing Telephone

A new developer will not have the same context and working knowledge of the application — while this is unavoidable in most cases, it’s something to consider and to not underestimate. This is where WELL THOUGHT OUT project requirements are the keys to long-term success, through supporting your developers

[More] Words From the Writer
This isn’t to say that I, in any way, advocate for not putting new devs on existing projects (boops you on the head with a newspaper). This is to say Strong Requirements will make Strong Developers; Thoughtful Requirements will make Thoughtful Developers

Thinking Things Through

Just like when it came to picking out your CMS platform, version, etc., sometimes you need to lean on others for specialized information. Including developers in discovery or requirement conversations is paramount to predicting pitfalls and hurdles that can be addressed now, or at the very least, planned for

If you’re a developer you may be groaning that I’m signing you up for another round of meetings… But participating in Discovery is a good way to make sure you keep your application knowledge sharp

This is also another way for you to try and avoid the last “headache” that you worked on. I say, don’t be afraid to bring up pain points of development, even if you think “it’s just you” experiencing it. When something doesn’t make sense, it’s best to ask for clarification; maybe you thought of something that no one else did

If developers can review designs or requirements before work has started we can make more informed decisions. Whether that’s making a small modification to a design that greatly reduces the complexity (therefore: time) of a task, or being aware of potential issues that others may run into; can lead to better time estimates at the very least

The Problem With Shapeshifting

Overengineering is a problem that can occur when a component/webpage/service has undergone many rounds of revision without even realizing it’s happened. It’s as if, the longer a task has existed it starts to slowly lose it’s identity over time

Many developers may describe “Legacy” code as “wonky”, “spaghetti-code” or “no idea what the original purpose was.” This could lead back to the first point on this post about losing context as applications change ownership. Instead, here’s another point: Documentation can help developers and users keep track of what specific things do and are expected to do

Is it supposed to make that noise? Do the ears always move like that? Can it change color? All excellent questions to be answered by documentation

This can be especially true when it comes to the organization or hierarchy for our Sitecore items, and more so if you are using item inheritance to create more complex (though, modular) templates. Having modular templates can be great for keeping data and displays consistent, but if you get too carried away, you could be left with an overengineered mess

Don’t be afraid to have a sanity-check now and then and ask “what does this REALLY do or NEED to be doing?”

Though, we may try, we cannot always predict the future with full accuracy. New technology and new requirements will undoubtedly arise to complicate further enhancements. But what are the things we can be Proactive about?

Don’t Neglect The Afterthoughts

Don’t say any names, but raise your hand if you’ve been in a meeting where someone said “we can just add that later.” If the plan is to add it later, it should be taken seriously from the get-go. It definitely shouldn’t get tacked to a backlog and left to gather dust, until a developer (with no or less context than the one who wrote it) comes along to work it

Here are a few pieces I think are critical to discuss and should absolutely not be “tacked to the backlog to be forgotten”

Accessibility: Ethics aside, let me ask you a question: How many people do you want to use your site? Do you want as many users as possible to access your site?
Not everyone has access to 8gb of RAM and Highspeed Internet. Not every internet connected device has a mouse or keyboard. Not every user is going to speak your language. Not every user can see or hear. Not every user has full mobility. If you want people to use your service, you MUST make it accessible to them; and putting that off until late in the game is a terrible idea (IMHO).
Accessibility can be a tricky game to figure out, as you aren’t simply “adding a frame” to the website elements. Using JavaScript on a page or having a specific Tab Index behavior can complicate things even further, sometimes leading to complete redesigns because things were setup inconveniently from the start (because the “do it later” requirement of accessibility was not considered).

Mobile and Tablet Support: As a web developer I commonly code against Chrome, and perhaps FireFox or Edge if I’m feeling feisty. And yet… as a consumer I primarily use my phone or tablet for 95% of my online interactions.
Knowing what your Mobile and Tablet support is from Day One is great, but you need to declare these requirements and have developers and designers alike adhere to them.
Consider, what breakpoints do you need to hit? What devices do your users use? While the design may be unique and elegant in a Power Point, does it actually display well on a phone/tablet? What about extra-wide monitors?
Additionally, if it’s the right solution for you, when it comes to mobile and tablet styles there are libraries that can be added to your project to do a lot of the heavy lifting for your team. Just be sure to introduce a standard for how to use them so the team stays consistent.

Specific Browser Support: The days of supporting Internet Explorer have long since passed (and developers everywhere rejoiced), and while many browsers use some flavor of “Chromium” you will still come across edge-cases between browsers, especially if interacting with newer CSS or JavaScript features. In many cases, I notice the bigger problem comes with JavaScript but if your project use SASS or LESS I wouldn’t be shocked that I ran into issues, so it wise to plan accordingly
When it comes to testing for a specific browser, device, or OS ~ I love to use Browserstack (not an ad, I swear (though it could be; hit me up)). Check links below if this is for you

Closing Thoughts

Thank you for reading a, very opinionated piece of mine 😅 hopefully there wasn’t too much rambling. I am just a developer, and not a project manager by any means (at the moments); I’ve based a lot of this article off of my own observations and conversations.

I hope that, together, we can all be more mindful and thoughtful when it comes to writing up project requirements so [hopefully] we have easier lives in the future

Related Links

Sitecore Knowledge Center: The CMS Features You Need
https://www.sitecore.com/knowledge-center/digital-marketing-resources/the-cms-features-you-need

W3 Accessibility Guidelines
https://www.w3.org/WAI/standards-guidelines/

BrowserStack: 10 Tips for Mobile-Friendly Design
https://www.browserstack.com/guide/design-mobile-friendly-website-and-app