LATEST FROM OUR BLOG

Take your daily dose of (only) relevant news, useful tips and tricks and valuable how to's on using the latest web technologies shaping the digital landscape. We're here to do all the necessary information sifting for you, so you don't have to, to provide you with content that will help you anticipate the emerging trends about to influence the web.

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
Why Mule ESB? Why Switch to It  from Your Current Point-to-Point Integration System? 5 Reasons
Is your enterprise “ecosystem” of apps, systems, and IT components getting overwhelmingly complex? Is managing it and leveraging it getting increasingly challenging? Then it's a fact: you need to get them organized in a more effective infrastructure. One that should bridge them all together and enable a continuous flow of data across the whole structure. You need to move away from the traditional point-to-point integration system and go for an ESB instead. "But why Mule ESB?" A more than valid question. Here are 5 top reasons why it stands out from all the other ESB products. Why you should consider using it as your future integration platform:   But First: What Is an ESB More Precisely? Take it as a set of principles rather than as a software on its own. A set of “rules” for building out your bus-like infrastructure where your disparate systems:   get bridged together exchange data via the communication bus that this ESB system provides; and it's a two-way communication process that takes place: the systems share data among them and they all communicate with the bus individually, as well are independent of one another   And it's this very last feature that what makes the ESB architecture such a big “leap” ahead from the traditional point-to-point integration system. But how does this type of bus-like infrastructure for organizing your apps and systems benefit you precisely:   it speeds up marketing your new initiatives it enhances productivity, translated into more apps developed within your organization it allows you to leverage your existing systems during app development thanks to all the pre-built communication and transformation capabilities   Why Move Away From a Traditional Point-to-Point Integration? Because in a point-to-point integration system your apps are tightly dependent on one another. And this “dependency relation” does interfere with the very principle of organizational agility, doesn't it?   What Is Mule ESB? What Sets It Apart from Other ESB Products? To answer your first question: Mule Soft is a lightweight, highly scalable Java-based service bus (or integration platform, if you prefer) which:   enables developers to connect a whole ecosystem of Saas, on-premises apps and disparate systems quick and easy … and to enhance communication between them, a continuous data flow alongside the infrastructure   “And what makes Mule as an ESB stand out from the crowd of other ESB products?”   Let's point out those key features that set Mule ESB apart from the its “competitors: it's, in fact, a component part of a larger structure of API design management capabilities it comes with a pre-built library of templates … and with out-of-the-box connectors enhancing the reusability of components (and this is big)  it comes with built-in agile software development methods and multiple toolchains boosting your developers' productivity   Why Mule ESB? Top 5 Reasons to Consider Using It as Your App Integration Technology 1. It Scales Effectively, Both Up and Down  And this key feature translates into unlimited freedom for your teams to bridge together as many apps and systems as needed. Mule ESB will scale to efficiently incorporate them all! In addition to being effectively scalable, Mule ESB's ideally embeddable, as well:   you can embed it into a single app, directly or you can plug it into your app server (JBoss, WAS, Tomcat) instead and even into a JUnit test case (for yes, it does come with built-in JUnit support, as well)   2. It Perfectly Integrates All Components, Irrespective of the Technology Used And this is a strong argument to consider when you're asking yourself: “Why Mule ESB over another ESB product?” It's definitely not a restrictive or “picky” ESB: it will incorporate all the existing systems regardless of the technologies that they might be running on: Web Services, JMS, HTTP, JDBC, you name it.  … from a “POJO” to a component coming from a different framework! Moreover, not only that it integrates them all under its “umbrella”, but it enhances communication across this infrastructure of various apps and multiple systems. It allows data flows between the bridged apps within your organization and across the web.   3. It's Highly Accessible, Supporting a Wide Variety of Code Languages And this is great news for your Java developers!  Since it:   comes with a set of widely used tools (Maven, Eclipse, Spring, JUnit) that your team's already familiar with uses an XML transformation language for presenting logic layers supports multiple code languages: JavaScript, Ruby, Java, Python...   In short: your development team will face no problems writing custom code.   4. It  Enables You to Reuse Your Components Here's another reason that makes a great answer, alone, to your “Why Mule ESB?” question! Unlike other integration platforms out there, this one enables reusability! Your team's empowered to reuse your infrastructure's components. Therefore, it enables them to run the existing ones since it doesn't call for Mule-specific code.   5. It's Ideally Lightweight Mule ESB does, indeed, stand out from a “weight” point of view. Moreover, thanks to its modular design you get to make it even lighter by removing all the modules that you won't use. While thanks to its configuration model you get to easily add, re-order and upgrade functionality sparing the time you'd otherwise invest in implementing changes to your existing integrations instead.   And this is THE list! The one including 5 key reasons why Mule ESB could make a great choice when you consider using an integration platform within your company. Are there any other ESB products competing with it for your appreciation? Are these 5 reasons not convincing enough or have you already identified possible drawbacks balancing them? Do share your thoughts! ... Read more
Adrian Ababei / Oct 05'2017