In our ongoing series of Tag1 Team Talks commemorating the 20th anniversary of Drupal, Tag1 Senior Architect and long-time Drupal contributor Nat Catchpole joins Managing Director Michael Meyers to talk about Catch’s time in the Drupal community. Catch has nearly 8500 commits in his 15 years working with Drupal. He’s worked on a wide variety of modules, as well as holding the dual positions of Drupal Core Release Manager and the Framework Manager. His focus on performance and scalability has helped build Drupal into what it is today. For a transcript of this video, see Transcript: 20 years of Drupal – Nat Catchpole. ### Related content In the coming weeks, Tag1 will be featuring Team Talks with some of its long time Drupal contributors. Check back here, or follow the blog to see these interviews as they become available: – Jeremy Andrews – Doug Green – Fabian Franz – Narayan Newton – Francesco Placella – Greg Lund-Chaix – Marco Molinari – Michael Meyers – Moshe Weitzman – Nat Catchpole ———– Photo by Daniel Olah on Unsplash
Part of contributing to any open source project, or even really being a contributing member of any community, is sharing what you know. That can come in many forms. While many projects over emphasis code, and most of us understand the value of conference talks, good how-to articles are some of the most critical contributions for any software platform. There isn’t much point to a tool if people cannot figure out how to use it.
Why do I write how-to articles
I’ve contributed code to Drupal, some of it even good and useful to others. But usually when I hear someone noticed something I created it’s blog posts about how to solve a problem.
When I struggled to find the answer to a question I expect it is a candidate for a how-to post. I am not so creative that I am often solving a problem no one has, or will want to, solve for another project. And I am good enough at what I do to know that if I struggled to find an answer it was probably harder to find than it could been.
That helps me find topics for articles that are helpful to the community and benefit me.
How-to articles help others in the community use tools better
The goal of a good tutorial is to help accelerate another person’s learning process. The solution does not have to be perfect, and I know most people will have to adapt the answer to their project. I write them when I struggled to find a complete answer in one place, and so I’m hoping to provide one place that gives the reader enough to succeed.
Usually I combine practical experience earned after digging through several references at various levels of technical detail – including things like other people’s blog posts, API documentation, and even slogging through other people’s code. I then write one, hopefully coherent, reference to save others that digging extra reading.
The less time people spend researching how to do something, the more time they have to do interesting work. Better yet, it can mean more time using the tools for their actual purpose.
How-to articles serve as documentation for me, colleagues, and even clients
The best articles serve as high level documentation I can refer back to later to help me repeat a solution instead of recreating it from scratch. When I first wrote how-to articles I was solidifying my own learning, and leaving a trail for later.
They also came to serve as documentation for colleagues. When I don’t have time to sit with them to talk through a solution, or know the person prefers reading, I can provide the link to get them off and running. Colleagues have given me feedback about clarity, typos, and errors to help me improve the writing.
I have even sent posts to clients to help explain how some part of their solution was, or will be, implemented. That additional documentation of their project can help them extend and maintain their own projects.
How-To articles give me practice explaining things
One of the reasons I started blogging in the first place was to keep my writing skills sharpened. How-to articles in-particular tend to be good at helping me refine my process in specific areas. The mere act of writing them gives me practice at explaining technology and that practice pays off in trainings and future articles. If you compare my work on Drupal, Salesforce, and Electron you can see the clarity improve with experience.
How-To articles give me work samples to share
When I’ve been in job applicant mode those articles give me material to share with prospective employers. In addition to Github and Drupal.org, the how-to articles can help a hiring manager understand how I work. They show how explain things to others, how I engage in the community, and serve as samples of my writing.
How-To articles help me control my public reputation
I maintain a blog, in part, to help make sure that I have control over my public reputation. To do that I need inbound links the help maintain page rank and other similar basic SEO games.
From traffic statistics I know the most popular pages on this site are technical how-to articles. From personal anecdotes I know a few of my articles have become canonicaldescriptions of how to solve the problems.
When I first started my current job we had a client ask if I could implement a specific feature that he’d read about in a post on Planet Drupal. It turned out to be mine. Not only was I happy to agree to his request, it helped him trust our advice. My new colleagues better understood what this Drupal guy brought to the Salesforce team. Besides let’s be honest it’s fun when people cite your own work back at you.
The actual writing process isn’t that hard, but often people leave out steps, so I’ll share my process. This is similar to my general advice for writing instructions.
Pick your audience
It’ll be used more widely than whoever you think of, but have an audience in mind. Use that to help target a skill set. I often like to think of myself before I started whatever project inspired the article. The higher your skill set the more you should adjust down, but it’s hard to adjust too far, so be careful is aiming for people with far less experience than you have – make sure you have a reviewer with less experience check your work. Me − 1 is fine, Me − 5 is really hard to do well.
Start from the beginning and go carefully step by step
Start with no code, no setup, nothing. Then walk forward through the project one step at a time writing out each step. If you gloss over a detail because you assume your audience knows about it add reference links. You can have a copy of a reference project open but do not use it directly; it’s there to prevent you from having to re-research everything.
List your assumptions as you go
Anything that you need to have in place but don’t want to describe (like installing Drupal into a local environment, creating a basic module, installing Node, etc) state as an explicit assumption so your reader starts in the same place as you do. Provide links for any assumptions which are likely hard for your expected audience to complete. This is your first check point – if there are no good references to share, start from where that article you cannot find should start (or consider writing that article too).
Provide detailed examples
Insert code samples, screenshots, or short videos as you progress. Depending on what you are doing in your article the exact details of what works best will vary. Copy and paste as little reference code as possible. This helps you avoid accidentally copying details that may be revealing of a specific project’s details.
If you look at mine you’ll see a lot of places where I include comments in sample code that say things like “Do useful stuff”. That is usually a hint that whoever inspired the article had interesting, and perhaps proprietary, ideas in that section of code (or at least I worried they would think it was interesting). I also try to add quick little asides in the code samples to help people pay attention.
Test as you go
Make sure your directions work without that reference project you’re not sharing. This is both so your directions work properly and further insulation against accidentally sharing information you ought not share.
End with a full example
If you end up with a bunch of code that you’ve introduced piecemeal, provide a complete project repo or gist at the end. You’ll see some of my articles end in all the code being displayed from a gist, and others link to a full repository. Far too many people simply copy and paste code from samples and then either use it blindly or get stuck. Moving it to the end helps get people to at least scan the actual directions along the way.
Give credit where credit is due
If you found partial answers in several places during your initial work, thank those people with links to their articles. Everyone who publishes online likes a little link-love and if the article was helpful to you it may be helpful to others. Give them a slight boost.
Get a fast Drupal 9 setup in 3 commands.
It just relies on a PHP built-in server, so no Docker here, the only requirements are Composer and PHP.
Then, we will do a recap of the available tools for developers.
Tag1’s 20 years of Drupal series continues with an interview with Senior Architect Francesco Placella. Francesco has had a Drupal.org account for over thirteen years and in that time has made his own significant contributions.
It’s been years since I paid much attention to my personal blog, dropping by only occasionally to post something new, moderate comments, or apply Drupal updates. I’ve been wanting to upgrade for a while, and the current status of Drupal 9 + its core themes Olivero (front-end) and Claro (admin) convinced me to spend a few evenings making it happen. However, I didn’t want to just rock the default blue palette the Olivero theme uses by default.
In various areas of my life, my motif is late 70’s, early 80’s … ’77 Alfa Spider, long hair and trucker hat, fleece lined sherpa jacket, etc. I’ll work all night grooving to CCR or Darksynth, and if I can’t have an angular Lamborghini Countach, I can at least dream of a Tesla Cybertruck. To make Olivero “mine”, I opted for an 80’s synthwave inspired palette pairing the Centarro purple with neon pink accents. Read more
This research replaces Forrester’s Wave on Web Content Management Systems. The focus is now on “agile content management” instead of “web content management”. This makes sense given the way people consume content today. Because consumers shift between channels when researching a brand or product, organizations need a back end that can support all these different end points (e.g. web, mobile, kiosks, voice assistants, etc).
The analysts note: The [Acquia] platform shined in developer and practitioner tooling, with superior capabilities in front-end components and backend extensibility of the platform..
Choosing Right CMS for Your Business: Part 1 Akanksha Mehta Fri, 02/26/2021 – 10:15
This is the first of the two-part series on ‘Formulating a business case for a new CMS’. The first part debates on open source CMS and proprietary CMS. The second part will discuss various other factors that are to be considered before opting for a new CMS for your business.
A successful business is resultant of an array of decisions, whether big or small, leading to its conception, formulation and finally, execution. With digital being normalized to the extent where it is the only way we know of to access a ton of products and services, a solid online presence has come to be of utmost importance for a business. A lot of times, businesses prefer going for a CMS (Content Management System) instead of building a website from scratch, as a CMS gives you a pre-built website, good to go as it is, or easily customisable even without having a dedicated team of developers and related coding knowledge.
What are the options?
The first step towards making a business case is to weigh your available options side by side. As a business choosing a new CMS, you will be rendered the following options –
A) Proprietary Model CMS
A CMS built under the proprietary backdrop will have a unitary ownership. Every tool and feature available will be created and listed by the owner organisation, and will be served to the end user in a transactional manner, with not much deliberation involved as everything sources back to one single origin.
B) Open Source CMS
On the contrary, in an open source CMS model, apart from a few core features, contributions are invited from everybody. The model opens up avenues for discussion and innovation for its end users thus forming the likes of a community, working together for the greater goal.
Due to the community benefits that come along with an open source CMS, recent statistics point towards an increase in inclination towards adopting an open source model for a business.
The said benefits can largely be summed up in the following points.
Business Case : Open Source CMS vs. Proprietary CMS
For a better understanding of the business case for a CMS of either kind, let’s compare from various dimensions the features of Open Source and Proprietary CMS models with a business point of view –
In a proprietary model, since it is the organisation that bears all the cost of maintenance, addition and subtraction of features, upgradation and bug fixation, it will recover these expenses in the form of subscriptions, licenses etc. You might need to pay yearly renewal fees or monthly usage charges. Along the line, be prepared for cost surprises, as they may initially be hidden, but will pop up soon enough.
If you’re wondering why to choose an open source CMS in this case, it is because it’s free to use with no charges in the form of subscriptions or premiums.
Hence, both the models do need some form of monetary support, and it is the business owners’ call what they want to invest their money on.
With the homogeneity that comes with proprietary CMS models, also comes rigidity in terms of customisation and personalisation, since there’s very little that is left to you for deliberation. Hence, if your business thrives on establishing unparalleled user experience by tapping on features like personalised feed and customisable layouts, go for open source. An open source model remains connected to its user base owing to continuous contributions and ongoing discussions within the community, making the field research for customisation much easier.
On the other hand, if your requirements do not place much focus on the look and feel of the site, and rather banks on niche content for niche audiences, the associated costs and effort that comes with customisation is not that high utility for you and this is when to choose a proprietary CMS.
Needless to say, all the additional features and tools make open source CMS unnecessarily complex. A small business with limited resources might find it too overwhelming to delve into web development especially if it is not their calling. However, the open source community, like that of Drupal, for instance, is available at your disposal any time. Just leave your questions in the dedicated forum, someone from the Drupal Community, that comprises millions of members, would surely revert. Or, if you wish to get web performance optimisation services or support and maintenance services, you can also partner with a digital agency which specialises in Drupal. In the case of proprietary CMS, with a single vendor to reach out to, things can be streamlined here as well.
A proprietary CMS is a one-stop-shop experience, everything is handed out to you at once and you have very little to worry about if your area of expertise lies elsewhere. You can certainly rely on it in customary scenarios where you’re looking for greater stability of the product. But what must be kept in mind is that the ownership decides the lifespan of every service offered, and reliance takes a hit if the products you’ve based parts of your business on are changed opposite to your liking, or even removed. You also need to rely on the owners for bug fixes.
On the other hand, in case of an open source CMS, when our surrounding technology sphere undergoes change, open source is the first to reflect it, as it consists of users, and more importantly, contributors, from all across the globe. It gives one the freedom to work on a part of the software that is useful to them, hence creating their own safety net.
Proprietary CMS models bank on security by keeping their source code under wraps, which might backfire as any bugs that creep into the source code will remain hidden from the public eye as well. Although the source code being open in open source models has drawn speculation, it is widely known for bug fixes being very prompt as multiple hands are working constantly to make it error free. Snyk found out in one of their reports that there were lower vulnerabilities reported across popular open source ecosystems, and that there was an improved security mindset within open source organisations.
Proprietary software packages come in a bulk, installing various components that you might never end up using, as choosing exactly what to install isn’t everybody’s cup of tea. Open source softwares are based online, taking up negligible computer storage space. If bulkiness is your area of concern because you already have a lot of bulk on your plate, closed source might add to the problem.
Open source is a developer’s paradise. If you have the expertise to work on an open source software or can afford people with the needed skills, nothing like it. However, if your website requires multiple people being on board to handle the content on a regular basis, it might not be the best choice for you. A closed source software doesn’t need any technical knowledge or coding skills to work seamlessly, while open source does. People with little to no technical experience can also work on proprietary software.
The flexibility and space for innovation that comes with an open source software is unparalleled. Open source is like a self service buffet, each user is free to take what he or she wants, but it does not end there. New ideas for the betterment of the software and the community are always invited. In comparison, closed source models have a few people deciding on the features of the software, so it is impossible to cater to everybody. If your business’ future is to thrive on change and creativity, it is best to go for an open source model to avoid a fix in the future.
In open source communities, we see newer ideas and technologies on the ground not only sooner, but also on a continuous test drive with multiple technicians already working on the issues as soon as they’re detected. Open source CMS Drupal has held quite a starry record in unleashing new trends and making those functional as an open source platform. Macro trends in the industry like Continuous Delivery for superfast project deliveries, microservices infrastructure for small, autonomous services and machine learning for ‘intelligent’ web development’ have been brought to good use by Drupal. Hence, newer technologies see optimum utilisation with the backdrop of an open source community.
Most importantly, the satisfaction of working with open source and contributing to it
Contributing to open source also has a plethora of hidden, indirect benefits. A company that is known to contribute to the common good is sure to build a positive, welcoming and compassionate brand value both within and outside the company. Developers involved in working on the open source components would be interacting with similar abundantly skilled people from all around the globe. Hence, not only is open source the right thing to do, it is equally exciting and challenging to work on. A person constantly interacting with the community is bound to gain a lot of dynamic experience, leading to a much faster growth rate as compared to a stagnant worker. And at the end of the day, one walks home satisfied and content with the feeling of having contributed to the bigger picture, to have fulfilled a bit of their own social responsibility.
Companies as big units also find it important to provide funding to the community as a part of their CSR (Corporate Social Responsibility). Since they derive so much in terms of components and knowledge from the open source community, it only makes sense at the end of the day to give back to it. More on large companies’ preference for open source here.
Drupal as an open source software has time and again seen how contributions and community engagement keep the platform afloat. Drupal acknowledges each contributor by issuing them credits for their work, and derives essential data from the trends of contributors. For example, if they see minimal engagement from a social or ethnic group, the inclusion statistics are likely to be revisited in order to analyse whether Drupal is accessible to everybody to engage and contribute in. Drupal also states in its Values and Principles that the bigger goal is to foster a learning environment leading to collaborative decision making and overall excellence. To know more, take a look at what makes open source recession proof, how it has tackled Covid-19 problems, and how Drupal stayed on top in the coronavirus pandemic.
The process of choosing a new CMS should be undergone carefully after thorough analysis of every aspect of the business cases for different softwares. The CMS is what you choose to represent and associate your brand image with, hence it should do justice to your goals, agendas and vision.
While this trend might be counteracted by another – brutalism – you’ll find a gluttony of sites brandishing a set of bright colours emboldened further with soft gradients. This of course poses some accessibility challenges with text overlapping such backgrounds. Check out Stripe.
The more courageous of the brands push their vivid colours even further with background gradient animations. Check out Qoals.
Peering through glass-like interface elements might hark back to Windows Vista times, and more recently with the latest builds of iOS. UI designers are taking it further with ‘glassy’ overlays to help text become a bit more accessible over gradients and bright backgrounds. Check out DesignCode.
We’ll keep you updated as we release these and more on Convivial.