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.

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 here, 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 
     

Now. 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!

Sep 25 2018
Sep 25

With phone in hand, laptop in bag and earbuds in place, the typical user quickly scans multiple sites. If your site takes too long to load, your visitor is gone. If your site isn’t mobile friendly, you’ve lost precious traffic. That’s why it’s essential to build well organized, mobile ready sites.

But how do you get good results?

  • Understand whom you’re building for
  • Employ the right frameworks
  • Organize your codebase
  • Make your life a lot easier with a CSS preprocessor

Let’s look at each of these points.

Design For Mobile

When you look at usage statistics, the trend is clear. This chart shows how mobile device usage has increased each year. 
 

Mobile device usage graphSource

A vast array of mobile devices accomplish a variety of tasks while running tons of applications. This plethora of device options means that you need to account for a wide assortment of display sizes in the design process.

As a front end developer, it’s vital to consider all possible end users when creating a web experience. Keeping so many display sizes in mind can be a challenge, and responsive design methodologies are useful to tackle that problem.

Frameworks that Work

Bootstrap, Zurb, and Jeet are among the frameworks that developers use to give websites a responsive layout. The concept of responsive web design provides for optimal viewing and interaction across many devices. Media queries are rules that developers write to adapt designs to specific screen widths or height.

Writing these from scratch can be time consuming and repetitive, so frameworks prepackage media queries using common screen size rules. They are worth a try even just as a starting point in a project.

Organizing A Large Code Base

Depending on the size of a web project, just the front end code can be difficult to organize. Creating an organizational standard that all developers on a team should follow can be a challenge. Here at Zivtech, we are moving toward the atomic design methodology pioneered by Brad Frost. Taking cues from chemistry, this design paradigm suggests that developers organize code into 5 categories:

  1. Atoms
  2. Molecules
  3. Organisms
  4. Templates
  5. Pages

Basic HTML tags like inputs, labels, and buttons would be considered atoms. Styling atoms can be done in one or more appropriate files. A search form, for example, is considered a molecule composed of a label atom, input atom, and button atom. The search form is styled around its atomic components, which can be tied in as partials or includes. The search form molecule is placed in the context of the header organism, which also contains the logo atom and the primary navigation molecule.

Now Add CSS Preprocessors

Although atomic design structure is a great start to organizing code, CSS preprocessors such as Sass are useful tools to streamline the development process. One cool feature of Sass is that it allows developers to define variables so that repetitive code can be defined once and reused throughout.

Here’s an example. If a project uses a specific shade of mint blue (#37FDFC), it can be defined in a Sass file as $mint-blue = #37FDFC. When styling, instead of typing the hex code every time, you can simply use $mint-blue. It makes the code easier to read and understand for the team. 

Let’s say the client rebrands and wants that blue changed to a slightly lighter shade (#97FFFF). Instead of manually finding all the areas where $mint-blue is referenced on multiples pages of code, a developer can easily revise the variable to equal the new shade ($mint-blue = #97FFFF; ). This change now automatically reflects everywhere $mint-blue was used.

Another useful feature of Sass is the ability to nest style rules. Traditionally, with plain CSS, a developer would have to repetitively type the parent selector multiple times to target each child component. With Sass, you can confidently nest styles within a parent tag, as shown below. The two examples here are equivalent, but when you use Sass, it’s a kind of shorthand that automates the process.

Traditional CSS

Sass

Although there are a lot of challenges organizing code and designing for a wide variety of screen sizes, keep in mind that there are excellent tools available to automate the development process, gracefully solve all your front end problems and keep your site traffic healthy.

This post was originally published on July 1, 2016 and has been updated for accuracy.

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

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

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

Jun 02 2015
Jun 02

In April 2015, NASA unveiled a brand new look and user experience for NASA.gov. This release revealed a site modernized to 1) work across all devices and screen sizes (responsive web design), 2) eliminate visual clutter, and 3) highlight the continuous flow of news updates, images, and videos.

With its latest site version, NASA—already an established leader in the digital space—has reached even higher heights by being one of the first federal sites to use a “headless” Drupal approach. Though this model was used when the site was initially migrated to Drupal in 2013, this most recent deployment rounded out the endeavor by using the Services module to provide a REST interface, and ember.js for the client-side, front-end framework.

Implementing a “headless” Drupal approach prepares NASA for the future of content management systems (CMS) by:

  1. Leveraging the strength and flexibility of Drupal’s back-end to easily architect content models and ingest content from other sources. As examples:

  • Our team created the concept of an “ubernode”, a content type which homogenizes fields across historically varied content types (e.g., features, images, press releases, etc.). Implementing an “ubernode” enables easy integration of content in web services feeds, allowing developers to seamlessly pull multiple content types into a single, “latest news” feed. This approach also provides a foundation for the agency to truly embrace the “Create Once, Publish Everywhere” philosophy of content development and syndication to multiple channels, including mobile applications, GovDelivery, iTunes, and other third party applications.

  • Additionally, the team harnessed Drupal’s power to integrate with other content stores and applications, successfully ingesting content from blogs.nasa.gov, svs.gsfc.nasa.gov, earthobservatory.nasa.gov, www.spc.noaa.gov, etc., and aggregating the sourced content for publication.

  1. Optimizing the front-end by building with a client-side, front-end framework, as opposed to a theme. For this task, our team chose ember.js, distinguished by both its maturity as a framework and its emphasis of convention over configuration. Ember embraces model-view-controller (MVC), and also excels at performance by batching updates to the document object model (DOM) and bindings.

In another stride toward maximizing “Headless” Drupal’s massive potential, we configured the site so that JSON feed records are published to an Amazon S3 bucket as an origin for a content delivery network (CDN), ultimately allowing for a high-security, high-performance, and highly available site.

Below is an example of how the technology stack which we implemented works:

Using ember.js, the NASA.gov home page requests a list of nodes of the latest content to display. Drupal provides this list as a JSON feed of nodes:

Ember then retrieves specific content for each node. Again, Drupal provides this content as a JSON response stored on Amazon S3:

Finally, Ember distributes these results into the individual items for the home page:

The result? A NASA.gov architected for the future. It is worth noting that upgrading to Drupal 8 can be done without reconfiguring the ember front-end. Further, migrating to another front-end framework (such as Angular or Backbone) does not require modification of the Drupal CMS.

Nov 19 2014
Nov 19

As product designers and experience strategists, we research how people use systems and design products that tap into users’ natural behaviors. We want people to instinctively know how our product works.

Years of research into the human mind tells us that our brains love patterns, the repeated way in which something happens or is done. Our subconscious mind uses what we’ve learned from patterns – like turning a knob will open a door – to instinctively make decisions about what we do throughout our day. This is why we can walk or breathe without thinking about it – we spend most of our time running on autopilot.

We have an understanding of how people make decisions, but we forget to apply this knowledge when communicating our product vision to stakeholders.

There are Drawbacks to Designing in the Abstract

Experience design deliverables, or artifacts, are abstract. We too often produce artifacts, intended to build a shared understanding of a product vision, that are hard to understand. Low-fidelity wireframes and complex flow diagrams require stakeholders to think hard about what we are trying to communicate. They mentally fill in the gaps where we lack details. We consistently break Steve Krug’s number one rule: “Don’t make me think!”

Imagine how these abstract artifacts skew conversations about a product:

We show a stakeholder some wireframes and talk them through the features. Once they see them they begin to imagine the ways features will look and act based on similar products they have used.

While perfectly natural, this behavior is problematic – what we envision may be nothing like products this stakeholder has previously used. These assumptions your stakeholder makes will lead to you and your stakeholders having different expectations during product development.

You need to make artifacts as real as possible in order to elicit the most unbiased, unimpeachable feedback from users during research. You do not need to build a fully functioning product to validate your idea.You do need to eliminate or reduce the guesswork needed to understand how your product will work.

Make Your Product Vision Real

Prototyping is a great way to eliminate ambiguity so that you get the best results from user research. A prototype is a preliminary model of a product used to show a concept or validate an idea. A prototype should only contain the minimum amount of content, design and functionality needed to demonstrate how the end-product will function.

Context is key to determining fidelity of a prototype. If you are conducting user testing with a tech-savvy group of stakeholders, clickable wireframes may suffice. If you are introducing a new concept to a set of clients, then you may need a higher-fidelity, interactive web page. Your prototype should only contain the fidelity needed to have a meaningful conversation with your users about your product.

Build The Right Prototype For You

There are many different approaches to building prototypes. You can link wireframes together to show user flow with a system like inVision, or build interactive features using an open source CMS like Drupal.

When creating prototypes, make sure to include the following:

  1. The main actions that a user can take and the reactions they will receive from interactive elements.

  2. The key messages you want to communicate to users at different stages of their interaction.

  3. A programmatic way to track user behavior while they use the prototype.

Get Better Results from Your Projects

Some of the many benefits of prototyping are:

  • It produces more accurate results from user testing, allowing you to better determine what works and what doesn’t.

  • It gives you more opportunity to focus on interaction design by forcing you to have conversations about interactive elements during user research rather than development.

  • Prototypes bring less-apparent usability issues to light earlier in the development process.

  • You have a potential starting point to work from when beginning development, minimizing the amount of work that needs to be done in the long run.

John Whalen said “UX does not happen on a screen. It happens here. In the mind.” Keep that in mind (no pun intended) as you seek to build a shared understanding of, and validate, your product ideas. The more real you make the experience of interacting with your product early in the design process, the more accurate a feedback you will get from your users. For more thoughts on prototyping, check out Frederic Mitchell’s “Static Prototyping and Keeping Drupal Simple (KDS)” and “The Devil’s in The Details” by Sharon Smith!

Oct 20 2014
Oct 20

Recently 10 members of the Drupal development team at Capgemini went to Drupalcon Amsterdam. Having been to two Drupalcons before, I more or less knew what to expect, but something I hadn’t previously given much thought to was how big an event it is. Compared to most other web conferences, it’s a beast. For me personally, I wonder if it’s getting too big and too impersonal, and I think that I’ll be more interested in going to smaller events.

Some of the more interesting sessions for me were the BoFs - in particular a discussion of open source training material and apprenticeships provided a lot of food for thought, and hopefully we can get involved at some level. Capgemini already does a lot of work getting graduates and apprentices into our engineering practice, and with such a big Drupal team, I hope we can benefit from and contribute to the Open Drupal initiative in 2015.

Whenever I go to an event, I come back with a to-do list, and this was no exception. I’ll definitely be digging further into CasperJS following Chris Ruppel’s session on Automated Frontend Testing. I was also very interested to hear about the way that Lullabot spin up test environments for pull requests - it will be good to investigate the feasibility of incorporating this into our workflow.

The other talk that stood out for me was John Albin Wilkins on Styleguide-Driven Development. For a long time, I’ve had a bee in my bonnet about the value of component libraries over Photoshop comps, and it was good to be reminded that I’m not alone. In an interesting session, John outlined an approach to integrating component-based design and automated style guides to agile development projects.

It’s been said many times before, but it’s worth remembering that all too often, people are still thinking in terms of pages, rather than systems.

In the context of the work that we do, this is even more important. We’re a large development team, building CMS-driven sites for large corporate clients, where the design is done by a team working for another company. We’ve made some inroads into building a more collaborative process, but it’s still too easy to end up with the designers throwing things over the wall to the developers. Very often the designer isn’t closely involved during the build phase, and design tweaks are agreed between the client and the developer without the opportunity to go back to get the designer’s opinion.

This is the whole point of living style guides - component libraries that stay in sync with the code as it evolves. As Shay Howe has discussed, component libraries help everyone on the project.

Designers are reminded of the visual language of the project, and it’s easier for them to see when they’re about to reinvent the wheel.

Style guides help developers by defining and documenting standards, and make it easier to dig in and find the way you solved some problem six months ago.

The projects we work on are large and complex, with a long lifecycle, and as developers we need to value maintainability of the front end code. Part of John’s approach to this was his class-naming convention. Having seen Jonathan Snook present on SMACSS I’d thought it was interesting, but to a certain extent it felt like a fancy name for something that was basically common sense. John’s presentation brought the concept to life well, and persuaded me that there’s more to it than that, with an impressive display of flower power.

The other interesting aspect was splitting up SASS files into components, and using KSS to create the style guide - this is something I definitely intend to do on my next project.

Modularity makes sense - it’s how the back-end is going, it’s how Javascript is going, so why shouldn’t design and CSS go the same way?

UPDATED 3rd December 2014: Unfortunately we got Chris Ruppel’s name wrong in the original version of this post, calling him “Dave Rupl”. Sorry Chris.

Dec 01 2013
Dec 01

I’ve been leading Drupal web projects for some years now and yet have never heard a frontend developer say: “This design is meant for Drupal. It is so easy to implement it, the designer totally gets how Drupal works. I’m totally having coffee with this guy later today, we’re pals.” Instead, it’s often about how the designers only goal in life must be to think of ways how to drive the devs into insanity and ultimate extinction. What seems to be the problem?

Where to start from, would the themer say, putting down his half-smoked pipe and jQuery cheatsheet. Lets start from the beginning. The moment when you see Dropbox icon in update mode, and with a shaky cursor, open the design folder for the very first time. What will it be, Photoshop, Fireworks, or God save us all, an Illustrator file? Or is it just a bunch of .jpg’s with no means to separate backgrounds from text and shadows?

Whatever it is, the themer is usually left to discover his own way around the new landscape. Because the designer is off to a vacation, or too busy with his next project, or generally not involved, because his job is done, right? And it’s easy to understand that he is fed up with it. Because, yet again, the client puts him into a position where he not only has to make it look pretty, but also work out the UX process and half of the functionality while at it.

And grid. The grid is those cyan lines that help you align stuff in Photoshop. And Omega is a watch company. Keep the number of columns consistent through different responsive states, you say? Your stupid math has no place in my creative process, I say!

Finally you get throught the main laoyouts and move on to theme more specific functionality. The comment thread. The pager. The inputs. Is there design for those? No. And when you ask for it, the designer frustratedly spends his Saturday evening catching up and creates a pixel perfect design, that has no common ground with Drupal’s default layouts whatsoever, requiring thousands of characters of JS to make it work.

Lets breathe in

Its fun to rant, but all jokes aside, there’s some pretty simple stuff that would save a ton of time and money for everyone:

  • make nice layered source files, where all elements can be extracted separately. Please don’t send .jpg’s.
  • a Drupal project should be a team effort from the start. There is no independent graphic design phase. It does not make sense that the web designer is also the one who single handedly draws up the layouts and UX.
  • use consistent grid when doing responsive layouts.
  • when drawing up standard Drupal elements, look at the examples, get a basic knowledge of how the code works. Features are cheap, details expensive.
Sep 11 2013
Sep 11

With our workflow in hand, let's shift our perspective to the big picture.

What does this mean for the other deliverables

What prototyping may mean for your other deliverables in the design phase is that they may need updating after being "finalized." When sign off needs to be obtained on a deliverable make it clear that what the client is saying is "Yes, I agree we are going in the right direction and I understand the vision proposed thus far." It may seem rudimentary, but take the time review this with them.

Drupal

We've gotten this far with little mention of Drupal. So, what does this have to do with Drupal? Drupal is very well-suited to build extremely robust and complex websites with a lot of different functionality and behaviors. In fact, this is Drupal’s superpower, but also its curse. It is much easier to add functionality than interactivity. Ensuring that your client is crystal clear on exactly what and how the application will be is mission-critical. So, while the process can save time on your end, it will also increase understanding between you and your project team.

Certain Drupal themes, like Zen, and Omega, while not based on Zurb's Foundation, they attempt to responsify sites out-of-the-box. Instead of laboring over every last minutia for each breakpoint, polishing up what these base themes offer from the get-go is often the most viable path forward for organizations who are on a shoestring budget.

Alternatively, another bridging tool here is to have or develop a base theme whose markup matches that of the prototyping tool. The the process is further leaned up in re-use of prototype code in production code.

Tools

Like I mentioned before, the tool we use at OpenSourcery, we developed internally. It's called Hadron, and is based on the Ruby application Serve, and Zurb's Foundation framework. The long-term goal, and the reason for the name, was to ram the Foundation framework and AdaptiveTheme's WCAG-compliant markup together at high velocity and see what comes out. It is available to be forked and cloned from Jonathan Hedstrom's repository on github.

Micah Godbolt at Lullabot has developed his own prototyping tool, Tractor, based on AngularJS and Grunt.

Wirefy is another tool, that I haven't tried personally, but is free to grab and fork on github. It uses HTML, SASS, Javascript and fonticons. It is style agnostic and comes with many basic web elements (menus, forms, slideshow, etc).

What's next?

As touched on earlier ever so briefly, it would be awesome to remove the need to learn how to code in order to create prototypes. This would allow not only UI designers and architects to focus on the design itself, and less on the code they're developing creating hurdles for their vision, but it also would lend itself to clients being able to collaborate in a visual format. What we have with the existing prototyping solutions is the ability to communicate to the client in a visual capacity, doing rather than saying, but they are still chained to providing their feedback in a static format. I hope that someday there will be a low barrier to entry tool that could permit real-time or close-to-real-time collaboration between client, stakeholders, development team, and architects to create the best solution for the project.

Tangentially related is the development of style tiles in lieu of comps. We should not be mocking up layouts for every breakpoint range, but rather taking an indication of style (fonts, colors, treatments, block styles, etc) and letting them flow naturally into the layout for the device. No more pixel pushing on every possible layout means huge time savings and a more natural feel.

Again, as mentioned earlier, having graphic designers implement their vision in code. This is easier said than done. Actually, it's less about them implementing it in code, but rather having their vision be translated into CSS and SASS, so that nothing gets lost in translation when being handed off for theming. There is some merit to having to have the graphic designers think through their vision in terms of code before going buck-wild. As we all well know, anything is possible, but possible does not mean cheap.

Lastly, prototyping directly in Drupal. I would love to be able to throw a minimal theme on a Drupal instance and start prototyping. It would allow designers to show the inherent capabilities of Drupal out-of-the-box. It also starts to blur the line between site building and design. Time will only tell if this will become a reality, and then we'll have other issues on our hands!

Sep 10 2013
Sep 10

Workflow

The prototype fits best in an agile development processes. The prototype in agile becomes a parallel tool to the live website. It’s not a development or staging instance, it’s before both of those. It’s its own instance.

So, that being said, where does the prototype fit in the watergile or waterfall application design process? At OpenSourcery, true agile is often not a possibility for our projects. In these cases, our stages of application design are as follows:

  1. Development of functional requirements list (Optional for projects that come prepared with these.)
  2. Prioritization of functional requirements.
  3. User stories (which describe our Behat tests, Behat in itself merits its own series of blog posts-- I highly recommend watching Ryan Weaver's session from DrupalCon Portland.)
  4. Sitemap (can be developed concurrently with User Stories).
  5. Informal wireframe exercises (whiteboarding, on paper, other tools) with client participation (in meeting or otherwise).
  6. Prototype development and iterations based on client feedback.
  7. Development road map initiated by designer, with input from, revisions by and eventually ownership assumed by the principal developers on the project. This document describes the content types, taxonomies, modules, views, entities, and any other structures for the project. It is not expected that the architect can fill this out fully without the aid of a developer, but should be able to write the large majority of it. The development roadmap is intended to be a living document that can be referred to in the event of a handoff between developers. While this is made available to the client or stakeholder, it usually holds little to no value to them, so it is not considered a deliverable.

Because constructing a prototype takes a bit of extra time up front, it's best to reserve this for the one of the last deliverables of the puzzle, when prior design milestones and details have been ironed out, such as the site map, user stories and functional requirements prioritization. Sometimes, clients may grow impatient with this workflow, but it's important to emphasize that saving the prototype for last will decrease the number of iterations necessary to get it just right, and that it is practiced this way to better optimize their budget.

What’s more ideal, if you’re organization is able to fund this sort of up-front investment, complete prototypes prior to development scoping and estimation. This way, when a client gets particularly excited about feature X, you’ll be able to point out that it costs Y number of dollars. In this way, prototyping becomes a tool for up-selling and negotiating trade-offs. It also brings the “Chinese Menu” approach to web development.

Also while we're on the topic of budget again, I'll reiterate it another time-- partials, partials, partials. Use them!

I personally start the informal wireframe process a little bit earlier than the informal wireframe exercise with the client, so as to come prepared with ideas to float in front of them, though this can sometimes be undesirable.

In the next post of the series, we'll be talking about what all these changes mean for other project deliverables, for Drupal, and for the future.

Sep 05 2013
Sep 05

While there are many positives to the adoption of the prototype, it isn't all a cakewalk. There are several complications that can arise as a part of adopting prototypes into the regular project process.

Setting Expectations

One "drawback" that is commonly brought up in reference to prototyping as a part of the design process is the struggle to explain to the client how the prototype constructed is not the end product they receive. This confusion is even more likely to occur if a graphic designer comps directly on top of the prototype in CSS or SASS. If a client claims that instead of having their CMS built for content editing ease among other benefits, they would rather just take the prototype code and maintain their website as such, take a moment demonstrate to them the difference. Show them how content is edited in the prototype. Then, spin up a Drupal instance, whether that's locally or on a service like simplytest.me. Show them the content editing experience through Drupal. Explain to them that Drupal protects them from themselves, and minimizes the risk of accidental errors, like deleting a </div> tag that throws off the markup for the entire site. I'd even recommend doing this before the prototyping process begins, so that they understand exactly what it is the designer does.

Explain to them what Drupal will allow them in the now and in future-- upgrades, easier content management, better analytics, and protection.

How to convey what the prototype should be assessed for

Explaining this process doesn't differ too much from explaining what to look for in a wireframe. The biggest piece that is new and relevant to a prototype that isn't captured in a static mock up, is to have the stakeholders click through the prototype, thoroughly, documenting when their expectations differed from what the prototype provided, and what the differences were. The process is much like writing up a bug report.

Additionally, as with wireframes, explain that content is not the focus in a prototype. Because the prototype seems more "real" than a static mock up, it's evermore important to emphasize that the three most recent news items may not actually be their three most recent news items, though they should be real content, if at all possible.

Issues with prototyping for creative purposes

One large drawback with prototyping is that the tools used, the skills a designer has, or the mindset they are in could limit his or her ability to create the experience they’d like to portray quickly and easily. With a drawn wireframe, it’s easy to can scrap and start over. It’s also easy to draw things that have never been coded before. Designers aren't limited by their coding ability or the available libraries as to what they can produce. Additionally, designers can draw things that are nearly impossible to code up in a reasonable amount of time (how many layers and smart objects are used in that block treatment?). The rise of the prototype does not need to (nor should it) mean the extinction of the static wireframe. Rather, the static wireframe should be de-emphasized and used as a lightweight, disposable tool prior to the code-heavy creation of the prototype.

Start with lo-fi mockups

This may seem contradictory to what you’ve been reading thus far, but even before the first line of code for the prototype is committed, take out a pen and paper or a whiteboard and dry erase marker. Especially for cutting edge situations where a project may be embarking on a path never traveled, start with informal paper or whiteboard wireframes. Collaborate with the client in person. Identify early on where in the interface may take more time to create in code than had been budgeted. Show informal mockups to the developers, (a step that should be happening in any thorough design process), and see if they have any ideas on how an idea could implemented that in simple code. See if they notice any red flags about how they will implement the solution in Drupal.

Maybe even go so far as to using a tool that your clients are familiar with, like PowerPoint or Keynote, if that’s what it takes to create a collaborative environment.

However, make sure to avoid rabbit-holing on the paper or whiteboard wireframes. After all, they are informal and at a certain point your team will hit diminishing returns, in particular due to the fact that the informal wireframes do not result in an official deliverable for the client. Sure, they can hold on to the coffee-stained napkin from your meeting, but the prototype will be the authoritative document used going forward.

In the next post, we'll talk about exactly where the prototype fits into the project workflow.

Sep 05 2013
Sep 05

With our definitions in hand, let's navigate the ways in which the adoption of prototyping positively impacts web development projects.

Communication

This ability to describe interactive functionality visually, and with limited words, allows us to better communicate with our stakeholders. If your team is comprised with folks of a variety of different backgrounds and vocabularies (which is the case more often than not), visual definitions speak much louder than written definitions. Instead of using words whose definitions may be universally agreed upon (how many different meanings does the word "template" have?), we now have the capability to show these definitions to the stakeholders directly. They can see the definition for themselves. They can interact with the functionality and provide feedback. Because stakeholders have the ability to click and get a response, they will be able to tell you where the discrepancies are cropping up between their expectations and reality of the design. With static wireframes, there is no sure-fire way (aside from overly complicated and time-consuming annotations that likely won’t be read or comprehended) to ensure that you and your stakeholders are on the same page.

Additionally, if access to content is given in the early stages of application design, that content can be plopped into the prototype to show the stakeholders what it will (more or less) look like in the envisioned end-product. This will suss out any issues up front, before the solution has been built and 80% of the budget is gone.

The content-first approach also adds a nice touch for making the application design process more personal for each project. Nothing screams "I'm not thinking about your needs specifically" like "dolor sit amet." Lorem ipsum’s main merit is that it focuses attention away from content. If done intentionally, Lorem Ipsum is being used correctly. This makes good sense in certain contexts (e.g. wordpress style templates). If done unintentionally, it means that either the designer doesn’t know what is realistic content (which means he/she doesn’t understand the project) or the designer is lazy.

Earlier User Testing = More User Testing = Better Product

By having the clients and stakeholders review the prototype, they’re actually beginning the process of user testing, and they’re beginning it much earlier than they would otherwise. So, prototyping rolls in an extra layer of user testing, which means more user testing, which in turn leads to a better product.

Prototyping isn't only beneficial for stakeholders, but also for the development team. Engaging with the prototype will allow them to identify early on where they need more information, rather than forcing them to surmise what behaviors, functionality, and basic layouts will be required. What will happen the user clicks that link? Did the UI designer intentionally not wire that page because it is supposed to echo an existing wireframe? Does that news page wire double as a basic page wire? All these questions can and will be answered in prototyping.

If you work with a graphic designer who is comfortable creating comps in code, the gains will be even greater. Whole or partial chunks of CSS and SASS can be reused. How many times have you reviewed PSD comps wondering "What were they thinking?". Entire thought processes can be discerned when coupled with the use of a catchall or a "kitchen sink" comp, which is a sort of frankenstein comp made up of all possible HTML elements that could be used. Horizontal rules, block quotes, you name it. With the kitchen sink, the need to return to the drawing board, or the need to wait on another mockup from the designer before implementing, these needs will be noticeably diminished.

Time is on Your Side: Partials, Documentation, and Coding

Partials are reusable snippets of code that can be repurposed across layouts. The concept of a partial is somewhat similar the concept of blocks in Drupal. You can create a partial for the social media sharing buttons, a partial for the menu, the partial can be placed in one place on one layout and in another place in another layout. It's extremely powerful. In my Hadron repository, I have a partial for just about everything I need to use regularly: Quicklinks, Main Navigation, Slideshow, Social Media buttons, Breadcrumbs… the list goes on. On the less technically-complex projects, all I have to do on is update the content in any partials to be relevant, and voilà, my Hadron instance is client-specific. Partials are your friend. Use them!

On a non code-level, prototyping means as an architect or designer, you will spend less time making notes or extra mockups to describe how your solution should work, especially in regard to mobile devices. There are many frameworks that automatically adapt content for mobile layouts (like Zurb's Foundation), which keeps you as the designer from needing to create and recreate static mockups for each and every possible layout. There will no longer be a need to redraw each mockup for phone landscape and portrait, mini tablet landscape and portrait, tablet landscape and portrait, laptop, desktop, and God only knows what else will crop up in the years to come. Creating static mockups for each one of these, or even just some of these layouts is a tremendous time suck. On top of the time loss, it also can create technical roadblocks if not reviewed by an extremely discerning and scrutinizing pair of eyes in advance of implementation.

As noted before in our section on communication, if comps are completed on top of the prototype, whole or partial chunks CSS or SASS can be reused, saving time for developers in the actual coding of the site, which as we all well know, preserves the client's budget in the long run. Enough said.

Keeping an Eye on Scope: A Project Manager's Dream

If designers (myself included!) are dreaming up things in the visual language of code, impossible and overly lavish design ideas can be averted when necessary. If the designer is forced to put their ideas into code, they will be confronted with the complexity of their ideas prior to getting client signoff.

Additionally, better communication on the features being discussed, will naturally lead to a more tightly controlled scope.

Validation

Introducing the prototype early in the process demonstrates the designer’s technical know-how from the get-go. Now and then architects or designers will come across a client who marginalizes the work being done to create a wireframe, particularly the static wireframe-- "You're just moving boxes, lines and latin around on a sheet of paper… I'm paying you how much per hour for this? I could have just made this in PowerPoint." Nowadays, it’s safe to assume everyone knows how to operate some kind of program that allows them to draw and move boxes and arrows, be it MS Paint, GIMP or Illustrator. Despite the aforementioned sentiments stemming out of a misunderstanding in communication around experience, roles and responsibilities; I understand how a stakeholder or client could feel like they could easily produce the deliverables themselves. In many of these cases, a prototype will demonstrate the designer’s skill and value to the stakeholder, as the skill set it takes to construct an in-browser prototype is unlikely to be a skill set the stakeholder has. (And if they do have that skill, hooray! The stakeholder has a better understanding of what the designer is doing and communication is off to a great start!)

If the designer is feeling lucky, he or she can make code edits on the fly, in front of the stakeholder (although, keep them small and to a minimum, since nobody wants to spend even 5 minutes of a meeting watching someone else code). This will show them how easy it is to make changes, as well as demonstrate his or her technical skills. However, I don’t recommend this. When a code edit crashes and burns in front of stakeholders, it is painful. Really, painful. Alternatively, changes to the prototype can be performed on a whiteboard in meeting, and sent over the revised prototype within 24 hours. Still impressive, and much less painful.

In the next post of this series, we'll examine the complications and potential drawbacks of prototyping.

Aug 30 2013
Aug 30

Instead of picking up right where we left off, for clarity's sake, let's review some definitions of the terms I’ll be referring to throughout this series.

Mockup

A mockup is an interchangeable word that refers to any visual depiction of the application. Graphic design comps as well as wireframes can be considered mockups.

Wireframe

A wireframe is a visual depiction of the functionality and basic layout of a software application. My favorite analogy, while it isn't perfect, is the blueprint of a house. Much like a blueprint, a wireframe depicts the the structure of the application and describes its functionality, but it is not used to describe the look and feel of the software application. While in a blueprint it matters where the sinks are located within your house, with wireframes, even layout to a certain extent is not as a part of the wireframe deliverable.

Static Wireframe

A static wireframe is a document created on paper or through the use of tools like Photoshop, or Omnigraffle, that visually describes the functionality and layout of a software application. These documents are static, meaning that there is no interactivity or behavior feedback when a user clicks, touches or otherwise interacts with the document. It is looked at and consumed, but not engaged with. Wireframes are often accompanied by a written document describing the implied behavior in the document. Graphic design comps are also static in most cases.

In-browser Wireframe

An in-browser wireframe is exactly as you would think. A wireframe that is rendered in the browser (Chrome, Safari, Firefox, etc) using HTML or other tools that can be opened by a browser. Why is this desirable? This way, the wireframe lives within the context in which the end-product will actually be used. It's similar to listening to a demo tape of your music on the sound systems your audience uses to make sure it's still a quality experience and still intuitive.

To be clear, images or anything else not “read” by the browser that is opened in a browser, don’t count as an in browser wireframe. To render a static wireframe in-browser misses the point entirely of what the browser is for-- interactivity. So, by this definition, static wireframes are not and should not be in-browser.

Prototype

A prototype takes the concept of a static mock up one step further, by offering the interactivity that is so noticeably missing in the static deliverable. A prototype is a fragile-state piece of code. It is not to be used by any client, and in most cases cannot be tampered with by clients who have no code experience. By default, a prototype is not necessarily in-browser, however, as the most basic and fundamental web tools (HTML, CSS, Javascript) are rendered in the browser naturally, prototypes are generally created for in-browser review.

Some would say that prototyping is orthogonal to wireframing. Especially with Drupal’s modular approach, it is easy to add functionality. Some also separate the two by stating prototype explores engineering, and wireframes/traditional mockups explore presentation and experience.

Hadron

To give you a visual to aid for the spoken definition for prototype, check out the brief click-through demo of Hadron, our prototyping tool at OpenSourcery. You can clone and fork it off of github. Hadron is based on Serve, which is a small Rack-based web server, and Foundation by Zurb, which is mixed in to have some default CSS to pretty up the wireframe a bit and offer responsive layouts out-of-the-box.

In the video to the left, you’ll notice the prototype is much like an actual website. It's interactive, much more so than your typical sheet-linking wireframes. In this instance, we have a basic page, a login page, a blog page, a blog detail page and a homepage. Right here, you've got a super simple brochureware site wired out, and coupled with version control, can be used time and time again at the drop of a hat.

Hadron and other prototyping engines are a huge departure from what are traditionally thought of as wireframes. However, they still function as wireframes-- the prototype depicts functionality (and actually more comprehensive functionality than its static sister), and basic layout. The main difference is that instead of needing to describe interaction and user experience using annotations or any words at all, we can now describe it visually.

In the next post, we’ll examine how this difference impacts a development project.

Aug 30 2013
Aug 30

In July, I made the trek to my homeland of Minnesota to attend Twin Cities Drupal Camp, and boy did it feel great to be back with such great people, and above all, such great Drupalistas. I gave a session in the first slot of the camp called “Prototyping is the future: The decline of the static mock up, the rise of in-browser wireframes.” For those of who couldn’t make it, or those of who want a summary posted up, you’re in luck-- that’s just what this blog series is for.

Why you should care about prototyping

The adoption of prototyping doesn’t just affect UI/UX designers. Making in-browser wireframing a part of the project process changes the development process, sales and marketing communication, scope wrangling, the envisionment of graphic design, and, perhaps most importantly, communication with stakeholders and with the internal team. In essence, it impacts every element of a development project. What’s more, it changes all of these things for the better.

For the architects and designers who have little to no experience coding or using the command line, the gains that come with adopting prototyping far outweigh the costs of picking up a small tidbit of coding. All the same, I hope that one day prototyping won't require a knowledge of code to create, and, when that day comes, that there will be little or no barrier to entry in order to create living breathing prototypes.

Why prototyping matters now more than ever

There are several reasons.

  1. From a project management perspective, prototyping is a win-win-win on the all important triangle of time, scope and budget. Prototyping saves time, which in turn saves budget, and it better defines scope and features which, coupled with the time saved, allows you to offer your client more features (a.k.a. broader scope) for the same budget. Thus, prototyping shrinks the distance between the vertices of the PM triangle, but the possibility for a highly successful project increases with the adoption of prototyping as a direct result of the shrinkage. Given the increased potential for a highly successful project or end-product via prototyping, waiting to adopt it will be and is detrimental to your success as an organization, and your relationships with your stakeholders.

  2. Communication is improved all around. We'll touch on this at length, but in short, better communication should never be postponed, as it will bring everyone on to the same page faster and with less frustration, which means happier people and better products!

  3. From a scalability perspective, we now live in a world with thousands of different types of mobile devices, and the number is only growing. There is also a wider variety of users than ever before. The static mockup is no longer sustainable, as the way we use the web is not a one-size fits all anymore-- the desktop computer is becoming an elusive creature. This is the crux of content-first design and post-web digital content strategy. Presentation is becoming the least important aspect of design.

  4. Ensure testing happens early and often, as it will be necessary to ensure user satisfaction for the lowest cost and least amount of time spent. You'll see that by taking on prototyping you'll be able to get realistic feedback earlier, and be able to make better decisions earlier in the design process. In addition to this we get production-ready layout definitions that don't need to be re-implemented in code, since they were designed in code in the first place.

In the next post, we'll be analyzing important definitions to better understand where prototyping fits in the design process.

a. A diagram that portrays the shrinking of distance between vertices on the project management triangle. Projects that prototype are likely to have a higher percentage of highly successful projects.

Diagram of concentric project management triangles overlayed by a circle

Jul 22 2013
Jul 22
image/jpeg iconnetwork.jpg

As Drupal software is increasingly used by more people around the world to power a varied array of projects - from simple online publishing tools to complex web applications, defining the sense of community drupal.org facilitates becomes more relevant.  

At base, the term ‘community’ can be applied to the meta group of people and organizations using Drupal around the world purely by the fact that they share this use in common.  Taking the definition a step further, a more ideal ‘community’ would also imply a sense of fellowship between members which could result in common goals.

As the Drupal community grows, a greater importance must be placed on encouraging a strong sense of community whereby drupal.org can serve as a platform for achieving common goals of all members.  This brief post attempts to highlight some key areas of opportunity for encouraging such engagement.

 

Better leveraging the power of our network

Problem - Almost all professional firms and contractors using Drupal software are registered members of drupal.org yet the ‘Marketplace’ listing at https://drupal.org/drupal-services is limited and biased.

Suggestions:
To better represent the wealth of professional service vendors working with Drupal, Marketplace listings need to become better integrated with member profiles; when registering at drupal.org and/or filling in a profile, members should be prompted to fill out a professional services description, which auto-lists in the Marketplace and collapses the anemic member directory at https://drupal.org/profile into a better functioning Marketplace/community listing (perhaps making commercial vendors a filter of the larger community list.)

There should be no distinction between ‘Featured’ and non-featured providers in the Marketplace; this confuses anyone coming to drupal.org looking to procure a vendor - instead, to establish vendor credibility we can offer tools such as ratings, testimonials/endorsements (as used on linkedin, for example) by previous customers to leave feedback on each vendor, and represent that information on their Marketplace listing.

Given that we work in a global context, and most Drupal professionals take on international client work, it seems redundant to only offer ‘Browse by country’ as a filter in the current Marketplace.  Instead, filters would be more relevant if they related to skill-sets/services each vendor offer.

Problem - Lost opportunities for collaborative work.

Suggestions:
Based on how members tag their profile/marketplace-listing (listed services etc...), drupal.org should recommend other members to them; complimentary skill-sets need to be made obvious to members to encourage collaborative approaches to commercially working with Drupal.

Drupal vendors working together should be able to express their relationship publicly. Like the ‘Connections’ functionality on linkedin, vendors could ask each other to approve a simple flag (ideally with an annotation to explain how they work together) to display on each of their profiles.

Problem - Job Listings are too static.

Suggestions:
Though the main drupal.org job post/listing interface (https://groups.drupal.org/jobs) is hosted on drupal.org it is not integrated with marketplace functionality - so posters aren’t automatically recommended vendors (through their service offering etc...) and vendors are not notified about the availability of postings unless they have been targeted to groups a member may belong to.

Tightening up the recommendation and notification cycle around procurement would encourage communication between posters and vendors and better humanize the procurement process.

As well, the current interface uses reverse-chronological listing; which buries older posts, even though they may not be filled.  Instead, it would be worth considering alternate types of sorts which visually group listings by relevance to the person looking at them.  Additional information at-a-glance should be offered through hover-tips to relate a summary of the position to the vendor looking through listings (often job descriptions are almost synonymous; who is looking for what is more important than the title they want to call the position which is available.)

Problem - Difficult to price procurement of Drupal vendors.

Suggestions:
Without standards for pricing varying tasks and quality of work, it will always take longer for procurement to sort through job listing responses etc... Vendors should easily be able to post case-studies formatted within set guidelines (to maintain congruency) with optional pricing; the case-studies should be available when viewing a vendor profile (individually and possibly through a simplified interface when looking at the marketplace.)

To allow customers of vendors to offer insightful feedback on the value of the service they experienced, a rating criteria should be offered to them so that the accuracy of pricing is maintained.  For example, if vendor X posts case study Y with a guideline pricing/budget of $100 and their client, Mister Z, rates the value of X’s service as 80%, it is obvious to the case study reader that the project may have been better priced at $80.  As a large data set is auto-generated through submitted case studies and customer feedback, pricing recommendations can be automated as messages sent by drupal.org to vendors to suggest augmenting their price to better service customers (we could possibly have standards emerge as the aggregate pricing based on service per case study across the whole community.)

A simple pricing guideline can also help procurement; explaining how the community chooses to charge for their services.  This could be tied to a set of standard methods which each vendor flags as their preferred pricing format.  For example, ‘Hourly rate’ vs ‘Monthly retainer’ vs. ‘All-inclusive per-project’ etc...

 

Contextual Communication

Problem - Issue queues are support silos and IRC is abstract.

Suggestions:
Currently live communication online between members of the Drupal community happens on Internet Relay Chat - in a myriad of channels (listed at https://drupal.org/irc) per specific topic of interest (e.g. accessibility vs commerce etc...)  IRC is a great way for people to chat with each other but requires a separate client application; which non-technical community members may not want to install; further, newer Internet users may not be familiar with command prompt conventions of IRC and thus feel inhibited from communicating with the rest of the community using IRC.  Asides from the learning curve of using IRC, it is further restrictive in not being contextual - because it requires a separate-from-browser application, communicating about information on drupal.org may feel discordant.

An integrated web-based chat facility on drupal.org (e.g. https://drupal.org/project/drupalchat) which displays to logged-in members of the community and features chat rooms per topic would be a huge improvement.  If possible, this could just be a web client to an IRC server so that the existing conversations are not buried but instead brought right onto the drupal.org website.  As members browse drupal.org and have immediate questions which may not warrant posting an issue queue, they should be able to simply type a chat message and be able to reference whatever they are looking at on their screen.  A web-based chat system would also serve to better introduce members of the community to one-another as their on-site profiles would be linked to their chat IDs/handles (as opposed to the general anonymity of IRC handles.)

 

Financing Innovation

Problem - There is no direct way for members to sponsor development of modules which do not exist.

Suggestions:
There needs to be a marketplace by the community for the community - where module development can be proposed and answered by parties interested in working on specific modules.  This would rely on better member profiling and need some automated notification whereby members can type in a time (or other resource) commitment of availability to work (for the community) and the type of work they can offer.  

Ideally drupal.org would notify members with related availability when a project has been proposed, and then voted for with a certain minimum weight by the community.  In addition to being able to create a floated list of top-priority module development projects, an integrated crowd-funding system would ensure that adequate resources could be allocated to developing whatever modules the community needs.  So, based on availability and remuneration needs, community members could actively work on module development and be paid for their time and effort.

Problem - When module development stalls, vendor credibility suffers.

Suggestions:
Many Drupal modules have been created to integrate Drupal software/websites with 3rd party services (such as Mailchimp for email newsletters or Kaltura for video.)  Some of these are actually sponsored or even published by the 3rd party service but the majority are created out of needs specific client projects present to developers.  A common phenomena seems to occur on drupal.org where a lot of work is put into creating an integration module and then its developer will not have adequate time or will to support its development; leaving modules out-dated as their integrated service adds features etc in time.  

Often in these cases the 3rd party service vendor isn’t aware that the lack of support for their Drupal integration is causing drop-off to their service use within the Drupal community, or unsure as to what extent that drop-off or dissatisfaction has reached.  Ultimately drupal.org relies on issue queues per module to provide forum for discussing Problems of all kind with modules.  As issue queues grow and developers become weary of supporting modules they’ve created out of lack of time/money to do so, it would be helpful if they can flag a module for additional support; this could be facilitated as a formal request to the integrated service (sent on behalf of drupal.org - lending brand equity and stature) and/or a request for support to the community.

Again, integrating a crowd-funding mechanism with drupal.org could allow not only new modules to be sponsored by the community but existing modules - so when a developer can’t afford to work on their module, the community can help buy the time required for them to fulfill issue queue requests/feature-advancement etc...

AttachmentSize [Empowering Community Engagement Through Improving drupal.org - PDF Version]2.4 MB

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