Acro Media: Drupal Point of Sale 8 Released!

Planet Drupal - Thu, 2018/06/14 - 2:28am
Official 8.0 Version Now Available


The Drupal Point of Sale provides a point of sale (POS) interface for Drupal Commerce, allowing in-person transactions via cash or card, returns, multiple registers and locations, and EOD reporting. It’s completely integrated with Drupal Commerce and uses the same products, customers, and orders between both systems. You can now bring your Drupal 8 online store and your physical store locations onto the same platform; maintaining a single data point.

The Drupal 7 version has been in the wild for a while now, but today marks the official, production ready release for Drupal 8.

Release Highlights

What features make up the new version of Drupal Point of Sale 8? There are so many that it will probably surprise you!

Omnichannel

Omnichannel is not just a buzzword, but a word that describes handling your online and offline stores with one platform, connecting your sales, stock and fulfillment centers in one digital location. Drupal Commerce has multi-store capabilities out of the box that allow you to create unique stores and share whatever product inventory, stock, promotions, and more between them. Drupal Point of Sale gives you the final tool you need to handle in-person transactions in a physical storefront location, all using your single Drupal Commerce platform. That’s pretty powerful stuff. Watch these videos (here and here) to learn more about how Drupal Commerce is true omnichannel.

Registers

Set up new registers with ease. Whether you have 1 or 1000 store locations, each store can have as many registers as you want. Because Drupal Point of Sale is a web-based solution, all you need to use a register is a web browser. A touch screen all-in-one computer, a laptop, an iPad; if it has a web browser, it can be your register. The Point of Sale is also fully open source, so there are no licensing fees and costs do not add up as you add more registers.

Customer Display


While a cashier is ringing through products, the Customer Display uses WebSocket technology to display the product, price, and current totals on a screen in real-time so the customer can follow along from the other side of the counter. Your customers can instantly verify everything you’re adding to the cart. All you need for the Customer Display is a web browser, so you can use an iPad, a TV or second monitor to display the information in real-time as the transaction progresses.

Barcode Scanning

Camera based barcode scanning
Don’t have a barcode scanner? No problem. With this release, any browser connected camera can be used to scan barcodes. Use a webcam, use your phone, use an iPad, whatever! If it has a camera, it works. This is helpful when you’re at an event or working a tradeshow and you don’t want to bring your hardware along.


Traditional barcode scanning
A traditional barcode scanner works too. Simply use the barcode scanner to scan the physical product’s barcode. The matching UPC code attached to one of your Drupal Commerce product variations will instantly add the product to your cashier’s display.

Labels

Generate and print labels complete with barcodes, directly from your Drupal Point of Sale interface. Labels are template based and can be easily customized to match any printer or label size so you can prep inventory or re-label goods as needed.

Receipts

Easily customize the header and footer of your receipts using the built in editor. Add your logo and contact information, return/exchange policy, special messaging or promotions, etc.

When issuing receipts, you can choose to print the receipt in a traditional fashion or go paperless and email it to your customer. You can do either, both, or none… whatever you want.

Returns

Whether online or in store, all of your orders are captured in Drupal Commerce and so can be returned, with or without the original receipt. A return can be an entire order or an individual product.

End of Day (EOD) Reports

When closing a register, you cashiers can declare their totals for the day. You can quickly see if you’re over or short. When finished, an ongoing daily report is collected that you can look back on. On top of this, Drupal Point of Sale is integrated with the core Drupal Commerce Reporting suite.

Hardware

Use Drupal POS 8 with anything that supports a browser and has an internet connection.

Technical Highlights

Adding to all of the user highlights above are a number of important technical improvements. It’s the underlying architecture that really makes Drupal Point of Sale shine.

Themable

Cashiers login to Drupal Point of Sale via a designed login page. Once logged in, the theme used is the default Drupal admin theme. However, like any other part of Drupal, your admin theme can be modified as much as you like. Keep it default or customize it to your brand; it’s yours to do with as you please.

Search API Enabled

The search API is a powerful search engine that lets you customize exactly what information is searchable. Using the Search API, your cashiers are sure to quickly find any product in your inventory by searching for a product’s title, SKU, UPC code (via barcode scanner), description, etc. Search API is completely customizable, so any additional unique search requirements can be easily added (brand, color, weight, etc.). The search API references the products on your site, and at any other store or multi-warehouse location to allow for you to serve customers in real-time. 

Fully Integrated with Drupal Commerce

The Drupal Point of Sale module seamlessly integrates into the existing Drupal Commerce systems and architecture. It shares products, stock, customers, orders, promotions and more. This makes Drupal Point of Sale plug-and-play while also making sure that the code base is maintainable and can take advantage of future Drupal Commerce features and improvements.

Permissions and Roles

When Drupal Point of Sale is installed, a “cashier” user role is created that limits the access users of this type have with your Drupal Commerce backend. Use Drupal’s fine grained permissions and roles system to manage your cashiers and give different permissions to employees, managers, marketers, owners, IT, etc. Any way you want it.

Custom Hardware

As mentioned above, all you need to use Drupal POS 8 is anything that supports a browser and has an internet connection. This opens the door for all kinds of custom Point of Sale hardware such as branded terminals, self-serve kiosks, tradeshow-ready hardware, and more.

We’ve been having fun prototyping various Raspberry Pi based POS hardware solutions. You can see some of them here and stay tuned for more. Drupal Point of Sale is open source, so why not open up the hardware too?

Drupal Point of Sale 8, Ready for your Drupal Commerce platform

We’re excited to finally release the production ready version of Drupal Point of Sale 8.0. There are many ecommerce-only platforms out there, but almost none of them can ALSO run in your physical store too. This is a BIG DEAL. Drupal Point of Sale gives you the last piece needed to run your entire store using Drupal Commerce allowing for centralized data and a single system for your team to learn and manage.

One admin login, one inventory list, one user list, one marketing platform, ONE. True omnichannel, without the fees.

Next Step

Commerce Kickstart
Starting a Drupal Commerce project from scratch? Use Commerce Kickstart to configure your install package (including Drupal Point of Sale).

Install with Composer
Already using Commerce for Drupal 8? Install Drupal Point of Sale with Composer.

$ composer require drupal/commerce_pos

Let Acro Media help
Acro Media is North America’s #1 Drupal Commerce provider. We build enterprise commerce using open source solutions. Unsure if Drupal Commerce and Drupal Point of Sale meet your business requirements? A teammate here at Acro Media would be happy to walk you through a replatforming evaluation exercise and provide you with the Point of Sale workbook to help you make your decision.

More from Acro Media
Categories:

Lullabot: A Hierarchy of Software Quality

Planet Drupal - Wed, 2018/06/13 - 10:12pm

Our sales team often refers to our Hierarchy of Qualification when evaluating projects. This pyramid, inspired by Maslow’s hierarchy of needs, gives us the tools not just to evaluate the business needs of a project, but the human needs that are “encoded” in the project and team.

I’ve been thinking about how this applies to software development, particularly in the enterprise space. Enterprise implies that the software is maintained by large teams over long periods of time. Most developers have encountered internal enterprise software that leaves us shaking our heads, asking “how was this ever released?” Alternatively, we’ve used an internal tool that is quite good, but where the business has trouble repeating that success with new projects.

If we can describe the path towards self-actualizing software quality, we can elevate our teams from solving a series of one-off problems towards building value for our businesses and ourselves. It’s important to acknowledge that these steps are additive, meaning a team may benefit by mastering the lower rungs of the pyramid before moving on to the next.

undefined Describing software and how humans will use it

This is the base of the pyramid and undergirds everything else. Before writing a line of code, a team needs to have a good handle on who the audience is and how the software will affect them, along with the overall goals of the new project. Often, enterprise teams are given work to do by their customers or their management with the explanation: “a big internal department has told us this is a blocker, so don’t ask why and get to coding, so we aren’t late.”

This leaves project managers and developers in the dark, and unable to make reasonable guesses when requirements and technology conflict. Knowing the audience lets teams prioritize their work when time is short. Is the audience a group of editorial users? What’s their day-to-day workflow like? In that case, time may be best spent on testing and iterating the user interface, at the expense of implementing every last feature request. Is the audience another group of developers? Then perhaps the project doesn’t require a user interface initially, so developers can focus on great APIs and documentation. Not knowing the audience may lead to otherwise avoidable mistakes.

Like audience, project or product goals are another important piece of the puzzle. When goals are fuzzy, it is hard to know when a software project is done, or at least at a “1.0” release. Teams tend to leave projects at a nebulous “0.x” version, making future developers uncertain about the quality or robustness of a system. For example, perhaps a client asks to implement Apple News and Facebook Instant Articles on their website. It’s a reasonable request. Nevertheless, prematurely ending requirements gathering at “implement the feature” deprives your team of critical information.

There’s a business reason behind the request. Is the analytics team seeing declining traffic on their website, and worried the website audience is defecting to social networks? It may be good to suggest working on Facebook integration first, assuming you have some analytics data from existing Facebook posts to back it up. Or, perhaps the sales team is hearing from advertisers that they want to purchase ads against your content inside of the Apple News app. In that case, finding out some rough estimates for the additional ad revenue the sales team expects can help with qualifying estimates for the integration effort. If the estimated development budget eclipses the expected revenues, the team can investigate different implementation methods to bring costs down, or even rework the implementation as a one-off proof of concept.

Using audiences and goals to guide your development team makes it possible to discover opportunities beyond the immediate code, elevating the team from an “IT expense” to a “technical partner.”

Technical architecture and documentation

Writing the right software for today is one thing. Writing maintainable software that future developers can easily iterate on is another. Spaghetti architecture can leave you with software that works for now but is very expensive to maintain. For Drupal sites, that means avoiding god-objects (and services), writing true object-oriented code (and not procedural code that happens to live in classes), and avoiding side effects such as global and public variables. It’s important to document (preferably in code) not just what you built but why you built it, and how the architecture works to solve the original business problems. Think of it as writing a letter to your future self, or to whatever team inherits your code.

Determining the effort to put into this work is tricky, and time pressures can lead to quickly written, but poorly architected software. It’s useful to think about the expected life of the application. Look at similar applications in the company and ask about their initial and current development. For example, in our CMS projects, we often find we are replacing systems that are over a decade old. The code has gone through many teams of developers but is in a decrepit state as the architecture doesn’t follow common design patterns and the documentation is non-existent. No one wants to touch the existing application or infrastructure because experience has shown that may lead to a multi-day outage.

In cases like this, we know that following good design patterns and effectively documenting code will pay dividends later. A marketing site for an event in 3 months? You can probably take a lot of shortcuts without risk. Treat the project for what it is—a startup within an enterprise.

A culture of iterative feedback

Defining the software to write and following good architecture in its execution is important but we can do more. Now that our efforts are well documented, its time to create a proper harness for testing. Without one, it’s impossible to know if your team is meeting your quality goals. It’s easy for teams to fall into a fragile, untrustworthy process for testing. For sites, that typically means not defining and following deployment best practices or creating a QA bottleneck through infrastructure.

The typical git model of development implies not just a few branches that are merge destinations (like master and develop) but many feature branches, too. It’s not uncommon for developers to create multiple branches breaking a single ticket into smaller code components that can be independently reviewed and tested.

For developers, “waiting for a QA build” is one of the biggest motivation killers they face. For QA, trying to coordinate testing of various features onto a single QA server is complex and leaves them questioning the validity of their test plans.

Just as “smaller, chunkier” pull requests are a best practice for developers, a similar guideline helps QA analysts feel confident when certifying a feature or release.

Tugboat is one tool that lets teams implement automatic, lightweight, and disposable testing environments. When a developer opens a pull request, a complete working copy of the website is built and available for anyone with access to poke at. It’s easy to rebuild new testing environments because the setup is automated and repeatable—not manual. A process like this extends the effective QA team by including both developers (who can reproduce and take ownership of bugs “live” with QA, before code is merged), and the actual patrons of the build—project managers and business stakeholders—who will eventually need to sign off on the product.

These tools also change the culture of communication between stakeholders and implementation teams. Even with two-week sprints, there still can be an information gap stakeholders face between sprint planning and the sprint demo. Instead, getting their feedback is as frictionless as sending a link. There are fewer surprises at demos because stakeholders have already seen the constituent parts of the work that compose the whole demo.

Automated tests and quality metrics

Frictionless QA is great, but it’s still a manual process. It’s incredibly frustrating for an entire team to be going through manual QA for regression testing. Sometimes, regression tests uncover the sort of bugs that mean “rewrite the feature from scratch,” leading to failed sprints and missed demos. That’s especially likely when regression testing occurs at the end of a sprint, leaving precious little time for rework and another round of QA.

In contrast, developers love when automated tests alert them to issues. Not only does it save developers and QA time (they can work on a new ticket while waiting for a test suite to run), but it reduces the cognitive load of developing a new feature in a complex application. Instead of developers having to become the application experts, and maintain that knowledge in perpetuity, the automated tests themselves become the legal description of how the code should work.

Comprehensive test coverage, regardless of the actual tool used (like PHPUnit or Behat), also helps ensure that software quality remains constant as underlying dependencies are upgraded. For a Drupal site, teams should expect at least two significant upgrades of Drupal per year, along with an update to PHP itself. Automated testing means the initial work is as simple as “upgrade Drupal, run tests, and see what breaks,” instead of throwing a bunch of time and money at manual testing. It also means that testing of security patches is much faster, saving time between vulnerability disclosure and deployment.

Of course, there’s a cost to automated testing. Tests are still code that need to be maintained. Tests can be buggy themselves (like that time I accidentally tested for the current year in a string, which broke when 2018 rolled around). Someone has to pay for a continuous integration service or maintain custom infrastructure. Reducing these costs is a particular interest of ours, leading to templates like Drupal 8 CI and the Drupal Testing Container.

Again, knowing the expected life of the software you write helps to inform how deep into testing to go. I don’t think I’ve ever written automated tests for a microsite but for a multi-step payment form expected to endure for 5 years, they were critical.

Technical architecture, for all of its focus on “clean code,” can rapidly devolve into unresolvable conflicts within a team. After all, everyone has their idea of what “good design” looks like. While automated tools can’t tell you (yet) if you’re using the right design pattern to solve a given problem, they can tell you if your app is getting better or worse over time.

Start with enforcing basic code standards within your team. Code standards help team members to read code written by others, which is “step 0” in evaluating if a given codebase meets quality goals or not.

For example:

As a technical      architect, you       want reading the          code to feel as natural as             reading written text — so you            can focus on the meaning, and not       the individual words.

Think about how much harder it is to focus on the idea I’m trying to communicate. Even though you can understand it, you have to slow down and focus. Writing code without code standards sacrifices future comprehension at the altar of expediency. I’ve seen teams miss critical application bugs even though they were hiding in plain sight due to poor code formatting.

Luckily, while different projects may have different standards, they tend to be internally consistent. I compare it to reading different books with different fonts and layouts. You may have to context switch between them, but you would rarely have the paragraphs of the books interspersed with each other.

While code standards tend to either be “right” or “wrong,” code quality metrics are much more of an art than a science—at least, as far as interpreting and applying them to a project goes. I like to use PhpMetrics as it has a very nice user interface (and works perfectly within continuous integration tools). These reports inherently involve some subjective measure of what a failure is. Is the cyclomatic complexity of a method a fail at 15, or 50, or not at all? Sometimes, with difficult codebases, the goals come down to “not making things any worse.” Whatever your team decides, using these tools daily will help ensure that your team delivers the best product it can.

Continuous delivery

As a team addresses each new layer of the hierarchy, the lower layers become habits that don’t require day-to-day focus. The team can start to focus on solving business problems quickly, becoming an IT partner instead of an IT expense. Each person can fully participate in the business instead of the narrow field in front of them.

With all of these prerequisites in place, you will start to see a shift in how your team approaches application development. Instead of a conservative and fragile approach to development, your team will start to design and develop applications without fear. Many teams find themselves rotating between the bottom two levels of the pyramid. With careful planning and hard work, teams can work towards the upper tiers. The whole software delivery process—from ideas to releases to hotfixes to security releases—becomes a habit rather than a scramble every time.

Hero Image Photo by Ricardo Gomez Angel on Unsplash

Categories:

Appnovation Technologies: Blazing Fast Drupal Workflow

Planet Drupal - Wed, 2018/06/13 - 8:34pm
Blazing Fast Drupal Workflow Why we need to improve our tools We are living exciting times as web developers. Nowadays, many great tools are available to develop and deploy Drupal websites. However, it is still hard to find your own way through the countless software and platforms available out there. Productivity depends on your tools and your workflow. Carefully picking softwa...
Categories:

Electric Citizen: Electric Citizen Presents...

Planet Drupal - Wed, 2018/06/13 - 5:20pm

Twin Cities Drupal Camp 2018 just happened and Electric Citizen were able to present no less than four sessions on subjects ranging from Drupal search, configuration management, local development environments and dealing with emerging tech.

Just some of the folks who showed up for camp this year
Categories:

Drupal Association blog: Meet the Drupal Association 2018 At-Large Board Member Candidates

Planet Drupal - Wed, 2018/06/13 - 2:24pm

Did you know you have a say in who is on the Drupal Association Board? Each year, the Drupal community votes in a member who serves two years on the board. It’s your chance to decide which community voice you want to represent you in discussions that set the strategic direction for the Drupal Association. Go here for more details.

Voting takes place from July 2 until July 13. Anyone who has a Drupal.org profile page and has logged in to their account in the last year is eligible to vote. This year, there are candidates from around the world. Now it’s time for you to meet them.

Meet The Candidates

We just concluded the phase where nine candidates nominated themselves from six different continents for the board seat. From now through July 2, we encourage you to check out each person’s candidate profile, where they explain which board discussion topics they are most passionate about and what perspectives they will bring to the board.

This year, we asked candidates to include a short video - a statement of candidacy - that summarizes why you should vote for them. Be sure to check them out. Videos are found in the candidate’s profile as well as here:

What To Consider

When reviewing the candidates, it is helpful to know what the board is focusing on over the next year or two, so you can decide who can best represent you.

Here are the key topics the board will focus on.

  • Strengthening Drupal Association’s sustainability. The board discusses how the Association can improve its financial health while expanding its mission work.

  • Understanding what the Project needs to move forward and determine how the Association can help meet those needs through Drupal.org and DrupalCon.

  • Growing Drupal adoption through our own channels and partner channels.

  • Developing the strategic direction for DrupalCon and Drupal.org.

There are certain duties that a candidate must be able to perform as a board member. The three legal obligations are duty of care, duty of loyalty, and duty of obedience. In addition to these legal obligations, there is a lot of practical work that the board undertakes. These generally fall under the fiduciary responsibilities and include:

  • overseeing Financial Performance

  • setting Strategy

  • setting and Reviewing Legal Policies

  • fundraising

  • managing the Executive Director

Hopefully providing this context gives you a helpful way to assess the candidates as you decide how to vote From July 2 until July 13.

We encourage you to ask the candidates questions. Use comments to leave a question on their candidate profile page.

Categories:

Agiledrop.com Blog: AGILEDROP: Our blog posts from May

Planet Drupal - Wed, 2018/06/13 - 12:22pm
You have already seen what Drupal blogs were trending in the previous month, and now it is time to look at all our blog post we wrote. Here are the blog topics we covered in May.   The first blog post was How to Integrate Google Analytics with Drupal 8. It’s really important to keep track of the statistics of your websites. One tool that stands out and probably beats all others in terms of popularity when it comes to website analytics is Google Analytics. In this blog posts, we looked at how you can integrate Google Analytics with Drupal, specifically with Drupal 8.    The second was a … READ MORE
Categories:

Droptica: Droptica: Effective software delivery? Remote SCRUM team

Planet Drupal - Wed, 2018/06/13 - 11:05am
The deadline is today. A remote development team have worked for several weeks on your software. You obtain the long-awaited access to the system. You check it and you are not satisfied with the achieved results. All that was needed to avoid this problem is a team with experience in technology and working using SCRUM. What is SCRUM Wikipedia defines SCRUM as an agile framework for managing work. It is an approach used in many companies to develop software. Full definition can be found here https://en.wikipedia.org/wiki/Scrum SCRUM solves most of the problems arising during software development This is my opinion and many people agree with it. I have been developing commercial projects since 2008. I started as a programmer. Currently, I am supervising high-level projects.
Categories:

clemens-tolboom commented on pull request jithurjacob/vscode-nbpreviewer#7

On github - Wed, 2018/06/13 - 8:15am
clemens-tolboom commented on pull request jithurjacob/vscode-nbpreviewer#7 Jun 13, 2018 clemens-tolboom commented Jun 13, 2018

Very quick response :-) What I meant was to only commit the file src/notebookjs/notebook.js as that contains your fix. Other changed files are code…

Freelock : Freelock Named Top Web Developer in Seattle on Clutch & The Manifest!

Planet Drupal - Tue, 2018/06/12 - 9:30pm
Freelock Named Top Web Developer in Seattle on Clutch & The Manifest! Submitted by Don Dill on Tue, 06/12/2018 - 13:30

Here at Freelock, we are all in for web development. Truly, what could be more important for our clients in today's climate than a properly functioning and safe website? We are pleased to share that our expertise has paid off as we have been identified again an industry leader by Clutch. 

Agile Awards Business Client Drupal Planet feedback Project Management Quality Assurance Results
Categories:

clemens-tolboom commented on pull request jithurjacob/vscode-nbpreviewer#7

On github - Tue, 2018/06/12 - 6:10pm
clemens-tolboom commented on pull request jithurjacob/vscode-nbpreviewer#7 Jun 12, 2018 clemens-tolboom commented Jun 12, 2018

Having a separate feature branch could also help to review and merge a PR :-)

clemens-tolboom commented on pull request jithurjacob/vscode-nbpreviewer#7

On github - Tue, 2018/06/12 - 6:09pm
clemens-tolboom commented on pull request jithurjacob/vscode-nbpreviewer#7 Jun 12, 2018 clemens-tolboom commented Jun 12, 2018

The bug fix is 4 lines; the PR contains ~3000 changes ... huh!? Did you make a push mistake adding lot's of formatting and .lock file?

clemens-tolboom pushed to patch-1 in clemens-tolboom/ipyleaflet

On github - Tue, 2018/06/12 - 6:01pm
clemens-tolboom pushed to patch-1 in clemens-tolboom/ipyleaflet Jun 12, 2018 1 commit to patch-1

clemens-tolboom commented on issue jupyter-widgets/ipyleaflet#173

On github - Tue, 2018/06/12 - 5:58pm
clemens-tolboom commented on issue jupyter-widgets/ipyleaflet#173 Jun 12, 2018 clemens-tolboom commented Jun 12, 2018

I get the same report but succesfull map > jupyter nbextension list Known nbextensions: config dir: /Users/.../bin/../etc/jupyter/nbconfig notebook…

Specbee: Why We Love Web Accessibility With Drupal 8 : Why You Should Care Too

Planet Drupal - Tue, 2018/06/12 - 3:03pm
Why We Love Web Accessibility With Drupal 8 : Why You Should Care Too
  • By : Ganesh
  • Date :12-06-2018
Categories:

Amazee Labs: Zurich Drupal Meetup - June

Planet Drupal - Tue, 2018/06/12 - 2:37pm
Zurich Drupal Meetup - June

Join us on Wednesday, at Gridonic, for the upcoming Zurich Drupal user group meetup.

Anli de Jager Tue, 06/12/2018 - 14:37

The gathering is dedicated to all those interested in Drupal. Everyone, from beginners to experts, are more than welcome.

Hope to see you there!

Date and time: Wednesday, June 13, 2018, from 6:30 PM to 9:00 PM

Venue: Gridonic - Ernastrasse 22, Zürich

Categories:

Vardot: 6 Reasons Why Leading News and Media Networks are Using Drupal 8

Planet Drupal - Tue, 2018/06/12 - 1:03pm
Ahmed Jarrar June 12, 2018

The world’s top news and media networks operate different sites to targeting a wide audience. They know that the only thing better than playing to a niche market is playing to all the niche markets --by running multiple websites tailor-made to fit the preferences of their different market segments, they play to win.

This kind of business model takes effort. Their content has to be distributed in multiple languages and reworked to fit different cultures. Naturally, it takes the right CMS to be able to pull this off while still managing to be user-friendly (after all, new content pops up every hour of a given day).

This article will cover the reasons why leading news and media outlets opt for Drupal 8, choosing the framework for all other alternatives in the market. Read on to find out why Drupal is trusted by 73% of the top news and media networks (including Al Jazeera, the Walt Disney Company, Time Inc., The Economist, Twenty-First Century, CBS, and Viacom) are using it.

 

Drupal 8 is Optimized for a 24 Hour News Cycle

 

The news cycle is both the greatest and worst thing to ever happen to news media. On one hand, it guarantees a steady stream of content, and therefore opportunities to earn from subscriptions and ad space. On the other hand, news media practitioners are almost always on the clock.

The freshness of a news item is time-sensitive and highly dependent on presentation (nobody wants to read a poorly-presented article, for instance). This is why a CMS like Drupal 8, which offers core features straight out of the box, is preferred among newsmen. For example, Drupal offers a rich media editor for the content creation stage of editorial work.

Drupal’s functionality also extends beyond the newsroom, with offerings such as monetization tools, social media integration, and near-universal 3rd party integration.

 

Drupal 8 is Easy to Personalize and Localize

 

Personalization is the key to engaging with an audience. Users want to see content that appeals to their interests and challenges them to discover new information. Naturally, timing is also a major factor; a news site that is aware of their readers’ most active times can take full advantage of things like push notifications, and special offers to exclusive content.

Beyond this, news agencies need to be able to push content that appeals to a person’s sense of locality --people are naturally drawn to things that might have an impact on their lives directly. While there’s no contesting the average person’s curiosity about distant happenings, top news and media networks know how to tap into the power of the parochial mindset.

Drupal enables personalization through a suite of powerful tools designed by its large community of developers. The platform makes it easy to connect readers to the kinds of content that align with their interests. Likewise, localizing content is a necessity made accessible through the platform --nurturing a loyal following is easier with Drupal 8, which allows your content to be relevant to events that take place in their immediate surroundings.

 

Drupal 8 Allows for Convenient Multi-Site Management

 

Running multiple websites is easy with Drupal. The platform allows businesses to run multiple websites grounded in the same code base. In plain English, you don’t need to build websites from scratch every time you want to expand your base of captive niches, and you can apply the same brand of aesthetic and experiential quality to your different digital holdings.

Drupal offers a multi-site management solution, complete with tutorials, that makes the job of expanding a news empire about as accessible designing a blog. Put this together with Drupal’s offer of news and media distribution solutions straight from the box, and sprawling online presences for news agencies can grow virtually overnight.

Drupal 8 is Secure

Security is a natural concern for any organization, and news companies are no exception. Nobody wants to lose credibility in the face of a cyber attack, or worse, have their subscribers’ data leaked.
One of the pivotal reasons why the media prefers Drupal is the long tradition of security that surrounds the platform. Between the swarms of developers working to close every loophole and patch over every possible entry point and the dedicated team of security specialists attached to Drupal, the framework does an excellent job of guaranteeing its users’ security.

 

Case Study: Uber Publisher & Al Jazeera

 

We mentioned Al Jazeera among the list of news agencies that rely on Drupal for their CMS needs. They were generous enough to agree to serve as an extensive case study on the official Drupal website, and some of the major takeaways do a good job of proving how the platform is a good fit for the industry.

The case study banks on the news agency’s growth after their tie-in with Drupal. It also describes how the agency met their myriad goals, including the unification of AJMN’s digital assets and workflows into a single interface. All told, the decision to opt for Drupal was a success for Al Jazeera.

Now, what the case study didn’t cover was Al Jazeera’s decision to opt for one Drupal-based solution in particular: Uber Publisher, a sub-profile of Varbase. Uber Publisher is a Drupal distribution that contains over a thousand out-of-the-box features and is continuously funded, supported, and improved by Vardot --and likely a contributing factor to Al Jazeera’s digital success. Its features for media marketing, automated tagging, easy authoring, and SEO make it a potent tool in the hands of a business of any size.

 

Conclusion

Drupal 8 is an optimal solution for news and media networks, regardless of their size. It’s affordable, convenient, and easy to both implement and maintain over the lifespan of a media agency. A good network would do well to tap into the functionality that Drupal has to offer, and a great one would scan the market for tools such like Vardot’s Uber Publisher; with any luck, they’ll meet the same digital success as Al Jazeera and its cohort (or exceed it).

Categories:

clemens-tolboom starred thangqd/HCMGIS

On github - Tue, 2018/06/12 - 9:22am
clemens-tolboom starred thangqd/HCMGIS Jun 12, 2018 thangqd/HCMGIS

HCMGIS QGIS3 Plugin

Python 2 Updated Jun 12