English

There are 7 posts tagged English (this is page 1 of 1).

Making Madrid´s citizen platform accessible to a wider audience

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.

Work less, produce more

According to tradition, a programmer’s productivity was measured by “lines of code” in the old days. That is, the amount of code you wrote.

Anyone remotely interested in programming understands how crazy that is, because the less code you need to write to make something happen, the more talented programmer you are (if the code is documented, structured and can be understood by others).

The fact that this measurement was used isn’t that crazy though — that’s our economic system’s standard way of measuring work. We get rewarded for working hard, doing overtime, putting in the hours and so on. If I as an employee come up with a way to do my job in less hours, it’s not like I will be rewarded for it. Just imagine if I came up with a way of completely automating all of my assignments at work. I would probably lose my job.

So a lot of innovation when it comes to automation, which is what a lot of innovation is about, is hampered by how the economy is structured. There is simply no economic incentive for it.

As a result, a lot of amazing innovation comes from other incentives than economic ones. The autobiography of Linus Torvalds, the main guy behind Linux, is called “Just for fun”. That is also how he describes his motivation behind writing the operating system that powers most of the internet servers and supercomputers today. And that is how large sectors of the open source sector still works.

If we truly want an innovation driven economy though, we need to create more incentives for productivity and automation. For starters, collectively owned workplaces would help. That way you might actually benefit from automation and a rise in productivity. Sharing our results and ideas freely will also immensely benefit innovation. And last but not least, we need to get rid of the work ethos that are encouraging us to measure productivity in “lines of code”.

Designing a guiding app for digital democracy

This is a description my project for as a part of the Collective Intelligence for Democracy workshop in November 2016 for MediaLab Prado Madrid.

In Sweden, more young people use Facebook every day than who voted in the last general election. This is an international trend, and most certainly does not come down to lack of interest in politics from young people, but from outdated and excluding tools and processes for democratic participation.

Digital tools open up completely new possibilities for instantaneous participation, discussions and decision making, without relying on geographical proximity. If traditional political instances and organisations do not adapt to new ways of working and thinking, they will keep losing trust and members. If they take advantage of the new possibilities of participation they will have enormous potential.

In the rest of Europe, we look up to you in Spain. You have found ways of implementing some interesting digital services in your local municipalities, political parties and NGO:s, and the rest of Europe has a lot to learn from you.

So we know that there are a lot of interesting tools already available, that needs to be tested and evaluated in local contexts.

In my organisations, Digidem Lab and ABF Göteborg, we are planning a long term project starting next year together with Sweden’s Local Municipalities, the Green Party, The National Council of Swedish Youth Organisations, Young People with Disabilities and Young Media. The project will research new ways for young people to get involved with digital democratic processes.

What we have seen in the run up to this project is that there is a demand for new technology, both in municipalities, parties and NGO:s. But also an urgent need for concrete examples of implementation, cost efficient solutions and practical guidance. And we think that this also is true in an international context.

Digidem Guide, the project that we will develop during this workshop, is an app guiding organisations to the digital tools that meet their specific needs for direct democratic participation via the Internet. The app will help organisations to find the right tools for digital democracy based on criteria like field of application, scope, need for security, technical knowledge and licensing.

The target group is decision makers in NGO:s, political parties and local municipalities. By developing it in an international context with all the valuable experiences from other team members, we will widen the reach to an international audience.

The project’s aim is to make existing tools available to a wider audience without technical knowledge or previous experience in the field. By broadening the user base we will also be able to get better feedback on the tools to help proceed the development further.

As a web strategist who has worked for NGO:s for about fifteen years, I know that it takes time to introduce new technologies and new ways of working. Having said that, there is often a willingness in organisations to find ways to get people involved and widen the reach of the organisation.

My experience is that usability is the key to succeeding in introducing new digital services. We need to be sure that the new tools and workflows that we introduce are as intuitive and user friendly as possible. To be honest, that is not always the case with open source applications. Therefore, to make the tools work for everyone, we need to involve people from all sorts of backgrounds and levels of technical experience who are willing to do user tests and evaluations, and help developers and designers in finding the right tools for the right task.

The development and design of the app will be focused on early user testing with the whole team, and I would therefore very much welcome the participation of activists, politicians and NGO representatives in the process.

The development of the app will kick off with an the initial workshop where we share ideas and visions for the project, after which we will all start researching and collecting tools to document in the app.

As I said earlier, focus then will be on creating an early prototype, with open source app frameworks, that can be tested by the whole team. We will prioritise the three most important improvements, and work on them until the next iteration of user testing and development. The process will be repeated three times, while we will also integrate a shiny user interface and a user friendly back-end for adding content. After that, we will be ready to launch the app as a web interface and eventually an Android and iPhone app!

I am very much looking forward to this workshop, as an opportunity to combine experiences from Sweden and the Spanish and international community, and to find ways of networking and collaborating on an international scale.

Modular and responsive design for Doctors Without Borders

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.

Writing better design briefs with User Stories

The thing about design briefs for web projects is that they can be very detailed and totally make sense for everyone, without being helpful at all for the developer. The briefs that I’ve read often describes features in too much detail, or is set on a specific solution for the design, without defining the actual user need or problem to be solved.

In comes User Stories, a really clever way to define exactly what the users need and why, without makes assumptions about how to make it happen.

User stories are written like this
As a <type of user>, I want <some goal> so that <some reason>.

For example
As a user I want to find contact information so that I can get in touch with the organisation.

I have found user stories really helpful, not only in cases of development, but also for design decisions. It is done in a language that the client can understand, and the developer or designer can interpret, without having to read between the lines.

Using Evidence Planning to develop new digital platforms for Friends of the Earth International

Friends of the Earth International (FoEI) came to me recently to develop a new digital platform, in a combined effort to replace an old intranet that no one was using, and finding ways of mobilising members to collaborate and take action.

With member organisation in 75 countries and around 5000 activist groups worldwide, there is clearly a challenge in finding the right tools for the task. I love matching the right digital tools for different tasks, but the big question is always ”will people use it?”. So the whole process will need to be thoroughly based on user needs and expectations in the organisation.

We decided early on to follow the United Nations backed Principles for Digital Development, as they set a framework that I believe most digital projects should follow, and gives both the client and developers a common understanding of the process.

We also narrowed down the scope to initially focus on a Minimal Viable Product (MVP), both in order to focus on the main objectives and maybe more importantly to be able to involve the stakeholders in testing and evaluation the product as early as possible.

I have worked with (my own take on) a method called Effect Mapping for years, and I find it invaluable for understanding the focus, user groups and user needs in a project. The downside of this and a lot of other methods is however that they only focus on the new product. There is always some old system in the background that we are looking to replace. And the limitations or advantages of that system will always effect the expectations for the new project.

Another limitation in only looking at the current project is missing how it is linked to other systems that the organisation use, and how it enhances or interacts with them.

Thanks to the Development Impact and You Toolkit by Nesta I found this awesome workshop exercise called Evidence Planning.
In a really basic template with five fields, you and the client go through what the Key focus of the project is; how it Enhances current systems; Re-uses stuff that is already in use; which tools to Replace and what the Limits of the project is.

This method can be used for a lot of other cases than digital systems, but I found it really useful to quickly get the full picture of where this project fits into the organisations workflow.

In the case of FoEI, we found that we need to enhance internal systems like an Odoo installation that holds lots of organisational data, and the external web that is recruiting new members. By being the middle ground between these two: not for office workers or complete newbies, but people inside the organisation who wants to get more active.

It will re-use and present all the activities that are happening in groups all over the world and give a chance to share all those stories. And the systems that it is looking to replace are the intranet and it’s document repository, and possibly systems for internal communication, like email lists.

Thanks to this I now have a better grasp of where this project fits in and what the expectations from the organisation might be.

Looking ahead, we will work with User Stories to get all the details about what we want to get out of this, or these, new platforms.