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

Sep 16 2017
Sep 16

While preparing for my DrupalCamp Belgium keynote presentation I looked at how easy it is to get started with various CMS platforms. For my talk I used Contentful, a hosted content as a service CMS platform and contrasted that to the "Try Drupal" experience. Below is the walk through of both.

Let's start with Contentful. I start off by visiting their website.

Contentful homepage

In the top right corner is a blue button encouraging me to "try for free". I hit the link and I'm presented with a sign up form. I can even use Google or GitHub for authentication if I want.

Contentful signup form

While my example site is being installed I am presented with an overview of what I can do once it is finished. It takes around 30 seconds for the site to be installed.

Contentful installer wait

My site is installed and I'm given some guidance about what to do next. There is even an onboarding tour in the bottom right corner that is waving at me.

Contentful dashboard

Overall this took around a minute and required very little thought. I never once found myself thinking come on hurry up.

Now let's see what it is like to try Drupal. I land on d.o. I see a big prominent "Try Drupal" button, so I click that.

Drupal homepage

I am presented with 3 options. I am not sure why I'm being presented options to "Build on Drupal 8 for Free" or to "Get Started Risk-Free", I just want to try Drupal, so I go with Pantheon.

Try Drupal providers

Like with Contentful I'm asked to create an account. Again I have the option of using Google for the sign up or completing a form. This form has more fields than contentful.

Pantheon signup page

I've created my account and I am expecting to be dropped into a demo Drupal site. Instead I am presented with a dashboard. The most prominent call to action is importing a site. I decide to create a new site.

Pantheon dashboard

I have to now think of a name for my site. This is already feeling like a lot of work just to try Drupal. If I was a busy manager I would have probably given up by this point.

Pantheon create site form

When I submit the form I must surely be going to see a Drupal site. No, sorry. I am given the choice of installing WordPress, yes WordPress, Drupal 8 or Drupal 7. Despite being very confused I go with Drupal 8.

Pantheon choose application page

Now my site is deploying. While this happens there is a bunch of items that update above the progress bar. They're all a bit nerdy, but at least I know something is happening. Why is my only option to visit my dashboard again? I want to try Drupal.

Pantheon site installer page

I land on the dashboard. Now I'm really confused. This all looks pretty geeky. I want to try Drupal not deal with code, connection modes and the like. If I stick around I might eventually click "Visit Development site", which doesn't really feel like trying Drupal.

Pantheon site dashboard

Now I'm asked to select a language. OK so Drupal supports multiple languages, that nice. Let's select English so I can finally get to try Drupal.

Drupal installer, language selection

Next I need to chose an installation profile. What is an installation profile? Which one is best for me?

Drupal installer, choose installation profile

Now I need to create an account. About 10 minutes I already created an account. Why do I need to create another one? I also named my site earlier in the process.

Drupal installer, configuration form part 1 Drupal installer, configuration form part 2

Finally I am dropped into a Drupal 8 site. There is nothing to guide me on what to do next.

Drupal site homepage

I am left with a sense that setting up Contentful is super easy and Drupal is a lot of work. For most people wanting to try Drupal they would have abandoned someway through the process. I would love to see the conversion stats for the try Drupal service. It must miniscule.

It is worth noting that Pantheon has the best user experience of the 3 companies. The process with 1&1 just dumps me at a hosting sign up page. How does that let me try Drupal?

Acquia drops onto a page where you select your role, then you're presented with some marketing stuff and a form to request a demo. That is unless you're running an ad blocker, then when you select your role you get an Ajax error.

The Try Drupal program generates revenue for the Drupal Association. This money helps fund development of the project. I'm well aware that the DA needs money. At the same time I wonder if it is worth it. For many people this is the first experience they have using Drupal.

The previous attempt to have simplytest.me added to the try Drupal page ultimately failed due to the financial implications. While this is disappointing I don't think simplytest.me is necessarily the answer either.

There needs to be some minimum standards for the Try Drupal page. One of the key item is the number of clicks to get from d.o to a working demo site. Without this the "Try Drupal" page will drive people away from the project, which isn't the intention.

If you're at DrupalCon Vienna and want to discuss this and other ways to improve the marketing of Drupal, please attend the marketing sprints.

Share this post

Dec 20 2016
Dec 20

War Child UK describes itself as “a small charity that protects children living in some of the world's most dangerous war zones”. Founded in 1993, the charity works with vulnerable children and communities in war torn areas; providing safe spaces, access to education, skills training and much more to ensure that children’s lives are not torn apart by war.

War Child International has multiple offices all over the world, protecting, educating, and empowering marginalised children.

The Short Brief

The UK team came to us with a mission: to get a new site live as soon as possible. They’d done the planning and got the design; we needed to implement it quickly.

The previous War Child UK site wasn’t responsive, so they felt there were missing many donation opportunities from supporters on mobile and tablet devices. They also wanted a bold new design, with a high focus on imagery, for the highest possible impact and to create empathy.

From a Content Management System (CMS) point of view, they wanted to rationalise and consolidate content types, so the site could be easily managed without large overheads. Every penny counts for charities, and the website should enable them to get information and campaigns out quickly and easily, without a large website team or dependency upon external agents.

The original site also integrated with Stripe and Salesforce, and they wanted to ensure this functionality remained to provide a seamless experience for their donors, and reduce the need for internal training on the new site.

They also had a deadline: they wanted the have the new site up and running in time for a new donation drive for Christmas.

We sat down and crunched some numbers. We calculated that we could have one three week sprint before we had to deploy to live. We got to work.

‘good enough and live’ is better than perfect but in development for months.


How?

So, that was our mission: To build and launch a Minimum Marketable Product (MMP) with donations, and a simplified CMS in a single three week sprint. It had to be a polished product that would serve them during one of their busiest periods, without a loss of critical functions, such as donations. A MMP achieves the earliest possible route to market and therefore brings benefits sooner without cutting corners. With a tight deadline this approach was right.

Their previous site was Drupal, which we have a lot of experience with. There are many pre-existing modules available, such as Stripe and Salesforce that meant we could produce what they needed without much customization, which freed the team up to focus on providing the best site we could

We knew we had to get things right first time - we didn’t have time for cycles of iterations or lots of bugs back from the client. We always aim for right first time, but with this deadline it was imperative. We started writing Acceptance Criteria.

Warchild-iPad.jpg

Acceptance Criteria is a method of writing out conditions that the software must meet to be accepted by the client, or users, or other stakeholders. They’re written in non-technical terms, using terms specific to the business or organisation in question. They are the one version of the truth of what we’re building, understood and signed off by the lead developer, the QA person, and the client.

The acceptance criteria combined with the designs meant we had a clear vision of what each piece of functionality should do and look like before we started work, and the client knew what to expect from our work before seeing it.

The client was on board with the MMP model, realising that:good enough and live’ is better than perfect but in development for months.We started planning the next two sprints while development work was happening on the first sprint, so War Child’s stakeholders had continued visibility of what was future work was, and access to a backlog for long term future planning.

[embedded content]

The small number of essential features meant we could still be flexible in what we offered in the first sprint - even bringing in small features from the backlog when we realised it would be useful for go live and that it would fit in our time scales.

We learned a lot from this small, fast project: that an MMP site is possible in weeks not months, but that requires forward planning, flexibility, and buy-in from all members of the team. We learned a lot technologically as well, integration with Stripe and Salesforce and customising it for War Child UK’s set up.

blog-warchild-mobile.jpg

War Child UK now have in place a mobile donation platform underpinned by a powerful Drupal CMS. This is just the beginning. Thanks to Drupal’s extensibility and with our Agile process there are a series of additional features in the pipeline, all aimed at placing War Child in a better place to help children in crisis.

War Child UK now have in place a mobile donation platform underpinned by a powerful Drupal CMS. This is just the beginning. Thanks to Drupal’s extensibility and with our Agile process there are a series of additional features in the pipeline, all aimed at placing War Child in a better place to help children in crisis.

Mosul appeal: War Child have a team on the ground right now providing safe spaces and emergency care for 6,000 boys and girls who have fled the city.

Read the full case study

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

Apr 24 2015
Apr 24

Launching a website is just the beginning of a process. Websites need nurturing and care over the long run to stay relevant and effective. This is even more true for a service or tool such as LibraryEdge.org. Why would users come back if they can only use the provided service once or can’t see progress over time? And how can you put that love and care into the service if it is not self-funded?

This month, LibraryEdge.org released a number of changes to address just these issues.

Helping Libraries Stay Relevant

Before we dive into the release, here’s a bit on the Edge Initiative.

With the changes created by modern technology, library systems need a way to stay both relevant and funded in the 21st century. A big part of solving that problem is developing public technology offerings. Even in the internet-connected age, many lower-income households don’t have access to the technology needed to apply to jobs, sign up for health insurance, or file taxes, because they don’t have personal computers and internet connections. So where can people go to use the technology necessary for these and other critical tasks? Libraries help bridge the gap with computers and internet access freely available to the public.

It’s important that libraries stay open and are funded so their resources remain widely available. By helping library systems improve their “public access computers/computing,” the Edge Initiative and its partners have made major strides in making sure libraries continue to be a valuable resource to our society.

That’s where LibraryEdge.org comes in. The Edge Coalition and Forum One built LibraryEdge.org in 2013 as a tool for library systems to self-evaluate their public technology services through a comprehensive assessment – plus a series of tools and resources to help library systems improve their services.

New Functionality

Reassessment

The biggest feature update we recently launched was enabling libraries to retake the Assessment. They can see how they have improved and where they still need work compared to the previous year. To create a structure around how libraries can retake the Assessment, we built a new feature called Assessment Windows. This structure allows the state accounts to control when the libraries in their states can take the Assessment. States now have control over when their libraries conduct the Assessment and can track their libraries’ goals and progress on Action Items. This feature allows states to more accurately assess the progress of their libraries and adapt their priorities and programming to align with library needs.

Edge State

Results Comparison

The Edge Toolkit was initially built to allow users to view their results online, along with providing downloadable PDF reports so libraries can easily share their results with their state legislatures and other interested parties. Now that libraries can have results for two assessments, we’ve updated the online results view and the PDFs. Libraries can now see a side-by-side comparison of their most recent results with their previous results.

table

Graphs

It’s common knowledge that people retain more of what they see, so we’ve also visualized important pieces of the results data with new graphs. If a library has only taken the assessment once, then the charts will only display its highest and lowest scoring benchmarks. However, if they’ve taken the assessment a second time, they can also see bar graphs for the most improved and most regressed benchmarks.

graphs

Improved User Experience

Interviews

We made a number of enhancements based on feedback from libraries that have been using the tool for the past couple of years, as well as from interviews that we conducted with State Library Administrators. Starting with a series of interviews gave us great insight into how the tool was being used and what improvements were needed.

New Navigation

The added functionality of being able to retake the Assessment increased the level of complexity for the Edge Toolkit. So we redesigned the interface to guide users through this complex workflow. We split out the Toolkit into four sections: introduction/preparation, taking the assessment, reviewing your results, and taking action. This new workflow and navigation ensures a user is guided from one step to the next and is able to complete the assessment.

Notification Messages

Several dates and statuses affect a library system as they work through the assessment, such as how long they have to take it and whether it is open to be retaken. We’ve implemented notifications that inform the user of this information as they are guided through the workflow.

new

Automated Testing

When we release new features, we need to ensure other components on the site don’t break. Testing this complex of a system can take a long time and will get expensive over the lifetime of the site if it’s done manually. Furthermore, testing some sections or statuses involves taking a long assessment multiple times. In order to increase our efficiency and save time in our quality assurance efforts, we developed a suite of automated tests using Selenium.

What’s Next for Edge

The updated LibraryEdge.org now allows libraries to assess their offerings again and again so they can see how they are improving. Additionally, we’ve built a paywall so Edge can be self-supporting and continue to provide this valuable service to libraries after current funding ends. The launch of this updated site will help Edge remain relevant to its users and, therefore, ensure libraries remain relevant to our communities.

Previous Post

Is Your Site Telling You Something? Start Listening to the Analytics

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!

Aug 28 2014
Aug 28

Gesso theme on drupal.org For the past year Forum One has been using a Drupal starter theme created in-house to make theming more flexible, consistent, and easier to maintain. This theme is now available on drupal.org! Gesso (pronounced JEH-so) is an art term for the white paint mixture used to prepare a canvas or sculpture for painting. Likewise, the Gesso theme prepares Drupal’s markup and styles to give us a clean starting point.

Gesso is a responsive, Sass-based theme developed with accessible, standards-compliant HTML5 markup. It follows a mobile-first, future-friendly approach to coding responsive websites. Gesso also removes much of the cruft that we previously tended to override on each project and standardizes common components.

A word of caution: this theme is geared towards advanced themers. If you want to be able to manipulate the theme’s design, markup, or layout via a nice GUI, Gesso is not the theme for you. We built this theme to make it easy to customize within the Drupal theming layer, without getting in your way.

Gesso is not a stand-alone product. It depends on several Drupal modules and Sass tools: Magic, HTML5 Tools, Compass, Breakpoint, and Singularity.gs. It also integrates well with optional Drupal modules such as Display Suite, Panels, Blockify, Clean Markup, and Modernizr.

To be clear, Gesso wasn’t created in a vacuum. We got a ton of great ideas by diving deep into the code of other Drupal themes, such as:

If you want to develop a deeper understanding of Drupal theming, I encourage you to check out the code within these themes.

The biggest differentiator between Gesso and other themes is the altered Drupal markup, which makes it easier to follow the Drupal 8 CSS architecture guidelines. This theme leverages SMACSS with a modified BEM naming convention to organize styles. This encourages a component-based approach to theming through the creation of discrete, reusable UI elements.

In follow-up articles we’ll cover Gesso in more depth, including Sass organization, site building, and theme settings. Please join us in the issue queue if you have questions or ideas on how to improve it.

Previous Post

Customizing SearchApiQuery Filters

Next Post

Making a Big Splash at World Water Week

Developer? Designer?

Join the Forum One team.

Apply now
Jul 15 2013
Jul 15
image/jpeg iconhansel_und_gretel.jpg

Here is the deck I presented at DrupalCamp Toronto 2013 this past weekend; a video of the presentation should be made available soon.

The overview of the talk:

Whether Drupal is used to create simple online publishing solutions or more robust web applications, developers often focus on implementing whatever a 3rd party designer has specified for the' front end' user interface and ignore the need for well designed interfaces to administer sites.

This session will take a macro perspective look at how Drupal out-of-the-box comes with general work-flow problems by relying on implementers to develop custom user experiences, and then jump into simple ways these can be facilitated through modules available from drupal.org

Ref: http://2013.drupalcamptoronto.org/sessions/modules-to-help-streamline-us...

Jun 14 2013
Jun 14

The people who use any given web site are all different in terms of geography, past behavior, intent, device, time of day, the temperature of the climate they’re currently in…and the list goes on. Developing for the web is anything but easy, so, over the last few years, the Drupal community has been focusing on keeping up with the various mobile device sizes, design patterns and browser technologies, putting a lot of attention on responsive design, and doing it well. So, we’ve since been doing fairly well on adapting to various devices, but what about the aforementioned traits such as intent, past behavior and the like?

We often create personas to plan and design web sites, but the content does not embody or respond to these fictional-turned-real characters. Marketers spend a lot of time producing content that could be better-tailored to each individual. An individual’s browsing history can be cookied, if they are an anonymous user, or logged in analytics and tied to their account as an authenticated user.

Amazon.com has been a leader in this domain. Just look at all the recommendations and custom-tailored content you receive when logged in to amazon.com. The site even informs the anonymous, uncookied user when there is no browsing history to act upon, encouraging further activity on the site.

Amazon.com with no browsing history

Think about a woman in her late 60s – based purely on statistics, she might opt-out if she receives an email that contains offers for power tools and pro athlete products. Or a man who receives an email with women’s clothing. Similar consequences are in play on web sites.

Another example of a leader in context is Netflix. New videos are recommended based on your viewing habits, ratings, and even your Facebook friends’ activity on Netflix.

Screen Shot 2013-06-14 at 4.39.50 PM

The buzzword for this context is called Web Experience Management (WEM). Vendors have been developing proprietary, expensive, closed-source solutions. It is to the great benefit of the Drupal community to engage in WEM as part of What Drupal Does. There is already work being done with the WEM project that allows one to track user events as they occur throughout the site. By so doing, one can customize a user’s experience so that it is unique and relevant to the user. The WEM module also integrates with Google Analytics to further track events. Any event you track in WEM can also be sent to Google Analytics.

Events are tracked via the included  Engagement API. You can track an event via PHP on your page or during a certain hook in a custom module. The PHP would look something like this:

engagement_event_track($event_name, $event_value, $event_data, $uid);

An event can also be tracked via Javascript, like so:

Drupal.engagement.track(event_type, val, data)

An event can also be tracked via HTML, such as in an HTML email.

The WEM project is currently under active development, but already usable. It needs people to help with integration into Views, Rules, and similar Drupal architecture patterns. With that, let’s close with a few screen shots of the WEM module in action, running on on Drupal 7. One can see that UI for assigning points to events within categories is simple yet effective. User segments can be built from these categories and corresponding point totals to deliver a customized, contextual experience to your user. This effort will hopefully make WEM much less of a concept of its own, and lead to the expectations of what Drupal does as a CMS. WEM is really just a CMS, with context.

Screen Shot 2013-06-12 at 3.33.41 PM Screen Shot 2013-06-12 at 3.34.33 PM Screen Shot 2013-06-12 at 3.34.44 PM

Web Experience Management: User interface in Drupal 7

Web Experience Management: User interface in Drupal 7

May 22 2013
May 22

We just launched Zact, one of our largest design projects to date at Chapter Three. We designed nearly 200 comps, including an e-commerce workflow, a customer dashboard that mirrors the functionality of the phone’s software, a Support section built on ZenDesk, and a consumer-facing website.

A disruptive new cell phone provider, Zact is a new company looking to redefine how customers purchase mobile services by making your plan 100% customizable right from your phone with no overage fees or contracts. They even give you a refund every month for any unused minutes, texts or data.

Helping Zact overcome business hurdles
As a new company in a major market, Zact turned to Chapter Three to help them solve some of their immediate business hurdles online.

  • Establishing brand trust
    To overcome lack of brand recognition and to educate new customers about the key advantages of the service, we created the “Why we're different” and “How it works” sections as a way for new customers to get to know us.
  • Paying full price for the phone
    To educate customers about the long term savings of buying the phone at full price, we created an interactive Savings Calculator. The calculator allows customers to compare various plan and phone options to their current bill to show their dollar amount saved over a two year period.
  • Buying a phone online
    Without the ability to physically touch the phone customers are buying, we needed to build in extra guarantees to make customers feel comfortable purchasing a device online. We featured a “satisfaction guarantee” statement prominently throughout the site, promising a refund within 30 days if the customer did not like the phone.

Herculean feats of UX strength
The complexity of interactions across the site gave us an opportunity to flex our UX chops. We collaborated with Zact’s usability specialist, incorporating feedback from weekly usability tests to iteratively improve our designs.

  • Customer dashboard
    To provide the functionality of the phone’s software on the website, we designed a web-specific interpretation of the phone software that empowers customers to access and control the full breadth of Zact’s service offerings. Because the software was being developed in parallel with our web design, we adopted an agile design approach to iterate in sync with the development team.
  • E-commerce
    Our team worked with Zact’s usability specialist to implement a checkout flow pulling from best practices across the web. We delivered a solution that pushes the capabilities of Drupal Commerce and its ability to integrate with third-party systems.

Agile design
An agile design process was critical in the success of this project. We needed to be flexible as requirements and scope were changing daily. We met with the client daily via WebEx with new design deliverables for review, which allowed us to gather feedback often and respond quickly. For any given page, we were able to explore a number of options on a high level before focusing on a more final solution.

In fact, some of the best ideas on the project came directly from the client, as a result of organic discussion during those meetings. The Savings Calculator, which allows users to more visually understand how they will save money over time with Zact, grew out of a conversation we facilitated.

Our first iterations of the Savings Calculator were pretty skeletal and didn’t quite feel right; the user had to fill out the form and click a button before seeing results. After further discussion, the client suggested that we make the actual dollar savings visible and dynamic throughout the page, so that as you interact with the form you can directly see how your savings are affected. This minor design change immediately made the page more engaging and an effective tool in communicating why Zact is a viable alternative to a traditional phone contract.

Starting up in Silicon Valley with Drupal
One of the most exciting and challenging parts of the project was the rapid pace of startup culture. The level of expertise and web savvy amongst Zact’s staff allowed for a flourishing partnership where we were able to push boundaries and do great work together. So far, the site has been covered by some major press outlets, including Gizmodo, Engadget, Forbes and TechCrunch.

The site is finally live, but our work isn’t over yet. We’re continuing to evaluate and optimize the usability of the site and will continue to roll out design updates over the coming weeks. We look forward to working further with Zact and seeing how users will react to the new site.

Feb 07 2013
Feb 07

Design Principles for a Multi-device World

Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction.
— Albert Einstein

I would argue that a huge part of that genius Einstein refers to can be found in clarity of purpose and principles.

We all wind up in those situations where we're focusing on technical details, implementation and points of process, and missing the bigger picture. I confess I've been there far too often. When we find ourselves in those situations as designers, it's important to have some guiding principles we can remind ourselves of and even share with our team and colleagues. Guiding principles can help get everyone on the same page and make it easier to work through the details of process and implementation. They're no panacea, but they've certainly helped me maintain my sanity.

Below I've documented some of my emerging, fundamental design principles. These principles have helped guide me in this brave new world of a bazillion devices and amazing possibilities. Hopefully they'll be helpful to you as you hone your design process, document your own principles, and face challenges along the way.

    The mobile web is important!

    Secret: 98% of the following three paragraphs I learned directly from Luke Wroblewski. If you need help making the case for a focus on mobile, read his writing, see him speak, get in touch with him!

    Why care so much about mobile in our design process? By Q1 of 2012 Apple released numbers that showed there were now more iPhones sold every day than babies born in the entire world (300k babies to 402k iPhones)! That was just iPhones, there were actually 562k iOS devices (which includes iPod Touch and iPad) sold each day at that time. By Q1 2012 we'd also reached 700k Android devices activated per day, 200k Nokia smartphones and 143k Blackberry devices. According to Morgan Stanley Research, by 1990 there were 100M+ desktop internet users. By the early 2000's we had reached 1B+ desktop internet users. Today that number of desktop internet users is only slightly higher than it was in the early 2000's, yet the number of mobile internet users is now 10B+! The number of mobile devices on the planet surpassed the number of humans on the planet nearly two years before Morgan Stanley's research predicted it would, which means mobile is not only ubiquitous, it's growing faster than our expectations.

    But wait, there's more! In Q1 of 2012 Facebook announced they were seeing more people accessing Facebook on the mobile web than from ALL of their top mobile native apps combined! Facebook also released data suggesting that mobile web and app users invested noticeably more time on site than all of their Desktop web users combined. In Q3 of 2011 Nielsen US released their research on mobile users showing that of the millions and millions of mobile users across all platforms, significantly more were using the mobile web as opposed to native apps when given the choice (57M vs 49M).

    Create once, publish everywhere.

    Editorial teams need a singular, simple workflow to produce content once that then gets distributed efficiently and effectively to all device types. Editorial teams need to be focused on content quality, NOT things like device level placement, layout and aesthetic style. When developing your content model, model content types on core editorial and business needs, with an eye towards multi-channel reuse. You can then use those building blocks in the design process. This will ensure that editors aren't forced to become "designers by default". Ideas about form, structure and presentation that create new and more complex processes for editorial teams should be viewed with skepticism and caution. Anything that slows the editorial process, without adding significant content value, damages the core value in your product. A COPE approach (Create once, publish everywhere), with a consistent content model and simple data feeds that can be used by web-based widgets, apps, and business partners, helps facilitate rapid experimentation and innovation. It ensures that experimentation can happen at "the edges" without requiring foundational infrastructure changes.

    Editorial workflow is important!

    It's very easy for design teams to become focused on the consumption experience for content on a website, while completely ignoring how said content is created, reviewed, edited, curated and published. Great consumption experiences begin with great creation experiences. Spend time with the authors, reviewers, editors and publishers early in your design process. Watch what they do. Learn about the content they're producing. Gain an understanding of things like volume (how much of it do they produce), frequency (how often do they produce it) and average length (how much content makes up a single piece) for every type of content they're producing. As a designer, you can't create innovative ideas for new components and interaction methods without really understanding the content, and the best way to understand the content is to spend time with the people who create and nurture it.

    The second part of this principle is that bad or painful editorial workflows create content problems. Also, eliminating editorial workflow pain points makes happy clients. You may not be able to solve all the problems of an editorial workflow process as a designer, but you can play your part in the process by treating it as important.

    Release early and often.

    "Write drunk, edit sober."
    — Ernest Hemingway

    Always err on the side of the simplest viable product for each release (see KISS principle as well as Getting Real). Make quick decisions, make something, find out how users interact with it and what they're valuing. Discover pain points. Adapt. In a competitive market place we need to iterate quickly and fail gracefully. Failing is necessary for innovation, and we can't fail till we try something. Create a culture of rapid experimentation as opposed to analytical paralysis.

    Make existential design decisions based on data, 
not assumptions.

    By "existential design decisions" I mean decisions about whether a particular piece of content or component should exist on the screen. The basic rule here is don't remove things from a mobile experience because you assume mobile users don't want it. Conversely, don't add additional elements to a desktop experience because you assume those users want "enhanced experiences." Begin by delivering one content model and architecture across all devices, and then let real user data drive device specific optimization and customization.

    Mobile users will tell us what they're wanting as they use things (or don't use things). Their interaction patterns, values and preferences can guide optimization and customization, but not until we have them. We need to release something and watch people use it before we form assumptions (see earlier release early and often principle).

    Begin with the basic question of "Is this valuable for users?", not "Is this valuable to users on a particular device type or screen size?". While we may make some assumptions about hierarchical discrepancies from one device type to another, always start from the assumption that if it's important to users, it's important to ALL users.

    It's worth noting that gathering web-based metrics about the behavior of mobile users is easier than logging and tracking the detailed interactions of mobile app users. The mobile web experience can lead the way for us, providing the data we need to understand user values and interactions. Mobile users continue to defy expectations as to what they will do and want to do on their mobile devices. A common frustration for mobile web users happens when assumptions are made about what mobile users do NOT want or need from a desktop experience. It's extremely important that we not limit mobile users based on these assumptions. Creating tailored experiences with unique content models and components for different devices can create significant user experience problems. For example, lets imagine google indexes the desktop version of a website, and provides links to said content on mobile devices based on a search. If those mobile devices then redirect to a tailored site with a limited content model, editing out the content that was searched against, confusion and user frustration ensues. We must never dumb down or limit a desktop experience and call it a mobile experience!

    Design from content outward (not device type or display inward).

    Focus first on delivering the best and simplest possible experience of a complete content model across all devices. Design should begin by uncovering the most valuable type(s) of content, and designing an experience for those. All subsequent displays and views into that content should follow. For example, a news site could begin by determining the most valuable type(s) of news content they provide to their consumers. A design team can then begin researching, wireframing, prototyping and brain storming around the consumption experience of a representative piece of content from each of those types. Once that is fleshed out, the focus can shift to the various structural channels through which parts of that content type are displayed (e.g. a homepage, a top level category landing page, etc.).

    Nothing's more important than knowing what's important.

    "Design is the conscious effort to impose a meaningful order."
    — Victor Papanek

    Design is about helping people understand what's really important and meaningful. That's beautiful. Embrace it! Discover and understand the relative importance of each type of content, the pieces that make up that type of content, and the channels through which that content flows. You can't begin to apply visual hierarchy in design without first knowing the content hierarchy. Design decisions should begin with broad hierarchy evaluations. Develop a components list for each screen (a list of the discreet pieces or chunks of content that exist on the page) and assign a relative hierarchy (e.g. a 1, 2 or 3) to each component in the list. After all that, you can begin to work things out visually with placement, proportion, and style.

    Design mobile first.

    Once again, Luke Wroblewski has shined a spotlight on this and helped me understand it.

    Designing "mobile first" means that we embrace the constraints of a tiny screen early in our design process. We evaluate our content model, components list and hierarchy first with that tiny screen in mind. Once we've established that, we then ask if there are ways that hierarchy changes or interactions can be enhanced for users with screen sizes and bandwidth capabilities beyond mobile. The constraints of the mobile screen size help enhance focus during the design process and keep design teams more closely aligned with whatever the core product value is. It's like packing first in a carry-on suitcase to discover what you REALLY want to bring. Often, you'll find that those extra things you put in your larger suitcase never get worn or used.

    This does NOT mean that the visual experience can't be impressive. Remember, in many ways mobile devices have MORE capabilities than what's common among desktop devices. Things like device positioning, motion, location detection, multi-touch, gyroscope, and audio, video and photo input are common among mobile devices. Design teams may actually create more innovative and rich experiences focusing on mobile first during their design process.

    Optimize, then customize.

    After we actually make and release something, and have real user data to drive the next round of iteration and innovation, we need a way to prioritize that iteration. When both optimizations (e.g. technical solutions to serve up smaller file sizes or more appropriate ad sizes) and customizations (e.g. ideas about changes or enhancements to hierarchy, content or features) are being considered, optimizations should almost always be prioritized over customizations. Great experiences come from the ease and speed with which users can access, interact with, and contribute to content, and that ease and speed are very important. Mobile users continue to defy our assumptions about what they want to do on mobile devices, but they almost always want to do it faster and with greater ease.

    Create and maintain a visual language (NOT a myriad of distinct designs).

    Design teams need to produce a flexible visual language that can provide stylistic guidance across a myriad of screen sizes. There are some formal processes and design tools that can help you do this (e.g. element collages, style tiles, web style guides), but the core principle is to establish a visual language that can allow for quick design decisions across all breakpoints. This approach reinforces the "release early and often" principle above. Having a style guide and other tools to guide visual decisions, rather than a collection of concrete designs tied to specific device widths and scenarios, means that new experimental designs don't have to chart their own course. A design process that takes a tailored approach, providing a myriad of custom static comps can dramatically limit your ability to quickly respond and innovate.

    Dec 21 2012
    Dec 21

    Listen online: 

    Jeff Eaton and Sara Wachter-Boettcher discuss her new book Content Everywhere, the benefits of cross-discipline communication, and the need to build tools for humans.

    Links mentioned:

    Release Date: December 21, 2012 - 10:00am

    Album:

    Length: 38:32 minutes (15.27 MB)

    Format: mono 44kHz 55Kbps (vbr)

    Feb 04 2012
    Feb 04

    Posted by Graeme Blackwood on Saturday, 4 February 2012 at 6pm

    One of the most important and complex aspects of a DrupalCon is the schedule. An enormous amount of work goes into getting it right – from the huge number of session submissions, which have to be reviewed and selected by the track chairs and their teams, to the people whose job it is to carefully consider and decide time slots for all of them.

    Once all of this work has taken place, the schedule then needs to be presented, in print, on meter boards, posters and in the delegate guide, as well as on the website and mobile app.

    With around 70-80 sessions over three days and eight tracks, with three possible skill levels and multiple presenters, all split up into different time slots, and sometimes sub-time slots, presenting this lot is not a simple task. I had some great people working with me on the London schedule and I think we did a pretty good job.

    For Denver, the plan was to take the schedule a bit further, making it responsive so that the layout adjusts to the size of the screen you are viewing it on. This is particularly useful for mobile phones and tablets, on which the user experience would be very poor if the design wasn't responsive. Initially the Denver team were looking at a table format for the schedule, similar to the Chicago approach: http://chicago2011.drupal.org/schedule. This layout is really good, but tables don't do well with responsive design. Tables have no way of rearranging themselves – if the width of the table shrinks, the cells just squash horizontally until they are stopped by the longest word in each. This looks pretty horrible and usually breaks a website's layout on smaller screens.

    DrupalCamp Austin did use a semi-table layout, and importantly, it doesn't actually use table markup, meaning it can collapse. This worked well because the number of sessions in a given time slot was limited. Denver's maximum is seven sessions in a single time slot, which even in a 960 set up, would be really squashing them in on a single row and force them to collapse almost immediately on the slightest resize.

    Drupalcamp Austin's horizontal schedule layout

    So a different method was needed. Initially taking the approach of a mobile web app, I put together an example schedule using Denver's branding to help demonstrate how it could collapse on smaller screens. The main difference in this layout is that instead of side by side, the sessions are stacked, divided by the time slots. The track icons were produced for Drupalcon Chicago and it felt really right to pick them up again for Denver.

    The Denver team then adapted the prototype to fit the website and extended the icon set to cover the new tracks. While implementing, they made some subtle improvements to my prototype, like the track title on hover: http://denver2012.drupal.org/program/schedule

    Drupalcon Denver web app prototype

    There are definitely more improvements to be made. The hit area isn't very large on the sessions (only the title), so it's not always easy to press with your finger; wrapping everything in an a tag would resolve this. The rooms aren't displayed yet, which would be pretty useful to help you find your way around and some of the sessions don't fall into specific time slots, so we are working on adding these soon. Also the filters are yet to be implemented on the Denver site, but it is worth looking at the prototype on a mobile device to see how I envisaged them working.

    This is of course, just one example of a schedule for one event format, but if you are reading this from inside or outside the 'Drupalsphere', I hope you found some of the ideas useful.

    Categories: drupal, DrupalCon, Mobile, Responsive, UX

    Nov 04 2011
    Nov 04

    This morning, I happened upon and quickly found myself frowning. I wasn't frowning because of the Wired editors' decisions about which apps are the best, it was because I was frustrated with a glaring design problem in their article and I suspect I know the reason it looks so bad:

    Developers Built it That Way


    Developer-enforced Design Flaws

    It's not an isolated problem, really. A developer is given a functional spec that calls for a grid display of 'apps' which will have a company name and the app name. Seems reasonable, and with most modern CMSes, probably not too hard to build, either. It looks great with dummy lorem ipsum content when shown at the design review meeting, no one ever stops to wonder if their content will actually fit the requirements, though. And then when it comes time to put the real content in both company name and application name are required fields, so when you come to a company that is self-publishing an eponymous app, like Netflix, then your editors are stuck. They are forced to do something they know is wrong and they put the same name into both fields.

    It's easy to pick on Wired, but this is something I see (and, I'll admit, have done) on any number of websites. Maybe it's the nature of building and using content management systems. We do a lot of work with Drupal around here and I think it's safe to say we run into this problem somewhat regularly. We build interfaces and want them to be easy–excruciatingly easy– for editors to use to create and manage content. So we separate content out into separate inputs in the content creation screens, we make different 'content types,' we create arbitrary divisions between what is content and what is 'auxiliary content.'

    Recently, there was a bit of a scandal in the WHATWG around one spec editor's personal plan to deprecate the <time> element and replace it with something he saw as more appropriate. Jeremy Keith wrote a blog post about the event and in it talks about one of the key decision-making guidelines for the HTML spec: the Priority of Constituencies:

    In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once.

    It seems to me that this would be a great guiding principle for CMS developers, too. Of course, with CMS development you might have many types of users: visitors, commenters, contributors, editors, managers, administrators, etc.; so how do you decide who should get precedence? I think the Priority of Constituencies still speaks to this scenario: privilege the visitors of your website over your content creators and staff over your developers.

    What do you think? Do you see developer-enforced design flaws in the sites you visit? In the work you do? How can we bring the Priority of Constituencies into our work as website and CMS developers?

    Jun 17 2010
    Jun 17
    Printer-friendly version

    With the release of WordPress 3, there's a whole new set of discussions about Drupal vs. WordPress.

    I'm going to try and explain my views on UX in Drupal, once again using the lego analogy.

    First, I propose that you need a defined purpose to build great UX. WordPress focuses on blogging, and thus has an excellent blogging product.

    With WP3, they've even integrated their version of multisite / Aegir out of the box. BuddyPress is an example of a product that sits on top of this base infrastructure. So now WP does blogs as well as multi-user social groups / communities.

    In Drupal, we've optimized for a big box of lego. And there are a LOT of pieces in there. Pirate bits, space ship bits, viking bits. And lots of blocks that fit together pretty well if you're creative and pick through looking for ones that match in colour and so on.

    I could talk about the WYSIWYG editor that ships with WP as an example. They took the base piece, customized it, and now have a rich text editor piece that fits exactly into the blogging product. It's not even a block! It can't get re-used easily with all these pirate bits! Sometimes, it's OK to plug in that perfectly shaped lego piece that isn't really a block at all.

    But that's really hard to do if you don't have a defined purpose. Because something that is perfect for a large community site isn't going to be great for running an intranet. And an open everything access & permissions model is great for the former, and dangerous for the latter.

    So, if we want to improve Drupal UX, we can't just take out a big UX brush and improve everything. There are certainly base building blocks and flows that we can improve, but on top of that, it will be need to be optimized for different use cases.

    Just over a year ago, I proposed that Drupal could be a great social community out of the box (as in, core install profile). I'm not so sure anymore, but I think we should continue to have the discussion "What should Drupal do out of the box?" so that a) new users have a reason to use core to accomplish a task beyond "it can build anything" and b) we can experiment with optimizing UX for that purpose. This will teach us lessons that can be re-used and rolled into all Drupal-based products.

    And, in general, I would like to see more people trying to build nicely polished products that have a defined purpose: this is what will move us forward in the UX department. Dries has a discussion on the business model of products / distributions that is important - because we'll need to fund development over time.

    Thanks to @mattfarina for kicking this loose from my brain on Twitter.

    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