On one hand, you “crave” improved site performance, improved checkout process, improved scalability, and all the other improvements that Magento 2 “seduces” you with. On the other hand, just the thought of risking to compromise your data, your Magento extensions or the various customizations in your store simply... paralyzes you. It's obvious: you need a bulletproof, actionable, and 101% safe plan for migrating from Magento 1 to Magento 2...
A step-by-step guide to:
reduce some of the intimidating complexity of the process
secure each one of its phases (from the preparation phase to the data migration phase... all the way to deployment)
streamline it
Well, here it is: the 7-step migration roadmap that you need to safely and efficiently structure your Magento 2 migration process.
1. Evaluate Your Current Implementation and Try to Estimate Your Migration Effort
The first step to take in the preliminary part of your plan is to review your Magento 1 implementation.
Start by assessing your current environment and setting it against this list of Magento 2 software and hardware requirements:
PHP: 7.0.13+ or 7.1.x
+2G of Ram
MariaDB 10.0,10.1,10.2 or Percona 5.7 or MySQL: 5.6, 5.7
PHP extensions: soap, curl, mcrypt, gd, iconv, PDO/MySQL, openssl, intl, ctype, bc-math, libxml etc.
Next, take some time to analyze your current e-commerce store's provided user experience, extensions, configurations...
Then, reflect on the following key questions:
How many storefronts and domains are included in your Magento 1 architecture? Needless to add that moving a highly customized multi-site infrastructure is going to be a lot more challenging than migrating a single store...
How large is your current store (run an inventory of all your products, users, attributes, orders, categories)?
How bulky is your ecosystem of third-party extensions, Magento core customizations, custom themes, various integrations (CRM, ERPs)?
It's only after you've performed an in-depth analysis of your current online store (or multi-store) that you can roughly estimate the migration complexity.
Word of caution: remember to backup your Magento 1 online store (secure your folders, database, and files) and to always migrate data from your cloned database instead of transferring it straight from your live online store...
2. Make an Inventory of Your Extensions: Search for Similar Versions in Magento 2
And this step makes a perfect opportunity to... declutter:
Run an inventory of all the extensions on your current e-store and decide which ones are to be kept and which of them you should let go of...
Next, divide your “pile” of extensions into 3 categories:
Magento 1 extensions with corresponding versions in Magento 2
Magento 1 extensions with third-party alternatives instead
Magento 1 extensions that were custom-built for your current store, that you now need to rebuild
Run a 1:1 analysis and identify the extensions, themes and custom code on your e-commerce store that are compatible with Magento 2...
3. Migrating from Magento 1 to Magento 2: Choose the Right Migration Tool
In this respect, the Magento 2 data migration tool is a highly reputed one. It will greatly streamline the whole process, but do keep in mind that:
you'll still need to write custom code to seamlessly merge data into the new platform
you'll need to adjust your custom code to fit in; for instance, tables and columns aren't considered standard dataset in Magento 2
Note: now it's the best time to reconsider your third-party extensions. Do they really compensate for all those data entries and product parameters that they injected into your Magento 1 store?
If you still consider them relevant and valuable enough to be moved over to your new Magento 2 store, you might want to consider the Magento 1 to Magento 2 code migration tool for this.
4. Migrate Your Theme
And this will be possible only if:
your current Magento 1 theme is compatible with Magento 2
there is a version of your current theme available in Magento 2
If not, if you've been running your e-commerce website on a custom theme, let's say, then you can either:
create a whole new theme from the ground up
purchase a Magento 2 theme
Note: this is also that step of your “migrating from Magento 1 to Magento 2” roadmap where you integrate your new online store with your key corporate systems.
5. Migrate Your Extensions
As already mentioned, there are 3 possible actions that you can take regarding your current load of extensions:
check whether they have Magento 2 counterparts
if so, incorporate those Magento 2 versions into your new store
if not, integrate some brand new extensions, that provide the same or similar functionality
6. Migrate Your Code Customizations
Rely on the Code Migration toolkit for this and let it do all the heavy lifting that the code migration process involves.
Word of caution: after you've let it perform its function, remember to go back and focus on all those files that need manual editing.
7. Migrate Your Data
As already mentioned, the Magento 2 Data Migration Tool is one of your most reliable “allies” in migrating from Magento 1 to Magento 2.
And I'm referring here to the orders stored in your store, products, settings and configurations, categories and so on...
How do you use it?
It's no more than a 5-step process:
Use Composer to install the tool
Enter your authentication keys (Magento Marketplace > Sign in > Click on My Access Keys) or generate a new pair
configure your tool
migrate your Magento 1 store's settings (system/store configurations, shipping, tax settings...)
Migrate your data by entering this command: php bin/magento migration:data --reset <path to your config.xml>
Next, it's testing time: test, test, test, then... test some more! Check whether your new Magento 2 store works properly.
Make sure you run your performance analysis and optimization process on real data. This way, you can check whether the actual Magento 2 store is capable to withstand real-life loads of data...
Also, do keep in mind to update the existing data with the newly added one before deploying your Magento 2 store. And that because at this point you might end up with identical data: identical products, users, categories...
Once you've fixed this issue, you only need to pick the right time — preferably not the “peak traffic” hours on your website — to launch it...
The END!
Have I missed any key step(s) that anyone migrating from Magento 1 to Magento 2 should take?
Get in contact with our team of Magento 2 experts in Toronto and complete your migration!
Image by Ross Mann from Pixabay
Silviu Serdaru / May 31'2019
Let's take this scenario: you need to create a landing page for your Magento 2 website. You have no coding experience, you need it built fast and preferably as easily as... dragging and dropping some builder elements. “What's the best Magento 2 page builder extension?” you then ask yourself...
Now, let me try and guess the other key features on your “must-have” list for this page builder:
to provide a drag and drop interface (definitely!)
to be optimized for speed
to come packed with powerful customization options
to support responsive design and mobile-ready layout
to make it easy for you to change the layout elements and build new blocks
to be integrated with Magento WYSIWYG
to provide a rich collection of widgets for you to “joggle with”
to be compatible with other Magento themes and extensions
Have I guessed most of your “wishes”?
Now, here are 5 Magento 2 page builders that meet your expectations of performance and ease of use:
But First: What About the Built-In Page Builder in Magento 2.3?
First of all, you should know that you'll get this page builder out of the box with the Magento 2.3 Enterprise Edition edition only. The Community edition doesn't provide it.
So, if your eCommerce website's running on the EE edition, the default Magento 2 page builder gets automatically installed.
It provides you with powerful content creation tools and visual drag and drop page builder to create and to easily edit your pages.
1. Landing Pages for Magento 2, from Amasty
A flexible module for creating landing pages in Magento 2.
Expect to get “spoiled” with lots of powerful functionalities aimed at boosting conversation:
it allows you to create custom sub-selections of your products/services, for each page
… custom meta tags
… Google friendly URLs
it enables you to put together unique and engaging content for your landing pages
Key features:
it allows you to display your custom CMS blocks at the top/in the bottom of your landing page
it allows you to create page-specific lists of products by leveraging the flexible conditions that it provides
it allows you to list your landing pages to your sitemap
it allows you to create a wide range of landing pages
2. Bluefoot CMS & Page Builder for Magento 2
In your “quest” for the best Magento 2 page builder extension, you'll definitely want to consider Bluefoot, as well.
It's a content management system and page builder that empowers you to create custom, feature-rich webstore pages, with zero technical knowledge (either PHP or Magento template system related...).
Using it is unexpectedly easy:
its interface resembles the already familiar admin panel in Magento 2
just use Bigfoot once you have the WYSIWYG in Magento popping up
Key features:
drag & drop page builder
easy third-party content integration: from Google Maps to Youtube, building feature-rich web pages, posts and categories becomes surprisingly easy
a whole collection of styling options
Magento WYSIWYG integration
static block integration
open-source code
In short, with Bluefoot CMS and Page Builder, creating custom web pages turns into a matter of... minutes.
3. Magento 2 Page Builder, from Landofcoder
The best Magento 2 page builder extension if you fancy the idea of creating and configuring your (complex, feature-rich) pages right at the front-end. No admin panel needed...
Easy to use, convenient and highly intuitive.
Key features:
create an unlimited number of page layouts
easily change your layouts
a collection of +50 popular Magento widgets
a built-in element builder to create your own content elements and mix and match them to your liking
visual drag & drop admin interface
CSS skin builder, that grants you full control over your web pages' looks
block builder: create your blocks, then assign them to specific positions on your pages
top performance; it's built with page load time in mind
4. CleverBuilder
Simple, intuitive, flexible and fast. What more expectations could you have from the best Magento 2 page builder extension, right?
Key features:
intuitive interface: just swipe through and select out of hundreds of content elements and templates
an all-baked-into-one solution: manage your whole web design workflow from one place
live front-end editor & inline editor: apply changes to your webstore pages (and test the end-results) in real-time
top performance
100% visual design: simplicity & flexibility at its best
5. Front-End CMS Page Builder, from Magesolution
From homepages to content pages, to ads pages, to landing pages, this page builder allows you to create your CMS pages right at the front-end, by just dragging and dropping content elements.
Key features:
+30 builder elements
enhanced speed for your newly created web pages
highly intuitive drag & drop interface that display the updates you're making in real-time
responsive design options
compatible with other extensions and themes
6. Page Builder for Magento 2, from Magezon
Another candidate for the title of “the best Magento 2 page builder extension”. And no wonder why: Magezon's page builder empowers you to create custom page layouts in no time. With zero coding experience required...
From adding descriptions to your products to putting together your website's structure, you're free to configure everything about your layout.
Key features:
+50 content elements
drag & drop page builder
fast performance with cache
ready-made templates
Magento WYSIWYG editor
a wide range of plugin integrations
a wide collection of customizable options
The END!
Needless to add that it's not the best Magento 2 page builder extension that you should be looking for, but the most “suitable” one for your own needs. So, what features do you value most?
Would you trade ease of use for... lightning-fast performance? Are flexibility and freedom of customization more important for you than simplicity and an intuitive interface?
Contact our team of Magento 2 experts in Toronto or leverage our Magento web design services in Vancouver to drive outstanding development outcomes.
Image by 200 Degrees from Pixabay
Silviu Serdaru / May 10'2019
Do you need to set up a custom image carousel? Or maybe one slider with a teaser, displaying content from your website? What are the best Drupal 8 slideshow modules to consider for implementing and maintaining your slideshow?
And out of the box options are... out of question, right? Your requirements are too specific for that.
Maybe you need:
a certain number of slider items
different arrow designs
to display the image slideshow on other pages, too, not just on your homepage
With such flexibility and customization requirements in mind, we started digging into the “pile” of Drupal 8 image slider modules.
And here are the 4 ones that we've selected, those with the best reviews in the Drupal community:
1. Views Slideshow
If it's a fully customized slideshow that you want to implement, Views Slideshow's the module you need.
It'll “spoil” you with tons of add-ons to select from and give your unmatched flexibility. From:
titles
to images
to teasers of the last X blog posts on your website
… you get to include any type of items in your carousel.
Furthermore, it's jQuery-powered and it allows you to configure different settings for each one of the views that you'll create.
Note: oh, yes, you'll need to be pretty comfortable using Views in order to leverage this module at its full capacity.
Some of its key features:
your slider can include and display the latest products added to your eCommerce website
you can set up a news item slideshow (the latest X news articles published on your Drupal 8 website)
from the latest X blog entries to the latest videos, testimonials, forum posts etc., you're free to include any type of content in your slider...
Now, here's a very brief step-by-step on how you can set it up and use it to create your slideshow:
1.1. Install and enable the module
Once you've downloaded it from Drupal.org, installed and enabled it, make sure to download its corresponding ZIP folder on Github, as well.
Give your folder a new name — /jquery.cycle/ — then start uploading all its files to the
/libraries/ folder in the root of your Drupal website.
1.2. Set up your view
Time to create your slideshow now. For this, just go to Structure> Views>Add new view
1.3. Publish your slideshow block
For this, go to Structure>Block layout and select the region on your website that you want your slider to get displayed on.
1.4. Create a new image style
As you can see, the images included in your slideshow are currently of different sizes. Therefore, they're not perfectly adjusted to fit the block region that you've chosen for your slider.
To solve this inconvenience, just go to Configuration>Image styles>Add Image style.
There, you can create a new style, that will be shared by all the images included in your slideshow.
2. Slick Slider, One of the Most Popular Drupal 8 Slideshow Modules
Another one of Drupal's modules for creating custom image slideshows, that ships with a heavy load of options. Powerful and flexible... what more could you ask for from your slider solution?
Capitalizing on Ken Wheeler's Slick carousel, working perfectly with Views and fields, the Slick Slider module:
enables you to set up a slider including multiple views, value fields and paragraph types
comes with image, audio and video support
supports complex layouts, as well
Some of its key features:
you're free to enable/disable the swipe functionality
it's responsive (scales along with its container)
some of its layouts are CSS-built
it's designed to work with Field collection, Media, Views, Image (and also to work perfectly fine with none of these modules)|
it allows you to configure your own “slide selecting” dots, the arrow keys and your slider's navigation, as well
it provides modular and extensible skins
you get to choose how you want your slideshow to be scrolled: swipe, desktop mouse dragging, auto scroll, mouse wheel scroll...
3. Owl Carousel
Another one of those Drupal 8 slideshow modules that gets the best reviews.
Here's why:
it leverages the Owl Carousel slider built by OwlFonk.
it, too, empowers you to customize your image slideshow; in this respect, it ships with a myriad of customization settings
it's responsive
it capitalizes on a small ecosystem of submodules: Administration UI, Views Style, Field Formatter
Some of its key features:
from customizing your events to styling your controls, it allows you to tailor your image slider to suit all your needs
it supports multiple sliders
touch events
4. jCarousel
A simple module to consider each time you need to display a group of images in a compact way on your website. It even allows you to set the number of items to be included in your carousel...
Speaking of which, you should know that jCarousel, as its name says it, allows you to leverage the jCarousel jQuery plugin.
For this, it ships with a developer API for other modules to access. Furthermore, it integrates with Views, so you can easily turn any list of images (or other type of content) into a slideshow...
Some of its key features:
jCarousel field formater
out-of-the-box Views support
API for using jCarousel without Views
a collection of modern skins to choose from
Carousel pager that enable users to jump between multiple sliders
The END!
These are the first Drupal 8 slideshow modules to consider when looking for the best method for setting up your custom image/content slider.
Packed with tons of customization options, feature-rich and powerful, these 4 solutions for creating image carousels in Drupal 8 should be on your short list when you start looking beyond the out-of-the-box options for putting together a slider...
Photo by Samuel Zeller on Unsplash
Silviu Serdaru / Apr 25'2019
With the Twig templates replacing the old PHP templates, Drupal has been brought to a whole new “era”. We can now leverage the advantages of a component-based development in Drupal 8. But what does that mean, more precisely?
How does this (not so) new approach in software development benefit you? Your own team of developers...
And everyone's talking about tones of flexibility being unlocked and about the Twig templates' extensibility. About how front-end developers, even those with little knowledge of Drupal, specialized in various languages, can now... “come right on board”. Since they're already familiar with the Twig engine...
Also, we can't ignore all the hype around the advantage of the streamlined development cycles in Drupal and of the consistent user experience across a whole portfolio of Drupal apps/websites.
But let's take all these tempting advantages of component-based UI development in Drupal 8 and point out how they benefit your team precisely.
1. But First: What Is a Component?
It's a standalone piece of software that can appear in multiple places across your Drupal website/application.
One of the most relevant examples is that of a content hub. One displaying teasers of the latest blog posts, events... You could set up a component that would determine how each item in that content hub should look like.
In short:
one single component can be used by several types of content
any update to its template/style would automatically reflect on all those content types, as well
Accessible via an API, this independent piece of software explicitly defines all its application dependencies.|
Your team could then easily architect a new interface by just scanning through and selecting from the library of components.
2. What Is Component-Driven Development? What Problems Does It Solve?
A succinct definition of component-based software engineering would be:
A software development technique where you'd select off-the-shelf, reusable components and put them together according to a pre-defined software architecture.
“And what challenges does it address?”
It streamlines and lowers the level of complexity of otherwise intricate, time-consuming development and design processes. As the author of given components, your role is to get them implemented.
No need to worry about how they'll get “assembled”; this is what the well-defined external structure is there for.
Word of caution: mind you don't get too... engrossed in putting together the right components, in architecting the best component-based structure, for you then risk investing too little time in... building them properly.
3. Component-Based Development in Drupal 8
Now, if we are to focus our attention on the component-based UI approach in relation to Drupal 8 software development, here are the key aspects worth outlining:
with the Twig engine in Drupal 8, you're free to “joggle with” extensible templates; once you've defined a Twig template in one place, we get to reuse it across the whole Drupal website/app
the Component Libraries module allows you to set up template files (storing all their needed JS and CS), assign a namespace for them and place them pretty much anywhere on your Drupal filespace (not just in your themes' “templates” directory)
you then get to use the KSS Node library and define a living style guide; it's where you'll store all the component templates built for your Drupal website (styles, markup, JS behaviors, etc.)
By filling in your toolboxes with all these tools — the results of a joint effort of the Drupal and the front-end communities — you're empowered to design themes that are more modular. And, therefore, more efficient...
4. The Top 6 Benefits of the Component-Based UI Approach
4.1. It Ensures UX Consistency Across All Your Drupal 8 Websites
Take your library of components as the “headquarters” for all the teams involved in your Drupal project: QA, business, development, design teams...
It's there that they can find the pre-defined standards they need to keep the consistency of the features they implement or of other tasks they carry out across multiple projects.
A consistency that will bubble up to the user experience itself, across your whole portfolio of Drupal 8 websites/applications...
4.2. It Accelerates the Process of Turning Your Visual Design into a UI
Embracing the component-based development in Drupal 8 you'd avoid those unwanted, yet so frequent scenarios where the front-end developer gets tangled up in the wireframe he receives and:
he/she translates parts of it the... wrong way
he digs up all types of “surprise” issues
By using a component-driven UI approach translating a visual design into a user interface gets much more... event-less.
With:
a pre-defined component architecture to rely on
well-established standards to follow
a whole library of component templates at hand
… there are fewer chances of discrepancies between the UX defined in the visual design and the one delivered via the resulting user interface.
Not to mention the reduced delivery timelines...
4.3. It Streamlines the Whole Development Process
“Sustainability” is the best word to define this approach to Drupal software development.
Just think about it:
whether it's a particular grid, navigation or layout that your front-end developer needs when working on a new project, he/she can pull it right from the component library at hand
… and “inject” it into the app/website that he's working on
in case that element needs further updating, the developer will already have the baseline to start with
… there's no need for new components to be designed, from the ground up, with every single project: the already existing ones can always get further extended
And that can only translate into significant savings of both time and money.
4.4. It Reduces the Time Spent on Setting Up the Functionality & Defining the UX
And this is one of the key benefits of using component-based development in Drupal 8. Your various teams would no longer need to define the UX requirements and the functionality every single time during the design process.
With an easily accessible library of components, they can always pull a component standing for a specific requirement (display of complex data, filtering, pagination in grids, etc.) and just define its extensions. And the business logic, as well.
4.5. It Enables You to Systematically Reuse Your Components
And “reusability” goes hand in hand with “sustainability”. I would even say that it's a synonym for “future-proofing”, as well...
Just think about it: by having a Drupal 8 website in a component-based format you can always rearrange components as technologies grow outdated and new ones emerge...
In short, embracing a component-based development in Drupal 8 enables you to remove the need of rebuilding your website every time its underlying technologies “grow out of fashion”.
With your component library at hand, you'll be able to swap your guidelines, design patterns and various content templates in and out, keeping your Drupal app or website up to date.
4.6. It Integrates Seamlessly into the Development Process
By leveraging a component-based development in Drupal 8, you'd also gain better control over the whole development cycle. The update process here included...
Since you'd then build your components and manage your production quality user interface code in a repository like GitHub, every update that you'd make will be displayed in there. And be easily accessible to everyone in your team.
In short, your developers get to pull pieces of code from the repository to further extend them, then re-submit them to GitHub (or to another source code repository) for review.
With the ability to version your component library, your team can keep a close track of all your Drupal applications with their corresponding versions of the approved UX.
The END!
This is how the component-based development in Drupal 8 would benefit you and your team. Have we left out other key advantages of using this approach?
Image by Arek Socha from Pixabay
Silviu Serdaru / Apr 11'2019
Simple, yet visible enough, actively persuasive, yet not invasive, powerful, yet intuitive. How do you make your mobile call to action buttons intuitively... usable? What are those techniques which, once applied, enhance their intuitiveness?
And thus boost their effectiveness, as well...
How do you know whether your current mobile CTAs aren't optimally designed for mobile devices and adapted to mobile users' specific UX needs?
users spend too much time on the action screen; it's not obvious enough for them which are the highest priority actions to take, there are too many options crammed in there, too much text, etc.
your click-through rate could be... better, to say the least
Now, here are 10 straightforward, yet highly effective tips to make your mobile call to action buttons more effective:
1. Bold Your Text Labels Differently to Indicate Priority Level
A simple, yet powerful technique, that's often underrated: varying the boldness of mobile CTAs based on priority. This way, you'd put different emphasis on the various actions referred to.
For instance, is the action of “checking out” more important than that of “viewing the cart”? Indicate this hierarchy of priorities using varied intensity when you bold your text labels: go from the least bold to... the boldest.
2. Go for Button Shapes Instead of... Text-Only “Buttons”
Stick to the safe beaten road of UX when designing your mobile call to action buttons: don't trade straightforwardly shaped buttons for text-only ones.
You'd only end up confusing your users: “Is that a button or a piece of information?” And you'd risk having them miss/skip your most important CTA because... they won't notice it or just take it for... copy.
In other words: place your text labels into “familiar” button shapes.
3. Consider Those Screen Areas of "High Thumb Activity"
Always take heed of “the thumb zone”! It's made of all those key spots on a phone's screen that are the easiest for users' thumbs to reach and to... click on.
Once identified, strategically place your mobile CTAs there...
4. Consider Users' Natural Scanning Pattern when Placing Your CTAs
Do you want your mobile call to action buttons to be (just) visible or effective?
In this respect, placing the highest priority CTA first, will make it visible, but not necessarily effective, as well. Why? Because users are then forced to scan the screen bottom-up. And this is not their natural flow: first the “Checkout” button, then the “View Cart”, then the “Continue Shopping” buttons...
Any deviation from this familiar flow will affect the “intuitiveness” of your CTAs.
5. Stick to the Best Practices for Mobile Call to Action Placement
Left or right? Top or bottom? Where is it most effective to place your mobile CTAs on the screen?
You'll get the best answer to your question only once you've studied your target audience:
what triggers them to... action?
what catches their attention first on a screen?
Run some tests to identify those best practices on call to action placement that are most effective for your own scenario.
6. Keep It Straightforward: One CTA Per Page
Challenging users with too many options is another “self-sabotaging” technique. So, make sure you don't fall into the trap of overcrowding your screens with multiple CTAs.
Instead, make the most of that limited real estate on a mobile device's screen and place just one CTA per given space.
Otherwise, you only risk discouraging users with a too complicated decision-making process...
7. Use Color Wisely to Signal Progressive Actions & Priority Levels
Let's take 3 of the most common actions that mobile users are presented with: “Continue shopping”, “View cart” and “Checkout”.
Now, how would you indicate a given user the lowest, the medium and highest priority action to take? How would you signal progressive actions (as opposed to regressive actions, like “view cart”)?
You use the same color, but with different levels of saturation and brightness.
Note: using equally saturated color on all your mobile call to action buttons wouldn't make the hierarchy of priorities very intuitive, while using different colors would only place the same emphasis on all those progressive actions.
Tip: to indicate the highest priority, you could also opt for light text label set against a dark background; as opposed to the dark text on a lighter background, that you'd use for lower priority CTAs.
8. Use White Space to Make Your Mobile CTAs Stand Out
And this best practice goes hand in hand with the “one CTA per given space” technique: let the white space work for you/your call to action button.
Make sure to wrap it in enough white space to help it... stand out and catch users' attention.
You'd then:
make the most of the limited real estate that you're constrained to work with
avoid unwanted scenarios where, due to screens crammed with text and CTAs, users accidentally click the “wrong” links
9. Keep Your Copy Concise, Yet Persuasive
Your mobile call to action buttons should feature text that's:
short, yet descriptive enough
concise, yet actively persuasive
action-oriented
10. Use an Icon to Indicate the Highest Priority Action
What about color blind users? How can you make your mobile call to action buttons visible and intuitively easy to use for them, as well?
For using color wisely and varying the boldness of your text labels to indicate different priority levels sure isn't helpful for them.
Well, you go with an... icon. Just place it inside your checkout button and you'll make it stand out even more. It will be that visual element that they'll spot and cling to once they lend on a screen.
The END!
These are our 10 easy to implement techniques that will help you boost the “intuitiveness” of your mobile call to action buttons.
Would you have added other ones, as well?
Image by LeoNeoBoy from Pixabay.
Silviu Serdaru / Apr 05'2019
Isn't it ironic? On one hand, you've kept hearing/reading have all this talk about WebAssembly and what a game changer for the web it is. Yet, on the other hand, few developers are actually leveraging it in their projects? There's all this hype around the new way of assembling code in any language and running it right in the web browser, yet everyone's still a bit hesitant about using it. Are there any truly compelling use cases for WebAssembly?
Why would you use it? What are its primary use cases?
For now, what you do know are its “selling points”, that everyone's blowing the trumpet about:
it enables you to build reliable, dynamic, faster websites
it's now shipping in all major browsers
it enables you to write your piece of software once and then have it run on... every platform with a browser
it's a “revival” of the smart client software development
On the other hand: it's still a “steamy fresh” technology and people are half-hearted about using it.
And where do you add that it requires a huge shift in mentality, as well: using the browser for tasks that developers are used to performing in the back-end.
Now, let's shed some light here and bring forward the most compelling use cases for WebAssembly:
1. Writing Faster Code
And writing “almost fast as native code for web browsers” has been one of developers' ever-present goal.
Well, yes: WebAssembly does enable you to write faster code.
And yes, it is faster than JavaScript, “showing off” its performance-oriented side particularly when it comes to performing highly computational tasks. Those kinds of operations where lots of numbers and memory strain are involved.
Notes:
Do keep in mind that being able to write faster code to be run with ES6 doesn't mean that WebAssembly will replace JavaScript. It's designed to cohabit with it, not to be the “cause of its death”.
benchmarks have shown WebAssembly to be 10% slower than C code. Still, many consider it as a too little compromise for all the flexibility and portability they get in return.
2. Client-Side Compression: One of the Primary Use Cases for WebAssembly
Just think of the tones of convenience that such a use case comes bundled with.
Let's take this hypothetical user who takes a photo on his/her phone and then uploads it on a website. In that case, it's the server that normally handles the compression part: the user uploads the image at a default maximum resolution, then the server compresses it.
When using WebAssembly all this compression happens in the... browser. The result: fewer server resources and data/bandwidth used...
You get to run your web apps using the client's CPU instead. Compared to the “old way”, where you would access the server first, then send the result to the client.
3. Writing Code for the Web in Other Languages than JavaScript
By far one of WebAssembly's biggest “selling points” is the flexibility that it provides. You get to write your code for the web in a... non-JavaScript language.
And that's huge! Just think that till recently you were constrained to write your code for the web browsers in JavaScript. There was no alternative...
Again, that doesn't mean that we'll witness a migration of developers from JavaScript to other specialized languages. Instead, scenarios where you'd use JS for the app's logic and UI alongside WebAssembly, used for the core functionality, are more likely to happen. As well as those scenarios where performance bottlenecks in your existing JS apps will get rewritten in a more... specialized language. One that's more fitted to tackle those specific issues...
4. Compiling Existing Applications for the Browser
Another one of the compelling use cases for WebAssembly is this: compiling your current apps so that they run on the browser.
A possible way to do this is by writing your existing apps in a managed language that has a large runtime. Take for instance a scenario where you'd compile Photoshop for the web browser.
That, of course, if you don't have anything against sending an oversized file over each user's network.
5. Compiling & Accessing C/C++ Libraries
… and compiling Rust, I must add.
“What is WebAssembly good for?” To access C/C++ libraries for a wide range of operations:
digital media processing
graphics
compression
physics simulation
And, of course, to compile C/C++ and Rust (or other statically typed languages) to a new format, to be easily run in the web browser. All that with a low runtime, so that you can reap the benefits of predictable performance.
6. Moving from Desktop-Only to Browser-Based Applications
WebAssembly marks the “extinction” of the last desktop-only apps.
From VR/AR apps to apps with heavy data usage, to photo and video editors, to games with complex system requirements, they can all be run in the web browser now.
Final Word
Just imagine all the possibilities that WebAsembly unlocks: it enables you to take code from any language and run it in the web browser. Moreover, since it's a compile target, it “plays nicely” with other languages on the web: C++, Rust, C...
And this leads us to the required shift in mentality mentioned at the beginning of this post: using technology for operations that would normally be performed in the back-end, but which, in this case, involve the web browser...
Image by Rani Suarni from Pixabay
Silviu Serdaru / Apr 02'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
“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
Progressively decoupled Drupal has gone from concept to buzzword. Until recently, when we've started to witness sustained efforts being made to set up a standard workflow for implementing this architecture.
New dedicated modules have been developed to fit those use cases where just a few particular blocks, affecting the website's overall performance, need to be decoupled. All while preserving Drupal's standard robust features.
Features too famous among content editors and site builders to be sacrificed in the name of high speed and rich UX.
We've gradually shifted focus from “Why would I choose progressive decoupling over a headless CMS?” to:
“How precisely do I implement the progressive approach into my own decoupled Drupal project? Is there a standardized process, based on a set of dedicated modules, that I can leverage?”
And this is what I'll be focusing on in this post here.
More precisely, on the efforts for standardizing the whole workflow: see Decoupled Blocks and the SPALP module!
1. Progressively Decoupled Drupal: Compromise or Viable Alternative to an All-In Transition?
Is this approach nothing but a compromise between:
content editors — and all Drupal users working in the site assembly — who depend on key features like content workflow, layout management, site preview, seamless administrative experience
and front-end developers, who're “dying” to “inject” application-like interactivity and high-speed front-end technologies into certain portions of the Drupal web pages?
Progressively decoupling blocks in Drupal is, indeed, the best compromise you could get between:
your editorial team's “fear” of losing familiar Drupal features critical for their workflow
front-end developers willing to experiment with new technologies promising top speed and richer user experiences
Developers get to leverage the JavaScript framework of their choice without interfering with the site assemblers' workflow. Flexibility at its best!
But does being a viable compromise makes it also a worthy alternative to the fully decoupling option?
It does.
Specifically because:
it caters to all those who haven't been won over by the “headless CM movement”
it removes the risk of trading vital Drupal functionality for the benefits of a powerful front-end framework
In other words:
For all those Drupal projects requiring that only certain components should be decoupled, an all-in transition would be simply... redundant and unnecessarily risky.
For all those projects there's the progressively decoupled Drupal alternative.
2. Why Has this Approach to Decoupling Drupal Been So Unpopular?
How come the progressively decoupled Drupal strategy gained so little traction?
It seems that despite its drawbacks — the need to reinvent some of the lost “Drupal wheels” and its higher costs — the fully decoupled approach has been more popular.
And there are 3 main causes for this, that Dries Buytaert identified and exposed in his blog post on “How to Decouple Drupal in 2018”:
progressive decoupling doesn't leverage server-side rendering via Node.js
modern JavaScript cohabits with old-school PHP
JavaScript's ascension is not going to stop any time soon; therefore, the risk of sacrificing some of Drupal's popular capabilities might still seem insignificant compared to the JS advantages at a front-end level
3. The SPALP Module: Towards a Standard Workflow for Implementing Progressive Decoupling
Now, back to this blog post's main topic:
Clear pieces of evidence that we're finally heading towards a standardized process for implementing this type of decoupled system.
And one such evidence is the SPALP module: Single Page Application Landing Page.
Here's a specific use case, so you can get an idea of its role in the entire workflow of a progressively decoupled Drupal project:
Let's say that you need to integrate a couple of JavaScript-based one-page apps into your Drupal website. The CMS will continue to be “in charge” of the page rendering, access control routing and navigation, while the JS apps would be developed independently, outside of Drupal. How would you configure these JS apps as Drupal web pages?
You'd use the SPALP module to configure each one of them so that:
you stay consistent and “joggle with” the same configuration every time you need to add a new app to your Drupal website
you make its easy for your content team to manage this entire ecosystem of single-page JavaScript apps
“And how does this module work?”
Here's the whole “back-stage” mechanism:
the SPALP module helps you to set up a new “app landing page" content type, the one providing the URL for the app about to be integrated
each one of these applications must have its own module that would declare a dependency on SPALP, include its JSON configuration and define its library
once a module meeting all these requirements is enabled, SPALP will create a landing page node for it, which will store the initial configuration
the SPALP module will add the pre-defined library and a link to an endpoint serving JSON each time that node is viewed
Note: speaking of the efforts made to create a “Drupal way” of implementing this decoupled architecture, you might want to check out Decoupled Blocks, as well. It's designed to empower front-end developers to use the JS framework of their choice to develop individual custom blocks that would be later on integrated into Drupal. No Drupal API knowledge required!
The END!
What do you think: will the community continue their efforts to build a standard workflow for the progressively decoupled Drupal approach? Or will it remain a conceptual alternative to headless Drupal?
Silviu Serdaru / Jan 23'2019