Russian MPs have reportedly asked regulators to investigate EA for an LBGTQ-inclusive FIFA 17 promo, alleging it turned the game into gay propaganda aimed at minors -- illegal under Russian law. ...
This is the eleventh installment of Palantir.net’s Guide to Digital Governance, a comprehensive guide intended to help get you started when developing a governance plan for your institution’s digital communications.In this post we will cover...
- Questions you should consider specifically related to private websites
- Why you should think about whether your private site should be a part of your public site
- Why it's important to serve the needs of site users
We want to make your project a success.Let's Chat.
Most organizations these days have some form of private area for only staff, group members, constituents, partners, vendors, etc. These sites are sometimes guarded behind a firewall and a user authentication system, sometimes just user authentication, and sometimes simply hidden by obscurity. Most often, though, you can identify one of these types of sites because it requires a login and password and is not generally accessible by the public.
Most of the previous questions, regarding content, organization and design are relevant to internal Web properties as well, but here are a few questions you may want to ask yourself specifically with regard to private websites, intranets, and internal-facing portals:
- Who owns each one? If they are shared responsibilities, what are the parts and who owns each part?
- How are accounts distributed and access granted?
- Who determines access and account creation?
- What is the process for account creation?
- What is the criteria for gaining access via an account?
- Do user accounts have different roles with different permissions?
- Who are the content editors and creators within the site?
- How is the site edited and maintained?
- Are there any workflows or approval processes for content?
- What distinguishes content that is appropriate for external channels from content that is only appropriate for internal channels?
- Who will be responsible for determining what is appropriate? And how will they enforce those rules?
Public vs Private
Another important consideration for private websites and intranets, especially if you are planning to build one or redevelop your public website, is whether or not an intranet (or a private website) should be a part of your public website. In other words, should the same system for administering and maintaining your public website be the same system as your intranet or private website?
On the surface, the simple answer may appear to be, “Of course! Wouldn’t that be the most simple and streamlined approach?” Once you dig into the requirements of what you need for your private site, and compare that with the purpose of your public site, you may determine otherwise.
The most common purpose for a public website is to communicate information about your organization to a range of audiences, many of whom are not currently part of your organization. In fact, the primary purpose of your public website, specifically, may be to attract those who are not part of your organization in order to convince them to become part of it. In short, your public website’s primary purpose is likely to be a marketing tool for expanding your message and growing your constituency (membership, clientele, user-base, however you think of them). There is not typically a lot of functional interaction that happens between user and website at this stage, aside from asking visitors to contact you, sign-up up for something, attend an event, purchase a product, or some other interaction that is typically managed by a relatively basic form.
In other words, the necessary functionality for a public, marketing website tends to be fairly light in terms of the weight of its programming logic and requirements.
Intranets and private websites tend to be a different animal. Being private, by definition, means they need to support accounts for users. Having a lot of users logging into a system presents a number of challenges and requirements that can become quite complex. A heavier set of tools are often required, adding more software to the system.
Given that users and authentication credentials are involved, often integrations with user databases or user management systems may be involved, and almost certainly, a higher level of security and encryption becomes necessary.
Usually, when you have a private site or intranet, the needs of users become more transactional than consumption marketing information. Once a user is a member, they no longer need to be sold on the organization; they need to “do” things through the website – use tools, access account information, transmit or receive private data, etc. All of these things require deeper levels of programming, security, and the infrastructure to support it – a lot more heft and complexity than what you need for your marketing website, which probably benefits most from being nimble and quick to deliver relevant content.
Perhaps most important, though, is the organization of information – and this is where many projects that aim to combine a public website with a private intranet get bogged down. Since the two sites address the needs of largely different audiences, the menuing and navigation in sites that aim to serve both public and private needs are often in conflict with themselves.
Rarely do you want to show navigation, menuing, or content to the public which is meant only for private users. However, how do you then present the private content and way-finding to authenticated users without breaking a design that, in theory, looks appropriate for only the public content and navigation?
As you get into the details of accommodating both public and private needs on a website, what you often find is that you make odd compromises to things you ordinarily wouldn’t (like usability of the site), in order to make the two work together. In truth, given that the audiences for the two sites may have very different needs, and the websites need to serve very different purposes, it is often wise to separate the two, even if that means support of two separate systems. In the end, it is better to serve the needs of the users, such that they can be successful using your websites.
This post is part of a larger series of posts, which make up a Guide to Digital Governance Planning. The sections follow a specific order intended to help you start at a high-level of thinking and then focus on greater and greater levels of detail. The sections of the guide are as follows:
- Starting at the 10,000ft View – Define the digital ecosystem your governance planning will encompass.
- Properties and Platforms – Define all the sites, applications and tools that live in your digital ecosystem.
- Ownership – Consider who ultimately owns and is responsible for each site, application and tool.
- Intended Use – Establish the fundamental purpose for the use of each site, application and tool.
- Roles and Permissions – Define who should be able to do what in each system.
- Content – Understand how ownership and permissions should apply to content.
- Organization – Establish how the content in your digital properties should be organized and structured.
- URL Naming Conventions – Define how URL patterns should be structured in your websites.
- Design – Determine who owns and is responsible for the many aspects design plays in digital communications and properties.
- Personal Websites – Consider the relationship your organization should have with personal websites of members of your organization.
- Private Websites, Intranets and Portals – Determine the policies that should govern site which are not available to the public.
- Web-Based Applications – Consider use and ownership of web-based tools and applications.
- E-Commerce – Determine the role of e-commerce in your website.
- Broadcast Email – Establish guidelines for the use of broadcast email to constituents and customers.
- Social Media – Set standards for the establishment and use of social media tools within the organization.
- Digital Communications Governance – Keep the guidelines you create updated and relevant.
To err is human, and coders too, like us are humans and are bound to make mistakes while coding, especially if the needs of the project are complex and if they adhere to the true meaning of agile.
Adds a new field mapper to the Salesforce suite of modules to allow using a term reference field. Entity references for content are supported natively by the Salesforce modules, but term references are not unfortunately.
This code is almost entirely based on the work of Mike Christianson and he deserves the credit: http://codeaweso.me/2015/04/mapping-salesforce-object-fields-to-drupal-t...
This module integrates Login and Pay with Amazon with Drupal and Drupal Commerce.
Amazon Payments provides Amazon buyers a secure, trusted, and convenient way to log in and pay for their purchases on your site. Buyers use Login and Pay with Amazon to share their profile information (name and email address) and access the shipping and payment information stored in their Amazon account to complete their purchase. Learn more at
This article was initially posted as a guest blog on The Digital Echidna Blog on December 2, 2016.
Lots of organizations are working hard to see that their IT is accessible to their visitors and staff. Reducing barriers for effective two-way communications is really important for businesses that want to engage fully with their community. Unfortunately, many organizations overlook the many challenges with online web forms.
Organizations who adopted Drupal 7 benefit from having semantic labels associated with their web forms automatically. This is a particular problem with custom built web-forms, but the Drupal community made an effort towards solid accessibility defaults and continues to do so.
Drupal 8 takes web forms further, adding WAI-ARIA to provide additional semantic markup around descriptive text. Drupal 8 is the first CMS to embrace the HTML5 details/summary elements. These elements allows Drupal 8 forms to use fieldsets for what they are intended and avoids the problem of nested fieldsets, which were inevitable in earlier versions of Drupal.
Adding other HTML5 tags to Drupal Core helps build more semantic sites. Users are encouraged to use tags with meaning which help screen-reader users as well as search engines.
The Accessibility Team wasn’t satisfied with this and realized that we needed to address Guideline 3.3 of WCAG 2.0 AA, which states that all users need to:
- Be aware that an error has occurred and understand what is wrong
- Be given suggestions for correction of an input error if it is possible
- Be provided with safeguards to avoid serious consequences resulting from mistakes
- Have their input checked for errors and be provided an opportunity to correct them.
These really don’t sound that difficult, but unfortunately they are. Brandon Bowersox-Johnson spearheaded this back in 2012 outlining what needed to happen.
This required many changes to Drupal’s Form API, which is used on almost every Drupal admin page and with all of its web forms. An issue to address this was started later that year in the Drupal issue queue and Inline form errors for accessibility and UX resulted in over 600 comments over four years.
It also got into Drupal Core, although not for very long. It became clear that there were a number of regressions which were major enough that Drupal 8 could not be released without their being fixed. Rather than continue to hold up the release, the community decided to roll this back into an Experimental Core module.
This was absolutely the right call for 8.0. More attention has gone into the many sub-issues and several of them have been fixed. Drupal Core needs to be stable and predictable. Several developers have been very active in trying to fix these issues. In no particular order I’d like to highlight just some of the folks who have contributed to addressing these issues: Pieter Frenssen, Tim Plunkett, Baris Wanschers, Daniël Smidt, and Scott Carpenter.
There has been a lot of effort from some really smart folks going into this very important issue. Unfortunately it isn’t enough. Inline Form Errors need to be enabled by default. Everyone benefits from this better UI. Right now only a small fraction of Drupal 8 sites have enabled this module, because it is an optional Experimental Module and there are serious warnings included with it.
This module is also slated to be removed from Core and brought in as a regular Contrib module. There are good reasons to do this, but it makes it less likely that this improved pattern will ever get into Core.
This is not a trivial request, but it is an important one. For all agencies who are legally required to meet WCAG 2.0 AA, this is an area where your site likely fails. Although there are workarounds that can be done for individual sites and specific modules, we really need a centralized solution for this.
Please consider investing time or money in addressing this outstanding Drupal 8 meta issue and seeing that Drupal remains a leader in this space.Topic:
The Distance Cataloging Interface (DCI) was built as a way to collect and review feedback on specified content on a Drupal website from it's users.
On Friday, December 9 we are organizing a global virtual Drupal UX sprint. As always, many different features and projects are currently worked on. We'll use this day to work on issues that need UX input or feedback.What will happen that day?
Join the #ux channel on drupal.slack.com (get an invite automatically at http://drupalslack.herokuapp.com/) to participate all day.
- UX mentors will be available to help onboard designers who want to contribute
- We'll pair designers and devs (as available) to work on actionable tasks
- Planning to do some ad hoc usability testing
- An introduction to the main strategic initiatives and their UX components will be provided
You can join us even after the global UX sprint. We have meetings every Tuesday at 9pm CEST and every Wednesday at 9am CEST on the #ux Slack channel at drupal.slack.com (get an invite automatically at http://drupalslack.herokuapp.com/). Bring your issues there to discuss! CEST is the timezone observed in Amsterdam.
Here is where we bring awareness to Drupal modules running on less than 1% of reporting sites. Today we'll consider Markup, a module which allows you to insert additional markup on the node/edit form just for content authors.