Mobile App Launch Checklist: 10 Critical Issues To Fix and Metrics to Measure When Gearing Up for Launch
Adriana Cacoveanu / Mar 26'2019
And developing a website with accessibility in mind means precisely that: to write your HTML code for screen readers. For those website visitors who depend on assistive technologies to fully enjoy the user experience delivered there. Therefore, the way you'll configure your HTML elements will have a sure impact on your website's overall accessibility: good or bad. In this respect, here's a checklist of the most effective (and handiest) ways to make your HTML elements fully visible and comprehensible to screen readers: 1. Provide Alternate Text for Every Image on Your Website By far the handiest way to write HTML code for screen readers: just grow a habit of adding a succinct, yet perfectly comprehensive “Alt text” description to every new and old image on your website. Make it descriptive enough, but do look out for overly specific (and long) descriptions. Keep in mind to provide context... You'd thus prevent awkward situations where the assistive technology would just let that website visitor know that... there's an image on that page. 2. Writing HTML Code for Screen Readers: Use ARIA Attributes One of the best HTML accessibility best practices is to add ARIA (Accessible Rich Internet Applications) to your HTML elements. Why bother? Because this way you're providing visually-impaired users with more information about specific elements on a web page Take this example: the “role” attribute gives more context; it makes it easier for the screen reader (and the assisted user implicitly) to see what that element's “role” is in the context of that specific web page. Just add the “navigation” value to that “role” attribute and the screen reader can then interpret the HTML element as being a... menu. And then present the user with all the options listed there. Something intuitive for a user, but not so much for a visually-impaired one. And this is but one of the many functions for ARIA attributes that you could add to your HTML code to enhance its accessibility. 3. Declare A Page's Language in HTML You can and should do that via HTML. This way, if your website's accessed: from a different country by a visitor with different language settings … the screen reader “detecting” its default language will be quick to translate it. Note: if you have snippets of text in a language different from the default one on your website, remember to add a new language tag to each snippet. This way, you'll be signaling to screen readers that those specific parts should be translated accordingly. 4. Keep Your Links Short, but Not Too Short Try to find that ideal balance between confusingly long and ineffectively short text for your links. It's one of the “trickiest” parts of writing HTML code for screen readers: if you use too many words, since the link will get read out loud by the screen reader, it might just confuse the visitor in question if you make it too short, those users who rely on screen readers but still use their mouses to navigate websites might just... miss it 5. Use Semantic Tags: Make Your Content Readable and Understandable What do you think of when you say “semantic tags”? Tags like <b>, for bold text (and, therefore important information) or <i> for italicized text (which might indicate a quote) might be the first the come to your mind, right? But still, these are indicators for how the text should be displayed. And that's irrelevant for visually-impaired users... By comparison, 100% semantic tags, like <strong> and <em> indicate to the screen readers how that text should be interpreted. They're valuable “stage directions” on how it should be read to enhance the users' understanding. 6. Structure Your Pages so They... Make Sense to Screen Reader Users Writing HTML code for screen readers means also structuring your web pages with accessibility in mind. So, ask yourself common questions like: when a visitors tells his/her screen reader to jump to the main context section on a page, are the links there short enough not to confuse him/her and long enough not to... miss them? does that main context make sense to someone who can't interpret visual details like color scheme, layout, route of navigation? Would he/she still be able to make sense of your web page's structure? The END! Needless to add that the list of ways that you could tweak your HTML code for screen readers, for enhancing accessibility, is a... never-ending one. Start by focusing on these 6 aspects that will help you develop the right mindset for accessibility then... keep adding on more techniques.
Silviu Serdaru / Mar 23'2019
Planning to build a social network with Drupal? A business community maybe? A team or department collaborating on an intranet or portal? Or a network grouping multiple registered users that should be able to create and edit their own content and share their knowledge? What are those key Drupal 8 modules that would help you get started? That would help you lay the groundwork... And there are lots of social networking apps in Drupal core and powerful third-party modules that you could leverage, but first, you need to set up your essential kit. To give you a hand with that, we've selected: 5 modules in Drupal 8, plus a Drupal distribution, that you'll need to start a perfectly functional social networking website, with all the must-have content management features and knowledge sharing tools. Before You Get Started: A Few Things to Take Care Of First of all, let me guess the features on your must-have list: articles groups photos user profiles groups forums It should feature pages with dynamic content leveraging a fine-grained access system and social media hubs, right? Well, now that we've agreed on this, here are the preliminary steps to take before you get actually started, installing your key modules and so on: configure your “Taxonomy” categories after you've installed the Forum module set up a custom content type for Blog posts set up your thumbnail settings for the Article nodes create your key user roles (admin, content author, paid subscriptions) use the PathAuto module to define your URL path structure define your Article nodes' thumbnail settings and remember to upload an anchor image, as well 1. Panels Panels and Views make a “power team” to rely on for setting up pages with dynamic content for your social networking site. What makes it a must-have module to add to your essential kit when you build a social network with Drupal? It enables you to create custom layouts for multiple uses. You get to use it to set up your website's homepage, one featuring multiple Views blocks with dynamic content retrieved from forums, articles, blogs... Feel free to add a top slideshow image, to go for multiple-tiled stacked layout, including views from forum, blog and article posts... In short: the Panels module empowers you to get as creative as possible when setting up fine-tuned layouts for your landing pages displaying dynamic content. 2. Views Not only that it enables you to present content to your social network's registered users in pretty much any form you might think of — tables, lists, blocks, forum posts, galleries, reports, graphs — but it also: enables you to display related content (e.g. display a list of the community members along with their pieces of content) enables you to use contextual filters It'll turn out to be one of the handiest Drupal 8 modules in your toolbox when you need to create and display dynamic content from: forums blocks blogs Yet, maybe one of the most common use cases for the Views module on a social networking website is that of: Setting up a (Views) page listing all the article posts. 3. Blog Another module you'll most certainly want to add to your social networking website as it: enables both single and multi-user blogs empowers authorized site members to maintain it Speaking of which, blog entries can be either public or private for a specific user, depending on the role he/she's assigned with. And it's precisely that system of user roles and corresponding permissions set up on your website that will determine whether a member can: access the “Create Content” link or not access a “My Blog” section or... not You can further leverage this Blog module to add a “Recent blog posts” block to your webpages, in addition to the “Blogs” navigation link on your main navigation menu. 4. Profile, a Must-Have Module to Build a Social Network with Drupal You just can't imagine that you could build a social network with Drupal without a module enabling you to create registration page fields, now can you? Well, here it is: the Profile module. And here are its “superpowers”: it enables configurable user profiles it enables expanded fields on the user registration page it provides social network members with two different links, one for their account settings, one for their user profiles it provides private profile fields (that only the admin and that specific user can access) it enables you to set up different profile types for different user roles with... different permissions granted 5. Group The sky is the limit in terms of what the Group module enables you to do when you build a social network with Drupal: it powers pretty much any scenario you can think of, from subgroups to specific per-group behavior, to access permissions... it enables you to put together content collections on your website and grant access to it based on your user roles and permissions policy it enables you to easily add relevant metadata to define the group & content relationships on your site it enables you to control all your settings via a user-friendly admin UI; no need to write custom code to determine what each group is allowed and not allowed to do on your social network Open Social I just couldn't help it... Even though this was supposed to be a roundup of those essential modules you'll need to build a social network with Drupal, I had to add this Drupal distribution, as well. Open Social is that out-of-the-box solution that you can leverage to get your online user community up and running in no time. An open source software with all the needed features and functionality already pre-built, so that you can enable members on your network to: work together share knowledge organize events Convenience at its best when you want to start a social networking website without worrying much about: installing a whole collection of modules doing custom work in the “backstage”. The END! This is the minimal kit you'll need to build your online community website with Drupal. Would you have added other essential modules to the list?
RADU SIMILEANU / Mar 16'2019
The earth is round and images are “the usual suspects” of too long page loading times... Along with video content. So, what do you do? You comprise, of course. And then you face a major challenge: resizing images for the web without impacting their quality. What file format should you select when saving your images for the web? And what type of compression should you choose? How do you strike a balance between an image file's ideal size and that quality standard that you've set for your website? On one hand, you strive to optimize your images for the web — to reduce their sizes — and thus to improve your website's overall speed and the user experience delivered there. But, on the other hand, you risk affecting precisely the user experience if you over-comprise your images and compromise their quality. Now, time to shed some light on this “size vs quality” dilemma here: 1. What Does It Mean to Optimize Images for the Web? In short: what does Google expect you to do when it suggests you to optimize the images on your website for improving your page loading times? To reduce your image file sizes... This way, you'd lift some of the weight and give your load time a speed boost! You can do that either manually, using a script/plugin or... both. And, when it comes to compressing images for the web, you have 2 common methods to choose from: lossy compression lossless compression And we'll be delving into details in a bit... What I want to stress out now is a bad practice that too many website owners stubbornly stick to: Even though image optimization is one of the easiest ways that one can improve his website's performance, it's too often the most underrated one, as well. Resizing images for the web means no more than: saving your images in the correct format using the context-appropriate image compression method 2. Choosing the Best Image File Format for Web: JPG vs PNG vs SVG vs GIF What does it mean to save your images for the web “correctly”? What file type should you use, more specifically? Here are the most commonly used ones along with helpful suggestions on their best use cases: 2.1. The JPG Image Format Opt for a JPG (or JPEG) file format when you optimize your images for the web if it's screen shorts and general photos that you're saving. Images that include many colors... Now, what you do need to keep in mind is that: The JPG format helps you reduce the files' sizes for the web, but with a loss in the quality of your images. And here we get to the compression technique specific to this file format: the lossy compression. It's a filter that, for the sake of decreasing the image's size, removes some of the data from the original file. This can only affect the quality of the image who's size you're trying to reduce. Do keep in mind that this “degradation” process is irreversible... In short: your web page will load faster, yet at the cost of your image's quality. The more you'll try to compress it, the... uglier it'll get. The solution? When you're faced with a scenario that requires this type of image format (e.g. saving images with lots of colors, complex still images), strike a balance between its quality and its size. Just mind you don't over-reduce its size in the name of page loading speed... 2.2. The PNG Image Format Choose the PNG format when resizing your images for the web if you do need high resolutions and high detail. If it's simple images that you're saving (instead of fine-art photos with lots of colors). Wondering what's the compression technique specific to this file format? The lossless compression: A technique where the image's size gets reduced with no compromise on its quality. 2.3. The GIF Image Format There's no point adding that it's a file format specific to animations. When compressing your animated GIFs, it's the lossless technique that's being used. In other words, no need to worry about the loss of quality. 2.4. The SVG Image Format Is it a logo, text, icon, or simple image that you're planning to optimize for the web? And are you looking for an image format that supports animation and interactivity? Opt for the SVG format then. Here are some more reasons why it might be the most suitable one for your use case: Google indexes SVGs, JPGs, and JPGs the same way; there would be no impact on your website's SEO SVG image files are scalable, by default, in both photo editing tools and browsers in most cases, SVG files are lighter than JPG and PNG image files 3. Resizing Images for the Web: Lowest File Size vs Acceptable Quality What's that reasonable file size that you should target, that would preserve an acceptable quality of your images? How do you strike a balance between compression rate and “decent” quality? you choose the appropriate file format for the type of image that you're trying to optimize and, implicitly, the suitable compression method, for that image format, as well Yet, nothing beats “the golden rule of moderation” when looking for the balance between size and quality: Opt for a medium compression rate. Don't get “greedy”, don't reduce your images' sizes to the point of affecting their quality. Even if it's top page load speed that you'd be gaining (and speed is UX, right?), the poor quality images resulting will still have a negative impact on the user experience. 4. Web Images Best Practices Here's some sort of “guide”, including all the essential must-dos when resizing images for the web and optimizing them for an improved page loading time: save them in the correct file format save them at the appropriate size choose lossy compression, whenever possible lazy load images, when possible, for better page load times use pixels instead of inches when sizing images for the web; DPI — dots per inch — is not fit for the layout on the web automate the process, as much as possible go with a plugin that would compress and optimize your images externally, on their servers; this way, you'd be offloading your own website use web fonts instead of text within your images; they take less space and scale better when creating Retina images, make sure they're two times larger and, therefore, clear enough once displayed on the Retina device; the quality of the images should be the highest possible on your Retina Display-driven website The END! These are our tips and tricks on resizing images for the web and optimizing them without risking to affect their quality. What other best practices would you have included? Photo by Markus Spiske on Unsplash
Adriana Cacoveanu / Mar 13'2019
Why not stick to a traditional web hosting server? Why use a CDN, as well? After all, you can run your website, upload your videos and images and deliver content to your website visitors without relying on a CDN, right? Why bother, then? Do the benefits outweigh the costs? And is faster content delivery the only major advantage for implementing it? Now, let's look for some straight answers: 1. What Is CDN? It's a network of nodes... Nodes that are, in turn, mini-networks of systems and servers. What all these clusters of servers do is store content as cache (graphics, media files, text, documents, live video streaming data, scripts etc.) and serve it to their nearest users. The main benefit of using a CDN is the reduced distance that the data request would need to travel from the browser to the central data location. And also the reduced distance of the retrieved content from the server back to the end user's web browser. In this case, there would always be a server closer to the website visitor to process his request in a shorter time. Just imagine this benefit in the context of a peak load, like a flash sale on your website, with users from all over the globe flooding in. 2. Why Use a CDN: 8 Powerful Benefits 2.1. It Reduces Your Web Page Load Times The significant push that a CDN gives to content delivery is the top reason why website owners opt for a CDN. The process behind it, the main “culprit” for the reduced page load times, can get summed up to this: A CDN would always retrieve data from its nearest node. The shorter the distance for the content request to go through, the quicker the page receiving that data will load. As simple as that... 2.2. It Secures Your Website Against DDoS Attacks But first: “What are DDoS attacks?” They're those types of attacks when a hacker holds the resources on your server by “overwhelming” it with a heavy load. One causing your website to crash down... Now, how would a CDN help you prevent these malicious attempts? What does a CDN do, more precisely? It enables you to implement WAFs (web application firewalls) and “origin shields”, that will mitigate any attempt of a DDoS attack. And, since we've tackled the “boosted security” aspect, here are some other ways that a CDN can tighten the shield around your website: the CDN edge servers: they withhold the heaviest load on your website, keeping it up and running even at traffic peaks; any attack on your server will first have to go through these edge servers, which, due to the decentralization of the data, won't bail on you you get to opt for a proxy and thus hide the origin of your IP address you can implement an SSL; even if the attackers manage to take over your server's resources, their access will then automatically... self-expire. 2.3. Your CDN-Based Website Gets Robust Enough to Withstand Peak Traffic Why use a CDN? Because it doesn't fail on you/your website when heavy loads of traffic strike. Thanks to its evenly distributed network of nodes, it's equipped to withstand any traffic “tsunami”. If one node fails, there's always a neighboring server ready to back it up and take on the load. 2.4. You'd Cut Down On Your Bandwidth Costs How? Well, it's quite obvious: with multiple edge servers installed in a CDN, you reduce the strain put on your hosting server (your origin server); the load will then get distributed among the CDN nodes therefore, you'd offload CPU and use less server resources which will automatically translate into a lighter bill from your web hosting provider Just imagine the bandwidth you'd save at traffic spikes... And there's more! Another benefit of using a CDN is that it provides hotlink protection. This way, you can prevent others from embedding your assets on their own websites (which would otherwise turn into a “surprise” cost on your bill) 2.5. It's More Cost-Effective in the Long Run When you hear of giants like Netflix implementing a CDN solution you inevitably tell yourself: “Yes, but they can afford it." Time to bust this myth that a CDN integration is highly expensive once and for all. Just think about it: A CDN would handle +60% of the total load on your website. So, your origin server would be using less bandwith for bearing its share of the load. That can only lead to a “friendlier” bill from your hosting provider. In short: a CDN is less costly in the long run. 2.6. Higher Ranks in the SERPs & Enhanced User Experience And high loading speed is user experience... Your website visitors will benefit from the speed that a CDN “injects” into your website, whereas Google will reward it with a push in the SERPs. Use a CDN for images, since it's geared at increasing the crawl rate of media content (e.g. images). In a traditional web hosting scenario, you'd have to restrain yourself from uploading too many images, since they're the main “culprit” for low page loading speed. That's not the case when you have a CDN solution hosting them... 2.7. It Helps Your Website Overcome the Scalability Hurdle Why use a CDN? Because it's built with scalability in mind. Scalability which goes hand in hand with... availability. If, at some point, you need to expand to new geographic locations, your CDN will have got your covered: The cached content on your website will be available across a whole network of POPs, located in different regions. Therefore, any high load of traffic will be dynamically routed from one server to another, if one happens to... succumb. No matter the scalability challenge that your website might be faced with, you can be sure it will manage to deliver its content at high speed. 2.8. Faster Streaming Video And this is no negligible benefit of using a CDN since video content's been ruling supreme for a while now. By cutting down the time-frame, a CDN geared at delivering dynamic content will automatically reduce the video latency. The time elapsed from the instant that a request is submitted to the moment it gets a response from the server is drastically shorter. The END! Have you got your answer now to the “why use a CDN?” question? Photo by Ken Treloar on Unsplash.
RADU SIMILEANU / Mar 08'2019
We wanted to share this good news with you: OPTASY, the Canadian Drupal firm, has been ranked as a 2019 "Canada leader" in 3 categories of the Clutch annual list. Top Development Firms in Canada Canada Top Web Developers Best PHP Developers in Canada Thank you! For taking the time to answer the Clutch team's questions and give your honest feedback on working with us. For challenging us to be our best and turn our expertise into your results. We're looking forward to working with you on new projects. Sincerely, The OPTASY team
Adriana Cacoveanu / Mar 07'2019
“Should I stay or should I go?” Should you stick to an all-too-familiar traditional CMS and “reap” the benefit of getting loads of much-needed functionality out-of-the-box? Or should you bid on flexibility, top speed, and versatility instead? In a headless CMS vs traditional CMS “debate”, which system best suits your specific needs? Now, let me try and “guess” some of the CMS requirements on your wishlist: to have all the needed functionality “under the same hood” (a predefined theme, robust database, a user-friendly admin dashboard...) to be developer friendly to integrate easily and seamlessly with any modern JS front-end of your choice to “fuel” your website/app with high speed Needless to add that: You can't have them all in one CMS, either traditional or headless. What you can actually do is: set up a hierarchy with all your feature needs and requirements set it against each of these two types of CMSs' advantages and limitations Just see which one of them “checks off” the most requirements on your list. Then, you'd have yourself a “winner”. So, let's do precisely that: A headless CMS vs traditional CMS comparison to help you determine which one's... a better fit for you. 1. Traditional CMS: Benefits and Challenges Everything in one place... That would be a concise, yet fully comprehensive definition for the traditional CMS. Just imagine a content management system that provides you with all the critical features and functionality, all the needed elements straight from the box: a generic theme a dashboard for easily managing your own content a predefined database PHP code for retrieving the requested content from your database and serving it to the theme layout The back-end and front-end, meaning the code, database, and the layout/design, are “under the same hood”, strongly coupled. It's all there, pre-built, at hand... “Convenience” must be another word for “traditional CMS”. Security & Performance: A Few Challenges to Consider Getting all that critical functionality out-of-the-box does translate into... code. Lots and lots of code, lots and lots of files. Which also means lots and lots of potential vulnerabilities to be exploited. There could be an error in any of the files in that heavy load of files that you get. Or a query string parameter that could be turned into “free access” into your database... Therefore, the convenience of built-in functionality does come with its own security risks. Also, whenever you make a “headless CMS vs traditional CMS” comparison, always be mindful of the maintenance aspect: Of the upgrading that you'll need to perform with every new security patch that gets released. Now, as regards the performance “pumped” into your traditional CMS-based website/application, just think: compiling files. That's right! Consider all those custom files, in addition to the pre-defined ones that you'll be provided with, that you'll pile up for... customizing your website. All these files, all the new libraries that you'll want to integrate, will need to get compiled. Which can only mean: more stress put on your server memory copying code of functionalities that you might not even use a poor page loading time, with an impact on the user experience provided on your website 2. A Traditional CMS Is the Best Choice for You If... Now, you must be asking yourself: “How do I know if a traditional CMS is the best fit for my own use case?” My answer is: You go through the here listed “scenarios” and see if any of them matches your own. you already have a team of PHP experts with hands-on experience working with a particular CMS (Drupal, WordPress...) it's a stand-alone website that you need; no other applications and tech stack that might depend on a CMS's provided functionality you're not opinionated on the technology that your website will get built on 3. Headless CMS: What Is an API-Based Website, More Precisely? “It's a CMS that gives you the flexibility and freedom to build your own front-end — Angular, Rails, Node.js-based, you name it — and integrate it with content management tools via an API." In short: your headless CMS can then serve raw content — images, text values — via an API, to a whole “ecosystem” of internet-connected devices: wearables, websites, mobile apps. And it'll be those content-consuming devices' responsibility to provide the layout and design of the content delivered to the end-users. What's in it for you? it dramatically streamlines the development cycle of your API-based website; you can get a new project up and running in no time there's no need to pile up lots and lots of files and the code of out-of-the-box functionalities that you might not even need if there's a particular service that you need — store form submissions or a weather forecast — there's always a specific service with an API that you could integrate to have that particular content served on your website A headless approach gives you the freedom to integrate exclusively the functionalities that you need into your website. Moreover, you still get a dashboard for easily managing your content. Your headless CMS will have got you covered on this. With no code being “forced” into your website/mobile app or need to perform a performance “routine” for this. You get it by default. Security and Performance: Main Considerations In terms of security, a short sentence could sum all the advantages that you can “reap” from having an API-based website: There's no database... Therefore, there are no database vulnerabilities, no unknown gateway that a hacker could exploit. Furthermore, in a “headless CMS vs traditional CMS” debate, it's important to outline that the first one doesn't call for an administration service. Meaning that you get to configure all those components delivering content to your website as you're building it. Except for that, the rest of the dynamic content gets safely stored and managed in your headless CMS. “But can't anyone just query the service endpoints delivering content on my API-based website?” True. And yet, there are ways that you can secure those channels: use double-authentication for sensitive content be extra cautious when handling sensitive data; be mindful of the fact that anyone can query the JS implementation Now, when it comes to performance, keep in mind that: It's just assets that your web server will provide. As for the content coming from all those third-party services that your headless CMS is connected with, it will get delivered... asynchronously. Now, considering that: most of those endpoints are hosted in the cloud and highly flexible the first response — the first static HTML file that gets served — is instant you could go with a headless CMS that leverages a CDN for delivery in a traditional CMS scenario the website visitor has to wait until the server has finished ALL the transactions (so, there is a bit of waiting involved in there) … you can't but conclude that in a “headless CMS vs traditional CMS” debate, the first one's way faster. 4. Use a Headless Approach If... you already have your existing website built on a specific modern tech stack (Django, React, Node.js, Ruby on Rails) and you need to integrate it with a content management system, quick and easy you don't want your team to spend too much time “force-fitting” your existing tech stack into the traditional CMS's technology (React with... WordPress, for instance) you need your content to load quickly, but you don't want a heavy codebase, specific to traditional CMSs, as well you want full control over where and how your content gets displayed across the whole ecosystem of devices (tablets, phones, any device connected to the IoT...) you don't want to deal with all the hassle that traditional CMS-based websites involve: scaling, hosting, continuous maintenance 5. Headless CMS vs Traditional CMS: Final Countdown Now, if we are to sum it up, the two types of CMSs' pros and cons, here's what we'd get: Traditional CMS It comes with a repository for your content, as well as a UI for editing it and a theme/app for displaying it to your website visitors. While being more resource-demanding than a headless CMS, it provides you with more built-in functionality. Headless CMS It, too, provides you with a way to store content and an admin dashboard for managing it, but no front-end. No presentation layer for displaying it to the end user. Its main “luring” points? it's faster it's more secure more cost-effective (no hosting costs) it helps you deliver a better user experience (you get to choose whatever modern JS framework you want for your website's/app's “storefront”) It's true, though, that you don't get all that functionality, right out-of-the-box, as you do when you opt for a traditional CMS and that you still need to invest in building your front-end. In the end, in a “headless CMS vs traditional CMS” debate, it's: your own functionality/feature needs your versatility requirements the level of control that you wish to have over your CMS your development's team familiarity with a particular technology … that will influence your final choice. Photo from Unsplash
Silviu Serdaru / Mar 06'2019
Which of those Drupal modules that are crucial for almost any project make you want to just... pull your hair out? For, let's face it, with all the “improving the developer experience” initiatives in Drupal 8: BigPipe enabled by default the Layout Builder Public Media API and so on … there still are modules of the “can't-live-without-type” that are well-known among Drupal 8 developers for the headaches that they cause. And their drawbacks, with a negative impact on the developer experience, go from: lack of/poor interface to a bad UI for configuration to hard-to-read-code too much boilerplate code, verbosity to a discouragingly high learning curve for just some one-time operations Now, we've conducted our research and come up with 4 of the commonly used Drupal modules that developers have a... love/hate relationship with: 1. Paragraphs, One of the Heavily Used Drupal Modules It's one of the “rock star” modules in Drupal 8, a dream come true for content editors, yet, there are 2 issues that affect the developer experience: the “different paragraphs for different translations” issue the deleted (or “orphaned”) paragraphs that seem to “never” leave the database for good Developers are dreaming of a... better translation support for the Paragraphs module. And of that day when the deleted pieces of content with paragraphs data don't remain visible in their databases. 2. Views Here's another module with its own star on Drupal modules' “hall of fame” that... well... is still causing developers a bit of frustration: You might want to write a query yourself, to provide a custom report. In short, to go beyond the simple Views lists or joins. It's then that the module starts to show its limitations. And things to get a bit more challenging than expected. It all depends on how “sophisticated” your solution for setting up/modifying your custom query is and on the very structure of the Drupal data. Luckily, there's hope. One of the scheduled sessions for the DrupalCon Seattle 2019 promises to tackle precisely this issue: how to create big, custom reports in Drupal without getting your MySQL to... freeze. 3. Migrate There are plenty of Drupal developers who find this module perfectly fit for small, simple website migration projects. And yet, they would also tell you that it's not so developer friendly when it comes to migrating heavier, more complex websites. Would you agree on this or not quite? 4. Rules Another popular Drupal module, highly appreciated for its flexibility and robustness, yet some developers still have a thing or two against it: It doesn't enable them to add their own documentation: comments, naming etc. And the list could go on since there are plenty of developers frustrated with the core or with the Commerce Drupal module... The END! What do you think of this list of Drupal modules that give developers the most headaches? Would you have added other ones, as well? What modules do you find critical for your projects, yet... far from perfect to work with?
Adriana Cacoveanu / Mar 01'2019
3 Types of Content Management Systems to Consider in 2019: Traditional CMS vs Headless CMS vs Static Site Generators
Kind of stuck here? On one hand, you have all those software development technologies that are gaining momentum these days — API, serverless computing, microservices — while on the other hand, you have a bulky "wishlist" of functionalities and expectations from your future CMS. So, what are those types of content management systems that will be relevant many years to come and that cover all your feature requirements? And your list of expectations from this "ideal" enterprise-ready content infrastructure sure isn't a short one: to enable you to build content-centric apps quick and easy multi-languages support user role management a whole ecosystem of plugins inline content editing to be both user and developer-friendly personalization based on visitors' search history to support business agility search functions in site ... and so on. Now, we've done our research. We've weighed their pros and cons, their loads of pre-built features and plugins ecosystems, we've set them against their “rivaling” technologies and selected the 3 content management systems worth your attention in 2019: But What Is a Content Management System (CMS)? A Brief Overview To put it simply: Everything that goes into your website's content — from text to graphics — gets stored in a single system. This way, you get to manage your content — both written and graphical — from a single source. With no need for you to write code or to create new pages. Convenience at its best. 1. Traditional CMS, One of the Popular Types of Content Management Systems Take it as a... monolith. One containing and connecting the front-end and back-end of your website: both the database needed for your content and your website's presentation layer. Now, just turn back the hands of time and try to remember the before-the-CMS “era”. Then, you would update your HTML pages manually, upload them on the website via FTP, and so on... Those were the “dark ages” of web development for any developer... By comparison, the very reason why content management systems — like Drupal, WordPress, Joomla — have grown so popular so quickly is precisely this empowerment that they've “tempted” us with: To have both the CMS and the website's design in one place; easy to manage, quick to update. Main benefits: your whole website database and front-end is served from a single storage system they provide you with whole collections of themes and templates to craft your own presentation layer quick and easy to manage all your content there are large, active communities backing you up Main drawbacks: they do call for developers with hands-on experience working with that a specific CMS except for Drupal, with its heavy ecosystem of modules, content management systems generally don't scale well they require more resources — both time and budget — for further maintenance and enhancement A traditional CMS solution would fit: a small business' website a website that you build... for yourself an enterprise-level website … if and only if you do not need it to share content with other digital devices and platforms. You get to set up your website and have it running in no time, then manage every aspect of it from a single storage system. Note: although more often than not a traditional CMS is used to power a single website, many of these content infrastructures come with their own plugins that fit into multi-site scenarios or API access for sharing content with external apps. 2. Headless CMS (or API-First Pattern) The headless CMS “movement” has empowered non-developers to create and edit content without having to get tangled up in the build's complexities, as well. Or worrying about the content presentation layer: how it's going to get displayed and what external system will be “consuming” it. A brief definition would be: A headless CMS has no presentation layer. It deals exclusively with the content, that it serves, as APIs, to external clients. And it's those clients that will be fully responsible for the presentation layer. Speaking of which, let me give you the most common examples of external clients using APIs content: static page application (SPA) client-side UI frameworks, like Vue.js or React a Drupal website, a native mobile app, an IoT device static site generators like Gatsby, Jekyll, or Hugo A traditional CMS vs headless CMS comparison in a few words would be: The first one's a “monolith” solution for both the front-end and the back-end, whereas the second one deals with content only. When opting for a headless CMS, one of the increasingly popular types of content management systems, you create/edit your website content, and... that's it. It has no impact on the content presentation layer whatsoever. And this can only translate as “unmatched flexibility”: You can have your content displayed in as many ways and “consumed” by as many devices as possible. Main benefits: front-end developers will get to focus on the presentation layer only and worry less about how the content gets created/managed content's served, as APIs, to any device as a publisher, you get to focus on content only it's front-end agnostic: you're free to use the framework/tools of choice for displaying it/serving it to the end-user Main drawbacks: no content preview you'd still need to develop your output: the CMS's “head”, the one “in charge” with displaying your content (whether it's a mobile app, a website, and so on) additional upfront overhead: you'd need to integrate the front-end “head” with your CMS In short: the headless CMS fits any scenario where you'd need to publish content on multiple platforms, all at once. 3. Static Site Generators (Or Static Builders) Why are SSGs some of the future-proofed content management systems? Because they're the ideal intermediary between: a modular CMS solution a hand-coded HTML site Now, if we are to briefly define it: A static site generator will enable you to decouple the build phase of your website from its hosting via an JAMstack architectural pattern. It takes in raw content and configures it (as JSON files, Markdown, YAML data structures), stores it in a “posts” or “content” folder and, templating an SSG engine (Hugo, Jekyll, Gatsby etc.), it generates a static HTML website with no need of a CMS. How? By transpiring content into JSON blobs for the front-end system to use. A front-end system that can be any modern front-end workflow. And that's the beauty and the main reason why static site generators still are, even after all these years, one of the most commonly used types of content management systems: They easily integrate with React, for instance, and enable you to work with modern front-end development paradigms such as componentization and code splitting. They might be called “static”, yet since they're designed to integrate seamlessly with various front-end systems, they turn out to be surprisingly flexible and customizable. Main benefits: they're not specialized in a specific theme or database, so they can be easily adapted to a project's needs Jamstack sites generally rely on a content delivery network for managing requests, which removes all performance, scaling, and security limitations content and templates get version-controlled right out of the box (as opposed to the CMS-powered workflows) since it uses templates, an SSG-based website is a modular one And, in addition to their current strengths, SSGs seem to be securing their position among the most popular types of content management systems of the future with their 2 emerging new features: the improvement of their interface for non-developers (joining the “empower the non-technical user” movement that the headless CMS has embraced); a user-friendly GUI is sure to future-proof their popularity the integrated serverless functions; by connecting your JAMstack website with third-party services and APIs, you get to go beyond its static limitation and turbocharge it with dynamic functionality To sum up: since they enable you to get your website up and running in no time and to easily integrate it with modern front-end frameworks like Vue and React, static site generators are those types of content management systems of the future. The END! What do you think now? Which one of these CMS solutions manages to check off most of the feature and functionality requirements on your wishlist?
RADU SIMILEANU / Feb 26'2019