CKAN is an open source management system whose main goal is to provide a managed data-catalog-system for Open Data. It is mainly used by public institutions and governments. At Liip we use CKAN to mainly help governments to provide their data-catalog and publish data in an accessible fashion to the public. Part of our work is supporting data owners to get their data published in the required data-format. We’re doing this by providing interfaces and useable standards to enhance the user experience on the portal to make it easier to access, read and process the data.

Metadata-Catalog

Out of the box CKAN can be used to publish and manage different types of datasets. They can be clustered by organizations and topics. Each dataset can contain resources which themself consist of Files of different formats or links to other Data-Sources. The metadata-standard can be configured to represent the standard you need but the Plugin already includes a simple and useful Meta-Data-Standard that already can get you started. The data is saved into a Postgres-Database by default and is indexed using SOLR.

Powerful Action-API

CKAN ships with an API which can be used to browse through the metadata-catalog and create advanced queries on the metadata. With authorization the API can also be used to add, import and update data with straight-forward requests.

Cli-Commands

The standard also includes a range of Cli-Commands which can be used to process or execute different tasks. Those can be very useful, e.g. to manage, automate or schedule backend-jobs.

Preview

CKAN offers the functionality to configure a preview of a number of different file-types, such as tabular-data (e.g. CSV, XLS), Text-Data (e.g. TXT), Images or PDFs. That way interested citizens can get a quick overview into the data itself without having to download it first and having to use local Software to merely get an better idea on how the data looks.

Plugins

While CKAN itself acts as a CMS but for data, it really shines when making use of its extensibility and configure and develop it to your business needs and requirements. There is already a wide-ranging list of plugins that have been developed for CKAN, which covers a broad range of additional features or make it easier to adjust CKAN to fit your use cases and look and feel. A collection of most of the plugins can be found on CKAN-Extensions and on Github.

At Liip we also help maintaining a couple of CKAN's plugins. The most important ones that we use in production for our customers are:

ckanext-harvest

The ckanext-harvest-plugin offers the possibility to export and import data. First of all, it enables you to exchange data between Portals that both use CKAN.

Furthermore we use this plugin to harvest data in a regular manner from different data-sources. At opendata.swiss we use two different types of harvesters. Our DCAT-Harvester consumes XML-/RDF-endpoints in DCAT-AP Switzerland-Format which is enforced on the Swiss Portal.

The Geocat-Harvester consumes data from geocat.ch. As the data from geocat is in ISO-19139_che-Format (Swiss version of ISO-19139) the harvester converts the data to the DCAT-AP Switzerland format and imports it.

Another feature of this plugin we use, is our DCAT-AP endpoint, to allow other portals to harvest our data and also serves as an example to Organizations that want to build an export that can be harvested by us.

ckanext-datastore

The plugin ckanext-datastore stores the actual tabular data (opposing to 'just' the meta-data) in a seperate database. With it, we are able to offer an easy to use API on top of the CKAN-Standard-API to query the data and process it further. It provides basic functionalities on the resource-detail-page to display the data in simple graphs.

The datastore is the most interesting one for Data-Analysts, who want to build apps based on the data, or analyze the data on a deeper level. This is an API-example of the Freibäder-dataset on the portal of Statistik Stadt Zürich.

ckanext-showcase

We use ckanext-showcase to provide a platform for Data-Analysts by displaying what has been built, based on the data the portal is offering. There you can find a good overview on how the data can be viewed in meaningful ways as statistics or used as sources in narrated videos or even in apps for an easier everyday life. For example you can browse through the Showcases on the Portal of the City of Zurich.

ckanext-xloader

The ckanext-xloader is a fairly new plugin which we were able to adopt for the City of Zurich Portal. It enables us to automatically and asynchronously load data into the datastore to have the data available after it has been harvested.

CKAN Community

The CKAN-Core and also a number of its major plugins are maintained by the CKAN-Core-Team. The developers are spread around the globe, working partly in companies that run their own open-data portals. The community that contribute to CKAN and its Plugins is always open to developers that would like to help with suggestions, report issues or provide Pull-Requests on Github. It offers a strong community which helps beginners, no matter their background. The ckan-dev-Mailing-List provides help in developing CKAN and is the platform for discussions and ideas about CKAN, too.

Roadmap and most recent Features

Since the Major-Release 2.7 CKAN requires Redis to use a new system of asynchronous background jobs. This helps CKAN to be more performant and reliable. Just a few weeks ago the new Major-Release 2.8 was released. A lot of work on this release went into driving CKAN forward by updating to a newer Version of Bootstrap and also deprecating old features that were holding back CKAN's progress.

Another rather new feature is the datatables-feature for tabular data. Its intention is to help the data-owner to describe the actual data in more detail by describing the values and how they gathered or calculated.

In the Roadmap of CKAN are many interesting features ahead. One example is the development of the CKAN Data Explorer which is a base component of CKAN. It allows to converge data from any dataset in the DataStore of a CKAN instance to analyze it.

Conclusion

It is important to us to support the Open Data Movement as we see value in publishing governmental data to the public. CKAN helps us to support this cause by working with several Organizations to publish their data and consult our customers while we develop and improve their portals together.

Personally, I am happy to be a part of the CKAN-Community which has always been very helpful and supportive. The cause to help different Organizations to make their data public to the people and the respectful CKAN-Community make it a lot of fun to contribute to the code and also the community.

fenaco is an agricultural association with a concept dating back over a century and is owned by around 192 LANDI cooperatives and their over 42,000 members, 22,000 of whom are active Swiss farmers. Some of their best-known brands include drinks manufacturer RAMSEIER Suisse, meat processor Ernst Sutter, retailers Volg and LANDI, fertiliser supplier Landor, feed manufacturer UFA and energy supplier AGROLA. The aim of fenaco is to help farmers economically develop their businesses.

The company is celebrating its 25th birthday this year, an excellent reason to update its outdated online presence. A new company website was needed, but what would it look like – and what should it say?

The website project

The aim of the project was to achieve a simple, clearly structured appearance. The company’s website needed to be modern and attractive. The fenaco brand was to be strengthened without weakening the brands of the companies which are part of the association. These were the requirements with which we began the project. We had a clear aim, a short time frame and a modest budget.

Agile development methods and an active exchange with customers meant that the project could be implemented within a short period of time and for a relatively small budget. Two POs (product owners) worked to ensure that everything ran smoothly: fenaco’s PO recorded the requirements in the form of tickets in Jira, and Liip’s PO prioritised them in conjunction with the development team. Regular coordination and approval meetings in small groups were held for this purpose.

The website was developed using Drupal 8 to ensure a high level of flexibility and a modular structure. The design impresses with its simple colours, taken from fenaco’s corporate design, and its user-oriented menu navigation. The end results speak for themselves! We look forward to seeing how fenaco’s customers and stakeholders react.

Trust over control

We worked together to replace the outdated website and improve fenaco’s visibility without competing with the brands of its members, building on the trust placed in our collaboration and shared goals.

«Liip delivered on their promises – consulting on equal terms, strong project support, a high level of design skill, and a technically perfect solution – all on budget and on time, in what was a very pleasant collaboration. Thank you!»
Elias Loretan, Online and Social Media Manager at fenaco

«A precision landing with minimum effort thanks to a straightforward collaboration between Liip and fenaco» Daniel Frey, Liip PO

After each optimization I thought that I understood how the srcset and sizes attributes of the <img> tag works. But each time, I made some new findings about how these attributes really work and where I need to take care while implementing them. Since there are lots of things you should know before using srcset I thought it could be useful to summarize the most tricky parts in a blog post.

A short introduction

I think most of you already heard of responsive images and especially the srcset attribute. But to be on the same page I still would like to start with a short introduction about these two attributes:

srcset

The srcset attribute is listing different resolutions of the same image from which the browser chooses the best fitting image source before loading it.

Example: srcset="ninja-1000w.jpg 1000w, ninja-500w.jpg 500w, ..."

To calculate this, the browser assumes the image fills up the full viewport width (100vw) by default, which means it uses the full width of the browser.

sizes

To tell the browser how much space the image really needs on our viewport, we can use the sizes attribute. This attribute contains a comma separated list of one or more image widths for different viewport sizes.

Each entry is a combination of a media condition and a width. Both of these values are described in CSS pixels so we don't need to care about device pixel ratio for this. If the media condition is omitted it evaluates to true automatically (= fallback). The sizes attribute gets read from left to right. As soon as a media condition evaluates to true the width of this entry is used. So be sure to order your values correctly!

Example: sizes="(min-width: 1000px) 50vw, 100vw"

The example above tells the browser that if the viewport is at least 1000px wide the image fills 50% of the space. If the browser is smaller, the image uses 100% of the available width.

If we combine the above two examples in an <img> tag and request it with a (1x/non-retina) browser the result would be the following:

• Browser width: 500px -> Matching sizes width: 100vw -> Needed image size: 500w -> Chosen image: ninja-500w.jpg.
• Browser width: 900px -> Matching sizes width: 100vw -> Needed image size: 900w -> Chosen image: ninja-1000w.jpg.
• Browser width: 1000px -> Matching sizes width: 50vw -> Needed image size: 500w -> Chosen image: ninja-500w.jpg.

Sizes affect how the image is shown

The first thing which is important to know about the sizes attribute is that it isn't only used to calculate the needed size, it is used as the rendered width of the image if the width is not defined in CSS too.

This means as soon as you add the srcset attribute to the <img> element the image might be displayed differently.

The reason for that is when you add the srcset attribute and omit the sizes attribute, the browser uses the default value for it, which is 100vw.

Here's an example (https://codepen.io/tschortsch/pen/LeMmyO):

As you can see, the browser stretches the image always to the matching size in the sizes attribute, as long as the width is not defined in CSS.

This leads us to Rule #1: Always set the sizes attribute if you use srcset. If sizes is omitted it defaults to 100vw.

How the browser selects the needed image size

Short answer: We can't tell.

Long answer: Every browser has a slightly different implementation which can change with every version of the browser. This leads to Rule #2: Never assume which image size the browser will choose.

The browser just chooses the best matching image for the current size. But if the browser finds a cached version of an image from the current srcset which is bigger than the needed size it prioritizes the image from the cache for example.

This makes it really hard to debug a srcset. To avoid the loading of cached files you should always debug srcsets in your browsers privacy mode.

As a result of this, it is possible that you have two exact same devices (same screen and browser size) but you get a different image size in both browsers.

Another really important takeaway from this brings us to Rule #3: A srcset should only contain images of the same ratio.

Since you can't really decide which image is loaded in which browser size you can't use srcset to serve different images on different sizes a.k.a. art direction (eg. 1:1 image on smaller devices, 2:1 image on larger devices). If you would like to do this you should use the <picture> element.

Pitfalls of the width ('w') descriptor

The width (w) descriptor of the srcset attribute has also some things which should be taken care of. First of all Rule #4: The width (w) descriptor should always match the images natural width. This means if the image has a width of 500px the width (w) descriptor should be exactly 500w. This sounds pretty easy to achieve but there are use cases where this isn't as easy.

Think of the following example: You load your images through a CDN, where you predefine all the sizes that should exist of an uploaded image. In the template you define a srcset with all of those predefined sizes. If you do not enable upscaling (on CDN side) and upload an image which is smaller than the biggest defined size, you will get an image which doesn't fit the width (w) descriptor in your template.

If this is the case you can get unexpected results. Let's look at this example (https://codepen.io/tschortsch/pen/rpoXvW / The problem in the example only occurs with screens that have a DPR >= 2):

If you don't have a display that has a DPR >= 2 here's a screenshot of what would happen if you had:

What is showed in the example above? As long as we don't define a CSS width, the image (which is originally 400px wide) doesn't fill up a container which is only 300px wide.

Let me explain what's happening here: We have an image container which is 300px wide. The image has a srcset with two possible image sizes: 300w, 600w. The 300w image has a natural width of 300px (correct). But since the original image has a width of 400px the 600w doesn't return an image which is 600px wide but the original 400px image (wrong).

If this container gets loaded with a DPR >= 2 the browser requests the 600w image (2 * 300px). Since the browser doesn't know that the image behind this descriptor is smaller than 600px it displays it as it would be that size. This means it gets squeezed to half of its size (400px / 2 = 200px). And that's why we end up with this strange situation that the image (which is originally 400px wide) doesn't fill the whole 300px image container.

When we enforce the image width in CSS, like we do in the 2nd example, the (400px) image gets stretched again to fill the 300px container and everything looks like expected.

And here we are with the Rule #5: Always enforce the image size in CSS when using srcset.

Wrap up

As you see responsive images have some parts, you should know when implementing them. Let's quickly go through our rules again:

• Rule #1: Always set the sizes attribute if you use srcset. If sizes is omitted it defaults to 100vw. Since the sizes attribute has an influence on how the image is displayed, it should never be omitted. If you do so, the browser uses the default value of 100vw.
• Rule #2: Never assume which image size the browser will choose. The reason for this is, that all browsers have slightly different implementation on how the correct image from a srcset is chosen. This implementation should be a black box for us, because it can change with every update.
• Rule #3: A srcset should only contain images of the same ratio. As a result of rule #2 we never know which image is loaded by the browser. To get the same result for all visitors every image in the srcset needs the same ratio.
• Rule #4: The width (w) descriptor should always match the images real width. The browser uses the width (w) descriptor to calculate how it should display the image. If it doesn't match the real width, we can get unexpected behaviour.
• Rule #5: Always enforce the image size in CSS when using srcset. Since there are some use cases where rule #4 can't be achieved, we should always enforce the width of an image in CSS.

Further resources

There are some really good resources to learn more about responsive images:

• Responsive images on Mozilla Developer Network: https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images
• Responsive images on CSS-Tricks: https://css-tricks.com/responsive-images-youre-just-changing-resolutions-use-srcset/
• Very nicely done introduction about srcset and sizes: http://ericportis.com/posts/2014/srcset-sizes/
• <img> Element documentation: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img

What is OctoberCMS?

WordPress is based on simplicity - everything is a post, which makes it easy to use for content authors and developers. Thanks to this concept, (nearly) all backend forms look consistent which helps content authors a lot. But this simplicity makes it harder for developers to create backends for more complex content.

This is where OctoberCMS jumps in. It is a great mix of a file based and database driven CMS. Everything which is more or less static (like pages, menus and templates) is saved as files. Like this the content can be served really fast. However you can of course edit these entities directly through the backend.

Everything which is more dynamic and more complex (like events, news or blogposts) is stored in custom tables in the database. Thanks to this you will have full freedom on how to create your own types.

Complexity doesn't matter

With this strategy OctoberCMS can be used for simple websites as well as for really complex ones. When using it for simple websites, the user experience of the backend can be compared to the one of WordPress. It is easy to use and looks consistent. On top of that it adds some useful features for power users, like editing multiple content elements in tabs or keyboard shortcut. The most useful one is saving data with CMD+S / CTRL+S. I'm already at a point where I find myself trying to save blogposts in WordPress with this key combination (which doesn't work sadly).

When using it for a more complex website you'll get full freedom on what to use OctoberCMS for. You can easily use it as a headless CMS for any sort of web application. To help you with this, the backend gives you a base structure for list views and form views for each model. If required you can modify these templates to fit your own needs. The provided form widgets helps creating consistent backend forms for almost every use case. If needed you can create your own form widgets without any hassle. This means the backend is highly customizable which improves the usability when editing complex content extremely.

Still not convinced?

Let's look at some more, great reasons why you should consider OctoberCMS for your next website:

• Based on Laravel: OctoberCMS is based on the Laravel framework (which is based on Symfony. It builds a really solid foundation for the core, plugins and themes.
• Clean code: By using the Laravel framework there is clear coding style definition which helps your code base to stay clean.
• Open Source: The whole OctoberCMS project is hosted as open source software on GitHub which is a really important thing to build a big user community around.
• Easy to extend: OctoberCMS is built for extensibility. The best example for that is that even the most basic features, like creating and editing pages, are provided via a plugin and are not hardcoded in the core.
• Database query building with Eloquent: For database query building Laravel has Eloquent ORM integrated. With this you can easily create database queries which fits your needs.
• Database migrations: The whole OctoberCMS setup (core and plugins) is based on database migrations. This helps keeping the database consistent when installing or updating plugins or the core. With this mechanism you can easily rollback to an older version if something doesn't work as expected.
• Event driven: The whole setup is event driven which enables you hook into core or plugin processes and extend them easily.
• Twig templates: OctoberCMS uses twig as templating engine. This makes it possible to completely separate your data from the templates.
• Integrated assets pipeline: OctoberCMS comes with a twig based assets pipeline to compile and minify your CSS (support for Sass & Less) and JS files. All you need to do is including your source files directly in your twig templates and they get compiled, minified and cached automatically when calling the website the first time. If you have more complex requirements Laravel provides an abstraction layer above webpack called Laravel Mix which makes the creating of webpack based build tasks easy.

The bad parts

Not everything can be nice and shiny. So here we go with the imperfect or missing parts of OctoberCMS:

Core bugs

First of all since this is a rather new CMS project (compared to other big players on the market) you might find some more or less "simple" core bugs while implementing a complex backend feature. This can be annoying, but since the community is very active (on Slack or on GitHub) you will get help quickly.

i18n

Another important topic is i18n: OctoberCMS provides an implementation for translating content as a plugin. With it you are able to translate most of your content from a base language to other languages which works fine.

But since you always need your content to exist in a base language you are limited to only translating your website and not doing real i18n stuff like different content in different languages. The good thing about this is that the folks behind this plugin are working on that feature right now and since the plugin is hosted on GitHub you can help if you want.

That's all folks

We're really looking forward to build a lot more websites with OctoberCMS. And if you are a web developer you should really consider it when planning your next CMS project.

Your Website is not Responsive

That's usually one of the key indicators for you to think about a website redesign. Did you know that on an average day 80% of internet users use a smartphone to surf the web? That's almost 15% more mobile than desktop usage. Mobile first is thus not just a buzzword, it is a reality that is being confirmed on a statistical basis every day. [1]

Your Website Loads too Slowly

We've all had experiences with slow websites. They're pretty annoying and not fun to use. Actually, 40% of a website's users will leave a page if it takes more than three seconds for it to load? Also, data shows this is bad on a computer but on a mobile device it is even worse. Consider this: Key engagement metrics such as average time on site, pages per visit, or bounce rate already lag behind on smartphone usage. If it now also takes longer to load, you can be almost certain to lose your valuable visits and your conversion rate will take a hit. [2]

You Are Experiencing a High Bounce Rate

That's certainly not a good sign and you should definitely do something about it. Essentially, what it means is that you manage to get people to visit your website and they immediately decide to leave again. That's pretty bad, right? Well, the good news is: if you do collect your data well the internet will also give you some answers about what to improve. It does not necessarily tell you to redo everything but you will have some strong arguments up your sleeve on where to invest your budget next and why. In case you're missing that valuable information, I would strongly advise you to consult with an analytics expert. He will then also know, if a redesign could be an option for you to consider. [3]

You Have Expensive License Costs From a Closed Source Provider

If you do use closed source software, you know what I am talking about: such a model comes attached with expensive license costs. And that's just the cost for you to be able to use the software, development for your system will additionally strain your budget. With open source systems such as Drupal, that's for free – no strings attached. Just like with a closed source system you will also get an incredibly powerful system, enterprise-ready security standards and the help of a community with thousands of developers. It's pretty simple math: add the cost of your closed source system over the years and start investing it in software that will more efficiently generate business value for you.

Your Current Website Setup Is Hard and Expensive to Maintain

It's absolutely normal that your content structure and the requirements towards its digital representation changes over time. As your business advances so will your core digital tools and therefore the requirements to connect their data pools to your business' online representation via clever interfaces. If you spend too little time cultivating and evolving your system this process will even speed up. In such situations, this often results in steep investments towards an old system or it will be getting more difficult to add the right content where, how and when it needs to be there for your online customer. Most definitely, that's just one symptom that is then supplemented by the frustrating experience for your administrators that cultivate your platform – no wonder that content quality will suffer. Does this sound familiar? Then a redesign might be the way out of this vicious cycle.

There are certainly many other influencing factors that might trigger you to think about redesigning your website. In my experience and in almost any case, it boils down to the question of what your online customers are expecting from you as well as from your online business. If you do understand them well this can much more easily be translated in technical and visual requirements. In turn, you get to better understand the ROI and the question of when and if to redesign your website can be answered much more reliably.

If you do find yourself in a position where two or more of the above situations are a match, I would strongly suggest you to bring together your key stakeholders to a roundtable and define a strategy to tackle this situation. It's as simple as that, there is no second chance for the first impression.

[1] storage.googleapis.com/think/docs/twg-how-people-use-their-devices-2016.pdf

[2] thinkwithgoogle.com/articles/mobile-page-speed-load-time.html

[3] thinkwithgoogle.com/interviews/winning-the-zero-moment-of-truth-measure-success.html

Brave new web

The dawn of the Web 2.0 era has seen the uprise of many new and highly interactive elements of what make today's internet: rich internet applications, user generated content and social networks just to name a few. Along with these came a higher sensitivity to the users needs. This led to UX Design entering the realm of the web as the response to the increased demand to professionally tackle the issue of shaping customer and user experience.

In the first decade of the browser based internet (1993-2003) professional UX Design was only rarely a part of the standard commission and development process.

Introducing UX design to projects has brought along a shift in focus. Ever since UX experts have been involved in the development of sites and applications they saw themselves confronted with the problem of not being integrated well in the development process. The traditional participants of the process seem to tenaciously ignore their points of view and all the explaining of the importance of UX concepts for the success of a project doesn't seem to change that. However it would be negligent to reduce this to the lack of knowledge about UX or even to the lacking will by the participants to learn about UX.

Every project is a process that extensively involves decision making. In order to be successful this presupposes mutual acceptance of the participants, an acceptance that is heavily depending on expressing and meeting expectations.

This paper shows the dynamics of collaborative design as a process of extensive decision making  and defines criteria that are relevant for the acceptance of UX in a development process.

From Collaboration to Collaborative Design

In short collaboration is the successful sharing of a working environment in a joint effort to accomplish a task. Good collaboration allows the free flow of information and an awareness of when and how the stakeholders participate in the collaboration.

Collaborative design expands this concept. It is distinct because it points at the creation of an artefact as a more complex form of accomplishing a task:

Collaborative Design takes place whenever an artefact is planned and/or implemented by two or more participants.

The term design is not restricted to graphic representations, but has to be understood in a wider sense: as the act of giving form to a structure or object. In some typical collaborative design areas like architecture, software development or movie making the creation of the artefact involves the design of high variety of interdependent elements and the contribution of different departments that have to agree on a single design.

Collaborative design is the inevitable process that emerges when something is built by a team. It is not a consciously chosen process like User Centred Design or Test Driven Development. Collaborative design is an inherent part of a project, it just happens. Even if the project is between a one-person company and a one-person client it involves collaborative design.

The Structure of Collaborative Design

The process of collaborative design involves a network of participants and is shaped by the interactions of these participants. Each participant is able to propose solutions for design issues. The goal of any collaborative design is a product with an optimum of utility:

Some designs are better than others. We can in principle assign a utility value to each design and thereby define a utility function that represents the utility for every point in the design space (though in practice we may only be able to assess comparative as opposed to absolute utility values)[…]

The goal of the design process can thus be viewed as trying to find the design with the optimal (maximal) utility value, though often optimality is abandoned in favor of ‘good enough'. (Klein et al. p. 203)

Each project typically has participants in different concurring entities or divisions with very distinct tasks. In order to fulfil these tasks decisions have to be taken, some of which may have a negative effect on the fulfilment of an other participant's tasks: Every participant is driven by self-interest that bears the risk of favouring the fulfilment of the personal task over the achievement of a common goal.

A simple example with three participants: a customer, a developer and a designer. As a customer I want the product to be affordable and yet magic. As a developer I want the product to be solid, stable and performing. As a designer I want the product to be highly functional and visually appealing. So each of these participants has a very distinguished personal task that determines self-interest. Fulfilling this self-interest means being good at the task assigned within the project. This however does not mean serving the project in the best of possible ways. Fulfilling the self-interest means reaching a local optimum of utility, an optimum thus only valid in the realm of the task assigned.

The decisions that may be made by each participant for the fulfilment of tasks in a project are highly inter-dependent. Typical inter-dependencies may involve access to shared data, research results or infrastructure. These inter-dependencies make the radical pursuit of the fulfilment of self-interest both harmful to the achievement of the common goal and almost impossible to accomplish. It is harmful because ignoring the dependency of a participant leads to the failure of the other participant. It is difficult to accomplish because inter-dependencies are mutual: no participant is completely independent from others. Hence: Participants must be willing to compromise their self-interest for the sake of a global optimum.

Adding Complexity

The larger the projects the higher the level of complexity. With a high number of participants the system can become non-transparent because it is hard to keep track of the interactions and design decisions.

Further complexity is added when not only the number of participants but also the number of companies involved increases. This additional layer is especially complex due to the variety of possible constellations between companies. Companies involved can be competitors, subcontractors, partner-companies.

An increased number of participants can favour the emersion of subsystems consisting of a few participants with similar tasks. These subsystems also have a local optimum utility plus their participants are loyal to each other.

Every new participant brings a different set of expertise to tackle a task and therefore establishes an own local optimum and a specific self-interest. This brings along a shift in the overall utility. The project however could fail if old participants refuse to accept a new participant. If the old participants are unwilling to compromise their self-interest in order to allow the new participant to contribute to the project, the overall utility will not be reached.

Acceptance

Before UX experts were engaged in the creation of applications and sites, developers took themselves as users and modelled processes according to their needs instead of the user's.

UX expertise brought and is still bringing a paradigm shift by putting the user in the centre of development efforts. This means that there is a shift of what the optimum utility is made of, not only as far as a single project is concerned. This applies to a whole industry. This change is not happening without considerable problems, the main effect being that UX concepts are not implemented and become paper waste on the moment they are put into the hands of the developers.

Both contracting developers and executing participants involved on the client's side (e.g. system engineers, data-administrators) show only little or hesitant acceptance towards the new paradigm.

In addition before UX engagement the responsibility for the utility of a design was not clearly assigned but diffused among the participants. UX experts took up this responsibility explicitly.

The key to acceptance is understanding. In order to build truly active commitment overcoming passive tolerance or even rejection, it is important to raise awareness of the dynamics mentioned before. However is also important to understand why the developers are so reluctant to reject idea of them as users and why they hesitate in embracing the paradigm of user centricity. Two aspects seem worth exploring: the role of measurability and objectivity and the role of expectation management.

Measurability and Objectivity

Since an application's utility was not anyone's explicit responsibility prior to UX experts being involved, utility did not figure as a criteria for quality assertion. If quality assertions for utility would happen at all, they only did in the context of usability tests after the main development phase, but not as a part of the conceptual phase.

A list of elements for quality assertion includes:

• Performance (computing speed, interface response)
• Drain on resources (bandwidth, disk-space, file-size)
• Implementation standards (normalisation, unit/functional testing, validation)
• Deficiency (incomplete or faulty implementation)
• Duration, cost (on time, on budget)
• Utility (relevance of information, ease of task completion)

There is an important difference between utility and all the other elements of the list: The assertions of the other elements can be done by the participants themselves. The measurability is higher because scale is not an issue: it is not difficult to measure response time or bandwidth consumption. The scales are based on absolute figures, easy to read and interpret. Utility, on the other hand, needs a process involving users to be asserted. It's findings are hard to read and difficult to interpret. Patterns arising from the findings are obscure to participants alien to UX.

Another reasoning that is important in respect to the false assumption that developers are apt to assert utility, is that in the case of utility the user is the only valid measuring instrument. Evidently it is bad advice being tester and testee (or, to be accurate, the measuring instrument) at the same time.  Simultaneously being tester and testee deprives the developer from objectivity. Objectivity is only possible if the results do not depend on the tester, which in the case of the developer being the tester   is not possible. Only measurements based on objectivity lead to reliability and validity.

Expectation Management

One aspect of tackling the lack of acceptance is expectation management. Unexperienced participants know little of what they can expect from UX experts and what expectations these experts have. Expectation management is an essential task both of project management and participants alike. “[…] it is important to continuously manage stakeholder expectations. In other words, regularly communicate and meet with these parties to understand their expectations, candidly identify what each stakeholder can and cannot do.” (Spafford, 2009)

Despite the very heterogenous expectations there are two obvious demands that UX experts have to answer to in order to maintain credibility: device proficiency and completeness of information.

UX experts must be aware and proficient of the device they conceive an interaction-concept for. They must be familiar with the conventions of use on the device as well as its limitations. This is especially true for internet applications due to the fact that the interpreting “devices” are the variety of very heterogenous browsers, be they for desktop or mobile platforms.

One example for this is how printing is handled in the browser. Printing can be triggered in several ways and not all can be intercepted by the page's javascript in order to do optimization form printing. If printing is a key element for task completion, developers expect that the interaction patterns proposed by the UX expert take this in consideration.

One further demand is for completeness and consistency of the information architecture proposed by UX experts. There is a clear division between who determines the architecture and who implements it. Incomplete concepts pave the way for arbitrariness. Missing information that has to be assumed by the developer means asserted utility that is lost.

This means that developers to some extent need methodological guidance. As Rönkkö points out developers become highly engaged in design tasks during implementations, a fact that lead to the appearance the concept of Personas:

[…] developers became heavily engaged in design tasks and often had strong opinions and made suggestions for changes in initial design. Arguments arose between developers and interaction designers concerning the best way to present functionality in the interface. The Interaction designers often had to confront developers with such questions as – from whose perspective do you put forwards claims? Is your opinion a fair representation of the user's opinions? (Interaction designer) The fact that their opinions might not be the same as the target groups was raised. The ID team wanted to remain faithful to the developers' good intentions, their creativity and questioning, but direct it towards a shared user understanding outside their own personal opinions.  (Rönkkö, p. 195)

Raising Acceptance

Successful Collaborative Design is based on the commitment of each participants to achieve an optimum of overall utility. Successful acceptance is based on reciprocal understanding of each others standards and expectations. This understanding can be reached through clear negotiation and can heavily benefit from alliances established by shared experiences and common achievements.  It is essential to make an effort to overcome barriers that separate companies in order to enhance the forming of interdisciplinary teams. Common workflows based on high iteration with frequent synchronisation should be stressed as well as the elaboration of interdisciplinary patterns. These patterns can include project based interface and interaction conventions but also address general collaboration issues like workflow definitions, role assignments or documentation patterns.

                        __

Watch the Slides

Read the most important points of this essay summarized as a slideshow.

Embracing Collaborative Design

References

Klein, Mark , Peyman Faratin, Yaneer Bar-Yam and Hiroki Sayama. “The Dynamics of Collaborative Design: Insights From Complex Systems and Negotiation Research” Concurrent Engineering, Vol. 11, No. 3, 201-209, 2003. Print.

Spafford, George . “Active Expectation Management” Web. 29. Nov 2009 http://itmanagement.earthweb.com/columns/article.php/2246881

Rönkko, Kari . “Making Methods Work in Software Engineering Method Deployment – as a Social Achievement”. Karlskrona, Sweden: Blekinge Institute of Technology,  2005.  Doctoral Dissertation Series No. 2005:04. Print.