How should you prepare for Drupal 9? You deep clean up your codebase of all deprecations and errors and wait patiently for the big upgrade to... happen.
“But how do I know whether my Drupal website's using any code deprecations?” you'll legitimately ask yourself.
How do you identify and make an inventory of all the code errors on your site, so you can remove them and start... waiting, patiently, for that big upgrade to Drupal 9?
Well, you “stuff” your toolbox with all the essential tools that'll help you track down deprecations (still) lurking in your codebase.
Here are the 5 most effective ones:
1. Drupal Check
You can't claim that you're getting ready for Drupal 9... the proper way if you're not already using Drupal Check to scan your codebase for deprecations.
“But what is Drupal check?”
It's a command-line tool — a custom runner for PHPStan — that enables you to run PHPStan against your Drupal website to look for any deprecations and code errors.
In short: instead of running PHPStan, you run Drupal Check, which comes as a package storing PHPStan, PHPStan Drupal, PHPStan's Deprecation Rules, plus configurations for them all, as well.
Source: glamanate.com
Just incorporate it into your build processes and continuous integration systems and run audits on:
your custom and contributed modules, checking their compatibility with Drupal 9
your D7 to D8 migration code
Use it on your existing Drupal 8 website. Or use it on the one that you're developing, when you're nearly done, to check whether any deprecations have made their way to your codebase...
Word of caution: expect Drupal Check to provide you with an accurate report of the deprecated code used on your site, but don't expect it to fix them for you, as well.
2. Upgrade Status Module
Here's another “tool” that you shouldn't miss from your toolbox. That if you do want your website's upgrade to Drupal 9 to be... buttery smooth.
Source: Drupal.org
What the Upgrade Status module does is:
inspect your code — your custom and contributed projects — for deprecations
make an inventory of all the identified issues
Moreover, its Drupal 8 version harnesses the power of PHPStan and comes as a complete solution that you can use for running full-site checks.
Let it work its “magic” on your Drupal site and find out where it stands in terms of compatibility with Drupal 9.
3. PHPStan & PHPStan-Drupal
PHPStan's the very foundation of the toolkit to rely on when you prepare for Drupal 9.
Source: Matt Glaman's Twitter page
Not only that you save valuable time using it, time that you'd otherwise invest in pinpointing every error spotted during your code reviews:
classes called incorrectly
nonexistent classes
PHP projects that you forgot to run once you compiled them
… but you get to write your own custom rules.
You get to indicate specific “red alarm” situations that you'd want PHPStan to... investigate for you.
Now, it may be the key tool to keep at hand when you evaluate your site's compatibility with Drupal 9, but nevertheless... it does have its own limitations:
It won't load any files on its own if you run it against a Drupal module out of the box. It depends on Composer to load all that information...
Luckily, Matt Glaman's developed an extension to address precisely this... limitation of PHPStan: phpstan-drupal.
An extension that'll help you make the most of PHPStan when using it to scan Drupal code: from your various dependencies to... Drupal core.
4. Use Project Deprecation Status to Prepare for Drupal 9
And what this tool does is answer one key question:
“What's the current status of the Drupal modules in terms of compatibility with Drupal 9?”
Which Drupal projects are already compatible and which of them need more fixing before the big upgrade?
Project deprecation status is the right tool to... gain an accurate picture of where each Drupal project stands in relation to upcoming Drupal 9.
5. Rector
So far I've pointed out the 4 key tools for deep-scanning your Drupal website to detect any uses of deprecated code as you prepare for Drupal 9.
But what if you want to get rid of that pile of deprecations that you will have collected by the end of the scanning process?
How do you fix/remove them?
And, more importantly: how do you automate this code cleaning process?
In this respect, Rector for Drupal 8 — a proof of concept for now — comes with great potential:
Check it out and... be prepared to add it to your toolbox for any automated deprecation fixes that you'll want to perform on your site.
The END!
These are the 5 essential tools to have in your toolbelt for running deprecation checks on your Drupal website, getting all ready for Drupal 9.
Would you have added some other must-have tools to the list, as well? Let us know in the comments here below:
Image by Michael Schwarzenberger from Pixabay
Silviu Serdaru / Nov 22'2019
"What's new in Drupal 9?" or "What are the new features in Drupal 9?"
These 2 questions are on everyone's lips these days, both Drupal teams and organizations using Drupal.
How about a... shiny new main theme?
For, let's face it: we've been longing for a new default theme in Drupal for some time now...
The current one, Bartik, hasn't got an update since... 2011 and it has started to show: Drupal 8's outgrown its core theme.
The new one, Olivero, which is still just design with a proof of concept, is expected to address all of Bartik's limitations:
to be more simple
to be more modern
to be more flexible
to support Drupal's increasingly powerful functionality
But let's dig in for some more info about this initiative:
why do you need a new default theme in Drupal?
the key design principles established for this theme
the main components of the new design system
1. How Does Your Ideal Default Theme for Drupal Look Like?
Does it resemble Bartik?
I'm pretty sure it doesn't, judging by the fact that:
it hasn't seen a major change since January 2011
it still uses gradients, drop shadows and other out-of-date graphical elements
it no longer accommodates all the modern website functionality implemented in Drupal (e.g. Layout Builder) over the last years
Overall: Bartik has started to look a bit... out-of-fashion, while Drupal's back-end has been growing more and more robust.
Therefore, I bet that the words that you'd use to describe your "ideal" default theme in Drupal revolve around these key adjectives:
clutter-free/minimalistic
flexible: to provide plenty of options to choose from
light
modern and fresh
accessible
intuitive
elegant
clean
2. Olivero and The 3 Main Goals Behind this Drupal Core Initiative
No goal no... glory.
That's why the team behind this Drupal core initiative, Lullabot, set 3 major objectives for the Olivero theme:
it should support all the latest functionality implemented in Drupal: embedded media, second-level navigation, layout builder, etc.
it should be WCAG AA compliant from the ground up (accessibility should not be an afterthought)
it should look and feel more modern: all those design elements that made Bartik feel too heavy to be reduced to a minimum, while particular design system parts — color palette, typography, and animation — to be reconsidered
3. What's New in Drupal 9: Design Principles Set for Its Theme
Source: Dries Buytaert's blog
Curious which of the features on your wishlist for an ideal default theme have made it to the list of design principles for Olivero?
Well, here they are:
simple: clutter-free; by "clutter" they mean all colors, effects and visual elements that are irrelevant and make the theme look and feel too heavy
modern: support for modern browsers' features and interaction modes
flexible: presents Drupal (front-end) developers with multiple options to choose from
focused: includes all those design elements, like negative space and high contrast, that grab user attention
accessible: it's designed with WCAG AA conformity in mind; from functionality to layout, to colors, all elements should be thought out to be accessible for everyone
4. The Olivero Design System: Key Components
"What's new in Drupal 9?" Look forward to a new, promising design system.
I'll highlight just 5 of its components, so you can get an idea of what the team behind this initiative mean by "modern" and "flexible" in relation to the Drupal 9 default theme:
Source: Drupal.org
4.1. Color Palette
They chose:
bright blue as the base color
neutral grays to counterbalance the design elements and layout
darker colors to enhance accessibility
lighter colors in the layout to highlight the design elements
4.2. Typography
They used the size 18px for the base font in the body copy, to be leveled for metadata, headers, quotations, etc. and adapted to smaller viewports, as well.
Consistency, throughout line-height and spacing, has been a key goal when setting the scale for typography.
4.3. Header & Navigation
The flexibility principle is best reflected in the header of the future default theme for Drupal 9:
it's designed to incorporate, seamlessly, all logo types and text titles
it comes in multiple versions to choose from, one for every site identity type
it turns into a hamburger menu once the user scrolls down
4.4. Sidebar
The news factor is that in Drupal 9 you'll have one sidebar region instead of two competing for space on the screen.
A single spacebar, next to the primary content, where your content team can display related posts and all kinds of utility blocks.
4.5. Site Branding Variations
The Olivero theme will ship with background-color and width settings that you can configure in order to fit any text length and logo type.
5. Final Word
"What's new in Drupal 9?"
I think this question is not quite accurate, in relation to this upcoming front-end theme.
"What's bound to be new in Drupal 9?" is more appropriate.
For the Olivero theme is not yet... a theme in itself, but work-in-progress.
A proof of concept, a core initiative that's still calling out for contributors. One that's expected to become the new default theme in Drupal, that should:
accommodate all the new powerful features implemented in Drupal these last years
be accessible from the ground up
be (more) intuitive
Why would you care for this initiative if you were a Drupal developer?
Because it would improve your entire experience of working with Drupal.
Why would you care about this work-in-progress theme if you were considering Drupal for your next web project?
Because all visually-appealing websites have one thing in common: a modern, accessible and flexible theme.
Image by Mudassar Iqbal from Pixabay
Silviu Serdaru / Nov 13'2019
You're building a React website/application. You have your bulky list of functionalities all set, you know how you want it to look, but can't decide on the React framework to build it on: What's the main difference between Gatsby and Next.js, after all?
And what's the difference between server-side rendering and static site rendering?
Since both frameworks seem to be serving your main goals:
not to get tangled up in config or routing
to generate a fast, fully accessible and SEO-friendly website
to provide you with boilerplate application
So, what's the fundamental differentiator between Gatsby and Next?
The one(s) that'll help you identify the framework that best covers your specific use case.
Or, are there several of them (differentiators)? Just keep on reading:
1. But First: What Do Gatsby and Next.js Have in Common?
How are they similar?
they're both React frameworks
they're both great options for SEO purposes
they're both great options if you need a high performance React app/website
they both provide entirely formed HTML pages
they both provide boilerplate application
they both simplify and speed up the React app/website development cycle
they both generate SPA out-of-the-box
they both provide great developer experience
In short: both Next.js and Gatsby score well in categories like speed and SEO; they're both awesome solutions to streamline app/website development in React.
But the way they go about it... that's where these frameworks are fundamentally different.
2. How Does GatsbyJS Work?
It builds HTML code on build time.
That would be the short(est) answer to your question. But if we were to elaborate upon it:
GatsbyJS is a static site generator that... generates (static) HTML code during the “build” process. How? It fetches data from external sources — APIs, Contentful, WordPress, markdown files — and uses GraphQL to render it.
Example: say you have a blog. In this case, you could use Gatsby to fetch your blog posts from... Contentful. Or any other repository where you might be storing your content (e.g. WordPress or Drupal).
3. What's Next.js?
A tool for rendering pages on the server-side.
And a more detailed answer would be:
It's a React framework that supports server-side rendering. Meaning that it generates the needed HTML code dynamically, from the server, each time a request is being sent through.
In short: your browser's provided with pre-rendered HTML code instead of empty “div”.
Now, how does its distinctive way of going about building a React app/website suit you?
It enables you to develop multi-page applications using static rendering and serving dynamic data from a back-end.
4. What Are They Used For? Specific Use Cases for Gatbsy and for Next.js
What's the difference between Gatsby and Next.js in terms of use case?
In other words: when should you choose one over the other?
4.1. Specific Use Cases for GatsbyJS
1. Blogs and small-scaled websites
And I'm talking here about a particular scenario:
When you have no comments section on your blog or, at least, not a very “busy” one. So, a use case where you don't need to render content every 5-10 minutes.
Since blogs are static and their content doesn't change that frequently, Gatbsy's ecosystem makes the perfect fit for them.
And you have 2 options for your blog post creation and publishing process:
you write a blog post and the npm build will generate a corresponding HTML page
you write a blog post in Contentful (or a CMS of your choice), publish it and recompile your blog in Netfly
2. Landing pages
Again, since they use static content, landing pages make an ideal use case for GatsbyJS.
Where do you add that Gatsby “spoils” you with such a wide collection of plugins to choose from and to boost your landing page with: PWA, inline critical CSS, AMP...
4.2. Specific Use Cases for Next.js
1. Content-packed websites
Dealing with lots of content? Or are you expecting your site's content load to grow, over time?
Then Next.js should be your first choice.
The reason is simple:
Just imagine your Gatsby framework overstrained to rebuild all that content over and over again. Not precisely the most time-effective solution to go with, don't you think?
2. When you need more freedom for accessing your data
Do you want to empower your content team to publish content on their own? Then you might want to consider Next.js.
3. To-Do Apps
They make the perfect use case for server-side rendering:
Next.js retrieves the content for your list, from the server, and displays the to-do's upfront.
5. The Fundamental Difference Between Gatsby and Next.js Is...
… that Gatsby's a statically generator, while Next.js generates HTML dynamically.
Image by Colin Behrens from Pixabay
The first creates JS/HTML/CSS at build time, while the second generates it at run time.
Or, if you wish to put it this way:
Gatsby doesn't depend on a server, while Next can't function without one.
6.4 Other Main Areas Where They Differ
For the “Gatsby vs Next” debate doesn't end at the “static vs dynamic” comparison.
There are other factors, as well, that set these 2 React frameworks apart. And we'll outline the 4 most obvious ones:
6.1. Data Handling
In case of Gatsby, the framework's the one “deciding” how you should handle data in your app.
It needs to know where your data, your images and other types of content will be handled.
What's in it your for? Why would you accept this... “compromise”: to be told how to handle data in your own app?
Because:
Gatsby, through its rich collection of plugins, enables you to hook up your site to various data sources. This way, you gain external control over your data...
By comparison, Next's totally unopinionated.
Is gives you the freedom to decide your own data architecture.
In short: it doesn't “tie” you to a specific technology. You're free to handle data your own way.
6.2. Deployment
You can deploy Gatsby anywhere you need to, with no special configurations, since it's no more than compiled CSS, JS, and HTML.
And things are equally straightforward with Next.js, as well. Since it's a Node application, you can host it anywhere you want to...
6.3. Routing
With Gatsby, you have a pages directory where you're free to create all the HTML pages needed for your app/website.
Moreover, they provide you an API, as well, for creating routes dynamically.
With Next.js you get a “pages” folder, as well, where you can set up your new pages and get your app running, with no routing to config.
6.4. Plugins
“What's the main difference between Gatsby and Next.js?” Plugins sure are a powerful differentiator.
Gatsby comes “loaded” with an entire ecosystem of plugins.
So, do you need to have your JS minified, you CSS compiled, your...? There must be a Gatsby plugin for it.
Image by Michael Schwarzenberger from Pixabay
Next.js, on the other hand, doesn't “tempt” you with plugins, since its smaller scope doesn't justify the usage of plugins...
The END!
These are the key differences between Next.js and Gatsby, along with their common points and specific use cases.
Have you had your “Aha!” moment(s) reading through our post? Have you managed to identify the right framework for your own use case?
Photo by Charles ?ﾟﾇﾭ on Unsplash
Silviu Serdaru / Nov 12'2019
They're both open-source and some highly popular options for cross-platform app development. They're both backed by huge tech communities... so your struggle is real: "React Native vs Flutter: which one should I go with?"
On one hand, you have Flutter, which has gained momentum incredibly fast this year, putting the same question on most developers' lips:
Will Flutter replace React Native?
On the other hand, you have React Native, which has been around for +4 years now and uses "good old" JavaScript.
Should you place your bid on "familiarity" and reliability or should you take the leap and go with a newer, but so promising platform instead?
Speaking of which:
What are Flutter's selling points more precisely? Those that have instantly propelled it in developers' radar so quickly?
Why would you choose Flutter over React Native? And when is the latter the best option?
1. Why Choose Cross-Platform App Development in the First Place?
Why would you go with this approach to mobile app development instead of taking the "native" path?
Here are the most powerful reasons:
you get to write (most of) your code once and use it on multiple platforms
you get to tap into the features of your cross-platform framework of choice to develop various types of mobile apps: social apps, eCommerce apps, interactive apps
you get to build a native-like app without getting tangled up in Android, iOS or Java development
Notes:
optimizing your cross-platform app might get discouraging if you're not prepared for it
expect it to be less performant than its native counterpart
your platform of choice might not ship with all the functionalities that you need (Bluetooth, GPS...), so consider creating new plugins or opting for 3rd party ones to compensate for the lack of certain native features
2. React Native Is an...
... open-source JavaScript framework — or a new version of React, if you wish — launched by Facebook, used for building Android and iOS mobile apps.
Source: Facebook.Github.io
How does it work? What kind of "witchcraft" does happen under its hood that enables you to build a hybrid app? One that works both on iOS and Android?
React Native uses a JavaScript bridge which... bridges your UI code to native components.
3. Reasons Why You Would Choose React Native over Flutter: Top 3
Source: Google Trends
So, going back to our "React Native vs Flutter" dilemma: why would you go with Facebook's "prodigy"?
because it's written in JavaScript (entirely) and so it's much easier to find experienced JS developers for your app project
because it's more... mature: it's been around for +4 years, which translates into reliability and a high level of popularity among developers
because it streamlines the app's development cycle: it's faster (just think "ready-to-use components") to build app-like experiences with React Native than with Flutter
4. Flutter Is...
... Google's open-source SDK, written in Dart, used for building cross-platform apps.
How does it work?
It leverages the skia rendering engine to render Dart-based UI in both Android and iOS.
Source: Flutter.dev
4 Key Features of Flutter:
design-specific features
entirely customized environment
platform-specific SDKs
native-like performance
5. Flutter: Biggest Selling Points and Main Weaknesses
What makes this "new kid on the block" so tempting among developers?
Source: Stack Overflow
What does it bring to the table that React Native can't provide?
it's easier to install it: when using React Native, many developers choose to use Expo precisely for this purpose; there's no way of automating the whole process and you bump into errors pretty often
it's easier to test it compared to the complicated setup that you need to do for testing a React Native app
it uses proprietary UI widget sets (by comparison, React Native uses native components), which give you more freedom to customize your UI block components
it benefits from first-party support for its iOS-style and material design widgets
it uses object-oriented design (due to Dart)
it performs better: Flutter's slightly faster since it depends on a JavaScript bridge, like React Native, for interacting with native components
it speeds up the UI designing process (React Native uses native components, while Flutter uses owner widgets)
And this last one is Flutter's most "seductive" feature:
It allows you to create a new custom layout in no time.
"And why would I be hesitant to choose Flutter over React Native?" you might also ask yourself.
Here are some of the aspects that might discourage you from using Flutter for building your cross-platform app:
there aren't so many developers working in Dart, the language used for writing Flutter, compared to the deep pool of JS professionals
the development process is a bit lengthier
it's still relatively a young platform: you might not have a library for every functionality that you want to implement; not just yet...
6. React Native vs Flutter: You'd Be Better Off With...
... Flutter if:
you need to have your app running on both Android and iOS
you're already an experienced C++/Java developer (or developers in your team are), since it'll then be easier for you to learn Dart
high performance is on top of your priority list
you want a visually-appealing UI for your cross-platform app
And opt for React Native if:
you're already an experienced JavaScript developer
you put a high value on the support of a giant, mature tech community
The END!
How do the scores look like on your evaluation list?
Which of the 2 cross-platform solutions would you go with and why? Let us know in the comments below:
Photo by Coffee Geek on Unsplash
Silviu Serdaru / Nov 06'2019
It sure is “the thing” these days. But does that make it “the perfect... thing” for your project, as well? For your specific project needs and priorities? What is Next.js used for more precisely?
Can it handle both portfolio sites, let's say, and... particularly large web projects?
Is it the best fit for both rarely and frequently updating websites? For both websites depending on a rich third-party ecosystem and those that don't use so many libraries?
Let's dig up some answers on:
when (and when not to)
why
… to use Next.js.
1. But First: What Is Next.js?
It's a lightweight React framework used for server-rendered and static web applications.
Now, if we were to highlight some of its main features, any shortlist would have to include:
(default) server-side rendering
ecosystem compatibility
prefetching
HMR and Error reporting
automatic code-splitting
Note: since it resembles PHP development so much, many developers find it easy to “jump on the Next.js bandwagon”.
2. And How Does It Work?
Next.js renders your React app/website on a server (as opposed to being rendered on the client-side).
Source: GoogleDevelopers
So, do keep in mind that you'll need to have a server... somewhere.
The main gain here is that it supports scenarios where data has to be updated in real-time.
As for the drawbacks of server-rendering:
higher level of complexity: expect to write more code to get everything working properly
it's a bit more challenging when dealing with third-party services
a bit more difficult to deploy (compared to client-side rendering and HTML)
3. What Is Next.js Used for? What Types of Projects Would You Use It For?
Now, back to the question that generated this blog post in the first place:
When should you consider Next.js?
When is it the best choice? Does it serve your... specific use case, for instance?
In this respect, we've identified 3 types of projects that Next.js makes the best fit for:
3.1. When SEO is your top priority
Do you need SSR (server-side rendering) to ensure SEO-friendly pages on your website? Then Next.js is your only option.
It's built to serve precisely this type of project, where good SEO is a crucial objective.
3.2. When content gets updated particularly often
Let's say that new and new data gets uploaded on your website and that the content on your web pages needs to get updated within... 3 minutes, maximum.
Source: When Should You Use Gatsby?
And I'm thinking here:
news sites
large eCommerce websites
property listing websites where new comments get added and descriptions updated on a regular basis
In short: if you expect content on your future website to get updated often, then it writes Next.js all over your project.
4. Final Word
Now, would you care for a piece of advice? When trying to answer questions such as:
“What is Next.js used for?”
“Should I use it on my project or should I go with static?”
… make sure you evaluate both your short-term and long-term needs.
In other words: your website might not need to update its content frequently right NOW, but maybe you're considering scaling it up in the future...
For in that case, build performance and SEO will become some key requirements and your client-side or static architecture won't serve your goals anymore.
Just make sure you coordinate your final choice with your future goals, as well.
Image by Lynn Neo from Pixabay
Silviu Serdaru / Nov 04'2019
It's fast, it's secure, it boosts SEO and it provides a great developer experience, but does it fit your use case? For it all comes down to one key question: “When to use GatsbyJS?”
Is it suitable for both a portfolio or documentation site and an app with a large content base? Or a large-scale enterprise website, for instance?
Should you use GatsbyJS irrespective of your/your team's JavaScript experience?
What are the obvious and some of the... less expected use cases for GatsbyJS? Key benefits that would make you want to choose it over a framework like... NextJS, for instance?
Now, let me break down the strongest use cases of Gatsby for you.
See for yourself whether your own use case has made it to the list or not:
1. When to Use GatsbyJS? When You Need a Static Site... Obviously
GatsbyJS's is optimized for this particular use case, after all: generating static websites.
Say you have a static web page (a landing page), that serves plain HTML, some JS, and CSS. As for your more specific types of content, you plan to use Youtube and a platform like Medium to host it on.
Gatsby would make the perfect choice for your use case since:
it provides server-side-rendering out of the box
it ships with a heavy load of plugins to delve into (extract data from your CRM of choice: Contentful, Drupal...)
it has a robust data layer built-in
Use it to create pages dynamically from almost any data source.
2. Use It for Your Documentation/Personal Portfolio Website or Blog
Use GatsbyJS for your blog, eCommerce website, or any other general static site that's under 500 pages, where you don't expect to serve any kind of dynamic content.
Note: there are the obvious use cases of GatsbyJS and the more... project-specific ones.
The volume of content served on your website and the amount of traffic aren't always clear indicators of whether you should or should not use Gatsby.
It's all a matter of infrastructure and of whether:
you do afford a build process for your React-based web app
your team's experienced enough to get the most of a micro-service architecture and of serverless functions
you depend on a database that should reflect, instantly, any changes made
GatsbyJS's built to go beyond small/medium scale static sites if used to its full potential.
3. Use It When You “Crave” High Performance
Not only that it's fast by nature, but GatsbyJS even stands out from the crowd of static site generators...
If page load time is your main concern, you might want to consider Gatsby as your first choice.
4. Use It When Your Project Demands a High Level of Security
“When to use GatsbyJS?” you ask yourself.
When you need to add an extra layer of security to your website.
Since it serves plain HTLM files and there's no database or sensitive customer data stored on the server... there's not much to hack there, is it?
The only thing left to “contaminate” if they do manage to get in is... your HTML files.
5. Use It to Build Your Progressive Web App
For GatsbyJS is far more than just another static site generator:
It's designed, from the ground up, to be a PWA website framework.
Quote source: The New Stack
In this respect, it:
ships with robust progressive web app features
is built to be fast and highly accessible across all devices and in all hardware and network contexts
6. Use It If Developer Experience Is One of Your Top Priorities
Luckily enough for your development team, GatsbyJS provides a modern development environment: simple, robust tooling and powerful built-in features.
To give you just a few specific examples:
it automatically generates static assets like CSS and images from the “static” directory
it builds routes between pages automatically
it minifies everything “behind closed doors” before it serves it up to the client
7. Use It If You Have Enough JS/React Experience
One of the few constraints when it comes to using GatsbyJS is the above-the-average JS/React experience required.
There are no two ways about it...
Also, another answer to your “When to use GatsbyJS?” question is:
When you already have some React components or codebase available to reuse on your static web pages.
8. Use It if You Fancy a Huge Ecosystem of Plugins
Why use GatsbyJS?
Source: Reddit.com
Because it ships with an impressive collection of plugins.
Basically, it enables you to enhance your otherwise simple, static website with all kinds of powerful plugins:
you could just plug Google Analytics into your site
you could “inject” a gatsby-source-medium plugin and have previews of your articles automatically served up on your website
9. Use It if SEO Is Crucial for You
When to use GatbsyJS?
When the SEO factor is of critical importance to you.
The web performance boost that you'll get from powering your website with Gatsby — since it'll render static HTML only — won't go unnoticed by your users and... by Google itself.
Just make sure:
a static architecture is, indeed, the right fit for your project
you've configured your SEO settings properly
10. Use It with a Headless CMS
It's another one of those primary use cases for GatsbyJS:
Pair your Gatsby site with a CMS data source of choice (a “headless” CMS): Contentful, Drupal, Netfly, WordPress.
This way, you pass all the “worries” regarding hosting and serving your data over to your CMS.
GatsybyJS integrates seamlessly with any data repository, so you can focus on implementing your front-end instead.
The END!
These are the top 10 use cases for GatsbyJS, ranging from the most common to specific ones.
Which of its benefits — security, high performance, plugin system, developer experience, CMS integration — is more important for your own use case?
Image by nugroho dwi hartawan from Pixabay
Silviu Serdaru / Oct 25'2019
With no standardized chatbot testing method at hand, how can you ensure your bot is error-free and user-engaging?
What performance testing tools should you use?
What are the most effective mechanisms for testing its functionality? What metrics should you include in your scenarios?
In other words: what goes into a solid bot testing strategy?
In this respect, here's a chatbot testing checklist — tools, ground-rules, best practices, techniques, key considerations — aimed at helping you set your own standardized testing plan.
1. Test Your Bot's Conversational Flow
Engage your chatbot in a conversation.
Take it as a form of UI/UX testing, where the interface's given by the questions and replies that your bot serves up.
Start with the broad, user-greeting questions and critical use cases (or chatbot testing scenarios), then gradually tackle the edge cases, as well.
Your list of questions, as this stage of your chatbot testing process, should include:
Does my chatbot understand the user's questions?
Does it respond promptly to them?
Are its responses accurate enough and relevant?
Are there enough conversation steps or... too many?
Does it keep the user engaged?
2. Run a Custom, Domain-Specific Test
Now, you can imagine that including every single expression specific to your field and every possible question related to your services/product is... mission impossible.
And yet, you can still provide broad classes when setting your context-specific questions for the bot to answer to. Do pay great attention to how you formulate them and to what niche terms you include there:
This is that stage of the conversation where your chatbot provides credible information on your products/services.
Where it should influence the user into making a decision...
3. Include Developer Testing
It goes without saying that your team of developers working on your chatbot project will test it anyway while building it.
Developer Testing Photo by Studio Republic on Unsplash
For them, it'll be more of a verification and validation test. They will have predefined the bot's replies and set the users' inquiries, so at this stage they'll just:
Check whether the chatbot serves up accurate and relevant answers to a hypothetical user's questions.
4. Run a Chatbot-Error Handling Test
Or what you might call a “limit test”.
Image by Tumisu from Pixabay
While putting together your chatbot testing strategy, just ask yourself:
What if a user enters a meaningless sentence or a not so commonly used expression? How would my chabot respond to that?
Of course, you cannot possibly anticipate all the irrelevant information that users might enter. All the exceptions that your chatbot will be challenged to handle... elegantly.
And still, your developers should come up with “emergency replies” for those exceptions that you do anticipate.
This is that phase of your testing process where you check whether your bot provides understandable answers in such “exceptional” scenarios.
5. 3 Chatbot Testing Tools to Consider
“What tools can I use for chatbot testing?” you might ask yourself.
Here's a shortlist of 3 tools to consider streamlining your testing efforts with:
5.1. Chatbottest
An open-source guide packed with 120 questions for assessing the user experience that your chatbot delivers.
It operates at three levels:
possible chatbot testing scenarios
expected scenarios
almost impossible scenarios
And it provides you with 7 different metrics to use for evaluating your bot's performance:
Understanding: does your chatbot understand any kind of user input — curse words, small talk, idioms, emojis...?
Answering: are its answers context-relevant and accurate enough?
Navigation: is it intuitive enough for you to go through the conversation you're having with your bot?
Personality: does its tone suit your audience and the nature of the ongoing conversation?
Onboarding: is it clear enough to the user what your chatbot's functionality is, from the very start? Is it intuitive enough how he should interact with the bot?
Intelligence: does your chatbot “remember” certain details, key information that the user has provided throughout the conversation?
Error management: how does your chatbot handle errors and exceptions?
5.2. Botanalytics
From usability to conversational flow, to the delivered user experience, this custom service enables you to test every key aspect of your chatbot.
5.3. Dimon
The great thing about this chatbot testing tool is that it integrates seamlessly with major platforms like Telegram, Slack, WeChat, Facebook Messenger.
Use it to detect any issues in your bot's conversational flow, in the user experience that it provides.
6. Automate Your Chatbot Testing
“How can I automate my bot testing process?” is another valid question that might be “haunting” you.
You use a chatbot that'll interact with your own bot. No intervention from your side.
This way, you can run your conversation transcripts... automatically. Your job boils down to 1 key task: evaluating your chatbot's replies.
7. Final Word: It's an Ongoing Testing Process
Whether it's you, your development team or you opt for automated testing, any chatbot testing prior to its release is... beta testing, after all.
Real-life feedback, provided by its users, is the real test.
In other words: be ready to constantly adjust your chatbot to the feedback you get after its release.
Keeping it relevant, future-proofing its current performance calls for an ongoing testing process.
Image by mohamed Hassan from Pixabay
Silviu Serdaru / Oct 23'2019
How do you get from a large audience to an... actively engaged large audience? How do you turn that massive volume of traffic that you've striven to attract into... actual sales? It's simple: you incorporate interactive website features into your site.
For it's elements like built-in feedback system, chatbots, or interactive photos that would get that large audience of yours involved on your website.
A fast, visually stunning, and mobile-friendly website won't grant you more leads. Instead, a website that retains and connects with its visitors will...
But let's dive right into these (not so) “mysterious” website design interactive features that will help you boost user engagement on your site:
1. What Is an “Interactive” Website?
But first, let's see what an interactive website is NOT:
It's not a site that simply displays... content.
Instead, an interactive website IS, in fact:
A site that gets visitors to interact with its displayed content. Instead of merely “consuming” it...
A website that drives users to communicate with its interface by filling in popping-up forms, typing in comments, or clicking on the on-screen image of a product...
2. Why Does Your Website Need to Be Interactive?
In other words: why would you care about adding this level, as well, to the user experience delivered on your website?
I mean, your website's already super fast, visually striking, and conveniently responsive. It should be more than enough to... engage visitors, right?
Well, not really. Here are the strongest reasons why you should consider making your website strategically interactive, as well:
it cuts down your bounce rate: users tend to spend more time on a website that interacts with them than on a static one that reduces them to... mere content consumers
it builds long-term relationships: engaged visitors are much more likely to turn into... returning visitors
it boosts your brand awareness: interactive user experience is always a high impact one, that clings to visitors' memories, making your brand... memorable
it boosts user engagement (duh!): strategically placed interactive website features trigger more action than a mere display of content
3. What Are the Best Interactive Website Features to Consider? Top 7
Disclaimer: there's no such thing as “universally best” interactive website elements.
There are, though, the “most suitable” interactive features for your own industry sector and business goals.
For instance: is it financial services that you provide? Then an interest calculator is the “best” interactive feature to incorporate into your company website. Relevance is key here...
Now, let's dig out the interactive website features with the biggest impact on user engagement metrics.
3.1. Simple Interactive Tools
Simple yet... highly effective, these tools range from short games to quizzes, to ad ROI calculators, to budgeting tools, to... math tools.
Needless to add that their selection depends entirely on your business goals.
3.2. User-Generated Content
And this must be one of the most powerful interactive website features that you could integrate into your site.
Image by OpenClipart-Vectors from Pixabay
Empower users to create and upload content on your website:
product/services reviews
pictures of them wearing/using your products
guest posts
comments
It's a highly effective means to connect with your website users.
… to make them feel that they have the power to influence the user experience delivered on your website, to make them spend more time there, and even attract other potential customers with their reviews.
3.3. Wisely Used Interface Animations
Animations should be on anyone's list of interactive features on a website.
Word of caution: mind you use animations sparingly and with the sole purpose of enhancing your website's usability.
If instead you use them to visually “wow” your visitors, you'll only risk making your website look amateurish and untrustworthy.
Not to mention that a site crammed with animations would make your content difficult to read, as well.
Still, when used wisely, scrolls-triggered animations and dynamic hover states on images or links, for instance, will engage users.
3.4. Social Media Apps
Image by ijmaki from Pixabay
The handiest way to “inject” interactivity into your website: social media apps.
And this “too” common functionality of enabling users to share your content and to follow your brand on social media is, still, one of the most effective ways to boost user engagement.
So, mind you don't underestimate the power of these buttons...
3.5. Live Chats or Chatbots
Assisting users throughout their visit on your website, being ready to anticipate and to promptly answer their questions... There's hardly a better way of connecting with and retaining website visitors.
Take live chats and chatbots as a too powerful mix of stellar customer service and “excuse” for users to stay on your website for a longer period of time.
3.6. An Interactive Feedback System
A built-in online survey tool or a contact form are other great ways of injecting a high level of interactivity into your website.
Take, for instance, the contact form: you get to reach 2 major goals with one shot.
you enrich your database of leads
you convey a “We Care” message to your online customers
3.7. Interactive Images and Videos
Let's try a little empathy exercise: get into the shoes of your eCommerce website user!
Now, answer this question:
“How convinced are you that you're making the right choice when you buy a product displayed in an on-site picture?”
Don't you struggle with the doubt that you might not make the best decision?
An interactive photo or video revealing certain features of that product in detail or showing it in action, in the real world, would have a dramatic impact on your customer journey, don't you think?
The END!
These are the 7 high impact interactive website features to put on your shortlist when you plan to make your site more engaging.
Which of these elements are you already making the most of on your website?
Main image by Caroline Attwood on Unsplash
Silviu Serdaru / Oct 04'2019
They used to be THE norm and to dictate web designers' decisions. No one questioned their usability or long-term efficiency. Or that they would soon grow into some outdated web design trends. Deprecated conventions that, when not mocked, are now regarded as mere haunting “ghost of the past”.
A “past” where glossy buttons, flashy design, and overly embellished page dividers used to steal the spotlight.
Now, let us go against today's trend of talking about “the biggest web trends in 2019” and, instead, dig out some old UI cliches. Just to determine the cause of death so that you:
don't risk falling into yesterday's pitfalls in terms of web design once again
leverage the lessons of the past to contribute to a better future of the web
1. The Flash Menu
Remember those “glory days” of the... flashy web?
There was sound pretty much everywhere on a web page, animated buttons, interactive elements. And there were fancy flash menus, of course.
All web designers used to take “flashy” and “animated” for... “user engaging”.
The causes of death:
applying any changes to a flash menu was discouragingly challenging (you couldn't get away with just editing a text file)
it had a negative impact on the website's SEO; crawling those flash files was “mission impossible” for the search engines
it wasn't mobile-friendly
it had poor loading times
it had to be installed into the browser
plugins had to be updated constantly... frequently
2. The Frame, the Elder “Cousin” of Today's iFrame
Now, let's turn back the hands of time and “freeze” it right at those days before tables stepped into the spotlight. What did we use for basic layouts back then?
We used frames...
Which are now no more than another one of the outdated web design trends that, well, it's not worth resuscitating. Back then, we didn't have JavaScript to overtake the burden of loading data, so web browsers had to do all the heavy work.
The causes of death:
they would compromise the browser history and break the back and forward buttons
copying and pasting links to web pages on the same website was a dread
they would enable the web browser to partly update a page instead of loading a brand new one
reloading a website would, more often than not, mean no more than guiding the user back to the exact front page
3. The Table Layout, One of Those Outdated Web Designs Trends to... Bury
OK, maybe there's no need to “mourn” over this dead UI convention, but we can't just overlook its massive contribution to... the evolution of web design.
Image source: Genealogy Web Creations
Back then, when the table-based layout trend emerged and stole the spotlight, it opened a whole world of possibilities:
It empowered us to structure our web content by breaking it into multiple columns and rows.
Surprisingly enough, that mix of GIF files and inline styles did manage to glue those layouts together.
The causes of death:
it wasn't responsive
<div> tags and classes came to... seal its faith
CSS, “tempting” us with floats, stepped on the stage of web design
4. The Border Ornament and Decorative Page Divider
The overly embellished page separators are another “once a norm, now just one of the outdated web designed trends”.
Image source: Image by Karen Arnold from Pixabay
In its “glory days,” it was our only option to split chunks of text on our web pages. And since the <hr> elements looked a bit too... dull, we went to the other extreme and started using these overly embroidered GIF separators to section our web pages.
Separators which, at first, were no more than some horizontal bars. Until web designers fell prey to the urge of gilding the lily.
The causes of death:
the heavily ornamented borders ended up diverting users' attention away from the essential: the text itself
CSS/CSS3 eventually stole our attention, as web designers
divs and classes made the segmentation of a web page much more... fluid, with no impact on the overall user experience
5. The Blinking Marquee
There was a time, way before image sliders gained their bad reputation when we would have text just... slide across web pages, from right to left.
What made this “sliding” possible? HTML's marquee tag, the equivalent of Internet Explorer's <blink> tag...
The causes of death:
it distracted website visitors from the core message
it affected SEO, since it only displayed partial information to search engines
it was an unnecessary artifice in most cases, for it carried minor information and it was the main “culprit” for a high cognitive load
6. The Image Button
Another one of those outdated web design trends dating back to early 2000, when “flashy”, “cluttered” and (most of all) “fancy” were the best adjectives to describe web designers' work.
And the glossy, 3D-looking image-based buttons created in Photoshop were fancy, alright! Where do you add that they paired with custom-made, animated cursors, as well.
The causes of death:
with text “carved” into the image, buttons were too difficult to manage, too difficult to apply changes to
they weren't responsive (they would get “partially responsive” and that only after a lot of hard work)
CSS3 came to... bury it for good
The END!
These are the 6 most representative UI conventions for the early 2000s that have gradually turned into some outdated web design trends.
Or, better said, into “learning materials” on the old/wrong ways of designing for the web and how they influenced today's UI design best practices.
Image by Mudassar Iqbal from Pixabay
Silviu Serdaru / Jun 03'2019