Jul 11 2019
Jul 11

On September 12–14, at Hilton Garden Inn Atlanta-Buckhead

Kaleem Clarkson Kyle Mathews, 2019 DrupalCamp Atlanta Keynote

This year, DrupalCamp Atlanta is honored to welcome Kyle Mathews as our keynote speaker, creator of the open source project Gatsby. Gatsby was a hot topic at DrupalCon this year, and we’re ready to dive into the software at DrupalCamp this September.

Follow Kyle on Twitter and Github.

Session submissions are now open for DrupalCamp Atlanta 2019! With Kyle as our keynote, we’re interested to see how others are combining Drupal and Gatsby. In addition, we’re also accepting sessions in the following tracks:

  • Beginner
  • Design, Theming, and Usability
  • Development and Performance
  • Site Building
  • Business Leadership
  • Education and Training

Each session is 40 minutes with 10 minutes for Q&A. Each room will be set classroom style and will have a projection screen and with in house audio.

Trainings

In addition to 50-minute sessions, we’re also looking for volunteer trainers for our full day of trainings on Thursday (9/12) and a half day on Friday (9/13). Training sessions can range across all experience levels. You can submit your call for training here.

One of our goals for this year’s camp was to increase the number of case studies. We encourage web development companies and units to connect with their clients to co-present a session at this year’s DCATL.

We see this as an opportunity to re-engage with a client by highlighting the great work you have done together all while introducing them to the awesome Drupal community we have. So, reach out to some of our clients and propose a presentation today!

SUBMIT YOUR PROPOSAL HERE

May 21 2019
May 21

For website builders, the perennial debate between WordPress and Drupal rages on. As a Drupal-focused agency, it would be easy for us to promote Drupal’s benefits while badmouthing WordPress. Ultimately, though, that kind of thinking distracts form a more nuanced take on the debate: which CMS is best for you? While we’ve covered the comparisons between the two platforms before, it’s always worth revisiting the similarities and differences between them.

drupal-wordpress

Part of the reason why the “WordPress vs Drupal” narrative persists is because there is no definitive “winner.” Drupal and WordPress are both great tools that we’d have no problem recommending. In fact, the two platforms have more in common than you might realize. Both WordPress and Drupal are free, open source content management systems with vast ecosystems of contributed plugins and modules. Both are also sustained by communities of users and developers who continue to make each platform successful.

Ultimately, the choice between WordPress and Drupal comes down to you and your site’s requirements. Both platforms come with advantages and disadvantages depending on the task at hand, so it really is a case-by-case basis. Instead of boiling the matter down to “Drupal vs. WordPress,” consider the following comparisons against your needs to determine which platform is the best fit for your project.

Ease vs Order

Imagine that you want to publish a new piece of content on the site. If you’re just trying to, say, publish a blog on your site as quickly as you can, it’s hard to beat WordPress. With its simple-to-use interface, WordPress streamlines the content management process and makes it easier for editors to swiftly publish or edit a basic story.

On the other hand, if you have content originating from multiple sources and you want to be able to publish across channels, consider the Drupal CMS. While slightly more difficult to master, the Drupal back end can handle varying data types and keep them organized. Essentially, if you are managing multiple sites or are publishing more complex content types, Drupal’s has the power to deliver a robust, seamless experience.

Model vs. Building Blocks

Consider a model kit. If you follow the directions and don’t deviate, you’ll end up with a sleek and stylish figure. WordPress is very much the same. Sites built using WordPress are specially optimized for easy posting and content creation. If your needs are contained and fit within the boundaries of what WordPress was designed to do, it’s a perfect out-of-the-box solution.

Adding custom features to a WordPress site, however, can be complicated. This is not the case with Drupal, which is more akin to building blocks than to a model. Much like a field of Lego bricks strewn on the floor, Drupal allows for so much customization that you may not even know where to start. Once you have a plan, though, a Drupal site can be configured to your exact specifications while still leaving room for changes later.

Solo vs Team

Because of its aforementioned ease-of-use, WordPress gives plenty of power to content creators. If you stick to OOTB functionality, you can manage an entire WordPress site on your own. Even the plugins and themes that you can add to a site can be updated with a click of a button, making routine maintenance easier.

Given its enterprise-level capabilities, Drupal is better suited to a site run by a team. Different roles with custom permissions can be assigned to different team members inside a Drupal site. These hierarchies can make it easier to collaborate on a site and ensure that there’s accountability throughout the development process.

Pages vs. Architecture

Even without any technical experience, a content creator could easily design a page on a WordPress site. The OOTB editing suite allows you to build and layout rich pages with text, images and other assets that you can quickly deploy and publish.

Though Drupal has taken strides to make their page layout builder more accessible, creating pages in Drupal takes some practice. What Drupal has going for it is its structure. Drupal offers various levels of tagging and taxonomy that allow you to organize and repurpose content in endless permutations. Further, you can create custom content types in Drupal, expanding the possibilities of what kinds of content you can publish.  

What these comparisons illustrate isn’t that one platform is better than the other. Rather, they show that each tool has its own strengths and weaknesses depending on the situation. And in the end, your mileage may vary; our team has seen enterprise sites that run on WordPress and run on Drupal. It’s all about what each user wants and needs.

Duo specializes in Drupal because we like working with the CMS’s flexibility at an enterprise scale. If you think Drupal is right for you or if you still need help deciding, please feel free to reach out to us!

Explore Duo

May 16 2019
May 16

One of the best things about Drupal’s open-source ecosystem is that it empowers you to be open-minded. Given the vast array of solutions and modules available, users can customize their site to their whims. Alternatively, if you think up and code something new, your contributions can be shared online with other users. With all of the customization available, Drupal is a conducive platform for outside-the-box thinking.

federated search

Decoupling is a recent example of this philosophy. Where a standard Drupal website would feature a Drupal-powered front and backend, decoupling opens the door for a variety of possibilities. A decoupled site can utilize different platforms and technologies for both the front and backend. For example, a decoupled site could utilize Drupal’s backend CMS while running a React-powered frontend. Such is Drupal’s flexibility that it can power scores of different, user-facing channels from a single backend, including other sites, native apps, Internet of Things (IoT), and more.

This decoupled or “headless” concept has more applications than just for site design, though. The search function of a website, for one, can benefit from components that utilize this headless approach – and not a moment too soon. As Google has begun to sunset its Google Search Appliance offering, there is now a need for an open and flexible search tool with enterprise-level capabilities.

At this year’s Midwest Drupal Camp, the team from Palantir demonstrated that a decoupled approach to site search was viable. This solution, federated search, allows for indexing and searching across multiple sites. For organizations with a large web portfolio across different platforms, this open federated search solution can fill the gap left by Google.

Decoupled Drupal Facts & Myths

Understanding why federated search for Drupal is important requires an understanding of how regular site search functions operate. At the core, the search feature is built from three different components: the source, index and results. The source simply refers to all of the searchable content on a given site, from blogs to landing pages. The index is a compilation of metadata that makes the content form the source easier to parse. At Duo, we often use Apache Solr, a platform-agnostic, open source solution for indexing, as it provides speed, power and its own server capabilities. Finally, the results refers to the front-end experience that compiles and delivers the search results to the user.

The above setup will work fine for most simple websites, but larger organizations often require a more robust solution. With federated search, users can query across multiple sites across different platforms without placing much strain on Drupal, since Apache Solr is handling generating the index and providing results. This is accomplished through some tweaking of the basic site search formula.

Part of what makes this search so powerful is that it takes advantage of Drupal’s backend without relying on its frontend. For that, Apache Solr’s dedicated servers empower this new search solution by shouldering the burden of indexing and providing the results. Before it can work, though, some configuration is needed. Based on this configuration, Apache Solr can encompass searches across different sites – including sites that aren’t built with Drupal. Creating this custom solution, in conjunction with the Search API and Search API Solr modules, will ensure that the different data types being indexed will be standardized.  

As for the results section, the best approach is a decoupled one. Building out the front-end component in the React JavaScript library allows for robust searches without slowing down the rest of the site. By using Drupal’s CMS, Apache Solr and React’s power in coordination, any organization can create a search feature that quickly indexes vast ranges of data and delivers it in an easily digestible manner. For a deeper dive, Palantir has made their demo of federated search available.

This powerful and streamlined take on site search has a variety of applications. Before releasing the solution, Palantir originally developed federated search for the University of Michigan, as each department ran their own sites on different platforms. Federated search now allows users to seamlessly search for information across the entire school’s network, regardless of the technology used to deliver the content. Beyond university ecosystems, federated search also presents an opportunity for eCommerce. Using this solution, products from different vendors can be consolidated into a simple search.

Thanks to Drupal being open source, organizations can utilize federated search and any other contributed solution at any time. This level of openness is what makes Duo such champions of the Drupal platform. At Duo, we’re committed to exploring new features like this and helping each of our partners think outside the box. If you’re ready to start rethinking your website or sites, we’re just a click away.

Explore Duo

Apr 25 2019
Apr 25

Do you need to set up a custom image carousel? Or maybe one slider with a teaser, displaying content from your website? What are the best Drupal 8 slideshow modules to consider for implementing and maintaining your slideshow?

And out of the box options are... out of question, right? Your requirements are too specific for that.
Maybe you need:
 

  • a certain number of slider items
  • different arrow designs
  • to display the image slideshow on other pages, too, not just on your homepage
     

With such flexibility and customization requirements in mind, we started digging into the “pile” of Drupal 8 image slider modules.

And here are the 4 ones that we've selected, those with the best reviews in the Drupal community:
 

If it's a fully customized slideshow that you want to implement, Views Slideshow's the module you need.

It'll “spoil” you with tons of add-ons to select from and give your unmatched flexibility. From:
 

  • titles
  • to images
  • to teasers of the last X blog posts on your website
     

… you get to include any type of items in your carousel.

Furthermore, it's jQuery-powered and it allows you to configure different settings for each one of the views that you'll create.

Note: oh, yes, you'll need to be pretty comfortable using Views in order to leverage this module at its full capacity.

Some of its key features:
 

  • your slider can include and display the latest products added to your eCommerce website 
  • you can set up a news item slideshow (the latest X news articles published on your Drupal 8 website)
  • from the latest X blog entries to the latest videos, testimonials, forum posts etc., you're free to include any type of content in your slider...
     

Now, here's a very brief step-by-step on how you can set it up and use it to create your slideshow:
 

1.1. Install and enable the module

Once you've downloaded it from Drupal.org, installed and enabled it, make sure to download its corresponding ZIP folder on Github, as well.

Give your folder a new name  — /jquery.cycle/ — then start uploading all its files to the 
/libraries/ folder in the root of your Drupal website.
 

1.2. Set up your view

Time to create your slideshow now. For this, just go to Structure> Views>Add new view 
 

1.3. Publish your slideshow block

For this, go to Structure>Block layout and select the region on your website that you want your slider to get displayed on.
 

1.4. Create a new image style

As you can see, the images included in your slideshow are currently of different sizes. Therefore, they're not perfectly adjusted to fit the block region that you've chosen for your slider.

To solve this inconvenience, just go to Configuration>Image styles>Add Image style. 

There, you can create a new style, that will be shared by all the images included in your slideshow.
 

2. Slick Slider, One of the Most Popular Drupal 8 Slideshow Modules

Another one of Drupal's modules for creating custom image slideshows, that ships with a heavy load of options. Powerful and flexible... what more could you ask for from your slider solution?

Capitalizing on Ken Wheeler's Slick carousel, working perfectly with Views and fields, the Slick Slider module:
 

  • enables you to set up a slider including multiple views, value fields and paragraph types
  • comes with image, audio and video support
  • supports complex layouts, as well
     

Some of its key features:
 

  • you're free to enable/disable the swipe functionality
  • it's responsive (scales along with its container)
  • some of its layouts are CSS-built
  • it's designed to work with Field collection, Media, Views, Image (and also to work perfectly fine with none of these modules)|
  • it allows you to configure your own “slide selecting” dots, the arrow keys and your slider's navigation, as well
  • it provides modular and extensible skins
  • you get to choose how you want your slideshow to be scrolled: swipe, desktop mouse dragging, auto scroll, mouse wheel scroll...
     

Another one of those Drupal 8 slideshow modules that gets the best reviews.

Here's why:
 

  • it leverages the Owl Carousel slider built by OwlFonk.   
  • it, too, empowers you to customize your image slideshow; in this respect, it ships with a myriad of customization settings
  • it's responsive
  • it capitalizes on a small ecosystem of submodules: Administration UI, Views Style, Field Formatter
     

Some of its key features:
 

  • from customizing your events to styling your controls, it allows you to tailor your image slider to suit all your needs
  • it supports multiple sliders
  • touch events
     

A simple module to consider each time you need to display a group of images in a compact way on your website. It even allows you to set the number of items to be included in your carousel...

Speaking of which, you should know that jCarousel, as its name says it, allows you to leverage the jCarousel jQuery plugin.

For this, it ships with a developer API for other modules to access. Furthermore, it integrates with Views, so you can easily turn any list of images (or other type of content) into a slideshow...

Some of its key features:
 

  • jCarousel field formater
  • out-of-the-box Views support
  • API for using jCarousel without Views
  • a collection of modern skins to choose from
  • Carousel pager that enable users to jump between multiple sliders
     

The END!

These are the first Drupal 8 slideshow modules to consider when looking for the best method for setting up your custom image/content slider.

Packed with tons of customization options, feature-rich and powerful, these 4 solutions for creating image carousels in Drupal 8 should be on your short list when you start looking beyond the out-of-the-box options for putting together a slider...

Apr 24 2019
Apr 24

Simple or custom-made? Is it a quick-to-assemble, rather “prototypical” form that you need for your website? Or a more complex, custom-made one? In a Drupal 8 Contact Forms vs Webform “debate”, which Drupal form builder best suits your data collection requirements?

On one hand, you have the convenience of creating your web forms in no time: simple, straightforward, “conventional” web forms. On the other hand, you get to scan through a never-ending list of advanced options and come up with a complex, fully custom-made web form.

That, of course, if you don't mind the time you need to invest in going through all those different form elements and available features and the risk of getting... overwhelmed by tons of field customization options.

Ease of use vs unlimited capabilities...

The convenience of getting your forms up and ready to collect user data in no time vs the chance to tailor some more advanced forms, ideally customized, carrying lots of different field values.

Decisions, decision...

Now, to help you decide here's a more detailed Drupal 8 Contact Forms vs Webform comparison. Weigh each one of the 2 form modules' benefits and drawbacks, set them against your own needs and... make the choice:


1. The Contact Forms Module 

Being part of Drupal core, there's no need to download and install the module.

Just go to Structure>Contact forms. Next, choose either to opt for the default form or to set up a new one: click the “Add contact form” button.

Drupal 8 Contact Forms vs Webform: Add Contact Form


Once in the form creation screen, enter your form's values in the predefined fields that you have there:
 

  • give the form a name in the “Label” field
  • enter the email address where all the form submission will be sent to (most probably your site admin address) in the “Recipients” field
  • enter your “Thank you” text in the “Message” field there; this will be the “thank you” text line your users will see once they hit the “submit/send” button 
  • in the “Redirect path”, enter the URL to the page that you want them to get forwarded to after they've submitted the forms (that if you don't want them to be redirected back to the homepage, by default)
  • click “Save” and there you have it: a simple form, with all the basic, must-have field values, built in no time
     

Of course, that doesn't mean that you can't further explore the given features and maybe add a few more fields and even styling options.

For instance, you could “Edit” your newly created form. Just select it in the “Contact Forms” screen and, scrolling down the options in the drop-down menu opening up, click the “Manage fields” option.

Click “Add field”, then “select a field type” – Text(plain), let's say – enter the “Label” and configure its settings.

Furthermore, if you want to style your form a bit, hit the “Manage form display” tab and... opt for a placeholder, for example. Next, explore the options available in the “Manage display” screen. For instance, you get to decide if you want your field label to be hidden, inline or visually hidden...

In short: in a Drupal 8 Contact Forms vs Webform comparison, the first form builder will always outshine the latter when it comes to ease of use.

It empowers you to set up a simple form quick and easy...
 

2. The Webform Module

Now, if Contact Forms is a rather minimalist form builder, the Webform module is a feature-rich, powerful one.

The customization features that it ships with go from email notifications to fine-grained access, from statistic collection of data to delivering results in a CSV format. From exporting data in various formats to... conditional sorting and filtering.

In other words, with Webform sky is the limit when it comes to the contact form that you can create.

It can go from a basic one to a highly complex, multi-page form. One made of lots of elements, advanced options for the user to select from, settings and features for you to leverage in the back-end...

But, let's keep in mind that it's contributed module so you'll first need to download it from Drupal.org.

Next, go to “Structure” and hit the “Webforms” tab. Then, click the “Add webform” button and, in the next screen popping up, give your new form a name (enter it in the “Title” field).

You'll be automatically forwarded to the “Build” tab, which is where all the “magic happens”. Once you click the “Add element” button, you'll get to “swim through” a sea of lots and lots... and lots of form elements (known as “fields” in Contact forms) to choose from. Ranging from basic to really advanced ones...

Webform: Select an Element Screen


Let's assume that you'll want to add a “Text field” element. Click the “Add Element” button corresponding it, then scan through all the new customization options listed up in the “Add Text field element” screen opening up next...

Feel free to add other elements to your webform: a “text area” maybe, an “email” element, as well... 

Note: do keep in mind that, once you've settled for the final fields/elements to be included in your web form, you can always change the order to get them displayed in. Just drag and drop them till they fit that predefined order in your mind...

Also, you can check/mark them as “Required” and turn them into “must fill in" fields, as opposed to optional form fields.

Note: feel free to edit that “Thank you” page that your webform will automatically forward users to. How? By clicking “Back to form”>"Settings”>"Confirmation” and selecting from the different options that you have there:
 

  • enter your own Confirmation title (e.g. “Thank you!”)
  • customize your Confirmation message
     

3. Drupal 8 Contact Forms vs Webform: Key Differences

Now that we've run our spotlight over each one of these 2 form building tools, let's make an inventory of the differences that we've identified:
 

  • first of all, it's obvious that the Webform module gives you more control over your web forms' design
     
  • also, unlike Contact Forms, it supports conditional emails; you get to send an email to a specific user in your list based on conditions associated with the value of certain elements in your form
     
  • Webform enables you to add basic logic to your web forms
     
  • … it comes packed with tons of advanced options, ranging from JS effects to conditional logic, to submission handling, etc.
     
  • Contact Forms, on the other hand, allows you to set up a simple contact form in the blink of an eye; you skip the tedious process of scanning through lots and lots of options, settings, and complex features
     
  • Webform allows you to create your forms either in a YAML file or in its the admin-friendly UI
     
  • also, Webform comes as a “cluster” of submodules – Webform REST, Honeypot, Webform Views, SMTP, Webform Encrypt, etc. – which are “responsible for” its multiple capabilities
     

4. In Conclusion...

The conclusion of this Drupal 8 Contact Forms vs Webform “debate” is quite simple: 

If you need a basic form on your website and you need it built fast, go with Contact Forms. Being included in Drupal 8 adds convenience...

But if you want to customize your form (and you have the time), to style it to your liking and “turbocharge” with advanced features and options, then go with Webform.
 

It's a much more powerful and feature-rich form builder, perfectly suited for your complex requirements...


Image by Tumisu from Pixabay

Apr 18 2019
Apr 18

In the Drupal community, the annual DrupalCon show is the biggest event of the year. Held in a different city each year, the event brings Drupal users together for a week of sessions and networking.

drupalcon accessibility lessons

With so many people and agencies committed to Drupal in attendance, DrupalCon is the perfect opportunity to provide training and guidance. This year’s show, DrupalCon Seattle, dedicated its first two days to community summits and full-day training sessions. One of these summits tackled one of the most prevalent issues of the year for Drupal: Accessibility. Through a combination of keynotes, panels and breakout sessions, the summit’s organizers gave attendees actionable insights and new perspectives on front-end accessibility.

The day kicked off with a keynote from OpenConcept’s Mike Gifford, who spoke about his agency’s work with the Canadian National Institute of the Blind (CNIB). For the organization’s 100-year anniversary, the CNIB sought a rebrand and redesign with an emphasis on making their site’s content more accessible. As OpenConcept learned, creating an accessible platform is easier said than done. To illustrate how difficult the process can be, Gifford wryly offered this Donald Rumsfeld quote:

There are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns — the ones we don't know we don't know.

In the context of web development, accessibility is often an “unknown unknown.” Without extensive testing, programmers won’t know that any given element won’t limit access for certain users. As such, one of the major lessons that Gifford shared was the importance of manual testing.

“Automated accessibility testing will only get you 25 percent of the way there,” Gifford said. “Manual testing is essential, and this mostly comes down to getting rid of your mouse and tabbing through a site."

Download Accessibility Checklist

As Gifford and speakers from subsequent panels noted, the best method for testing a site’s accessibility is to actually use it. While a lot of problems can be found by, as Gifford said, unplugging your mouse and using the “tab” key to navigate, this approach can still miss blind spots that able-bodied users wouldn’t consider. Alternatively, hiring disabled users to perform QA testing on a given site is often the best solution. 

This ethos is especially true when building mobile sites. Another keynote speaker, Gian Wild of AccessibilityOz, covered the mobile accessibility testing process in detail. Manual testing on real devices can root out common traps, like if a site’s buttons are too small to be navigated with a finger or if links aren’t underlined. For more common errors, Wild’s slide deck can be found here.

As important as manual testing is, though, automated accessibility tools are a vital element of the accessible design arsenal. Though pervasive and subtle errors still require hands-on QA testing, automated solutions will identify many more thousands of minor issues in a fraction of the time. As such, using these tools in coordination with manual testing will ensure that your site is as accessible as can be.

During the final breakout session of the summit, attendees shared which tools they think work best for rooting out accessibility issues, many of which conveniently come in the form of browser extensions. Some commonly mentioned tools included:

We’ve previously profiled several accessibility tools, and you see which one is best for you here.

As challenging as accessibility testing can be, the reward of expanding your audience is well worth it. Fortunately, the Drupal platform helps ensure out-of-the-box accessibility features. During his keynote, Gifford pointed out that Drupal design patterns have already been tested, known bugs are listed transparently, and the development community actually cares about the issue. In fact, OpenConcept’s work for CNIB produced several fixes and modules that can now be utilized by any Drupal user. These contributions and further info about the CNIB redesign can be found on Gifford’s slide deck here

With a senior-level team of designer and developers, Duo can apply these lessons to sites across industries. Our commitment to accessibility means that every site we build will be open to all users. To learn more about our process and values, reach out to our team today!

Explore Duo

Apr 17 2019
Apr 17

What makes Drupal a great choice from a UX standpoint? What features are responsible for the enhanced end-user experience in Drupal 8? Those features that enable you to easily create an intuitive and enjoyable visitor experience on your own Drupal-based website/application.

And to constantly improve it...

Is it all those performance enhancements that it ships with? Or maybe its “responsive out-of-the-box” nature? Or rather its multilingual capabilities?
 

1. But First: 7 Evergreen Ways to Improve Your Website's UX

It goes without saying that, in order to create an enjoyable, rich user experience on your Drupal 8 website, you'll need to:
 

  • put together a solid UX strategy
  • run extensive user research and map the user's journey
  • come up with an effective, well-planned UX design, paying attention to all the latest design trends (and now decoupled Drupal empowers you to tap into a whole range of new possibilities...)
     

And while carrying out all these phases of the UX design process, make sure to apply the following evergreen techniques for enhancing the visitor's experience:
 

1.1. Optimize the page loading time

For speed will always be the factor with the biggest influence on the user's experience on your Drupal site.

In this respect, there are tons of performance enhancements that you can implement, ranging from aggregating your JS and CSS files to properly configuring your cache to opting for a CDN, to...
 

2.2. Use bullets to structure your text

Bulleted lists are the “holy grail” of neatly structured, easy to read content.

For, in vain you invest time and effort in providing content that delivers real value to your website's visitors if you display it as an... “impenetrable” block of text.

In this respect, bullets help you break down the information. The result: users will see the key product or service benefits/will go through all of the presented features a lot quicker.
 

2.3. Use white space strategically

Speaking of easy to read content: there's no better way to enhance readability and to draw attention to specific elements on a page than... by using the white space itself.

It will automatically direct their attention to the text/image emphasized by all the white space surrounding it.
 

2.4. UX design is consistent Design

From color palette to button styles, from the size of the headings in your text to the chosen font, from the used photos to various design elements... keep consistency across all the pages on your Drupal website.

Otherwise, you risk to confuse and eventually... tire its visitors.
 

2.5. Go for visible, attractive CTAs

Always use action words for your calls to action and make sure they're easily recognizable. CTAs play a crucial role in setting up an intuitive, efficient navigation structure on your website...
 

2.6. Use images wisely

As images are always well-deserved “breaks” for the eye, especially when it's a long text that it's challenged to go through.

And yet, if you fail in using the relevant images, those that perfectly team up with your text... the user experience that you'll deliver will be anything but compelling...
 

2.7. Make your headings a high priority 

Remember to write your headings around some of the main keywords.

Also, strategically design them so that they're highly visible and help users to quickly scan through the content.
 

2. 4 Features Responsible for the Superior End-User Experience in Drupal 8

Gluing together all the design best practices that make a great user experience does call for a flexible and dynamic web platform.

Drupal 8 is that platform. It comes packed with some powerful features that make it easy for you to create the best visitor experience on your website.

Here are the ones with a huge influence on your website's UX:
 

2.1. Drupal 8 is responsive right out-of-the-box

And responsiveness, along with top page loading speed, still is one of those factors with a great influence on visitors' experience with your Drupal website.

With:
 

  • all the available base themes now being responsive
  • the convenience of adapting your images to various screen sizes right from their display properties
     

… creating a compelling end-user experience in Drupal 8 is dead-simple.


2.2. Enhanced performance

From a performance standpoint, Dries Buytaert's post on Drupal 8's performance optimizations is still one of the most relevant sources.

If Drupal was already built to “inject” enterprise-level performance into static pages, Drupal 8, with all its caching enhancements, is designed to speed up dynamic web pages, as well...


2.3. Multilingual capabilities

Remember the user experience's main facets, ranging from useful to findable, to valuable, to credible to... accessible?

Well, Drupal 8 provides you with multilingual capabilities right out of the box. You get to translate your website's UI, content, configuration, etc.

Meaning that, with this multilingual system at hand, you can easily create an accessible user experience on your website.


2.4. Content personalization (by segment, login time, device, language...)

In this respect, the Aqua Lift Connector module is your most reliable tool.

What it does is bring together customer data and content, so that you can deliver targeted content experiences across multiple channels and devices.
 

The END!

And these are those robust features that stand behind the superior end-user experience in Drupal 8. The very reasons why this platform, and particularly this version of Drupal, makes your best ally in creating the most compelling UX on your website.

Photo by Lucian Novosel on Unsplash

Apr 02 2019
Apr 02

For many businesses, eCommerce is an increasingly important trend. With the potential for frictionless and simple exchanges, doing business on the web has never been more appealing to customers. To make eCommerce work for your business, though, our site needs to be robust enough to handle every step of every transaction.


drupal decouples commerce

Photo by Igor Miske

With its open source community and robust core, the Drupal platform is a worthy solution for any and all eCommerce needs. While a site built on Drupal will have the enterprise capabilities needed to handle a wide array of business needs, one of the major selling points of the platform is its flexibility. Drupal has the ability to be decoupled, allowing you to use Drupal as your background CMS while utilizing a third-party solution for your front end. If your brand is tied to an existing look or design, a decoupled or “headless” solution will let you have your cake and eat it, too.

As you might imagine, headless solutions have major implications for the possibilities of eCommerce platforms. At this year’s MidCamp, an annual meetup of the Drupal community in the Chicago area, Commerce Guys Product Lead Matt Glaman took a look at the future of headless commerce solutions. What emerged from the session painted a picture of progress, as developers are continuing to create solutions in Drupal that will power a wide array of eCommerce solutions.

Decoupled Drupal Facts & Myths

Leading the path toward making headless commerce more feasible is Commerce Guys, a Drupal software firm that held a couple of events at MidCamp on the subject. Best known for creating the Drupal Commerce module and the shopping-cart software Ubercart before it, Commerce Guys brought years of experience in the eCommerce space to this year’s event.

Offering a look at the technical side of Drupal-based eCommerce, Glaman examined the various challenges and solutions surrounding headless commerce. As he explained, the heavily structured data model of eCommerce in general presents a challenge, as do the relationships between the various layers in a site, such as the data and presentation layers. Making sure that the connections between the Drupal-backend and the myriad of frontend possibilities are robust and stable is essential to making headless commerce solutions work for users.

To address these challenges, Glaman highlighted a variety of existing API solutions. To enable headless commerce, the available options include the GraphQL data query language, JSON-RPC, JSON API and the RESTful Web Services spec. Though the latter two have the convenience factor of being included in Drupal Core, all of these solutions have their strengths and weaknesses in the context of headless commerce.

The efficacy of each solution varies depending on which stage of the eCommerce process you look at. For catalogues and product display pages, using the JSON API offers strong query capabilities but doesn’t support mixed-bundle collections. A GraphQL solution, on the other hand, supports cross-bundling but queries can become very large. Most existing solutions also struggle with “add to cart forms,” as it can be challenging to create reusable solutions. Overcoming that hurdle requires using solutions in concert, such as a GatsbyJS:React and GraphQL build. Finally, for carts, the JSON API requires integration with a Cart API, while the aforementioned query issues with GraphQL require the use of GraphQLMutation plugins to solve. For a deeper look into the nuances of these existing headless commerce solutions, you can watch Glaman’s full presentation here:

[embedded content]

So, while headless commerce in Drupal is achievable, it takes some effort to get to a point where it can handle your business’ eCommerce needs. Luckily, the strength of Drupal’s open source community means that you don’t have to wait for the Commerce Guys to fix everything. A firm like Duo can help you fine-tune an eCommerce solution to fit your needs. Don’t just take our word for it; our previous work with the Chicago Botanic Garden demonstrates our prowess in designing unique and robust eCommerce platforms.

If you’re interested in exploring a headless commerce platform on Drupal or are just looking to make your online business run more smoothly, Duo is the right partner for you.

Explore Duo

Mar 15 2019
Mar 15

A lot of effort goes into engaging your visitors to ‘Sign-up’ or ‘Contact’ you. You send them a warm and fuzzy invitation to complete the form, tell them all the great reasons why they should complete the form… but who likes to complete a form?  Guarantee a smooth sign-up process and increase the completion rate of your webforms with these six tips. 

#1 Make it Flow

Before you begin designing that web form, it is always good to create a User Flowchart. Working to establish the form completion process from start to finish, a flowchart will help you: 

  • Determine what information is needed (and when)
  • Decide what actions and interactions are appropriate
  • Determine the order of actions
  • Make considerations for new patterns to aid the completion process

A User Flowchart can begin with a simple Flow Outline, which can then be placed in a flowchart diagram and later illustrated using low fidelity paper prototypes to find the most natural set of actions. When creating the outline consider the following:

The Business Objective

  • What is the main objective of the website for achieving successful completion of the form? (ie, we want to gather as many email addresses as possible.)
  • What is the required information needed from the person completing the form? (ie, we need their name and email, and since our site is only for adults we also need their birth date.)

The User Persona

  • Take advantage of the information gained from the User Personas to focus on the user’s various needs and considerations. What problem do they want to solve and how can this form help them?

  • What devices do they access most frequently to complete webforms? It’s good to know in advance if most of the users complete forms on their mobile phones and/or if they have inferior internet connectivity.

The Entry Point

When designing a User Flowchart, keep in mind the point of entry. Perhaps they arrive after clicking the Call to Action on the homepage. Often webforms are a part of an email or social media campaign, or the user arrives at the form after an organic search. The users should be treated differently based on where they come from, and may need extra context to reiterate the goal of the form to help them get orientated when they arrive. Consider all possibilities.

#2 Keep it Short and Sweet

Don’t ask for information that’s not needed. Your subscription or contact form — or any form that gathers basic information — should only ask for the bare necessities needed in order to accomplish that goal. People will usually stick around long enough to enter their name, email address and password. Anything more than that should be the absolute minimum amount of information needed, with further data obtained in follow-up communications or by implementing a multi-step form (see tip #3). No one enjoys completing a form, so keep it as simple as possible! Neil Patel found that three form fields was the optimal number.  Pegasystems, a Mediacurrent client, leveraged third-party integrations on their Drupal 8 site to pre-fill form fields with data and improved the user experience for returning visitors. 

Reducing the number of form fields can increase conversion rates by 26 percent. 

Email Address

  • Forward thinking email form fields provide suggestions for fixes when the email address has been entered incorrectly. … Did you mean @gmail.com?
  • If you include an auto fix for mistyped email addresses you won’t need to require the user to enter it twice. Otherwise, it’s is a good approach to provide the extra guarantee that they’ve got it right.
  • When the form is for creating an account or signing up for a newsletter, a current practice is to use the email address for the account instead of providing a separate username. This will cause less frustration with creating one that is not already in use, as well as remembering it every time they login.

Name

The person’s name is really only needed in instances where account personalization or custom communication is used. A frequent approach is to provide one field for their full name. This is a bonus since some users may have more than two words that make up their full name, and one field takes less time to complete (especially on mobile devices). Check first to see if the system requires the first name to be isolated for marketing purposes.

Password

  • Enough with the 'confirm password' already! They will lower your conversion rates. Give the user the option to actually SEE the password they’re entering with a ‘show password’ toggle, and they won’t have to enter it twice.
  • Include a Password Strength Indicator. You can get creative with messaging to encourage users to try harder when creating a more secure password like Geeklist does: “Crack Time: 5 minutes”
  • Depending on the level of site security, another time-saving feature is the ability to never have to enter their password again with the ‘Remember Me’ feature.

#3 Multi-step Forms

Single step forms are the most common type of form found on a website. Sometimes, however, using the minimum amount of fields will not accomplish the goal of capturing essential user data. Instead of simply adding more fields to your one-page form you should be aware of an important point: 

Multi-step forms have been found to increase conversions by as much as 300% (without increasing website traffic). 

Multi-step forms convert well for several reasons:

Simplicity

Through the use of progressive disclosure design techniques, we can improve usability when only the minimum data required for a task is presented to the user. Multi-step forms provide the ability to break up a longer form into manageable steps so the user is not visually overwhelmed with requirements at the beginning or during the process. By including only one or two questions per step with a manageable number of steps overall will improve the user experience and significantly increase the chance they will complete it. 

Reduced Psychological Friction

Multi-steps with a simplified interface allow opportunity to use low-friction language in order to reduce psychological friction. In order to encourage the user to become immersed with an energized focus on the activity, we must always seek to minimize disruptions and use language that puts them in a positive state of mind. 

Orientation

Progress bars encourage form completion. The most common use of visual progress trackers are when conducting an online purchase since those are often broken into a multiple step process. It answers the questions the user may have during completion:

  •  How long will the form take?
  • What comes next?
  • Is anything happening?

Displaying the steps required to complete the form along with where the user currently is at in the process will help manage their expectations and keep them oriented throughout.

Investment

By using the approach of requesting general information at the beginning of the form and moving towards more sensitive information requests towards the end of the form, the user feels more invested and is therefore more likely to complete.

Conditional Logic

Longer forms will sometimes benefit by using conditional logic in order to personalize the experience. The user is provided with specific questions based on certain responses therefore eliminating irrelevant information retrieval while simultaneously obtaining more targeted data. Save them valuable time and customize their experience, and they will likely reward you by clicking the submit button.

#4 Make it Easy to Read

Including the labels and inputs, consider the context being used for all text on the page and work to ensure your font sizes are large enough to be legible on all devices. The amount of content on the page should be considered while also using best practices for accessibility. 

  • Recent trends are a 14px font size at minimum.
  • When specifying a 16px font size for mobile devices, iOS will not zoom in when the user taps the field, because it’s not needed. This approach can be less distracting especially when there are multiple form fields on the page.
  • Consider the maximum amount of characters that will be needed in all cases to ensure enough room is provided to complete each field. For example, some zip codes in other countries use a varying number of digits.

#5 Inform Everything

Label All Things

The label of the form field you want the user to complete should ALWAYS remain visible. The labels can be placed outside of the field near the top, right, or left — or even better — use the Infield Top Aligned Label. This popular approach has been found to be the quickest to scan, has the best flow, and takes up less real estate. The labels are placed inside of the field, jumping to the top left corner as the user begins typing. Either way, at no point should the user lose sight of the information that’s needed inside of the field.

Inline Form Validation

  • Inform the user as they progress if anything has been entered incorrectly or if a field is missing information. Don’t make them click the ‘Submit’ button at the end of the form only to receive a bunch of red text telling them what they have to re-do.
  • Micro interactions such as a simple green check or a red ‘X’ along with a brief message as the user completes the form will improve the workflow.
  • Tell them if their CAPS LOCK IS ON.

Required or Optional?

Inform the user which fields are required and which are optional for the form to be accepted. An asterisk is often used to designate required information, but they are ignored by screen readers so make sure the required fields include the HTML5 ‘required’ attribute or the aria-required set to true.

Field Details

Explaining the information needed for each field is another great approach. If your Registration Sign-up Form will require a password with at least 6 unique characters with 2 of them numbers, tell them! Does the phone number field require a +, or a country code, or an area code? Tell them or show them.

Progress Bar

  • A form that’s broken into logical steps is easier to complete. If there are multiple steps that require multiple screens to complete, add a progress bar so the user knows where they are in the process.
  • If possible, add a link to the completed steps in the progress bar so the user can go back if needed.

Safety

  • Make your users feel safe during sign-up by informing them about your terms, policies, or rules.
  • Ensure them you will not share their information or spam their email.
  • Provide an easy way to cancel or opt out at any time, without much effort.

#6 Must be Mobile

While optimizing your site for mobile devices, any forms on your site should also be carefully considered. Not only are the screens smaller, but often the connections are slower, and entering text can be a bit tricky, so reducing the number of required fields is especially important. Luckily, recent innovation for mobile forms have provided modern solutions and compression techniques that could actually encourage sign-up on a mobile device:

Predefined DropDowns

  • Whenever possible, avoid open input fields and provide a dropdown list instead for easier completion.
  • Dropdown selections should be written as they would normally display (ie, Credit Card expiry date: 01/20).

Collapsible Menus

This really helps when multiple offerings are available with details for each.

Predictive Search Fields

As the user begins typing the keyword, a list of possible results is provided. 

Calendar Tools

Choose a calendar that is easy to use, with big targets that help to avoid user input errors

Combine Inputs When Possible

Providing only one field for a ‘Full Name’ instead of one for ‘First Name’ and one for ‘Last Name’ will speed up the form completion process and reduce user frustration. 

Automatic Advance

The system should recognize when a date or email has been entered and take the user to the next field automatically, whenever possible.

Buttons That Engage

  • The ‘submit’ button should use a strong command verb that provokes emotion or enthusiasm, such as ‘Sign-Up Now!’
  • Use bright, engaging (and accessible) color combinations. Color changes on tap add even more visual information about the progress.
  • Ensure the tap target is large enough for users with big fingers or who have difficulty being accurate. Apple's iPhone Human Interface Guidelines recommends a minimum target size of 44 pixels wide 44 pixels tall.

Final Word

Achieving a smart form design isn't always easy, but it's well worth the effort. 

What are some great examples of forms you've seen? 

Editor’s note: This post was originally published on November 14, 2016, and has been updated for accuracy and comprehensiveness.

Jan 16 2019
Jan 16

In a past life, I worked as an editor for a couple of B2B websites. The first one ran on Drupal 7, while the second, launched several years after the first, was built out on Drupal 8. When this D8 site was ready for action, I was eager to dive in and test out all of the bells and whistles.

drupal admin ui

While I appreciated much of the streamlining and improved functionalities between the two versions, I couldn’t help but notice that the user interface (UI) for Drupal 8 wasn’t much different from Drupal 7.

As it turns out, I wasn’t the only one who saw the resemblance.

In a recent blog post, Drupal founder Dries Buytaert addressed criticisms from the community regarding the Drupal admin UI. Acknowledging that the interface was dated, he wrote:

This critique is not wrong. Drupal's current administration UI was originally designed almost ten years ago when we were working on Drupal 7. In the last ten years, the world did not stand still; design trends changed, user interfaces became more dynamic and end-user expectations have changed with that.

To address this issue, Dries continued, the Drupal team is going to revamp the Drupal admin UI. From the inside and out, this new UI is going to become more in-line with a modern editing experience.

There have been attempts to fix or update the admin UI before, but this new effort is wider in scope. Contrasted with a component like the Material Admin theme, which is also meant to modernize the backend editing experience, Drupal’s plan for a new admin UI is part of a comprehensive modernization strategy. The Admin UI & JavaScript Modernization initiative seeks to update Drupal’s APIs and underlying JavaScript code. This multi-year initiative’s ultimate goal is to make Drupal both more compatible with decoupled applications and easier to navigate for end users.

While these UI advances sound tantalizing, they’re a bit far off, as this initiative will take several years to complete. As the first phase of this plan, however, the Drupal team has a solution they’re planning on releasing sooner. In this case, they’re taking a cue from the community and creating a new theme known as Claro.

With a beta anticipated to come out in Spring 2019, Claro represents an early version of the Admin UI & JavaScript Modernization Initiative’s goals. Claro will be built along the same design principles that guide the initiative despite being built from the D7 core theme. While this first step is limited to visual improvements, insights gained from its adoption will be used during the larger modernization initiative. By developing this temporary solution, Drupal is giving users a chance to experiment with a version of the new layout while still staying open to feedback.

These gradual technical changes are much anticipated, but the big takeaway is that this isn’t just a cosmetic upgrade. Many of the guiding principles behind the admin UI modernization initiative are rooted in accessibility, responsiveness and collaboration. Thanks to the updated JavaScript-based UI, the interface will be React-powered, making the experience more app-like (read: intuitive). Design elements like iconography and colors will be simplified for easier understanding. While an update of this magnitude could easily have eschewed these concerns and opted for a purely aesthetic redo, signs point to a revamped admin UI that will improve the editorial experience for everyone.

Based on these defined principles and the level of attention already dedicated to the project, the Drupal team’s commitment to improving its user experience in this case cannot be understated. When users identified an outdated admin UI as an issue, Drupal offered both a short-solution to address the problem while being open about plans and philosophies for long-term development. By the end of the process, the out-of-the-box Drupal admin UI will be able to compete with other content management systems in terms of usability and appearance.

At Duo, we're committed to making sure that editors can easily and effectively manage their content. If you have any questions about Drupal or any new features on the horizon, please feel free to reach out.

Let's Talk!

Jan 09 2019
Jan 09

There’s no getting around it: Website redesigns are expensive, arduous processes. From project management to quality testing, the challenges involved in undergoing such a design overhaul are legion. Given the costs involved and the extent of labor needed to update any given site, delaying or putting off a major design overhaul is an understandable stance from business owners.  

drupal 8 upgrade

Photo by rawpixel

Drupal sites are not exempt from this reality. For businesses running sites on earlier versions of Drupal, upgrading to Drupal 8 represents a daunting task. With reasoning varying from typical costs to unsupported functionalities, forgoing a Drupal 8 migration has long been the norm. Though Drupal 8 launched back in 2015, adoption has been slow. Globally, there are around 71,000 live sites using Drupal 8 compared to over 333,000 live sites using Drupal 7. 

It’s time for that to change. 

With a suite of new and updated features, Drupal 8 has never been more of an asset. We’ve covered some of the benefits of a D8 migration in the past, but the framework only grows more robust each day. The development community continues to break new ground on Drupal 8, making it a robust solution for all manner of business needs. 

Beyond Drupal 8’s virtues, another, more pressing, reason to upgrade is rearing its head: the end of a lifecycle. As laid out in a blog post, Drupal founder Dries Buytaert has revealed the timetable for the launch of Drupal 9. The new version is expected to launch on June 3, 2020, rather than an initially projected December release. 

Why the accelerated timeline? One of the major dependencies for current Drupal cores is the PHP framework Symfony. The end-of-life date for the latest version, Symfony 3, will be in November 2021. To maintain site security, Drupal 8’s end-of-life is also tied to this date. To reiterate, by November 2021, everyone should have upgraded to Drupal 9. For everyone running Drupal 7 sites, the same deadline applies. 

Luckily, there’s good news. Once your site is upgraded to Drupal 8, moving over to Drupal 9 will be a much easier transition. This is because Drupal 9 is being built on Drupal 8 rather than on an entirely new codebase; the main work that will need to be done mostly involves removing deprecated code and updating dependencies. From a site owner’s standpoint, this means that functionality from Drupal 8 sites will carry over to ones on Drupal 9. With this level of backward compatibility, meeting the deadline of November 2021 will likely be smoother than a full-on website redesign. 

Given the eventual sunsetting of Symfony 3, moving to Drupal 9 is inevitable. The choice to make now is whether to ride out Drupal 7 and then upgrade to 9 before November 2021 or to upgrade to Drupal 8 first. After taking into account the value of Drupal 8, though, it isn’t really much of a choice at all. Easier integrations, a more robust content authoring interface and, crucially, mobile responsiveness are all features that make Drupal 8 sites feel more modern to users and more accessible to owners. Setting all of these bells and whistles aside, a move to Drupal 8 early on will prepare businesses for the eventual, inevitable switch to Drupal 9. Staying ahead of the development curve while adding improved site functionality is a win-win proposition that can put any business ahead.  

In the coming months, we will be taking a deep dive into more of the reasons why upgrading to Drupal 8 is the right move. In the meantime, reach out to us if you have any questions about the process or the challenges involved.

Free D8 Upgrade Worksheet

Jan 03 2019
Jan 03

As we step into 2019, it’s a good time to stop and take a look at what’s been happening with the Drupal editing experience. 2018 seemed to be the “year of the editor” for not only Drupal, but the entire open source CMS world.

 

drupal-editing-trends-main

Photo by Crew on Unsplash

Editors need easy-to-use, highly flexible and accessible tools to create beautiful sites. With the rise of solutions based in react.js coming of age as well as more REST oriented architectures, we can certainly expect to see an explosion of the editing experience, especially in Drupal.

Merging Technology Between The Giants in CMS with Gutenberg Editor

The greatest thing about open source is that it’s open. One platform can adopt the features of another, and they often do when their aims are as close as those of Drupal and WordPress. Last year the Drupal community adopted a project called Gutenberg for a more pristine editing experience. The editor allows you to have a visual inline content creation experience with text, media and, of course, blocks. Gutenberg was created in coordination with a major WordPress effort to introduce the concept of blocks to their CMS. Since Drupal was born in this concept, Gutenberg was an easy adoption into our community.

drupal-editing-trends-gutenberg

This editor of course enhances the experience on both systems. However, I believe Drupal stands to gain the most from this project as the CMS has a long established history of blocks as a delivery system, though the editing experience has needed help. When you add in all the other complexities Drupal offers, such as Paragraphs, Context and Views, the possibilities are endless.

Drupal and WordPress have always been locked in a great debate as to which to use, when, what’s better than what. In this case, it’s great to see how different open source communities can enhance each other. Drupal’s concept of blocks is hands-down proven and, conversely, WordPress has been a favorite for editing content. Even Matt Mullenweg, the founder of WordPress, was heard saying “Drupal is my other favorite open source project” at the 2018 WCUS conference. It’ll be exciting to see what comes of this in 2019 as we progress in Drupal.

Try a Demo of Gutenberg

Layout Builder

Layout Builder is an experimental module still in progress from the Drupal community. It’s a drag-and-drop style editing experience that is geared towards allowing editors the opportunity to create structured content with ease. If you’re familiar with Drupal Panels or Panelizer, you can think of this as a next step from there and in a similar direction as Gutenberg.

According to a Dries Buytaert post, we should see Layout Builder become stable and ready to use by May of 2019. Many of the remaining issues are related to maintaining Drupal’s commitment to accessibility standards. Layout Builder is aiming to keep up with Level AA compliance with WCAG and ATAG.  

Check out his live demo here.

layout builder drupal

Emerging 3rd Party Page Builders like Glazed

For those who desire more free and wild control, we’re seeing solutions like Glazed surface from 3rd party companies like Sooperthemes. Glazed is a Drupal module that allows you to have granular control over padding, margins, custom animations and so on with a rich feature list.

sooperthemes drupal

While the Sooperthemes strongly promotes their pre-built themes, the Glazed module is able to be installed independently into any theme. Paid modules with this kind of functionality are a bit against the grain in the Drupal community, however it’s gained a note of praise from Dries even. I recommend testing it out and seeing if it fits into your organization's needs.

Try a demo of Glazed

Making Trends Work for You

It’s really awesome to see how far we’ve come, but how you make a decision on which direction to go is always the question. There’s a few questions you can ask to help determine what’s best for your company.

  • Do you have the need for consistent and structured content?

  • Does your company have an established brand style guide?

  • How trained are your editors for design and technical editing?

Solutions like Glazed, for example, are very loose and free in what you can do. If you have multiple editors in your company on different teams, tools like this could distract from your brand’s consistency. In the case of needing structured content with some flexibility, I’d keep my eye on what’s to come with Layout Builder. And of course, if you have editors that come from the WordPress side of things, Gutenberg maybe a strong choice to minimize on new training while still benefiting from Drupal’s core features.

As a front end Drupal developer I favor structured, component driven theming patterns. One of the greatest challenges in delivering a custom Drupal theme is meeting the immediate need for an editor to understand how to utilize the tools I’ve made.

I’m a huge fan of Paragraphs, as it offers tons of flexibility for creating reusable components. However, those features and options can get buried in technical feeling UI. It’s exciting to have tools like these to tighten the gap between the features we make and the experience our clients have editing in Drupal.

Let's Talk!
Nov 08 2018
Nov 08

Now that the excitement of BADCamp has worn off, I have a moment to reflect on my experience as a first-time attendee of this amazing, free event. Knowing full well how deeply involved Kanopi Studios is in both the organization and thought leadership at BADCamp, I crafted my schedule for an opportunity to hear my colleagues while also attending as many sessions on Accessibility and User Experience (UX) as possible.

Kanopi’s sessions included the following:

The rest of my schedule revolved around a series of sessions and trainings tailored toward contributing to the Drupal community, Accessibility and User Experience.

For the sake of this post, I want to cover a topic that everyone who builds websites can learn from. Without further ado, let’s dive a bit deeper into the accessibility portion of the camp.  

Who is affected by web accessibility?

According to the CDC, 53 million adults in the US live with some kind of disability; which adds up to 26% of adults in the US. Issues range from temporary difficulties (like a broken wrist) to permanent aspects of daily life that affect our vision, hearing, mental processing and mobility. Creating an accessible website allows you to communicate with 1 in 4 adults you might otherwise have excluded.

What is web accessibility?

Accessibility is a detailed set of requirements for content writers, web designers and web developers. By ensuring that a website is accessible, we are taking an inclusive attitude towards our products and businesses. The Web Content Accessibility Guidelines (WCAG) are a globally acknowledged set of standards that help us publish content that fits within the established success criteria. These guidelines are organized into the following four categories.

WCAG Categories:

  • Is your website perceivable? This applies to non-text content, time-based media (audio and video), color contrast, text size, etc.
  • Is your website operable? This ensures that content is easy to navigate using a keyboard, that animations and interactions meet real-user requirements, buttons are large enough to click, etc.
  • Is your website understandable? This means that text content is easy to read for someone at a ninth grade reading level, that interactions follow design patterns in a predictable manner, that form errors are easy to recover from, etc.
  • Is your website robust? This means that content should be easy to interpret for assistive technologies, such as screen readers.

The World Wide Web Consortium (W3C) is an international community whose mission is to lead the Web to its full potential. They have also published a checklist to aid our efforts in meeting WCAG success criteria.

Need help with making your site accessible? Contact us.

How can we be successful in making the web accessible?

Industries have varied requirements when it comes to web accessibility. WCAG has three levels of compliance, ranging from A to AA to AAA. A conformity has the lowest set of requirements and AAA has the strictest set of requirements; so strict, in fact, it may be impossible to achieve across an entire site.

Efforts to meet these standards fall on every individual involved in the process of creating a website. Although there are many tools that aid in our journey, we reach accessibility through a combination of programmatic and manual means.

The most important thing to keep in mind is the fact that achieving success in the world of accessibility is a journey. Any efforts along the way will get you one step closer towards a more inclusive website and a broader audience base.

Please Remember: Once Kanopi helps you launch an accessible site, it’s your job to maintain it. Any content you add moving forward must be properly tagged; images should have proper alt text and videos should have captions. Users come to your site because they love your content, after all! The more you can make your content accessible, the more you will delight your users.

Interested in making your site more accessible? Check out some of the resources I linked to above to join in learning from my peers at BADCamp. If you need more help getting there, let’s chat!

Nov 02 2018
Nov 02

What's your favorite tool for creating content layouts in Drupal? Paragraphs, Display Suite, Panelizer or maybe Panels? Or CKEditor styles & templates? How about the much talked about and yet still experimental Drupal 8 Layout Builder module?

Have you "played” with it yet?

As Drupal site builders, we all agree that a good page layout builder should be:
 

  1. flexible; it should empower you to easily and fully customize every single node/content item on your website (not just blocks)
  2. intuitive, super easy to use (unlike "Paragraphs", for instance, where building a complex "layout", then attempting to move something within it, turns into a major challenge)
     

And it's precisely these 2 features that stand for the key goals of the Layout Initiative for Drupal

To turn the resulting module into that user-friendly, powerful and empowering page builder that all Drupal site builders had been expecting.

Now, let's see how the module manages to “check” these must-have strengths off the list. And why it revolutionizes the way we put together pages, how we create, customize and further edit layouts.

How we build websites in Drupal...
 

1. The Context: A Good Page Builder Was (Desperately) Needed in Drupal

It had been a shared opinion in the open source community:

A good page builder was needed in Drupal.

For, even if we had a toolbox full of content layout creation tools, none of them was “the One”. That flexible, easy to use, “all-features-in-one” website builder that would enable us to:
 

  • build complex pages, carrying a lot of mixed content, quick and easy (with no coding expertise)
  • fully customize every little content item on our websites and not just entire blocks of content site-wide
  • easily edit each content layout by dragging and dropping images, video content, multiple columns of text and so on, the way we want to
     

Therefore, the Drupal 8 Layout Builder module was launched! And it's been moved to core upon the release of Drupal 8.6.

Although it still wears its “experimental, do no use on production sites!” type of “warning tag”, the module has already leveled up from an “alpha” to a more “beta” phase.

With a more stable architecture now, in Drupal 8.6, significant improvements and a highly intuitive UI (combined with Drupal's well-known content management features) it stands all the chances to turn into a powerful website builder.

That great page builder that the whole Drupal community had been “craving” for.
 

2. The Drupal 8 Layout Builder Module: Quick Overview

First of all, we should get one thing straight:

The Drupal 8.6. Layout Builder module is Panelizer in core!

What does it do?

It enables you, the Drupal site builder, to configure layouts on different sections on your website.

From selecting a predefined layout to adding new blocks, managing the display, swapping the content elements and so on, creating content layouts in Drupal is as (fun and) intuitive as putting Lego pieces together.

Also, the “content hierarchy” is more than logical:
 

  • you have multiple content sections
  • you get to choose a predefined layout or a custom-design one for each section
  • you can place your blocks of choice (field blocks, custom blocks) within that selected layout
     

Note: moving blocks from one section to another is unexpectedly easy when using Layout Builder!
 

3. Configuring the Layout of a Content Type on Your Website

Now, let's imagine the Drupal 8 Layout Module “in action”.

But first, I should point out that there are 2 ways that you could use it:
 

  1. to create and edit a layout for every content type on your Drupal website
  2. to create and edit a layout for specific, individual nodes/ pieces of content
     

It's the first use case of the module that we'll focus on for the moment.

So, first things first: in order to use it, there are some modules that you should enable — Layout Builder and Layout Discovery. Also, remember to install the Layout Library, as well!

Next, let's delve into the steps required for configuring your content type's (“Article”, let's say) display:
 

  • go to Admin > Structure > Content types > Article > Manage Display
  • hit the “Manage layout” button
     

… and you'll instantly access the layout page for the content type in question (in our case, “Article”).

It's there that you can configure your content type's layout, which is made of:
 

  • sections of content (display in 1,2, 3... columns and other content elements)
  • display blocks: tabs, page title...
  • fields: tags, body, title
     

While you're on that screen... get as creative as you want:
 

  • choose a predefined layout for your section —  “Add section” —  from the Settings tab opening up on the right side of the screen
  • add some blocks —  “Add block”; you'll then notice the “Configure” and “Remove” options “neighboring” each block
  • drag and drop the layout elements, arranging them to your liking; then you can click on either “Save Layout” or “Cancel Layout” to save or cancel your layout configuration
     

And since we're highly visual creatures, here, you may want to have a look at this Drupal 8 Layout Builder tutorial made by Lee Rowlands, one of the core contributors.

In short: this page builder tool enables you to customize the layout of your content to your liking. Put together multiple sections — each one with its own different layout —  and build website pages, carrying mixed content and multiple layouts, that fit your design requirements exactly.
 

4. Configuring and Fully Customizing the Layout of a Specific Node...

This second use case of the Drupal 8 Layout Builder module makes it perfect for building landing pages.

Now, here's how you use it for customizing a single content type:
 

  • go to Structure>Content types (choose a specific content type)
  • click “Manage display” on the drop-down menu 
  • then click the “Allow each content item to have its layout customized” checkbox
  • and hit “Save”
     

Next, just:
 

  • click the “Content” tab in your admin panel
  • choose that particular article that you'd like to customize
  • click the “Layout” tab
     

… and you'll then access the very same layout builder UI.

The only difference is that now you're about to customize the display of one particular article only.

Note: basically, each piece of content has its own “Layout” tab that allows you to add sections, to choose layouts. 

Each content item becomes fully customizable when using Drupal 8 Layout Builder.
 

5. The Drupal 8.6. Layout Builder vs Paragraphs

“Why not do everything in Paragraphs?" has been the shared opinion in the Drupal community for a long time.

And yet, since the Layout Builder tool was launched, the Paragraphs “supremacy” has started to lose ground. Here's why:
 

  • the Layout builder enables you to customize every fieldable entity's layout
  • it makes combining multiple sections of content on a page and moving blocks around as easy as... moving around Lego pieces 
     

By comparison, just try to move... anything within a complex layout using Paragraphs:
 

  • you'll either need to keep your fingers crossed so that everything lands in the right place once you've dragged and dropped your blocks
  • or... rebuild the whole page layout from scratch
     

The END!

What do you think:
 

Does Drupal 8 Layout Builder stand the chance to compete with WordPress' popular page builders?


To “dethrone” Paragraphs and become THAT page layout builder that we've all been expected for? Or do you think there's still plenty of work ahead to turn it into that content layout builder we've all been looking forward to?

Oct 03 2018
Oct 03

Recently, The Guardian Insurance Company made the strategic business decision to start marketing and selling their products directly to consumers. While Guardian has been around for nearly 160 years (WOW!) most consumer experiences with their products stem from employer insurance coverage offerings. As the industry landscape evolves and the US workforce moves slowly towards distributed and independent employment Guardian endeavored to differentiate their offerings not only from industry stalwarts but also from up-and-coming, startup-like products catering to the same demographics. Mediacurrent was proud to be chosen by Guardian Insurance Company as their Design and Strategy partner during product development of their new direct-to-consumer website.

Now that the site has launched, we’re happy to share some behind-the-scenes details of how this fresh, new experience came together. While our Case Study gives a broader overview of the project, this blog post will provide additional insight into our data driven design process.

Part 1 of this 2-part series covers the early planning parts of our process including Strategic Design Discovery, Style Tiles, and Wireframing. Part 2 will cover Mockups & Visual Design, Custom Illustration, and Custom Iconography. Let’s dive in!

Strategic Design Discovery

A Discovery phase begins many of our projects at Mediacurrent. This phase is led by a cross-functional group of our world-class team to help frame the challenges ahead. Throughout this phase, comprehensive knowledge of the Guardian brand, its customers, its competitors, and its business were gathered. These strategic design discovery insights allowed us to understand the types of consumers the new product is being geared towards (user personas), how success is being measured (Key Performance Indicators or KPIs), the ways in which a person becomes a customer (conversion paths) and a boatload of other data that served as our “guiding light” throughout the process.

Wireframes

Next, we moved on to really digging into the user personas and conversion paths generated in the Discovery phase by creating wireframes for the different sections of the site. One of the most exciting parts about this project was that we were not only designing the marketing section of the site but also the entire customer experience from the point where the visitor is attracted, becomes a lead, and eventually converts to a customer. This means that in addition to top-level marketing pages – like the home, about, and product pages – user journey designs were also needed for getting a quote and enrolling in one or multiple products.

Throughout the wireframing process, we broke down the different types of pages and sections of the site that users will encounter when visiting and organized the placement of content and calls-to-action (CTAs) by mapping the layout structure to the user journeys and KPIs identified in Discovery. Working from the Mobile First perspective, we made sure to consider this hierarchy not only on desktop machines but also tablets and mobile phones. In this case, we decided to take a medium fidelity approach – meaning that we avoided color or imagery in order to maintain focus on content organization and the user journey. We did include the typographic and iconography styles defined in our approved Style Tile, and we simulated actual copy since the process included quoting and checkout workflows which would not have made sense with greek copy.

In the end, these blueprints ensured that the user experience was providing the clearest path for a visitor to learn about the products, understand the cost and coverage offered, then ultimately enroll in a Guardian Insurance plan.

The goals mapped through the top-level marketing page wireframes were not only to educate the consumer about the company and the products offered but, more importantly, to serve as a hassle-free gateway to the actions the business measures – namely generating a quote and enrolling. On the homepage, Guardian wanted to make sure a newly developed brand message – Life is full of surprises. The cost of paying for them shouldn’t be. – was clearly communicated so we even started to play with some interaction suggestions. 

medium fidelity wireframe focuses on content organization and the user journeyDesktop, tablet, and mobile homepage wireframes.

The goals mapped through the quoting experience provided a simple way to understand the cost and coverage offered for a variety of different types of consumers – single person, couple, children, adult dependents, etc.

wireframe shows progression toward getting a quote

Tablet-width wireframes of the Find a Dental Plan (or quoting) process.

The goals mapped through the enrollment/checkout process were to 

a) keep the experience as simple and logical as possible for all types of visitors; 
b) allow them to enroll in one or multiple products at the same time;
c) gather all legally required information and consent – which varies between products.

wireframes show user journey to find a price quote

Desktop-width wireframes of the Enrollment (or checkout) process.

Along with these broader page-level experiences, microinteractions – such as saving and retrieving quotes – were considered and wireframed to ensure that the experience was cohesive.

Style Tiles 

With these insights in hand, we began creating Style Tiles that took the brand’s visual guidelines, placed them in an interactive digital context, and expanded on them where we saw the need and/or opportunity. This process created a high level view of the visual tone of the new website. Adding a bit of complexity, Guardian was deep in the midst of a larger corporate rebrand when our project began. In this case, we had to consider the existing brand guidelines, be flexible enough to incorporate new brand elements as they were provided, and ensure that the digital experience was coherent, unique, and accessible to all users – a critical concern identified during Discovery. 

Three concepts were presented initially:

1. New Blue Suit

– This concept expresses subtle sophistication through the use of color, typography, and whitespace. It relies heavily on the brand’s primary blue hue as a color that reinforces trust, loyalty, and integrity. An overall contemporary, minimalist approach is suggested as a means of reducing cognitive load. The icon style followed these principles as well by choosing an outline style with subtle monotone accents. Typographically, we included the fonts defined in their brand guidelines in order to maintain consistency with existing materials.

style tile includes blue and gray color palette and brandon grotesque typography

2. Happy Place

This concept is lively and pleasant using bright colors to create a friendly experience. We expanded the brand color palette to add cheerful, accessible hues able to be used in a variety of UI elements. Typographically we pushed the existing brand guidelines by incorporating a new font – Open Sans – as its wider variety of weights allows it to be used more expressively than the currently defined Arial family. Our type treatments utilized a lighter weight body font to balance the heavy use of color and maintain valuable whitespace. The icon style suggested takes a more fully-realized illustrative approach making use of the expanded color palette and adding dimension through highlights and shadows.

style tile with primary color palette

3. Gilded Skies

This concept reduces the color palette and adds trendy accents. Broader than New Blue Suit, but more restrained than Happy Place, this example’s color palette features a rich gray, trusted blue, and adds shades of gold to suggest value, elegance, and quality. Here we’ve suggested a hand-drawn icon style that personalizes the experience with a more genuine feel. We also included photography style suggestions that feature color and light effects to extend the color palette and maintain a clean and crisp look.

style tile features photography examples and a gray, blue, and gold palette

Through this exercise, we were able to understand just how far Guardian was willing to push their existing brand and create a final document that was approved by all stakeholders as the visual voice we wanted to achieve with the final product. In the end, and with a few iterations in between, we landed on what was essentially a blend New Blue Suit and Gilded Skies as the path forward. This final Style Tile was chosen in order to maintain consistency with Guardian’s larger, existing brand guidelines while introducing elements that would help create a more casual tone appropriate for the demographic of their direct-to-consumer offerings. 

final style tile includes blue, grey, gold and red tones, typography, buttons, and icons

Stay Tuned!

Our process does not end here but part 1 of this post does, unfortunately. :( Keep an eye out for part 2 where we’ll dig into the visual design details of the site! We’ll look at different visual concepts that were created, how the design was finalized with custom illustrations and iconography, and the component-driven approach we follow. For now, just direct your feet to the sunny side of the street!

Aug 30 2018
Aug 30


Full name


Email


Phone number


Company


Location


Website


Project type


Estimated budget


Tell us about your project or idea

SUBMIT

Aug 22 2018
Aug 22

At Mediacurrent, we hear a lot of questions — from the open source community and from our customers — about website accessibility. What are the must-have tools, resources, and modules? How often should I test? To address those and other top FAQs, we hosted a webinar with front end developers Ben Robertson and Tobias Williams, back end developer Mark Casias, and UX designer Becky Cierpich.

The question that drives all others is this: Why should one care about web accessibility? To kick-off the webinar, Ben gave a compelling answer. He covered many of the topics you’ve read about on the Mediacurrent blog: introducing WCAG Web Content Accessibility Guidelines, some the benefits of website accessibility (including improved usability and SEO) and the threats of non-compliance.

[embedded content]

Adam Kirby: Hi everybody, this is Adam Kirby. I'm the Director of Marketing here at Mediacurrent. Thanks everyone for joining us. Today we're going to go over website accessibility frequently asked questions. 

Our first question is: 

Are there automated tools I can use to ensure my site is accessible and what are the best free tools? 

Becky Cierpich: Yes! Automated tools that I like to use —and these are actually all free tools— are WEBAIM’s WAVE tool, you can use that as a browser extension. There's also Chrome Accessibility Developer Tools and Khan Academy has a Chrome Plugin called Tota11y. So with these things, you can get a report of all the errors and warnings on a page. Automated testing catches about 30 percent of errors, but it takes a human to sort through and intellectually interpret the results and then determine the most inclusive user experience. 

What's the difference between human and automated testing? 

Becky Cierpich: Well, as I said, the automated tools can catch 30 percent of errors and we need a human on the back end of that to interpret. And then we use the manual tools, things like Chrome Vox or VoiceOver for Mac, those are some things you can turn on if you want to simulate a user experience from the auditory side, you can do keyboard only navigation to simulate that experience. Those things will really help you to kind of drive behind the wheel of what another user's experiencing and catch any errors in the flow that may have come from, you know, the code not being up to up to spec. 

Then we also have color contrast checkers. WEBAIM has a good one for that and all these are free tools and they can allow you to test one color against another. You can verify areas that have too little contrast and test adjustments that'll fix the contrast. 

What do the terms WCAG, W3C, WAI, Section 508, and ADA Title III mean? 

Mark Casias: I'll take that one - everybody loves a good acronym. WCAG, these are Web Content Accessibility Guidelines. This is the actual document that gives you the ideas of what you need to change or what you want to a base your site on. W3C stands for World Wide Web Consortium - these are the people who control the web standardization. WAI is the Web Accessibility Initiative and refers to the section of the W3C that focuses on accessibility. 

Finally, Section 508 is part of the Rehabilitation Act of 1973, well it was added to that act in 1998, to require Federal agencies to make their electronic and IT  accessible to people with disabilities. ADA Title III is part of the Americans with Disabilities Act which focuses on private businesses, it mandates that they need to be fully accessible to individuals with disabilities. 

 What are the different levels of compliance? 

Tobias Williams: Briefly, the WCAG Web Content Accessibility Guidelines tell us that there are three levels - A, AA, and AAA, with AAA being the highest level of compliance. These are internationally agreed to, voluntary standards. Level A has the minimum requirements for the page to be accessible. Level AA builds on the accessibility of level A, examples include consideration of navigation placement and contrast of colors. Level AAA again builds on the previous level - certain videos have sign language translation and improved color contrast. 

To meet the standard of each level there are 5 requirements that are detailed on the WCAG site. Every every actionable part of the site has to be 100% compliant. WCAG doesn't require that a claim to a standard be made, and these grades are not specified by the ADA but are often referenced when assessing how accessible the site is.

Should we always aim for AAA standards?

Ben Robertson: How we approach it is we think you should aim for AA compliance. That's going to make sure that you're covering all the bases. You have to do an internal audit of who are your users and what are your priorities and who you're trying to reach. And then see out of those, where do the AAA guidelines come in and where can you get the biggest bang for your buck? I think that the smart way to do it is to prioritize. Because when you get to the AAA level, it can be a very intense process, like captioning every single video on your site. So you have to prioritize. 

What Drupal modules can help with accessibility?

Mark Casias: Drupal.org has a great page that lists a good portion of these modules for accessibility.  One that they don't have on there is the AddtoAny module that allows you to share your content. We investigated this for our work on the Grey Muzzle site and found this was the most accessible option. Here are some other modules you can try:

  • Automatic Alternative Text -The module uses the Microsoft Azure Cognitive Services API to generate an Alternative Text for images when no Alternative Text has been provided by user.
  • Block ARIA Landmark Roles -Inspired by Block Class, this module adds additional elements to the block configuration forms that allow users to assign a ARIA landmark role to a block.
  • CKEditor Abbreviation - Adds a button to CKEditor for inserting and editing abbreviations. If an existing abbr tag is selected, the context menu also contains a link to edit the abbreviation.
  • CKEditor Accessibility Checker - The CKEditor Accessibility Checker module enables the Accessibility Checker plugin from CKEditor.com in your WYSIWYG.
  • High contrast - Provides a quick solution to allow the user to switch between the active theme and a high contrast version of it. (Still in beta)
  • htmLawed  - The htmLawed module uses the htmLawed PHP library to restrict and purify HTML for compliance with site administrator policy and standards and for security. Use of the htmLawed library allows for highly customizable control of HTML markup.
  • Siteimprove - The Siteimprove plugin bridges the gap between Drupal and the Siteimprove Intelligence Platform.
  • Style Switcher - The module takes the fuss out of creating themes or building sites with alternate stylesheets.
  • Text Resize - The Text Resize module provides your end-users with a block that can be used to quickly change the font size of text on your Drupal site.

At what point in a project or website development should I think about accessibility? 

Becky Cierpich: I got this one! Well, the short answer is always and forever. Always think about accessibility. I work a lot at the front end of a project doing strategy and design. So what we try to do is bake it in from the very beginning. We'll take analytics data and then wecan get to know the audience that way. That's how you can kind of plan and prioritize your features. If you want to do AAA features, you can figure out who your users are before you go ahead and plan that out. Another thing we do is look at personas. You can create personas that have limitations and that way when you go in and design. You can be sure to capture those people who might be challenged by even things like a temporary disability, slow Internet connection or colorblind - things that people don't necessarily even think of this as a disability.

I would also say don't worry if you already have a site and you know, it's definitely not compliant or you're not sure because Mediacurrent can come in and audit, using the testing tools to interpret and prioritize and slowly you can get up speed over time. It's not something that you have to necessarily do overnight. 

How often should I check for accessibility compliance? 

Tobias Williams: I’ll take this one - I also work on the front end, implementing Becky’s designs. When you're building anything new for a site, you should be accessibility testing. test work, During cross-browser testing, we should also be checking that our code meets the accessibility standards we are maintaining.

Now that's easy to do on a new cycle because you're in the process of building a product that currently exists. I would say anytime you make any kind of change or you're focused on any kind of barrier of the fight, I would run a quick accessibility check. And then even if you don't address the changes straight away or at least you're aware of that, you can document them and work on them later. As far as an in-production site where you have a lot of content creators, or where independent groups work on features it is also a good idea to run quarterly spot checks. 

I've seen these on a few sites, but what is an accessibility statement and do I need one?

Becky Cierpich: An accessibility statement is similar to something like a privacy agreement. It's a legal document and there are templates to do it. It basically states clearly what level of accessibility the website is targeting. If you have any areas that still need improvement, you can acknowledge those and outline your plan to achieve those goals and when you're targeting to have that done. It can add a measure of legal protection while you're implementing any fixes. And if your site is up to code, it's a powerful statement to the public that your organization is recognizing the importance of an inclusive approach to your web presence. 

What are the legal ramifications of not having an accessible website? 

Ben Robertson: I'll jump in here, but I just want to make a disclaimer that I'm not a lawyer. Take what I say with several grains of salt! This whole space is pretty new in terms of legal requirements. The landmark case was  Winn-Dixie, the grocery store chain — it was filed under title III of ADA Act and they lost. It was brought up by a blind customer who could not use their website. The court order is available online and it's an interesting read but basically, there were no damages sought in the case. The court ordered that

they had to have an accessibility statement that said that they would follow WCAG 2.0. That's a great refresh for site editors to make sure that they're following best practices. They also mandated quarterly automated accessibility testing. 

I really think if you have these things in place already, you're really gonna mitigate pretty much all your risk. You can get out in front of it if you have a plan. 

If I have an SEO expert, do I need an accessibility expert as well? 

Tobias Williams: I'll explain what we do at Mediacurrent. We don't have one person who is an expert. We have a group of people. We have several developers, designers and other people on the team who are just interested in the subject and we meet once a week, we have a Slack channel where you just talk about accessibility. There are people who are most familiar with different aspects of it and that allows us to be better rounded as a group. 

I can see somebody being hired to be an accessibility expert but I think that the dialogue within a company about this issue is most important. The more people who are aware of it, the better. You can prevent problems before they occur. So, if I'm aware of the accessibility requirements of an item building, I'm going to build it the right way as opposed to having to be reviewed by the expert and then making changes. The more people who are talking about it and were involved in it and I'm the general level of knowledge, it goes a long way. We don't need to have experts as much as we need to have interested people. 

As a content editor, what's my role in website accessibility?

Mark Casias: Your role is very important in website accessibility. All the planning and site building that I do [as a developer] won't mean a thing if you don't attach an image alt tag to your images or you use a bunch of H1 title tags because you want the font size to be bigger and things like that. Content editors need to be aware of what they're doing and its impact on accessibility. They need to know the requirements and they need to make sure that their information is. keeping the website rolling in the right direction. Check out Mediacurrent’s Go-To-Guide for Website Accessibility for more on how to do this. 

Some of the technical requirements for accessibility seem costly and complex. What are the options for an organization?

Ben Robertson: Yeah, I totally agree. Sometimes you will get an accessibility audit back and you just see a long list of things that are red and wrong. It can seem overwhelming. I think there's really a couple of things to keep in mind here is that one, you don't have to do everything all at once. You can create an accessibility statement and you can create a plan and start working through that plan. Two, it really helps to have someone with experience or an experienced team to help you go through this process. There can be things that are a very high priority that are very easy to fix and there can be things that may be a low priority.

You can also think about it this way: if you got a report from a contractor that something you're building was not up to code, you would want to fix that. And so this is kind of a similar thing. People aren't going to be injured from using your website if it's inaccessible but it's the right thing to do. It's how websites are supposed to be built if you're following the guidelines, and it's really good to help your business overall. 

How much does it cost to have and maintain an accessible site? Should I set aside budget just for this? 

Adam Kirby: You will want to set aside a budget to create an accessible site. It is an expense. You're going to have to do a little bit more for your website in order to make sure it's successful. You're going to have to make changes. How much does it cost? That will vary and depend on where you are with your site build; if it’s an existing site, if you're launching a new site, the amount of content on your site and the variability of content types. So, unfortunately, the answer is it just depends. 

If you need help with an accessibility audit, resolving some known issues on your site, or convincing your leadership to take action on website accessibility, we’re here for you.  

Webinar Slides and Additional Resources 

Jun 18 2018
Jun 18
June 18th, 2018

Last month, Ithaca College introduced the first version of what will represent the biggest change to the college’s website technology, design, content, and structure in more than a decade—a redesigned and rebuilt site that’s more visually appealing and easier to use.

Over the past year, the college and its partners Four Kitchens and design firm Beyond have been hard at work within a Team Augmentation capacity to support the front-to-back overhaul of Ithaca.edu to better serve the educational and community goals of Ithaca’s students, faculty, and staff. The results of the team’s efforts can be viewed at https://www.ithaca.edu.  

Founded in 1892, Ithaca College is a residential college dedicated to building knowledge and confidence through a continuous cycle of theory, practice, and performance. Home to some 6,500 students, the college offers more than 100 degree programs in its schools of Business, Communications, Humanities and Sciences, Health Sciences and Human Performance, and Music.

Students, faculty, and staff at Ithaca College create an active, inclusive community anchored in a keen desire to make a difference in the local community and the broader world. The college is consistently ranked as one of the nation’s top producers of Fulbright scholars, one of the most LGBTQ+ friendly schools in the country, and one of the top 10 colleges in the Northeast.

We emphasized applying automation and continuous integration to focus the team on the efficient development of creative and easy to test solutions.

On the backend, the team—including members of Ithaca’s dev org working alongside Four Kitchens—built a Drupal 8 site. The transition to Drupal 8 keeps the focus on moving the college to current technology for sustainable success. Four Kitchens emphasized applying automation and continuous integration to focus the team on the efficient development of creative and easy to test solutions. To achieve that, the team set up automation in Circle CI 2.0 as middleware between the GitHub repository and hosting in PantheonGitHub was used throughout the project to implement, automate, and optimize visual regression, advanced communication between systems and a solid workflow using throughout the project to ensure fast and effective release cycles. Learn from the experiences obtained from implementing the automation pipeline in the following posts:

The frontend focused heavily on the Atomic Design approach. The frontend team utilized Emulsify and Pattern Lab to facilitate pattern component-based design and architecture. This again fostered long-term ease of use and success for Ithaca College.

The team worked magic with content migration. Using the brainchild of Web Chef, David Diers, the team devised a plan to migrate of portions of the site one by one. Subsites corresponding to schools or departments were moved from the legacy CMS to special Pantheon multidevs that were built off the live environment. Content managers then performed a moderated adaptation and curation process to ensure legacy content adhered to the new content model. A separate migration process then imported the content from the holding environment into the live site. This process allowed Ithaca College’s many content managers to thoroughly vet the content that would live on the new site and gave them a clear path to completion. Learn more about migrating using Paragraphs here: Migrating Paragraphs in Drupal 8

Steady scrum rhythm, staying agile, and consistently improving along the way.

In addition to the stellar dev work, a large contributor to the project’s success was establishing a steady scrum rhythm, staying agile, and consistently improving along the way. Each individual and unit solidified into a team through daily 15-minute standups, weekly backlog grooming meetings, weekly ‘Developer Showcase Friday’ meetings, regular sprint planning meetings, and biweekly retrospective meetings. This has been such a shining success the internal Ithaca team plans to carry forward this rhythm even after the Web Chefs’ engagement is complete.     

Engineering and Development Specifics

  • Drupal 8 site hosted on Pantheon Elite, with the canonical source of code being GitHub and CircleCI 2.0 as Continuous Integration and Delivery platform
  • Hierarchical and decoupled architecture based mainly on the use of group entities (Group module) and entity references that allowed the creation of subsite-like internal spaces.
  • Selective use of configuration files through the utilization of custom and contrib solutions like Config Split and Config Ignore modules, to create different database projections of a shared codebase.
  • Migration process based on 2 migration groups with an intermediate holding environment for content moderation.
  • Additional migration groups support the indexing of not-yet-migrated, raw legacy content for Solr search, and the events thread, brought through our Localist integration.
  • Living style guide for site editors by integrating twig components with Drupal templates
  • Automated Visual Regression
Aerial view of the Ithaca College campus from the Ithaca College homepage. From the Ithaca College Homepage.

A well-deserved round of kudos goes to the team. As a Team Augmentation project, the success of this project was made possible by the dedicated work and commitment to excellence from the Ithaca College project team. The leadership provided by Dave Cameron as Ithaca Product Manager, Eric Woods as Ithaca Technical Lead and Architect, and John White as Ithaca Dev for all things legacy system related was crucial in the project’s success. Ithaca College’s Katherine Malcuria, Senior Digital User Interface Designer,  led the creation of design elements for the website. 

Katherine Malcuria, Senior Digital User Interface Designer, works on design elements of the Ithaca.edu website

Ithaca Dev Michael Sprague, Web Chef David Diers, Architect,  as well as former Web Chef Chris Ruppel, Frontend Engineer, also stepped in for various periods of time on the project.  At the tail end of the project Web Chef, Brian Lewis, introduced a new baby Web Chef to the world, therefore the amazing Randy Oest, Senior Designer and Frontend Engineer, stepped in to assist in pushing this to the finish line from a front-end dev perspective. James Todd, Engineer, pitched in as ‘jack of all trades’ connoisseur helping out where needed.

The Four Kitchens Team Augmentation team for the Ithaca College project was led by Brandy Jackson, Technical Project Manager, playing the roles of project manager, scrum master, and product owner interchangeably as needed. Joel Travieso, Senior Drupal Engineer, was the technical lead, backend developer, and technical architect. Brian Lewis, Frontend Engineer, meticulously worked magic in implementing intricate design elements that were provided by the Ithaca College design team, as well a 3rd party design firm, Beyond, at different parts of the project.

A final round of kudos goes out to the larger Ithaca project team, from content, to devOps, to quality assurance, there are too many to name. A successful project would not have been possible without their collective efforts as well.

The success of the Ithaca College Website is a great example of excellent team unity and collaboration across multiple avenues. These coordinated efforts are a true example of the phrase “teamwork makes the dream work.” Congratulations to all for a job well done!

Special thanks to Brandy Jackson for her contribution to this launch announcement. 

Four Kitchens

The place to read all about Four Kitchens news, announcements, sports, and weather.

Jan 16 2018
Jan 16

It's no longer a matter of “Why?”, but a matter of “How?”. The conversational interface trend isn't going anywhere but... UP.

So, if you want to keep up with the break-neck pace at which your competitors will be launching their own chat-based apps this year, you first need to:

put an end to your “to go or to go conversational?” dilemma. You only have one option...

Then, to start focusing on more pressing issues:
 

  1. what are the user experience challenges to expect when designing conversational user interfaces (CUIs)?
     
  2. what are the best practices to adopt for creating state of art conversational experiences?
     
  3. how do you design a... conversation, after all? One that's natural, seamless, quick and ideally convenient for the user?
     

And once you've pondered on these 3 questions, go ahead and turn the following “enlightening” answers into your trump cards for designing your own rival to Siri, Alexa and or OK Google.
 

1. Put Together An Exhaustive List of Hypothetical Use Cases 

In other words: leave no dead ends in your chat-based app's script. No weak links that could impact your conversation's fluidity.

And how do you get “unpredictability” down to zero? By getting knee-deep in user research work. 

Invest plenty of time and teamwork in identifying all the possible use cases that your chatbot's scrip should cover... impeccably!

How will users react to hypothetical scenario A? And what queries is he/she likely to input in scenario B? What “tricky” request will he/she make?

Once you have THE list at hand, filling in your script with copy will sure feel just like putting the puzzle pieces together. 
 

2. The Onboarding Experience: Be Sure to Give It Special Attention 

The more straightforward your chatbot's onboarding message is, the more chances there are for the user to interact with your conversational interface.

In other words: take no chances, don't try to play smart, resist the temptation to turn your app into a “guessing game”!

Let the user know which are your bot's functionality and key features and how precisely it may serve him/her via:
 

  • a speech bubble
  • an intro message
  • a suggestive animation
     

… from the very beginning.
 

3. Focus on User Convenience When Designing Your Conversational Interface

And convenience in conversational UX translates into minimal user input!

Now here are 2 best practices to consider for achieving the proper level of user convenience:
 

  1. keep your copy crystal-clear and straight to the point: avoid ambiguity at all costs, like giving more than one answer to the same question or answers completely out-of-the-conversational-context, irrelevant to the user's intent
     
  2. keep the user's input to a minimum: the less your customer will need to type in/interact with your chatbot, the better; aim for “yes/no “questions and avoid overburdening them with too many choices to scan through and to select from
     

Extra tip: make your content ideally easy to squeeze through; keep your sentences conveniently short, thus anticipating that the user might head straight to the call to action.

Why should you discourage him/her with an almost impenetrable block of text to keep on scrolling through?
 

4. Set Up Visual Cues-Based Replies to Your Users' Queries

How would you improve readability in “conventional”/non-conversational design? You'd instantly reach out to your not-so-secret trump card — the whitespace — right? 

Well, in case of a conversational design, your trump cards are the visual cues.

Here are 2 examples of how/when you can use them for boosting readability and turning your conversational interface into a truly intuitive AI experience:
 

  1. Use them to assist your customers when in need; for conveying bite-sized information and addressing your users' queries in a highly intuitive way. Maps, charts, infographics images, GIFs will be far easier to “digest” than chunks of text and far more efficient for relaying the message
     
  2. Use them to convey... emotions: whenever words are not enough to convey the feelings you need to convey (e.g. giving them a warm welcome into the app), go with... visual cues; and emoji make the handiest of them all
     

5. Empathy Is Key to Designing a Human-Like Chatbot

A natural conversational interface experience is a human-like one. And a “humanized” AI app is one that easily passes the empathy test. 

Now here are 2 suggestions on how to “inject” empathy into your chatbot:
 

  1. Read the script out loud: how does it sound? Would you say those lines to someone close to you? Do they sound natural enough? Or rather robot-like? Is the conversation fluid enough?
     
  2. Pay attention to context and adapt your script accordingly. Now you wouldn't want your app to give a robotic-like, impersonal reply such as “I hate to hear that” to a user writing: “I feel a bit dizzy”. It goes without saying that you should anticipate all use cases and user queries and have all the context-suitable replies ready (popping up a map showing the nearby hospitals in this case, for instance)
     

6. Embrace the “Less Typing on the User's Side” Principle

For the less they'll need to type, the more fluid the whole conversational UX is going to be.

And, in this case, by far the most popular example to inspire you is Linkedin messager's automated replies. See how it provides users with plenty of choices, right at hand (multiple buttons, “attach a file” option, automated replies etc.)? 

In other words: whenever suitable, automate... everything and aim for user convenience at its best!
 

These are the “tips and tricks” that you may want to consider if you're determined to create a highly intuitive conversational interface experience for your chatbot's users. Ponder on them and see how you can adapt them to your own app's and use cases' scenario.
 

Dec 22 2017
Dec 22

Designers mapping out a website.

Designers mapping out a website.

So your site isn’t working the way you want it to. Maybe it’s sluggish, or you’re not seeing the conversions you want, or customers are complaining. Before you drop a huge chunk of your budget on a complete rebuild, consider that there might be a simpler (and more affordable) solution to your website woes.

We see a lot of Drupal 7 and WordPress websites here at Kanopi Studios, and we often discover that it’s more cost-effective for our clients to simply update their sites rather than rebuilding them. Making targeted updates can allow you to focus on addressing a few key issues, while still leveraging the investment of time, energy and funds that went into your site’s foundation.

In this series, we’ll look at three key topics to consider:

1. How do you know when it’s time for a change?
2. Is your website optimally organized and designed to be user-friendly?
3. How strong is your technical foundation?

How do I know it’s time for a change?

Do any of these problems sound familiar?

  • Low conversion rates
  • Site pages take more than 3 seconds to load
  • Site doesn’t work well on mobile or other devices
  • Updating content is a difficult and frustrating process
  • Users struggle to find what they need on the site or have shared negative feedback
  • Site crashes when updating
  • Too many bugs
  • Building new features is difficult or may not even be possible
  • Site is not loading on https and triggers security warnings

If your answer to any of these is yes, it’s time to take action.

But first … is it really that important for me to address these issues?

Yes! A website that isn’t working optimally can dramatically affect your bottom line. An out-of-date or poorly designed website can:

  • Damage your credibility. If your website loads slowly, is crowded with clutter or is just plain not working, you are sending the message that your company is unprofessional.
  • Make you appear out of touch. A dated website tells your customers you are behind the technological times, or worse – you don’t care enough to stay up-to-date.
  • Cost you customers. Every customer who leaves your site in frustration due to broken links, complex forms, slow pages or confusing navigation is a customer you won’t get back. If your competitors offer similar services and have a stronger website experience, your loss will be their gain.

Decision time. If you want to avoid the damage that a dated website can cause, you’ll need to either rebuild your site or update it. If you’re ready to take action, we can help you find the best and most cost-effective approach.

There are two primary things to consider when maximizing your site’s ROI: your user’s needs and the technology that drives your site. If you can identify and fix problems in both of these categories, you can most likely avoid a costly rebuild.

Venn diagram showing optimum website health at the intersection of smart user experience and strong tech foundation.

Venn diagram showing optimum website health at the intersection of smart user experience and strong tech foundation.


Next, we’ll dive a bit deeper into tips to help you level up your user experience and update your website technology without starting over from scratch. Consider it the non-surgical, diagnostic approach to improving your website experience right where it needs it the most. 
Dec 22 2017
Dec 22

Now that you’ve decided that it’s time to take action to improve your website, It’s time to see if any user experience upgrades could help. Take a look through our list of issues below, and the tips to help resolve them.

Having a hard time converting leads or getting sales?

If you’re not sure why you’re not generating business from your website, it’s time to get serious about strategy. Here’s how:

  • Add a survey to your website to understand what users are looking for
  • Take a look at your analytics to understand where you are losing your users. If you don’t have analytics installed, get either Google Analytics or Tag Manager set up on your site.
  • Try an online user testing platform like Hotjar to help you go beyond standard analytics with heatmaps, visitor recordings, conversion funnels and more.
    Complete a User Experience & Conversion Optimization Audit with Kanopi Studios. We can make a whole range of insightful recommendations within your budget. Contact us to learn more.

Does your site take forever to load?

If it takes longer than three seconds, you have a problem.

  • Use Google PageSpeed or Pingdom to test your site’s speed, understand what might be slowing it down and take action to resolve any issues.
  • Make sure you have a reliable hosting company backing your site at the right level for the amount of traffic you receive.

Does your site work on mobile? Is it accessible?

It’s vital to make sure your site is accessible to everyone, no matter what device or screen size they are using. Here’s how to check:

  • Try using your site on a phone or a tablet. If you have to pinch or zoom to interact with the content, it’s time for a responsive design.
  • Make sure you can tab through all navigation and content on your site using only your keyboard, that all images have alt tags, and that you are able to use a voice browser to “read” your pages out loud. If not, you are missing key elements of accessibility.
  • Contact Kanopi Studios about an accessibility audit. We can help you identify the issues and build a plan for how to resolve them.

Is it frustrating – or impossible – to update content on your site?

If it’s a major undertaking to change even the simplest thing, something needs to happen.

  • Define your ideal workflow, then ask an expert to take a look and see how you can optimize the backend.
  • Consider the types of content that your site needs to support. Do you have templates in place that meet your needs? If not, it may be time to consider a bit of design and development time to build additional page types on your site.

Getting negative user feedback?

If the people visiting your site are taking the time to complain, chances are they might also take the time to help you make things better. Here’s how:

  • Collect feedback by sending out a survey, or document your customer service calls.
  • Always thank people for taking the time to help you improve.
  • Look for trends in the information you are receiving from users and build a plan to address any issues to help meet their needs

If none of the issues above apply, congratulations! Your user experience is likely more solid than many of the websites out there! But there are still more things to consider before committing to rebuilding your site. In our next post, we will walk you through a number of common technical issues and some helpful fixes for them.

Oct 25 2017
Oct 25

Did you see this coming? 2016 was, undoubtedly, the year when chatbots ruled over the digital landscape. When all the “players” in the arena rushed to jump on this mega-trend and to ride the tide.

And then some of the voice interface's limitations have started to come out.

It's in this very context that the conversational form interface (not yet a mega-) trend has started to “steal away some of the spotlights”! It's then that designers with a vision decided to dig deep into the "old trunk" with out-of-fashion web interfaces and take out the “dusty” old web form

Yet, they weren't that naive to think that users would just move away from cool chat-based interfaces to... filling out clunky, long web forms. They definitely had to give web forms a modern touch to ensure user engagement.

And so, they made them... conversational!

This is how this “experimental” approach, the hybrid conversational form interface, was “born”! It's designed to improve user experience where conversational interfaces start to show their “weaknesses”. And it's designed to drift away from the classy, unanimously hated web forms.

Now, let us highlight for you here both:
 

  • the most “irksome” limitations that voice interfaces have started to show
  • how precisely the conversational form UI succeeds to deliver a better user experience where chatbots fail
     

The Biggest Inconveniences of Using a Purely Conversational UI 

“... for both users, development teams and site/app owners.”

It looks like chat-based conversational UIs have slightly loosened the “spell” that they had cast on users. 

Customers have gradually started to grow frustrated (and this is due mostly to their (too) high expectations in chatbots) when they realized that:
 

  • they have to (there's no other way) go through each and every single sentence that the bot asks, which leads to more tapping (and friction) than they would have expected
  • they can't just skip some of the questions in case they don't feel comfortable giving away certain sensitive information
  • they experience the whole information-collecting process as being mandatory, as if they're being “constrained” to divulge that data
     

On the other hand, compared to a conversational form interface, a purely conversational interface isn't any more convenient on designers'/developers' and their clients' side either:
 

  • dealing with the validation of some "tricky" answers isn't precisely a breeze (like when someone enters an invalid phone number, for instance)
  • in order to prevent all kinds of “dumb bot” experiences, the bot has to be perfectly “trained” to parse users' answers correctly (even when faced with situations where users give “I'm a butterfly collector” type of answers to a “What's your job title?” question)
  • it's no easy task for the app's/website's owner to actually set up the chatbot; they need to carefully plan ahead how the questions will be phrased, the used tone and voice etc.
     

How Exactly Does a Conversational Form Interface Increase User Engagement?

Now that we've “exposed” to you the voice interfaces' limitations, it's only logical that we present to you a solution to these issues, right?

Introducing web forms turned into conversations? Or conversational forms, if you prefer!

What started as an experiment now stands all the chances to perfectly fit all those scenarios when companies can't afford to just blindly jump on the latest UI trend! And where they need to go for a hybrid type of approach instead: conversational UI & web forms.

Here's what these “experiments” revealed:
 

  • users feel more comfortable knowing that they DO have the option to simply ignore filling in these conversational forms if they want to
     
  • since users interact with these forms only within conversations, practically these web forms aren't intrusive, like the old web forms used to be, when they would overlay on top of the open text fields; it doesn't feel like a disruption of the user's flow anymore
     
  • the same users tend to provide the required information much quicker than they do when faced with a conversational UI (they're already familiarized with web forms and they do not experience that “awkward” feeling that someone's “asking” them to give away information).
     
  • it calls for minimal bot interaction since users get to control, right within the form, whether they've correctly filled in the required fields or not (once they chose a wrong format, they can just correct it themselves)
     

In short:
 

  • it's not just the old “dreaded” type of web forms that users choose to fill in
  • they're actually delivered within the conversational UI itself
  • implicitly, it's not an exclusively voice-based conversation that we're dealing with
     

... but with a CI incorporating one or multiple web forms
 

Bottom Line 

“If it doesn't fit, just don't jump on the latest design trend!” As simple as that.

Conversational UI doesn't have to be “purely” conversational after all! It could also mean voice-based conversation AND interactive elements such as buttons, cards or forms.

If you anticipate that this type of chat-based conversational UI:
 

  • won't get you too far with your information-collecting
  • will just manage to irritate your customers
     

… you can always take a step back from what's currently “hype” and experiment another type of UI instead. Maybe this hybrid conversational form interface will best fit your needs and your customers' expectations. 

Maybe you'll be surprised to discover that it's those “oldies but goldies”, “dusty” designs that help:
 

  • your users carry out the given tasks faster and with minimal friction
  • you to collect that concise, basic information or data that you need for tailoring your offers/products to your questioned customers' own needs and preferences
     

What's your opinion on this hybrid approach to UI design?

Aug 09 2017
Aug 09
August 9th, 2017

We are excited to announce the completion of the second major development phase of our engagement with Forcepoint: improving the authoring experience for editors and implementing a new design.

Reimagining the Editorial Experience

Four Kitchens originally launched Forcepoint’s spiffy new Drupal site in January 2016. Since then, Forcepoint’s marketing strategy has evolved, and they hired a marketing agency to perform some brand consulting, while Four Kitchens implemented their new approach in rebuilding the site. We also took the opportunity to revisit the editorial experience in Drupal’s administrative backend.

Four Kitchens has been using Paragraphs on some recent Drupal 8 projects and found it to be a compelling solution for clients that like to exert substantive editorial control at the individual page level—clients like Forcepoint. Providing content templates for markup that works hand in hand with the component-driven theming approach we favor is a primary benefit we get from using Paragraphs for body content.

Editorially, the introduction of Paragraphs gives Forcepoint a more flexible means of controlling content layout for individual pages without having to rely as heavily on Panels as we did for the initial launch. We’re still using Panels for boilerplate and some content type specific data rendering, but the reduced complexity required for editors to layout body content will allow their content to evolve and scale more easily.

In addition to using paragraphs for WYSIWYG content entry, Forcepoint editors are now also able to insert and rearrange related content, Views, Marketo forms, videos, and components that require more complex markup to render.

We’re big proponents of carefully crafted content models and structured data. Overusing Paragraphs runs the risk of removing some or even a lot of that structure. Used judiciously however, it allows us to give clients like Forcepoint the flexibility they want while still enforcing desirable constraints inherent in the design.

Congratulations!

We’ve been working with Forcepoint for over a year now, and are incredibly proud of the solutions we’ve created with them. This kind of close relationship and collaboration is what we strive for with all of our partners. We thrive on understanding our partners’ underlying business challenges and goals, collaborating with their teams, and creating solutions that delight their customers.

The Forcepoint team was led by Chris Devidal as the project manager, working alongside Taylor Smith who acted as internal product owner. Jeff Tomlinson was technical lead and assisted Patrick Coffey who adeptly wrangled all the difficult backend issues. Significant frontend technical leadership was provided by Evan Willhite who worked with Brad Johnson to implement a challenging design. Props also go to Keith Halpin, Neela Joshi and Adam Bennett at Forcepoint for their many contributions.

Web Chef Jeff Tomlinson
Jeff Tomlinson

Jeff Tomlinson enjoys working with clients to provide them with smart solutions to realize their project’s goals. He loves riding his bicycle, too.

Jul 20 2017
Jul 20
Go to the profile of xpersonas

Jun 8, 2017

Simple Style Guide was created to be a fully flexible style guide for Drupal developers and site builders.

I’ve been using style guides for a while now. I can’t imagine developing any site without one, regardless of size. The idea behind this module was to enable devs and site builders to create a fully functional, living, style guide with only the elements you want and nothing more.

What I wanted was the ability to create one in a fast, effecient manner. No elements are required. No elements are added by default. And all this funcationality is fully accessible to site builders without having to write a single line of code.

Style Guide Settings

Default Patterns
You can choose from a set of very basic default patterns such as headings, text, lists, blockquote, horizontal rules, table, alerts, breadcrumbs, forms, buttons, and pagination. Chosen elements will appear on the style guide page. Choose as many default options as you like, or choose none.

Color Palette
You also have the ability to create a color palette by adding a hex color code, a class name, and usage descriptions (if desired).

Live Example of a Color Palette

Custom Patterns
You can also create custom patterns. Custom patterns can be any chunk of html that you want. There are no restrictions.

Add Any Custom Patterns

With these tools, I hope you will be able to create a very flexible style guide/pattern library. To view a live example of a working style guide, you can check out this page:

https://eisforeveryone.com/simple-styleguide

Jul 20 2017
Jul 20
Go to the profile of xpersonas

Jul 7, 2017

Simple Password Reveal alters password fields on user login and user edit forms to show plain text by default, while also adding a checkbox for concealing the password as needed.

Rather than creating friction for a user to show a password every time by clicking a checkbox, the password is revealed by default. In my own experience, I generally prefer password fields to be plain text almost all the time. It’s only when in public or during a presentation that I want to conceal passwords. And I’m not the only one…

There is another module that provides similar functionality. However, Simple Password Reveal takes a different approach than the Password Toggle module. They use javascript to add a checkbox to each password field in any and all forms. They also have a Drupal 7 version.

This module attempts to keep things simple by concentrating solely on the user login and user edit pages. If you need this feature on custom forms, on forms loaded by ajax, or for a Drupal 7 site then this module may not be for you.

Simple Password Reveal also uses form alters to add one checkbox per form, rather than one checkbox per input. So, for example, when you are on the user edit page you have three password fields — current password, new password, and confirm password. Rather than having a checkbox for each password field, this module only has one.

Jul 12 2017
Jul 12

“Riding the waves or caught in the tide?” Do you simply comply with whatever is hot in digital product design at the moment or do you dare to go beyond just following the trend of designing a conversational interface and turn it into an experience instead?

A natural, authentic, “human-like” one!

If you've chosen the first option, than you can remorselessly go back to doing what you were doing and spare the time you would invest in reading this post.

But if you're determined to go beyond the very basics of conversational UI design and to strive and “humanize” the experiences that you deliver, then you'll find the “UX toolkit” that we've “wrapped up” for you here more than helpful!

Basically it contains all the core principles for designing a conversational interface that's closest to a human-like conversational experience. 

Let's dig in:
 

First Things First: What Is a Conversational Interface?

When you say “conversational interface” you instantly say Siri or virtual assistant M!

And it's precisely these 2 examples that “authorize” us to divide them into:
 

  • chatbots (besides Siri, think of H&M's chatbot for instance!)
  • virtual assistants (Amazon's, Alexa's virtual assistant etc.)
     

What these conversational UIs do is practically mimicking human chatting! 

And it's the verb itself, “to chat”, that “warns” you that there's a shift of focus (as compared to the graphical user interface) from visuals to words themselves. With this in mind, you'll implicitly need to revise your set of core UX rules that you would have normally designed your GUI interface by!
 

But What Turned Conversational UI Into Such a Phenomenon?

That conversational interfaces have become ubiquitous is no news for anyone. 

But what are the factors that keep influencing its ascension in the digital world? Let us point out the 2 most impactful ones:
 

  • natural language processing technologies
     
  • artificial intelligence: is rapidly improving its capabilities to accurately “grasp” intentions interpreting the user's uttered words
     
  • last but definitely not least: our human nature itself; chatting is carved in our very DNA as social beings
     

In short:
 

  • recognizing the user's uttered input is no longer a challenge for nowadays technologies
     
  • as users (and “chatting human beings) we're instinctively drawn to this “new” type of interaction with technology
     

The Challenge You're Facing From a Conversational UX Standpoint

For there is, indeed, a challenge that you need to respond to once you go ahead and start designing your (first) conversational interface: adding the authentic human touch to your bot!

That's right! Since accurately interpreting the user's spoken input is no longer a challenge, “humanizing” the conversational experience that you deliver via your interface is a serious challenge! 

How do you craft conversations that sound natural and authentic, that are both helpful and... delightful? This is the question!

And now let's dig deeper into our list of UX principles to apply for successfully responding precisely to the aforementioned challenge: creating human-like conversations!
 

1. Create a Consistent Persona 

How could you possibly “humanize” your conversations with no information (or with just vague info) precisely on those “humans” that your bot will be chatting with?

This being said: defining a persona is the very first step to take, way before you even start to design a “draft” of your future conversational UI!

Draw your target user's “portrait” by determining and then writing down its personality traits. It's these traits that will let your team know how to approach him/her. What conversational scenarios to put together. What vocabulary to start setting up and so on.

And did we mention “consistent persona”! By “consistent” we meant that once you have your user's backstory and personality traits established, your conversational UI needs to remain consistent in the tone, words and phrases that it will use. 

You don't want a banking app to start with a formal tone and then “spice it up” with one or two slang words, now do you?
 

2. Create and Maintain a Natural Conversation Flow

Conversations between your users and your chatbot/virtual assistant should simply... flow fluidly, naturally!

This means that at no time should your user feel like he/she's putting some sort of effort to overcome obstacles for establishing a good communication with your system.

And here are some UX “hints” for keeping that conversation flowing:

2.1. Promptly Guide Your Users With Hints

… don't wait till they get too confused and clueless about how they're supposed to start the conversation with your chatbot or about how precisely this one can help them!

How? By simply providing them guiding hints! 

For instance, your chatbot/voice assistant can initiate the conversation itself via a short introduction and a clear call to action! 

2.2. Set Up Your System's Purpose

What should your voice assistant/chatbot do? What user problem should it solve, promptly and effectively (with at least input/effort from your users as possible)?

Make sure you define one clear purpose that your chatbot should serve!

Make it:
 

  • unique (no need to go for a multi-purpose, too-hard-to-handle type of system)
  • make it clear (for your team)

2.3. Strategically “Sprinkle” Some Well-Timed Earcons

And we feel like stressing out the word “strategically”!

For it's only the proper, well-thought usage of earcons (well-timed earcons) that will help you liven up your conversations!

When triggered precisely at key stages of the conversation these audio sound effects (applauses, musical feedback, beeps) will come to break an otherwise monotonous tone of the conversation. To infuse some personality!

It's also a sign for users (take Siri's “Ding!Ding” earcon) that it's their turn to ask questions, that the app is then “listening” to them. 

2.4. Keep Away from Open-Ended Questions!

“And from the rhetorical ones, too!”

One you've given your users the chance to choose from a multitude of possible answers to the questions asked by your chatbot... you'll “lose” them!

And it's the same case with rhetorical questions, too, since users tend to respond to them anyway and confuse your system.

In other words: stick to close-ended questions, giving your users no possibility to confuse your system with a “surprise” answer, one that you haven't pre-set in its conversational scenarios!
 

3. Keep The Conversation Natural and Authentic

Modeling the conversation to an authentic, real-life human one should be your main objective once you start designing your conversational interface!

And here are some UX principles to follow for achieving this level of “authenticity”:

3.1. Humanize It

Go beyond the “robot-like” chabot and aim for a human-like one!

And you'll only get to this level of “humanization” if you properly leverage those persona traits and back-story that you will have established!

Don't be afraid to throw in a slang word or two (if your target audience's profile and your own app's nature permit), to go informal and to use that specific tone and vocabulary that your target users would use in their day-to-day life.

Familiarity is key here!

If you manage to make your chatbot talk like a member of that specific community, then you will have won them over, you will have convinced your users to go on and keep engaging in conversation with your system!

3.2. Keep It Concise and To the Point

Since mimicking natural, real-life chatting sure means sticking to short phrases. For that's how we communicate, in brief, succinct phrases, and your system should stick to this pattern of the conversational speech.

And speaking of concision in real-life conversations, here are 2 “paths” that your conversational UI should stick to:
 

  1. avoid asking multiple questions at once
  2. request information from your users one by one
     

Note: It''s true though that utterly concise and straightforward “yes” and “no” answers tend to make a conversation sound a bit mechanical. This is why our Toronto web development team's advice to you is to masterfully alternate phrases/answers of different lengths and to rely on turn taking, too. This way, even if the answers are just the simple “yes” or “no” type, the conversation becomes far more engaging, less robot-like.
 

4. Let Your Users Be in Control 

Make them feel that they're in control at all time! During the entire conversational experience!

Now here are some UX tips and tricks to apply for placing total control into your users' hands:

4.1. Enable Them to Start All Over Again

It's crucial that you provide this possibility! Your users should be able to reset the conversations that they'll engage it. At any time!

4.2. Provide Helpful Guidance and Assistance 

Whenever your customer/user feels lost and confused make sure to prompt in some help messages and to suggest him several options to choose from!

4.3. Provide "Undo" and "Cancel" Functionalities

And this is a key UX principle to apply, both in case of a graphical user interface and of a conversational one! 

Allow them to change their minds and don't turn wrongly inputted data into an “irreversible mistake”!

Remember to integrate those two crucial functionalities into your conversational interface and thus enhance your customers' experience!

4.4. ASK Them to Confirm, Don't Just State

And following this “rule” is critically important when you're dealing with sensitive user inputs (credit card details for instance).

Each time you need them to confirm an option that they will have selected or an action that they will have asked the system to carry out for them, it's always best to “ask” for their confirmation. To “double check” with them, instead of just stating the action that's being performed on their behalf. 

Needless to add than by asking them to confirm you're making them feel in control of the app!
 

5. Boost Their Confidence 

Reinforcing users' perceived self-efficacy goes hand in hand with restoring their confidence. And with smoothing their experience with your chatbot or voice assistance, too, of course!

Let them know that your system has understood their questions and requests! That your chatbot has validated and confirmed the data provided.

So, “sprinkling” some “Got it”, “OK” and “Sure” acknowledgers throughout the conversation will just keep your users going, keep them listening to your bot and willing to chat with your system.

Note: for a more natural conversational experience randomize your acknowledgers! It will make the conversation sound less monotonous and more fluid!

And our list of 5 UX principles to apply when you design your conversational interface ends here! Have we missed any key “rule(s)” to be followed for “humanizing” chabots/voice assistants?

Mar 22 2017
Mar 22

It's no doubt that these web design myths “controlling”, just like some “tyrants” the online world, have initially emerged as web design innovative notions, turned into widely used techniques and, finally, into highly influencing web design trends. 

It's also true that since their “adopters” have started to take them way too literally or to refuse to adapt them to the ever-evolving digital landscape, to the ever-changing users' digital behaviors, these web design practices have gradually turned into... myths. Into rigid, “dusty” web design mindsets risking to affect both the design's quality itself and the website visitors' experiences.

Be better than that! Be smarter than that! Take smarter design decisions than those still “stuck” with these preconceived assumptions which are no longer relevant in 2017's web design context. 

And here are the 10 web design myths “exposed”:


1. "The 3 Second Rule"

This is probably the best exemplification of a notion turned into a rigid “rule”. Of a concept taken ridiculously literally!

No need to develop a paranoia imagining your generic website visitor holding a timer in one hand and his mouse (if we're talking about a desktop user) in the other and counting precisely those 3 seconds! It's absurd!

The 3 second rule is just a figure of speech (it could easily be a 2 second a 4 or 5 second rule) “invented” only to stress the importance of an optimized page loading time. To “warn” you that you should constantly strive to boost your website's performance. 

If your web pages load in, let's say, 4 seconds, it's really not the end of the world!

Instead, if they load in 3 seconds just to show a bad design and low quality content... then you might be, indeed, facing a major traffic problem!


2. "White Space Is a Wasted Chance of Capitalizing Space on My Site"

This is already a “prehistoric” type of web design preconception!

And we couldn't give you better examples than Google's front page and Apple's clean and airy design where big chunks of white space act as spotlights directing our eyes towards their “star” products!

“Clutter” is your biggest enemy when it comes to web design! While white space and moreover, strategically using it for guiding your users' attention towards key points on your website, well, this is almost an “art”!

Less sure is more, in this case! White space acts as a spotlight focused on the key content(s) on your web pages, but only if you just know just how to focus it!


3. "Mobile Device Users Are Always On the Fly and Easily Distracted" 

It's a false assumption now “cemented” in the collective thinking: mobile device users are always on the go, always in a rush and easily distracted!

It's noting but an exaggerated generalization!

In fact, studies (Google's studies, the one that we're referring to here taken in 2012) have shown that:
 

  1. 68% of mobile device users are, in fact, accessing websites from their smartphones in the comfort of their homes (surprise, surprise!)
     
  2. 67% of desktop users are simultaneously using another device, as well, as compared to 57% of mobile device users. 
     

We're all living in the age of distractions. We get constantly distracted whether we're just watching TV, doing online shopping on our smartphones or reading articles on our PCs! 

You should still design for highly mobile users, but being fully aware that “on the run”, “striving to resist various distractions”, is not the main context that your mobile device users will be visiting your website in!


4. "Good Usability's a Must, While Good Aesthetics an Option"

This thinking's maybe one of the riskiest user experience pitfalls!

With all the web designers and web owners out there playing all their cards on good usability, they tend to undermine good aesthetics' key role or (even worse) to ignore it completely.

You can't effectively reach out to your users and turn them into customers, if you don't emotionally connect with them, first. If you don't strive to make the very best impression (and since we're all highly visual creatures, a “good first impression” is nothing but another word for “great looks”).

Usability's a very technical concept, made of certain (equally) technical, precise tactics to implement for achieving good usability on your website. While aesthetics is far more “human” and it's to humans that you need to reach out to first and only then to... “prospects”. Do keep that in mind!

When combined, these two “powers”, good usability and good aesthetics, or, better said, good usability and credibility (that good aesthetics invests your Drupal website with) you can't get but a superpower to turbocharge your website with!


5. "User Feedback Is Not to Be Questioned or Debated"

Of course that you should constantly ask for your users' feedback, it's vital for every business, be it online or not!

What you should avoid doing is: taking that feedback, all the comments that your visitors will leave on your site, too literally!

People don't always know what they want and they're quite bad at explaining their preferences, why is it that they like/dislike certain features on your website or anticipating their future choices/behaviors.

A “healthy” way of doing web design is to dig in, starting from your users' comments, to the core problems! Base your design decisions on those core problems to be solved, first and foremost! Complying with your users' suggestions/complains, should come second on your list of “motivations”.
 

6. "Simplicity Can Only Mean Minimalism"- One of the Popular Web Design Myths

And this web design myth is still influencing, to a great extent, web designers' work and website owners' design decision-making!

There's this popular belief turned into a whole trend, that you can't possibly achieve a simple design than by cutting out UI elements, by drastically reducing steps and user interactions on your website.

False! Even a complex web design can be made simple if you're a gifted web designer!

Focusing on simplifying users' experiences and reducing the visual surface (minimalism) is not the same thing as reducing all the “friction” that a way to laborious, overly demanding design would imply from the user's point of view (simplicity).

Its not the same thing as striving to reduce some of the energy that he/she would invest in visually “digesting” the content on your website.

Notice the difference?


7. "Good Design is Self-Sufficient"

“Design in the absence of content is not design, it’s decoration.” 

Therefore, looks aren't everything and good design isn't self-sufficient! Visually-arresting graphics, cool fonts and visually-appealing colors won't compensate for the absence of high quality content.

In other words: if there's no happy “marriage” between web designers and content marketers, you'll be left with a great looking website that only you and your team will get to admire. For no user will ever find it!

If you don't enhance your great looking design with meaningful, engaging content that not only that completes it, but adds extra value to it, with content that addresses your visitors' needs, then your design won't go beyond its decorative function.


8. "The Homepage Is The Most Important Page on My Site"

Homepage's “supremacy” has started to fade away! If it used to be the page that users always landed on first, since it served as the main directory and, therefore, since there was no other way for accessing a website, today this is no longer the case.

And it's time that you, too, started to see the homepage's supremacy as a web design myth!

Now users can land directly on a product page, coming from certain links posted on social media or on other sites. Your website's visitors might not even get to visit the front page at all.

Moreover, and this is especially the case with websites selling products or services, you should accept the fact that your users aren't there for delighting themselves with the “wow” content on your homepage! For them your front page is nothing but a “gateway” to the product pages that they're really interested in. Or, depending on the site's specificity, to the information they can find on other pages of your Drupal site..

Think of Facebook! How often do you visit its homepage as a logged in user?

Put together, all the web pages on your site are much more frequented than your homepage. Just think about that!


9. "The Three Click/Two Tap Rule"


This is another baseless assumption! That all the elements on your website should be at a three-click's distance or a a two-tap's distance (on mobile devices).

Irrelevant! Whether your users decide to prolong their visits on your site or to leave it  after just a few seconds, has nothing to do with this rule. User's main interest is to carry out his task (purchasing something, getting a key info etc.)

You could abide by the three click rule and still witness visitors leaving your website in a rush if the content that they'll you'll deliver them, after precisely these three clicks/two taps, doesn't engage them or meet their needs.

As a general rule: it's precisely when web design rules are taken too literally that they risk to turn into web design myths!


10. "Cutting Out The Navigational Choices"- One of the Influential Web Design Myths

Somehow this theory initially related strictly to short term memory and to multiple product choices, has started to impact web design, particularly navigation, as well!

It's one thing to cut out items from an excessive product/services collection (leading to the paradox of choice) and a completely different thing to start removing pages from your navigational bar/menus. 

It's those pages that grant your user easy access to the content on your site that he's interested in. It's them that will enhance his/her exploration of your website!

So, instead of blocking his/her access to different web pages on your Drupal site and of negatively impacting his overall experience with your website, you'd better figure out how to efficiently group these pages.
 

And it seems that we've reached the end of our list of 10 web design myths you should be aware of and... stay away from! Have you “busted” others, as well?

Jan 06 2017
Jan 06

Mobile rules the day or better said: mobile has been ruling the whole year of 2016 and is here to stay, to constantly evolve and to dominate the digital landscape in 2017, too!

It will continue to redefine the way users perform different actions online and it will definitely continue to reshape the way companies conduct their businesses online.

Implicitly, it has started to redefine the way online marketers are crafting their landing pages, too. 

How are you adapting to “the new way” of designing landing pages? Have you gone beyond the “simply stacking content at mobile size” mentality? Have you started to approach content differently when you build your mobile landing pages?

To cut out the lengthy content? To reconsider the placement of your conversion elements, due to the limited amount of space at your disposal?

As you ponder upon the above questions and reexamine your previous mobile landing pages, scan through these 5 strategies bellow, strategies that we, ourselves, are using here, at our web development company in Toronto, strategies aimed at helping you convert your users on mobile:
 

1. Think Through Your Mobile Content 

Content is (the almighty) king on mobile, too! Just make sure you don't “push it off” its throne by approaching it the wrong way.

Which is this “wrong approach” you say? 

Not adapting your mobile content to your own specific area of activity and, therefore, to your specific target audience's expectations, as well!

Instead of “jumping on whatever's the most popular trend right now” when it comes to content's ideal length on mobile devices (some will say you should go for a 500-word, others for a 1000-word piece of content for your landing page), you should run some A/B test yourselves.

But that only after you've drawn some pretty logical conclusions from analyzing your area of activity and studying your target audience, too:

  1. Let's assume you run a plumbing company; well, then, my friend, you can't expect a user accessing your landing page (going through a pipeline leak “crisis”) to be willing to read a lengthy piece of content detailing various types of pipelines (let's say), before he/she will have scrolled down like a madman for finding your contact details. It's common sense deduction don't you think?
     
  2. Let's assume that you run a luxury goods company; considering your items' high prices, you should expect your potential customers to want to read detailed product descriptions, including all the details they need for making their final decision. You should expect them to want pictures, lots of pictures, which will help them visualize those expensive items from various angles, to read all about the lifetime guarantee that you provide and so on.

In one word: you can't just play by “what's most likely to happen” and you definitely can't risk guessing, either.

Just keep in mind the type of products/services that you're selling through your landing page!

Takeaways:

  • A common sense rule is to place your conversion elements and important content as high as possible on the page, but not to be afraid to continue to deliver quality content and more information about your business bellow the “fold” at the bottom of your users' screens 
  • It's perfectly true that more often than not mobile users would stop with their scrolling (and reading) to he bottom of their screen
  • But! There are also surveys revealing that if websites feature a user-friendly interfaces and engaging content (such as video content) they're more likely to keep scrolling down
     
  • Shorten your paragraphs, more frequent paragraph break will help your mobile (potential) shoppers to easily “digest” your content. Remember that a paragraph of reasonable length on desktop will look awfully “crowded” when compressed for the mobile screens! Therefore: ease your reader's job and break your content into breaf paragraphs!

2. Consider and Prevent User Experience Barriers 

As we've already relentlessly pointed out here, on our blog: user experience is and will be the main “generator” of online initiatives, strategies and plans impacting your business. You simply can't afford underestimating it!

How does the user experience factor shape your mobile landing page designing efforts?

Easily! It will challenge you to foresee that whole journeys that your users will take once they visit your landing page. It will also challenge you to to review it, beforehand, on multiple mobile devices and by asking the opinion of several users.

Now speaking of the user experience barriers that you should avoid, here are a   examples:

1. Illegible Text on Mobile Devices

Don't just transition your text from desktop to mobile and consider your job done!

Make sure your text, once shrunk to mobile size, still looks legible. Is the font too small? How about the background color? Does it impair legibility or not?

Tip: your goal shouldn't be to keep your user “captive” on your mobile landing page, but to direct him/her on your primary Drupal website instead. Therefore, remember to make your logo visible and to provide footer links back to your site.
 

2. The Temptation of Using Interstitial Forms

No matter how tempting it might look to you to use such conversion tactics, resist it!

The result is sure to be a high number of users who'll instantly bounce off your landing page instead of that luring no. of converted users that you might have in mind!

Note: if on the desktop variant of your website it might be easier for your users to click the “X” for closing your newsletter sign up form, just imagine how frustrating this action gets on mobile. Your users might just assume that you will have specifically made it impossible for them to close your form and you can just guess how this will affect your conversion rate, right?
 

3. Faulty Responsive Design

Take your time (it will be well invested time) to think through how you'll stack all the elements of your landing page at a mobile size!

By doing so you'll avoid risks such as: users having to scroll down excessively in order to reach your “Contact” button or your form.

This will also allow you to apply the right layout adjustments for placing your contact form higher on the mobile-size page or for opting for a “Contact” button that remains visible on the page as the user scrolls down.
 

3. Don't Lose Sight of Your Goal: Conversions

It's not (just) for presenting your products/services, for “wowing” users or for “showing off” your design skills that you're building your mobile landing page! But for converting your users!

That's your main goal and you should steer all your efforts towards reaching it! 

How do you do that “constrained” by the limited pace you have on a mobile devices' screen? 

Here are a few tips:

  • you keep in mind to place and to make visible a click-to-call button; remember that it's from their mobile devices that your users access your landing page and, therefore,  they're far more likely to place a call for service than desktop users
  • you keep in mind to place both a “Contact” button and a prominent contact form on your mobile landing page
  • you keep in mind that your form's fields might get awfully shrunk and thus impossible to be tapped on when transitioned from desktop to mobile. Make sure to fix this issue!
     

4. Make Sure That It Loads “Instantly”

Remember that it's mobile users that you're reaching out to! They don't expect your landing page to load (just) quickly, but instantly! 

Gather your team of web development experts and run some speed tests and then figure out how you could optimize your mobile landing page for a better performance!

You simply can't afford to underestimate this aspect!
 

5. Properly Test It Before Launching It

Without proper testing all your (mobile) landing page building efforts risk to be nothing but a waste of resources!

How do you run “proper” tests on your landing page? Here are some good practices for testing your landing page performance before launching it:

  1. You “recruit” your testers from both the Android and iOS users' communities; make sure to pick users owing different types of mobile devices for getting them to test your landing page
     
  2. You run A/B tests (you could use tools such as Google Analytics, Optimizely, Content Experiments) to find out which is the most efficient way of placing elements on your landing page
     
  3. You install a heatmapping tool (we recommend either Hotjar or Crazy Egg) to discover how far into the content your users would scroll down and what elements on your landing page they're more likely to engage with
     

And here is how you do it! Here is how you put together not just visually-pleasing, but also efficient mobile landing pages. 

What other strategies have you been successfully implementing for converting your mobile users?

Dec 12 2016
Dec 12

Don't you just feel the sweet taste of new possibilities right now?

And still, any new Drupal 8 project comes with its own set of challenges, as well, and choosing a theme, from the very start, is probably one of the greatest ones.

What should it be then?

Should you go for a classic base theme (AdaptiveTheme or Zen, maybe), for a contributed theme instead or maybe you prefer implementing the framework yourself or build your very own theme, from scratch, relying on Drupal core?

Before you make the decision that will have a huge impact on your whole project's structure, take some time to go through this quick “quizz” here and try to give yourself some clear answers:
 

  • are you dealing with a multi-site project (meaning that your theme, once chosen and implemented, will be used across all the other websites, too)?
     
  • is the person maintaining the theme a HTML guru or a CSS expert?
     
  • will this theme be used just on the website itself or for internal apps as well?
     
  • what level of front-end performance optimization does it imply?

Classy vs Stable: Which Base Theme Works Best for You?

This might just be the most important choice to take during your Drupal project's life-cycle!

It's your theme that dictates/overrides your CSS, JS and Drupal's markup, you know. Where do you add that your chosen theme can feature a parent-child relationship, where the sub-theme inherits the base theme's templates, JS and CSS.

In short: think through your theme choice for the sake of your project's success and your whole workflow!

“And still, which one to choose: Classy or Stable?”, you might ask yourself.

Here's how you can tell which one suits you (as a Drupal developer, with certain goals in mind and with a certain theming experience) and your particular web project (which comes with its own set of particularities):

  • are you planning to add classes only where the context demands them? Then Stable's The base theme for you!
  • do you want lean markup, with very little classes (e.g toolbar and contextual links), giving you the freedom to customize your own markup patterns in your theme, to create only those classes that are required by your project? Stable again, is the “lucky” word, in this case!
  •  do you want to have a set of classes at your disposal, to tweak and use as styling hooks, right from the starting point? Then it "write" Classy all over your Drupal project!

This being said, let's see which are the 5 factors that you should consider before you choose your Drupal 8 base theme:
 

1. How Much CSS and Markup Updating Does it Require?

How much CSS out-of-the-box does your chosen theme come “equipped” with?

It makes a great difference, you know. Take these two examples for instance:

  1. You decide to build your website on Classy theme, which in Drupal 8 comes with very little core CSS, so you will have to write your own classes and occasionally even to override the templates, depending on what you want your classes to style. 
     
  2. You're building your theme on Zurb Foundation or Boostrap, which come with their own of out-of-the-box classes that all you need to do is apply to your markup. What's important for you to keep in mind, if you incline for this particular work scenario, is that once you have your Drupal site built, there's going to be a lot of template customization to do for adding all those out-of-the-box classes to your site's new components!

2. Has Your Client Expressed Any Preference?

Your client may or may not come with his/ her own preferences when it comes to the theme that you and your team should to build his website on. 

Be sure to have one aspect settled with your client, during your before-the-project meetings: are you supposed to maintain the theme that you two will decide upon on the starting point or is there a chance that this should be replaced with a new one, as the project unfolds? It's essential that you discuss this aspect with your client, for it's important for both of you to consider the learning curve (and implicitly the extra time) of each new theme.

In case your client has no specific preferences regarding the theme to be used for his site, your own theming experience and your development process preferences will be the only factors that will influence your theme choice!
 

3. Consider the Design 

It's no news for any developer, no matter his/her level of experience, that Drupal is tremendously flexible! When it comes to theming, it allows you to build practically anything you want: ranging from a large web app, to great customer-facing websites in the latest design and functionality trends!

Depending on what exactly you need to design in Drupal, you get to choose among several platforms:

  1. Ember or Adminimal make some great administrative themes, that will do their job superbly helping you build your back-end app
     
  2. Zurb Foundation or Bootstrap make great choices if your web project includes components such as tables and forms 

4. Will You Be Using a Pattern Library?

A base theme always makes the perfect choice if you're planning to create your own patterns.

In other words: keep it simple, at the theme level, especially if you'll be applying your own classes, which will then get themed by your own pattern library styles!
 

5. Consider Performance

Less is always better! You keep that in mind and let this common-sense motto guide you through your theme selection!

The more functions, JS libraries and settings your website needs to load, the heavier its “burden” will be (and the longer its load time will be, as well).

Go for a light theme based on Drupal core, which won't come equipped with its own heavy load of out-of-the-box JS libraries and CSS and remember that if less is always more, so does “testing makes it perfect”!

Remember to test all the theme settings on your website, thus keeping its front-end performance closely monitored!

These is our list of factors that any Drupal developer should take into account and think through before choosing the base theme for his/her project. Do you have any other aspects that you usually consider and which determine you to go for a specific base theme or another once you start your Drupal web projects?

Nov 17 2016
Nov 17
November 17th, 2016

Background

Automated (or “living”) style guides are a popular topic in frontend development these days. And it’s no surprise, as they benefit the integrity of the project as well as ease design and development (as you can see in Part 1 of this miniseries!). Four Kitchens has a long history of using static style guides within projects, but as the frontend team re-evaluated our process this year, we wanted to standardize around an automated styleguide for future projects. By automating this part of our process, we ensure the style guide always reflects the latest design and code during the entire life of the project.

We began by evaluating existing automated style guide tools and narrowed the selection down to a couple that made sense alongside our existing toolset: KSS and Pattern Lab. We then committed to testing these in real projects to expose strengths/weaknesses so that we could eventually choose the best tool for our needs. Randy discussed KSS in a previous article, and in this article we will explore Pattern Lab.

Pattern Lab & Atomic Design

Pattern Lab is one of the more established style guide tools out there and is the brainchild of Brad Frost, best known for his “atomic design” principles. When evaluating Pattern Lab, it’s best to start by understanding atomic design.

Atomic Design

Put simply, atomic design just asserts that like organic matter, design systems can be broken down into their smallest pieces and built up from there. In web development, this means we shift from the mentality of building “pages” to breaking down designs into patterns, organized smallest to largest, and use these building-block patterns to develop the project. Here are the categories commonly used in this approach:

  1. Atoms: simple HTML tags (e.g., <button>, <input type="text" />, </button>
    <h1>
    , <a>, </a></h1>)
  2. Molecules: small combinations of atoms (search form, menu, lists)
  3. Organisms: groups of molecules forming a distinct design section (header, masthead, footer)
  4. Templates: organisms combined to form contextualized designs
  5. Pages: fully actualized templates often with real content

There is a video from the Pattern Lab website that demonstrates this best. Some folks get distracted by the lingo (atoms, molecules, etc.), but you should see these naming conventions as only one way to break down components into a logical structure. Pattern Lab actually allows you to use any category names you want. Pattern Lab does, however, expect you to use atomic design in that it wants you to organize patterns smallest to largest regardless of the category names.

Pattern Lab

On the technical side, Pattern Lab is a static site generator powered by either PHP or Node that supports Mustache and Twig templating languages. The Node version has Grunt and gulp support as well. Importantly, Pattern Lab is open-source and actively maintained.

In terms of built-in perks, Pattern Lab not only ships with a nice stock UI, it allows you to populate pattern data using JSON or YAML and then annotate the patterns using Markdown. It also provides a way to easily create pattern variations as well as pattern states (e.g., in progress, needs review, approved). It also ships with a pattern searching tool and a viewport resizer in the toolbar to easily test/demo your components across any screen size.

Building Patterns in Pattern Lab

Patterns are small chunks of HTML that may also contain CSS and/or JavaScript. In other words, there are no technical hurdles for a current Frontend developer to build these components—only the mental shift in breaking a design down to its logical atomic design parts.

Let’s take a look at building a simple button component. We’ll be using Twig as our templating language.

The button component is comprised of a file with the button’s markup (button.twig):


<a href="https://www.fourkitchens.com/blog/article/frontend-style-guide-miniseries-part-three-pattern-lab//{{ url }}" class="button{% if variation %}--{{ variation }}{% endif %}">{{ text }}</a>

and a stylesheet containing the component styles (button.scss)


a.button {
  background-color:#35AA4E;
  border:none;
  color:#fff;
  cursor:pointer;
  font-size:100%;
  padding:1em 2em;
  text-transform:uppercase;

  &:hover {
    background-color:#eee;
    color:#35AA4E;
    text-decoration:underline;
  }

  &--alt {
    @extend .button;
    font-size: 80%;
    padding: .5em 1em;
  }
}

To take full advantage of Pattern Lab, let’s also create some default data (button text and URL) and some annotations to help describe the component. For the data, let’s create a simple button.yml file:


url:
  "/"
text:
  "Default Button"

This is what will populate the Twig variables in our markup above. And now let’s create an informative annotation that will display in the style guide. For this, we’ll create a Markdown file (button.md):


---
el: ".button"
title: "Default button"
---
Here we can see the default button styling in action.

This all shows up in Pattern Lab like this:

Screenshot one.

As you can see, we have our component name, followed by our annotations with code snippets in both Twig and HTML versions (another Pattern Lab perk) and then we have the design element itself, our button.

Let’s now add an alternative button option. It’s as simple as adding an alternative YML file (button~alternative.yml). The tilde character tells Pattern Lab this is a variation, and Pattern Lab uses the name after the tilde as the variation name. Let’s add this content to the file:


url:
  "/"
text:
  "Alternate Button"
variation:
  "alt"

You may have noticed that button.twig contained a check for a variation variable that added the variation as a modifier class (class="button{% if variation %}--{{ variation }}{% endif %}"). This alternate YML file supplies that variable, which means our template will change the class accordingly. This is what Pattern lab looks like now:

Screenshot two.

As you can see, Pattern Lab makes it quick and painless to create components with variations and metadata. From here, Pattern Lab also makes it easy to build nested patterns and to link patterns to one another to form a full, working prototype.

Final Thoughts

Adopting any new technology has its pain points, and it is of course no different with Pattern Lab. The latest version of Pattern Lab (v2) overcame our frontend team’s strongest critiques, namely that Twig is now natively supported and data can be specified in YAML format. I personally also like that annotations can now be written in Markdown, as it is a great format for this type of notation. My only remaining critique is that while writing components comes easily, debugging or tweaking core Pattern Lab does take some effort as the codebase is fairly large. This critique, for me, is far outweighed by all the built-in perks I mentioned above but I thought it worth mentioning.

Overall, I would argue Pattern Lab is one of the strongest contenders on the market for creating an automated styleguide. If you would like to learn more, consider reading through the documentation on their website or jumping into the codebase. Mostly, I would recommend downloading and installing Pattern Lab, as it’s the most rewarding way to learn atomic design while building an automated styleguide.

Stay tuned next week for the thrilling conclusion of our Frontend Style Guide Miniseries!

Recommended Posts

  • In this issue: come see us at DrupalCon Amsterdam, Instagram CSS3 filters, ontology is overrated, Douglas Crockford: the better parts, iPhone promo products from Japan, Go-powered robots, tree simulator MMO,…
  • In this issue: Come hang out with us at DrupalCon LA: we're speaking, training, playing Drupal Games, and bowling with Aten and Kalamuna! Plus, Markdown Here, more responsive media sites,…
  • In this issue: DrupalCamp Stanford 2015, party at DrupalCon Los Angeles, Headless Drupal and Frontend Performance training, and UX methods; plus WIRED's new multimedia stories, the look and feel and…
Evan Willhite
Evan Willhite

Evan Willhite is a frontend engineer at Four Kitchens who thrives on creating delightful digital experiences for users, clients, and fellow engineers. He enjoys running, hot chicken, playing music, and being a homebody with his family.

Design and UX

Posts about user experience: best practices, tools we use, methodologies we love. Posts about the design process: wireframes, colors, shapes, patterns. Frontend posts that focus more on the user interface aspects (visual, aural, etc.) than on coding practices.

Read more Design and UX
Nov 15 2016
Nov 15

This post is the second in a series covering Zivtech's usage of Gulp for front-end development in Drupal 8.

In the last post, I covered how to setup Gulp for teamwork on Drupal 8 projects. In this post, I'll go over how to get started with writing Gulp tasks. I'll also break down a specific task for Sass linting to ensure good code quality.

Maintainable and Readable Gulp tasks

With any mid-to-large sized Drupal 8 theme, it's really easy for the main Gulp file (gulpfile.js) become unwieldy and complex. With dozens of tasks doing all kinds of automated work, before too long, gulpfile.js becomes a soup of illegible code.

Additionally, members of your team might have different ways of naming Gulp tasks. One person might write a Sass building task called "buildSass" and another might create an identical task called "css."

It'd be nice to strip down gulpfile.js, make it readable, and somehow compartmentalize each task separately. Also, we want to cut down on task naming variations and create a unified system for structuring our tasks.

My current favorite way to handle these wishes is gulp-require-tasks. Basically, each task is written as an individual, CommonJS style module. Then, the tasks are arranged in directories, and that directory structure defines the task name. It is a very simple and predictable way to setup Gulp tasks.

Structuring Gulp tasks

Start off by creating the file tree structure below:

├── project/ │ ├── .gitignore (ignore node_modules, gulpfile.yml) │ ├── package.json │ ├── gulpfile.js │ ├── default.gulpfile.yml │ ├── sass │ │ ├── styles.scss │ ├── js │ │ ├── scripts.js │ ├── gulp-tasks │ │ ├── styles │ │ │ ├── lint.js │ │ │ ├── build.js │ │ ├── scripts │ │ │ ├── lint.js │ │ │ ├── build.js

The YAML settings file, default.gulpfile.yml, was discussed in the last post of this series, if you need a refresher.

gulp-require-tasks lets these tasks be accessible according to their structure. For example, to build the styles, you'll run "gulp styles:build" and to lint the JavaScript, you'll run "gulp scripts:lint." If you don't like the colon delimiter, you can change that too.

Update Gulp settings

In the last post we started the default.gulpfile.yml, and now we'll edit that same file to add in settings for the Gulp tasks we'll create in this project.

Open the file: it should look like this:

themeName: "myTheme" themeDescription: "myTheme description"

Expand on that by adding settings for source and destination paths of Sass and JS:

themeName: "myTheme" themeDescription: "myTheme description" styles: src: "sass//*.scss", dest: "css" lint: enabled: true failOnError: false scripts: src: "js//*.js", lint: enabled: true failOnError: false

Under the "styles" and "scripts" sections of the YAML, you can see I added some linting options too. From within the YAML settings, people can enable or disable linting, and also decide if they want the Gulp process to stop when linting errors are detected.

Pulling these settings out of the Gulp tasks themselves and into this YAML file means that developers don't have to search through the tasks looking for settings to change. Instead, they have every setting exposed to them in this one, concise file.

Importing tasks for Gulp

We haven't written any Gulp tasks yet, but we can go ahead and setup importing them so they can be used.

Open up the gulpfile.js we started in the last post. It should look like this:

(function () { 'use strict'; var gulp = require('gulp'); var yaml = require('js-yaml'); var fs = require('fs'); var assign = require('lodash.assign'); // read default config settings var config = yaml.safeLoad(fs.readFileSync('default.gulpfile.yml', 'utf8'), {json: true}); try { // override default config settings var customConfig = yaml.safeLoad(fs.readFileSync('gulpfile.yml', 'utf8'), {json: true}); config = assign(config, customConfig); } catch (e) { console.log('No custom config found! Proceeding with default config only.'); } })();

If you recall, we loaded the default.gulpfile.yml and overrode that with any settings from gulpfile.yml if it exists. The gulpfile.yml file has the exact same structure has default.gulpfile.yml, but settings can have different values. This lets other developers on the team override some settings if needed.

At this point in gulpfile.js, the config is loaded and ready to be used. Next, we integrate gulp-require-tasks.

(function () { 'use strict'; var gulp = require('gulp'); var yaml = require('js-yaml'); var fs = require('fs'); var assign = require('lodash.assign'); var gulpRequireTasks = require('gulp-require-tasks'); // read default config settings var config = yaml.safeLoad(fs.readFileSync('default.gulpfile.yml', 'utf8'), {json: true}); try { // override default config settings var customConfig = yaml.safeLoad(fs.readFileSync('gulpfile.yml', 'utf8'), {json: true}); config = assign(config, customConfig); } catch (e) { console.log('No custom config found! Proceeding with default config only.'); } gulpRequireTasks({ path: process.cwd() + '/gulp-tasks', arguments: [config] }); })();

Setting up gulp-require-tasks is super easy. We tell it where our gulp tasks are located, in the "gulp-tasks" directory.

Then, to each module (i.e. 1 module will be 1 Gulp task) in the directory, gulp-require-tasks passes arguments to each task. The first argument is always gulp itself. The "arguments" setting for gulp-require-tasks is an array of other things you want to pass to each module. I've opted to pass in "config," which is the object representing the settings merge in the YAML files.

This is essentially all you need in gulpfile.yml. However, I also like to add shortcut tasks too, that combine other tasks for quicker use. For example, general "build" and "lint" tasks might be like this:

gulp.task('build', ['styles:build', 'scripts:build']); gulp.task('lint', ['styles:lint', 'scripts:lint']);

Modular Gulp tasks

Let's start off creating the Sass linting task. To help with this, I recommend using gulp-sass-lint. You'll want to read over how to setup sass-lint, which I won't cover in detail here. Essentially, you create a .sass-lint.yml file in the root of the project. That file contains all the rules you want to validate; for example, should developers avoid styling with IDs or should they use RGB rather than HEX values for colors.

After sass-lint rules are in place, open up the styles linting file. Here you'll see the guts of the linting task:

'use strict'; var cached = require('gulp-cached'); var sassLint = require('gulp-sass-lint'); var gulpif = require('gulp-if'); module.exports = function (gulp, options) { if (options.styles.lint.enabled) { return gulp.src(options.styles.src) .pipe(cached('styles:lint')) .pipe(sassLint()) .pipe(sassLint.format()) .pipe(gulpif(options.styles.lint.failOnError, sassLint.failOnError())); } else { return console.log('css linting not enabled'); } };

For the three required packages, you'll want to "npm install" them of course. Don't forget the "--save-dev" flag to get those packages stored in package.json!

The bulk of the code exists within the standard, CommonJS "module.exports" directive. A Gulp process is passed into the task as well as the set of options from default.gulpfile.yml.

We start off by running a quick if/else check so that we short-circuit out of this task if the user disabled Sass linting. Then, we pipe in the files that we selected in the Gulp settings' "styles.src" section. Files are then piped through gulp-cached, which keeps a list of the source files (and contents!) in memory. This makes the task faster.

Next, the styles are linted and the results are formatted and reported out to the console. Finally, we use gulp-if to determine if the Gulp process gets terminated now should there be linting errors.

The sky's the limit

I leave it as an exercise for the reader to go about developing the other Gulp tasks. In the next post, I'll go over some other, more complicated Gulp tasks to show more advanced usage. Until then, you're more than welcome to look over and reference our own Gulp tasks we publish for Bear Skin.

Posts in this series

  1. Use Gulp for Drupal 8 with Teams, Part 1: Gulp Setup
  2. Use Gulp for Drupal 8 with Teams, Part 2: Creating tasks
Oct 26 2016
Oct 26

Gulp is a mainstay of front-end development nowadays. Of course, like all front-end development tools, there is a massive proliferation of build systems, from Webpack to SystemJS and Grunt to Gulp. Yet, we at Zivtech find ourselves using mostly Gulp, particularly when dealing with Drupal 8 projects.

This article is the first of a series of posts where I outline how Zivtech uses Gulp. In this first part, I'll talk about our reasoning and setup process.

Why does Zivtech use Gulp for Drupal 8?

The choice of Gulp over other front end tools is due to how Drupal utilizes front-end assets. It's perfectly fine to use something like Webpack or Browserify with Drupal, but those all-encompassing, "build and combine all the things!" systems are best used for projects that don't have a built-in asset pipeline. For example, Drupal concatenates and minifies CSS and JS for us, and it's really just over-compiling (is that a word?) to use something that Drupal obviates.

Also, we use Gulp over Grunt or even Broccoli (because yes, that's a thing too) strictly because Zivtech does a lot of node.js development as well. The concept of streams and buffers in Gulp are used throughout node.js, and it makes sense that we'd align with our other development.

Many projects and distributed teams

As a client services company, Zivtech has many projects and several teams working on projects. Thus, our building tasks have to be somewhat abstract so as to apply to most situations. So the first step to conquering the Gulp pipeline is figuring out a way to make the tasks themselves static, but let the configuration remain changeable.

Some examples of these changeable settings include: the website address that Browsersync should proxy when watching your development. It's possible that this website address could change on a per-user basis too. Also, the website name would change on a per-site basis too.

Within each project, we could just alter the Gulp tasks directly to account for these differences. Yet some people on the team may not be too familiar with Gulp and you might be sending them into the weeds trying to suss out "that one weird setting" they should change.

At this point you might be thinking we should make a settings file for each project's Gulp tasks, and you'd be correct if so! The Gulp tasks remain the same, but the settings always change.

As it turns out, Drupal 8 has a preferred method for settings files: the YAML format. Being a flexible guy, I vote for just sticking with what the system wants. Thus, our new settings files will be written in YAML.

Using YAML for Gulp settings

First, let's think about how we're going to implement settings from a big picture perspective. We've already determined that we'll work in YAML and we'll have a default group of configuration settings available. We also want each member of the team to be able to override some settings to fit their situations.

It makes sense that we'll have a file called default.gulpfile.yml for the default settings. Gulp should merge another file, we'll call it gulpfile.yml, on top of the default. The default settings get tracked in Git or your chosen version control system, but the other one should not. This allows for complete flexibility of any setting you or one of your teammates might want.

In default.gulpfile.yml, start off by creating some basic settings:

themeName: "myTheme" themeDescription: "myTheme description"

Next, create a gulpfile.yml to contain your customized settings:

themeName: "myRenamedTheme"

When Gulp runs, the themeDescription setting should match default, but the themeName setting should be overridden.

Finally, in your gulpfile.js:

(function () { 'use strict'; var gulp = require('gulp'); var yaml = require('js-yaml'); var fs = require('fs'); var assign = require('lodash.assign'); // read default config settings var config = yaml.safeLoad(fs.readFileSync('default.gulpfile.yml', 'utf8'), {json: true}); try { // override default config settings var customConfig = yaml.safeLoad(fs.readFileSync('gulpfile.yml', 'utf8'), {json: true}); config = assign(config, customConfig); } catch (e) { console.log('No custom config found! Proceeding with default config only.'); } })();

Now, when you run any Gulp task, your config files will get merged by lodash. One day, Object.assign will be more widely available, and lodash won't be needed any longer. For now, things work fine this way.

You'll notice that loading the custom config is in a try ... catch block. We do that so there are no show-stopping errors if the custom config is not found. Additionally, if it's not found we can let the user know that only default settings are in use.

Wrapping up

Well, this has been a high-level explanation of how and why we use Gulp at Zivtech for D8 projects.

In the coming articles in this series, I'll expand on the simple gulpfile.js and default.gulpfile.yml files started. I plan to outline our process for linting and compiling CSS, linting and compiling JavaScript, and a couple extra tasks too, like integrating Bower and favicon generation. Until then!

Posts in this series

  1. Use Gulp for Drupal 8 with Teams, Part 1: Gulp Setup
  2. Use Gulp for Drupal 8 with Teams, Part 2: Creating tasks
Jun 23 2016
Jun 23

These days, it’s pretty rare that we build websites that aren’t some kind of redesign. Unless it’s a brand new company or project, the client usually has some sort of web presence already, and for one reason or another, they’ve decided to replace it with something shiny and new.

In an ideal world, the existing system has been built in a sensible way, with a sound content strategy and good separation of concerns, so all you need to do is re-skin it. In the Drupal world, this would normally mean a new theme, or if we’re still in our dream Zen Garden scenario, just some new CSS.

However, the reality is usually different. In my experience, redesigns are hardly ever just redesigns. When a business is considering significant changes to the website like some form of re-branding or refresh, it’s also an opportunity to think about changing the content, or the information architecture, or some aspects of the website functionality. After all, if you’re spending time and money changing how your website looks, you might as well try to improve the way it works while you’re at it.

So the chances are that your redesign project will need to change more than just the theme, but if you’re unlucky, someone somewhere further back along the chain has decided that it’s ‘just a re-skinning’, and therefore it should be a trivial job, which shouldn’t take long. In the worst case scenario, someone has given the client the impression that the site just needs a new coat of paint, but you’re actually inheriting some kind of nasty mess with unstable foundations that should really be fixed before you even think about changing how it looks. Incidentally, this is one reason why sales people should always consult with technical people who’ve seen under the bonnet of the system in question before agreeing prices on anything.

Even if the redesign is relatively straightforward from a technical point of view, perhaps it’s part of a wider rebranding, and there are associated campaigns whose dates are already expensively fixed, but thinking about the size of the website redesign project happened too late.

In other words, for whatever reason, it’s not unlikely that redesign projects will find themselves behind schedule, or over budget - what should you do in this situation? The received agile wisdom is that time and resources are fixed, so you need to flex on scope. But what’s the minimum viable product for a redesign? When you’ve got an existing product, how much of it do you need to rework before you put the new design live?

This is a question that I’m currently considering from a couple of angles. In the case of one of my personal projects, I’m upgrading an art gallery listings site from Drupal 6 to Drupal 8. The old site is the first big Drupal site I built, and is looking a little creaky in places. The design isn’t responsive, and the content editing experience leaves something to be desired. However, some of the contributed modules don’t have Drupal 8 versions yet, and I won’t have time to do the work involved to help get those modules ready, on top of the content migration, the new theme, having a full-time job and a family life, and all the rest of it.

In my day job, I’m working with a large multinational client on a set of sites where there’s no Drupal upgrade involved, but the suggested design does include some functional changes, so it isn’t just a re-theming. The difficulty here is that the client wants a broader scope of change than the timescales and budget allow.

When you’re in this situation, what can you do? As usual with interesting questions, the answer is ‘it depends’. Processes like impact mapping can help you to figure out the benefits that you get from your redesign. If you’ve looked at your burndown rates, and know that you’re not going to hit the deadline, what can you drop? Is the value that you gain from your redesign worth ditching any of the features that won’t be ready? To put it another way, how many of your existing features are worth keeping? A redesign can (and should) be an opportunity for a business to look at their content strategy and consider rationalising the site. If you’ve got a section on your site that isn’t adding any value, or isn’t getting any traffic, and the development team will need to spend time making it work in the new design, perhaps that’s a candidate for the chop?

We should also consider the Pareto principle when we’re structuring our development work, and start by working on the things that will get us most of the way there. This fits in with an important point made by scrum, which can sometimes get forgotten about: that each sprint should deliver “a potentially shippable increment”. In this context, I would interpret this to mean that we should make sure that the site as a whole doesn’t look broken, and then we can layer on the fancy bits afterwards, similar to a progressive enhancement approach to dealing with older browsers. If you aren’t sure whether you’ll have time to get everything done, don’t spend an excessive amount of time polishing one section of the site to the detriment of basic layout and styling that will make the whole site look reasonably good.

Starting with a style guide can help give you a solid foundation to build upon, by enabling you to make sure that all the components on the site look presentable. You can then test those components in their real contexts. If you’ve done any kind of content audit (and somebody really should have done), you should have a good idea of the variety of pages you’ve got. At the very least, your CMS should help you to know what types of content you have, so that you can take a sample set of pages of each content type or layout type, and you’ll be able to validate that they look good enough, whatever that means in your context.

There is another option, though. You don’t have to deliver all the change at once. Can you (and should you) do a partial go-live with a redesign? Depending on how radical the redesign is, the attitudes to change and continuous delivery within your organisation and client, and the technology stack involved, it may make sense to deliver changes incrementally. In other words, put the new sections of the site live as they’re ready, and keep serving the old bits from the existing system. There may be brand consistency, user experience, and content management process reasons why you might not want to do this, but it is an option to consider, and it can work.

On one previous project, we were carrying out a simultaneous redesign and Drupal 6 to 7 upgrade, and we were able to split traffic between the old site and the new one. It made things a little bit more complicated in terms of handling user sessions, but it did give the client the freedom to decide when they thought we had enough of the new site for them to put it live. In the end, they decided that the answer was ‘almost all of it’.

So what’s the way forward?

In the case of my art gallery listings site, the redesign itself has a clear value, and with Drupal 6 being unsupported, I need to get the site onto Drupal 8 sooner rather than later. There’s definitely a point that will come fairly soon, even if I don’t get to spend as long as I’d like working on it, where the user experience will be improved by the new site, even though some of the functionality from the old site isn’t there, and isn’t likely to be ready for a while. I’m my own client on that project, so I’m tempted to just put the redesign live anyway.

In the case of my client, there are decisions to be made about which of the new features need to be included in the redesign. De-scoping some of the more complex changes will bring the project back into the realm of being a re-theming, the functional changes can go into subsequent releases, and hopefully we’ll hit the deadline.

A final point that I’d like to make is that we shouldn’t fall into the trap of thinking of redesigns as big-bang events that sit outside the day-to-day running of a site. Similarly, if you’re thinking about painting your house, you should also think about whether you also need to fix the roof, and when you’re going to schedule the cleaning. Once the painting is done, you’ll still be living there, and you’ll have the opportunity to do other jobs if and when you have the time, energy, and money to do so.

Along with software upgrades, redesigns should be considered as part of a business’s long-term strategy, and they should be just one part of a plan to keep making improvements through continuous delivery.

May 31 2016
May 31

If you are a developer or a web development agency and you’ve just built a web development prototype, you might often find yourself in a bit of a pickle – your users might find it ugly or your web development demo might look very bad. Here are a few "golden" design tips for web development, guidelines on how to make your web development demos look as good as they deserve.

Keep your cool, By Far One of The Most Valuable Design Tips for Web Development

One way of putting it is like this: “Good design, when it’s done well, becomes invisible. It’s only when it’s done poorly that we notice it.”. Jared Spool’s quote is spot on for all design work but it’s especially true when it comes to web development and demos. If you are building a web development demo users shouldn’t really pay attention to the design aspects of it, but its functionality and purpose.

If you’re trying to make your demo more stylistic, you’re actually moving away from your ultimate goal – keep it simple and focus on its functionality. If it doesn’t look as good as you’d want it to be, try removing some web development design elements such as effects, borders or shadows.

Try to avoid complex color palettes

Poor color choices can make or break a design – your color picks should be made during the UI design process, even if it can be tempting to make bold color choices early in the project.

When making the UI wireframe, you’ll begin using monochrome rudimentary lines and shapes. Once you finished that part, you can start adding more details until you reach the color aspects of your project. Here are a few tips when picking your colors:

It’s a good idea to keep your demos monochrome with plenty of greys until you’re ready to color it up properly.

Another tip is to avoid fully saturated colors, especially when your demo will be viewed on an illuminated screen as this can lead to discomfort for your users.

In the same time, you should avoid black and white due to the same reasons as previously stated – sticking to shades of color will make your users less tired and improve UX.

Add color to your monochrome design but do it just one at a time – each color can be a distraction to your users. Pro tip: you can use a range of saturations of just one color – this will offer plenty of variety and you basically can’t go wrong.

Simple typography works best

If you’re building a web development prototype or a demo there’s no need to for fancy fonts but here are a few pointers on typography:

If you don’t know what to pick, sans-serif works best in all situations. Serif fonts usually have details where strokes terminate. These fonts can help you bring a little bit of personality to your design and at the same time make your text easier to read. While serif fonts have some advantages, they’re not usually used for UI design since at smaller sizes they display varied stroke weights.

Other fonts you should take a look at are humanist droid sans, used by Google in their Android interface, noto, and roboto. If you’re an Apple fan you can go for San Francisco or Neue Helvetica. Firefox OS uses Fira Sans. All these are sans-serif fonts which you can use for your project.

Sometimes characters can be difficult to distinguish – combinations such as 9g, 6b, 2Z, 5S, I11 or 8B can be very confusing for users, depending on the font chosen. It’s best to first test them out in order to see readability and if that’s fine keep using it, if not, do some changes.

White space works wonders

Functional space or white space helps web development designers in many different ways – this space reduces your visitor eye strain, can help draw attention to particular areas of your page and creates a general sense of balance. Cramped UI will make users tired and uncomfortable but keep in mind that “less is more” works perfectly at this stage.

More breathing space will offer your users a breather as well – boosting line heights, margins and plenty of padding works great. And this is one of those priceless design tips for web development to put on top of your "must-do" list.Spread everything out on your design and it will look much better.

Spacing needs to be consistent throughout your design – consistency is the key to harmony and rhythm.

Improve your web development workflow

Foundation and Bootstrap can be a great help to developers even though they receive criticism for making websites look too generic – these tools are perfect for prototypes. Foundation and Bootstrap actually make the right choices on your behalf, leaving you with ample time to focus on other aspects of your project.

Spare yourself the extra work and just grab templates from Foundation or Bootstrap which you can customize to fit your style. Most of these templates are very comprehensive, so you’ll definitely have all the pieces you need to get going.

Conclusions

By following these design tips for web development you’ll smooth any problems you may encounter when building a prototype or demo.

May 23 2016
May 23

Working as a developer you might sometimes find yourself in a situation where you’re dissatisfied with your work but you simply can’t figure out why. Even if you research and read design theory books, it’s very though to create seamless design work at the snap of a finger. Luckily enough, there are ways to improve your work with very little effort. Here are 8 tips on creating great design.

Font weight

Thin fonts are all the rage in 2016 but they are risky to use simply because they can cause eye strain. Eye strain occurs when users have a hard time reading text or they must focus more in order to be able to read it. This can quickly exhaust anyone and force them to exit your website. Thin fonts are usually quite hard to read, especially on certain backgrounds, so it’s a good idea to make changes whenever necessary. The optimal font weight is around 400 as this will create the least amount of eye strain – try to be more receptive when you get feedback regarding the readability of your text and fonts, it will pay off in the long run.

Colour contrast

When entering a website, the first thing a user does is to quickly scan all the content and search for information regarding their problem. If they can’t find a solution to their problem, they’ll most likely bounce. When designing a page, any page…you need to keep the user’s needs in mind. Let’s say you are designing a services page – your visitors need to be able to find the “next” button or a contact button fairly quickly or else they will just leave. Contrast is an excellent way to help your visitors discover all nooks and crannies of your website. Using rich and vibrant colours for links and buttons is highly recommended.

Icons will give you some personality

Let’s start off by saying Font Awesome really is awesome. Make use of icons whenever and wherever appropriate – your visitors will thank you for it. We live in a world ruled by signs – red is danger, green is safe and blue is comforting. Use it to your advantage! Spare your visitors the effort of reading every little bit of text on your website by simply adding an icon next to it – it will help clarify your text and make it a bit more user friendly.

Clarity is the key to good content

When writing content for your website or pages, it can get pretty confusing. Your average user will spend less than 10 seconds on a website to try and find the information they need before they search for another one. It’s a good idea to always have simple ~5 word headers over any block of text. This will help your user know if the information is of any value to him or her – time’s expensive!

Clickable elements need to be obvious

If you want someone to click on a link or button, you’d better make it obvious that it’s clickable! Menu items, buttons and links are common clickable items on a website. That being said, make sure that your buttons have a high colour contrast compared to the rest of the page and that your menu items have an icon next to them. You can also play around in CSS to change their colour when the user hovers over them. Links should always be in blue – having some call to action text next to the link can also help.

Colour your website properly

Colours should bring order and clarity to your website. You should never use too many similar colours as this can cause eye strain for your user. Colours can also clash with each other, making the user’s brain work harder to figure out what is what. Colour balance needs to be attained through careful and patient testing!

Keep information consistent

Every piece of content on your website should have the same layout and approximately the same size. Your information’s colour, format and proximity to other links or related pieces of information should be consistent throughout the whole website. Different portions of content that are different but fill the same role should also be consistent. For example, if you offer a basic, medium and premium offer all information regarding these offers should have the same size and the same font. You can get creative, but keep it consistent!

Text alignment

If you want your user to feast on all the information provided on your website, you should make each and every piece of information as digestible as possible. Alignment can help you do that easily. Alignment should be where the user’s eye begins – either left or centre-aligned. 

Conclusions

When coding, you can make mistakes and you’ll get error messages. But with design, mistakes or errors can be difficult to spot. Think about these tips when building up your project or go through them when you’re in a pickle and soon enough these principles will be imbedded in your workflow!

May 11 2016
May 11

Bootstrap is a giant framework with almost everything you could need for building a site or web app interface. Bootstrap is changing, version four is in alpha release. Naturally, we’re just as curious to know what’s different, so I dived into the documentation to find out. Keep in mind, though, that this is an alpha release. It cannot be considered feature-complete. It could radically change.

From Less to Sass

This is obviously the biggest and most important change. Heck, you’ve probably already heard of it. People have gone so far as to procliam the “death of Less” due to this switchover. Well, I don’t know if anything’s gone and died because the Bootstrap team decided to do things differently. It is, however, a monumental undertaking, and it will drastically change how people use and customize the framework. Sass is just generally more developer-friendly, with wider support, a bigger community, and yes, more features. It can do some things that, right now, Less just can’t. I say this with sadness. I’ve never made any secret of my love for Less; but it seems that the community at large has spoken, and declared that Sass is just, well, better.

New features

Figures

Figures are for showcasing single media objects (usually images), with an optional caption. Support for Bootstrap’s various helper classes is factored in, so you can align and style the image (and its caption) however you like. Images placed in a figure element, given the right classes, become responsive automatically.

Flexbox

Now, due to lack of support, Flexbox has not replaced the regular grid system. However, it is available to anyone who wants it. Change a variable, recompile the Sass, and boom! You now have a new, modern layout system.

Cards

Okay, we’ve been seeing the proliferation of card-based design for some time now. Bootstrap now has a specific component for them, with myriad layout options. You can group them up, keep them separate, add headers, footers, buttons, images, and overlay text on those images. Wells, thumbnails, and panels all get replaced by the new card component, so in that way, Bootstrap is a bit more streamlined.

Reboot: new customization variables

Bootstrap has historically been a bit of a pain to customize, aesthetically speaking: There were a lot of styles to over-write, and individual variables to customize if you wanted to make your Bootstrap-based site look like anything other than a Bootstrap-based site. Heck, remember all of those customization apps made just for changing Boostrap’s look? Well the developers have heard your prayers and Github issues. Change all of the transition animations at once, disable rounded corners, change all the colors, or anything else you like with one big bunch of Sass variables. It’s all there in the Reboot module, and it’s about time. We can expect some more original-looking designs now, with any luck.

Rem and em units

That’s right, we’re moving away from pixels, to these relational units of measurement. This ties into the whole customization thing, too. Want a tighter design with thinner margins? Change the main text size, maybe a couple of variables, and boom. Everything looks “thinner”.

Stuff that’s basically the same

As you might expect, everything got re-written and upgraded (because of the Sass move). But still, the basic usage for most of these components will be the same. Do double-check the documentation, though. Certain things will have changed. Take the grid, for example: they added an “extra-large” tier to the grid system, presumably for those ridiculously huge retina screens that we’re seeing these days. · Alerts · Breadcrumb · Button dropdown · Button group · Buttons · Card · Carousel · Code · Collapse · Dropdowns · Forms · Images · Input group · Jumbotron · Label · List group · Modal · Navbar · Navs · Pagination · Popovers · Progress · Reboot · Scrollspy · Tables · The Grid · Tooltips · Typography

Other updates

No more IE8 support

It’s about time. There’s not a whole lot more to say about that. Not much will change for most of us. Anybody who really, really needs to support legacy browsers will have to use an older version of Bootstrap.

All JavaScript plugins have been re-written

The proliferation of ES6 means that a lot of people are re-writing their JavaScript. This means performance improvements for all, the exodus of older browsers, and programmers having fun with new toys. It’s a win-win.

Overall impressions

Where Foundation is going “smaller” and more streamlined with specialized frameworks, Bootstrap seems to want it all. They have done a lot of work to improve performance, and streamline what they could, but Bootstrap still aims to do just about everything you can think of. Mind you, anyone can configure their version of the framework however they like by dropping unnecessary modules, or adding new ones. It’s not a big deal. Still, there’s definitely a one-size-fits-all mindset in play. And that can be a good thing. There are large, wide-scope projects out there that need the room to expand. In any case, Bootstrap will continue to satisfy its users’ needs. It’s going to be mostly the same, but better.
Source: http://www.developerdrive.com

Apr 07 2016
Apr 07

I’m not a fan of color theory. But the theory has always eluded me, and, truthfully, I’ve never found it useful when trying to use color in my projects. Somewhat ironically, I’ve been finding that the better I get at choosing and using color, the better I become in the theory behind it. Of course, that doesn’t really help when you’re just starting out, does it? That’s why, in this article, you won’t see a single color wheel. Instead I’m going to show you a simple color workflow that you can use in your next web project. You will, of course, subconsciously be learning the theory along the way. So, I recommend coming back in a few months time and giving the theory another go.

Choosing A Base Color

We can see something like 10 million colors at any given time, that’s a huge amount of colors. And out of those, we need to choose one — just one color — to be the base of our website, for our brand. Everything will stem from this one color, so it’s kind of important.

How to choose a starting color

Now, picking a color out of the blue (pun intentional) would be quite easy, but we’re not going to do that. For any project in which you’re having contact with clients, you should try to justify as many of your choices as you can. If you don’t, it’ll be a case of your favorite color versus their favorite color. They’re the client. They’re paying you. They will win. Don’t think too much about it. Just make sure you have some kind of reasoning behind your color choice (and every choice, for that matter). It’ll make you look good.

Tips on choosing a starting color

• Use what you have. If the client has a logo with an established color, that will usually be your starting color. • Eliminate your competitors’ colors. If one of your main competitors has a strong brand color, don’t copy it if you can help it. Find your competitors’ colors to eliminate them from your own color schemes. • Think about your target audience. The colors of a website for a pizza shop would sure be very different from the colors for a kids club. Think about who will be using the website and how you want them to feel (excited, serious, taken care of, etc.). • But don’t default to stereotypes. If you’re designing a website for young girls, you don’t have to use pink. Avoid clichés to gain credibility. • Play a word game. If you’re struggling, write down any words that you associate with the client’s business. This list should give you some ideas for colors. If you’re really struggling, hop on any website about color meanings and see which fits best. You should now have a base color in mind for the design. It should be something simple like red, green, blue, yellow or pink. We’ll get to the exact shade next. Let’s say you choose blue.

Choosing A (Nice) Base Color

Instead of messing about with Photoshop’s color-picker to find a nice shade of blue, we’re going to steal like an artist and use other people’s design choices to help us out. First, go to Dribbble.com and Designspiration.com and click on the “Colors” link in both. You can use this as the next step to find the right shade of blue. For a fresh and energetic brand, go for one of the lighter, brighter blues (one of the top five options). For something a bit more corporate and serious, the bottom five should be a better fit. Choose a shade from each website to see actual designs that use that color. You can then use any of CSS-Tricks’ color-picking techniques to grab the exact colors right in the browser. Not only will you see different versions of your base color, but you will easily see colors that match.

Creating A Strong Color Palette

All right, you should now have a HEX value for your color. Now we’re going to make a palette out of that color. And it’s easier than you think. The problem with this kind of color palette is that applying it to a real design isn’t very practical. Most palettes have way more colors than you’d ever need, especially considering that we need to add an average of three neutral colors to every scheme: • white, • dark gray, • light gray (optional). If you tried to add five or six colors to the neutrals, it would be a mess. All you really need are two colors: • a base color, • an accent color (we’ll get to this in a jiffy). If you can create a website using only these five colors, you’ll get a much better result than if you were to go overboard with complementaries, split-complementaries, triads and the rest.

Finding your accent

Your accent color will be used in very small amounts on your website, usually as a call to action. So, it needs to stand out. Your next step is to go to Paletton.com and type your HEX code into the color box. From here, you can find your accent in two ways. First, you could click the “Add Complementary”! That yellow there? That’s your accent. Alternatively, if you don’t like the color it has generated, you can click around the icons at the top to find something more suitable. Personally, I quite like the red that comes up under the triad icon, so I’m going to use that for our scheme. There is, of course, science and stuff behind what Paletton is doing; but, for now, let’s put a pin on it. You’ll learn the theory a bit later, and all will become clear. So, below is our color scheme as it is now. We’ve got a nice base color and a shot of an accent. Let’s add white to the mix, because white is always good. All that’s missing now are some grays.

Adding the gray

For most of my web projects, I find having two shades of gray to be infinitely useful — one dark, one light. You’ll use them a lot. The dark is usually used for text, and the light for when you need subtle differentiation against all that white (usually for backgrounds). You can choose your grays in one of two ways: • You could use Dribbble.com and Designspiration.com again to find a nice gray from your previous results that matches your base color. But usually it’s easier to type blue website in the search bar, which will show more grays in the results. • If you have Photoshop or the like, you could use Erica Schoonmaker’s technique to harmonize your grays with the base color.

Creating harmonious grays

To get our shiny new harmonious grays using Erica’s method, we’ll start by picking two default grays out of a hat. Then, follow these steps: 1. Create two shapes and fill them with #4b4b4b and #f5f5f5. 2. Insert a color fill layer above your two shapes. 3. Change that fill to your base color. 4. Set the blending mode to overlay, and bring the opacity right down to between 5 and 40% (in the example below, it’s set at 40%). 5. Use the color picker and copy your new values. I should point out that this method works exceptionally well when your overlay color is blue. For any other color, you will want to either bring the opacity right down to 5 to 10% or stick with your original grays. Our color scheme is complete.

Applying Your Color Scheme

Now that we’ve got our color scheme, it’s time to apply it. This is a whole other article unto itself. Tip: If you struggle with color, a good trick is to create your website layout in grayscale first. Figure out the hierarchy, and then experiment with the color later. Our accent, red, stands out beautifully against the base color. This is used in very small areas, for buttons and in the icons. The less you use this color, the more it will stand out. The dark gray is used for the text, logo and icon outlines. (Don’t skip putting the colors in your icons. It’s a small detail but makes a big difference.) The white and light gray form the background. The light gray doesn’t have to be here at all, but I find it is another small detail that really makes a website look polished.

Conclusion

As you can see, we really don’t need much more than the palette we’ve created today. But that doesn’t mean you are limited to these colors! As you’re designing, you might decide it’s appropriate to introduce some more colors to your palette. That’s totally fine! As long as you’re attentive, you can use the steps above to find more colors that work with your scheme. The beauty of this is that the more you do it, the better you’ll become at choosing colors. You’ll get to know what works together and what doesn’t. Sometimes, the method above will yield results that are less than desirable, so feel free to tweak things. Play around and have fun learning color theory, without the theory!
Source: https://www.smashingmagazine.com

Apr 06 2016
Apr 06

User interface, also known simply as UI is one of the most important considerations when designing any product. Graphic designers as well as industrial designers use and implement UI design principles but user interface design is becoming more and more important in the digital world.  

By following user interface design principles, web developers can make their websites or apps easier and more pleasurable to use. Nowadays the internet is flooded with engaging websites and apps – competition is very high so if you want to make the best out of your user interface and create satisfying user experience.

For user interface design companies and web developers good UI design means starting with basic elements such as fonts and colours, and ultimately to every component present on the web page or in the app. Here is a list of UI design principles which will help you along the way to create attractive and most of all effective UI design for your projects.

Following UI Design Principles

The idea behind UI design is simple: it should be centred around the future user. Every UI designer’s number one priority is to understand the intended user and his or her expectations.

That being said, it’s a good idea to begin with an analysis of potential users and their expectation. You can begin with either informal or formal research plus a lot of brainstorming. Defining your goals for the user interface itself is paramount to your project’s success in the long run.

Here is a list of questions you should take into consideration before beginning to work on the user interface design:

  • What does the user want from it?
  • Is your user comfortable with technology?
  • How does the user engage with the user interface?

Once the research part of the task is done, the UI designer can begin building it – afterwards real user testing is needed in order to measure results and make alterations.

UI Design Principles Prioritize Clarity

Very clear and specific features are the backbone of creating good UI design. Humans and users tend to ignore things they don’t understand – this allowed us to prioritize on things we consider important instead of wasting time on things we don’t understand.

When it comes to user interface design, the principles are the same – most users will simply ignore certain elements such as icons which they don’t immediately understand. Features without a clear purpose are also ignored. UI designers and user interface design companies need to focus on what the user wants or what the user needs from a website.

One great example of UI design clarity is Google’s decision to collapse the Gmail menu under a general grid icon. Visually speaking, it looks clean and quite appealing but this small change created many problems for certain users – they couldn’t find the features they needed and some of them didn’t even notice the new icon. When clarity is lost, user experience takes a dive!

UI Design Principles Imply Intuitive Layouts

Users need to be able to find the information they need without looking or thinking too hard. Every UI designer needs to create layouts that tells the user how to use the site’s features and how to navigate through it – by doing this you’re creating a better user experience and it also enables users to focus on getting what they need from the web page or app.

UI design companies need to consider the real life end users when building websites or apps. Sidebars, menus and other navigation tools should be easy to use and clear.

User interface design consistency is also important when building intuitive layouts – all elements and features need to be consistent in terms of use, colour, shape, font, etc. This way, users will be able to use them properly time and time again.

Instant Feedback is Important for UI design

Instant-feedback messages can boost your user experience. These messages are essential to keeping your users informed about their actions or what the website is doing – error messages, loading messages or icons, instant updates are essential to providing your users with feedback. Good UI design includes instant feedback for any of the user’s actions.

UI Design Defaults Should be Productive

A lot of users don’t even bother to change default features or settings on their interfaces. The iPhone default ringtone is a great example of this – the default setting is neutral. Auto-fill forms can save your users plenty of time by filling in information on their behalf.

Guided Actions

Instead of simply leaving users to guess on how they should use a feature why not remove all the guesswork by showing them how to complete certain actions? Good UI design always leads users towards a satisfying and productive experience. Features can be emphasized through size, colour, text or even extra buttons.

UI Design & Basic Design Elements

Many user interface designers think basic design elements can’t be innovative or fresh. This is false – good UI design implies using as many basic design elements as possible – these elements have a huge impact on your user experience. Here is a list of basic design elements which you need to keep in perspective:

Text size – Text weight has a great impact on shaping your user interface. For example, static text may require your users to zoom in, which can lead to a frustrating user experience.

Screen resolution – Good UI design works with varying resolutions. Poor resolution choices can have a negative impact on usability and readability.

Distortion – User interface designers need to avoid any disruption or distortion of visuals as it can impede your user from engaging with the user interface properly.

Contrast – Contrast makes all elements easy to engage and read. UI design should be accessible for users suffering for colour blindness for example. Keep in mind that low-contrast visuals can cause people with minor vision loss to struggle before finally leaving your website.

Conclusions on UI Design Principles

We are all becoming more and more engaged in the online experience so UI design is becoming more important for our daily activities. By following these simple UI design principles, UI designers can make a positive impact on most aspects of our lives.

Mar 05 2016
Mar 05

When it comes to mobile development, it’s much easier to create a brand new responsive website than to upgrade an existing website from unresponsive to responsive. That being said, the task is definitely doable if you follow these mobile development tips:

This is a list of different mobile development methods which you can use to roll out a responsive redesign.

Responsive retrofit

If retrofit works on your current project or website, it’s a great option for quick mobile development. It’s definitely not a magic wand but you can definitely retrofit an existing desktop website to a mobile one in a relatively short period of time – some projects can last under two months while some can last just a few weeks.

 

Parallel beta

You should definitely use a beta and have your users test it out in order to make sure you get the right results. Mobile development companies use this method to get a lot of user feedback and implement different solutions to fix potential problems.

Mobile-only responsive

Similar to the parallel beta method, using an existing m-dot site to experiment and gain user feedback is a great idea. The existing m-dot website can be used as a sandbox for rolling out responsive design in stages. This method was used by BBC and the Guardian to upgrade their websites, so you know you’re in good company.

Conclusions

With the number of mobile users surpassing desktop users, it’s essential for any organisation or company to have a fully functional responsive website to handle this new trend.

Jun 29 2015
Jun 29

drupalgovcon logoWe’re excited for Drupal GovCon hosted in the DC area July 22nd through the 24th! We can’t wait to spend time with the Drupal4Gov community and meet fellow Drupalers from all over! Forum One will be presenting sessions in all four tracks: Site Building, Business and Strategy, Code & DevOps, and Front-end, User Experience and Design! Check out our sessions to learn more about Drupal 8 and other topics!

Here our are sessions at a glance…

Nervous about providing support for a new Drupal site? A comprehensive audit will prepare you to take on Drupal sites that weren’t built by you. Join this session and learn from Forum One’s John Brandenburg as he reviews the audit checklist the our team uses before we take over support work for any Drupal site.

Drupal 8’s getting close to launching – do you feel like you need a crash course in what this means? Join Forum One’s Chaz Chumley as he demystifies Drupal 8 for you and teaches you all that you need to know about the world of developers.

If you’re wondering how to prepare your organization for upgrading your sites to Drupal 8, join WETA’s Jess Snyder, along with Forum One’s Andrew Cohen and Chaz Chumley as they answer questions about the available talent, budgets, goals, and more in regards to Drupal 8.

The building blocks of Drupal have changed and now’s the unique time to rethink how to build themes in Drupal 8. Join Chaz Chumley as he dissects a theme and exposes the best practices that we should all be adopting for Drupal 8.

Drupal 8’s first class REST interface opens up a world of opportunities to build interactive applications. Come learn how to connect a Node application to Drupal to create dynamic updates from Forum One’s William Hurley as he demonstrates the capabilities of both JavaScript and Node.js using Drupal, AngularJS, and Sails.js!

Are you excited to launch your new website, but getting held down by all the steps it takes for your code to make it online? On top of that, each change requires the same long process all over again… what a nail biting experience! Join William Hurley as he demonstrates the power of Jenkins and Capistrano for managing continuous integration and deployment using your git repository.

If you’re a beginner who has found the Views module confusing, come check out this session and learn important features of this popular module from Leanne Duca and Forum One’s Onaje Johnston. They’ll also highlight some additional modules that extend the power of Views.

Have you ever felt that Panels, Panelizer and Panopoly were a bit overwhelming? Well, come to our session from Forum One’s Keenan Holloway. He will go over the best features of each one and how they are invaluable tools. Keenan will also give out a handy cheat sheet to remember it all, so make sure to stop by!

Data visualization is the go to right now! Maps, charts, interactive presentations – what tools do you use to build your visual data story? We feel that D3.js is the best tool, so come listen to Keenan Holloway explain why you should be using D3, how to use D3’s visualization techniques, and more.

Implementing modular design early on in any Drupal project will improve your team’s workflow and efficiency! Attend our session to learn from our very own Daniel Ferro on how to use styleguide/prototyping tools like Pattern Lab to increase collaboration between designers, themers, developers, and your organization on Drupal projects.

Are you hoping to mentor new contributors? Check out this session where Forum One’s Kalpana Goel and Cathy Theys from BlackMesh will talk about how to integrate mentoring into all the layers of an open source project and how to develop mentoring into a habit. They’ll be using the Drupal community as an example!

If you’re a beginner looking to set up an image gallery, attend this session! Leanne Duca and Onaje Johnston will guide you in how to set up a gallery in Drupal 8 and how to overcome any challenges you may encounter!

Attend this session and learn how to design and theme Drupal sites using Atomic Design and the Drupal 8 CSS architecture guidelines from our very own Dan Mouyard! He’ll go over our Gesso theme and our version of Pattern Lab and how they allow us to quickly design and prototype reusable design components, layouts, and pages.

Can’t make it to all of the sessions? Don’t worry, you’ll be able to catch us outside of our scheduled sessions! If you want to connect, stop by our table or check us out on Twitter (@ForumOne). We can’t wait to see you at DrupalGovCon!

Previous Post

Programmatically Restricting Access to Drupal Content

Next Post

Announcing Selectability.js: Style-able, Accessible Select Fields

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web