Web Development

Upcoming project at Medialab Prado’s Collective Intelligence 2017.

The citizen platform Consul is used by Madrid and over thirty other cities in Spain, as well as several cities in Latin America. In the last few months it has also been used by the social housing company of Paris for participatory budgeting and the British People’s Momentum for their annual meeting. This makes it one of the most interesting and well used open source projects for deliberative democracy right now.

Many of the organisations and social movements that we in Digidem Lab are in contact with are impressed by the possibilities of Consul. But it is also hard to demo the tool for them, and show them what their next step for implementing it would be.

Although a very useful tool with a wide range of use cases, the installation and setup process requires a lot from its administrators, and is something we believe is holding it back from being more widely used.

Adapting to new needs

With the new target audiences for Consul (cities abroad, NGO:s, different kind of participatory budgets), we need to look at the user journeys for adapting the tool for the different users and see how to best meet their needs and expectations.

This project is about finding the best ways to lower the threshold for the installation and setup process for these new target audiences. With an interdisciplinary team of marketers, developers and designers, we would be able to tackle many of the obstacles to wider implementation of Consul and provide a clear step by step process for any organisation interested in implementing and adapting it.

Any self hosted platform will of course have the problem of needing people with technical expertise. But some open source platforms, like for example Nextcloud, has shown an ability to meet their users half way by providing a range of options for installations, demo versions and documentation.

Finding the pain points

We will work in two phases, by first identifying new target audiences, their needs and pain points; then work iteratively on the setup process and documentation.

In the first phase we will get to know the users by defining target audiences, researching user experiences, defining personas and drawing user journeys.

Defining new target audiences: Which are the new groups using Consul, and how do we pinpoint and define these new users?

Researching user experiences: Interviewing for example Open Source Politics from France and Peoples Momentum from the UK about their experiences from using Consul in new contexts.

Personas and user journeys: Defining detailed profiles for our new personas. Creating user journeys for how the personas ideally would come to adopt Consul. Identifying pain points and obstacles where improvements in the documentation and installation process can be made.

Working on improvements in iterations

In the next stage, we work on improvements in iterations looking at for example automated installation options; a clearly designed installation guide; pre-configured installation profiles or demo versions based on the known user cases like citizen platforms, annual meetings, participatory budgeting.

Automated installation: Help the Consul development team with automated installation scripts for Ansible or Heroku. There are some progress in making Docker images that we could develop further.

Installation guide: There is a new drafted text from the Consul team. We could design and set up a manual in for example Read the docs or Hexo and work on the texts. Another option to explore is to make instruction videos for the different user cases.

Installation profiles and demo versions: The Consul team is working on a preconfigured setup file that we could extend to cover more cases that would be useful for demo versions.

Going worldwide

We are collaborating with the Consul development team to contribute to their work and base this development on their future needs. They are already making progress in these three areas, that we could feed into and develop further during the lab.

The overall theme is to make the installation and setup process easier and more accessible, to make it go worldwide! While these are general ideas about how to do it, the exact ways will depend on the identification of personas and user journeys, our contact with the Consul team, and the input and different skills that the working team contribute with during the lab.

This is a recap of a talk by Petter Joelson at Rabash’s Design Salon on February 19, 2015.

My agency Rabash was hired in 2014 to start redesigning Doctors Without Borders (Médecins Sans Frontières, MSF) Sweden’s website. The mission was to make the navigation intuitive, especially on smaller screens; optimise the donation interactions and enable moderators to create flexible campaign pages.

After the initial concept phase, I chose to start working on an early responsive prototype in html. Step by step, the prototype evolved to be equivalent to a full website. It might seem like a complicated process to make such vast prototypes in html, but I have learnt some tricks to make it quite easy. I have also seen three major advantages in this way of working, that I will walk you through one by one.

1. Responsive

Show the client how the website will look and behave.

Since responsive design came around a few years ago, I have worked according to the Mobile First-principle, and started the design process with wireframes for mobile screens. It is often an illustrative way of showing the client which priorities they have to make for the website to be easy to navigate. But it started to feel more and more impractical to show mockups of a page that does not look like the end result at all and can not be tested in its ”natural environment” which is the browser on a phone, tablet or desktop. This makes it unnecessary hard for the client, and even me as a designer, to envision the functionality and look of the final product.

Having to write complicated code just to show a quick idea for a client would not work for me. My first criteria for prototyping was that it should involve as little coding as possible. And even as front end development has become more and more specialised and complicated over the years, there are now more and more easy to use frameworks for building websites and other digital products.

A couple of years ago I started to experiment with simple prototypes in html. In the beginning it was just static pages built with Bootstrap. When I got the hang of it, I realised that it was actually as quick as drawing page by page in a wireframe app. For example: if I changed the height of an element at the top of the page, I did not have to move every other element; if I wanted to change the size of all headlines, I only had to do it once.

Now I use a combination of Bootstrap and Jekyll, with a few minor plugins that I install with Bower.

2. Modular

Give clients a custom design system with which they can modify, extend, and grow with into the future.

Brad Frost

A few years back, it was a really big deal when you every three to five years launched a new website. After the launch the sites became more and more out of date, until you did a complete redesign again. Most people understand now that their website has to be a living thing that evolves over time, in small adjustments, to stay relevant to users.

So how do we adapt to this workflow in the design process? Brad Frost advocates a method that he calls Atomic Design. He breaks down the design into smaller components to be able to present the client with a comprehensive design system, not just mockups for specific pages. Frost uses five levels for his design system:

Atoms: A single button or headline
Molecules: A search field with button and textfield; A byline for an article
Organisms: A campaign area, menu or list of news
Templates: The page template for news articles
Pages: Complete pages like About or Blog

To showcase the design system, Frost has developed something he calls Pattern Lab, that provides a kind of responsive style guide, documenting all parts of the website.

Inspired by Frost’s Pattern Lab, I developed a documentation for the different components of the website for Doctors Without Borders. It made it easier to explain to our AD which components needed graphic design, and the structure of the website became clearer for our developers.

For a vast project like this, it also made the whole workflow run smoother, as I could get an approval from the client for specific components, before the whole page template was done.

3. Content first

Separate content and presentation

A challenge with the new design was making huge amounts of information accessible on small screens. To achieve that, I needed to start with the content, and not make the mistake of building a perfect website, that get gets ”ruined” when the actual content is added.

The advantage of working with a system like Jekyll is that you can make a complete separation of design and content. The content files, using Markdown, are super simple text files that only defines the content, fields and template to use, nothing more.

That enables me to be able to work separately with the content, let a copy writer or the client go through the texts during the prototyping phase, and avoid surprises in later stages.

The prototype for Doctors Without Borders is nearly a complete version of the website, as I define templates in Jekyll and then only need to add ”raw” content.

From the prototype, I was able to generate a documentation page, that lists entry pages, types of articles, components and menu items.

To be able to make this separation of content and design is extremely valuable for responsive design. When the next gadget with a browser arrives (glasses, watches and so on), you will have the content files ready and can focus only on designing the presentation.

Next step: Integrating design and development

During this process, the prototyping has evolved parallell with the graphic design and the development of the final website. My aim for future projects is to better be able to integrate these processes, and be able to create both design and functionality in an iterative way and in dialoge with the client. When the CMSes become easier to work with, and the software for graphic design are better suited for responsive web it will of course get easier. But until then we need to experiment with ways of making the transitions between design and functionality as seamless as possible.

Making Madrid´s citizen platform accessible to a wider audience