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
10-Point Drupal SEO Checklist: Before You Launch Your New Site
“Hasty climbers have sudden falls...” So you're ready to take off. To release into the wild that shiny and new Drupal site of yours, carrying hundreds of hours of work. It's got the looks and it sure has the power, but is that all it takes to ensure it a successful launch? How about SEO? Here's the essential Drupal SEO checklist to go through for boosting its search engine ranking and for ensuring it a significantly high traffic wave right from its early days.   1. On Top of Your Drupal SEO Checklist: Is The Redirect Module On?  Take it as a more than handy solution for getting your users on the right track. The track to your Drupal site! Practically here's how this module works:   whenever a potential site visitor clicks a broken URL to your website  whenever a user enters a typo while trying to access your site   … Redirect... redirects (obviously!) those users from their way to “no man's land”, where those broken links (and typos) would have taken them, to your welcoming front page. Moreover, the module helps you keep track of how many times your site visitors land on your website via redirects!   2. Have You Been Using The Pathauto Module to Create MEANINGFUL URLs? In other words: have you actually built your Drupal site for the users? And implicitly for search engines, too? For, if not, neither of them will “digest” those “node/123” type of path aliases that Drupal automatically created for you. This is where the Pathauto module comes in handy: it will set up specific patterns and rules to be followed when putting together new URLs, making site navigation a breeze for your visitors and search engines' bots crawling in. In short: it creates “meaningful” links, replacing the “node-like”, totally user-unfriendly URLs on your Drupal site. How could we have possibly not included this point in your Drupal SEO checklist, right?   3. Does Every URL On Your Site Include a Target Keyword? We're well aware of it. This sort of “mapping” all the targeted keywords on your website and all the associated page URLs is probably one of the most tedious of all the steps included in your Drupal SEO checklist! Yet, it's worth it! And it's crucial that you carry it out now, before launch day:   double check whether all those keywords included in your “target keywords list” (that you will have set up after a throughout keyword research process) are there, on your Drupal site next, that every web page has a target keyword assigned to   Where there's a gap, a “missing” keyword or a URL with no focus keyword, make sure you fill it in!   4. Have You Enabled the Site Verification Module? No? Then hurry up and get it enabled and properly configured. The insignificant time you'll spend and the little effort you'll invest in carrying out this quick step is minimal compared to the benefits you'll reap:   the Site Verification module will indicate to you all the boxes to check for “reassuring” search engines that you actually own this site which will grant you access to more in-depth, private Google search data    … and help win web crawlers' “trust”; they will then crawl your website more “confidently” and this cannot but translate into high ranking for your new Drupal site.   5. Is The Global Redirect Module Enabled? And Properly Configured, too? Is it a Drupal 8 site that you're about to launch? Then just skip this step from your Drupal SEO Checklist: in Drupal 8 the functionality we're about to point out to you has been “injected” into the Redirect module! If not, we strongly recommend you to “team up” your Redirect module with Global Redirect. And here are the arguments:   it monitors and runs tests on all your URL, the ones without a trailing slash here included it makes sure that all your site's links are case-insensitive it redirects those “unlucky” users that run into broken links from a far less welcoming “404 page” to your site's front page instead   In short: as you leverage these 2 modules' powers you're basically welcoming in all potential visitors; both those trying to access your website and those who are already surfing it, trying to get to specific pages on your site, and all this even if they use broken access links.   6. How About the Search 404 Drupal Module? And speaking about properly handling All user requests, even to temporarily inaccessible sections of your Drupal site, the Search 404 module makes your best ally! It does precisely what its names says: it helps you greet those “unfortunate” visitors with a “404” page instead of a discouraging “Error: Page not Found” one. Moreover, it “rescues” them from that “dead-end” type of page by recommending them an alternative URL on your site. A true “bounce rate” killer!   7. Are Both The Google News Sitemap and The XML Sitemap Properly Configured? And what handier way to make sure that they are than by simply installing and correctly configuring the XML Sitemap module? It will automatically set up that bot-friendly map of your Drupal site that search engines can use to crawl in and easily index your website. So, once you've enabled your module, make sure you go for the right configuration options at admin/config/search/XML sitemap and that you properly set up your XML Sitemap.  Note: no need to put together your site's XML sitemap if it contains AMPs! Now that you've reached that point of your Drupal SEO checklist where you're addressing issues that might make your website inaccessible (or simply “unattractive”) to search engines, here are just a few more aspects to check:   that you've left no duplicate content lingering on your website that there are no broken URLs that web crawls can easily... crawl any page on your website that there are no pages lacking any sort of content or having too little of it   8. Have You Used Proper OG Tags? A Key Box to Check on Your Drupal SEO Checklist! Why should you rely on... chance while striving to make your shiny and new Drupal site ideally social when you can actually control its appearance on social media. And OG (Open Graph) tags make a great example of how you get empowered to define, yourself, how your site will look on Facebook, which taglines to be used, which images etc. Just double check that you've implemented the most suitable, properly descriptive ones before you... press that launch button!   9. Does Every Page on Your Drupal Site Have A Unique Title? “A unique and meaningful title” we should add. Do not underestimate the power of an attractive, SEO-friendly title! And if you want to make sure that all the pages on your brand new website have titles that:   stand out in search engines stir attention match the user's search terms   … just lay back and let the Drupal Page Title module do all the hard work for you.   10. Are Your Meta Tags Attractively and Relevantly Descriptive? They should be, so mind you don't neglect them before you let your site... take off! Since meta tags still enjoy a “VIP status” among on-page ranking factors. And for streamlining the whole meta tags SEO-optimizing process just harness the Metatag module's power! It will:   provide you with a user-friendly UI for managing your meta data  enable you to easily fill in your metadata fields with relevant keywords, with a user-friendly, SEO-optimized page description and so on grant you additional control over your Drupal site's looks when shared on social media   End of the list! The essential Drupal SEO checklist for you to go through if you want to jump-start your SEO before launch day! ... Read more
Adrian Ababei / Nov 02'2017
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 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 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 request...   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 as 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, which 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 weigh 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? If you need professional support in your database development projects, get in touch with Optasy.  ... 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 an 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 a true SQL database) will not impact just the user experience, but your website's/app's performance, as well. Basically, the offline cache makes it 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. Although it 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/service 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” that 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 on 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 types 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 businesses):   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 are 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. 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 using 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? You can also check out our Magento website design services in Vancouver.  ... 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