Adrian Ababei

Adrian Ababei

Adrian is our CEO, a full stack Drupal web developer with no less than 14 years of experience in designing, implementing and supporting interactive websites and applications. Completing his Drupal expertise with project management skills, as well, he's the one ensuring that we deliver all the Optasy's projects on time, within budget with no compromise on quality whatsoever.

Back to Blog Posts
7 Common Drupal Mistakes That You're Probably Making On Your Website
Imagine your Drupal site as a... patient who has received the wrong diet (or who simply hasn't been told that he should stick to a special diet in the first place) and all the wrong medication, as well. A silly metaphor for the most common Drupal mistakes that you might have been making on your website. ... and whom (your website “patient”) you're now striving to train for the Olympics, meaning to boost its overall performance.  It's not going to work unless you “detect” those common issues deriving from improperly handling your site and from deviating from Drupal's best practices. And not before you get them fixed, obviously. And how can you know for sure whether you are making these “popular” mistakes on your Drupal website? Easy! You just give an honest answer to each one of the 7 questions from our little “investigation” here below. Ready?   1. Have You Been Ignoring the Drupal Updates? Just admit it!  And then try counting how many times you placed the Drupal Core and Contrib Drupal Security Advisory at the very end of your priority list. Or just how many times you ran the suggested upgrades selectively? The more time has passed since you stuck to this “bad habit”, the more vulnerable your Drupal site's become.  This is, undoubtedly, one of the common Drupal mistakes and the “ultimate” source of the most security threats. Note: For instance, if it's an unacceptably long period of time that we're talking about since you stopped maintaining your website properly (if it runs on a version older than Drupal Core 7.32), then it stands all the chances to have turned into an easy target for Drupageddon attacks.   2. Are There Any Unused Modules Left to Linger On Your Drupal Site?   bogged down site performance (with your way too large database as a “culprit”) high impact security issues unnecessary overhead   This is precisely what you get when you're being negligent in managing your unused modules (or themes). Those modules that maybe you just installed and took out for a quick spin, fascinated with their much-talked-about functionality, and that you no longer use. Yet you just leave them... be. And weight down your database with an unnecessary load of source code. Some of them might be lingering there since... your site's early days. Think of all the developer and administration modules (e.g. Devel or View UI) which shouldn't be overburdening the production version of your website. Yet, they still do! They're just being tolerated and gradually turning themselves into some major security issues if no one in your team deals with Security Advisories regularly. The solution to this issue, that can easily make it to top 3 most common Drupal mistakes, is as clear as daylight: uninstall all the modules and themes that you're no longer using! Don't just bundle up unnecessary overhead. And while the solution is ridiculously handy, the benefits are definitely worth the time and “effort”:   improved file system instantly boosted site performance   3. Is The PHP Filter Module Enabled? One of the Most Common Drupal Mistakes Just skip this question if it's a Drupal 8 website that you own. For this specific module has been (thank God!) removed from Drupal 8 core. Now, getting back to the PHP Filter module, which many site owners decide to enable (like you, probably), here's why you should rush to... uninstall it:   practically it's an invitation for all ill-intended users to easily run PHP code right there, on your website once enabled, it's quite a challenge to.. disable it before you've reviewed your site's content thoroughly and if you skip this step (the close reviewing of your site content), you risk displaying PHP code in plain text on your website (which could turn into a true security “crate” if not detected before you disable the module)   4. Are You 100% Sure the JS/CSS Aggregation Settings Have Been Correctly Configured? If so, then the JavaScript and CSS files that Drupal renders in HTML can be easily bundled up and compressed. But if not properly configured, your users' browsers will be forced to process far more requests in order to render your web pages' content. Which will inevitably impact your site's page load times.   5. Have You Managed to Avoid the Common “Overusing Roles” Pitfall? Or not? Don't be too harsh on yourself if you have, indeed, “overused” the user roles system. It's, undoubtedly, one of the most common Drupal mistakes website owners make after all. And what else could you have done when the default user roles that Drupal provided you with just didn't fit the specific permission levels you had in mind for your users, right? You went ahead and created your own roles... Unfortunately, these newly custom-made roles can easily:   lead to Drupal admins being forced to edit each and every user role separately whenever he/she has to update the permissions cause “security craters” when not properly configured  (overusing roles, along with their “collections” of permissions, can) impact your site's overall performance (particularly when you're striving to manage each and very set of permissions in their associated user roles)   6. Have You Configured The Full HTML Input Format for Your Most Trusted Users ONLY? Or have you simply overlooked it entirely? Have you just disabled HTML filtering from the HTML Input Filter completely? By configuring the Full Input Format for ALL your users, you're basically granting everyone permission to post HTML on your website. This way, you're just opening a gateway for any user to embed malicious code on your Drupal site. Even a banal little thing such as an image tag can easily turn into an "injectable solution", a dangerous one, in the hands of an ill-intended user who can post HTML on your website just like that. Now here's what you should do to avoid this scenario:   make sure that your filter is configured for some users ONLY and, even then, that you set only the specific set of tags they'll need to use make sure your default and custom Input Filters are correctly configured so that they pose no security risks scan your database through and through identifying any possible suspicious code that might have been injected already   7. Are You Weighting Down Your Database With Too Many (Unused) Content Types? Do you need ALL the content types currently overcharging your database (considering the fact that three database tables get added to your database with every new content type that you bring on)? Are you actually using them all? For, it not:   your database is unnecessarily overburdened your content editors' workflow is unnecessarily complex due to the whole network of confusing content types that they need to tangle themselves up in And now the solution to this issue, for certain one of the top most common Drupal mistakes: Just run an inventory of all your content types, sort them into used and no longer used ones and... just "trim the fat"! Get rid of those that are just filling in space in your database! This is our top 7 mistakes that you, too, are probably making on your Drupal site (even if not all of them). Now that we've exposed them to you we can't but end our post with a conclusion/piece of advice: The handiest way to optimize your website's performance is by preventing performance issues to occur, in the first place. Now that you have them “brought to light” it should be easier, with a little bit of effort, to avoid them, shouldn't it? ... Read more
Adrian Ababei / Oct 30'2017
Jekyll or Hugo? Which Static Site Generator Best Suits Your Website?
“It depends...” This is the very first honest answer to your “Jekyll or Hugo?” dilemma. Since your own use case scenario is (obviously) different from all the rest:   Which feature do you value most: extensibility or page build speed? Do you prefer high performance over the simplicity of use? A massive community to rely on or out-of-the-box experience and simple workflow? Is it a small-sized website or a content-heavy, large-scale generated site that you have in plan? How frequently will you (or your team) be updating content on your site?   Once you've answered this “questionnaire” and you've identified your website's profile, delve into the Jekyll or Hugo 2017 comparison that our team of Toronto developers has prepared for you: Here it goes:   But First: When and Why Should You Go for a Statically Generated Site? “...instead of a dynamically generated one?”  Remember how the web used to be, back in the old days? “Databases-less” and static! Meaning: ideally simple and blazingly fast! Well, that's precisely what you get when opting for a static site generator:   a static website made of “pure” HTML and CSS with “a touch” of JavaScript, too, if you prefer  one with no dynamically generated content on the server side, with no moving parts (which, when not closely “monitored” and kept up to date turn into some major security risks) just speedy old static and secure HTML pages guaranteeing you a workflow comparably convenient to that of a dynamic site.   “But is a static site generator the best fit for my own website?” Now, this is just the right type of question to be asking yourself right now. Our answer is:    go for a statically generated site if its content gets viewed more often than edited ... and you don't need dynamic content to be constantly pulled from a database use a static site generator if it's a blog that you want to set up    What do you gain from using it?    boosted security you're cutting off unnecessary complexities that a dynamically generated content might lead to higher page load time (practically a static site generator builds a requested page beforehand, not “right after” the user has requested it)   When not to use Jekyll or Hugo or any other site generator:   the most relevant example is that of an e-commerce site since products get added to the customer's shopping cart dynamically; a statically generated site can't cope with this kind of requests...   Introducing Hugo  The powerful “younger” rival of Jekyll with an ever-growing community of followers ”seduced” by all those features that it's been equipped with and which Jekyll lacks:   it's way faster (thanks to its Go-based templating) it delivers you an “out-of-the-box experience”   Key limitations:   it doesn't excel when it comes to extensibility: practically it's distributed in one compiled file ... and it's close to impossible for you to upgrade it with plugins or additional functionalities it comes with no admin function like Jekyll does   Introducing Jekyll  The most widely used static site generator! Favored for its:   extended features and collection of plugins  recently added admin function  massive supportive community  Github support: get your site/blog up and running in no time, right after you've hosted it using the Github Pages   Jekyll or Hugo? 6 Criteria to Evaluate The 2 Static Website Generators 1. Installation  We need to admit that both Hugo and Jekyll provide you with very good documentation and great quick-start guides. So, you can launch your site with just one simple command:   hugo new site <your_site>, in Hugo jekyll new site <your_site>, in Jekyll    Still, if we are to compare the two based on this criterion only, we need to add that Jekyll does have a slight advantage: you get a default theme and some example content to start with. It depends on your own site's needs if you take it as an advantage or not quite (for you might not even use the default theme and content when you start up a new site anyway).    2. Speed There's no debate here: Hugo is a static site generator way faster than Jekyll! It's built on Go (compared to Jekyll, that runs on Ruby) and that explains a lot. So, if:   page build speed is a critical factor for you your site carries a heavy ecosystem of pages, content-packed pages that need constant, frequent editing, then Hugo might just be the right choice for you   3. Extensibility “Extensibility” is, no doubt, Jekyll's trump card!  Thanks to its plugin architecture it enables you to easily add extra functionality, to extend your Jekyll-powered website's features once you've set it up. So, the “Jekyll or Hugo?” question is primarily a “speed vs extensibility” debate.   4. Workflow The provided workflow for building your website is another aspect where the 2 static website generators seem to be neck-and-neck. Both the Jekyll server and Hugo server are configured to automatically catch up with any updates that you make to your theme, images, content or configuration while working on your website. Also, they both enable you to add new content to your website's backbone structure just by creating new files in the right place. Note: it's here that we can still “detect” an advantage of Hugo over Jekyll (so they're not THAT even after all); it provides you with certain functions which automatically check that your new files get created precisely in the right parts of your site's frame.   5. Themes In a “Jekyll or Hugo” dilemma the theming aspect does weight a lot, doesn't it? Well, we have 2 types of news for you: a good and a “so and so” one:   each one of them comes with its own surprisingly diversified collection of themes, suitable for all types of websites some might argue that, as you dig through these impressive collections, identifying the one that best fits your own site, narrowing down your searches isn't really a breeze  ... since you're not provided with sufficiently detailed information on each one of them   6. Community And here we have a clear winner: Jekyll! Since it was the very first modern site generator ever built no wonder that it gathered such a large community around it! In short: if support is crucial for you, you'll be thrilled by Jekyll's wide community of peers generating content, backing you up and being there to answer your questions.  So, which one of them has won you over so far, now that you've defined your site's specific profile and you've scanned through these 2 major static website generators' strengths and weaknesses: Jekyll or Hugo?  ... Read more
Adrian Ababei / Oct 26'2017
From Conversational UI to... Conversational FORM Interface?
Did you see this coming? 2016 was, undoubtedly, the year when chatbots ruled over the digital landscape. When all the “players” in the arena rushed to jump on this mega-trend and to ride the tide. And then some of the voice interface's limitations have started to come out. It's in this very context that the conversational form interface (not yet a mega-) trend has started to “steal away some of the spotlights”! It's then that designers with a vision decided to dig deep into the "old trunk" with out-of-fashion web interfaces and take out the “dusty” old web form!  Yet, they weren't that naive to think that users would just move away from cool chat-based interfaces to... filling out clunky, long web forms. They definitely had to give web forms a modern touch to ensure user engagement. And so, they made them... conversational! This is how this “experimental” approach, the hybrid conversational form interface, was “born”! It's designed to improve user experience where conversational interfaces start to show their “weaknesses”. And it's designed to drift away from the classy, unanimously hated web forms. Now, let us highlight for you here both:   the most “irksome” limitations that voice interfaces have started to show how precisely the conversational form UI succeeds to deliver a better user experience where chatbots fail   The Biggest Inconveniences of Using a Purely Conversational UI  “... for both users, development teams and site/app owners.” It looks like chat-based conversational UIs have slightly loosened the “spell” that they had cast on users.  Customers have gradually started to grow frustrated (and this is due mostly to their (too) high expectations in chatbots) when they realized that:   they have to (there's no other way) go through each and every single sentence that the bot asks, which leads to more tapping (and friction) than they would have expected they can't just skip some of the questions in case they don't feel comfortable giving away certain sensitive information they experience the whole information-collecting process as being mandatory, as if they're being “constrained” to divulge that data   On the other hand, compared to a conversational form interface, a purely conversational interface isn't any more convenient on designers'/developers' and their clients' side either:   dealing with the validation of some "tricky" answers isn't precisely a breeze (like when someone enters an invalid phone number, for instance) in order to prevent all kinds of “dumb bot” experiences, the bot has to be perfectly “trained” to parse users' answers correctly (even when faced with situations where users give “I'm a butterfly collector” type of answers to a “What's your job title?” question) it's no easy task for the app's/website's owner to actually set up the chatbot; they need to carefully plan ahead how the questions will be phrased, the used tone and voice etc.   How Exactly Does a Conversational Form Interface Increase User Engagement? Now that we've “exposed” to you the voice interfaces' limitations, it's only logical that we present to you a solution to these issues, right? Introducing web forms turned into conversations? Or conversational forms, if you prefer! What started as an experiment now stands all the chances to perfectly fit all those scenarios when companies can't afford to just blindly jump on the latest UI trend! And where they need to go for a hybrid type of approach instead: conversational UI & web forms. Here's what these “experiments” revealed:   users feel more comfortable knowing that they DO have the option to simply ignore filling in these conversational forms if they want to   since users interact with these forms only within conversations, practically these web forms aren't intrusive, like the old web forms used to be, when they would overlay on top of the open text fields; it doesn't feel like a disruption of the user's flow anymore   the same users tend to provide the required information much quicker than they do when faced with a conversational UI (they're already familiarized with web forms and they do not experience that “awkward” feeling that someone's “asking” them to give away information).   it calls for minimal bot interaction since users get to control, right within the form, whether they've correctly filled in the required fields or not (once they chose a wrong format, they can just correct it themselves)   In short:   it's not just the old “dreaded” type of web forms that users choose to fill in they're actually delivered within the conversational UI itself implicitly, it's not an exclusively voice-based conversation that we're dealing with   ... but with a CI incorporating one or multiple web forms   Bottom Line  “If it doesn't fit, just don't jump on the latest design trend!” As simple as that. Conversational UI doesn't have to be “purely” conversational after all! It could also mean voice-based conversation AND interactive elements such as buttons, cards or forms. If you anticipate that this type of chat-based conversational UI:   won't get you too far with your information-collecting will just manage to irritate your customers   … you can always take a step back from what's currently “hype” and experiment another type of UI instead. Maybe this hybrid conversational form interface will best fit your needs and your customers' expectations.  Maybe you'll be surprised to discover that it's those “oldies but goldies”, “dusty” designs that help:   your users carry out the given tasks faster and with minimal friction you to collect that concise, basic information or data that you need for tailoring your offers/products to your questioned customers' own needs and preferences   What's your opinion on this hybrid approach to UI design? ... Read more
Adrian Ababei / Oct 25'2017
Which Database Should I Choose for My Web App: MySQL or MongoDB?
Each one of the two popular databases “lures” you with its own set of tempting features that the other one lacks. Yet, you need to go beyond the old “relational vs NoSQL” debate to find the answer to your “Which database should I choose for my web app?” question. Therefore, it's more than a generic MySQL vs MongoDB comparison that we'll attempt to make in this post. It's not a well-founded answer to a question like “Which is the best database to use for web applications?” that we'll try to give. Instead, we'll try helping you discover which is THE one that best fits YOUR own web app's use case.   It All Comes Down to One Key Question: “What Type of Web App?” And just like a snowball rolling down a slope, once you've asked yourself this crucial question, expect it to “unleash” other key ones, as well:   What type of data will you be storing in your database? Is it relational data (e.g. social network-specific data, where each user has lots of associated photos, comments, groups etc.) or is it documents or analytical information that your web app's database will be storing?   Would you “trade” data protection guarantee (let's say... losing some of the stored data every dozen thousand transactions?) for really high data insert rate?   Would you store it in a relational schema guaranteeing you clear relationships between entities or would you go for a more flexible data storage format instead? One enabling you to perfectly store dynamic, unique items?   Do you expect your web app to grow any bigger? How big? Are we talking about a “very large” data volume? And this is probably the second most important question to ask yourself after the “Which database should I use for my web app?”   How many queries do you expect it to perform (per minute, hour, day)?   And which is your skills level (or your development team's skills level) in using various databases?   Will your database need to be perfectly equipped to support further and further joins?   What coding language/front-end framework will you be developing your web app in?   And you must surely agree that this is a never-ending list. There are so many aspects relevant for your specific use case, for your specific web app that you should take the time to determine. And to focus on those which weight heavily in your database selection process.   “Which Database Should I Choose for My Web App?” Go With MongoDB If... … it's a web app carrying a heavy write load that you're planning to develop. MongoDB database's biggest advantage over a MySQL one is its capability to accommodate really large data volumes. Take the comments section of high trafficked websites (The New York Times or Craigslist) for instance. Loads and loads of content is being “pumped in”, at high speed, and MongoDB's perfectly equipped to assimilate it all. Note: it might excel in terms of performance, yet it trades transaction safety to achieve that kind of performance. So, make sure you go with MongoDB only if it's not sensitive data that your web app's database will be storing. MongoDB does require a high level of risk tolerance, you know. And there are plenty of other reasons why MongoDB might be a suitable replacement for MySQL for storing data. You should back your web app with a MongoDB database if:   ... it's a small, a start-up business that you own. On open source document-oriented database, which doesn't pigeonhole your data in a rigidly structured schema (it simply stores all the values that you're inserting as documents), which is flexible, easy to set up, to manage, to deploy and to scale, is perfect for your own specific web app's needs.   . … you dream big. This NoSQL database is built to scale (horizontally), to auto-shard (and to replicate) your data as it gets heavier.   . … your web app doesn't require a complex data model and you're good to go with a simpler one. One with no further joins requests and much easier to deploy.   .... it's a prototyping scenario that you're planning to use it in.   And Now: When Not to Use MongoDB? For if it's best-suited for certain scenarios involving backing web apps, it certainly is ill-suited for others. Here are some of them:   if you're looking for an easy way to join tables to your database... MongoDB is not IT   if you're planning to use it as the primary database system for... 1k machines, let's assume. It's not that stable.   if it's security-critical information that you're planning to store in your web app's database (e.g. critical customer information). MongoDB doesn't guarantee you the same level of data protection as MySQL   if it's relational data that you'll be storing (so if there are clear relationships between your entities, e.g. users and reviews)   if you're counting on transaction support   A MySQL Database Might Better Suit Your Web App If... … it's a commercial/end-user app that you're developing, which depends on a strict hierarchy of relationships between various entities. In this case, you can't expect a MongoDB, piling up your data in collections of separate documents, to meet your needs. It's a relational database like MySQL, which stores your data in “conventional” tables, made of rows, that you should back your app with. And if this doesn't really answer your “Which database should I choose for my web app?” question, here are a few other use cases that might get you thinking:   it's not just a traditional RDBMS (relational database management system) that would meet your data storage needs, but a full-featured one. Luckily, MySQL is that “full-feathered” relational database that you need. Over the years it's been upgraded with views, cursors, clustering, triggers, query stored procedures etc.   real-time analytics is crucial for you    you're not willing to trade high data protection standards (let's assume, for instance, that it's a live auction app that you're developing, which will store and retrieve data of critical importance) for... high data insert rate   you need transaction support, security assurance for all the transactions carried out on your app    Also, to give you one more helping hand with your decision-making process, here's a short list of web apps where a MySQL database would work best as a back-end:   e-auctions automated online assistants online retailers e-commerce real-time big data analytics dynamic pricing   When Not to Use MySQL? Which Are Its Key Limitations? It's precisely those scenarios where MongoDB “shines” that MySQL doesn't. Therefore, here are some more clues to help you find the answer to your “Which database should I choose for my web app: MySQL or MongoDB?”:   scaling is definitely not it's trump card; it can't possibly rival a MongoDB database when it comes to horizontal scaling it can't handle high transaction loads so well; from a performance point of view, MySQL isn't built to cope with really big data volumes  although it's been upgraded with replication and clustering features, their implementation isn't precisely a... no brainer   So, which one's going to be? Will you use MongoDB as a backing storage for your web app or MySQL instead? ... Read more
Adrian Ababei / Oct 19'2017
Incoming Feedback by Hotjar: Building User-Friendly Sites & Apps Made Easy!
Building better websites and apps has just got easier! And by “better” we do mean user-friendly (a feature encompassing all the other aspects: UX design, various functionalities, written content, graphic content etc.). How so? Incoming Feedback by Hotjar makes it ideally easy and convenient for your users to give you specific feedback for your site/app (on its copy structure, on its design elements etc.) And right there, on-site, on-page, at precisely THAT moment in their user journeys. For your site visitors it's nothing but a two-clicks process (so much more at hand than answering questions in a poll) and for you, the site/app's owner it's:   a chance to grab instant and contextual feedback from your users … and turn it into actionable insight   And now, let us briefly point out to you:   The context that “called for” such a tool (and what makes it more efficient than conventional polls) How it works precisely How you get to collect, monitor and use all that data to “fuel” your future design/copy/functionality improving strategies   “But Why Incoming Feedback by Hotjar? I May As Well Grab User Feedback via Polls.” Let's play devil's advocate:  Why bother using this tool when you could easily use polls for collecting all the specific feedback you need? Your users would simply (and kindly) answer all the questions in your poll and... voila: a fresh new “crop” of user feedback for you to leverage! But what if:   you ask your questions long time after the user will have actually been on that specific page or has completed that specific action? you risk misinterpreting the collected answers, due to... LACK OF CONTEXT?   And this is precisely where we wanted to get! This new tool by Hotjar, added to their whole suite of all-in-one analytics & feedback tools, brings CONTEXT to the equation. For it's right THEN, right at that specific moment in your user's journey on your website/your app that you get to... pop up your question! Not a few pages after. Not a few hours or days after. The feedback that he/she gives you precisely then is, by far, the most relevant one! Relevant due to:   the context of that specific visited page/visualized designed element/tested functionality/read piece of content the impression that he/she gets about your target site element that very instant!   And How Does This Tool Work Actually? Incoming Feedback by Hotjar is as easy for you to set up and to customize as it is easy for your visitors to use it. 1. You get to configure your widget's color, its position, its flow and, finally, enter your message. It will simply sit at the edge of your screen, looking like a tab. 2. The instant your users will want to give their feedback on the element of your site/app that you point out to in your widget, they instantly get a pop-up up to:   evaluate your site/app on a “Love to Hate” scale enter a quick comment if they feel like putting their feedback into words even use the area selection tool to highlight specific elements on your page (and this gold!) eventually enter their email addresses allowing you to follow up   And there's more:   you get to create as many incoming feedback widgets as you need (since more likely than not it's multiple pages on your website/app that you'll like to get user feedback for) the Incoming Feedback by Hotjar works on all devices   How Do I Centralize The Answers? How Do I Monitor Performance Over Time? “By making a great use of your Incoming Feedback dashboard.” It's a two-in-one dashboard, actually, that you get to use for:   deep analyzing and drilling down the user answers that you will have collected (using various filters) monitoring your newly implemented enhancements' rates of success   Here are the two separate dashboards:   1. The responses dashboard  This is the repository of all the user feedback given for the suggested aspects of your site/app. Here's where you can filter them, by various criteria such as:   liked/disliked or the expressed feedback type time when the feedback was given page URL   … so you can turn them from “just” responses into valuable, actionable insights!   2. The results dashboard  This is where you get:   the full picture of the overall score resulting from your visitors' feedback a breakdown of their feedback over time   It's on this dashboard that you can measure the real impact that your bug fixes, your implemented upgrades and other various improvements to your site/app have on your users.   Bottom Line  Building user-friendly websites & apps has, indeed, just got easier! With a tool like Incoming Feedback by Hotjar you get to:   collect specific user feedback (you get to target particular aspects of your site/app) … instant, contextual type of feedback … and use it to take the needed action for improving the content (both graphic and written) that they dislike    Have you tried it?  ... Read more
Adrian Ababei / Oct 17'2017
10 Ways Your Business Will Benefit From Using HTML5
Creating web content and deploying it on a plethora of:   platforms devices (both modern desktops and mobile browsers) … of different screen sizes … and running different operating systems web browsers markets    … sure has “Mission: Impossible” written all over it, doesn't it? And this is precisely how your business will benefit from using HTML 5: it's been adapted specifically to help you turn all the above-mentioned challenges into... benefits. It's the formatting language that you can use to:   design rich media web pages/mobile web applications to... entice your users with implement them (your websites/web-based mobile apps), seamlessly, on all platforms, notwithstanding layout, design and functionality restrictions   This being said, let's get into it! Let's point out the 10 challenges which you're currently facing, as a business striving to stand still on in the “shifting sands” of the digital web of today. Challenges which HTML 5's built to turn into key advantages for you:   1. Cross-Device Mobile App Development: It Reduces Costs and Development Time In short, here's how your business will benefit from using HTML 5:    your development team can write code once and use it as... many times as needed (the very same batch of code) on several markets, devices and platforms this cannot but translate into: lower lifetime cost and reduced maintenance costs, too, obviously   How about investing those “spared” resources of time, money and effort... elsewhere?   2. It Turns Offline Browsing From a Challenge Into an Offline-Cache Web Experience Another great “app-like” behavior that HTML 5 adopts is that of running without internet connection. That's right, practically your HTML 5 web pages' code and content get stored via the offline application cache. This way, you can guarantee your business website's visitors a great web experience even while they're ... offline. Note: locally storing content and code (and client-side data in true SQL database) will not impact just the user experience, but your website's/app's performance, as well. Basically, offline cache makes possible for code and content to be accessed rapidly, locally, in a “no internet connection” context.   3. Better Mobile Access Translates Into Better Access to Business Intelligence  Just a moment (or two) of reflection on these 2 scenarios here:   you ask your team to either use the very same type of device, all of them, or to develop one business intelligence app for each and every type of device there is out there you use HTML 5 for developing one business intelligence app which will collect, collate and use data on all types of devices, by leveraging browser-based analytics tools   And this is another way that your business will benefit from using HTML 5! It's nothing but pure logic after all: since all devices run an HTML 5-compatible browser, your future business intelligence app will run smoothly on... them all!   4. Video Content Is King Now: Luckily HTML 5 Comes With Native Video Support  Just imagine: you get to build your video content right there, in the supporting browser! No plug-ins required! This can only translate into: faster video distribution to all targeted platforms! How about using the time you'll gain for crafting high-quality video content that will bring you both the targeted audience and SEO on your side?   5. It Makes Front-End App Development a... Breeze What is it that you're “cooking” (or planning to) in terms of front-end apps? Some drag and drop tools? Or maybe some discussion boards? Some wikis? No matter what type of front-end apps you might have in plan, with its standards and all its new features HTML 5 makes their development quicker and easier.  So, how will you value the extra time that your business will benefit from using HTML 5?   6. Here's How You Will Benefit from Using HTML 5: It's Operating System-Agnostic “No strings attached”, here's another possible way of defining HTML 5. For although its runs in a web browser, it's not dependent on the underlying operating system. How does this translate into a key benefit for your own business? Practically while developing your apps you won't need to:   get tangled up in complex, time-consuming development processes get dragged down by support overhead … like it's the case with native apps (iOS, Blackberry, Android)    7. It Turns The Challenge of Cleanly Structuring Your Web Page Into an SEO Advantage  Clean(er), neat(er) and semantically valuable code! This is how you could best describe the “backbone” of an HTML 5 web page. And this is precisely the type of easy-to-read, logical structure that search engine robots “enjoy” crawling through.  Bottom line: gaining search engine visibility is how your online business will benefit from using HTML 5!   8. Running Your Web Pages/Web Apps on ALL Browsers Is No Longer an Issue With HTML 5 It looks like “all the roads lead to” our preliminary definition of HTML 5: “Write once, run anywhere.” By implementing HTML 5 and leveraging the capabilities of CSS 3 your design team can easily create a business website/web app that will run on ALL browsers.     9. It Improves User Experience Via Multimedia and Graphical Content-Rich Web Pages And it's precisely rich-media web pages that create .. enriched web user experiences, right? Luckily HTML 5 makes adding animations, SVG content, audio content, charts, visually-arresting graphics (and the list of design and media types can go on and on) such a breeze. Providing your developers with features such as “<video”, <audio>” etc., they can easily integrate media files into your web pages. Enriched web user experiences... crafted with great ease!   10. It Turns Location-Based App Development from a Challenge into an... Advantage  If it's a location-based app/services that you're planning to develop, then here's how your business will benefit from using HTML 5: since it supports geolocation, APIs will make the user's location available to any browser-based app compatible with HTML 5. As simple as that!   And this is where our list of 10 benefits that you can “reap” from implementing HTML 5 when developing your business website/web-based mobile app. Would you add some more? Or maybe some limitations/downfalls? ... Read more
Adrian Ababei / Oct 17'2017
Look Forward to It: Magento PWA Studio Coming... Soon!
Magento's about to step into... the third dimension of e-commerce!  As you well know, the other 2 are:   responsive e-commerce websites native apps   And the e-commerce giant is about to make its glorious entrance by launching its Magento PWA Studio! A suite of tools designed to empower developers to... develop (obviously!) online stores as progressive web apps.  That Magento has jumped on this trend is really no surprise at all. But the suite of tools that it's now developing is, for sure, a source of ongoing assumptions, skeptic feedback and expectations.  Here's what we know for sure, right from their post on Magento turning into a progressive web application platform:   that these tools are aimed to turn into “learning tools” for future Magento PWA developers  that they're designed to enable them to build blazing-fast PWA front-ends for their e-commerce Magento stores that it's a “toolset” which will help them build PWA components and extensions to be reused or even sold on the Magento Marketplace   But before we get into this, before we shed some more light onto Magento's new “baby” (that they're developing in collaboration with Google) we should answer the next question:   What's a PWA? “The “eraser” of all clear-cut differences between the mobile web and native apps”.  Now, in order to give PWAs a less... metaphoric definition, how about “dissecting” the term itself, “progressive web app”, starting from the back:   it's an app (not an applet!): since it installs and runs its code on the customer's own device (PCs here included)   it's a “web” app: an obvious advantage over native apps, since it's not closely “dependent” on one specific platform and on its specific language; it uses “plain” web languages such as HTML, CSS and JavaScript    it's “progressive”: meaning that it progressively loads assets and data as the user scrolls down a specific page in the store or goes from one page to another; so, there's no need for those “surfed” pages to reload, since changes and transitioning happen... gradually   Summing up, progressive web apps:   look like native apps (delivering the same app-like and lightning-fast digital shopping experiences) behave like responsive mobile websites, since they run in browsers and are written in standard web languages and yet... they're neither native apps nor JavaScript one-page apps   They're... progressive web apps (a no-brainer conclusion, no doubt about it). And it's those type of digital shopping experiences of the future that the Magento PAW Studio's tools will help developers create.   Progressive Web Apps vs Native Apps  It's a fact: native apps “rule” in terms of conversion rates and in terms of provided shopping digital experiences. The mobile web stands no chance to compete with that!  Yet, developing native apps does come with its inconveniences for players in the e-commerce arena (especially for small and medium-sized business):   they're expensive to develop potential shoppers only download and install the apps of those specific brands that they interact with most frequently   And here's how PWAs “dare” to challenge native apps' long-time supremacy:   they're more cost-effective to build since they're developed on open standards (and even so more now, with the Magento PWA Studio soon to be available) they're equally fast they run their code right in the mobile web browser, there's no longer a need for a separate installation   Progressive Web Apps vs Responsive Mobile Sites In short: how are any better (for both online store owners and their customers) than traditional responsive websites? Here's how/why:   they leverage open source technology they rely on the new API's, Service Workers, integrated now into web browsers, which allow JavaScript to run in the background: boosted speed + improved usability   And, deriving from this tiny “detail”, there's a plethora of features that make them a huge leap forward into the future of e-commerce. We've pointed out the most significant ones in this post here on PWA's and how they can benefit your business.   What Does The Magento PWA Studio Include So Far? Now that we've defined PWAs and that we've compared them to the other 2 online shopping channels, let's focus more on Magento's plan to turn into a progressive web app platform. In this respect, here's what this suite of tools includes for now:   application shell: a basic PHTML file, created in the early phase of the project, standing for the basis for the HTML responses (coming from all routes) API layer: working on a new style of API and on new API methods, that could provide lighter, more customized responses (compared to those of the REST designs) application framework: the resulting PWA will be interacting with the “headless” Magento store via API calls    Yet, from all the information that the Magento team shared on their blog, the one with the greatest impact has been that: it's React apps that developers will get to build using the Magento PAW Studio. It's React-powered front-ends that these apps will have. A great news indeed, for all front-end developers out there, since there's no point denying that React's riding huge waves of popularity these days. No wonder that the Drupal core committer team, too, is considering to use React JS for building their own administrative user interfaces.   What's In It for You, The Magento Store Owner? Ok, so we've pointed out how much more enjoyable Magento developers' work is going to be, that they'll be enabled to get their Magento PWAs up and running in no time, but... what about you, the business owner? Let us point out some key PWA features that easily translate into benefits for you:   PWAs are SEO-friendly: thanks to their JavaScript architecture PWAs are easy to crawl through (by search engines' bots); also, they're lightning-fast, which makes them SEO-optimized right from the start    PWAs run on desktop browsers, as well: that's right, they're not restricted to the mobile web since Service Workers run on desktop browsers, too   PWAs will run on Safari, as well: Apple's planning to “do the necessary” so that PWAs can run on Apple devices, as well, in the near future.   The END! For now, at least, since the Magento WAP Studio is still under development, tests are being run, developers' feedback is being collected and closely analyzed. Are you looking forward to it? What's your opinion on progressive web apps shaping the future of e-commerce? ... Read more
Adrian Ababei / Oct 12'2017
Why Should My Company Use Hadoop Over Its Current Data Warehouse?
Or simply put: “What can Hadoop possibly do that my data warehouse can't already?” A predictable and legitimate question following the “Why should my company use Hadoop after all?”. Our today's post is not aimed at convincing you that you should, indeed, replace your current data warehousing solution and move your data over to a Hadoop platform. That would just point out the“why it's best to go with Hadoop”. Instead, we're ready to answer your specific question: “Why should my company use Hadoop as a data storing and data processing solution?” We'll be:   presenting you with specific use cases when Hadoop is, indeed, the best option outlining key advantages of using Hadoop over the traditional data warehousing    When Should You Consider Replacing Your Data Warehouse With Hadoop? One of the most popular sayings here, at our Toronto web design company, is: “if it ain't broken why fix it?”. Therefore, let us point out to you just 2 specific situations where you should consider a massive data migration to Hadoop as your best option:   you're dealing with a huge amount of data  you need built-in capabilities for processing raw and semi-structured data... in a scalable way, of course   Does any of these contexts ring a bell to you? If so, you're better off with Hadoop.   "Why Should My Company Use Hadoop?" 7 Advantages Over Traditional Data Warehousing  For it all comes down to the benefits that your company will gain from such a transition. In this respect, we've put together a list of 7 key reasons why Hadoop is a great asset for your company. Analyze them, weight them, compare them to the benefits that you're currently “reaping” from using your current enterprise solution and... do the math yourself:   1. It's Cost Effective: it's free actually No, no, we're not trying to brush under the carpet costs such as:   staff training investments that you should consider  commodity hardware costs to take into account for storing impossibly large sets of data    And yet, they are insignificant compared to the costs that legacy commercial vendors products' come along with:   annual support offered by the data warehouse's vendor (compared to Hadoop's open source support) perpetual licenses significant costs that each scaling process would call for (no wonder that companies used to get rid of loads of raw data since scaling their data warehouses to accommodate it all was cost prohibitive)   2. It's (so much) Easier to Use: skip formatting and “exploit” your data from day one Here's an answer, which makes a strong argument itself, to your “Why should my company use Hadoop over my current data storage solution?” Its ease of use feature will come as a major surprise to you once you've gone through a:   changing formats complex preprocessing establishing data models   … type of experience with your current enterprise solution. An entire “ordeal” to go through just to be able to finally leverage your own data! With Hadoop it's just a “feed the data” process! That's all! No preliminary steps to take. And where do you add that you get to use all your familiar tools, languages and even to test the newest methods for getting the most value out of our data!   3. It's Flexible: it can capture data from a plethora of data sources And this is gold when you have an entire ecosystem of data sources ready to deliver you data if you just have the right tool to... tap into! Hadoop's perfectly suited for the job: it will access and extract data and provide you with valuable insights from sources ranging from:   social media email conversations   … and lots of other “repositories” of both structured and unstructured data. It will go and get this heterogeneous load of data to you. Data that will then fuel your marketing campaigns, your fraud detection initiatives, your log processing actions etc. Do giants such Marks & Spencer and Yahoo and their own use cases of Hadoop make convincing enough answers to your “Why should my company use Hadoop?” question? They're using Hadoop to:   play the “personalization” card right put together cross-functional teams (IT, marketing, e-commerce, finance...) thanks to Hadoop's capability to seamlessly process all types of data gain a better understanding of their customers (this is where Predictive analytics comes into play)    And this is what extracting value from your own data, that's just sitting there, waiting to be leveraged, really means.   4. It's Open Source Technology: bugs and feature development handled by multiple companies Just try to compare bug fixing and new features development being handled by a single company (your commercial license vendor) to the same processes being carried out by hundreds of companies! In other words: when choosing Hadoop as your data storage platform there's an entire community of contributing companies offering you support and continuously improving the platform.   5. It's Built With High Scalability in Mind: keep on adding more and more data clusters How easily (or “costly”) is it to scale your current data warehouse to accommodate your increasing amounts of data? Hadoop scales... organically, using low-cost hardware as a unique resource! Here's how it works:    as you add new and new heavy nodes (clustering thousands of terabytes of data) Hadoop manages to seamlessly accommodate it all  … and to distribute it across hundreds of inexpensive servers that run in parallel   Scalability is, undoubtedly, one of Hadoop's “five-star” features, the one that traditional relational database systems (RDBMS) can't possibly compete with!    6. It's Fast: data processing at high speed When you're questioning yourself “Why should my company use Hadoop instead of sticking to its current data warehousing solution?”, you might be thinking, in fact: “How much faster than my current data warehouse can Hadoop process data?” A lot faster! And this is exclusively thanks to its unique data storage method: the data mapping & the data processing happen on the same server where data is stored. This way mapping and processing massive volumes of unstructured data is no challenge for Hadoop at all: it will map it no matter where it might be located in a cluster. And so processing it (we're talking about petabytes of data here) turns into a matter of hours!   7. It's Equipped to Handle Fails Remarkably: say Hello to automatic data replication! You can run, but there's no way of hiding/completely avoiding cluster fails! But luckily Hadoop provides you with a great “safety net” type of capability: it automatically replicates data for you, sending it to other nodes. So, when faults happen (and they will), you can stay reassured: Hadoop will always have copies of your data ready to be passed on to other, non-compromised locations of your data infrastructure.   Final Thoughts Or “recommendations” if you prefer:   if it's small data that your company's “piled up” so far, if there are small files that you need to store and leverage, don't go for Hadoop if you don't really need to access and to process your unstructured or semi-structured data, there's no real need to use Hadoop   Now getting back to the initial question, “Why should my company use Hadoop over its current data warehouse?”, our answer is: “Because Hadoop is built and being constantly enhanced with impossibly large amounts of data in mind!" ... Read more
Adrian Ababei / Oct 11'2017
Using React JS for Drupal's Administrative UIs: What to Expect?
He proposed it: “... make some of Drupal's own administrative UIs more powerful and easier to use, I proposed that we add a modern JavaScript to core.” (Dries Buytaert's keynote presentation, DrupalCon Vienna) ... and stirred waves of enthusiasm, of unveiled skepticism and never-ending debates. What would using React JS for Drupal's administrative UIs mean for you? You, the site builder. You, the content creator? And this is precisely what we'll try to answer in this blog post as we'll be:   presenting you the context: why is integrating a JavaScript framework right into Drupal core even needed? pointing our Drupal's long way to becoming “ JS ready” highlighting the reasons why React's most likely to win this “popularity contest” over other JS technologies highlighting the challenges to expect and to plan out for (to overcome) if React is, indeed, the “chosen one” outlining the clear benefits that YOU will get if a JavaScript framework, more precisely if React does get integrated into Drupal core   3 Inconveniences for Currently Not Having a JavaScript Framework in Drupal Core While headless Drupal 8 has proven to be a powerful content repository for front-end apps, not having a JS framework integrated into its very core has been the cause of certain … limitations:   it kept putting off addressing well-known editorial and site-building UX issues it made it almost impossible to help Drupal core contributors realize how they could leverage certain JavaScript approaches and advanced practices; how they could transpose them into new modules and new Drupal features it has been a break on assimilating more JavaScript experts and JS expertise into the Drupal community    From Improving Its Web Services APIs to Being Ready for Integrating a JS Framework in Core You're closer than ever, as a site builder/content creator, to using React JS for Drupal's administrative UIs. Yet, this didn't happen overnight: first Dries Buytaert (Drupal CMS's founder himself) and his team decided to stabilize Drupal's web services APIs then to step up their efforts even more for improving them and it's just now that they've decided that Drupal's finally matured and 100% ready for this major integration    Meanwhile, Drupal users have done wonders leveraging Drupal 8's web services APIs:   front-end apps have been built alongside Drupal, which has been backing them up as their content repository … and modern, JavaScript frameworks have been used for powering these apps' front-ends, with no restriction, whatsoever, on the particular JS technologies that web developers chose to use   Now having passed the “decoupled architecture test” and having managed to adapt itself to all JavaScript frameworks used as front-ends, Drupal's ready to...  level up! To incorporate a JavaScript framework in its core. And, implicitly, it's time for the Drupal community, as well, to commit to a unique framework that will be used for its administrative front-end.   Why React JS? We'll start by answering the “Why React JS over Angular or Ember?” question: “Because of its component-based nature.” And there's a growing “trend” among web developers to create user interfaces by putting together reusable component libraries. Luckily, React makes it easy to build self-contained components and to simply “assemble” them in big-sized apps. Therefore, the other 2 JS frameworks (focused on MV* specific workflows instead), are off the table. And now, let's list other reasons for using React JS for Drupal's administrate UIs:   it's backed up and constantly updated with new libraries, new tutorials etc. by a worldwide, active community of developers   it powers large-scale web projects such as Facebook, Airbnb, WordPress, The New York Times    it's this community itself that bundled up an ecosystem of no less than 16.000 libraries around it   its different approach to virtual DOM (Document Object Model): it “detects” precisely those virtual DOM objects that need to be updated and it's strictly those parts of the real DOM that it updates (instead of updating the entire DOM tree); a major performance boost indeed   it poses no problems working with it thanks to its rather straightforward programming approach   it “plays well” with all the other JS frameworks   licensing issues reported in the past have been resolved   it's widely used by the JavaScript developers    Expected Challenges of Working With React JS For there are challenges that the Drupal's main contributors are planning out for when it comes to using React JS for Drupal's core. And so should you:   modularity, itself, will turn out to be a major challenge to plan out for Drupal will need to “keep up with” React's much more alert release cycle  Drupal theming for decoupled UIs will never be the same again: React's approach will prevail   Using React JS for Drupal's Administrative Interfaces: What's in It for You? For adopting a JS framework for Drupal's own administrative UIs (and React seems to be the winning “competitor), does translate into key benefits for you, as well:   whether you're a Drupal site builder or a content creator, using Drupal will get much easier (talking about addressing its old UX issues right?) in a reversible, incremental way   building modern UIs will get a lot more streamlined when you have a modern, JS toolbox right at hand... in Drupal core!   a JavaScript framework would automatically speed up (“app-like speed”) content modeling, configuration tools, content listing   if you're a Drupal developer, you can stay reassured that your Drupal expertise will stay relevant in a JavaScript technologies-centered web   ... that, your future React-focused sills will be future-proofed (thanks to this JS technology's high popularity among web developers)   What do you think? Do you find adding a JavaScript framework to Drupal core a good idea or not? And what about using React JS for Drupal? Would you have gone for another JS technology instead if you could have chosen the one to power your administrative UIs from now on? ... Read more
Adrian Ababei / Oct 09'2017