WebriQ Blog

JAMstack for Web Marketers

Tue, 05 Mar 2019 22:49:00 GMT

JAM stands for JavaScript, APIs, and Markup.

In terms of what this means to you as a marketer – it’s essentially a modern way to build a website that is published as a set of static HTML files.

As a marketeer, you are obviously familiar with the 4 Ps and the marketing mix.

The term Marketing Mix was developed by Neil Borden who first started using the phrase in 1949. “An executive is a mixer of ingredients, who sometimes follows a recipe as he goes along, sometimes adapts a recipe to the ingredients immediately available, and sometimes experiments with or invents ingredients no one else has tried.” (Culliton, J. 1948)

E. Jerome McCarthy (McCarthy, J. 1960) was the first person to suggest the four Ps of marketing – price, promotion, product, and place (distribution). These constitute the most common variables used in constructing a marketing mix. According to McCarthy, the marketers essentially have these four variables which they can use while crafting a marketing strategy and writing a marketing plan.

All these basics concepts have evolved over time, and now some marketing gurus are talking about 6 Ps, the 2 new ones being Process and People.

The way we build websites, the way viewers consume websites, and what they expect from a website has evolved over time as well. For a marketer, a website needs to quickly grab a viewer’s attention and lead them to where they can start interacting with the website. And as websites may not have the long tradition and history of the marketing mix, building one has its own credos. Instead of the 4 Ps, we call it the 4 S (speed, security, stability, and scalability).

Whilst the 4 S are important to web developers and websites in general, they are important to marketeers as well. Speed and better performance means better site engagement and better SEO. Improved security means a better chance that you will reach your online marketing goals, because there is no chance your site will be down or hacked.

Cheaper, easier and faster to scale, means that new features can be added pretty easily and that you do not have to worry about being hit by 100,000 visitors at once because of a successful campaign.

Moving Away from Monolithic CMS and Plugins

Building a marketing website with well-known platforms like Wordpress or Drupal that offer plugins, add-ons, and other easy wins for marketers has been a great idea for many years. Sometimes it is a great idea. But too many times, performance is seriously lagging and the only real solution is to start over and build something that is suited to your specific needs, without all of the extra bloat.

Hacked up themes, page builders, and plugins for all of the things can wreak havoc with site performance if you have a dynamic site powered by a monolithic CMS. This has a knock-on effect on the user experience, SEO, and overall effectiveness of your website.

Site performance and site speed is an increasingly important ranking factor. Not only that, all of the top ranking factors these days are related to on-site engagement, which also suffers if you haven’t got a site that performs.

Ditching the concept of the plugin and opting for a JAMstack site which is “just HTML” doesn’t actually mean you have to give up functionality, or suddenly need to know how to code like a front-end developer to manage a site and its content. You can still achieve the same results with an ecosystem of tools and services that are tailored specifically for you. Yes it takes some development up-front (let’s be real, so does any website) - but the payoff is huge!

Moving Your Marketing Website to JAMstack

If you are looking to move your marketing website to JAMstack, here are the boxes you should tick:

1. Look for a Team with Strong Javascript Skills

For brands who are looking to move over to the JAMstack, the in-house or outsourced web development team should be well-versed in JavaScript and API ecosystem. We’re talking about front-end-centric development here.

2. The Choice of a Headless CMS

Strapi is a good example of a headless CMS

In order for your CMS to be JAMstack-ready, it has to be compatible with JavaScript. A headless CMS decouples the back end - which stores all the content, databases, and files - from the front end. Typically, a headless CMS uses APIs, through which content can be pushed and pulled between various platforms and devices.

Additionally, a headless CMS is front-end framework agnostic, making it compatible for Javascript frameworks like Angular.js, React, or Next.js to name a few. APIs give other applications easy access to your content which could include landing pages, microsites, or native iOS, and Android applications.

3. Choose a Suitable Static Site Generator

A static site generator (SSG) is the perfect partner for a headless CMS. An SSG generates an HTML-only website using markdown files. That static site can then be uploaded to a Content Delivery Network (CDN), remaining unchanged until the next time the SSG is run.

4. Choose WebriQ GLUE

If this is all a bit overwhelming and you need help in choosing all the building blocks, and your in-house capabilities are just not up to the job, WebriQ GLUE might be a good option to consider.

We have developed a very opinionated way of implementing websites, ecommerce carts, and webapps and we completely moved away from a monolithic, legacy and centralized approach. We believe in a decentralized approach whereby each software component is chosen for it is best in class, but at the same time replaceable with a newer best in class if needed. Where we can not find a best in class critical functionality that is open sourced, we develop it ourselves, i.e. WebriQ Forms.

We are strong supporters of the API economy and we strongly believe in microservices when it comes to functionality and automation. We aim at 100% serverless operation, and we know how to do that. We also aim for 100% uptime and, yes, we know what it takes to achieve this. We are highly specialized, and opinionated when it comes to the technology stack used.

test

Wed, 20 Feb 2019 16:00:00 GMT

test

The web has changed, so must our way to publish content for the web.

Sun, 20 Jan 2019 16:00:00 GMT

We now live in a multichannel world

51.3% of people now spend more time searching the Internet on mobiles than on desktops. US Consumers use on average 3.5 connected devices each. Augmented reality and virtual reality (AR/VR) market will grow from $5.2b in 2016 to more than $162b in 2020.

We need a new way of managing content in this multichannel world. We have been using traditional CMS systems, also referred to as monolithic CMS systems for years now. They are called monolithic because they handle the content in a database, and also handle the entire presentation layer. The most predominant players in the market are Wordpress, Drupal and Joomla to a lesser extend. Beyond have been around for over a decade, the biggest issue these systems have is that they are not well suited for a multichannel environment and usually support traditional rigid business processes.

In the new multichannel world, your content may be consumed on any number of devices. If you do not want to miss the opportunity of truly engaging with your customers, you need to make sure your content is ready for multiple channels. This requires a whole new mindset in structuring, organizing, managing, and presenting content. Unfortunately, traditional CMS systems were built with just websites in mind and, although they do support structured content, the multichannel approach is an afterthought for them and they do not support the new paradigm well.

Companies, waking up to the realization they need to be agile, are increasingly moving their systems to the Cloud. They recognize that running systems internally is less efficient and lacks the flexibility and speed they need in today’s dynamic world. While traditional CMS systems can be hosted in the cloud environment, they weren’t designed as Software as a Service (SaaS) products and lack the benefits of a true cloud-first solution.

Headless CMS - next generation in content management

In order to stay competitive and connected with your customers, you need a new generation of CMS—a cloud-first headless CMS. We’re at the very beginning of this new era. If you’re choosing a CMS today, you need to consider whether a monolithic digital experience platform or a new cloud-first headless CMS product is best for you.

Headless CMS is a content management system that allows you to manage content and access it from your applications using an API. Unlike traditional CMS solutions, headless CMS does without the presentation layer (the “head”) that would dictate how the content should be displayed. Instead, you control the presentation completely with your own code. This not only enables a content-first approach to your engagement with your audience (as content creators no longer have to wait for development teams to catch up) but it means you can use the same content across multiple channels—website, mobile app, digital assistant, virtual reality, smart watches, etc.—making the headless CMS the ideal solution for the fast-paced multichannel world.

True headless-first versus “me too” headless CMS

Many traditional coupled or decoupled CMS systems provide some kind of REST API and claim they are “hybrid” or “also headless”. You should be aware, however, of important details that make a big difference between a CMS that was designed with a headless or “API- first” approach in mind from the very beginning, versus a CMS for which the API was an afterthought. This is definitely the case for Wordpress REST API. Oftentimes you will discover that this REST API may not even make such content available or the way the content is provided makes it useless for other channels, like a mobile app. A true headless CMS was built with an API-first approach. Its creators usually pay a lot of attention to the API and the whole solution is designed in a way that enables its full power. Traditional CMS products often provide just a pure REST API, lacking the additional elements that ensure high scalability and security of the APIs in real-world applications. They usually don’t provide a Content Delivery Network (CDN) to ensure global coverage, or high speed or high service availability, which has a considerable negative impact on its overall performance.

True SaaS CMS versus CMS hosted in the Cloud

The most revolutionary aspect of the headless approach is that it enables CMS vendors to provide a CMS in a true multitenant Software as a Service model. This wasn’t possible with traditional CMS models that combined both content management and content presentation. In fact, it’s one of the main reasons traditional CMS vendors only provide single-tenant managed hosting or Platform as a Service (PaaS) hosting for their products. Such models, however, don’t unlock all the benefits of the Cloud.

Selection of the major players in the Headless CMS market

Contentful

Founded in 2013, Germany-based Contentful offers an API-driven headless CMS. Contentful’s RESTful API gives developers full programmatic control of content, digital assets, and translations. The platform also takes advantage of caching techniques as well as external CDN integrations to enable the delivery of API payloads in the sub-100ms range. It has the ability to display JSON snippets, a rich-text editor, and content modelling features the enable marketers to arrange individual fields and content modules such as text, images and calendars.

Directus

Brooklyn-based Directus is an open source headless CMS and API. Built using Vue.js., Directus manages custom-schema SQL databases directly. The idea is that developers can create custom databases based on specific project needs without learning a proprietary framework or being forced to build using specific technologies. When the database is ready, Directus’ API or SDKs can be connected, resulting in a customizable interface that business users can use to manage database content for their websites and applications.

GraphQL CMS - GraphCMS

Giessen, Germany-based GraphCMS is an API-first CMS that entered the market in 2017. The product is based on GraphQL, a data query language that some developers consider to be the successor to REST. GraphCMS allows you to develop a hosted GraphQL back-end for your application where you can define relations, structures, and permissions of your application data. It also comes with a number of tools to create and manage your content, including text editors, asset management, workflows, user roles, and multi-lingual support.

Prismic

San Francisco-based Prismic is a SaaS headless CMS that comes with a visual editor, custom type builds, multi-language support, and full revision history. As well as native integrations with eCommerce platforms like Shopify and Magento, Prismic comes with a scheduling and project management tool to enable collaboration and workflow management. Prismic provides developers with a development kit for their preferred programming language or framework.

Sanity

Launched in 2015, Sanity is an open source headless CMS that was developed in Oslo, Norway. Built on JavaScript and React.js, Sanity features a WYSIWYG rich text editor which allows you to embed editable data in running text and defer markup to render time. It also comes with a Sweet Query API that enables you to cache multiple queries on a single request. Sanity also provides real-time collaboration, live previewing, and content versioning.

Strapi

France-based Strapi is an open source headless CMS built on Node.js. It enables you to build and manage multiple APIs. The front-end agnostic platform features an extensible and customizable admin panel, plugins, asset management, and several security layers including CSFR, CORS, P3P, and XSS.

While the technology will differ from vendor to vendor, the biggest difference you’ll feel is the level of service and support the vendor will provide during deployment, and thereafter. Going headless isn’t the easiest transition your brand will make, so be sure to choose a vendor with a history of giving hands-on assistance and supportive expertise. Or choose WebriQ GLUE where we have prequalified and implemented all the building blocks of a true headless CMS approach, and where support and ongoing maintenance and updates are in the DNA of the service. We have been designing and developing websites and web apps for a long time, and we have seen all the deficiencies of project based pricing, per hour pricing, unknowns in devops, unknowns in maintenance, overruns, delays etc. We have developed a very opinionated way of implementing websites, ecommerce carts and webapps and we completely moved away from a monolithic, legacy and centralized approach. We believe in a decentralized approach whereby each software component is chosen for it’s best in class, but at the same time replaceable with a newer best in class if needed. Where we can not find a best in class critical functionality that is open sourced, we develop it ourselves, i.e. WebriQ Forms. We are strong supporters of the API economy and we strongly believe in microservices when it comes to functionality and automation. We aim at 100% serverless operation, and we know how to do that and we aim at 100% uptime, and we know how to do that. We are highly specialized, and opinionated when it comes to the technology stack used.

Monolithic or Headless CMS

Tue, 25 Dec 2018 16:00:00 GMT

What is a Monolithic or Legacy Content Management System?

In recent years, commercial CMS platforms have been targeted more to CMOs, by focusing heavily on marketing-specific technologies. Open-source platforms have focused much more on extensibility, making them truer “platforms” in that they can be easily built upon. Commercial “products” haven’t focused on extensibility as much as they have on feature sets that help them demo and sell licenses more easily. But one thing is common across all of these options: They’ve become more and more bloated as they try harder and harder to accommodate more use cases.

Traditional CMS systems are called monolithic because they pack all functionality, presentation and assumptions of how you work in one single system. They are called legacy because they have been around for quite a while, are build on old(er) technology stacks. In the last 5 years, the traditional CMS landscape has not evolved much - both CMS technologies as well market maturity remains unchanged. There is hardly any innovation from traditional CMS vendors. Although some vendors have added support for APIs and cloud services most have not even bothered to adapt with changing technology landscape. Case-in-point, most enterprise CMS vendors lack robust full-site content delivery network (CDN) integration. In fact, CDN support is often limited to static assets not realizing that with the arrival of HTTP2 domain sharding is a thing of past. When it comes to innovation, most of CMS solutions are constrained by their legacy architecture (read strong coupling between content management and content presentation) which makes it difficult to serve content to new types of emerging channels such as apps and devices. API support is critical for innovation but it needs to be a first-class citizen and not afterthought. In addition, traditional CMS solutions lack integration with modern software stack, cloud services, and software delivery pipelines. Possibility to apply continuous integration (CI) and continuous delivery (CD) concepts with a traditional CMS is mostly unheard-of. At the core, a traditional CMS is a monoliath. Any organization pursuing micro services strategy will find hard to fit a traditional CMS in their ecosystem.

What is a Headless CMS?

A headless CMS has no presentation layer and makes content available through APIs. With a headless CMS, the task of the content presentation is performed by an external client consuming APIs exposed by headless CMS. Here are few examples of an external client utilising the APIs exposed by a headless CMS: static site generator (SSG), single page application (SPA) (client-side as well as server-side rendering), a mobile app, a WordPress site, or an IoT device. These are usually called “Headless” or “API-first” CMSs. Some of them market themselves as “Content infrastructure,” “Content Hubs” or even “Content as a Service.” However, when you take a closer look, they all pretty much boil down to some database backend with a web-based user interface, where you access the content through an API. But WTF is an API?

What is an API?

API stands for Application Programming Interface, which in this context means that you get content in a way that is easier to integrate with existing or new software solutions. Usually, you do this by sending a network request to an endpoint. This network request is pretty much the same thing you do when visiting a webpage, e.g., https://yourdomain.com/api/posts/, but instead of a web page, you get a list with the post’s contents back. Developers can use this information when building software, be it an app, a voice interface, or a webpage. Most of today’s developers are used to programming with APIs and prefer them because it leaves them in control for how to build their systems. Some CMSs also allow changing content through APIs. API is a pretty generic term and goes beyond the world of CMSs and the World Wide Web. Most Headless CMS systems will expose their content through a REST API. REST APIs can be great for simple data structures but tend to get tedious and time-consuming to use when your content models are more complex. It’s also a more laborious exercise to change or fit these APIs for different uses. Facebook developed the API standard GraphQL as a response to the less flexible REST convention. GraphQL lets you query the API with the fields and relationships you need for each occasion, almost like what you can do directly with a database. It’s also easier to implement new fields and content types as your system matures.

Headless CMS will render its content through APIs and Application Delivery Networks

A CDN has become a lot easier and cheaper. Now a day there are so many options - Amazon CloudFront, Cloudflare, Google CDN, Azure CDN, Edgecast, Fastly, and the list goes on. Gone the days when you required to have big fat-contract with Akamai. With most of CDN services, you can start small and pay as you go. Having a CDN in front of origin (static site or APIs) reduces the global and regional latency. This is achieved by caching content (static HTML page, assets, APIs) at a large number of geographically distributed edge locations. In addition, CDNs scale really well - we are talking about 5-10k concurrent requests without any issues. To protect origin server from request overload some CDNs also support origin shield - an additional caching layer between edge and origin servers. Typically, this mid-tier caching is a designate edge or pop location closer to your origin server and other edge servers query origin shield rather than origin directly. Hosting companies like Netlify refer to their CDN infrastructure as Application Delivery Network (ADN), which has no distinction between edge and origin servers. This is primarily to support the atomic deploy model and instant cache invalidation so that there is no risk of stale content or inconsistent state. With ADN, switching between multiple version of a static site is as easy as changing symlink to a directory. Atomic deploy model can be extended to advanced functionalities such as staging, instant rollbacks, phased rollouts, and A/B testing. Many conventional CDNs are unable to support some of these features due to restrictions and limitations around the instant cache purge. For example, some CDNs rate limit the cache invalidation, while others charge for each cache invalidation request.

What can you expect from WebriQ GLUE

We have been designing and developing websites and web apps for a long time, and we have seen all the deficiencies of project based pricing, per hour pricing, unknowns in devops, unknowns in maintenance, overruns, delays etc. We have developed a very opinionated way of implementing websites, ecommerce carts and webapps and we completely moved away from a monolithic, legacy and centralized approach. We believe in a decentralized approach whereby each software component is chosen for it’s best in class, but at the same time replaceable with a newer best in class if needed. Where we can not find a best in class critical functionality that is open sourced, we develop it ourselves, i.e. WebriQ Forms. We are strong supporters of the API economy and we strongly believe in microservices when it comes to functionality and automation. We aim at 100% serverless operation, and we know how to do that and we aim at 100% uptime, and we know how to do that. We are highly specialized, and opinionated when it comes to the technology stack used.

A couple of showcases of WebriQ GLUE

Count on Kindness Global and https://registry.countonkindness.global/ is a global combined website and small business registry. It is a website and a registry where all living beings will be noticed, will be heard and will belong. To be eligible to the Count on Kindness Registry, Just be kind. Be willing to open your doors to people of all cultures, ages, genders, skin colors, sexual preferences, and faiths, removing all fear of discrimination and separateness. The website and Registry are build on Strapi headless CMS and GatsbyJS as Javascript framework. Combined with Algolia Search it delivers a website that is behaving like a web application. No complicated deploys with databases and servers, just a bunch of files that can be deployed easily on dozens of services. The site loads superfast, scales to the Internet and is unhackable.

The Anzac Day Commemoration Committee is a non-profit organization in Australia. “ANZAC” was the name given to a combined force of First Australian Imperial Force and New Zealand Army troops who landed on Turkey’s Gallipoli Peninsula at around dawn on Sunday, the 25th day of April, 1915, barely nine months after the outbreak of World War I. On every 25th day of April for the past 100 years, “ANZAC Day” has been observed in Australia and New Zealand, becoming an honoured and sacred institution along the way. The site includes a host of information about the origins of ANZAC Day, the Spirit of ANZAC and gives an overview of the conflicts in which Australian Defence Force personnel have served in times of war and peace. The website and shopping cart are build on Strapi headless CMS and GatsbyJS as Javascript framework. It delivers a website that behaves like a web application. No complicated deploys with databases and servers, just a bunch of files that can be deployed easily on dozens of services. The site loads superfast, scales to the Internet and is unhackable.

Headless Content Management Systems on the Rise

Sun, 07 Oct 2018 16:00:00 GMT

The previous generation of enterprise CMS offered an often-generic content editing experience glued tot out-of-date development and deployment environments. The emerging strategy for content management selects best-of-breed solutions, tailored to specific use-cases like e-commerce or blogging; it provides a modern framework for rapid iteration and it generates lightning fast websites out of the box. Many Content Repositories Fail To Meet Today’s Digital Everywhere Requirements. When the world was just web and email, a web CMS could handle dynamic content delivery just fine. These systems, which date back to the 1990s from vendors like Adobe, Drupal, Wordpress amongst others grew by solving tough problems like unique designs, WYSIWYG authoring, workflow for approvals and translation, marketing support, and Internet-scale delivery.

The content you need on a mobile app, printed statement, or Facebook post may not use HTML. When you store content for a specific delivery use case, it’s hard to use it elsewhere. In addition, different business practitioners, partners, and customers create content outside core systems or processes, and the explosion of mobile and digital customer interactions stress these old content architectures to the breaking point.

Most of the current CMS systems are coupling authoring and delivery mechanism, that’s why they are called monolithic CMS systems. In a monolithic, desktop and web only environment that is (rather was) the optimal solution. In a mobile, Internet of things, ecommerce environment the coupling of templates and content becomes a burden, that grows heavier with the day. API’s are an afterthought to these systems, and even if these systems have build API’s on top of their legacy systems, they still reflect the tightly coupled approach. There is no easy or simple way to pull out content natively and dynamically at runtime and re purpose the content in other non-HTML environments. And the content sits in Search Query Language (SQL) databases as opposed to the more agile and flexible non-SQL (such as MongoDB or MariaDB).

A headless CMS instead uses modern storage (non-SQL most of the time) bandwidth, and computing power. It uses modern storage, stateless interfaces, and cloud infrastructure to efficiently deliver Internet-scale content experiences on any device. The different components of the Stack are loosely coupled (GLUED) together via API’s. The content is stored in pure format, ready for any purpose. Stateless API’s are quite robust and even more robust with GraphQL. GraphQL queries access not just the properties of one resource but also smoothly follow references between them. While typical REST APIs require loading from multiple URLs, GraphQL APIs get all the data your app needs in a single request. Apps using GraphQL can be quick even on slow mobile network connections. With a headless content management system, you gain flexibility in your delivery tier. For example, you can pull the content from a separate web delivery tier like a Git repository and deliver that content to a CDN. Each time your repository content changes, a rebuild of the site will occur through continuous deployment.

Three rapid innovations are occurring almost simultaneously

Monolithic CMS Systems are being replaced by modular, specialized content management systems
Modern UI frameworks, like React or Vue are becoming essential to rich user experiences, and these frameworks are used to drive websites, web applications and native apps. React native uses the same fundamental building blocks as regular iOS and Android Apps
Mobile is now over 50% of the Internet traffic, and high-performance and speed is becoming a must have.

Why Does It Matter?

By shifting responsibility for the user experience completely into the browser, the headless model provides a number of benefits:

Set front-end developers free from the conventions and structures of the back-end, and it gives front-end specialists full control over the user experience using their native tools.
Speed up the site by shifting display logic to the client-side and streamlining the back-end. An application focused on delivering content can be much more responsive than one assembles completely formatted responses based on complex rules.
Build true interactive experiences for users by using your website to power fully functional in-browser applications. The back-end becomes the system of record and “state machine”, but back-and-forth interaction happens real-time in the browser.

All these changes are forcing more and more companies in to adopting a more flexible technology stack, and leaving behind the monolithic CMS approach. Until a few years ago, adopting such technologies changes and putting those systems together was quite a lot of work. With services like WebriQ GLUE these technologies changes are within reach for smaller projects and are no longer the exclusive domain of companies with in-house engineering and development resources. The implementation of these new technologies will create fresh, novel and engaging web and digital experiences that are more accessible to end-user viewers and customers.

Jam Stack your monolithic CMS system in to the Closet

Tue, 18 Sep 2018 16:00:00 GMT

In an ideal world, each company should have a custom made website with dynamically generated content backed by a CMS. It would be light-weight, deployed once per update, band updates by a tool that just does the updates, not everything. It would be rendered statically through a Content Delivery Network (CDN) just as your video streaming from Netflix or Hulu. Having a Jam Stack website is fun and all, but how would a non-technical person edit content there? As always, there are multiple solutions available. A better approach would be to choose one of the many available CMS systems, that are suited to go with the Jam Stack.

API Driven CMS

The typical way to build a CMS-powered website is to choose a fully-integrated solution like WordPress and build your website as a collection of tightly embedded templates. Or if you want more control, you build your own integrated CMS using your preferred tech stack.

An API-based CMS, also known as a headless CMS, is a relatively new approach to content management with many advantages over the “old” way. API-based CMSs, such as Contentful, Directus, Strapi or Prismic, allow you to build websites and apps that are decoupled from their content management tools and integrated via API. This gives you the flexibility to build your front-end using your preferred tools (eg. Gatsby, Spike, React, Node, Angular) while being able to integrate a customized, robust CMS with ease. An API-based approach can save a team significant time and money in the initial implementation as well as ongoing maintenance.

In a nutshell, API-based CMS’s offer all the same editing capabilities of traditional CMS’s, but are significantly easier for developer to setup and maintain. This means your developers and content writers spend less time and money working on your CMS, and more time focusing on things important to your business.

Here’s a table comparison:

	Traditional CMS	API Based CMS
Setup	Website must be built on top of CMS, requiring you to learn and build your website based on CMS rules and processes	Add CMS functionality where needed with just a couple of lines of code
Hosting	Requires a database and specific server hosting	Requires no database and no-hosting
Complexity	Content, CMS code, and website code co-exist and intertwine to create complexity and interdependence	Content exists separately and is rendered within website codebase via simple API calls.
Flexibility	Website must be built in a specific programming language or framework.	Integrates with any codebase.
Maintenance	Security upgrades, database backups, etc.	None

The biggest advantage in my eyes while using API Driven CMS is to not have to care about a CMS at all. It should provide data, give your user the ability to edit their Website/App/Content easily in any way - and maybe (only maybe) provide some automation like image optimization, plugins or/and localization to make life easier and more efficient.

This API Driven approach is used by WebriQ GLUE. It’s a CMS that allows you to create an API for your website, without coding. It doesn’t require a static site generator to work. With this approach, we will have to send asynchronous requests to our API on each website visit, to always serve fresh content. WebriQ GLUE is gluing together the entire workflow of dynamic content updates, and rebuilding the site each time an update occurs — the site is statically rendered and served uniquely to each individual viewer through a content delivery network. Totally safe and secure.

Git-Based CMS

A GIT based CMS solves common version control and integration challenges of the JAM Stack by delivering a natural authoring experience on top of GIT for non-technical content writers. In a nutshell, GIT based CMS systems are typically open source content management system for your Git workflow that enables you to provide editors with a friendly UI and intuitive workflows. You can use it with any static site generator to create faster, more flexible web projects. Content is stored in your Git repository alongside your code for easier versioning, multi-channel publishing, and the option to handle content updates directly in Git.

The core advantages are;

Fast, web-based UI: With rich-text editing, real-time preview, and drag-and-drop media uploads. Platform agnostic: Works with most static site generators. Easy installation: Add two files to your site and hook up the backend by including those files in your build process or linking to a Content Delivery Network (CDN). Modern authentication: Using GitHub, and JSON web tokens. Flexible content types: Specify an unlimited number of content types with custom fields. Fully extensible: Create custom-styled previews, UI widgets, and editor plugins.

The GIT based concept is used by WebriQ goes Mad. This CMS work as a Graphical User Interface for GIT. You can write posts through an admin panel, and under the hood, after saving, the CMS will commit your post to the code repository, and trigger a re-deploy of your website. A Git based CMS is simpler to set-up, update and maintain and is the preferred solution for companies that have no or little in-house content management resources.

An outdated website can dramatically decrease conversions. Retro, cluttered designs distract visitors from the conversion point; lack of modern upgrades can make a client lose faith in your business. You may not need all latest trends mentioned. But what you must have is a super fast, secured, reliable and scalable website that is designed for Mobile Browsers First and that can work offline in poorly covered areas . The choice between hiring a web agencies or an individual developer comes down to budget $$$$. Again in an ideal world you would hire a web agencies for all design and marketing aspects and a talented individual developer that is up to date with the latest web development techniques. Beyond the cost will be the time you as a busy entrepreneur will have to spent on gluing the project together to a workable day-to-day solution.

A potential middle ground is WebriQ goes Mad, with its pioneering Web Design as a Service Concept (WDaaS). WDaaS provides a fundamental change in the service of web design. With WDaaS businesses can create stunning websites, landing pages, and sales funnels, without the labor and frustrations of Do-It-Yourselves tools nor the expense of a marketing agency. So you get the services of a web agency and a developer at the cost of the developer.

This Is WebriQ Goes Mad from Alex Belding on Vimeo.

Benefits of Jamstack for customer projects

Mon, 27 Aug 2018 16:00:00 GMT

Traditional CMS Systems

At WebriQ we have been building websites with traditional monolithic CMS systems for many many years. And we have been building CMS platforms based on a one system do-it-all for many years as well. But we also became aware that all these systems are just doing too much. They became cumbersome to build websites on, and they became cumbersome to update, maintain, support and secure. The initial user friendliness got lost, and they reason we got away with it for so long is because we got used to a vdo-it-all dashboard. Today things have changed, CMS’s come in variant types and numbers, i.e. flat-file CMS, headless CMS, Git based CMS just to name a few.

Jamstack and Static Sites are on the rise

Thanks to modern browsers, static site generators, CDNs, and APIs, we’re now seeing web developers transition from dynamic server-side applications to modular, client-side stacks. A significant shift in focus from the backend to the now powerful frontend.

Best practices for defining a JAMstack project:

Entire website /application sits on a Content Delivery network (CDN) and no longer on a single server Atomic deploys Instant cache invalidation All your data and code lives in repositories Automated builds

Jamstack versus traditional CMS workflow

Traditional workflow

→ Building and hosting are coupled.

→ A user requests a page. The file gets processed and served following a (long) series of interaction between a database, backend code, server, browser, and layers of caching.

→ Core updates are pushed to production servers, often through FTP. Database must be maintained or updated.

→ Content updates are pushed through traditional CMS, like WordPress or Drupal.

JAMstack workflow

→ Building and hosting are decoupled.

→ A user requests a page. The file is already compiled and gets directly served to the browser from a CDN.

→ Core updates are pushed through Git; the site gets re-built entirely via modern build tools like static site generators.

→ Content updates are pushed through Git or a static site CMS.

Of course, the latter brings in lots of benefits:

The delegation of server-side & database operations removes lots of points of failures & security exploits.

The static content served via CDN makes for extra speedy user experiences.

The lesser complexity of development reduces costs.

The reduction of bloat & maintenance + refreshing flexibility in work further reduces cost

Turning technical features into business benefits

Do a speed and security test on testmysite.io and bring up two very similar sites (or the same one)—one static, one dynamic.

→ Static site = faster site = better user experience & Google rankings = more traffic, more $

A Wordpress website is like a 6 story house of cards, more vulnerable to collapse because it has more parts, more complexity to its structure. A static site, on the other hand? Make it a 1 story house of cards. Super easy to build and maintain.

→ Static site = simpler site = more secure & reliable = less unpredicted expenses, peace of mind

Reduced operational and development costs means hard savings:

“By ditching the the big web server, the databases, the plugins, and the constant maintenance, we’ll save you X thousands of dollars a year.”

Refuting common objections

More tech-savvy clients may bring up some legitimate concerns. Here are the two objections most frequently seen in online threads.

1) A JAMstack set up is nice, but I need to handle dynamic features on my site.

Truth is the JAMstack sites being built today are more hyper-dynamic than static. So regarding that presumed lack of server-side features: with the current API economy and explosion in SaaS offers an interesting à la carte approach. In other words, you can cherry pick the dedicated external services you need and adopt a truly modular development stack. Whatever dynamic information clients need to handle, there’s probably something just for that:

Tools like Webtask and Serverless can handle multitudes of backend functions for you.

Tools like Snipcart, Foxycart, Selz, Gumroad and Shopify’s Buy Button can handle e-commerce.

Tools like FormKeep, Typeform, Formspree and WebriQ FORMS—on top of building, deploying, and hosting your project—can handle form submissions.

Tools like Algolia, Google Custom Search, Fuse.js, Lunr.js and List.js can handle search functionality.

And the list goes on and on.

2) Static CMS are cool and all, but I also need to manage user permissions & editor roles.

As we’ll see in the next section, this is a recurring pain point with many modern “static” CMS. But the fact is some advanced headless CMS like Strapi, Sanity, Contentful, Prismic and Directus already let you manage lots of roles & permissions.

WebriQ CMS is a a GIT based CMS for Static websites that can handle all updates and roles & permissions seamlessly.

WebriQ - JAM Stack GLUE

At WebriQ, we have been developing and deploying JAM Stack websites for over two years now. With a dedicated APP, we have been able to build, develop, update and manage hunderds of sites. In this model we are using a Static Site Generator to develop the site, a GIT based CMS system to update the content and a Github repository to store all HTML, CSS and Javascript files. GIT files are pushed to a CDN network. Whereas this model does fit well for most smaller projects, it has it’s shortfalls when it comes to larger projects or projects with a need for frequent content updates and updates made by a variety of users, content writers and third party contributions

Since the JAM Stack is more a concept then a real technology stack, we have been contemplating for a while how we could combine the best of the traditional LAMP Stack ideas and the serious advantages and benefits of the JAM Stack. It’s what I would call the GLUE of the JAM Stack.

What are we gluing together

A comprehensive Database (MongoDB) Service https://www.mongodb.com

A Javascript (Node.js) API Content Management Framework https://strapi.io

A State of the Art Static Site Generator https://www.gatsbyjs.org

An ultra-redundant global CDN https://www.netlify.com

GET EARLY BIRD ACCESS TO WEBRIQ JAM STACK for ENTERPRISES

Top reasons to move from LAMP Stack to JAM Stack for your next Web project

Wed, 08 Aug 2018 16:00:00 GMT

Stacking web technologies is a common phenomenon adopted by developers since years to gain prominence in website development. One of the earliest web stacks formed with well-known open source technologies is LAMP STACK. LAMP is the combination of four important technologies – one is an operating system called Linux, second is the Apache web server, third being MySQL, the popular database system and last but not the least, Perl ( PHP or Python) the programming language used for developing HTML web pages. Every website requires a framework, a programming language, libraries and so on for its development. When you get the right combination of all these technologies you can surely develop a good website that can offer better performance. LAMP stack is a good but a conventional approach for website development that is now getting replaced by more modern approaches like the JAM Stack.

The term JAM Stack was coined by Netlify co-founder Mathias Biilmann to refer to the solution stack of JavaScript, APIs, and markup. JAM stack focuses on the front end build, eschewing server-side functions as much as possible. The three elements are: JavaScript: JAM stack JS resides on the client-side, handling responses and requests. Because this approach involves a style of build over specific technologies, the “J” in JAM stack can take many forms: pure JavaScript, a library like Vue.js, or even front-end frameworks like React. APIs: Server-side processes and database commands are implemented vis API, which is accessed by JS-driven HTTP calls. JAM stack is API agnostic in that it simply does not care where yours comes from. You can use any of the bazillion pre-packaged APIs out there or custom-build your own. Markup: This is the part users actually see when they access your site or app. These days there are all kinds of open source build tools (Grunt, Webpack, Gulp) — not to mention static site generators (Gatsby, Spike, Hugo) aggregating them into convenient platforms — to make creating templated markup stupid easy. Once you’ve actually built that JAM stack-based opus, you, of course, want to place it at the very front edge of the internet event horizon. There are fantastic git-centric hosting services that allow continuous deployment — meaning that you can simply push your app, and any subsequent changes, to GitHub, and the service will automatically build the site from source and deploy it. This is essentially how GitHub Pages works. And, since JAM stack architecture also couples beautifully with high-availability, high-performance nature of content delivery network distribution, be sure to shop for a provider that gives good CDN.

JAM Stack is a Concept – Not a Library

So often, I speak to non-tech-savvy executives who ask me questions such as: “Will you use the JAMstack library?” Well, it isn’t a library, but a collection of tools tied together as a concept…

It’s important to know the difference because confusion about what it can or can’t do will influence the conversations you have with developers. Much like “Progressive Web Applications,” which was another set of guidelines but not a library, JAMstack isn’t any one set of code. Rather, it’s an approach to solving problems.

That is a big distinction versus, say, Node.js, which is a library. JAMstack can involve any number of different technologies or methodologies and still be within the realm of what the concept encompasses.

Tendency to move away from monolithic LAMP Stack CMS Systems

Drupal , WordPress and SquarSpace are traditionally “monolithic” CMSs, with presentation baked in via the theme. However, due to the need for more flexibility and freedom, many companies have begun decoupling the CMS, using it for content management, editorial, and administrative tools, while implementing a separate frontend component that communicates with the CMS via API. Decoupled CMS architecture (aka “headless”) is rising in popularity in the development world. This model allows breakthrough user experiences, gives developers great flexibility to innovate, and helps site owners future-proof their builds by allowing them to refresh the design without re-implementing the whole CMS. With all this upside, it’s no wonder this type of build has gained serious traction in the business community as of late.

WebriQ - JAM Stack GLUE

GET EARLY BIRD ACCESS TO WEBRIQ JAM STACK for ENTERPRISES

JAMstack is the solution for your rapidly aging CMS

Tue, 31 Jul 2018 16:00:00 GMT

A bit of history

When a user tries to access a web page, their browser makes a request to the server that hosts it. Either the server answers the page immediately, exactly as it is stored, or the server generates it by executing code on demand. Although the Web was conceived as an entanglement of static files, server-side programming languages appeared very early and are now widely used. More than 80% of servers that use server-side language are running PHP. And hosting providers offering servers without dynamic language support are almost non-existent. Yet, the dynamic generation of HTTP responses presents significant disadvantages in terms of web performance. A dynamic webpage is often built around a web server that loads an execution language that analyzes the HTTP request, often requests a database (sometimes located on another server in the datacenter) and third-party services, populates a logical model that reveals itself through an aggregate of templates to generate the HTML response. Quite logically so, response time is longer. A paradigm shift If you want to deliver your static pages, you must have compiled them up front. This fact, as trivial as it may seem, changes everything. Indeed, compilation turns out to be the main advantage of static: shift the complexity from the Production environment to the integration process. If your pages are served by a web server without being generated first, you have no need for a server-side language to be executed. As a consequence, many attack vectors disappear. You can’t steal confidential data by injecting malicious code if you have neither a database nor a server-side execution language. The static trend allows you to completely transform the way a site is published.

How does the Jamstack work

A static site generator (SSG) is a software executed locally or as a service that produces (and sometimes deploys) a static website using some data sources for model and configuration, and templates containing the business logic. The SSG market is booming. Most of them generate a website from a set of files, often written with a lightweight syntax. The responsibility for the conversion to HTML is assigned to both a templating engine and a converter, responsible for transforming the markup into HTML. They are mainly a playground for front-end developers who know how they tick.

It becomes really interesting when you follow the lead of external data sources because then, we can talk about CMS that would not be used to render HTML, but only to store and expose data. They are called Headless CMS.

A headless CMS liberates the development team from the burden of maintaining a database, instead they can focus on the platform’s technical evolution and the assets pipeline while the contribution team can sharpen its content.

Editors and content writers can work on files which are easy to store and modify. Their only common language with developers becomes the metadata passed in each file. Editors can use the editing tool or service of their choosing, even one that ensures collaboration. Editors also can benefit from source code versioning whenever they want to consult the history of their files, merge several versions or branch to write content they don’t want to publish right away.

In essence this means, that we are no longer in a system where the main metric of scalability is the number of simultaneous visitors, but in a system that can adapt to the frequency of generation and deployment requested by editors and content writers.

**A headless CMS, a Static Site Generator and a deployment facility and you are ready to GO. **

JAMStack is a real paradigm shift. The website being served to the visitor becomes, more than ever, a shell in which services, whether self-hosted or third parties, are dynamically injected. It is even possible to rely on several services for the same purpose and switch to a fallback if the main service is not available. And since you’re shifting a lot of the efforts to the Front End, why not go further and build your site with a Single Page App, or transform it into a complete Progressive Web App (PWA), designed to be “mobile and offline first”? This is not inherent to JAMStack, but heavily facilitated by the change of development paradigm.

Jamstack – opportunities and risks

The biggest risk is to get lost in the plethora of Headless CMS, generators and service platforms. Those risks are greatly diminished when using WebriQ GLUE, basically a set of top of the line Jamstack tools, glued together for you, supported and serviced throughout the lifetime of your website and web application. Once you have fully grasped the specific risks and put in place appropriate workflows, the JAMStack nonetheless presents a tremendous opportunity for aging CMS systems and aging workflows

Building a JAM STACK website with us REQUEST A QUOTE

more in depth details can be read on https://blog.dareboost.com/en/2018/02/static-website-web-performance/

Headless CMS and Content as a Service

Wed, 25 Jul 2018 16:00:00 GMT

A Content Management System (CMS) as we know was created back when users browsed the internet using desktop browsers. And with the growing popularity of the internet came a content explosion. The monolithic CMS, as this is quite often called, seemed for a long time like the best way to handle content. But as technology shifted away from desktop and page-centric browsing to become more mobile, the CMS started to suffer from technical debt. One way of trying to solve the problem, is adding an API to a monolithic CMS. This is a band-aid repair. The quick fix does nothing to repair the fundamental problem, which is the enormous underlying technical complexity of a CMS initially designed for a past area. Very often solving problems that are are no longer a problem when building content-rich websites and web applications.

What makes a CMS Headless

It is a kind of metaphor, whereby the presentation layer is the head and the content is the body. So if your CMS only handles the content, and not the presentation layer it is de facto headless. The CMS acts as a specialized database, with and interface that allows editors to create and nurture content, that can be used and re-used by all types of clients. It allows developers to build clients on basically any tool. The client connects to the CMS API, fetches the content it needs and the client takes care of the presentation layer.
Most pure play Headless CMS are ‘cloud native’. They are only available as cloud services, not as software. Most of them are proprietary and behind some sort of paywall. The different packages you can choose from are very technical, non-transparent and do change quite often. A lot of these services start out with good FREE tiers, but are closing down on these FREE tiers as soon as they get some traction. The content-as-a-service approach simplifies scaling, monitoring, backups etc - while sacrificing flexibility and control. The idea behind Headless CMS pretty much scales down to avoiding coding in the CMS, and use an API instead - this combinations gets you off the block pretty fast, at least from the perspective of producing and delivering raw content.

The Headless CMS battlefield

Contentful - Contentful is recognized as a pioneer in the Headless CMS industry. Contentful offers a matured REST API with a matching development kits for just about any language. Watch out for the pricing model as it can quickly become expensive for high traffic solutions.

Sanity - A newcomer to the cloud-native Headless Space. The UI (Content Studio) is open sourced, and with that piece of software that you can self-host, you have a have a collaborative editing environment in React. The data is stored in real-time in a Hosted back-end and can be queried through GROQ (Graph Oriented Query Language) and soon GraphQL.

Directus - Open source, API-driven content management system, that can be self-hosted or hosted by Directus.

and many more that are popping up every month, even week.

WebriQ - JAM Stack GLUE

What are we gluing together

A comprehensive Database (MongoDB) Service https://www.mongodb.com

A Javascript (Node.js) API Content Management Framework https://strapi.io

A State of the Art Static Site Generator https://www.gatsbyjs.org

An ultra-redundant global CDN https://www.netlify.com

GET EARLY BIRD ACCESS TO WEBRIQ GLUE

WTF is a Static Site Generator

Tue, 17 Jul 2018 16:00:00 GMT

The difference between a Wordpress website and a Static site is well described in one of David Walsh blog posts.

How does a Wordpress website work

Try to imagine for a second that the only way for people to know what’s happening in the world is to go to the nearby news kiosk and ask to read the latest news. The attendant has no way to know what the latest news is, so he passes the request on to a back room full of telephone operators. When an operator becomes available, they will take the request and phone a long list of news agencies, ask for the latest news and then write the results as bullet points on a piece of paper. The operator will then pass his rough notes on to a scribbler who will write the final copy to a nice sheet of paper, arrange them in a certain layout and add a few bits and pieces such as the kiosk branding and contact information. Finally, the attendant takes the finished paper and serves it to the happy customer. The entire process will then be repeated for every person that arrives at the kiosk. That is essentially how dynamic websites work. When a visitor gets to a website (the kiosk) expecting the latest content (the news), a server-side script (the operators) will query one or multiple databases (news agencies) to get the content, pass the results to a templating engine (the scribble) who will format and arrange everything properly and generate an HTML file (the finished newspaper) for the user to consume.

How static sites work

The proposition of a static site is to shift the heavy load from the moment visitors request the content to the moment content actually changes. Going back to our kiosk metaphor, think of a scenario where it’s the news agencies who call the kiosk whenever something newsworthy happens. The kiosk operators and scribbles will then compile, format and style the stories and produce a finished newspaper right away, even though nobody ordered one yet. They will print out a huge number of copies (infinite, actually) and pile them up by the store front. When customers arrive, there’s no need to wait for an operator to become available, place the phone call, pass the results to the scribble and wait for the final product. The newspaper is already there, waiting in a pile, so the customer can be served instantly. And that is how static site generators work. They take the content, typically stored in flat files rather than databases, apply it against layouts or templates and generate a structure of purely static HTML files that are ready to be delivered to the users. With an ever-growing ecosystem surrounding static site development, many of the main issues surrounding building static sites are finding answers through new tools. Content management and administrative tasks can be challenging for end users who don’t have a technical background. Good news is there’s an impressive number of CMSs out there ready to complete your Static site. The difference between those CMSs and traditional CMSs, like Wordpress, being that you’ll use the former only for “content management” tasks, not templating and frontend content generation, making it easier for content manager and editors to contribute to the content of the website or the web application. Building websites using Static Site generators is often referred to the term JAMstack, stands for JavaScript, APIs, and Markup, and it describes a way of building static, database-free websites. This concept is deceptively simple– the word ‘static’ implies simplicity, or a lack of interactivity, but this could not be further from the truth. When we talk about static websites, we’re referring to the technology used to build, power, and serve them.

Beyond simplicity the main advantages of the JAMstack are

SEO : First, simplifying your URLs and site architecture is often easier with JAMstack than it is with a dynamic website and full CMS. Rather than relying on complex server-side URL rewrites to make your content available at pretty URLs (example.com/?p=12345 → example.com/nice-and-tidy/), your URLs can be whatever you want them to be: they simply reflect the locations of your website’s files. The potential for unwanted duplication is also massively reduced. Many CMSs will automatically generate pages for categories, tags, and date-based archives which you may not even need. Typically, such pages are handled with no index directives or canonicalization using extra plugins. Static site generators instead allow you to fine-tune page creation and create whatever taxonomy suits your content. Should you require it, many generators include powerful logic and functions for creating filtered, paginated archives.
Speed - Closely related to SEO, but obviously critical for UX too, is speed. The speed advantages of static websites can be phenomenal. With HTML generated in advance and database queries eliminated, your content can be served instantly from a global CDN. An experiment by Mathias Biilmann for Smashing Magazine found that with a highly optimized dynamic website (including a robust caching implementation), the time to first byte was on average six times faster using a static version distributed via CDN. Back in 2010, Google said page speed was a ranking factor but it “was focused on desktop searches” only. Now, in July 2018, it will look at how fast your mobile pages are and use that as a ranking factor in mobile search. Google has been promising to look at mobile page speed for years now, and it is finally there.
Security – your website build with a Static Site Generator is an absolute fortress, plain and simple.
Deployment and workflow – A core principle of JAMstack development is that everything lives in a Git repository; everything from our static sites components, generator config files, CSS & JS, to our written content (saved as plain-text markdown documents). With your hosting/deployment service configured to continuously mirror the appropriate branch of your repository, making a change can be as simple as pushing a commit to GitHub. Your entire website – code and content – lives in one centralized location protected by robust version control, and can be setup for continuous deployment.
**An exploding user and development community **- Take ecommerce, for example. For smaller retailers – the kind who might typically rely on WordPress and WooCommerce – a static website is now a totally viable option. Snipcart is a JavaScript-based shopping cart and checkout system which allows developers to add ecommerce functionality to any website. Product inventory and sales are managed through the Snipcart dashboard, and its API allows integration with inventory management systems, shipping providers, and so on. Alternative solutions include Foxycart and the Shopify buy button.

For bloggers who would typically use a pre-built theme for their site, there are now hundreds of options. It’s worth mentioning that some technical know-how is still required to get up-and-running with one of these static generators. They’re certainly a long-way off becoming thriving theme marketplaces in their own right, but in a way that’s a good thing: bloated themes stuffed with unnecessary plugins and page builder tools are not a problem here!

The future of Static Site Generators

A common question that arises when a frontend tool, workflow or library becomes popular is, how long will it last? It’s tough to say how reliable these predictions are, but based on the track record of the web—static sites were around in the early days of the web and are still heavily used—static sites are likely a mainstay for the foreseeable future. A feature that we’ll likely see moving forward is interface improvement for non-technical users. Currently, static site generators are heavily geared towards developers; “for developers by developers”. Many of them utilize the command line and rely on markdown as input for content; without a user friendly GUI interface to manage content. Thankfully, we’ve already seen the Headless CMS movement emerge to address this with content creating and editing experiences that prioritize non-developers. Solutions like Contentful, Prismic and Forestry provide proprietary solutions while Netlify CMS, WebriQ CMS and Strapi are fully open soure. With these solutions, a content creator doesn’t need to be privy to the intricacies of the build and can focus on creating content. Another feature that will likely grow over the next few years is the integration of serverless functions in static site generators. You can easily enrich your JAMstack site with dynamic functionality by including third party services and APIs. By default, a static site—being static—doesn’t allow for this functionality. Relying on third party services to handle this functionality may add unnecessary load that will slow down the performance of your site and expose you to potential security exploits. A good alternative that has been slowly gaining momentum are serverless functions. Serverless architectures encourage business-logic driven development, without making premature optimizations. As an architecture that scales well and is still easy to maintain, serverless functions fit in with the paradigm of lightweight aesthetic of static sites. Though serverless functions are still in their infancy, you can start using serverless functions in your static sites today using Netlify Functions, which lets you deploy Lambda functions without an AWS account, and with function management handled directly within Netlify.

How can your company benefit from the JAMstack and this web development revolution?

In this rapid changing web development environment, it is hard to keep up with all the changes, especially when you do not have an internal team that can support your web and digital marketing efforts. It is important to have access to a pool of competencies and people that can design and develop your website or web application and give it the right look and feel that potential customers will be attracted by it. You need access to people that can help you create the needed visibility for your website and can produce the necessary content to enable viewers and customers to easily find you on the Internet. You need a team of forward thinking developers and designers that can make an impact on how your viewers and customers experience your website or web application.

GET EARLY BIRD ACCESS TO WEBRIQ JAM STACK GLUE

Building a JAM STACK website with us REQUEST A QUOTE

JAM STACK the Web Development Revolution

Wed, 11 Jul 2018 16:00:00 GMT

Progressions in web development comes in various forms, from the physical developments in hardware to fresh ideas, which have opened up many new opportunities and the web technologies which enable these powerful digital experiences. Moore’s Law suggests exponential growth will continue in the technology sector, increasing speed and performance, whilst driving down cost. JavaScript is the fastest moving sector online right now. Developers have created at least six major JS frameworks over the last four years and users have started experiencing upgraded browsing experiences for many of the applications they use due to the fast adoption rate of these frameworks. Also, thanks to the innovation speed in browser technology, the user’s software gets automatically upgraded all the time to provide better experiences. Much like in the physical world, history has helped us become smarter, more efficient and more user-friendly with design and development. This should also be mirrored online, to ensure the experience of using the web continues to improve over time and evolves as our needs do. Our expectations of technology are now higher than ever, pushing the developers behind the devices and the platforms we use today to create experiences which are seamless, interconnected, secure and without boundaries. We must avoid legacy technologies and adopt and embrace the future technologies, which will power our world.

That leads us to today, where there is a revolution happening with web technologies. It all starts with JavaScript, the language that has been around since 1995 and is considered the glue in any web build. In the early days, everything had to be rendered server-side, simply because the browsers and devices were not powerful enough, especially on mobile phones. An important factor is SEO: Search engine traffic continues to dominate the game of Digital Marketing; if played right it’s the most affordable way to acquire inbound traffic. With traditional server-rendered pages, the process for setup and optimization was standardized for many years. When Javascript and other technologies arrived, search engines couldn’t see the content as the content was rendered locally. The search bots relied on fully loaded HTML to see the page content to generate data, which informed the ranking. From 2015, things changed when the devices and browsers used by the majority of Internet users were powerful enough to render a page completely client-side, without the need for a server. This was done with some HTML and JS files, plus data delivered through APIs to the web application. At the same time, Google announced they could now crawl and render JavaScript and CSS files, which was not achievable before. Javascript (and JS Frameworks such as React) is all about creating rich websites and applications, which are anything, the client sees in their browser. Traditionally, any changes to a web page would mean a reload was required. Now, Javascript removes this barrier and enables real-time loading of UI changes. With any change, however large or small, the user makes in the browser, the UI is updated instantly, even if the same information is reflected multiple times on the same page. It’s super fast since logic is rendered locally in the user’s browser, minimizing the amount of data being transferred from the web server. This is also often combined with CDN (content delivery network) technology, to bring the JavaScript files and associated media content as fast as possible to the client using the latest advanced technologies such as compression, minification, and chunking.

Last but not least, moving from server-side to client-side, especially combined with serverless computing, is way more secure than traditional server-based approaches because simply there is no server and therefore no attack vector. You don‘t need to patch anything because the code runs in the browser and not on your machines. This way of building websites and web apps is increasingly referred to as JAMstack applications: we’re not talking about specific operating systems and web servers anymore, but rather about creating a new development architecture, a new way of building websites and apps that delivers better performance, higher security, lower cost of scaling, and a better user experience.

The barrier between native mobile apps, native desktop apps and web pages is blurring. Clients are becoming faster and more robust, leading to dynamic front-ends, interactive content, and sleek desktop-like user experiences. JavaScript is also the perfect language for the cloud (otherwise known as serverless computing), as it’s built for compartmentalizing software, which has no connection to other software on the same machine. You can easily run multiple JavaScript applications on the same machine, without interfering with each other. As this sandboxing is also very important in browsers, in order that one loaded page does not interfere with another, JavaScript engines are highly secure and built for the Cloud - on the browser as well as in serverless computing. But, in the end, nobody wants a server. That‘s just the necessary tool to run the important thing: your application. In the end, everybody wants an application, not a server.

With these advancements in technology, how has the web experience for the end user been impacted?

Websites and web applications now have teams behind them, often large teams comprised of: designers, developers, UI/UX specialists, ecommerce specialists, SEO/SEM specialists, project managers, content producers and more. A whole industry has been created, called ‘User Experience’ or UX. It’s an industry dedicated to creating user-friendly design and experiences. With the advancement of mobile technology and the infrastructure to keep us connected, we now have access to data faster than ever before. This has changed and continues to change the way we do just about everything. It’s changed not only our behavior but also our expectations. These expectations are now very high - we expect our web experience to be super fast, dynamic and highly interactive.

How can your company benefit from this web development revolution?

GET EARLY BIRD ACCESS TO WEBRIQ JAM STACK GLUE

Or if you are interested in building a JAM STACK website with us REQUEST A QUOTE

WebriQ Technology Stack - The Glue of the JAM Stack

Wed, 20 Jun 2018 16:00:00 GMT

Things to Remember

JAM Stack is a Concept – Not a Library

One Size Doesn’t Fit All

JAMstack may sound amazing, and in many ways, it is a groundbreaking new way of looking at web development, content delivery, and web hosting, but it doesn’t fit for all scenarios.

As I mentioned above, the best way to know for sure is to undergo a thoughtful, comprehensive discovery process to get a sense of how your website or application should be built. It could be that your site would benefit from the current norm, such as a monolithic system. Or perhaps JAMstack is, in fact, right up your alley.

Technology choices should always be made based on business requirements, not what’s hot at the moment. Developers are way too often skewed toward always recommending the hottest and trendiest platforms and methods. Always offset those opinions with your own due diligence and the advice of an expert practitioner who is not married to any one approach.

Tendency to move away from monolithic CMS Systems

Digital Trends in Business

We now live in a multichannel world

We need a new way of managing content in this multichannel world

We’ve been using traditional web-oriented CMS systems for years. But the new multichannel era requires a different approach to managing content. In the new multichannel world, your content may be consumed on any number of devices. If you do not want to miss the opportunity of truly engaging with your customers, you need to make sure your content is ready for multiple channels. This requires a whole new mindset in structuring, organizing, managing, and presenting content.

Microservices

Microservices represent one of the major shifts in software architecture. Today’s systems are increasingly built as a combination of both internal and external services connected via their API. In the past, companies used to build websites on top of monolithic CMS platforms which meant they were locked in with a single vendor. When they decided to change their CMS, they had to throw away their investment and start pretty much from scratch. The new generation of CMS systems are built as “headless” or “API-first”, which means they can be easily integrated into any application, no matter what technology it uses.

WebriQ - JAM Stack GLUE

What are we gluing together

A comprehensive Database (MongoDB) Service https://www.mongodb.com

A Javascript (Node.js) API Content Management Framework https://strapi.io

A State of the Art Static Site Generator https://www.gatsbyjs.org

An ultra-redundant global CDN https://www.netlify.com

GET EARLY BIRD ACCESS TO WEBRIQ JAM STACK for ENTERPRISES

WTF is the JAM Stack

Thu, 14 Jun 2018 16:00:00 GMT

What JAM Stack Is

The term itself was coined by Netlify co-founder Mathias Biilmann to refer to the solution stack of JavaScript, APIs, and markup.

JAMStack—Modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup.

JavaScript—Any dynamic programming is handled by client-side JavaScript. This could be any frontend framework, library, or even vanilla JavaScript (e.g. React, Vue, Angular, etc.).

Reusable APIs—Any complex business logic such as user databases and content management are processed server-side and served as APIs to the frontend.

Markup—The HTML markup is prebuilt at deploy.

In short, JAMStack is a web development architecture that’s about developing websites using tools that are loosely coupled . The objective is to decouple the user interface from the Content Management System (CMS).

In most popular CMSes, (e.g. WordPress, Drupal, Django CMS) the CMS is responsible for both managing content and displaying the user interface, usually through the use of templates specifically designed for that CMS.

In the JAMStack architecture, the responsibilities of managing content and displaying it are separated.

What JAM Stack Can Do for You

If you’re sure that your needs extend beyond simple requirements, or if you’re frustrated with conventional CMSes, here’s a breakdown on why JAM Stack is worth a shot.

FASTER DEVELOPMENT

With most traditional CMSes, only the seasoned veterans are on the ball. Everyone else may struggle to implement specialised business logic on CMSes, especially when the CMS was designed for other purposes (I’ve seen a case where a logistics system was built on top of a blogging CMS—nothing short of a miracle).

Even though learning a new architecture, migrating your codebase, and training the team may incur a high cost in both time and money, the benefits outweigh the costs.

Using front-end frameworks like React can greatly increased productivity. Component-based approaches and more organised state management within websites have enabled better and faster responses to business changes.

HIGHER FLEXIBILITY

With JAMStack, you can replace tools in your architecture with ones that are more suited for the task, or in response to business growth and new goals.

This may not make a lot of difference if you are building a single landing page or a simple blog. But if you’re going to build a website with plenty of features, dynamic content, and interactive components, you’ll want to ensure that you’re not limited to the tools or architecture that’s provided by your content management system.

Besides, most modern JavaScript plugins are agnostic to the platform that you are using. Tools like Customer Relationship Management systems, Email Newsletters, can all easily integrate with the architecture, either directly or through a service like Zapier.

BETTER PERFORMANCE

You can deploy your whole website onto a Content Delivery Network. Services like Netlify allow you to do this with very minimal effort. This means content can be downloaded quickly from nearby servers as opposed to a single server that could be distant from the user’s location.

SMOOTHER USER EXPERIENCE

When using modern JavaScript frameworks to build websites, smooth animations can be added so that content transitions are seamless. These subtle improvements in page load speed can enhance the user’s experience of your brand touchpoint. Even though one cannot control user behaviour, these advantages can influence users’ perception of your brand.

TIGHTER SECURITY

As the user interface is separate from your CMS, it is significantly harder to hack JAMStack websites. If you’re using a 3rd party CMS service to manage your content, the hacker would effectively be required to hack the service provider—which has better detection and prevention measures compared to most self-hosted websites.

WebriQ and the JAM STACK

Future-proof your website – the web is mobile, and every website is a web app and every web app is a website. Use a universal framework to build your future proof website and web app.
Modern web tech without the headache – Enjoy the power of the latest open-source web technologies – MongoDB, Javascript Content Framework, React.js, Webpack and CSS all glued together with API’s
We build with the data that you want and need – through an embedded admin panel which has been built to be completely customizable to your data needs.
Static Progressive Web APPS – We only load the critical code and data so your site loads as fast as possible. Once loaded, we prefetch resources for other pages so clicking around sites feels incredibly fast.
Speed past the competition – we build the fastest possible websites. Instead of waiting to generate pages when requested, pre-build pages and lift them into a global cloud — ready to be delivered instantly to your users wherever they are.
Scale to the entire internet - Forget complicated deploys with databases and servers and their expensive, time-consuming setup costs, maintenance, and scaling fears. We build your sites as “static” files which can be deployed easily on a Content Delivery Network.

Our Building Blocks

A comprehensive Database (MongoDB) Service https://www.mongodb.com

A Javascript (Node.js) API Content Management Framework https://strapi.io

A State of the Art Static Site Generator https://www.gatsbyjs.org

Deploy to an ultra-redundant global CDN https://www.netlify.com

GET EARLY BIRD ACCESS TO WEBRIQ GLUE

Building a Serverless CMS Powered by Vue.js

Fri, 09 Mar 2018 04:50:53 GMT

Vue.js is a progressive framework for building user interfaces, is gaining in popularity among developers. But why yet another JavaScript framework? Vue has learned from the experiences of Angular and React and many see it as simpler to implement and understand.

Vue.js is lightweight and easily adoptable. It’s reactive and component-based, allowing you to create pluggable components you can add to any project. Most importantly for this tutorial, Vue and its hallmark incremental adoptability allows you to try Vue without putting your existing code base at risk.

Vue works well with serverless application architectures. Serverless architectures are becoming the preferred architecture for many developers because it allows them to create and fine-tune products efficiently without having to bear the burdens (server maintenance, outages, and scaling bottlenecks) of traditional server-based architecture. Sarah Drasner recently wrote an entire series on how to create a serverless checkout flow powered by Vue and is a good example of this in practice.

In this tutorial, you’ll learn how to build a marketing website as a serverless Vue.js application using ButterCMS. ButterCMS is a headless CMS and blogging platform that lets you build CMS-powered apps using any programming language, including Vue. There are other options for going with a headless CMS, but I happen to develop for ButterCMS and know it extremely well so that’s what we’ll be using in our examples.

This tutorial will show you how to add performant content APIs to your Vue.js application. These APIs are easy to navigate even for the non-technical members of your team, enabling you to enjoy agile content management without having to spin up and maintain your own CMS infrastructure.

Specifically, we’ll examine code samples for three content types we might find on a marketing website: customer case studies, frequently asked questions, and blog posts.

Note that the designs in the screenshots we use throughout this post will likely differ from what you build and are styled with light CSS for demonstration. Your real design would use the global styling from your app making the pages look consistent with the rest of your site.

Getting Started

We’re using ButterCMS as our content management system, so let’s install it:

npm install buttercms --saveOnce installed, you can proceed with the following examples.

Example 1: Customer Case Studies

Let’s start by making it possible for any non-technical person on your team to add customer case studies to the site. In this case, we’ll create a page that can hold all of the published case studies that promote the product or service we’re selling which, when clicked, open up the page for that case study.

Step 1: Setup Customer Case Study Page Type

Using the dashboard on ButterCMS, you can create a “page type” entitled “Customer Case Study” and define the content fields. Once you’ve done this, you can create your first page. Specify the name and URL of the page using the ButterCMS dashboard and complete the populate the content fields we just defined.

Once this is all done, the ButterCMS API will return your defined page in JSON format. It should look something like this:

{ “data”: { “slug”: “acme-co”, “fields”: { “facebookopengraphtitle”: “Acme Co loves ButterCMS”, “seotitle”: “Acme Co Customer Case Study”, “headline”: “Acme Co saved 200% on Anvil costs with ButterCMS”, “testimonial”: “We’ve been able to make anvils faster than ever before! - Chief Anvil Maker\r\n”, “customer_logo”: ”https://cdn.buttercms.com/c8oSTGcwQDC5I58km5WV”, } } }

```#### Step 2: Integrating Your App

Next, open your code editor and create a file called `buttercms.js` in your `/src` directory.

If you don’t have an existing project, create one by entering the following:

vue init webpack buttercms-project
cd buttercms-project
npm i
npm i -S buttercms
npm run dev

`Then, in src/buttercms.js:

import Butter from ‘buttercms’; const butter = Butter(‘yourapitoken’);

```Now, update the routes in your app. This is done in `router/index.js`:

import Vue from 'vue'
import Router from 'vue-router'
import CustomersHome from '@/components/CustomersHome'
import CustomerPage from '@/components/CustomerPage'
    
Vue.use(Router)

export default new Router({
  mode: 'history',
  routes: [
    {
      path: '/customers/',
      name: 'customers-home',
      component: CustomersHome
    },
    {
      path: '/customers/:slug',
      name: 'customer-page',
      component: CustomerPage
    }
  ]
})

You have content in a data file, which is great, but now you need a page that uses the content. You're going to define a `getpages()` method that fetches all of the case study pages so you can render them together on a single landing page to create an index of them all. This will be a "homepage" for all of the published case studies.

In `components/CustomersHome.vue` you add:

  // import ButterCMS from 
  import { butter } from '@/buttercms'
  export default {
    name: 'customers-home',
    data() {
      return {
        page_title: 'Customers',
        // Create array to hold the pages from ButterCMS API
        pages: []
      }
    },
    methods: {
      // Get List of Customer Pages
      getPages() {
        butter.page.list('customer_case_study')
          .then((res) => {
            // console.log(res.data.data) // Check the results in the console
            this.pages = res.data.data
          })
      }
    },
    created() {
      // Fire on page creation
      this.getPages()
    }
  }

  
    {{ page_title }}
    
      
        
          
          {{ page.fields.headline }}

Now, you're going to set up the page we get when clicking on a case study from the homepage. To do so, in `components/CustomerPage.vue` we define a `getPage()` method to get a particular customer page based on its slug:

  import { butter } from '@/buttercms'
  export default {
    name: 'customer-page',
    data() {
      return {
        slug: this.$route.params.slug,
        page: {
          slug: '',
          fields: {}
        }
      }
    },
    methods: {
      getPage() {
        butter.page.retrieve('customer_case_study', this.slug)
          .then((res) => {
            console.log(res.data.data)
            this.page = res.data.data
          }).catch((res) => {
            console.log(res)
          })
      }
    },
    created() {
      this.getPage()
    }
  }

  
    
      
    
    {{ page.fields.headline }}
    Testimonials

Success! Now you can go directly to a page that lists all published case studies and click on any of them to be taken to the detail page for a specific case study post.

### Example 2: Frequently Asked Questions

Now lets's walk through how to create a Frequently Asked Questions (FAQ) page for the app. We’ll be using ButterCMS "Content Fields” for this. Content fields are simply global pieces of content that can be managed by your team. This content can span multiple pages and each content field has a unique ID for querying, as you’ll see below.

#### Step 1: Setup Content Fields

First, you’ll need to set up some custom content fields. Using the dashboard, you can set up a workspace to organize content fields. Workspaces will allow content editors to curate content without affecting development or the API.

Once you're in a workspace, click the button to create a new content field. Choose the "Object" type and use "FAQ Headline" as the name of the field. It will have an API slug of `faq_headline`.

After saving, add another field but this time choose the "Collection" type and use "FAQ Items" as the name of the field. This one will have an `faq_items` API slug. On the next screen, set up two properties for items in the collection and go back to your workspace to update your heading and add some FAQ posts.

#### Step 2: Integrating Your App

Now that you’ve created dynamic content using content fields, it’s time to display it in the app. To do this, you’ll fetch the fields with an API call and reference them in your view. First, set up a route to your FAQ page:

Let's add FAQ routes in `router/index.js`:

import Vue from 'vue'
import Router from 'vue-router'

import FAQ from '@/components/FAQ'

Vue.use(Router)

export default new Router({
  mode: 'history',
  routes: [
    {
      path: '/faq',
      name: 'faq',
      component: FAQ
    }
  ]
})

`Then create components/FAQ.vue with a call to get the FAQ content from the API:

import { butter } from ’@/buttercms’ export default { name: ‘faq’, data() { return { pagetitle: ‘FAQ’, faqitems: [] } }, methods: { getFaqs() { butter.content.retrieve([‘faqheadline’, ‘faqitems’]) .then((res) => { console.log(res.data.data) this.pagetitle = res.data.data.faqheadline this.faqitems = res.data.data.faqitems }) } }, created() { this.getFaqs() } }

```Notice that we predefined `page_title` as `FAQ` and then updated it with the API call to the FAQ content fields.

Define the ``:

  
    {{ page_title }}
    
      {{ faq.question }}
      {{ faq.answer }}

Now anyone on your team can update the values from the ButterCMS dashboard and the corresponding content in your app will automatically update.

### Example 3: Blog Posts

Last, we’ll tackle a blog engine for the app.

#### Step 1: Displaying Posts

We’ll start out by creating a blog route using `vue-router`. To display posts we create a simple `/blog` route in our app and fetch blog posts, as well as a `/blog/:slug` route to handle individual posts.

In `router/index.js`:

import Vue from 'vue'
import Router from 'vue-router'
import BlogHome from '@/components/BlogHome'
import BlogPost from '@/components/BlogPost'

Vue.use(Router)

export default new Router({
  mode: 'history',
  routes: [
    {
      path: '/blog/',
      name: 'blog-home',
      component: BlogHome
    },
    {
      path: '/blog/:slug',
      name: 'blog-post',
      component: BlogPost
    }
  ]
})

To create your blog homepage that displays the most recently published posts, you’ll create a Vue component for the blog home in a new `components/BlogHome.vue` file:

  import { butter } from '@/buttercms'
  export default {
    name: 'blog-home',
    data() {
      return {
        page_title: 'Blog',
        posts: []
      }
    },
    methods: {
      getPosts() {
        butter.post.list({
          page: 1,
          page_size: 10
        }).then((res) => {
          // console.log(res.data)
          this.posts = res.data.data
        })
      }
    },
    created() {
      this.getPosts()
    }
  }

  
      {{ page_title }}
      
      
        
          
            
              
              
              
              
            
            {{ post.title }}
            {{ post.summary }}

#### Step 3: Creating a Blog Post

Next, create a new `components/BlogPost.vue` file which will be your view for a single post:

  import { butter } from '@/buttercms'
  export default {
    name: 'blog-post',
    data() {
      return {
        post: {}
      }
    },
    methods: {
      getPost() {
        butter.post.retrieve(this.$route.params.slug)
          .then((res) => {
            // console.log(res.data)
            this.post = res.data
          }).catch((res) => {
            console.log(res)
          })
      }
    },
    created() {
      this.getPost()
    }
  }

  
    {{ post.data.title }}
    {{ post.data.author.first_name }} {{ post.data.author.last_name }}
    

    
      {{ post.meta.previous_post.title }}
    
    
      {{ post.meta.next_post.title }}

#### Step 4: Handling Blog Post Routes

At this point, your app is pulling all blog posts, allowing you to navigate to individual posts. But, you will notice the next/previous buttons in the browser aren’t working. Why? When using routes with `params`, the same component instance will be reused when the user navigates from `/blog/foo` to `/blog/bar`.

Since both routes render the same component, this is more efficient than destroying the old instance and creating a new one. But, this also means that the lifecycle hooks of the component will not be called.

There is a fix for this. We need to watch the `$route` object and call `getPost()` when the route changes. To do this, update the script section in `components/BlogPost.vue`:

  import { butter } from '@/buttercms'
  export default {
    name: 'blog-post',
    data() {
      return {
        post: {}
      }
    },
    methods: {
      getPost() {
        butter.post.retrieve(this.$route.params.slug)
          .then((res) => {
            // console.log(res.data)
            this.post = res.data
          }).catch((res) => {
            console.log(res)
          })
      }
    },
    watch: {
      $route(to, from) {
        this.getPost()
      }
    },
    created() {
      this.getPost()
    }
  }

You can also use APIs to filter and feature content on your blog with categories, tags, and authors. In fact, there’s a lot you can do with an API in terms of managing different aspects of your blog, including RSS, Atom feeds, sitemap markup, and content styling with CSS.

### API or GIT Based Approach

A Git-based approach to managing content

The premise is that you can leverage modern frontend tooling to create lighter, faster, more secure sites. And FYI, this isn't fringe developer extravaganza. Entire organizations like Smashing Magazine, Sequoia Capital & Mailchimp have migrated to frontend tooling. 
One of the first implications here is decoupling the building & hosting of your site. You can "pre-bake" and pre-build assets and then serve them on Content Delivery Networks. This effectively frees your content from the database/templates imperatives of traditional CMS, like Wordpress and Drupal.
However, the content itself still needs to live somewhere. That's where GIT comes in.
To create your site, you can use a static site generator like Spike, the one implemented as standard by WebriQ or a JS framework like Ember, Angular, React, or Vue. It doesn't matter. The point is you store the site's content in a GitHub repository, where most of your pages can be simple Markdown files. Then, you deploy & host that static content on a content delivery delivery network of your choice. 
WebriQ CMS is a Git-based, open source Ember CMS. 
The CMS is part of an [APP](https://app.webriq.com) to build, manage, update and host sites build with unique front end tools. With WebriQ CMS your content lives in Github and the CMS leverages Github's API to interact directly with your content repository. The WebriQ API allows the CMS to interact directly with the Github repository. It loops editors directly in to Github workflow. 
You can see our Git based CMS in action on [WEBRIQ CMS DEMO](https://app.webriq.com/help/page/demo/howto)

Serverless technology is bringing CMS out of the past

Tue, 20 Feb 2018 07:43:48 GMT

The world is shifting to the cloud, but web content management systems (CMS) are still stuck in the past. Even the easy WYSIWG editors are limited in features. Developers are forced to constantly fill out form fields, preview their work, and regularly patch CMS installations.

In an age where organizations are trying to innovate to be the best, “they’re facing a watershed moment in web development,” according to CMS provider Scrivito.

Thomas Witt, founder and CEO of Scrivito, explained ReactJS, which is developed by Facebook, was the first JavaScript framework that really worked well with what they needed it to do with their CMS solution. He said that since it is very component-based, developers can go in and build their own components and reuse them between projects, making it useful for digital agencies. That combined with the serverless approach of ReactJS makes it a very powerful framework.

By taking a serverless approach, ReactJS can be loaded onto a content delivery network and be rendered in the browser. Developers are able to access any backend server they want to with this serverless approach.

This is a big advantage in development because everything takes place in the browser, the company explained. Gone are the days of having to constantly preview what your code looks like. With a serverless approach, developers are able to see those changes instantly. This means that the “turnaround times for developers are much, much faster than they used to be before,” said Witt.

“We think that ultimately everything is changing and we’re on the cusp of a new way of doing things and we want to take advantage of this technology and really push it to the limit and really try to make a product that speaks to everybody and does something for everybody, but really excels at security, scalability, and flexibility for editors, developers, and so forth,” said Douglas Patten, head of marketing at Scrivito. “We think that this combination of pretty much just working in React really is accepting into that and really pushing the boundaries of what’s possible right now. Things are going to change and we want to stay ahead of it.”

In terms of web app and web frontend development, Witt believes JavaScript “is simply the ultimate language and we think React is — at least at the moment — the ultimate framework.”

To address all of this, Scrivito announced today the first serverless JavaScript-based CMS. Scrivito is built on ReactJS and will improve the experience of building websites for web editors and developers.

“We’re at a tipping point. Agencies and dev teams that stick with WordPress and the like are doomed to be overtaken by the inevitable shift to serverless computing and JavaScript development,” said Witt. “We built Scrivito to help agencies and companies meet the needs of today’s dynamic website requirements across any device or platform. And this is just the beginning.”

WebriQ CMS — A Git-based approach to managing content

The premise is that you can leverage modern frontend tooling to create lighter, faster, more secure sites. And FYI, this isn’t fringe developer extravaganza. Entire organizations like Smashing Magazine, Sequoia Capital & Mailchimp have migrated to frontend tooling. One of the first implications here is decoupling the building & hosting of your site. You can “pre-bake” and pre-build assets and then serve them on Content Delivery Networks. This effectively frees your content from the database/templates imperatives of traditional CMS, like Wordpress and Drupal. However, the content itself still needs to live somewhere. That’s where Github comes in. To create your site, you can use a static site generator like Spike, the one implemented as standard by WebriQ or a Javascript frameworks like Ember, Angular, React, or Vue. It doesn’t matter. The point is you store the site’s content in a GitHub repository, where most of your pages can be simple Markdown files. Then, you deploy & host that static content on a content delivery delivery network of your choice. WebriQ CMS is a Git-based, open source Ember CMS. The CMS is part of an APP to build, manage, update and host sites build with unique front end tools. With WebriQ CMS your content lives in Github and the CMS leverages Github’s API to interact directly with your content repository. The WebriQ API allows the CMS to interact directly with the Github repository. It loops editors directly in to Github workflow. You can see our Git based CMS in action on WEBRIQ CMS DEMO

Why modern marketers and digital producers are going headless

Thu, 01 Feb 2018 01:30:51 GMT

Why modern marketers and digital producers are going headless

Every once in a while, a technology comes out that radically changes what developers can build for my fellow marketers. We hear about it at a periphery. Until we see the cool case studies though, it doesn’t mean anything to us. It’s just code and repos, which basically translates to “stuff that doesn’t help me meet my KPIs.”

I’m going to highlight a technology that allows marketers and web producers to be more creative and reach more people, IF we’re willing to part with our traditional tools and ways of thinking.

It’s time to lose your head.

Figuratively speaking, of course. It’s time to use headless content management technologies. This approach allows content creators and front end developers to use their own independent languages, tools, and workflows, rather than relying on a standard CMS or eCommerce platform. Content is simply delivered in a machine readable format called JSON. Designers and developers then gain a lot more freedom to use content wherever and whenever it makes sense.

That sounds like boring gibberish. Why should I care about this?

Because traditional CMSes or eCommerce solutions allow you to rock this:

Wowee. Not bad, but…You could be rocking this:

This is an actual Augmented Reality app from the British Museum. They use Contentful to do this. See the case study. By going headless, you can instantly ship and edit content into any app your developers can build. Content can be served at a specific location, and across multiple devices at the same time.

A headless CMS assumes nothing about the destination of your content, which is why it is much smarter for the modern web. Developers can integrate content across multiple applications at the same time. Developers can use your content in any way, at a much bigger scale, and in any device. A/B or multivariate test. Personalize content for users using advanced AI. Customize digital displays. Heck, pull content from another API, structure it, and ship it on your digital properties. If developers can build it, you’ll have a centralized dashboard to ship content to it.

Edit content that is then served on a static page. Edit voice interfaces. Edit a digital display on a flying drone that is carrying tacos. Whatevs.I don’t think that we as marketers recognize the capabilities that are already out there. We haven’t even built many digital teams who can accommodate this shift. Yet.

Yep. You wouldn’t force your homebuilder to use a single material for your house. Why are we forcing developers to use PHP or Java for our projects? Why must they stick with MySQL when they can launch databases that handle many more concurrent reads and writes, even in a graph? Just like the materials that build skyscrapers and homes, different programming languages, databases, and developer tools excel at different tasks.

This is how many developers see your CMS’s technology. Courtesy of Coding Horror

A decoupled approach makes more sense

Developers aren’t building these experiences very often because marketers are not asking for them. We’re sticking to our traditional way of doing our jobs. Most traffic is mobile, and there are more connected devices than human beings. What’s holding us up? Why can’t we customize that kind of content too?

So what’s the state of headless solutions?

The technology is there. It’s up to us to start using it.

Currently you can use WordPress’s new lightweight version, dubbed “Calypso,” on WordPress.com. Any developer can use their API though. Here’s a blog post that explains how to go headless with WordPress using React.

There are a variety of other Headless CMSes, including Kentico, GraphCMS (built on top of the popular GraphQL project), Contentstack, Canner, Prismic, and others.

Contentful offers “content infrastructure.” Their API goes beyond the traditional page-centric approach to content, hence, they do not consider themselves a CMS. Contentful may seem complex at first, but it is excellent for using content across various channels.

By leveraging Heroku, a frontend developers can easily deploy and scale stacks in all sorts of languages.

WebriQ is offering you a GIT Based CMS system with a Complete User Interface

WebriQ CMS is bridging the GAP between Static Site Generators and Flat File CMS Systems. The days when a brand only needed one website to house its online presence are long gone. Today, webinars, events, pop-up shops and product promotions all require their own microsites or landing pages. When we moved into what some call the post-CMS landscape, the usage of static site generators and Flat-file CMS and Static Site Generator functionality overlaps in many ways ; so how do you choose between the two?

When we moved into what some call the post-CMS landscape, the usage of static site generators (SSGs) and flat-file CMS for these microsites (and at times for lightweight corporate sites), grew. And now, with the headless CMS hype in full flow, the interest in these front-end solutions is returning.

After listing the best flat-file CMS and the best static site generators on offer — it’s time to formally identify what separates these two similar technologies.

The rise of the headless CMS approach and the benefits it provides for users, developers and operations mean it’s only going to become the default way to implement true multichannel, multibrand applications going forward.

It’s time for content creators and developers to get out of each other’s way. Now we can.

The web has fundamentally changed since the CMS first came out. Just as we moved from building websites in Dreamweaver to the CMS, it’s time that we move past traditional CMS thinking. The web will ultimately be a lot more interesting.

Do not try and bend the CMS. That’s impossible. Instead only try to realize the truth. There is no CMS.

Static Websites with Headless WordPress via REST API

Fri, 12 Jan 2018 09:21:14 GMT

Static Websites with Headless WordPress via REST API

Static websites are great but they still need some kind of content management system. And committing Markdown files to GitHub isn’t a friendly option for the majority of users including developers. So we end up using tools such as Prose, Netlify CMS or Contentful for the editing interface, user authentication and handling the media files.

Usually it is only the WordPress PHP templating layer that bothers the proponents of static websites and is perceived as the performance bottleneck. However, we now have the WordPress REST API which is way more flexible than any collection of Markdown files.

How?

Use WordPress REST API during the build process to create the content source files with the necessary front-matter.
Use Jekyll, Hugo, Metalsmith, Gatsby, Assemble or any other build tool to actually construct the website.

There is even a WordPress REST API client library for Node.js which simplifies everything for Node based workflows and deployment setups.

Finally, a free website on WordPress.com can be used as a content library.

Solutions WebriQ CMS is bringing to the to the table

We have made a choice for you when it comes to Static Website Generators

Spike

Spike is very good at helping to build static front-ends. It is sponsored heavily by Carrot Creative, and makes frequent, highly variable builds quicker and easier for freelancers and agencies. It’s a truly excellent framework for quickly and easily building small to medium sized front-ends of any kind. Spike is a next-generation static site generator. It is built on top of webpack, and a foundation of html, css, and js parsers that accept plugins to transform the output. It’s fast, actively developed, and very data-friendly. Check out the quick introduction video below to get a feel for Spike! Video

Why is WebriQ using Spike, and not Jekyll or Hugo?

The short answer is because Spike was built very specifically for static site builds, so it’s cleaner and better than general purpose build tools, since it’s specialized to that purpose. The longer answer is that it’s a qualitative thing. Much like people would ask “Why should I use snapchat when I can just text a photo” or “Why should I use slack when I already have hipchat?”, there is no logical answer other than that the experience is different, and in my opinion, much better — tailored exactly to what you need. So just try it, and you just might find that you really like it.

We are offering you a GIT Based CMS system with a Complete User Interface

After listing the best flat-file CMS and the best static site generators on offer — it’s time to formally identify what separates these two similar technologies.

We offer Integrations with Analytics, Content Marketing and Automation Tools inside our APP

Once you signed up and have your site created on our APP you can freely integrate

your Google Analytics account
Upcontent Content Curation Content
Automation Tool with Zapier - get your Zapier invite.

The Benefits Of A Headless CMS

Tue, 28 Nov 2017 22:25:24 GMT

There are a number of benefits of storing and managing content and design within a CMS, but this does mean that the purpose of the content is limited to a particular channel. For example, if you build a website within your content management system, it’s not going to be easy to offer this content to native mobile apps or third-party content users. For most organizations, a single piece of content can be used across Web, mobile, tablet, social media and other connected smart devices, commonly known as the IoT (internet of things). Business users are looking to publish content updates and affect all sites and applications that use this content.

To solve this problem, many organizations are turning to systems that provide a “headless CMS” style of implementation.

With a headless CMS, the CMS is responsible for publishing content and media only; layout, presentation and front-end technology are the responsibility of the development teams that consume content and use as required. With the headless CMS, content is published that is available to any application via API data services. This is commonly known as content as a service (CaaS).

This sounds like a simple solution (and it is) to ensure content is available to any channel and that it is de-coupled from the design.

There are a number of benefits to the headless CMS approach other than content de-coupling:

• The CMS implementation is cleaner. The CMS tool is purely storing content and isn’t cluttered with stuff that’s relevant to business users and other stuff that’s development only.

• With little technical involvement required in the CMS, it’s also a lot quicker for business teams to create new functionality. For example, if a marketing department wishes to create a new series of product mini-sites, it can go straight into the CMS and start creating the content immediately without having to wait for developers to build CMS-based templates.

• Companies no longer need large (and expensive) teams of specialist consultants who are knowledgeable in a particular CMS. Sure, some expertise is required, but not at the scale of a traditional CMS.

• It provides a better software architecture. A headless CMS is typically architected so that the CMS platform and the published content are separated. There are a huge number of benefits to this, including:

Security: Access to the CMS is restructured internally within the organization, while content that is published outside is either approved for public consumption or can be secured/encrypted as required.

Scalability: Need to add more servers to prop up demand for a particular application? Simply spin up a new app server and point it to the content.

Availability: Should the CMS application go offline, there’s no impact on the web applications.

• Future-proof updates. When it comes to re-branding one or more channels, there are literally no technical changes required within the CMS.

To summarize, a CMS is responsible for providing data storage, a user editing interface and a way to display and publish data, while a headless CMS provides a way to store and edit data but with a simple API to consume it without a specific way to publish such data.

While we remain vendor agnostic, a number of CMS tools are really showing leadership in the headless CMS space. One that stands out is Contentful, a CMS aimed at large-size companies. Another is SDL’s Tridion, a CMS for global enterprise clients, and WebriQ CMS, a Github based CMS system for small to medium sized businesses . While the majority of other CMS vendors such as WordPress, Drupal and Adobe have headless offerings, these are largely community-driven extensions that sit on top of the tools.

We are offering you a GIT Based CMS system with a Complete User Interface

After listing the best flat-file CMS and the best static site generators on offer — it’s time to formally identify what separates these two similar technologies.

This article was originally published by Forbes

Load time, static site generators & SEO: How we lowered our own site’s load time by 74%

Wed, 23 Aug 2017 07:19:10 GMT

Google has raised the bar on site load times consistently over the last decade, and the upcoming transition to mobile-first indexing, combined with its rising expectations of mobile site performance, should be a clear warning sign to site owners.

Site owners generally, however, seem not to be listening.

Unfortunately, based on our analysis of 10,000+ mobile web domains, we found that most mobile sites don’t meet this bar: The average load time for mobile sites is 19 seconds over 3G connections.DoubleClick research published in September 2016

At our company, we have been experimenting over the last year with static site generation. Our tests on our own site are aimed at allowing us to assess the challenges facing site owners, to understand the scope of opportunity and potential for performance improvement, and also to explore the practical limitations in content management — one of the key criticisms of static site generation.

Our site, QueryClick.com, was a small, fairly well-optimized B2B site, but it averaged ~6.99 second load time in the month prior to our deployment of static site generation (July 2016), dropping to ~1.8 seconds in the month following. That represented a load time reduction of 74.29 percent, despite some server response issues experienced during the period we were actively developing the site.

One month before and after switching to a static site generation infrastructure.

We performed further server optimization improvements over the year, reaching our sub-one-second mobile device target even while testing the impact of less efficient elements driven by JavaScript.

Yes, we know! We didn’t even use sprites, gzipping, or other such techniques — which highlights the impact of a platform-first approach to solving the page speed problem.

A platform-first approach to page speed

I’ve written before about the varying levels of importance of the different aspects of page speed on SEO and about how Google’s algorithm employs data about SERP bounce-backs (when users bounce back to its SERPs after losing patience with a slow-loading site). But it’s worth making the point again as we head to a mobile-first world: server response times and the critical render path event (the point at which everything in the initial device viewport is rendered) are key to delivering high-performance SEO, especially for enterprise-level sites.

Any developer worth their salt will look at the asset load requests in QueryClick’s site displayed in the above image and shake their head at all the unoptimized elements. But that is the point. High performance was achieved despite a lack of rigorous optimization in the code and asset deployment. It was driven by the platform and the high-level architecture decisions.

Google would like us to improve further — and we will, but real performance change has already been delivered.

So, what architecture did we use? As Python and Django evangelists, we write the copy in Markdown and push it to our staging server build via Github, where we can check to ensure it’s all OK. We thenuse Celery to set a time for the staging server copy to be pushed to the live Git repository. Then, Cactus regenerates the pages and, voila, the live server is populated with the static pages.

Of course, for your average content producer, this infrastructure is not as simple to create or maintain as a standard CMS without some technical know-how. That is the most common criticism of static site deployments, and many enterprise clients consider it a deal-breaker when they’re looking at static site solutions.

Certainly, if you manage product inventory that dynamically changes by tens of thousand in a day, which one of our clients does, then a robust management back end is essential.

That’s why anyone deploying a static site performance solution in the enterprise must leverage Oracle ATG or the like, which can easily generate and manipulate static web pages using its API. When you think about it, live dynamic site management requires significantly more hardware infrastructure than static.

If you need more convincing, take a look at the variety of static code bases already in flight. They use a variety of programming languages and many of them are fully capable of being fitted into an enterprise environment. When you also use a content delivery network (CDN) in production, you can offer a robust solution that delivers both blazing speed (for even poor 3G mobile connections) and total redundancy and elimination of server failure challenges.

Dynamic static asset provision and modern caching controls on static generators allow clean, live adjustment of content that is exactly comparable to dynamic site generation at a fraction of the hardware demand.

It may take years for the general web to catch up with Google’s pioneering push for modern, fast, easy-anywhere web experiences. But if you want to benefit your conversion rate and your brand experience, and enjoy a significant drive to SEO performance thanks to fast critical render performance and positive SERP bounce behavior, then you should have your development team investigate and find an architecture that works for your site today.

Do the test yourselves by entering your domain on TEST MY SITE or see the results for our WebriQ Site.

WebriQ CMS - a CMS for Static website deployments

With a Git-based CMS you can publish content every time you push changes to Git, allowing for a seamless development workflow. This approach is a bit difficult to scale with content that you want to publish across different platforms, but it will allow for you to have a purely static website. Since it runs on Git, you won’t have a problem finding an open source CMS to work with.

With an API-driven CMS, you’re creating content that will be strictly delivered via APIs. Although you won’t be able to keep track of content changes through Git, you’ll be able to scale your content through flexible APIs. But since you are working on a platform that hosts these APIs (server bandwidth ain’t cheap) these tend to not be open-sourced and rather pricey, but some offer freemium pricing models.

Or use WebriQ CMS, which in essence can be an API driven Git-based CMS.

About The Author

Chris Liversidge has over twelve years web development experience & is the founder of

QueryClick Search Marketing, a UK agency specialising in SEO, PPC and Conversion Rate Optimisation strategies that deliver industry-leading ROI.

What Do I Do: Static Websites or Wordpress?

Tue, 22 Aug 2017 03:29:59 GMT

Two Paths

There are essentially two famous techniques to take whilst making a decision to construct an internet site. You can go along with a static HTML internet site or a Content Management System (CMS) which include WordPress or Joomla. If you’re new to constructing and coping with web sites, then you might wonder what the huge difference is among these two tactics. They both make best websites, however, there may be an international of distinction on the way you get to the cease end result. Read onto discover the difference among them, and which one is really great for you.

HTML – CSS – JavaScript

A static HTML website is one which you construct with HTML and CSS. The cause it’s referred to as a static internet site is because nothing can alternate about the website or as a minimum no longer except you go back and exchange the code. Up till latest years, this becomes honestly the only way to make a website. There is no dynamic content, neither is there any actual consumer interaction. The only factor you get is what you input into the HTML. What does that suggest? Simply placed, after you are performed with the design and installation the internet site it will most effective do what you requested it to. You can make stunning web sites that allow the users to examine the content material, purchase merchandise, access to unfastened gives, sign on for newsletters and build your listing. Just approximately something your choice you can do with a static HTML internet site.

Though it is known as an HTML internet site, there are absolutely several exceptional coding languages generally used to construct an HTML website. List of basic HTML tags presents the shape or the core, but CSS is used to set the appearance and feel for the visuals and to make an appearance pretty too. You can set the dimensions, colors, fonts, backgrounds… And many others. JavaScript may be used to feature computer graphics to the internet site and even a touch dynamic interplay with the user. As you can believe though, in case you pick out to go this direction to create your internet site you’ll want to recognize at least the basics of each of the languages used.

WordPress or Joomla?

This is, in reality, a count of desire. Both are very good systems and for the maximum component, one is as clean to apply as the opposite. The biggest distinction among them is this: SEO WordPress has been around since 2003 and is very famous. As an end result, they get a huge amount of support from other programmers on the subject of Plugins (we’re going to talk about that is a minute) and search engine marketing, and there are a kazillion issues available for WordPress too, therefore making it a very popular desire for each rookies and pros alike. Joomla has not been around as long (2005) however has become very popular in its own right over the years. It is second handiest to WordPress and with over 30 million downloads and now with WordPress integration, it is no slouch. Both permit customers to depart comments to posts and or pages, circulate new content material from resources like social media or news websites and you could additionally quick add new posts to your blog without having to fear approximately editing your navigation bar (it’s computerized) or structuring your pages, thanks to built-in templates.

Pros and Cons

Static HTML: Pros – A static HTML internet site is straightforward to setup (especially if you understand code). You have complete manipulate of the layout, appearance, and feel. HTML best websites also have a tendency to load faster due to the fact they usually have fewer documents and information to download. As said in advance, a large gain of HTML is that you have total manipulate over the internet site’s appearance. You can trade the visuals of a WordPress or Joomla website online too, but you’re restrained via the amount of choices or flexibility available with the topic or template you’re the usage of. If you realize CSS, that is a fairly easy language, then you could without difficulty alternate the way your HTML website seems.

Static HTML: Cons – The cons of static HTML deal with its lack of interactivity and their complex shape with large websites. An HTML page has surely no interactivity and it handiest consists of what you code. For instance, in case you code a Web page with an editorial, then this is all you may get. There can be not anything else at the web page except for that article. There might be no person content, no dynamic content that generates at the same time as you’re away and the website will stay static. On the other hand, in case your software it to consist of a database in order that customers can get entry to the information I bet in a sense you can name that a constrained shape of interactivity. The same holds actual with a shopping cart. A user comes on your internet site buy a products or services you provide; so in the identical experience, they could engage with your internet site in a restricted form.

WordPress Pros – As stated in advance – you could use WordPress or Joomla, but for assessment sake, we’re going to simplest seek advice from WordPress hereafter. WordPress is regularly taken into consideration the first-class manner to setup a website because it’s miles very clean to do and clean for inexperienced persons to parent out. A WordPress blog does make the effort to setup but not when you don’t forget how long it took someone to jot down all of the code required for an HTML web site. Besides, we’re actually talking hours, no longer days or even weeks, but it might no longer be out of the normal for an internet developer to spend days designing a new internet site the use of HTML, CSS, and JavaScript. Installing a WordPress blog most effective takes a few minutes with maximum hosts, and including a new theme takes even much less time and subject matters are what WordPress is all about.

Let’s take a minute to talk about topics. Themes or templates permit you to trade the appearance or feel of your website actually in minutes. If you want a particular area of interest web page as an example, a medical looking experience or a golfing theme there are masses to choose from. Some are unfastened and others you will need to buy, typically called Premium topics. If you just need a blog and a place for humans to go away remarks, then a unfastened theme will possibly do the trick. However, in case you want a greater expert or storefront look with maybe a buying cart or an information feed for an Amazon associate, then a top rate topic is the manner to move. I pick premium topics due to the fact they typically permit for greater flexibility and customization.

WordPress Cons – One of the problems with WordPress may be too many plugins. I’ve seen websites that take too long to load and it changed into resulting from having a manner to many plugins established on the web page. Only use what’s vital. Another factor to recollect is the issues. Some are sincerely better than others. Theme developers put plenty of time and idea into the design, but a few developers are certainly thinking of the give up-person greater than others and recognize that we want lots of customization freedom and greater importance, now not each person has programming talents so make it easy to understand and use. All of them allow for some customization, but others will provide you with greater manipulate and the ability to make your internet site appearance the way you actually need it’s. All I’m announcing is to read the critiques and do your homework earlier than making an investment in a top rate subject matter. Also, a well-designed subject matter will look clean and cargo speedy. There are heaps of issues to select from, so you are certain to discover something that you like.

Solutions WebriQ CMS is bringing to the to the table

We have made a choice for you when it comes to Static Website Generators

Roots

Roots is very good at helping to build static front-ends. It is sponsored heavily by Carrot Creative, and makes frequent, highly variable builds quicker and easier for freelancers and agencies. It’s a truly excellent framework for quickly and easily building small to medium sized front-ends of any kind. Roots can handle a huge number of compiled languages, and can be used with many tools that help push static sites as far as possible. For example, it can link with an API, pull in your data, and render parts of it into your views on compile. Then it can render the same or other views as javascript templates and you can push any other data from your API into them on the fly at runtime on the client side in reaction to user actions. And that’s just a small taste of its capabilities. You really can do a lot with static sites, and roots is here to push those limits.

Why is WebriQ using Roots?

The short answer is because roots was built very specifically for static site builds, so it’s cleaner and better than general purpose build tools, since it’s specialized to that purpose. The longer answer is that it’s a qualitative thing. Much like people would ask “Why should I use snapchat when I can just text a photo” or “Why should I use slack when I already have hipchat?”, there is no logical answer other than that the experience is different, and in my opinion, much better — tailored exactly to what you need. So just try it, and you just might find that you really like it.

We are offering you a GIT Based CMS system with a Complete User Interface

After listing the best flat-file CMS and the best static site generators on offer — it’s time to formally identify what separates these two similar technologies.

We offer Integrations with Analytics, Content Marketing and Automation Tools inside our APP

Once you signed up and have your site created on our APP you can freely integrate

your Google Analytics account
Upcontent Content Curation Content
Automation Tool with Zapier - get your Zapier invite.

Disrupting Authoring: The Oldest Trick in the Web CMS Book

Thu, 03 Aug 2017 03:22:01 GMT

Every wave of web CMS change reflects the changing demands of the broader industry PHOTO: Aaron Burden When an industry has been around for decades, it naturally goes through waves of change.

As content management grew from a way to manage static sites to the backbone of the whole enterprise experience, it’s evolved with market needs. Interfaces got better, architecture became more efficient and the way marketers have controlled and measured content has continuously been improving.

From breaking classic bottlenecks to the current rise of personalization, the waves of change in enterprise needs is directly reflected in the way they choose to manage their digital empire.

Wave 1: Breaking the IT Bottleneck ---------------------------------- It was the late ’90s, and everyone wanted to get their business online.

At the time, doing so required each edit to go through a webmaster with their html authoring tools. Needless to say this bottleneck frustrated marketers and they looked for a way to create pages themselves.

Enter XML forms, where editors could fill in information, add in business logic, store the information in a shared database and publish on any application. It was the beginning of the separation of content and presentation and, for the businesses exploring digital, it was revolutionary. Without the need of a webmaster, an end user could fire up the form, generate the page, preview and publish, all with a separation of content that allowed raw data to be used in multiple spots.

Wave 2: Speed in the Age of the Digital Marketer ------------------------------------------------ We had separation of concerns, we had reusability, we had workflow — and then all of that faded away with the next evolution of market demands.

Marketers wanted to control not only the content but the presentation, something the custom XML templates didn’t offer. And they wanted to do this at speed, quickly being able to build and optimize landing pages, mobile sites, microsites and the like.

At the time channels were very siloed, with one person responsible for the desktop site, another for mobile, another for customer portals and so on. Each digital marketer had complete control over their channel, creating separate architecture for each and not considering content reuse across the channels they didn’t own.

Inline editing skyrocketed at this time. It allowed digital marketers to visually tweak their channel as much as they wanted, but this meant the content was locked to a single page. The industry put content re-use and workflow on the back burner to cater to separate business channels.

And for a time, this worked. Channel editors controlled their domain with the speed they wanted. But it was only a matter of time before the obvious flaw in these disjointed channels became apparent, in the next wave of the online experience.

Wave 3: Cross-Channel Customers ------------------------------- Businesses soon realized that even if they managed their channels separately, customers saw them as one and the same. Customers expected the information, and overall tone of experience, to remain consistent whether they were on mobile, an app, desktop or any other touchpoint.

Businesses tasked with focusing on the entire customer experience were faced with the reality that content lifecycles from one channel to the next were simply broken.

The solution was a return of structured content, and technology vendors rushed to do so. Marketers could fill out content in forms and preview that content in the context of multiple channels. As businesses invested more in content, especially the emotional influence it had on their customers, they needed to unlock the ROI by reusing it across absolutely every touchpoint.

The need for reusable content saw the return of neutral forms — but marketers were used to the control over presentation they had with inline editing. Web content management vendors reacted in multiple ways. Some remained page-based with inline editing, some went the headless route and let a third-party worry about content display and others linked a preview mode to the content editing mode to quickly toggle back and forth.

Wave 4: The Rise of Personalization ----------------------------------- The separation of content and presentation doesn’t just aid in cross-channel, it’s also a critical component in delivering the personalized experience today’s customers expect. Personalization requires not only this separation of concerns, but also the ability to attach metadata to re-usable content.

Inline editing, where changes to content are made in the context of a specific page, simply isn’t built to offer cross-channel, personalized and consistent customer journeys. A quick YouTube search for vendors’ editing capabilities will show slick demos with inline editing but when a company wants to roll out personalization across all channels, they ultimately end up using metadata friendly forms.

So is personalization and cross-channel consistency the death of inline editing? Of course not. Because when new industry needs arrive, new solutions quickly follow. Marketers need a way to organize metadata, easily target content, keep a consistent brand experience and remain in control of channel presentation. Enter visual editing.

With visual editing, marketers can instantly see their changes in context — across different channel perspectives, personas and targeting efforts — and, importantly, the changes are made to the underlying content repository. This means that any edits made in context, such as fixing errors, updating links or adding an image, will be carried over to every location that content is used: from remote display units to mobile apps.

This type of visual editing won’t remain a rarity for long, it’s simply where market needs are directing the experience management industry because large scale, AI-driven hyper-personalization is what enterprises will look to for competitive advantage.

Businesses relying on solutions without a separation of content and presentation will lack the metadata capabilities and thus miss the omnichannel, personalization boat.

Tjeerd Brenninkmeijer is the CMO of BloomReach EMEA. He is a frequent contributor to industry publications and a speaker at industry events.

Using the traditional monolitic approach whereby you build, manage and publish your website on a single server, there is a more distributed approach whereby you build your site on a Static Site Generator, publish the site on GIT repositories and host the site on a Content Delivery Network.

Choosing between a Git-based CMS or an API-driven CMS

Or use WebriQ CMS, which in essence can be an API driven Git-based CMS.

Static Website CMS

Wed, 26 Jul 2017 16:00:00 GMT

The Forgotten Potential of Static Websites

Recognizing that issues exist is only the first step in a long journey; actually finding a solution is the hard part. But as it turns out, the solution had already been created. In fact, it had been created even before CMSs like Joomla and WordPress had been invented! The answer is static websites, which are not generated by software on a server. Let’s break it down. with something like WordPress, the CMS is acting as the intermediary between the server and the user; when you visit a WP site, the browser requests the page, WordPress pulls the information, such as text, images and whatnot from its database, then uses predefined layouts from themes, plugins etc…to generate workable webpage from all that information that is then sent to the browser. In a static website, either the page is manually created, or generated using static-page-generation-tools. Either way, since the actual generation is done in advance, when your browser sends a request to the website’s server, the only thing the server needs to do is send the pre-generated files to the browser, rather than running through the entire fetch-generate-send process. This approach offers some pretty major benefits that directly answer the issues discussed earlier. For one, a static website hugely increases wetite security; many hacking attempts take advantage of exploits that allow them to ‘inject’ their own code into the CMS’ or website’s code, but in order to do this there needs to be actual code being run. In a static website everything is, as the name implies, static; no code is being run, only the generated website files are sent to the browser, making the site nigh-impossible to hack without gaining direct access to the server. Secondly, since a static website doesn’t demand any additional operations to be run by a server, such as compressing PHP code or connecting to a database, to generate the final content it allows for significant improvement in load speed and optimization. Compare the speed of a fully-optimized dynamic website: …/smashingmagazine.com with its faster static counterpart: …/smashing-static.netlify.com

Solutions WebriQ CMS is bringing to the to the table

We have made a choice for you when it comes to Static Website Generators

Roots

Why is WebriQ using Roots?

We are offering you a GIT Based CMS system with a Complete User Interface

After listing the best flat-file CMS and the best static site generators on offer — it’s time to formally identify what separates these two similar technologies.

We offer Integrations with Analytics, Content Marketing and Automation Tools inside our APP

Once you signed up and have your site created on our APP you can freely integrate

your Google Analytics account
Upcontent Content Curation Content
Automation Tool with Zapier - get your Zapier invite

Are You Using The Right CMS Platform?

Mon, 17 Jul 2017 00:29:22 GMT

CMS is short for Content Management System – and it’s easy to understand why many novices find the term confusing. Broken down, it sounds like a specialized tool, something you might use to store and organize materials before putting them online or saving reference materials. In reality, though, CMS platforms are everywhere. WordPress is a CMS and so is Drupal, and there are dozens of others. Once you understand that every website is dependent on CMS infrastructure, the importance of such tools becomes clear.

With that in mind, then, how do you know if you have the right CMS platform? Consider these 4 factors as you navigate this complex marketplace. The right host is the one designed for your niche, so stay outcome-focused as you assess your options. It’s all about results, after all.

Think Support

For those who are relatively new to web design, the level of support available for a given CMS platform can be a big factor when selecting one for your own site. For example, WordPress is the most popular CMS because it’s used not only for business sites but also for many free, personal pages – it has over 24 million installations. Because so many people are using the platform, then, there are tons of support boards online, as well as a robust customer service team.

Compared to WordPress, a CMS like Drupal has only 1.3 million installs and Typo3 and Concrete5 follow Drupal at a distance with 500,000 and 140,000 installations, respectively. Though the users for these platforms are passionate about them, you’re far less likely to find beginner-friendly support for these systems.

Know Your Field

Just like WordPress is ideal for personal and small business websites, some other industries have niche CMS platforms. For example, in 2015, all Australian government departments were made to migrate online. In doing so, it became clear that most of the sites were very similar. In order to save money and reduce redundancies, local firm Bliss Media helped the government streamline the process by developing govCMS, a single CMS platform that could be adapted for any Australian government site with both PaaS and SaaS options.

Of course, many other governments could likely make use of govCMS, not just those in Australia, but this was decidedly a targeted solution. If you ask around within your industry, you’re likely to find similar solutions exist.

To Host Or Not To Host

Most CMS systems offer multiple hosting options, specifically designed so you can keep your system onsite and host it through your own servers, or you can just buy the software and run it remotely.

For most businesses, SaaS is a better option than on-site hosting because you aren’t responsible for server failures, the software is typically more flexible and always up to date, and the company takes care of the IT side of things. Even advanced web designers can benefit from SaaS – and these systems grow with your audience.

Study Security

Finally, security is a top concern for web users today, so if you’re using a platform without proper protections, you’ll see your user base decline. Some CMS systems support security plugins, while others allow you to restrict different users access settings. Make sure to ask plenty of questions about your security options before settling on a CMS so that you don’t wind up facing a user privacy scandal.

There’s no single CMS system that’s right for everyone. Instead, it’s important that you understand exactly what your end goal is and pursue it through your choice of platform. Take your time and don’t jump into a decision just because you want to get your site built. This decision will impact your site’s performance in the long term. Thousands of organizations just like these use open source cms to run their websites because they are more often than not; easier to customize, typically more cost effective, easier to support and maintain, and usually integrate with 3rd party apps and software much better.

With open source software, you can keep your software up to date, never worry about obsolescence, and don’t have to keep learning how to use new programs because a developer doesn’t want to support its older products. Check out the infographic below to learn more about how open source software has changed the way people build websites.

Choosing between a Git-based CMS or an API-driven CMS

Or use WebriQ CMS, which in essence can be an API driven Git-based CMS.

Author: Spyrestudios Blogger

What Are the Benefits of Using an Open Source CMS for Your Business Website?

Sun, 09 Jul 2017 02:56:40 GMT

Benefits of Using an Open Source CMS

What Are the Benefits of Using an Open Source CMS for Your Business Website?

Businesses of all sizes should consider an Open Source CMS for their website needs when it comes to security, custom development as well as ongoing support.

Did you know that the three most popular content management systems are run on open source software? It’s true!

Drupal, Joomla, and WordPress all use open source software to power their frameworks and give end users software for free or nearly free.

Meanwhile, developers take advantage of the fact they can go into the source code of the frameworks and create their own products to work with these popular programs. The end result is a seemingly endless selection of themes, plugins, and widgets that simply work when you install them onto the software framework. And if it doesn’t? You can go back to the well and find something that does. It’s just that easy.

Open source software offers the same benefits as closed source software with an additional angle: Developers tend to support their work for far longer than closed source software providers. That means you get the security and comfort of knowing you can keep using something that works perfectly for your needs for as long as you’d like. Why? Because you can always find someone to work on the code even if the original developer has decided to stop supporting their software.

Here are just a few organizations and institutions that use the WordPressopen source cms to power their websites:

As you can see, these are some pretty big players, and they’re all using WordPress. Thousands of organizations just like these use open source cms to run their websites because they are more often than not; easier to customize, typically more cost effective, easier to support and maintain, and usually integrate with 3rd party apps and software much better.

Choosing between a Git-based CMS or an API-driven CMS

Or use WebriQ CMS, which in essence can be an API driven Git-based CMS.

Exciting times for all front-end developers and for business owners who want to simplify their web operations with secure, reliable and ultra fast technologies.

Get the White Paper, “The Benefits of Open Source Software” from our friends at CopyPress.

Static Site Generator vs Flat File CMS

Wed, 28 Jun 2017 16:00:00 GMT

After listing the best flat-file CMS and the best static site generators on offer — it’s time to formally identify what separates these two similar technologies.

What Is a Static Site Generator?

A static site generator does exactly what it says on the tin: it renders static websites comprised of nothing but static content.

Enterprise systems designer Craig Buckler offered this definition:

“A Static Site Generator combines content and templates into static HTML files. Generation occurs once and the files can be hosted anywhere without server-side languages, frameworks or other dependencies.”

SSGs compile text-based content files (including markdown or plain text) into HTML pages using templates to determine the layout of the page. The rendered site can then be uploaded to a server, remaining unchanged until the next time the SSG is run, making it ideal for sites that don’t require regular modification.

Because of the way SSGs work, they make ideal companions for headless content management systems, which can handle the heavy content lifting while the SSG acts as the delivery layer.

Their simplicity and agility make them a good solution for enterprises looking to deploy microsites and landing pages. However, they can slow projects down if the site in question is particularly large or image-heavy — as explained by web architect Stefan Baumgartner.

Pros and Cons of Static Site Generators

Pros

Site Speed: SSGs don’t require databases, nor do they rely on server-side script processing. You can put a static site on a CDN and let it quickly be consumed worldwide
Flexibility: Developers generally love the flexibility of SSGs because changing the layout or adding another microsite to the content does not require going deep into the internals of the content management system. You’re generally free from traditional content management system constraints
Security: Thanks to the simplistic nature of a static site, hackers and malware bots have fewer loose ends to exploit. Not having any database or any dynamic interpreter running on your servers reduces the risk of hacks
Managed Publishing Cycles: Storing all of the technology parts as well as the content in a version-control system such as Git allows for a flexible publishing cycle. Preparing content in a branch, merging it on demand and putting it out on the servers entails just a few clicks

Cons

Slow at Scale: Because SSGs render entire sites at once, larger sites can take a very long time to initially deploy. Thus, they aren’t ideal for large sites
Dynamic Content Is Out: By definition, static site generators don’t natively support the deployment of dynamic content — which can be an issue if you want your site to have something as simple as a calendar functionality. For such dynamic content, you’ll have to lean on third-party solutions
The Need for Headless: If you have clients or content editors who are comfortable with coding, you’re safe. But with most content editors being less than tech-savvy, you’ll need a headless or API-driven CMS to help manage your static content more easily
No Database: Going without a database has its benefits, but it also has its disadvantages. Users can’t search and sort through your site, nor can you add things like a blog or forum.

What Is a Flat-File CMS?

A flat-file CMS is also a database-less technology. However, they typically come with user interfaces like admin control panels and WYSIWYG editors, which is ideal for less technical marketers and agencies dealing with hands-on clients.

We turned once more to Buckler for a definition:

“A flat-file CMS allows you to edit website content through a user interface. Most traditional CMS store page data in a database but a flat-file CMS uses files instead. Server code combines content with a template when the page is requested, [unlike SSGs, which serve pages from one initial rendering].”

Flat-file content management systems allow for heightened speed, simplicity, mobility and security. Plus, because they come with a UI, they are an approachable solution for the less technical.

Pros and Cons of Flat-File CMSs

Pros

Faster Initial Deployment: There’s no database, so all you really need is a cloud or locally hosted environment and an FTP client to deploy a site. Plus, because flat-files sites aren’t rendered wholesale like SSG-powered sites, initial deployment is typically faster
Site Speed: Like SSGs, the absence of database queries helps flat-file CMS load sites faster
Lightweight and Portable: Flat-file platforms are typically very small in size. So moving flat-file projects from server to server is easier
Version Controlling: Flat-file CMS can be version controlled via GitHub and its competitors, which comes with all the associated collaboration and workflow benefits

Cons

Smaller Communities: Flat-file solutions never quite get as much attention as SSGs, and this is unlikely to change thanks to various headless CMS vendors recommending SSGs to their clients. Thus, the flat-file community and resulting support is more sparse
Not as Fast: Because flat-file CMS driven sites are rendered upon request, they take slightly longer to load for users in comparison to SSG-powered sites
No Database: Like with SSGs, you pay the price for going without a database. That means you can’t give users the ability to search and sort through your site, nor can you add more technical dimensions to your site, like a blog or forum.

How to Choose Between Flat-file CMS vs. Static Site Generators

If you’re still struggling to choose between a flat-file CMS and a static site generator, Buckler highlighted the differences.

“The primary difference between the two, is that a flat-file CMS provides a user interface, while a SSG is a developer tool with no interface other than the command line,” he said.

“However, the distinction is not always clear and the two technologies can share certain benefits. For example, a flat-file CMS could potentially run locally and use SSG techniques to render static HTML files prior to upload. Similarly, a static site generator could extract page content generated from any flat-file CMS (or indeed, any database-driven CMS).”

To sum up, a flat-file CMS is typically best suited for agencies with hands-on clients and content editors who require a user interface to produce content. SSGs on the other hand, are ideal for developers who want small, snappy websites, or who are hunting for a delivery layer to accompany their headless CMS.

After listing the best flat-file CMS and the best static site generators on offer — it’s time to formally identify what separates these two similar technologies.

WordPress or HTML?

Fri, 23 Jun 2017 04:49:08 GMT

There are basically two popular approaches to take when you decide to build a website. You can go to a static HTML website or a Content Management System (CMS) such as WordPress or Joomla. If you are new to building and managing websites, then you might wonder what the big difference is between these two approaches. They both make websites, but there is a world of difference on how you get to the end result. Read on to find out the difference between them, and which one is really the best for you.

HTML – CSS – JavaScript

A static HTML website is one that you build with HTML and CSS. The reason it’s called a static website is that nothing can change about the website or at least not unless you go back and change the code. Up until recent years, this was really the only way to make a website. There is no dynamic content, nor is there any real user interaction. The only thing you get is what you enter into the HTML. What does that mean? Simply put, once you are done with the design and install the website it will only do what you asked it to. You can make beautiful sites that allow the users to read content, purchase products, access to free offers, sign up for newsletters and build your list. Just about anything you desire you can do with a static HTML website.

Though it’s called an HTML website, there are actually several different coding languages typically used to build an HTML website. HTML provides the structure or the core, but CSS is used to set the look and feel for the visuals and to make look pretty too. You can set the size, colors, fonts, backgrounds… etc. JavaScript can be used to add special effects to the website and even a little dynamic interaction with the user. As you can imagine though if you choose to go this route to create your website you’ll need to know at least the basics of each of the languages used.

A Content Management System (CMS) is much more user-friendly in the sense that you do not need to know any code in order to use it. CMS is more of a “drag and drop” or “point and click” type system. You log in to the “admin” portion of the website and make the changes you desire and update. The changes you make to the appearance or functionality of your website take effect immediately after you save and update. One of the other nice things about CMS is the variety of themes available, but we’ll talk about that later.

Most CMS sites are referred to as Blog sites, primarily due to the fact they were originally used for blogging and not much else. In recent years CMS has become so much more and are now one of the most widely used programs for building a website today. Built using PHP, CMS sites have a database attached to save all of the core and dynamic content. So once again, the biggest differences between CMS and static HTML are dynamic content (change it on the fly) and no coding required.

WordPress or Joomla?

This is really a matter of choice. Both are very good platforms and for the most part one is as easy to use as the other. The biggest difference between them is this: WordPress has been around since 2003 and is very popular. As a result, they get a huge amount of support from other programmers when it comes to Plugins (we’ll talk about this is a minute) and SEO, and there are a kazillion themes available for WordPress too, thus making it a very popular choice for both newbies and pros alike. Joomla has not been around as long (2005) but has become very popular in its own right over the yeas. It is second only to WordPress and with over 30 million downloads and now with WordPress integration, it’s no slouch. Both allow users to leave comments to posts and or pages, stream new content from sources like social media or news sites and you can also quickly add new posts to your blog without having to worry about modifying your navigation bar (its automatic) or structuring your pages, thanks to built-in templates.

Pros and Cons

Static HTML: Pros – A static HTML website is easy to setup (especially if you know code). You have complete control of the layout, look and feel. HTML websites also tend to load faster because they usually have fewer files and data to download. As stated earlier, a big benefit of HTML is that you have total control over the website’s appearance. You can change the visuals of a WordPress or Joomla site too, but you are limited by the amount of choices or flexibility available with the theme or template you are using. If you know CSS, which is a fairly simple language, then you can easily change the way your HTML website looks.

Static HTML: Cons – The cons of static HTML deal with its lack of interactivity and their complex structure with larger websites. An HTML page has absolutely no interactivity, and it only includes what you code. For example, if you code a Web page with an article, then that’s all you will get. There will be nothing else on the page except for that article. There will be no user content, no dynamic content that generates while you are away and the website will remain static. On the other hand, if you program it to include a database so that users can access information I guess in a sense you could call that a limited form of interactivity. The same holds true with a shopping cart. A user comes to your website purchase a product or service you offer; so in the same sense they can interact with your website in a limited form.

If you want to make changes to your site like adding a new post (write a new article) or page you will need to create it first and then upload the HTML file it to your server and then change the navigation bar (menu) before it is visible to the user. This takes up a lot of time, especially if you add one or more pages a day. Another consideration is: if you don’t have a good CSS structure in place then changing parts of your website can be very cumbersome. For example, you want to change the background color for all of your pages on your site. If you have the background color programmed with CSS and have it called out in the HTML for all of the pages, then changing the color in the CSS will change the color on all of the pages on your website. This is huge for website that might have 100 pages or more, otherwise you’ll need to change all 100 pages individually. As you can see, static HTML sites are easy for the guy who understands the code requirements, but not so for that person little to no code knowledge. Finally, SEO! You will need to code all of the SEO into your static website yourself. Considering SEO is a somewhat dynamic process, you will find yourself always having to go back and tweak or change your site to keep it current.

WordPress Pros – As stated earlier – you can use WordPress or Joomla, but for comparison sake, we’ll only refer to WordPress hereafter. WordPress is often considered the best way to setup a website because it is very easy to do and easy for newbies to figure out. A WordPress blog does take some time to setup but not when you consider how long it took someone to write all of the code required for an HTML site. Besides, we’re literally talking hours, not days or weeks, but it would not be out of the ordinary for a web developer to spend days designing a new website using HTML, CSS, and JavaScript. Installing a WordPress blog only takes a few minutes with most hosts, and adding a new theme takes even less time and themes are what WordPress is all about.

Let’s take a minute to talk about themes. Themes or templates allow you to change the look or feel of your website literally in minutes. If you want a particular niche site, for example, a medical looking feel or a golfing theme there are plenty to choose from. Some are free and others you’ll need to purchase, usually referred to as Premium themes. If you just want a blog and a place for people to leave comments, then a free theme will probably do the trick. However, if you want a more professional or storefront to look with maybe a shopping cart or a data feed for an Amazon affiliate, then a premium theme is the way to go. I prefer premium themes because they generally allow for more flexibility and customization.

SEO is another big plus for WordPress because a lot of it is already built into the program. when you install WordPress on your server for the first time you immediately need to go the admin section and complete a setup process located in the settings> general settings area. In there you will fill in a couple of fields that are the beginnings of the SEO process. Afterward, every time you create a page or post you are able to add to your SEO and keep all of your content current and search engine friendly. There are plenty of good plugins you can use that can take your SEO to astronomical levels.

Speaking of plugins, there are thousands of plugins that add unique and interesting effects to your WordPress website. There are so many choices of plugins that it will be impractical to try and mention them here, but to give you a taste: there are plugins for advertising, SEO, article submission, spam protection, adding captchas, creating contact forms, email campaigns and even ones that will automatically backup your website according to a schedule you setup. The list of plugins goes on forever.

WordPress Cons – One of the problems with WordPress can be too many plugins. I’ve seen websites that take too long to load and it was caused by having way to many plugins installed on the site. Only use what is necessary. Another thing to consider are the themes. Some are clearly better than others. Theme developers put a lot of time and thought into the design, but some developers are really thinking of the end-user more than others and recognize that we want lots of customization freedom and more importantly, not all of us have programming skills so make it simple to understand and use. All of them allow for some customization, but others will give you more control and the ability to make your website look the way you really want it be. All I’m saying is to read the reviews and do your homework before investing in a premium theme. Also, a well designed theme will look clean and load quickly. There are thousands of themes to choose from, so you are sure to find something that you like.

Installing your WordPress Website

Installing a WordPress site with most hosts takes only a few minutes. I found GoDaddy to be one of the best web host out there. There is other good web hosting companies and I’ve used several of them and would not hesitate to recommend them, but GoDaddy (in my opinion) has superior customer service. I cannot say enough about a company that has a phone number you can call and an actual customer service person (a real human being) will answer and be there whenever you need them. However, Afterward your choice as to which ever company you decide to use and are more comfortable with.

Now back to installing! Just log in to your web host and follow their instructions for installing WordPress. Afterwards, you’ll need to upload and install your theme. Once that is complete and you received conformation from the server that the website is active, all that is left is to start adding content and customizing your new website and make it look the way you desire.

WebriQ CMS - best of both worlds. A Static Site building approach combined with a Git-based CMS system to continuously update your content

Concept for a better Netlify CMS editor / Part 2

Thu, 22 Jun 2017 09:41:25 GMT

Continuing from part 1 this post is going to be more practical and explain some solutions that could be used to either improve or be starting stone for the next Netlify CMSthat the community could build upon.

Here are some goals from all the data and research gathered in part 1 that I’ll try to solve or improve:

should have the ability to add sections while writing
should have default and customisable content blocks/sections
should have pre-made templates/layouts for specific content collection pages (example, job posting)
should be easily usable by any of the 3 groups of people
should give an experience of uninterrupted writing, the writer should stay in “the zone” from the beginning to the end of the article

Also, Shawn (Netlify CMS lead architect) gave some valuable feedback, especially that the average WordPress user still wants to use the mouse. So the goal of creating an “uninterrupted experience” for writers inside a CMS is limited by that as my main idea was to use just the keyboard without the mouse when inputting or writing text in the editor.

But after a short break, it’s not really a limitation as we can always use both writing flows so the user can use either one he prefers. Now the new method without the mouse would need a bit of training and would require a small learning curve but the user could choose which one he prefers after. Let’s look at it more of an evolution.

Let’s dive into different sections step by step on how all the parts would fit together, visual examples with some explanations behind them.

Note that there are 2 different editor uses in the CMS and it’s easier if you have only 1 editor for both. There are pages/blog posts which tend to be empty and you create or add layouts/sections based on the content or the desired structure (the layout is based on content). And the second use is for premade pages or content that already have defined inputs, like a job posting or a profile page (content is based on layout/structure).

Biggest problem of most CMS are the quantity of input fields

Hiding all the buttons we don’t really need help keep our canvas clean and the things we write structured. But again CMS’s can have these inputs and options all over the place.

Here’s an example of a site I designed for my wife’s business and how the building blocks and options are used in WordPress and ACF.

Now I really think this can be improved. There are many problems here like the one that you need to really search for either some settings or content if you want to edit it. The database is called for each of those fields on the front end and making lots of queries. Now static sites fix the later but the writing/editing experience is in blocks and not a fluid way of content. Everything is just too complex and all over the place. Hiding things in tabs makes it cleaner but the overview of the whole content on that page is really poor.

What if the content for a CMS would just go two ways, right (writing) and down (scanning) without any tabs etc.? And you would also see everything just by scrolling the page, without clicking or opening things up.

Blank canvas or writing without limits

There is a minimum of input fields needed here but the basic and minimal ones are mostly:

Featured image
Title of the post
Editor field for the content

Now to bring this together in the cleanest and minimal sense possible would look something like this.

The square button with the + inside is for a popup to upload the image and below we have the I-beam pointer (blinking |-cursor) that we’re used to. This is the main indicator to start writing or rather the cursor is waiting for the input.

The light grey coloured title is, in my opinion, a nice touch or a bonus that invites the user (motivates and gives assurance) to do great things. It’d be great to have more questions or inspiring copy here that is randomly changing. It’s something that’s been around for a long time (usually newsletters had input placeholders and Paper is also using it today). But imagine adding a “brands voice & tone” to this message for your writers and making it more personal?

Next thing is the title input. Like Paper from Dropbox and some other editors have already found out, there isn’t any need to have visible input fields or text inputs. Things just flow nicely here.

After writing the title and hitting enter/return key. You jump outside the title field and start the paragraph of that section. Really clean and simple. Again, no boxes, no toolbars or anything.

Toolbars and styling text

Most of the current (or old if you want) editors have a lot of buttons or different ways to manipulate or style the information we provide. Which is great but we have too many options and the canvas gets messy. Things have evolved and we can evolve them even further.

Writing things in Markdown is great and the most important thing is, you don’t need to switch to the mouse and use it. Yes, the writers may need to learn some of these things, but they’re really intuitive and do improve the writing and the experience. UX/UI tends to overfocus on making things easier, but we don’t always need to improve the product so it’s easier to people to use it. Why not teach people to use the product as it’s meant to be used? It’s similar to the driving licence, you want to drive on the road, you need the training to handle the car. You want to have a better writing experience, learn Markdown. Some say it’s a “programming language” or meant for programmers, I say it’s not. It just brings some more “rules” to the writing we already have. Just look at this text, we’ve used – . , ; / ” ! ? and other characters since early school days. Markdown just introduces some new ones or extends their usability.

We tend to “dumb down” the product which also has the effect of not making some things challenging for the user (dumbing users down). They want to grow too, try new things and evolve as much as we evolve our products.

But let’s not make the mistake of not giving the user a choice here. We need to cover both user experiences here. The old and the new. The user tries both and he decides what to use. We still need to educate about the new approach though.

The Alloy Editor which was also mentioned in Netlify CMS Github issue is a nice solution. It’s visible when you need it keeping the canvas clean. We just need to pair it with Markdown and use the selection menu as a “fallback” or an alternative option to styling things. And since both ways of styling are “hidden” they won’t get in each others way.

Here’s Alloy Editor in action:

So we don’t need toolbars at all. But we still keep the functionality and the clean look.

Having an editor without really using one

With today’s popularity of React.js and even Vue.js it’s a lot easier to create an amazing experience for writing content. As mentioned earlier, we don’t really need to see input fields and text area boxes like we’re used to with WordPress and Advanced custom fields. We also don’t need to see these fields or borders, we just need to know the structure of the content or end result and React.js can take care of everything else behind the scenes, magically.

A really nice and currently popular way of adding blocks of content is the + button next to the new paragraph. You click it and then you can choose what kind of “layout” or information placeholder you would like to add at that point. Netlify CMS already is using it and so are more and more other editors. I like this concept of “building blocks” and adding things like images is really a nice experience.

My concept/idea would improve that. You would write text like you do in Google Docs or Word, but the CMS would create hints on what and where the information will be explained. It would add the context of that information. And you would have minimalistic visual guides on what that content/layout is. The mentioned Alloy Editor already has a similar feature, but it can again be improved for the use in a CMS Editor.

This is how the basics would look. You click the + button and then you get displayed the layouts you could use. Remember, these blocks could be anything from ads to a call action block.

It’s something similar Netlify CMS already has. But again, we need to go in and click, input stuff and then we can continue with the writing. Also, it’s an improvement over the WordPress way I did above, but let’s try and make it right.

Putting it all together and making it work

Now things seem to be going places but there are still different concepts here which don’t yet fit perfectly well together. I think one of the things that would tie all this together nicely are the mentioned visual guides for the content blocks. Remember, that we’re still making a CMS Editor here but we want it to feel like a Word document. OR even better like something we would write on paper.

We would need a system of grouping things together for the content blocks.

Let’s try and analyse a simple landing page example with the above ideas. We start with how things would look without any grouping.

Left is a line sketch of the text and right are the sections or content blocks. This is the view we get in the Editor, not the front end, but as I said that I want the text to flow right and down it will keep the structure of the front end as much as possible. I wouldn’t use any columns in the editor.

One common way would be to make the background gray and make the sections white.

But this again created blocky content and the content doesn’t flow. We also introduced new (bigger) elements instead of using what was already there. So let’s take a step back and try color coding the things that are already there.

This variation above would color the text separating the blocks. But there would be a problem if you had 2 same blocks one after another as they would look as one. So let’s try and minimise this even further but still use the colors.

We keep the colors and just use a small line at the left side of the content block visually grouping the content on the right making everything clean and structured. But just the color may not be enough for first-time users so the icons for the content blocks should also be used, but these can be hidden until you hover over it.

Content blocks of the new CMS

If we have a blank page without any inputs, it’s hard to know what the new blocks need to input. For some it may be easier as you would just write a sentence, but what about a CTA? It can have a title, paragraph, button text, button url, url target etc.

That’s why new blocks would need to have labels so we can “fill them in”. It’s the main thing that makes any CMS work really. Here’s the CTA block when it’s empty.

And here’s the same block when full.

An image block also needs and “upload” or gallery button or that functionality. Here’s an example of how the different states would work.

Now on the front end, there should be things in place so that if we want to add more images to the above block, it would automatically add columns (or creates a gallery) for it. Add 3 images makes it a 3 column gallery. So depending on the input, display the correct output (side thought: anyone thinking of adding AI to this).

Here’s an example of how 2 columned texts would look like in a block.

So depending on the content/context, a CMS editor must not limit us in any way. Custom content blocks or widgets in Netlify CMS are amazing for this.

Using the editor without the mouse, ever.

The only enjoyable thing when using the mouse while writing should be clicking on the Publish button 🙂 And with that in mind I’ve been thinking how to improve the user experience throught everything mentioned above. How would we achieve navigating the UI and add content blocks by just using the keyboard but also not using any CTRL or ALT combos? Well, we go for the obvious key that we’re using all the time but can be used for much more than just the thing it’s doing. Yes, it’s the Enter/Return key.

You’re probably asking yourself how can you navigate the full UI with just one key that is already used to paragraphs or line breaks (enter and shift+enter). Well, I think with the help of React and JS we could extend the usability. Here’s a short video explanation of how it would work. The right side shows the key inputs used to navigate.

From the video above the legend of the navigation would be:

1x enter -> new paragraph
2x enter in succession -> open block list (same as clicking the +)
space -> select the block layout

This should work nicely for the 1st pass of writing, for the second pass of editing, it’d still be nice to use the mouse as it makes the jump from words to words easier.

I think this is something that was overlooked with all the Editors we have today. We always try adding new things instead of doing the basics really good (oh wait, isn’t that the JAMstack philosophy also?).

Canvas with placeholders for inputting information and data

For the example of using the Editor for layouts that are predefined with blocks depending on the context (job posting, real estate posting,…) A bit of setup in the JSON config file would do the trick to create the template layout.

Add a collection and you have a controlled placeholder for specific content needed for that section.

Conclusion & next steps

It’s been a while since I tried to solve a problem or find a new solution to something like this and I must say that an editor seems like an “easy thing to do” but digging deeper it has a lot of small gears that make everything work, the process if analysed in depth is quite complex but I love how things come out simple at the end and seem intuitive.

There is still more things to think about like the mobile execution of this concept or the idea that do we still need the preview if the content is shown in a straight path?

I guess the next steps (maybe a part 3?) would be to wait for feedback and revise and improve with the help of the community while enjoying the development of Netlify CMS.

Headless, But Not Brainless Web CMS

Thu, 22 Jun 2017 00:36:54 GMT

The biggest downfall of headless systems is the fact that siloed systems don’t share nicely PHOTO: Dane LowWith the rising buzz of headless CMS, comes the rising misunderstanding that CMS systems must fall into one of two categories: fully headless systems that require a from-scratch build for every new touchpoint, or page-based systems that are locked into desktop websites.

This, of course, just isn’t true. In fact, your options range across a whole scale of solutions, such as Experience-as-a-Service, where your CMS controls partial-page rendering, or Hybrid CMS, solutions that let you push your content to any channel — just as headless systems do — using a delivery tier that connects all those channels and shares data between them. Think of it as letting your experience work headless, without losing its brain.

Headless CMS Creates Siloed Islands ----------------------------------- If you think of your digital experience as an island — with visitor engagement onshore, and the pipelines of content and data running underneath — a headless system requires you to build a new bridge and intricate new data pipelines every time you want to add a new visitor channel, be it a microsite, mobile site, in-store display, intranet, etc.

This creates many siloed islands that don’t easily communicate with each other because each one requires individual maintenance and upkeep.

Hybrid CMS Builds a Connected Experience ---------------------------------------- The freedom to experiment quickly with new customer touchpoints is imperative for innovative businesses, and so is the connectivity that lets a cross-channel experience share content, assets and data to create one consistent feel across the entire experience.

This is where Hybrid CMS solutions come into play. Instead of tediously creating multiple bridges for every new initiative, you just expand your island, thereby easily supporting new touchpoints that can directly share the content and data with your entire digital landscape.

Silos Are the Death of Personalization

The biggest downfall — and biggest risk — of headless systems is the fact that siloed systems such as touchpoints, teams, assets and third-party integrations, don’t share nicely. At a surface level, this can cause a fragmented customer journey, since the lack of shared assets across touchpoints causes each one to look and feel different. That’s because they aren’t updated in unison and often have different messaging.

It’s a broken experience, and it’s simply not competitive when it comes to serving today’s channel-agnostic customers.

What’s more, under that metaphorical water, where all the data and content lie, these headless siloes are upsetting an even bigger beast — personalization. That’s because cross-channel personalization requires the constant communication of data between the touchpoints and third-party applications such as CRM and transactional platforms.

This is where personalization often comes to a staggering halt in purely headless scenarios.

True Flexibility Means Flexibility for All ------------------------------------------ The reason headless is getting so much hype is its promised agility when adapting to new touchpoints. In reality, though, what often ends up happening is that businesses create many separate integration points that become difficult to maintain.

This makes it hard on the developers, who must constantly keep an eye on the functionalities and templates of every integration, as well as the marketers, who must recreate content for every separate touchpoint. Not to mention that, without a presentation layer and the preview option it provides, content displays often become shots in the dark, making for some risky publishing.

Storing content independent from presentation is a great way to be open to experimentation with new channels, but if every update to these channels requires multiple rounds of back-and-forth between marketing and IT for every small change, you quickly lose the flexibility promised by headless solutions.

That’s why Hybrid CMS systems that keep content and presentation separate, but also have a cross-channel delivery tier built in, are so powerful. Content can be used in a format-neutral way that makes developers happy, but also supports content marketers who want to share assets cohesively across every channel.

If You Build the Software, You Become a Software Company -------------------------------------------------------- Companies jump into headless scenarios thinking, “Yes, this is great! We will build the delivery tier with the exact templates for the exact channels we want.” However, they quickly come to realize that if they are the ones building the software, they are also the ones maintaining it.

That means every bug fix, every update to customer demands or marketing needs, every API for new touchpoints — plus all the standard maintenance — becomes the responsibility of your development team, thereby burdening them with these tasks and turning them into maintainers of your delivery tier instead of innovators for your actual business.

And along with that continual in-house maintenance, building your own system means your developers must take into account all of marketing’s requirements, too. Template creation and upkeep will now fall into the hands of your development team, so stop to consider that every small tweak marketing would like to make, even something as simple as changing font sizes or colors, will now need developer intervention.

For global companies, that ability to translate content easily will need to be built from the ground up. Additionally, for companies with multiple content contributors and editors, development needs will include creating workflows with the appropriate permissions.

Lose Your Head But Keep Your Sanity ----------------------------------- For businesses accustomed to rigid page-based CMS systems, it’s no surprise that headless solutions seem like a breath of fresh air — and they are. The freedom to publish content independent of presentation is vital to building exceptional experiences across channels, but it’s vital to keep in mind that this headless-style flexibility can be accomplished while keeping your brain and going hybrid. Hybrid systems keep your content flexible, but unlike purely headless systems, keep that content connected across channels.

In a world with an ever-increasing number of customer touchpoints and business technologies, the ability to share content, assets and data across channels is exactly how a CMS should work. That’s why businesses aiming to create engaging, personal experiences for their multi-device customers need a solution that offers the content flexibility of headless architecture, together with the data connectivity that puts cross-channel intelligence at the heart — and in the head — of the digital experience.

Tjeerd Brenninkmeijer is the CMO of BloomReach EMEA. He is a frequent contributor to industry publications and a speaker at industry events.

5 Ways To Maintain Brand Consistency As You Grow Your Business

Mon, 19 Jun 2017 09:42:47 GMT

If you’re like many leaders, the early stages of your business required a lot of decision-making, from fundamental decisions like your core services or products all the way to decisions about design. Whether you put a ton of time into each and every choice or quickly call the shots to move on to the next one, it’s safe to say that your business evolves — and as it does, the look and feel of your brand can change, too.

If you could get your hands on it, you probably wouldn’t even recognize Influence & Co.’s first logo. Graphics, colors, fonts, logos, and messaging change over time, and that’s normal. But after a while, the customers who stay with your business year after year expect a certain look and feel. With 90 percent of buying decisions made subconsciously, that consistency is key to quickly and emotionally connecting with customers as your business grows.

Brands like Coca-Cola and Nike have managed to maintain consistency over decades in business. Even with subtle changes in design over the years, there is a basic look that remains consistent.

But your brand is more than a logo. It’s everything that represents your company, from your personal branding and the content you create to your mission, the employees that humanize your brand, and everything in between. As you grow your company, maintaining your brand’s consistency can be a challenge. Here are six tips that can help:

1. Understand your mission.

From the start, your brand image should be tied to your core values, which often relate specifically to what you want your venture to do for your audience and become over time. Even if you already have a logo and have designed your company website, you can make small tweaks to ensure your branding sends the right messages to your audience members about what you do and what they can expect if they engage with you further.

You might even be able to drastically change your logo once, but if it happens much more than that, you’ll risk appearing flaky. Put your mission statement and core values on paper, and conduct an audit to make sure your visual materials align with them.

What to Consider When Purchasing a Web CMS

Mon, 19 Jun 2017 09:26:43 GMT

So many factors go into the decision to buy or upgrade a web CMS: which should you focus on? PHOTO: Chloe RidgwayChoosing a web CMS is one of the biggest decisions a brand can make.

In 2017 and beyond, a content management system is no longer just the software you use to manage your website. Any CMS worth its weight is also able to leverage visitor behavior and data to shape customer journeys and deliver tailored content to multiple audiences across channels.

In short, a modern CMS is the primary link between a brand and its customers. Thus, it’s now more vital than ever to avoid going home with a lemon.

The only problem is, how do you go about choosing the best CMS for your brand?

The Question

What’s the most important factor in the decision to purchase a CMS? Is it price, functionality, architecture or something else?

The Answers

Karol Jarkovsky, Director of Product at Kentico
Jarkovsky has been working in product management, global software development and customer success for more than a decade. He recognizes the opportunity that businesses have to digitally transform themselves in order to survive and thrive in today’s highly competitive environment, and has committed himself to helping develop the disruptive technologies that make such transformation possible. Tweet to [@kentico\karolj](https://twitter.com/kentico_karolj)_

While all of these factors are important to consider, we believe organizations should pay equally close attention to two additional factors.

First is omnichannel experience management, and how effectively is the organization able to produce and manage content for various channels. Not just web or mobile, but also social, IoTs, VR, AR, voice assistants and others.

The second one are the microservices architectures organizations need to consider when building future-proof digital marketing technology stacks. This can help organizations be flexible and agile in fulfilling complex business needs through seamless integration of multiple best-of-breed solutions.

David Roe, Partner and CEO of Authentic
Roe founded Authentic because he saw the massive amount of potential in the Content Management market to align customer wants with client’s business needs using new methods and digital marketing technologies. He believes very strongly in the value of helping clients create “Authentic” relationships with their customers. Tweet to @authenticDgtl

The most important factor that should be considered in the purchase of a CMS is the facilitation of contribution. The focus should be on the actual contributors and the usability of the platform. If it isn’t used properly, it could be a point of failure across the board.

A well-designed CMS should enable the people who have their hands on the keyboard as they will always be your biggest success factors.

Boris Kraft, Chief Visionary Officer at Magnolia
Kraft is the co-founder and Chief Visionary Officer at Swiss-based Magnolia International Ltd., the company that develops Magnolia CMS. He has been writing code for 25 years and is a renowned public speaker. Kraft’s responsibilities at Magnolia revolve around the future of the company, the product and the CMS market in general. Tweet to @bkraft

A flexible product is your best bet to minimize business disruptions required if you need to replace your “can-do-everything-you-need-today CMS” with whatever you need next year. Every organization needs a CMS. So the decision is not if you need one, but what you want or need to stay in business. If your chosen CMS makes it easy to innovate and adapt, provides an inspiring user interface to foster creation of great content and comes with the tools you need, backed by a passionate support and development team, you are off to a great start.

As content marketing is driving business revenue, price should be irrelevant — it is value that matters. Content can come from many sources, including from the traditional notion of a CMS, but needs to be mixed, tagged, targeted, translated and generally turned into something useful. That is much harder than one might think.

You can get tons of free (as in “no license cost”) CMSs, but that doesn’t necessarily mean they help you win the innovation war. Functionality certainly is very important. Even though many CMS’s provide broadly speaking the same base functionality, the difference in what they were built for and how they perform in real life is massive.

Abhay Kumar, Vice President of Business Development at Priocept
Kumar has over 17 years of experience working on various IT, digital media, ecommerce and web application development projects. As a Project Manager at Priocept, Kumar oversees the designing, building and deployment of web technology platforms for some of Europe’s leading companies. Find him on LinkedIn

The slightly unsatisfactory answer is that the most important factor is subjective to each individual organization based on their differing requirements, experience and technical skills.

Technical capabilities is the one factor we focus on. Have you considered the technical implications for your creative vision? Who is going to build it? Support it? Do you need all the bells and whistles — or is simplicity better? Starting from a solid technical spec increases the likelihood of success.

Certainly one of the least important factors is price. In life, some things are reassuringly expensive such as a child car seat or breakfast tea. In these cases price ensures the quality of the product, but it doesn’t guarantee the happiness of your child in transit or the enjoyment of your first meal of the day. Similarly, investing heavily in a complex CMS doesn’t guarantee the success of a digital platform.

Tim Brigham, CEO of dotCMS
Brigham is a seasoned â€‹entrepreneur and “bootstrap executive” withâ€‹ â€‹more than 20 years of experience in creating and building digital content and software companies. He co-founded dotCMS in 2009 and has helped grow it into an award-winning open source CMS. Tweet to [@Its\DaKine](https://twitter.com/Its_DaKine)_

__While factors like price, functionality and architecture are important, the marketplace is now more experienced than ever before when it comes to content management systems.

Customers already know what they want and prefer to dig deeper into other aspects of the CMS, such as the product roadmap and strategy, customer success approach, and yes, even customer-vendor compatibility.

7 Reasons to Ditch Your CMS and Consider a Static Site Generator

Mon, 19 Jun 2017 09:18:26 GMT

For many years, publishing a website was out of reach many users. HTML authoring, hosting accounts, and managing the update of the hosted files was too much for average non-technical folks. Nowadays a user can sign up for a Tumblr account How To Easily Create a Blog with Tumblr How To Easily Create a Blog with Tumblr Read More and be typing their first post within minutes.

As users became more sophisticated, blogging platforms like WordPress provided ownership of their content. But WordPress and its peers still have a number of moving parts. This is overkill for someone who just wants to blog while still owning it. A recent answer to this is the static site generator (SSG). Let’s explore why you might want to consider one for your next online project.

What Is a Static Site Generator?

The first pages on the Web were just that: individual pages that someone wrote as an HTML file and uploaded to a server. While a modern CMS (Content Management System) presents content as a page, in reality it is mashing up markup, database content, and real-time calculations. They are web applications that help users create content, store it, then serve it up to site visitors.

In contrast, static site generators are publishing tools. They’re not so different from tools like Adobe Acrobat, which takes an editable format (e.g. Microsoft Word) and converts it to a format 7 Free Online PDF Tools That Could Save You A Lot Of Work 7 Free Online PDF Tools That Could Save You A Lot Of Work The Web is full of awesome little tools that can help you alter PDF files without breaking a sweat. Let’s look at lesser known PDF tasks that may come in handy for you. Read More that’s easy to consume (.PDF). In this case, SSGs are doing the following basic tasks:

Taking some sort of basic content as input;
Creating nice-looking web content from it, and;
Helping to push that content live to the web.

In the next section we’ll examine some of the advantages the “static” nature of SSGs provides over today’s CMSs.

Advantages of Using a Static Site Generator

For those used to working in a CMS like WordPress, some of the following will seem like a big change. But they make producing and maintaining some types of sites a lot easier. Let’s take a look at some of these advantages.

The below sections include commands and output from the Jekyll static site generator as an example. If you select a different SSG, the commands will be different, but the concepts are similar.

1. Static Sites Don’t Require Complex Installations

A major difference compared to a “traditional” CMS is that you’re installing static site generators on your local machine. For example, getting Jekyll up and running on an Ubuntu machine was as easy as the following command:

sudo apt-get install jekyllThen just start up a new project:

jekyll new mytestsiteYou’ll have the makings of a new site in the “mytestsite” directory with a number of default files. Take note of the “_posts” directory, which contains a Markdown file.

2. You Can Work on Your Site While Offline

Static site generators are designed to work with offline, local content. There’s no need for a live internet connection to create a new post. You can draft the content, then run a “build” command later to create the post/page that will make its way to the Web. If you’re used to offline blog editors such as BlogDesk 4 Alternatives To Windows Live Writer For Blogging 4 Alternatives To Windows Live Writer For Blogging Microsoft recently announced the end of the Windows Live brand. In response to concerns, all Microsoft is saying about Windows Live Writer is it will “work great on Windows 8” – not whether development is… Read More it’s similar, except instead of pushing posts one at a time, you’re building the whole site locally.

Next, create your content in the “_posts” folder mentioned above. You can build your site when you’re ready by executing the following command from the project’s directory:

jekyll serveThis builds the entire site in a sub-folder, as shown below:

When complete, you can also view this site using Jekyll’s built-in web server at .

If you like what you see, you can simply upload all the files in the “_sites” folder to a web host What Is a Web Server? [MakeUseOf Explains] What Is a Web Server? [MakeUseOf Explains] If there is one thing that causes the most confusion for people that are new to the web design game, it’s the concept of a web server. When most people think of a “server”, they… Read More . Your site is ready to go!

3. You Can Author Content in Different Formats

Also, you’re able to create those posts in a format friendlier than raw HTML. Markdown is the most well-supported, but many SSGs can also accept others either out-of-the-box or via a plugin. Jekyll’s plugins include options like Asciidoc, orgMode, or reStructuredText. If you’re using one of these other markup languages, a quick config change or plugin install should be all you need.

Image Credit: GitHubInterestingly, most SSGs also accept HTML as an input. “Wait,” you’re saying. “I thought converting to HTML was the point of this whole thing!” But consider this: other formats not directly supported by SSGs can often export to HTML. Imagine a workflow where you (or other writers) author in LibreOffice using ODT, which gets converted (such as via Pandoc How to Easily Convert Between Document Formats in Linux How to Easily Convert Between Document Formats in Linux Switching to Linux can result in problems with file compatibility. For instance, documents don’t look the same in LibreOffice as they do in Word. This is just one reason why you need pandoc. Read More ) to raw HTML, which is further processed and styled by the SSG. It would take some elbow grease, but it’s entirely possible!

4. You Can Still Benefit From Themes and Plugins

As mentioned above, most SSGs also support extensions or plugins to provide extra functionality. This range from automatically adding data to the site (e.g. date-based URLs for or related posts) to more “CMS-like” features like user authentication or comments. One plugin for the DocPad SSG even provides an administration panel!

Image Credit: npm### 5. Static Sites Are Fast

Between fetching content from the database and running any included code, loading some CMS pages can be sluggish. In contrast, static sites are already in the format the browser will consume. The only delay is in how long it takes the web server to send the page, and how long it takes the browser to render it How Do Browsers Display Web Pages, and Why Don’t They Ever Look the Same? How Do Browsers Display Web Pages, and Why Don’t They Ever Look the Same? Read More . But these are both things a CMS-driven site would also have to do.

In addition, since the output of SSGs is run-of-the-mill HTML, CSS, and Javascript. Just about any web server will serve these (along with any images) without issue. This means if you have your own server (such as a VPS), you have the flexibility of deploying a lighter web server like lighttpd or nginx The Best Linux Web Server Software (& Apache Alternatives) The Best Linux Web Server Software (& Apache Alternatives) Read More .

6. Static Sites Are Secure

The multiple moving parts of CMSs like WordPress, Drupal, and others open up attack vectors for the villains of the Interwebs. Access to a PHP file can allow an attacker to execute their own code on your site. A compromised database has led to headaches for e-commerce vendors The Sorry State Of Personal Data Security In E-Commerce The Sorry State Of Personal Data Security In E-Commerce Many of these retailers owe their entire being to the Internet, yet are incapable of following even the most basic of good data practices. Read More (as they’re in really a more sophisticated CMS).

@briancroxall perhaps missing: security much easier with static site generators.

— Martin Paul Eve (@martin_eve) March 25, 2017

On the other hand, all the programming magic of SSGs happens on your local machine. Thus, your biggest concern will be file permissions. Accidentally making a file writable to the world One Of The Most Important Tools In Linux - Understanding Chmod One Of The Most Important Tools In Linux - Understanding Chmod There are plenty of features that make Linux special, but one of them that makes it so secure is its permissions system. You can have fine-grain control over all the files in your system and… Read More would be a “bad thing,” but this is something that could happen to a CMS as well. However, since a static site doesn’t have any executable code within it and doesn’t access database content, it reduces the number of potential holes in your site’s security.

7. Static Sites Aren’t Subject to Live Upgrades

If you’ve ever managed a site, you know the moment of dread that comes along with seeing that “Upgrade available!” message in your admin panel. Sure, you’ll test it in your staging environment, but you never really know if that one code fix or oddly-formatted user comment will make it all blow up.

Compare this to static sites. Although new versions of the SSG tool may be available, these don’t impact anything on your live site. It will continue to chug along, oblivious to any upgrades that may or may not have happened. In the meantime you can upgrade your SSG, publish a new version of the site to test it out, and finally migrate the new version live. The same can be accomplished with CMSes, but not without considering things like database rollbacks and whether new user-generated content will be lost.

Types of Sites Ill-Suited to Static Site Generators

Not all sites are a good fit for static site generators. If you’re putting together a small personal site, or something like a traditional blog (i.e. a daily journal), the simplicity of SSGs might be for you. Basically, if you’re looking for one-way publishing of your text-and-graphics content to the web, a static site is a good choice.

But most modern websites aren’t glorified online journals. If you will need any of the following for your site, now or in the future, you should consider the caveats that come with static site generators.

Registered users — If your site must allow users to sign up, such as to receive a newsletter, look closely at what plugins are available, and whether they allow the type of interaction you’re looking for.
Comments — Likewise, if you want people to be able to comment on your blog, you’ll need to look for a native plugin that fits your needs, or a service like Disqus 3 Commenting Systems & 3 Apps to Track Comments 3 Commenting Systems & 3 Apps to Track Comments Read More .
Multiple authors — If you need more than one person to write for your site, things get more complicated. You’d either need to make sure you pull their posts to your local machine before building your site manually, or via another method such as Dropbox, source control, etc. Not Just For Coders: Top Version Control Systems For Writers Not Just For Coders: Top Version Control Systems For Writers The mention of version control or revision control makes it seem like something for geeks. You will be surprised to know that version control systems have their place not only in academic writing but in… Read More
Data-driven pages — There are plugins that let you, for example, create a CSV file with data you can include in your page templates. But setting them up is somewhat complex, while at the same time providing less functionality than a full database.
Highly interactive features — If you’re hoping to re-create Google Maps or Docs with one of these tools, you’re barking up the wrong tree.
E-commerce — Static sites don’t lend themselves to the many and constantly-changing rules and properties (taxes, shipping rates) of e-commerce What Is The Best E-Commerce Plugin For WordPress? What Is The Best E-Commerce Plugin For WordPress? So I often hear the question: “what’s the best eCommerce plugin for Wordpress?” I think it’s only in the last year or so that a clear answer has emerged. Read More .

Overall, static site generators are publishing tools ideal for users looking for a straightforward way to create some content and get it ready for the web.

What do you think? Would you be willing to give a static site generator a spin? Think a CMS is still the way to go? Let’s discuss below in the comments!

Image Credit: mihalec via Shutterstock.com

CMS Static Websites

Wed, 26 Apr 2017 03:00:00 GMT

You are most likely familiar with Wordpress to build a website. Wordpress is using what is called in technical terms the LAMP Stack. Static websites are using the JAM Stack. JAM Stack stands for JavaScript, APIs, & Markup; it’s an approach to building websites that allows you to have all the web performance and security benefits of a static website along with the dynamic capabilities of a database-driven CMS.

Problems dynamic websites build with f.ex. Wordpress are facing

Let’s start with web performance. Regardless of how well we optimize everything or how good of a job we do with with perceived performance, dynamic websites are SLOW. This is due to the amount of steps that have to take place in order to display the requested content everytime someone visits a web page. We’re also at a point where every website being built on Wordpress is being overwhelmingly loaded with plugins, scripts, and a ton of other overhead that just slows the crap out of what we ship to production. This is in addition to security concerns, expensive hosting, and the ever-changing landscape of different languages a developer must learn to build a website. So let’s rethink our approach to building dynamic websites and start from scratch static.

How Static Websites Differ

First, what’s a static website? Nope, not a new technology, static websites have been around for ages. That Dreamweaver website you created back in college? That’s a static website. A website made up of HTML pages with pre-populated content. When a browser requests the URL of a static page, the server returns the static page in it’s entirety. There aren’t calls to a database being made nor content being generated on the fly — the content is already there. That doesn’t mean we’re putting together every page by hand . There are different tools that address different layers of this technology stack.

Faster loading times

The fact that JAMstack websites don’t have to make any calls to a database makes the loading time exponentially quicker. Matt Biilmann, founder of Netlify, ran a test of the Smashing Magazine website (which currently runs on WordPress) against a static counterpart he cloned and deployed on Netlify. It resulted in a website that loaded six times faster than the original.

Solid Security

If you’re using a popular CMS, you know about the necessary security measures. This is mostly due to the login page being available to anyone with access to the website and some basic knowledge of the specific CMS. With a static website, a login page doesn’t exist. If you do integrate a headless CMS (more on what a headless CMS is further down) to your static website, tracking the website back to its CMS isn’t as straightforward as it is with a traditional CMS.

Front-End and CMS are Decoupled

You don’t have a CMS dictating the way you should structure your content and pages. Not having a CMS tied in to the presentation layer gives you the flexibility of creating anything you want on the front-end while using the API endpoints to pull in content.

Lower cost of scaling

We’re not dealing with expensive runtimes or complicated server setups — we’re only dealing with static files being served on the client side. For smaller sites, you can get away with cheap hosting as long as you pair it with a fast CDN.

Seamless developer experience

From the developer’s perspective, the JAMstack methodology doesn’t require us to learn a different backend language to build a data-driven website. We’re able to build on our foundation of HTML, CSS, and Javascript to build complex websites.

What Steps to take to take to build your Static Website

Step 1: Choose a Host & CDN

The beauty of static websites is that you’re able to host them anywhere. ANYWHERE. You don’t need a list of server requirements with a certain version of PHP or a specific database. All you need is a host that allows you serve HTML, CSS, and JS for a straightforward development workflow, especially when dealing with staging environments. I recently started playing around with the idea of moving to Amazon Web Services. I zipped up my website, uploaded it to their server, and boom, my website was ready to go live by just pointing the DNS. Because my website is static, I didn’t have to worry about transferring a database or server requirements. (It took me about 10 minutes to set this up.) Although you are going to enjoy the flexibility (and affordability) of hosting, specially with larger scale websites, you want to make sure that you’re using a host with a fast CDN to deliver your static files. You have a bunch of options:

Netlify

Built from the ground up to host modern static websites, Netlify (they actually coined the term “JAMstack”) understands the static concept and provide a full suite of open source products that are focused around static websites (sorta like the WP Engine of static websites). They’re also the hosting platform behind the new redesign of Smashing Magazine. Plans are relatively affordable but if you have an open source project, they’ll host it for free.

Amazon Web Services (AWS) S3

Amazon S3 is a utility storage service that’s used for backups and content storage as well as static websites. This is an ideal hosting setup for a JAMstack website. If it’s your first time creating an AWS account, they’ll provide free hosting for the first 12 months.

WebriQ

Using the full capabilities of the Netlify network, WebriQ provides you with a fully self-contained Software-as-a-Service for building and managing your Static Websites. Building tools, content management tools, continuous deployment through Github, SSL certificates are just a couple of important features that come standard with any service. Pricing is quite affordable and starts at $15 per month for a fully managed service. Free service is available at WEBRIQ APP

Step 2: Decide on a Static Site Generator

In order to avoid creating static html pages manually, you’re going to need a sturdy static site generator. There are 457 static site generators to choose from. But I’ll help you narrow down the list to the top three contenders below.

Jekyll

Built on Ruby and using Liquid as a templating engine; Jekyll was created eight years ago when Github founder, Tom Preston-Werner, was looking to write his own blogging engine. A very well documented SSG with the support of a massive community. It has been the de facto choice for static site generators since static websites began regaining popularity around four to five years ago. Although Jekyll is simple to setup, the workflow begins slow down when working on larger websites; static pages will still load fast once on the server, but the time for them to get generated locally during development starts becoming painful.

Hugo

Built on GoLang using it’s own templating engine; Hugo was created in 2013 by Steve Francia, Docker’s Chief Operator. Although relatively young, Hugo has the support of Smashing Magazine and its immense community; Smashing Magazine announced that they would be ditching WordPress for Hugo in the new iteration of their website. The main reason for choosing Hugo as their SSG was the speed in which Hugo generates its pages. This was something that co-founder, Vitaly Friedman, needed to carefully take into consideration for the large number of posts the website has published since 2006.

Roots

Why is WebriQ using Roots?

As awesome as Static Site Generators are, there are a few problems rooted in the fact that it gets a bit complex for the everyday admin user that’s just looking to publish content. It’s unrealistic for us in the agency world to get non-technical team members and clients to publish content and deploy websites via CLI. In order to make this appealing to the masses, we need a dynamic layer in our current stack that provides a friendly admin UI…

Step 3: Select a headless CMS

Choosing between a Git-based CMS or an API-driven CMS

Or use WebriQ CMS, which in essence can be an API driven Git-based CMS.

Exciting times for all front-end developers and for business owners who want to simplify their web operations with secure, reliable and ultra fast technologies.

Progressive Web APPS - Next step in Responsive Web Design

Mon, 24 Apr 2017 16:00:00 GMT

Honestly, I didn’t think much of it. Progressive Web Apps are for the hardcore web application developers creating the next online cloud-based Photoshop ?

Then, I saw CSS wizard, Harry Roberts, tweet about making some setting changes in CloudFlare and achieving the same. It might have been a coincidence that I stumbled across two influencers discussing the same topic, but it still caught my eye. So out of curiosity, I installed Lighthouse, the Chrome plugin that both Smashing Magazine and Harry Roberts had used, and ran my website through it.

Initial Lighthouse Audit I wasn’t too impressed with the results. I figured I’d look into this, write about it, and save any developers who stumble across my website a bit of time. But I was really surprised with what I found.

I sought out to see if PWAs could benefit the work I do daily with content marketing websites, and I was able to reach 100/100. You’ll see exactly what I did toward the end of this article, but I figured while I’m here, we could walk through it together.

To begin, let’s get on the same page and define exactly what a PWA is. Google says:

Progressive Web Apps are user experiences that have the reach of the web, and are:

Reliable - Load instantly and never show the downasaur, even in uncertain network conditions.

Fast - Respond quickly to user interactions with silky smooth animations and no janky scrolling.

Engaging - Feel like a natural app on the device, with an immersive user experience. This new level of quality allows Progressive Web Apps to earn a place on the user’s home screen.

In other words, a PWA is the in between of a native app and a website. Using new technology being shipped with the latest browsers, we’re now able to create web apps, or in this case websites, that feature similar functionality as native iOS & Android apps (push notifications being a popular one).

The beauty of it is that we don’t need to be on a specific platform to be able to install a specific app — we just need a URL to point our mobile or desktop browsers to — but it is also one of the most challenging aspects of PWAs because ANY browser on ANY device could access the web app.

This means that we’ll be catering to users that probably won’t have the latest version of their browser with the latest features that you’re using. And that’s OK.

PWAs are built with the core principle of the progressive enhancement. This means the app/website will focus on the core content or purpose, and it will use the latest and greatest features as an enhancement to the experience and not as a requirement. It won’t break or render useless if a specific feature isn’t available in the browser/device accessing it.

Why Your Website Should Be a Progressive Web App Although you probably won’t be using any hardcore app-like features for your website, there are a handful of enhancements, such as offline accessibility and native browser notifications, that will immediately improve the overall usability and engagement of your audience. It’ll result in higher conversions and lower bounce rates.

There’s even more to it:

Offline Accessibility with Service Workers

Using service workers, we’re able to “download” your website for offline use. Even with our tech-savvy way of life, there are plenty of use cases for this — subway riders with no internet access reading your blog, plant managers with spotty wifi looking up specs, those driving into more rural areas, etc.

Native Browser Notifications

If the website validates as a PWA, certain browsers take the initiative of displaying notifications such as offering to add the website to the home screen of the user — the PWA equivalent of installing an app.

Enabling Push Notifications

Push notifications are every developer and marketer’s favorite native app feature. When leveraging the Push API, you have the ability to re-engage your audience even when your website’s not being accessed.

Performance

With service workers, we have granular control over caching static assets, which reduces network requests and results in improved performance.

Google Likes it

If Google supports something, pay close attention. It won’t be long until Google starts favoring PWAs in certain search results. (You heard it here first!) Right now, there isn’t any evidence showing an increase in traffic; however, early adopters are usually the ones to reap the benefits.

Criteria for Progressive Web Apps Your website has to meet a baseline of standards in order to benefit from the PWA perks, but these are best practices you should already be considering and implementing on your website. If not, listen up.

Site is served over HTTPS

This is the secure version of your website. Sending information over HTTPS ensure any data that’s being passed through your website gets encrypted. Yes, even if your website is a simple content-based website with no complicated features, you want and need HTTPS (lots of bad hombres out there).

You can test for this with Lighthouse or just look at the address bar of your website and if the URL starts with https:// and not http://, you’re good to go. I use CloudFlare CDN, which makes it relatively simple to enable HTTPS.

Pages are responsive on tablets & mobile devices

By now, everyone should be building on a responsive foundation. Do I even need to elaborate here? Thinking no, but let me know otherwise.

The start URL (at least) loads while offline

Your home page URL needs to be able to load if you don’t have access to the internet — use service workers (not as difficult as it sounds) to help. (I’ll show you how to do this shortly.)

Metadata provided for add to home screen

Mobile browsers need basic information about your website such as an icon to represent your website on the home screen of a device, a short name (what gets displayed below your icon) and a browser theme color to match certain parts of the browser to the colors of your website (among many other options).

This gets accomplished through the web app manifest file, which is a simple JSON file that contains all of the specifics. (Again, I run you through setting one of these up toward the end of this post.)

First load is fast even on 3G

Your website needs to render fast. It should load within the first 4 seconds and get a 85+ PageSpeed Insights score as a minimum. I recently wrote an article on website speed performance, which goes over a few basic steps you can take to make sure your website loads pretty darn quick.

Site works cross-browser

Every single feature doesn’t have to work on every browser but being able to progressively enhance and using fallbacks where necessary should be the foundation of your website or app. Don’t target a specific browser or OS for your website/app to work on — it’s a big negative that goes against the progressive principle.

Page transitions don’t feel like they block on the network

Going from page to page should be a seamless experience — any type of render blocking delay deters you from achieving that. There are many ways to address this from making sure your website’s fast (two steps above) and using perceived performance techniques such as Critical CSS.

Each page has a URL

If you click on a page, make sure the website URL reflects that. Single Page Applications sometimes forget this and make it pretty difficult to share content across the web.

Seems like a handful of steps, but if your website is already built on a foundation of best practices, it won’t be much work to have it validate.

Most of our Buzzin Community websites adhere to all the best practices of Progessive Web APPS.

Wordpress hacking spree sees more then 1 million web pages defaced

Mon, 13 Feb 2017 16:00:00 GMT

A security flaw in the WordPress blogging software has let hackers attack and deface tens of thousands of sites. One estimate suggests more than 1.5 million pages on blogs have been defaced. The security firm that found the vulnerability said some hackers were now trying to use it to take over sites rather than just spoil pages. WordPress urged site owners to update software to avoid falling victim. Feeding frenzy. The vulnerability is found in an add-on for the WordPress blogging software that was introduced in versions released at the end of 2016. Security firm Sucuri found the “severe” bug and informed WordPress about it on 20 January. In a blogpost, WordPress said it delayed going public about the flaw so it could prompt hosting firms to update their software to a fixed version. The patched version of WordPress was formally released on 26 January and led to many sites and blogs automatically applying the update. However, many blogs have not followed suit leaving them open to defacement attacks. Security firm WordFence said it had seen evidence that 20 hacker groups were trying to meddle with vulnerable sites. About 40,000 blogs are believed to have been hit. The vulnerability had set off a “feeding frenzy” among hacker groups, WordFence founder Mark Maunder told the Bleeping Computer tech news site. “During the past 48 hours we have seen over 800,000 attacks exploiting this specific vulnerability across the WordPress sites we monitor,” he added. Sucuri said some hacker groups had moved on from defacement to attempts to use the bug to hijack sites for their own ends. “Attackers are starting to think of ways to monetise this vulnerability,” wrote Sucuri founder Daniel Cid. “Defacements don’t offer economic returns, so that will likely die soon.” Hackers were keen to use the vulnerable sites as proxies for spam or malware campaigns, he said.

With the rapid evolution of websites being build on Static website generators, and hosted on CDN networks versus servers, the whole issue of hacking and security fixes should go away altogether. At WebriQ we have built a tremendous technology platform enabling anyone with basic HTML knowledge to build a custom made website associated with a custom Content Management Software to update your entire content on the fly. Gone are the days where you needed knowledge of database set-up, plugins, server side scripts and all these complex background exercise that you never use as a website owner. Partner with WebriQ and find out how you can build and manage websites without the fear of being hacked and loosing all your hard work to make your website look the way it does. Gone are the days where you had to worry about databases and servers that could simply ruin the set-up of your website.

Nice examples of websites being build on the WebriQ platform are Buzzin Brisbane North, Mango Hill Tavern, Gas Certificate and Madcrane .

CMS-functionality for static websites

Tue, 03 Jan 2017 16:00:00 GMT

The case for the static site generator

More and more developers are jumping on the “go static train”, and rightfully so. Static pages are fast, lightweight, they scale well. They are more secure, and simple to maintain and they allow you to focus all your time and effort on the user interface. Often times, this dedication really shows.

It just so happens that static site generators are mostly loved by developers, but not by the average content editor. They do not offer WYSIWYG, previewing on demo sites may take an update cycle, they are often based on markdown text files, and they require some knowledge of modern day repositories.

A simple CMS system

The simplest way to update your content on a Static site is to use our single page web Javascript web app that writes data right in to a github repository. A straight forward Markdown editor that works pretty much like any WYSIWYG editor, let’s you publish, edit and manage all sorts of content. The content is directly written in to Github repositories, depending on you creating drafts or published posts. Each time you publish an update on the Github repository a new build will be triggered and your update will be published within seconds. The content model is based on Ember collections and can be adapted according to the specific needs of your website or Web APP. You only manage the dynamic data that you really want to manage. The repository is completely decoupled from your website, which renders itself as a Static website notwithstanding the fact that you can dynamically update and manage your content.

Content APIs is a more advanced option

An alternative is decoupling the content management aspect from the system. And then replacing the maintenance prone server with a cloud based web service offering. Effectively, instead of your CMS of old, you move to a Content Management as a Service (CMaaS) world, with a content API to deliver all your content. That way, you get the all the benefits of content management features while still being able to embrace the static site generator mantra.

A service that

from the ground up has been designed to be fast, scalable, secure, and offer high uptime, so that you don’t have to worry about maintenance ever again.
offers a powerful editor and lots of flexibility in creating templates for your documents that your editors can reuse and combine, so that no developers resources are required in everyday writing and updating tasks.
separates content from presentation, so you can reuse your content repository for any device platform your heart desires. That way, you can COPE (“create once, publish everywhere”).
offers webhooks that you can use to rebuild your static site in a fully automated fashion every time your content is modified.

How to automate using webhooks?

In order to be completely removed from everyday site management and maintenance, we suggest following the approach from Carrot Creative. In addition to an API driven CMS system, you will need a hoster that supports webhooks and is capable of starting builds and deploying websites.

On your host: Create a webhook endpoint that starts a new build and deploys a project whenever it receives a POST request.
On the CMS : Create a webhook with the host endpoint as destination URL. This way, whenever a writer creates or updates content, the host will receive a webhook and deploy. That way, a couple of minutes from publishing, the new content is live.

Getting started

Sign up to a WebriQ account now! There is free testing plan which will most likely suffice for most small projects. For bigger projects, you can upgrade to our PRO plan.

New features WebriQ CMS

Mon, 14 Nov 2016 16:00:00 GMT

A new Markdown Editor

A simple, beautiful, and JavaScript Markdown editor, that can be used by anyone. The WYSIWYG-esque editor allows users who may be less experienced with Markdown to use familiar toolbar buttons and shortcuts. In addition, the syntax is rendered while editing to clearly show the expected result. Headings are larger, emphasized words are italicized, links are underlined, etc. WYSIWYG editors that produce HTML are often complex and buggy. Markdown solves this problem in many ways, plus Markdown can be rendered natively on more platforms than HTML. However, Markdown is not a syntax that an average user will be familiar with, nor is it visually clear while editing. In other words, for an unfamiliar user, the syntax they write will make little sense until they click the preview button. The SimpleMDE implementation on our CMS system has been designed to bridge this gap for non-technical users who are less familiar with or just learning Markdown syntax.

Features of the new markdown editor

Autosaving – after two minutes of being idle on your browser, your work will be auto saved as a draft article or post
Spellchecker – spelling mistakes are highlighted
Mobile friendly – a bit difficult to write on a smartphone, but writing and updating your posts through a tablet is surely do-able
Multiple preview modes – markdown only, preview only and split markdown/preview
markdown guide

Other CMS enhancements

Draft articles or posts – all drafts wether it is a new post or a change in an existing post can be saved at all time. The drafts are in a separate Github branch for later publishing.
Discard draft – feature to go back to your original published post, discarding all changes made to the post
Unpublished – you can un publish existing post. Unpublished posts will be kept in a separate branch for later publishing if required
Published – new or existing posts can be published immediately and are put in to the Master branch of your Github account.
Further automation is expected to be on the platform in the latter part of this year, with notably calendar functionality, social media auto posting and integration with cloud based storage systems such as Dropbox and Google Drive.

Integration of Google Analytics

You can now integrate Google analytics in to our WebriQ APP. More details can be found on Google Analytics - Help

Is it time to give up on your WordPress site?

Wed, 09 Nov 2016 16:00:00 GMT

Nowadays WordPress has become extremely vulnerable to hacking because it’s open source and therefore really well-understood, runs something like 30 percent of all websites, and, given the huge range of third party additions (themes, plugins, etc.), ensuring any given installation is hacker-proof is pretty difficult. “Ah!” you might be muttering, “surely keeping WordPress and your plugins up to date is the answer?” Well, my friend, you might like to think so but it seems this latest wave of hacking WordPress may involve one or more zero day vulnerabilities. The scale and complexity of the WordPress ecosystem makes for what’s called a large attack surface.

But given the risks of getting hacked, which range from site defacement, through the theft of sensitive data, to becoming a source of malware to your visitors, you have to ask yourself if you still afford the time and effort to effectively secure your site and, even more importantly, if sensitive data could be exposed, can you afford the risk of remediation and possible litigation? Note that cyber-insurance, which sounds like a good hedge against disaster, may not work unless you can prove that you have exercised “due care,” something that may be tricky given the issues involved.

So, what’s the alternative? The answer could be a “static website” or “flat site”; i.e. a site that isn’t full of of databases and backend code but rather a bunch of static HTML, CSS, and client-side JavaScript that can be locked down and easily checked for unauthorized modifications.

There are a bunch of tools available to build and manage Static websites, and a good starting reference point is Static Generators.

At WebriQ we have put together a Modern Technology Stack for developers and content editors that is simplifying the many tasks at hand in building, managing, updating and hosting Static websites. It consist of a Static Web Generator specifically designed for business websites, all the tools to publish the code on Github and all the automation tools to continuously manage and update the website through Github commits. Last but not least, it contains an online Content Management System that deploys content changes almost instantaneously to your website.

Check it out on WebriQ APP

E-commerce Design Trends that Will Rule in 2017

Mon, 10 Oct 2016 16:00:00 GMT

Is it bad? Not necessarily. The same design concepts being utilized over and over again for the sake of keeping users happy: That’s good intent and sweet results for business owners, even if it means less conceptual diversity for designers and developers.

Now, as far as online store designing goes, here are 5 trends you can expect will be followed by everyone in the year ahead:

1. Card Layouts

You can thank Pinterest and every single template that used Masonry for this trend. Showing your products as Cards is something I can actively get behind, given its simplicity (of implementation) and users’ familiarity with the pattern.

2. A Different take on ‘Above the fold’

While a lot of us may have realized that the fold is a myth, that doesn’t stop many retailers from cramming all they can on the top half for that first glance. Only, instead of cramming forms up there, we have decided to use ‘above the fold’ area for capturing attention.

With carefully clicked and picked Hero Images, Sliders, Background videos, etc.

The trend is a conversion-friendly trend and it is catching up with e-commerce portals fast.

3. Material Design

By the end of 2013, we were at crossroads between flat and skeuomorphic design. We found the perfect solution in the form of Material design, and it is not going anywhere anytime soon. Everyone, including e-commerce stores, will be using the cleanliness and performance of flat with subtle enhancements of realistic design with abandon.

Here are some stores who are doing it right:

![Pottermore]( /img/uploads/pottermore.png )

“Not an online store, but the perfect example anyway”

4. Multi-channel done right

As the businesses change, so will the marketing trends and practices. 2017 is where multi-channel marketing and retail will truly take off as publishers and advertisers strive to create impactful, specifically targeted advertisements using advertiser data collected across multiple devices. This will help reduce advertising clutter on all devices.

This is to attract the tech-savvy millennials using a whole range of devices to shop.

Marketers were doing it through ads (targeted with geo-location) so far, but Facebook began giving out ‘Place Tips’ to businesses to digitize real-life experiences (or vice versa? I am not a retailer).

Basically: Even if Internet of Things hasn’t started to worry you yet, you should still prepare yourself to create more inclusive experiences as marketer and get ready to implement them as web developer and designer.

5. Pop-Up Marketing

“Reebok does popups nicely.”

“Visual confusion, bad popup, but good trigger (activates once you’ve read the content).”

God this one is catching on reallyfast, to everyone’s general annoyance. Every single online store I’ve visited lately showed me a pop-up before I even got a look at the products. No, sellers, I will not subscribe or register my email address with you (Well, not now that I know how desperate you are anyway).

Pop-up/interruption marketing to increase social shares or generate leads is gaining traction. But I have to say, if you must do it, do it nicely. Make it trigger delayed (page leave, cursor movement, time delayed, etc.), make the transition smooth (not abrupt as if you’re saying ‘Boo!’).

Try not to go for more than ONE popup per page; you can decide when to show it.

Bonus Takeaway

This is for the content people: Stock photos are dying out. Get ready to get creative with photography (Knolling, blur shots, anything else really), but make sure it’s your own so you get to get extra points for being a unique snowflake.

The Upshot

I’m not a fortune-teller, but my belief that these ‘trends’ will persist in the coming year is backed by the current opinions in web designer community.

You’re free to treat these as hogwash. Or share your own opinions for added enlightenment in the comments section below.

Bonne 2017!

**Author Bio:** Lucy Barret, a talented blogger and WordPress developer, currently employed at HireWPGeeks Ltd. She is an expert of [converting HTML to WordPress](http://www.hirewpgeeks.com/services/html-to-wordpress/) theme and has a team of skilled developers to assist her. Follow her company on [Facebook](https://www.facebook.com/hirewpgeeks).

Web Design and development Trends for 2017

Fri, 23 Sep 2016 16:00:00 GMT

Adopt a mobile-first approach

With mobile-phones now officially named as the primary devices used for browsing the web, more companies are realising the importance of having a site that effectively delivers content on a smaller screen. Content is designed to fit on mobile and smaller screened devices first, then you work up towards the larger-screened devices.

Wider implementation of Responsive Design

Very much in the same way as mobile first, the number of businesses that will implement a responsive design will still grow substantially. It keeps customers happy with an all-important user experience and it keeps Google search happy for the keyword rankings.

Focus on originality

Customers and users today seek authenticity from the brands they use, and stock pictures of creatives sat around a screen, or business men smiling just won’t cut it anymore. In order for a brand to really strike a connection with it’s audience, they’ll need carefully considered and completely bespoke visuals which are more representative of who they really are.

Bespoke illustrations, big and beautiful typography, and authentic photography are becoming real design differentiators.

Animations advance

Story-telling and personality is something more and more brands are working on to capture their user’s attention, and animation is starting to play a bigger role in this.

Animations come in all different shape, sizes and styles, and can all serve different purposes. Animations can range from tiny loading-devices which entertains the user while waiting for content to load, to an interesting hover-state used as a UX device to show a user they’re hovering over a link.

More card and grid UI

Cards, made famous by Pinterest are UIs where pieces of content (text,imagery, video) are broken down into individual ‘cards’ which the user is able to navigate through. Card UIs allow brands to show larger amounts of content on a screen at once. Cards tie in nicely with Mobile-First design and Responsive design with gesture based swiping.

Innovative scrolling and parallax

Scrolling, once reserved for getting from top of a page to the bottom, is being used in more creative capacities to deliver content online.

Scrolling is a versatile mechanic which can work great with all varieties ofcontent delivery. It works with video based content, where large full screen videos play and pause as the user scrolls, as well as static content, which can animate, move, or change depending on the users input.

Must have for 2017

As a business you may not be ready to implement all the trends mentioned. But what you must have going in to next year is a superfast, SSL secured, reliable and scalable website that is designed for Mobile-First. If not, your customers and Google will leave you behind.

Have a look at what WebriQ has to offer in the WEB DESIGN and DEVELOPMENT AREA

Differences between Static and Dynamic Websites

Sun, 18 Sep 2016 16:00:00 GMT

What is a Static Site Website?

A Static Site Generator is a compromise between using a hand-coded static site and a full CMS, while retaining the benefits of both. In essence, you generate a static HTML-only website using CMS-likeconcepts such as templates. The content can be extracted from a database but, more typically, Markdown files are used. These files are also the basis of the CMS system, enabling you to update any content on the fly.

The site generation can occur on your development machine or staging server. The resulting HTML files are then deployed to a live webserver. Users will never know the difference.

A related concept is a “Headless”or “Decoupled”CMS. These use an interface such as WordPress to handle content administration but allow other systems to access the data via a RESTAPI. One of the better implementations based on the Github Rest API, is WEBRIQ CMS.

Popular static site generators include Roots (used for WebriQ CMS) , Jekyll, Hugo and Metalsmith.

Major BENEFITS of STATIC WEBSITES

1. Flexibility

CMSs normally constrain your options, because they’re tied to a database with specific fields. If you want to add a Twitter widget to some pages, you’ll normally require a plugin, a short code or some custom functionality.

In a static site, the widget can simply be inserted into a file directly or using a partial/snippet. There are very few limits, because you’re unshackled by the those imposed by a CMS.

2. Better Performance

Most CMS applications offer built-in or plugin-powered cache systems to ensure pages are generated and reused when possible. This is effective, although the overhead of managing, validating and re-generating cached pages remains.

Static sites are pre-cached pages which never expire. Files can also be minified prior to deployment to guarantee the smallest load. A static site will always perform better than a CMS-powered version using a similar template.

3. Fewer Server-side Dependencies

A typical WordPress installation requires:

a suitable operating system such as Ubuntu or CentOS
a web server such as Apache or NGINX
PHP with associated extensions and web server configurations
MySQLor PostgreSQL
WordPress application
any necessary plugins
the theme/template code.

These dependencies must be installed and managed. WordPress requires less effort than some other applications, but it’s still possible for a single update to any part to cause chaos.

A static site is lightweight, and can be hosted by any web server able to return HTML files. There is nothing else to install, manage or update.

4. Improved reliability

A CMS is complex, with many moving parts and points of failure. Run a WordPress site for any length of time and you’ll almost certainly encounter the dreaded “Failedto establish a database connection”error. Unforeseen CMS problems can arise from sudden traffic surges, which crash the database or restrict active connections.

Serving a static site is less intensive — the server just has to return flat files. It’s still possible to crash a web server, but it’ll take considerably more concurrent requests.

5. Superior Security

There are several reasons why someone may want to attack your website. Traffic hijacking, rogue advertising, linking, authenticity spoofing and malware hosting all permit an unauthorized user to make monetaryand/or kudos gains.

A CMS opens a number of attack vectors. The most obvious is the login screen: it’s only as secure as the weakest user password. Be aware that any page running server-side code also offers potential exploits — for example, firing spam emails via your contact form. It may not be obvious that someone has gained access; the worst culprits want to stay hidden.

A static site has little or no server-side functionality. You cannot access it via scripting or database security holes. Someone could still gain access via SSH or FTP, but they would struggle to do much damage other than defacing pages or uploading files.

6. Client Control Considerations

You spend weeks building attractive CMS themes for the client to trash their site within minutes of your hand-over. Using a CMS is not necessarily easy, and it offers considerable power to content editors. You can lock down rights such as plugin installation, but it won’t prevent someone changing fonts, adding weird colors, using poor photographyor corrupting the layout.

A static site can use Markdown files. That limits the user’s options; they make fewer mistakes and cannot adversely affect the pages.

7. Version Control and Testing

Database data is volatile. A CMS permits users to add, delete or change content on a whim. Wiping the whole site is a few clicks away. You can back up databases but, even if that’s done regularly, you’re still likely to lose some data.

A static site is safe presuming your content is defined in Markdown files and you use a version control system such as Git. Old files are retained, and changes can be undone quickly. Testing becomes easier because the site can be generated and previewed anywhere. Preview files are on a separate Git repository, as the live files which are on themain branch.

So all is good in the static site world.

For developers interested in our Boilerplate or Certification process.

BOILERPLATE

GETCERTIFIED.

CMS system for managing Static Websites

Thu, 11 Aug 2016 16:00:00 GMT

How to build reliable, secure and scalable websites with the WebriQ platform

WebriQ is a global leader in software platforms used for mobile, social and web marketing initiatives. It is basically a free CMS developed to build static websites. Being a CMS for static site generators, it gives non-technical users an easy way to add/edit/delete content to any website developed with a static site generator. It allows you to create any type of website including news or community portal, multilingual E-commerce and complex multisite.

WebriQ comes with a parser tool and state-of-the-art CSS Template, capable of incorporating any custom design into the CMS platform. The complete platform is developed on an open source software and is now available to use on a monthly subscription plan.

How does it work?

WebriQ CMS is a single page app that helps you create a clean and user-friendly User Interface for editing content stored in your GIT repository.

In order to get started, you need to first setup a YAML config to define the content model of your website and modify the main layout of the CMS to meet your site design needs. When you click on /admin, you will be redirected automatically to the login page where you’ll be able to create or edit content as per your needs.

WebriQ CMS is available in two different options – WebriQpages and WebriQshops

WebriQ pages option allows you to create, manage and publish a variety of different pages ideal for setting up blogs, personal portfolios, business sites or more.

Features of WebriQ pages options

SuperFast and Secure

Unlike other single server based sites, websites created with this CMS option are served through a CDN which drastically reduces the latency, and offers 100% uptime and much faster downloads. Moreover, since all the websites are static and have no scripts that can be injected with malware or no database to connect to, it is pretty secure as compared to other platforms available out there. With WebriQ pages, service attacks denial, outdated scripts, and malware are all things of the past.

Stunning UI/UX Designs

Since the CMS does not require you to setup and create complex database structures for the site, the webmaster can be invested in building beautiful User interface designs that improve user experience on your site. Consequently, it improves user engagement on your website with reduced bounce rate.

Complete Control

WebriQ Pages gives you complete control over all the elements of your site be it the content or code of your site. It allows you to make changes to the content or the code whenever necessary.

WebriQshops, as the name suggests, allows you to create e-commerce stores to sell any type of products you want.

Features of WebriQshops:

API Enabled

WebriQshops comes with a storefront and Admin API to enable external integrations. You can also make connections with Restful JSON API.

Variety of shipping engines and payments

It also comes integrated with a huge range of shipping and payment methods into the standard shopping cart application.

Fast and Secure

The shopping cart application uses optimal computer resources and performs extremely fast. Being inline with PCI Compliance and best industry practices, WebriQ Shop is a very secure solution for businesses looking to establish their online presence.

100% Responsive Solution

The admin and storefront elements of this CMS are optimized for tablet and mobile devices along with various other screen sizes available out there.

How to build reliable, secure and scalable websites with the WebriQ Platform?

For a matter of fact, WebriQ provides a demo site to help you know how the platform works and what features it has.

Step 1: Creating an account

In order to create a site on WebriQ Platform, you first need to create an account with WebriQ. Open the official website i.e. https://www.webriq.com/#page-top and click create a free account.

Upon clicking the button, you will be redirected to a site creation wizard where you will be asked to select the type of website you want to create i.e. page or shop. When you choose page option, you will be asked to choose a template. For a free account, there are 4 different templates to choose from i.e. WebriQ Business, WebriQ Portfolio, WebriQ Landing Page, WebriQ Starter Page. Click on the desired option and hit Next.

Step 2: Completing the Site creation wizard

Once you have selected the type, you will need to enter the site name for your website. The website lets you create a subdomain under the webriqs.com primary domain. On the next page, enter your details such as email address, and password to complete the process. Check “I agree to the terms and conditions” and hit next.

Upon reaching confirmation page, you get confirmation of your subdomain and a request to click finish.

Step 3: Linking your website with GitHub Account

On the next page, you will get a link “Go back to dashboard”. Click it and you will be redirected to your website's dashboard with plenty of options to manage your site and account.

In order to manage your website, you need a verified GitHub account and connect it with WebriQ account.

Step 4: Customize and manage your website

Once you have linked your website to your GitHub account, you can now customize your website as per your needs, create/add new services and so much more. The dashboard lets you edit site settings such as adding a favicon, site logo, keywords, footer and main content. There are various other customization options available including image slider, adding testimonials, partners logo, featured work and more.
#### **Conclusion:**

WebriQ is a profound and invincible CMS that allows you to create beautiful and feature-rich static websites without having to write a single line of code. Whether you are planning to create a simple blog or fully customized e-commerce store, WebriQ lets you create a variety type of sites within minutes.

Author Bio:

Jason is a WordPress expert, associated with Wordsuccor Ltd. and has a lot of experience in offering best and reliable wordpress customization services. He has delivered numerous range of quality products related to this. He has a strong passion for writing useful and insights about WordPress tips and tricks.

Get WebriQ Certified

Wed, 03 Aug 2016 16:00:00 GMT

How To Get Certified

1. Create An Account

Create your free account and start creating your own static website

2. Use WebriQ Boilerplate

Navigate to Quicklinks Developer Boilerplate or you can go directly to boilerplate.webriq.com. Use the documentation to start building your site

3. Create Slack Account On WebriQHQ

Go to slackin.webriq.com to create your account and start chatting with other developers or chat with one of WebriQ developers on the Q&A channel

4. Submit Domain

Once you are done submit your domain(s) to getcertified@webriq.com

5. Website Review

Upon positive review you will receive a WebriQ Developers certificate and a 70% discount on our PRO service for a period of 1 Year, representing a value of $245 per year per site.

6. Profile Listed

Your profile will be listed in our APP, so that potential customers on the platform can contact you for jobs that need to be done on websites on the WebriQ platform.

7 Static Site Generators that will help you build the Amazing Websites

Sun, 10 Jul 2016 17:00:00 GMT

Do you remember the first website that you created? Most programmers start by building a series of pages with the particular HTML files. Each will call in some assets i.e. images, CSS, and JavaScript. You can launch all these files directly from the system without using a web server.The static sites offer excellent security and functionality as they don’t have dynamic content.

Today, websites are becoming smoother, faster and more flexible, as users love fast yet seamless experiences. The best way is to use a light and static website generator that makes web developmentand management incredibly simple. Static website generator has become a significant tool for creating the professional websites.Having a static site generator means you can create websites with advanced frameworks with a high level of efficiency.

Here are top 7 static site generators preferred by the most developers:

Jekyll

Powered by Ruby, it is a user-friendly static website generator. You can import content from WordPress, Drupal, Tumblr, RSS and CSV formats while using Jekyll. With its built-in server, you can evenbuild your personal static server from its template and source code. It acts as a local web server and generates the HTML, CSS & JavaScript files fromMarkdown, templates, Sass, or CoffeeScript files. With the help of templates, layout controls, and a large number of configuration options, it is easy to create the blog post.

Roots (roots.cx)

Roots is a static website generator that generates static HTML, CSS, and javascript files. It is a highly-functional framework used for creating small to medium sized front-ends. Comes with simple installation, it can manage a large number of compiled languages. It uses dynamic content to build blogs, collections, etc. WebriQ has implemented a Web APP to build and manage Static Pages based on Roots and Github repositories.

DocPad

Created on Node.js and Express.js, it is a static website generator provides your site with amazing layouts, pre-processors, and a powerful plugin system. It is integrated with the easy-to-manage administrator dashboard that makes publishing easier. It is easy to generate documents dynamically at runtime while using DocPad. Supported by the great community and maintained plugins, DocPad is becoming better every single day.

Hugo

Written in a statically compiled language, Hugo has become the most popular static website generator in just two years. Comes with a high level of flexibility, Hugo helps you organize your web content with any URL structure. It can be deployed on GitHub Pages, Dropbox, Amazon S3, or any host you choose. With Hugo, it is easy to define the metadata, declare the content types and use indexes to group the content.

Wintersmith

Created on top of Node.js, Wintersmith is a multi-platform static website generator. Comes with a Jade plugin, It provides absolutely no limitations on how do you manage your content.It also comes with some handy site templates for developing blogs & web apps.It will develop a basic structure for your website that contains all the assets and the content written in Markdown of JSON files.

Middleman

It is a command-line tool used for developing static websites. While simplifying HTML development, Middleman supports several templating languages that will enable you to add variables, call methods and use loops. With Middleman, you have access to Rb, Haml, CoffeeScript, verbose Javascript and multiple asset management solutions.With the LiveReload extension, the browser will automatically refresh whenever you edit the files of your website.

Nanoc

Written in Ruby, Nanoc is a powerful static website generator that is ideal for creating any kind of website, from personal portfolios to large business websites. Nanoc is highly flexible site generator helps you pick your favorite languages and extensions. It is easy to mix and match Haml, Sass, CoffeeScript, ERB, and Less, in order to minify CSS and JavaScript.

All these static website generators will help you highly functional static websites.

Author Bio: Ankur Purohit is working with Baymediasoft – a renowned PHP development company. With Six years of experience working in the field of development and digital marketing, he has technical as well as marketing skills to deliver valuable web solutions.

BOTS are the NEW APPS

Sun, 10 Jul 2016 16:00:00 GMT

Messaging bots are the all the rage. So what’s all the fuss about?

Bots are a lot easier to install than mobile apps. To “install” a bot, you simply search for the bot from within your favorite messaging app and click to start chatting. The bot has immediate access to your identity, too. For a mobile app, you open your app store, search for the app, click install, wait a minute to install, open the app, and login/create an account. You’re looking at a few minutes rather than a few seconds. The bot install results in at least a 10X reduction in friction.

Bots are easily distributed. Let’s say your friends are all using some awesome bot, they can easily share the bot with you from the messaging app itself. Bots can be linked to, shared on socialmedia, and even recommended by other bots. In the case of Slack, another team member can add your bot so that your whole team can use it.

Quality mobile apps are expensive to build, maintain and deploy. In the app paradigm, you need to have skilled Android and iOS client development teams ideally paired with a strong UXer or two. Then the app needs to be tested, refined and submitted to app stores for approvals. Rinse and repeat. In the bot world, you leverage the fact that messaging apps are built by someone else. New feature deployment can be done with continuous integration to the backend alone.

There is a very long-tail of use-cases that don’t justify a mobile app. Because of the low-friction install, distribution and development of a bot, a whole slew of use-cases open up. Users won’t likely install an app for their dentist or hairdresser. Therefore, to build dedicated apps for these use-cases would be futile. Instead, would that same user add their dentist and hairdresser to their contact list?

Messaging apps are ubiquitous and dominate consumer’s mobile engagement. Between Facebook Messenger, iMessage, WhatsApp, Kik, Line, Viber, Telegram, Slack and Hangouts messaging has almost complete market penetration. On top of this, messaging has 5.6Xhigher 12-month retention than other mobile apps.

Consumers are experiencing mobile app fatigue. What’s the last app that made it onto your home screen? How many apps did you install this month?

Bot interactions are intrinsically bi-directional. In the web and mobile app paradigm you need to provide contact info and/or rely on push notifications for the “receive” component of the UX. These notifications have to be stitched together by links and intents into the corresponding UI view. In messaging, incoming messages are a first-class citizen. This lends itself nicely to commerce and financial transactions which are, by definition, bi-directional.

Moving complexity to the cloud reduces a user’s cognitive load. Sure, you can always search Google, comb through results, click a few links, extract out the necessary information, and formulate a decision. However, isn’t it easier if a bot did that for you? Thisis especially useful when on the go or when time is limited.

Bots are extremely portable. While messaging apps are a bot’s native environment, they can just as easily exist in live chat, personal assistants , car audio systems, as a voice in your ear, smart watches, email, and push notifications.

Bot software development cycles are extremely fast. The first time the request can be serviced manually, then an automated version can be deployed behind the scenes. You get the added benefit of not wasting time building the wrong thing.

Humans are innately hardwired for language and conversation. Because of this language has evolved to become powerful, nuanced, and flexible. It goes without saying, but language has been used extensively for all of recorded history to do amazing things. Bots leverage this underlying human trait.

Bots go beyond devices

Today’s apps may be inextricable from their mobile hosts, but apps remain a far more flexible technology than their predecessors. Apps let us keep our favorite software products in our pockets and use them wherever we go, whenever, so long as we have a web hook-up. Bots are the new apps because they go beyond devices and provide a new version of mobility. Not only are we able to use bot technology anywhere in the world , but we can use the bot across multiple devices and interact with it in a variety of ways. Microsoft’s Satya Nadella calls this “conversation as a platform.” Rather than tapping, swiping, and searching, we will be able to just talk to bots to get exactly what we need. It’s the convenience of apps taken to the next level.

Bots are friendly

Facebook understands the No. 1rule of marketing - forging an emotional connection is the secret to customer loyalty. When I see a happy memory from the past, the memory makes me feel good and I transfer those feelings to Facebook.

Bots go further by making the emotional connection a seemingly two-way experience. Users may feel like their bots are their buddies, virtual friends they can joke with, who could grow to know their true selves. And bots are programmed to make users believe this is possible. Mezi, an AI-powered shopping bot, is programmed to feel like the user’s best friend who also happens to be an expert shopper. It’s easy to see how shopping with a code-based best friend could inspire even more feelings of good-will than the occasional Facebook memory.

Bots are multi-purpose

Apple killed the iPod because people prefered to listen to music on their iPhones. Smartwatch sales fell flat because they didn’t offer a radically new functionality. Tablets are on the decline. These stories speak to a trend in consumer technology: downsizing. Apps are the last vestige of the single-purpose product era. Bots will integrate all of these apps in one place, where the user won’t have to think to switch between solutions. Bots will make using technology as fluid as moving through life.

Our BOT implementations

At WebriQ we have been involved in a number of BOT implementations, through native Facebook API implementations and through dedicated platforms to build and manage BOTS on Facebook Messenger, Telegram and Slack. A couple of examples are WebriQ, Lawdingo and Buzzin Brisbane

Learn more on BOTS

What is a Static Website

Sun, 26 Jun 2016 16:00:00 GMT

A Little Background

There’s been a lot of talk recently about STATIC SITES and the new generation of tools used to create them,commonly referred to as “static site generators” or “static site engines.” As with any new technology, it can sometimes be hard to differentiate the hype from the reality. In a series of blog post aims to give you a broad understanding of the technology: what it is and whereit best applies. First, however,we need to define what static sites are and where they came from.

The term “static site” is an interesting one if you think about it, as it defines itself by what it lacks. The “static” aspect doesn’t so much describe a feature as the absence of one: dynamic page rendering. Once upon a time, probably before we commonly used the term “static site,” this would have been considered a weakness.

Those of us who’ve been working in web development for some time probably recall building static sites using tools like Dreamweaver, HomeSite, or(heaven forbid) FrontPage. The content on these pages could only be changed by manually altering the existing site files and replacing the files onthe server via FTP.

There were a number of issues with this process. Adding content to the site required a moderately high level of technical knowledge, either knowledge of the specific tool used to design and build the site or of HTML to hand code the site. One also needed to understand how to deploy the site to a host via FTP, which isn’t necessarily straightforward for non technical users. This meant that the content creators, who are frequently non technical, could not directly or easily contribute to the site and required the assistance of a webdeveloper to add new content.

Creating new pages typically required copying and tweaking existing pages. As the site grew, maintaining proper navigation and links typically became both tedious and extremely error prone. Some tools offered features like templates that tried to solve these issues, but these could be complicated or cumbersome to create.

In addition to these issues, there was the limitation that if your site required dynamic features like comments or forums, for example, this was simply not possible in a pure static site.

The Dynamic Site Era

Dynamic sites seemed to fix these issues. Non technical content creators could create and update pages via backend forms without the need to understand the specifics of website development tools or HTML. Since the content and pages were all driven from a database, navigation could be generated automatically. In addition, by definition, dynamic sites allow for dynamic features such as forums or comments.

In the case of content-focused web pages, dynamic sites often took the form of a content management system (CMS). These could be custom built to the needs of the site or, very frequently, selected from a number of commercial or open source options.

To this day, most of the content published on the Web runs through some form of content management system. Popular open source options include Drupal, Joomla,and Typo3 or WebriQ CMS. Nowadays, these systems typically handle much more than simply content creation and publication, with features such as complex roles and access control, workflow management, document management, and syndication.

These additional features lead to the biggest issue with dynamic sites, which is that the solution is often more complex than the problem. By virtue of its need to cater to a broad set of customers, a pre-built CMS often has a steep learning curve for both developers and content creators. Meanwhile, a custom CMS requires both extensive development efforts and access to a developer should issues or necessary changes arise.

Hosting dynamic sites is complicated by the need for database storage (and backups) as well as support for whatever dynamic language the site is built upon (PHP,Ruby, etc.). Factor in the need for regular updates to the dynamic language, database solution and even the CMS software itself, and it becomes rather obvious that, while dynamic sites solve many difficult problems, they bring with them their own set of complications.

The Rise of Blog Engines

The complexity of content management systems was not well suited for smaller, content-focused sites or blogs that didn’t require advanced features like complex user roles or workflow. Blogging engines, the most popular being Wordpress, aimed to solve this by making development simple, with pre-built and easily customizable templates, and publishing content quick and easy.

Blog engines don’t negate the need for supporting a dynamic language(PHPin the case of WordPress) or for a database(typically MySQL for WordPress). WordPress, however, became popular enough that many hosts made “out-of-the-box” hosting solutions that simplified set up and maintenance. To give you a sense of the popularity of WordPress, according to W3Techs, as of May 2015, Wordpress is used on approximately 23.9% of the top 10 million sites, a percentage that dwarfs every other content management system.

Nonetheless, overtime, WordPress has begun to gain some of the complexity of a typical CMS, and it is generally lumped in the category of CMS by most industry research. Many sites heavily depend on features that are added via plug-ins, the quantity and quality of which can dramatically impact site performance.(http://wpengine.com/2013/08/28/plugins-and-fast-wordpress-sites-its-not-the-number-of-plugins-its-the-quality/. In addition, features like plug-ins and “shortcodes”can impact the portability of content, keeping your site tied to the Wordpress platform.

Some in the blogging community felt that Wordpress and competing blog engines like MoveableTypehad strayed so far from the simplicity of their initial blogging focus that they created new projects, like Ghost , that aimed to get back to the basics of just blogging. Ghost’s tagline is, in fact, “Justa blogging platform.”

Static Pages Get A New Life

Whatever complexity dynamic sites may bring, for most use cases, there is simply no avoiding the need for dynamic data. Even the most basic content site, like a personal blog, generally has dynamic aspects: commenting, feedback or contact forms and search, to name just a few. So it wasn’t until the rise of new services that can fill these voids that static sites really became a viable option of rmore than just “brochureware”.

There are numerous services, both free and paid, that offer the ability to add dynamic aspects into static pages (it’simportant to note that these services are not specifically intended for use only on static sites). Some popular options include:

• Disqus, Livefyre, or Facebook for comments

• Wufooor or Google for forms

• Google, Swiftype, or AddSearch for search

• Discourse for forums

There are many more covering a full range of typical site requirements. There even BaaS(backend as a service) solutions like Parseor, Kinveyth that offer APIs that allow developers to pull any form of arbitrary dynamic data into a static page.

If you’re interested in some of the services listed above as well as implementations, read an article on the topic called “Movingto Staticand Keeping YourToys”.

Defining a Static Website

So far we’ve covered some background showing how the static web pages of old failed to meet the needs of the Web as websites became more complex and interactive. We discussed how dynamic sites generally and content management systems specifically solved some of these problems but led to increased complexity in both development and authoring. Blog engines partially addressed these issues but also took on some of the complexity over time. Finally, we saw how the rise of services have helped make static pages a viable option again.

Given all the above, what is a Static Website exactly

This is probably the key defining characteristic of a static site and part of why static sites tend to perform so well: there is no server-side generation at runtime. This means, for instance, that every visitor to your static site will be served an identical copy of index.html from the server until it is manually overwritten, say by uploading a new file or by committing to a Github repository.

There is no server-side language.

It follows from the preceding characteristic that there would be no server-side language (like Ruby or PHP for example) involved.

Thereis no database.

As there is no server-side language to speak to a database, there is therefore no database. This does not mean that there is no data. There can be data stored as files or via an external service like the ones discussed earlier. This means that if you need common features like user registration/login, this would need to be via an external service.

Static sites are HTML, CSS, and JavaScript.

This seems fairly obvious, but it should be clear that since static sites are intended to run in the browser, they must rely on web technologies to function. Of course, this can also include images like JPEG and GIF, graphic files like SVG and WebGL, or data formats like JSON or XML.

Benefits of Static Sites

While each of the preceding features brings with it certain limitations, they also lead to some of the primary benefits of static sites:

Performance

There is no server-side processing and no database to connect to, meaning that there is nothing to slow down getting a static page from the server to your end user. This also means that there are no bottlenecks that might cause slowness or outages should you encounter a significant traffic surge.

Hosting

Since no server-side language is required, hosting requires no complicated setup or maintenance, making it cheap and easy. In fact, there are even free options, like GitHub pages or Surge, for instance. Hosting and deployment will be covered in follow onposts.

Security

There are no server-side language issues to exploit and no database to hack. Basically, as long as the files on your host are secure, your static site is secure.

Content versioning

Since your entire site, from configuration to content, is file-based, it is very easy to keep all aspects of it within a version control system like Git. This can be especially advantageous for things like documentation that you may want to allow community contributions, forexample, using pull requests on GitHub.

To be continued in later posts.

Get a sneak preview on WebriQ’s Web Content Management System for Static websites or just go through a QUICK DEMO

This post is an extract from the Book by Brian Rinaldi – Static Site Generators.

Many reasons why your next website should be Static

Thu, 16 Jun 2016 16:00:00 GMT

Your website is overkill, and it’s killing your traffic.

There’s no reason to have a massive, unwieldy Content Management System with a database when you could have a fast, secure and beautiful static site. But how can you decide if a static site is right for you?

1. YOU VALUE SECURITY

When was the last time you updated your CMS software and plugins? By conservative estimate, 70% of all WordPress installs are vulnerable to known security exploits. In 2014, millions of Drupal sites were vulnerable due to a bug in the code, and Drupal told users that if they hadn’t updated within 7 hours of the announcement, they should assume that they were hacked.

With a static site, you don’t have to worry about malicious code being injected into your site when users visit it. Static sites are builton a production machine by static site generators, which take yourcode and spit out flat HTML files with CSS and JavaScript. When a user requests a page from your site, the server just sends them the file for that page, instead of building that page from various assets each time a viewer comes on . No build process means standard hacking attacks like scripting or database security exploits just don’t work.

2. YOU VALUE SPEED

What does a browser do? It renders HTML, CSS and JavaScript into a human-viewable format. No matter what type of site you use, a legacy dynamic site or a modern static one, what gets sent from the server to your browser is HTML, CSS and JavaScript. So why take the time and resources to render your site every single time someone visits when you can have a pre-built version ready to go? There’s a reason that a normal static site hosted on a CDN is often 10 times faster time-to-first-byte than a site built with a legacy Content Management System.

Additionally, by hosting your static site on a CDN, you can serve it from whichever node is closest to your users. Someone viewing your site in a coffeeshop in Vienna pulls from a European server, not a server farm in Silicon Valley. The same goes for your Japanese visitors, or a user just down the street.

3. FLEXIBILITY

Your basic site built with WordPress or Drupal starts out as a one-size-fits-all solution that is then customized by bolting on plugins. A lot of plugins. Seriously, so many plugins. A quick Googlesearch for “must have WordPress plugins” yields a front page where nine of the ten posts list 20 plugins or more as “must have”.

Witha static site, you can get lean and mean, with a tool that does exactly what you need it to. Make like the pros and use Middleman or Roots. At WebriQ we love to work with Roots as it build with a corporate client in mind.

4. SMALLER FOOTPRINT

Your WordPress install is a monster of cobbled together software and hardware, and probably looks something like this: a machine running your preferred distro of Linux a web server running Nginx or Apache PHP with its associated extensions and web server configurations MySQL WordPress or similar exercises like Joomla, Drupal, Concrete5 etc. All the plugins you need Your theme and template code If you don’t want to host your own, then you just have to hope that your host keeps its PHP and MySQL up to date, so that you aren’t exposed to those pesky security vulnerabilities that crop up everynow and again. Then there is the upkeep. Make sure you’ve allotted time to manage all these dependencies. And some more time in case an updated plugin or theme breaks something.

A static site, when generated, is capable of being hosted on any webserver that can return HTML files. Of course, you’ll want to take advantage of the possibilities afforded to you with a static site by finding a host that allows for things like continuous deployment,instant cache invalidation, automated deploys and more. That job is done for you here at WebriQ without the need of having admin staff on board.

5. RELIABILITY

The beauty of serving up flat HTML files is that they can be hosted anywhere and everywhere, like on a CDN. Let’s say there’s a DDoS attack on the server where your legacy site is hosted. Sorry, but you might just be down for a few hours or even days. That same attackhits a node where your static site is hosted? Your site just gets served up from the next node. Your visitors never notice that there’s a problem.

6. VERSION CONTROL

It’s completely possible to design a site on your production machine and then upload it to a host , but the majority of developers would like some sort of version control system like Git. You can be roll back toearlier commits, meaning that short of deleting your online repository, you can always go back to a previous version of your site with a few keystrokes. And if you are a WebriQ customer, you can rollback to a previous deploy with just one click.

7. DEVELOPER EXPERIENCE

The beauty of using a static website generator is in the developer experience. Build tools will output your HTML to a particular directory on your build machine, and nearly all tools include a local web server, which allows you to check and double check your progress as you go. You have the security of knowing that your site will look exactly the same to your visitors as it does to you as a developer.

8. SCALABILITY

You’ve hit it big! Your site has gone viral, and you are seeing absolutely massive response and increased visits thanks to getting name checked across the social media spectrum. Did you anticipate that this might happen? Did you over provision massively, just in case this happened? Are you paying for huge chunks of bandwidth monthly, hoping for an explosion of traffic.

Or are you making frantic calls to your service provider to get back up online after you made it to Reddit’s front page? Your plan couldn’t handle that kind of attention, and now you are down.

And when your traffic means that you have to scale, it means that you are paying for all that complex code to run on your server at every page request. And that’s going to hit you right where it hurts the most.

With static, scalability is barely an issue. Of course it scales! Increased requests mean increased pages served, but no extra work in building those pages. With some providers, scale is built in, whilewith others like Amazon’s S3, all you have to pay for is the increased bandwidth.

9. HOSTING & PRICE

I fall the heavy lifting of building a static site is done on your production machine, then what exactly is it that you are paying for with hosting? Asset storage, basically. Your static HTML files take up next to no space, and so your service is usually priced accordingly. Instead, you can spend your money where it really matters, on the features that make your site faster and your life easier, features like atomic deploys and asset fingerprinting to make sure your site is always globally consistent, or git integration andautomated builds, so your site is always up to date with your latest changes, and snapshot versioning and instant rollbacks.

There’s never been a better time to take advantage of the speed, security and reliability of static web generators and the development environment around them. So what are you waiting for?

Signup for a FREE account on SIGNUP

Cloud CMS for Static Websites

Mon, 06 Jun 2016 16:00:00 GMT

Database driven websites have been around for a while, and whereas they have been driving tremendous opportunities for the open-source development community ,they are not any longer the answer to most of the customer requirements out there. Why is that, because most websites plain and simply do not need a database or a web server for that matter, let alone complex development languages. Keep it simply if you can and focus on the main things that are driving traffic to websites, any website – mobile friendly design, speed, speed and speed, security and reliability. Why on earth would your site slow down or crash with 100 or even 1,000 concurrent downloads or be hackable by anyone understanding how plugins or scripts work. No reason.

Other often heard objections are there’s no way for users to interact with my content!

You may think that sites built with static tools aren’t interactive, but it is not really the case. With Application Programming Interfaces (API) you can add just about any functionality you desire to your site.

Social sharing can be done with Shareaholic or ShareThis. If you want to add comments, add Disqus or LiveFyre. Why do the heavy lifting when someone elsehas already done it for you?

There are too many choices and it is too hard.

There are,admittedly, lots of choices when it comes to finding a static website generator. But that is the beauty of it. In fact, those choices are pruned significantly when you take into account exactly what you–the-user–want from a site, and how you want to make it happen.

Well we made some choices to make it easy for you. We opted for Roots (www.roots.cx) as a Static Website generator, primarily because it was build by a creative agency with corporate customers and professional designs in mind. Any marketing or corporate website will work beautifully with Roots and there are extension available to pull in any data or template you may need for your site. It is all easy to install, well documented with a relative acceptable learning curve for any developer out there.

And there isdocumentation on our APP as well, making it even easier to build andmanage the entire process – http://app.webriq.com/help/page.

Updating content istoo hard! There is no CMS.

Actually, there are quite a few options for updating content on static sites. The first and most obvious is writing and saving your content as markdown files. The majority of static site generators support markdownout-of-the-box or with the simple installation of a plugin.

If Markdown is aproblem, and it actually is for most non-technical users, there are anumber of different CMS options. Some are hosted, some are content APIs, and some live on your production machine.

Contentful is a Software as a Service (SaaS) that uses a content API to deliver your content. Contentful has integrations for static sitegenerators including Jekyll, Roots, Middleman and Metalsmith. Roots has an extension that will hook you in to Contentful and you will beable to update your content through an easy to use UI. Each time you do that, an automatic build will be generated by our platform. Contenful is ideal for larger corporate projects and where multiple contributors have to work together in a workflow with roles and permissions.

Prose.io - actually lets you navigate and create new content right on GitHub.Once you have your site up and running in a repository, you can create new posts, define URLs, write in Markdown or use their built in editor to write and format your posts. Especially usefulfor customers who have no appetite to change anything on theirwebsite without the help of a qualified developer.

WebriQ CMS - based on the open source version of Netlify CMS it combines the UI of Contentful and updates the content through the Github API to the repository of the website, completely transparent for content managers or developers.

A demo can be tested on http://app.webriq.com/help/page/demo/howto.

Our SaaS platform comes standard with a pre-build template, a repository on Github,online CMS tool to manage content, tools to add Google analytics and other scripts, Form submission tools and a rollback to previous versions of your website. Premium features include SSL certificate, Invite members to your website for development or content management (role based) and Domain redirects to single or multiple Top Level Domains.

Why wait, build your websites with the latest and greatest tools available. We need to do better then Wordpress experiences, because we can.

Free CMS for Static Websites

Sun, 15 May 2016 16:00:00 GMT

We just dumped our old web content management system of choice , got the hang of a static websites , and really like the simple, lightweight and maintenance-free feel of it…

Why on earth would I want to get a CMS for static websites?

A few reasons, you should consider a CMS for a static website; So that non-technical folks are also able to create content for static websites, without the need to go and consult a developer. So that you can use static websites in lots more customer projects. So that no developer is required to update the repository and run the site.

It just so happens that static site are mostly loved by developers, but not by the average Joe. They do not offer WYSIWYG,previewing on demo sites may take an update cycle, they are often based on markdown text files, and they require some knowledge of modern day repositories.

Moreover, when teams are collaborating, it can get complicated quickly. Has this article already been proof-read or reviewed? Is this input valid? Are user permissions available, e.g. for administering adding and removing team members? Can this article be published at a future date? How can a large repository of content be categorized,organized, and searched? All these requirements have previously been more or less solved within the admin area of your CMS. But of course with all the baggage that made you leave the appserver-app-database-in-one-big-blob stack in the first place.

Content API is one solution

Decoupling the content management aspect from the web building system. And then replacing the maintenance prone server with a cloud based web service offering. Effectively, instead of your CMS ,you move to a Content Management as a Service (CMaaS) world, with a content API to deliver all your content. That way, you get the all the benefits of content management features while still being able to embrace the static site generator mantra.

Systems like Prismic or Contentful are typically designed to be fast, scalable, secure, offer high uptime, so that you don’t have to worry about maintenance ever again. Separates content from presentation, so you can reuse your content repository for any device platform your heart desires. That way, you can COPE (“create once, publish everywhere”). Offers webhooks that you can use to rebuild your static site in a fully automated fashion every time your content is modified.

On the not so positive site, the platforms are proprietary (as opposed to open source), do not come cheap, have a lot of complexity that more often not needed then needed and have a relatively high cost of ownership.

A better alternative is a FREE CMS for your static website

Deploy modern static websites with our automated open source platform. Add best practices like SSL, CDN distribution,and continuous deployment with a single click.

All elements of the platform are open sourced, so you are in full control of the website. The CMS interfaces with a Github repository through a simple User Interface, only containing the variable elements in the website, i.e. blogs, articles etc.

Each new content entry triggers a new build on the platform and ensures that your content updates are reflected on your site within seconds. All automated, and without the need of a developer and without the possibility to change the code on your website by mistake.

All the content is safely stored in a Github public or private repository. You can revert to previous or go back later versions of the site by a single click. Last but not least you can assign different content editors to take of the content updates by inviting them as a team member.

A full demo of the FREE CMS system is available at DEMO. Follow the instructions and let us know if you need any additional help. Register for an ACCOUNT.

Issues with Static Website generators

Mon, 02 May 2016 16:00:00 GMT

There has been a lot of talk recently on the rebirth of Static websites, for lack of a better word. Static websites have been around for quite a while, but have been gradually replaced by database driven websites and content management systems. The likes of Wordpress, Joomla, Drupal and a ton of others come to mind. Five to six years ago that seemed the way to - you store all your data in a relational database and you serve all the content from a web server. The dot’s are connected via a user interface to administer and manage all the content and users from of your web assets. Tablets and smartphones were not around in large quantities, browser capabilities were minimal and security and speed were not high on the agenda. Open source projects like Linux, Apache, MySQL and PHP were the drivers of a solid development community around those technologies.

But the success of database driven websites has created real issues that are hard to overcome. The model was not really scaleable - with a couple of simultaneous users, no worries. With hundreds of users, the server would go down eventually. With numerous plugins and patches, the model became highly vulnerable to Service attacks and denial of service. Webservers and databases need to be maintained and updated, a costly and complex exercise. The need of ever better and speedier user experience on now smartphones and tablets further stretches the model to where it becomes questionable if a database driven website is really the answer for websites in 2016 and beyond.

Over the last years we have seen the rise of Static Website generators

There are plenty of them around, like Jekyll, Roots, Hugo, Middleman just to name a few. They are great tools to use, as the use HTML, CSS and Javascript as main language. So no need for PHP knowledge, database and web server knowledge and no need to use plugins to put your site up. Without the need of a database, web server and a multitude of plugins, the websites build with these frameworks are fast, reliable and scaleable. Add an open source SSL certificate to it, put it on a CDN (Content Delivery Network) and you are done. Cost of building and maintenance is substantially lower then with a database driven website. It scales without additional resources, it is as fast for one visitor as it is for thousands of visitors.

There’s a rumor going around that dynamic sites are better for SEO. They’ve got plugins! They’ve got updated content! Spiders! If you’ve built a single page app with static technology, most of your site will be a bunch of javascript tags, something that doesn’t do you much good when the web crawlers come looking for content. That’s why there are services that offer prerendering. Pre rendering allows you to show the crawlers the content that users will actually see by rendering it in a browser, saving that static HTML, and then returning it to the crawler as HTML. Now your content will get indexed like a normal page. Check out prerendering services like Prerender.io, Brombone, SEO.js or SEO4Ajax to start. Wordpress fanboys will often run in screaming at the top of their lungs “Updated Content! Updated Content!”. Don’t be fooled, they haven’t cornered the market. Updated content can be added really easily on static websites: write your content, push it to your gitrepository, and boom: your content is updated. It’s the power of continuous integration. Now all you have to do is actually create the content. Beyond that, quality SEO is really all about structure, structure that isplatform agnostic. The head matter on your posts (that’s what willbe updated most often, right?) determines your metadata and URL structure. Build processes can specify Pretty URLs. Writing in an HTML friendly language like Markdown makes it easy to add links, images and alt text. Sites like GoogleKeyword Planner and KeywordTool can guide your keyword usage. Best practices for SEO are about the work and planning that you do, not a plugin.

What is the missing link - a simple browser based User Interface to update the content of a website. At WebriQ we have solved this by automating content updates through a Github workflow that automatically creates a new build for your website each time the Github repository is changed. It allows you to dynamically change the content from a website on a desktop, tablet and even on a smartphone in case of urgency. You can view a DEMO and you can manage the site on ADMIN - login with user demo@webriq.com and password demo!@#1234. Enjoy the ride.

Building Static Websites

Sat, 23 Apr 2016 16:00:00 GMT

It’s 3am. Your website has just gone viral. Thousands of visitors are pouring in to learn about your company, and possibly become customers. Before long though, most of your visitors are greeted with one of these:

INTERNAL SERVER ERROR 500

BAD GATEWAY – 502 ERROR

Your server is down, and so is your website.

But there’s another way. A way to have a website that never goes down. A website that quietly maintains itself, is safe and secure, and remains unchanged as it goes from 100 visitors a month to 100 visitors a minute.

The idea of a single server serving traffic for a website harks back toan age of mainframes and ISDN lines. But the demands of scale and perfect uptime killed the mainframe. Maybe it’s time they killed single-server sites as well.

A server is a complicated piece of equipment. It needs to be updated. Any of the two hundred processes running on it has the power to cripple the machine. It will stubbornly refuse to serve more requests than it can handle. It will shutdown in the middle of the night, or the middle of your vacation.

Your homepage and marketing pages shouldn’t need to connect to a database. If your marketing site is opening a database connection just to render, you have a very finite limit on how many requests you can serve.

Think of the browser as your new server. You get a brand new shiny one dedicated to every user who visits your site. It can make requests. It can make decisions. It can show what you want when you want. But unlike an actual server, it can interact with the user instantly, show helpful feedback, and look great. It can do more than simply display what your web server spits out.

So lose your web server. Host your site by uploading some HTML and JavaScript to the cloud, and let it be served to your users from a content delivery network with servers around the world. Upload yourfiles manually, use a static site host like WebriQ, or an open-sourcetool.

Nothing can compare to the simplicity of knowing your site can handle all the traffic in the world and still remain fast and reliable. That it can’t go down, because there’s nothing you’re responsible for which can stop working. It’s fundamentally so much simpler, and simpler things are better.

Better meaning easier to build. Easier to debug. Easier to change and improve. Easier to keep running in the face of whatever life is going to throw at your business. Oh, and it’s faster for your users, it can not be hacked, and never has to be updated, unless it needs change.

Try it out on DEMO and ADMIN your site with user name demo@webriq.com and password demo!@#1234

Static websites are the future. If you want some neat APPS that can enhance your Static website, check out EAGER

Why using a Static Website

Mon, 11 Apr 2016 16:00:00 GMT

Web development has stagnated on a concept in recent years, the idea of a requisite dynamic content management system (such as WordPress or Drupal), but now there is a resurgence in static websites. For some time we have recognized the value of using static websites and wanted to provide some insight into the practical choices made when evaluating the suitability of the static website approach.

When discussing static websites, most people respond “Why? Why should I make this website static?”, but instead the question should be Why should my website be Dynamic or driven by a database?

STATIC OR DYNAMIC WEBSITE

The term static site describes a website with pre-existing content and available as plain HTML files. This is in contrast to a dynamic site in which content is generated upon request by a series of backend systems, essentially a database.

All sites have some static content: the images, the styling, etc… For dynamic sites the HTML markup that brings all of it together is not already available for use, rather it is generated at the time it is needed by a browser. In contrast, a static website has this markup pre-generated and immediately ready to be sent to a browser without delay, having already performed the generation step before the site was made available.

Not taking the performance hit of generating the site content upon request spares the burden of real-time infrastructure, which translates directly to sites exhibiting greater speed and stability at significantly lower costs. The absence of this complex infrastructure results in sites that are more secure and scalable. Cloud hosting has made it such that for almost negligible cost a static website will never be unavailable and can scale to meet any perceivable demand. Static site generation was one of the techniquesused to save the healthcare.gov website when it had trouble scaling in it’s initial rollout.

WHEN TO USE A STATIC WEBSITE

As the LAMP stack , i.e Wordpress and it’s lookalikes grew in popularity, its use in creating websites became common and many sites that did not have particular needs to be dynamic were created dynamic by default. This is not the best approach.

Imagine you have a website that presents widget information, and you have 1000 widgets in your database. It would be easy to default to creating a dynamic website with a script taking the widget name as input and displaying specific information about that widget when the site was hit. An alternative is to use a static website generator to create the 1000 different pages (one for each widget) and use those to show the widget information. If the widgets ever update, the site may be re-generated to update the content. Now that static website generators have the capability to effortlessly rebuild websites around new content, adding new content to static websites may be configured to as a turnkey operation.

It may require creative thought as to how to turn a website that would be obviously dynamic into a static website. At the same time, never before has there been this many quality tools for adding dynamic elements to otherwise static websites. Now that the Google Crawler is executing JavaScript as part of content indexing, the traditional major penalty of this approach has been removed.

See the aforementioned article for greater details on the process of static website generation.

Generally you should be striving to make your website as static and compressed as possible, while recognizing there are some good reasons it may not be possible:

INFORMATION UPDATE FREQUENCY

The information you are trying to convey on your website may require real-time generation to display. If you must display content information accurate to the moment the request for the information was made, it would not be possible to pre-generate the content as you would not know what the information actually is at the time of site generation.

This is not to say that generation cannot be frequent if the data changes frequently. If you have a data set such that generating (and deploying) the site takes 60 seconds, and the data changes every 10 minutes. You still have the opportunity to automate site generation every 10 minutes and have a static website that is relatively current to the information it is conveying.

If real-time data is of absolute importance, then something like a microservice utilizing client side JavaScript to retrieve the most current information may be used in conjunction with a static website. Possible with some technical creativity.

PERSONALIZATION

If the page you display is completely customized to your user it would not be possible to pre-generate the pages as you would need authentication and then customization information that is only available at the time of the request. Again, this may be mitigated by using client-side JavaScript to provide some of the personalizing.

EASE-OF-USE

It makes sense to use a WordPress blog or other service if you simply do not have the expertise to use the generating tools. In these cases the value is not provided by the dynamic generation of the website, but the interfaces give by the CMS tools to customize the site, requiring that the site be able to feed from a dynamic infrastructure stack.

MAKING THE DECISION TO GO STATIC

EXAMPLE: THE WORDPRESS SITE

WordPress has become a often requested platform for websites. It is requested due to positive word-of-mouth and adoption rates, but rarely is it analyzed beforehand as the proper approach for a site’s needs.

The site requirements were a completely custom design, lots of static text, some data (not altering for the forseeable future), more of a classic corporate home-page, in single-page website format.

While it is possible to build this site on WordPress, it did not make a lot of sense. We instead suggested a static site, and built it with a tool chain readily available in the WEBRIQ APP. The site uses client-side JavaScript UI to retrieve and display own and third-party data, adding a more dynamic feel. The end result was a site that fulfilled the requirements, is editable by anyone who knows Text editing, is lightning fast to deliver and is hosted on a Content Delivery Network, with a 100% uptime.

EXAMPLE: THE CONTENT AGGREGATOR

This looked, initially, like a standard dynamically generated website. The site was a content aggregator, displaying news from a few third party websites, with some extra value-add information.

After analyzing the requirements, we saw opportunities in the nature of the aggregated data

We only needed to display the top 50 or so items from each site.
The sites did not exhibit much data churn within the span of an hour. What we saw here was that the overall site itself was static, the data was the only changing portion and that only needed to change on an hourly basis. After some quick prototyping, we found a good static approach. The website itself is statically generated, and the data is generated hourly into a JSON file which generates a webhook to automatically create a new build for the site. JavaScript is used on the client to display the content in the JSON file and add customization via meta data added as part of the aggregation process.

TOOLS

Some of the tools we use in creating static sites:

ROOTS

Roots is a static site compiler, that generates static html, css, and javascript files. It’s very good at helping to build static front-ends. It is sponsored heavily by Carrot Creative, and makes frequent, highly variable builds quicker and easier for freelancers and agencies. It’s a truly excellent framework for quickly and easily building small to medium sized front-ends of any kind.

Roots can handle a huge number of compiled languages, and can be used with many tools that help push static sites as far as possible. For example, it can link with an API, pull in your data, and render parts of it into your views on compile. Then it can render the same or other views as javascript templates and you can push any other data from your API into them on the fly at runtime on the client side in reaction to user actions.

GITHUB

Used to host all your HTML, CSS, Javascript and other assets for continuous deployment of your site. Each time your site has been updated with a new page, new content or new style a webhook will automatically start a new deployment process. The update process typically takes around 10 to 20 seconds, and you will be notified when the new build is ready. The repository approach has two other major benefits - you can revert to previous builds if needed and you can invite a series of collaborators to the repository for updating style sheets, pages and/or content.

STATIC CMS SYSTEM

A JavaScript based CMS for static site generators. It gives non-technical users a simple way to edit and add content to any site built with a static site generator, in this case Roots. The CMS is a single-page app that you pull into the /admin part of your site.

It presents a clean UI for editing content stored in a Git repository. As an example WebriQ Blog Admin

You setup a config to describe the content model of your site, and typically tweak the main layout of the CMS a bit to fit your own site.

When a user navigates to /admin she’ll be prompted to login with a Github credential, and once authenticated she’ll be able to create new content or edit existing content.

The business case for Static Websites

Sun, 10 Apr 2016 16:00:00 GMT

The current web is a mess. Every week we go to Hackernews and follow a broken link. Not long ago 12 million Drupal sites were infected with malware. 79% of all Wordpress sites are vulnerable to known exploits.

The emergence of mobile means a lot of slow loading sites with towering bouncerates and loss of business to follow.

We should do better. We must actually. Because we can.

Static websites have always been faster, safer, simpler and cheaper.

It’s just that browsers and hosting services weren’t good enough, so there were too many compromises. Making the slow, vulnerable and expensive traditional “dynamic” sites the best alternative.

But no more. The browser is all grown-up, and CDNs have really seen the light of day.

We want static sites to be as easy to make and to update as possible, while still gaining all the speed that static sites promise to deliver.

Static websites are faster, safer, simpler and cheaper. Here we explain how. Static sites are simple, but today they can do almost anything a traditional (dynamic)site can.

A traditional (Wordpress or Drupal) site needs to be hosted on a server, and it needs to render every single time a user visits. The difference with a “static” site is that you build it BEFORE you deploy it. So what’s live are only already rendered files. So there are no so-called movable parts live and you get tohost the site on a CDN. (Content Delivery Network). Anything that still needs rendering will be done so by the browser. Pretty cool if you think about it.

This all means a number of things. All of them good if you are going static.

1. Speed & Performance. That your site will be served from a CDN instead of a single server means much lower latency and much higher uptime

2. Security. As there is no movable parts, no scripts being executed, there is no wayto inject malware. Malware and the inherent structure of traditional web tech is becoming a major issue.

3. Simplicity. Again there are no moving parts. You don’t need to optimize your how fast your code will be rendered, as it’s already rendered when you deploy it. So no need to worry about server updates breaking your site, etc. When it’s live it’s live,and you can go on to doing other things.

4. Cost. It’s way way way cheaper to scale. And it all happens automatically. So no having to cover yourself by buying into a larger hosting service than you need, or having your servers cave to traffic spikes.

Mostsites would benefit from being “Static”.

There are two exceptions - sites that absolutely need a database as a back-end and those that need constant updating.

Building a static site takes a while - typically perhaps 10 to 20 seconds - and that’s too long a wait if you are updating lets say every minute.

Have a look at how we have automated the building, management and updating of a typical Portfolio website at WEBRIQ APP

Biggest E-commerce trends to stay afloat in 2016

Fri, 08 Apr 2016 16:00:00 GMT

However,the continuous increase in e-commerce consumption by people has also led torise in the competition for retailers. The best way to stay abreast ofcompetition is to optimize your e-store according to the latest trends. Now,when it comes to e-commerce, several on-going trends are expected to stayafloat in 2016.

Beloware some of the biggest trends that will dominate in the e-commerce industry in2016:

1.Wider Adoption of Responsive Design

Nearly 66 percent of user’s time spent on e-shops is done using mobile devices. And, 61 percent of consumers abandon an e-commerce site if it isn’t mobile-friendly. Thus, it’s imperative that your online shop must be optimized for Smartphones and tablets. Put it simply, having a site adjusted to multiple devices withdifferent screen sizes has become a hard-to-ignore priority than ever before.This clearly suggests that the adoption of responsive design is only going togrow rapidly.

Despite offering a streamlined viewing experience, responsive design has beenimplemented in only nine percent e-commerce sites. However, realizing thesignificance of responsive design, more and more e-commerce website owners areturning to RWD approach.

2.Flat Design: “When Less is More”

Most e-commerce stores are usually cluttered with stylistic elements like gradients,textures, and drop shadows, to name a few. But using such elements decreases usability. And so, many e-commerce sites owners have started following the “Less is more” motto to make their site user-friendly. Basically, retailers are making use of flat design templates to bring clarity and simplicity to their design. Rather than using stylistic elements, a flat design includes subtle elements, including bold colors, iconography, grid and much more.

One great example of flat styling is Canopy. You can use this site to get inspiration for applying flat design to an e-shop – that features a clean and minimalistic design with plenty of white space that quickly brings the user focus on the products.

3. Useof Split Screens Will Increase

In case you want to give prominence to a few products (ideally two products)simultaneously, on your e-commerce site then you can make use of split screens to fulfill such a need. Besides, helping you promote two of the most important items in your store, split screens also provide another benefit. You can showcase your primary product on the side of the layout, and on the opposite side, you can display additional information about that product.

For example, bellroy.com (a site that sells wallets and several other accessories) is designed with splitscreens. Below is an image of the site containing a passport sleeve on one sideof the product page, while the right side is used for displaying a travel wallet.

4. More Finger-Friendly Interfaces

As people prefer mobile devices for making purchases online, it’s important that your site can enable visitors to interact with a web page in a seamless manner. One best way to achieve such an objective is to make your e-commerce site interfacemore finger-friendly. Well, since consumers have become accustomed to usingfingertips for interacting with a page, apparently they’ll possibly would wantto use multi-touch gestures for navigating through your e-commerce site.

E-commerce website interfaces designed keeping in mind finger friendliness will most likely have two impacts. Firstly, the use of content sliders will reduce. Though such sliders have proved quite useful in showing plenty of informationin small screen displays, but users find it hard to click on the small-sizenext buttons of the content sliders. Secondly, use of larger CTAs will increaseas they help provide an enhanced shopping experience to users.

5. Add a Personalized Touch With Custom-Drawn Illustrations

In today’s highly competitive e-commerce industry, site owners resort to several techniques and tactics that could help in making their e-shop look unique and apersonal touch to it. And, one emerging trend that can assist you in accomplishing such a goal is to make use of hand drawn (custom) illustrations.Thus, you should consider adding hand-drawn stickers to your e-commerce siteinstead of the stickers available online. Also, you must think about adding alarge illustrated background.

For example, Merrell uses a fully illustrated background that not just add a realistic touch to the layout, but also help deliver the site’s message in an interactive yet easy-to-understand manner. Despite using plenty of illustrations, this e-commerce site doesn’t compromise on usability.

Post CMS Landscape

Tue, 29 Mar 2016 16:00:00 GMT

The challenge

Over the years, we’ve tried everything from Wordpress, Drupal, Squarespace, custom development app and we came all the way back to a Static approach.

There’s been quite a groundswell of belief over the past couple of years, we’ve been doing it all wrong. We’ve been making servers do all sorts of stuff they shouldn’t be doing.

The move to static worked out very well from a development perspective. It simplifies the development work, lowers the hosting costs, and ensures a high level of performance, scalability, and reliability.

In order to make this idea work at a large and on bigger projects, we needed to figure out how to automate the management, build, and deployment of static sites.

And we needed to pull this all together in manageable online tools.

Putting the Pieces Together

We decided to use our own website as a testing ground for using these tools. We migrated our content in to a repository on Github. In order to back into our Roots project, we used an extension: roots-contentful. Every time our website was compiled, roots-contentful would fetch data through Contentful’s API and pass it into our view templates. It would also compile each individual blog post’s HTML file using the single page views feature.

With the Roots project now built on top of data from Contentful, we then set about automating deployment when content changed. First, we created a webhook endpoint that would start a new build and deploy the project whenever it received a POST request. Then, we set up a webhook in Contentful with the new Netlify endpoint as the destination URL. With this in place, every time an editor creates, deletes, or edits a new piece of content, we receive a webhook from Contentful and kicks off a new deploy. We run Roots compile, loads the new Contentful data with roots-contentful, optimizes our assets, and finally pushes it out to a global CDN. Within a couple minutes from publishing, our new content is live on our static site. Pretty cool.

The next step in our process is to provide content managers and publishers with an online User Interface to update the content directly in to the Github repository. Each time the content is updated and committed to Github, a new build will be started and the new or updated content will be published on the Static site.

Whilst designing a website is the work of a designer, and coding it work for a developer, with the above approach we give content managers and content managers the needed tools to update the content via a simple browser based User Interface. The User Interface contains only the content elements that you want to manage, nothing more and nothing less. So, if you only need to change your blog, the UI will only contain the elements to manage your blog. If you have a more complex data model, it can contain all content elements of your website that you want to manage. The beauty is that you are not touching any of the codes of your website, only the relevant content elements.

Beyond security, reliability and scalability, the other big advantage of the Static approach is versioning of your website. Since your entire site, from configuration to content, is file- based, it is very easy to keep all aspects of it within a version control system like Git. This can be especially advantageous for things like documentation that you may want to allow community contributions, for example, using pull requests on GitHub repository.

You can see all the above in action on WebriQ APP or you can send us a DEMO REQUEST

Who needs a Wordpress Site

Tue, 29 Mar 2016 16:00:00 GMT

When Static Was It

The first ever website, Tim Berners-Lee’s original home page for the World Wide Web, was static. A website back then was a folder of HTML documents that consisted of just 18 tags. Browsers were simple document navigators that would fetch HTML from a server and allow the end user to navigate them by following hyperlinks. The web was fundamentally static.

As browsers evolved, so did HTML, and gradually the limitations of purely static websites started to show.

The most mainstream answer to the limitations of Static Websites was the LAMP stack and CMS’ such as WordPress, Drupal and Joomla. All of these played an incredibly important role in moving the web forward, enabling the Web 2.0 phenomenon, in which user-generated content became a driving factor for a lot of websites. Users went from following hyperlinks to ordering products, participating in communities and creating content.

Dynamic Website Wordpress Problems

The dynamic website architecture moved the web forward, but it also opened a can of worms. By a conservative estimate, more than 70% of today’s WordPress installations are vulnerable to known exploits (and WordPress powers more than 23% of the web). Just a few months ago, 12 million Drupal sites needed emergency patching, and any not patched within 7 hours of the exploits’ announcement should be considered infected with malware.. Not a week goes by when I don’t follow a link from social media to a website that shows a “Database connection error.” Scaling a dynamic website can be very expensive, and agencies that launch a campaign website or the like often have to overprovision drastically in order to guard against the website blowing up if it manages to go viral — or else they have to desperately scale it while trying to get it back online (something that never seems to happen during office hours).

We pay a huge price for the underlying complexity of dynamic code running on a server for every request — a price we could avoid paying entirely when this kind of complexity is not needed.

Is Static the next big thing again and why now?

Why is static website technology taking off now, and why did the early generators fail to make a dent in WordPress’ dominance? What’s changed? And how far can we take this?

Today’s static website tools play into a totally different ecosystem than their predecessors. Many of the constraints that made dynamic websites the best option for creating anything but the most basic online brochure have fallen away.

THE BROWSER IS GROWING UP

When Tim Berners-Lee launched the first website of the World Wide Web, a browser was a simple document viewer that could display hypertext, links and little else.

Today, we’re finally in the process of burying the last browser that has been holding the web back (RIP Internet Explorer 8). The modern browser is an operating system in its own right, no longer merely displaying documents downloaded from the web, but capable of running full-fledged web applications, making external calls to API, storing data locally, opening WebSockets to streaming servers, and even handling peer-to-peer connections to other browsers via WebRTC.

With the maturation of browsers, many features that used to require dynamic code running on a server can be moved entirely to the client. Want comments on your website? Add Disqus, Isso or Facebook comments. Want social integration? Add Twitter or Facebook’s JavaScript widget to your website. Want real-time data updating live on your website? Add a squirt of Firebase. Want search? Add Swiftype. Want to add live chat support? Slaaks is there.

The list goes on and on, as a whole ecosystem of purely browser-based add-ons to websites is emerging.

THE CDN IS GOING MAINSTREAM

When Akamai launched the first content delivery network in 1999, only the largest web properties in the world could afford to deliver their web assets from CDN edge nodes distributed all over the world. It wasn’t that long ago that CDNs were used only by companies at the scale of CNN and Facebook, rather than mere mortals.

While Akamai still has enterprise-level pricing, today anyone can sign up for Amazon AWS and put CloudFront on top of their website. Also, companies like Fastly, MaxCDN and CloudFlare offer CDN services at prices that even a small business can afford.

A static website can be readily deployed directly to a CDN and served straight from local caches near end users. Fiddling with the configuration still takes some time, and cache invalidation can be tricky, but it’s doable and can be completely automated with services such as ours

PERFORMANCE IS A MUST

The explosion of mobile devices has changed the face of the web in many ways. More and more visitors are coming to the web from a mobile device, sometimes on a 3G connection. Never has performance been as important as it is now.

We all know this data: 57% of online visitors will abandon a page if it takes longer than 3 seconds to load. People used to be willing to wait up to 10 seconds, but expectations are way higher today. And on mobile, where there’s no multi-tasking and little else to do, waiting for a website to load is so frustrating that more than 4% of people report that they’ve physically thrown their phone while using a slow mobile website!

No matter how much you optimize a dynamic website for performance or how many thousand of dollars you throw at it, it will never give you the same basic performance guarantee as a well-tuned static website hosted right on a CDN for a few bucks a month. With performance constantly growing in importance, it’s no wonder that developers are looking for ways to pre-generate their HTML, instead of letting the server spend time and resources on generating a page for every single HTTP request.

Static website generation also eliminates a lot of performance concerns during the development process.

If you’re building a dynamic database-driven website, the efficiency of the database queries you’re making is extremely important because they’ll need to be fast enough to run once for every single HTTP request. Even if a solid caching layer lies on top of your website, there’s often a risk that some requests will effectively work as cache-busters, triggering worst-case queries in the back end and causing the whole system to grind to a halt.

With a static-generated website, it doesn’t matter much if pulling content into a template takes a few seconds more or less: That only happens when you publish, and there will never be a performance penalty for end users.

The Final piece of the Puzzle

The final piece of the puzzle, however, is content editing. While working directly in Markdown in a text editor and pushing to GitHub is close to the ideal workflow for a front-end developer, it’s not something you’d get normal, non-technical end user to participate in.

Systems such as Contentful, Prismic.io and GatherContent decouple the CMS layer from the actual website builder. This makes them really interesting tools for multi-channel content management, where you’re writing content not just for a particular website, but also for a mobile app, a Facebook page or a white paper. Publishing new content triggers a webhook in a build system; then, a static website generator runs the build and fetches data from the content API; and the result is pushed straight to a CDN.

The ultimate answer is an open-source Static CMS system without any lock-in to a particular static website generator, Git host or hosting platform. It will be a great way to push the limit of what kind of website you can build with modern static website technology.

Here is a initial attempt to tackle a Static CMS system WebriQ Static Web CMS Application