Liip Blog https://www.liip.ch/en/blog Kirby Tue, 16 Jan 2018 00:00:00 +0100 Latest articles from the Liip Blog en Dear SaaS vendors http://feeds.liip.ch/~r/liip_blog/~3/-2K17WXIKgM/dear-saas-vendors https://www.liip.ch/en/blog/dear-saas-vendors Tue, 16 Jan 2018 00:00:00 +0100 <p>One of the several holacracy roles I have at Liip is called “Platform Gardener”. The purpose is defined as “provide corporate-wide streamlined digital services and tools”, which boils down to managing most of our SaaS and other software purchases. That being said, in true Liip style my job isn’t telling people what they can or cannot have but more to help them find the right tool, right licensing, finding synergies and help negotiating deals. As such I obviously deal with a lot of SaaS vendors like you and yes there are a lot of useful tools that you provide with awesome functionality. But beyond the core functionality I am quite disappointed with how little you SaaS vendors seem to care about making integration of your tools into company processes easy. So here is a list of the top things I would like you to work on:</p> <ol> <li> <p>Usage based licensing. Slack and <a href="https://rokka.io">Rokka.io</a> are very good examples. If you have a good product people will use it more and more. If you make me choose a number of seats without automatically refunding me for unused seats (Slack does this), then I will artificially limit adoption simply because adding a seat is a deliberate step that takes effort.</p> </li> <li> <p>Semi-related some of you require yearly licenses. Sure give me the option if you want to give me a discount, but in an agency where the average project lasts between 3 to 6 months it's often not practical to get a yearly license.</p> </li> <li> <p>Lack of PDF invoices is a pretty obvious and easy to fix issue, which goes hand in hand with automatic sending invoices by email to a configurable email address. That last bit is important since we track our costs via <a href="http://www.cleanshelf.com/">cleanshelf.com</a>.</p> </li> <li> <p>Speaking of <a href="http://www.cleanshelf.com/">cleanshelf.com</a> what would be even better is if you would provide a way to extract billing data without having to create paid user account. Obviously such accounts should specifically not have access to any data other than billing data. Ideally via an API but well <a href="http://www.cleanshelf.com/">cleanshelf.com</a> can also screen-scrape.</p> </li> <li> <p>Another mind boggling omission by many of you is, especially those that are part of actual production infrastructure for clients, is the total lack of configuration management. We used to laugh at Microsoft for requiring us to pass around screenshots to configure their server tools. Yet most SaaS tools support no versioning of configuration, let alone export. Meaning its impossible to keep configuration between testing and production in sync. If one of you would ever lose your config you would start from scratch. It also means that if you adds/removes/changes configuration options there is no structured way to communicate this to the user. So right now I have to document with screenshots which can become outdated without my control with the next minor layout update or feature change from one of you.</p> </li> <li> <p>Which brings to the next topic, most of you do not let me test out new features before you move them to production. I understand maintaining two versions is annoying and I am ok with there only being a specific time window. But every new release can have implications that I rather wish to be able to prepare for. Heck we might have done workarounds for previous bugs or limitations that we need to first remove.</p> </li> <li> <p>A rather small wish, let me add some notes to each service within your tool. Like which team for which project is using said service until when so that I have a clue when I login what is going on. Sketch also does a weird thing where they just register machine names for license seats. So I now have to know the machine names of everyone when I off board an employee. Maintaining this information outside of the SaaS tool is painful and error prone since it is never in sync. In my dream world billing would also allow me to easily group the costs according to projects.</p> </li> <li>The last wish is the ability to export all relevant data from the account. Right now its close to impossible to move once we have adopted one of you simply because there is still data in there which is needed for a few active projects or project where the client could come back with another development push. Then again if my usage based licensing wish from above is implemented then this is much less of an issue. If you must, charge me for storage, but this way we can just stop using the tool for a while without having a huge hassle with licensing.</li> </ol> <p>What is maybe overall the most frustrating thing is it feels a bit like the only incentive for any of you to not try to get me to over-license and lock me into your service is if laws would exist that require you comply with the above wish list. This is especially relevant for the last item. Laws would of course stifle innovation and likely end up hurting especially smaller SaaS tools just starting out. But maybe what it needed is a to create some sort of index with the above points and some more to be able to compare these things more easily. This might help to create some economic pressure on you if consumers start ignoring SaaS vendors that like to skim by with lock-in and in-transparency. Here is hoping that enough if you will realize that thinking about the needs the organizations of your users is a competitive advantage.</p><img src="http://feeds.feedburner.com/~r/liip_blog/~4/-2K17WXIKgM" height="1" width="1" alt=""/> https://www.liip.ch/en/blog/dear-saas-vendors Helvetia Web Relaunch http://feeds.liip.ch/~r/liip_blog/~3/Nz_-odNABE4/helvetia-web-relaunch https://www.liip.ch/en/blog/helvetia-web-relaunch Mon, 15 Jan 2018 00:00:00 +0100 <p><strong>Benutzerzentrierung als Leitsatz </strong><br /> Die Kunden ins Zentrum stellen - das war der Fokus mehrerer Web-Projekte bei Helvetia. In einem gemeinsamen Helvetia-Liip-Team standen die Umsetzung der anspruchsvollen funktionalen Teile von www.helvetia.ch im Zentrum: die Versicherungsrechner.<br /> Von der Privatkundenversicherung (Hausrat, Haftpflicht, Assistance, Rechtsschutz)- über die Mietkautions- bis hin zur Tier- und Eventversicherung bieten die Online-Rechner eine genaue Kalkulation der Prämie und darauf basierend gleich den nächsten Schritt: den Versicherungsabschluss.<br /> Mit einem “User Centered”-Ansatz wurden die Rechner schrittweise konzipiert, umgesetzt und mit Usability Tests geprüft.</p> <p><strong>Mehr Effizienz bei der Bearbeitung</strong><br /> Abschlüsse der umfangreicheren Rechner führen direkt zu einem Abschluss im Versicherungssystem und dadurch zu einer Arbeitsentlastung der Mitarbeitenden von Helvetia. Auch findet vor dem Abschluss eine automatische Bonitätsprüfung statt. Die Versicherungskunden können rund um die Uhr Versicherungen abschliessen und gleichzeitig wurde der administrative Aufwand minimiert. </p> <p><strong>Neueste Technologie</strong><br /> Mit Angular 4 wurden neuste Technologien eingesetzt und das Produkt auf den aktuellen Stand gebracht. Um inskünftig bereits während der Entwicklung, aber auch im Betrieb die hohe Qualität sicherzustellen, fand parallel zur Umsetzung die Implementierung einer Testautomatisierung mit Angular 4 statt.<br /> Als Basis für die Komponenten wurde die von Namics erstellte Pattern Library genutzt.</p> <p><strong>Mit einem Team zum Erfolg</strong><br /> Gemeinsam und agil ans Ziel war der Fokus der Zusammenarbeit. Helvetia und Liip arbeiteten zusammen in einem Scrum-Team, in dem die Firmenzugehörigkeit weniger wichtig war, als die Skills der einzelnen Personen. Es wurde gemeinsam am Projekterfolg gearbeitet. So ergab sich aus den ersten paar Monaten eine über ein Jahr dauernden Zusammenarbeit. Wir danken Helvetia für die sehr angenehme und unkomplizierte Zusammenarbeit!</p> <p>Berechnung Privatkundenversicherung: <a href="https://www.helvetia.com/ch/web/de/privatkunden/wohnen-und-eigentum/wohnen/hausratversicherung/praemie-berechnen.html/offer">https://www.helvetia.com/ch/web/de/privatkunden/wohnen-und-eigentum/wohnen/hausratversicherung/praemie-berechnen.html/offer</a></p><img src="http://feeds.feedburner.com/~r/liip_blog/~4/Nz_-odNABE4" height="1" width="1" alt=""/> https://www.liip.ch/en/blog/helvetia-web-relaunch Why New Year’s Resolutions Are Doomed, And How To Handle Them Differently http://feeds.liip.ch/~r/liip_blog/~3/cyHRp2N9Pmo/why-new-year-s-resolutions-are-doomed-and-how-to-handle-them-differently https://www.liip.ch/en/blog/why-new-year-s-resolutions-are-doomed-and-how-to-handle-them-differently Thu, 11 Jan 2018 00:00:00 +0100 <h3>FROM ONE YEAR</h3> <p>365 days. 12 months. 52 weeks. We all have the same amount of time, so how is it possible that only a few of us achieve our new year’s promises?</p> <p>The main reason is that one calendar year is a way too distant and unclear horizon to be forecasted. Plus, the world is complex now and despite all the energy we spend on making things happen, most of the things we wish for are not entirely under our control.</p> <p>We try but most of the time we fail, and we will try again next year.</p> <h2>ADJUST &amp; SHORTEN THE FOCUS</h2> <p>A better way to operate would be to pursue them on a monthly basis. Because we can sense the time we have until the end of the month, it is already way easier to estimate and engage ourselves to execute.</p> <p>Also, let’s not mix them up with commitment, which is about our attitude to do our best despite all the challenges sent by the complexity around us. Because yes, unexpected things will happen for sure!</p> <p>We cannot commit to a date or a result, only to our own behavior.</p> <h3>TO ONE MONTH</h3> <p>4 weeks. 28 days. Now we can visualize a few days ahead and put habits in place a one month timebox.</p> <p>We can even plan it and reflect at the end (are the goals still relevant?). And then we relaunch new adjusted month’s objectives.</p> <p><br /></p> <p>That way, yearly unattainable resolutions turn into graspable goals. Updated and checked one after the other, and sustained by a resilient mindset, we will achieve them without even noticing it.</p> <h4>So, what are your goals for January 2018?</h4> <p><br /></p> <hr /> <p><em>You would like to know more about the mindset, values and practices to become more agile?<br /> <strong>Join the <a href="https://www.meetup.com/AgileZurichMeetup/">Agile Zürich</a> community</strong> and participate in the discussions on <a href="https://twitter.com/AgileZurich">Twitter</a> with the hashtag <a href="https://twitter.com/hashtag/agilezurich">#agilezurich</a>.</em></p><img src="http://feeds.feedburner.com/~r/liip_blog/~4/cyHRp2N9Pmo" height="1" width="1" alt=""/> https://www.liip.ch/en/blog/why-new-year-s-resolutions-are-doomed-and-how-to-handle-them-differently How we want to change feedback culture at Liip http://feeds.liip.ch/~r/liip_blog/~3/GElS43TS2no/how-we-want-to-change-feedback-culture-at-liip https://www.liip.ch/en/blog/how-we-want-to-change-feedback-culture-at-liip Wed, 20 Dec 2017 00:00:00 +0100 <p><strong>That valuable but painful thing called feedback</strong><br /> We all know feedback is helpful. Employees want it and organisations depend on it so that people can grow, make progress and feel engaged. But still we resist it so often and it seems so incredibly difficult to give and take it.<br /> Employees at Liip get feedback from their peers once a year and have time to discuss the results and their goals. Many of them wish for more regular feedback to make progress in a faster pace. They miss both critique and compliments alike.<br /> At the same time they told me, they find it difficult to give meaningful feedback, to find the right words and that they fear to hurt others with critique. For most of us, feedback is awkward, uncomfortable and sometimes painful. </p> <p><strong>What if we took more time to develop others and work on our own goals?</strong><br /> A small team (Christian Stocker, Christina Henkel and me) started to change the feedback culture at Liip. Our motivation is that Liipers take more time to encourage and support each other to make progress. Professionally but also personally. That they take more time to work on their own goals. We hope for more motivation and pride, better quality and less fuck ups.</p> <p><strong>We asked for pioneers in a pilot project</strong><br /> We drafted a pilot and asked in the whole company for pioneers who are willing to spend 30min per week giving and getting feedback. We asked them to work on the following topics for the next 3-4 month.</p> <p><strong>Find a way to take time</strong><br /> Most of us have busy days. Client work has usually higher priority. It is difficult to take time to work on own goals and develop others.<br /> We suggested to specifically plan time in your calendar to give feedback to others. First thing in the morning, before all the other tasks hit you.<br /> To work on your own goals, find a mentor in the company. Somebody who discusses the topic with you, challenges you and just offers her perspective.</p> <p><strong>Get better in giving and accepting feedback</strong><br /> Feedback is a skill and most of us probably lack know how and experience. To gain more knowledge we offered some video and reading material (<a href="https://www.youtube.com/watch?v=VWc53-NdLBA">Clean feedback</a>, <a href="https://www.youtube.com/watch?v=4yODalLQ2lM">Radical candor</a>, <a href="https://www.quantumworkplace.com/practical-guide-to-giving-receiving-employee-feedback">Practical guide to employee feedback</a>).<br /> In addition we organised the external coach Marion Walz to give an introduction about how to give feedback and deal with challenges that come with it.</p> <p><strong>Do we need additional infrastructure?</strong><br /> <a href="http://www.leapsome.com">Leapsome</a> is a tool that lets people give and request feedback from other employees all over the company. It lets people define goals and view their progress.<br /> We test Leapsome in our pilot to understand if we need additional infrastructure or if we can go with what we have.</p> <p><strong>Is it worth to invest more time into feedback culture?</strong><br /> To understand if the pilot is of any value for the participants, we collect their feedback regularly and ask them about the progress they make. At the end of the pilot we will decide if we continue investing time. The tough question will be, what exactly we could do in the future, to improve feedback culture even further. During the pilot, we will develop and test prototypes (this could be a digital solution on screen, a service or even a physical space or a product) to understand what works best for our participants and employees.</p> <p><strong>It was a already a long way until here</strong><br /> Before we came up with this pilot, we went through different rounds of collecting ideas and sketching solutions (thanks for the great work Marlene Stroj-Rullo, as well as help and support from Laurent Prodon and Thomas Riotte). Not everything worked as we planned and imagined. Some of the prototypes did not come to life, others had only little impact. Very often complexity hit us and left us disencouraged. It helped me to ask “what is the smallest step we can take towards our goal?” instead of solving the whole problem at once.<br /> I also learned to evaluate ideas more carefully. In the early projects I often picked ideas that seemed most promising quite quickly. Today I sketch them out more carefully, ask for feedback from different people or do small experiments. Only then do I decide where to invest more time.</p> <img src="https://liip.rokka.io/www_inarticle/e422bf/feedbackworkshop.jpg" alt="Workshop about feedback"> <p>This is the first workshop we organised to collect ideas about feedback</p> <p><strong>The outcome is uncertain</strong><br /> If this pilot will be successful, we don’t know yet. We have a lot of volunteers and progress is visible. Taking time is difficult and often has low priority in the many tasks of daily work life. We definitely have a long way to go until we live a culture of regular feedback.</p> <p><strong>How about you?</strong><br /> Do you face similar problems in your company? What are your experiments or solutions? I would really like to hear from you at <a href="mailto:zahida.huber@liip.ch">zahida.huber@liip.ch</a></p><img src="http://feeds.feedburner.com/~r/liip_blog/~4/GElS43TS2no" height="1" width="1" alt=""/> https://www.liip.ch/en/blog/how-we-want-to-change-feedback-culture-at-liip Design Thinking chez QoQa : un retour d’expérience http://feeds.liip.ch/~r/liip_blog/~3/BzMH9-oj5OY/design-thinking-chez-qoqa-un-retour-d-experience https://www.liip.ch/en/blog/design-thinking-chez-qoqa-un-retour-d-experience Tue, 19 Dec 2017 00:00:00 +0100 <p>Nous sommes début 2016. Joann Dobler, responsable du digital et médias chez QoQa, nous appelle pour nous dire qu’après le web, ils veulent s’attaquer en parallèle à leur app mobile.<br /> Ca fait plus d’un an que le chantier du nouveau site web de QoQa.ch est entamé. Leur équipe digitale a déjà pris un virage à 180 degrés autant au niveau <a href="https://www.liip.ch/fr/blog/l-agilite-chez-qoqa-interview-avec-joann-dobler">feedback régulier de leur Qommunauté avec la méthode agile Scrum</a>, qu’au niveau expérience utilisateur avec des méthodes incluant les QoQasiens dans la conception.</p> <p>Ayant compris tous les bénéfices business que l’implication des QoQasiens va apporter à la nouvelle plateforme web, il ne peut pas imaginer faire autrement pour la refonte de leur application mobile. Les challenges principaux auxquels fait face l’équipe QoQa sont lancés :</p> <ul> <li>Challenge 1 : Qu’est ce qui ferait de l’expérience QoQa quelque chose d’exceptionnel ?</li> <li>Challenge 2 : Comment créer une expérience d’achat exempte de frustration, mais qui reste excitante et fun ?</li> <li>Challenge 3 : Comment peut-on accueillir les nouveaux clients pour qu'ils se sentent vraiment les bienvenus ?</li> <li>Challenge 4 : Comment faire grandir la famille QoQa ?</li> </ul> <img src="https://liip.rokka.io/www_inarticle/a0539f/qoqadesignthinkinglego.jpg" alt="Des Legos pour stimuler la créativité"> <p><em>Des Legos pour stimuler la créativité</em></p> <p>Afin d’aider QoQa de la manière la plus efficiente qui soit, nous leur avons proposé un workshop de Design Thinking. Cet outil de résolution de problématiques permet de co-créer des solutions créatives et innovantes en impliquant l'utilisateur final.<br /> L’avantage de cette approche est qu’en une ou deux journées, on arrive à : identifier les personnes clés ayant un intérêt pour la solution, définir une ou plusieurs problématiques à traiter, générer des idées innovantes, les prototyper, et les tester concrètement.</p> <p>Plutôt que de vous faire un résumé de cette journée moi-même, j’ai demandé à Joann de répondre à plusieurs questions pour vous partager son expérience.</p> <p><strong>Quel était le besoin initial derrière cette volonté de renouveler vos applications mobiles en 2016 ?</strong><br /> L’objectif était simple: nous avons toujours eu comme objectif premier d’offrir aux QoQasiens des applications simples à utiliser, et amusantes. Dès le départ, nous voulions utiliser ce nouveau support non pas comme un canal de plus, mais bien comme une nouvelle opportunité d’être au plus proche de notre Qommunauté. Pourquoi faire une app, si c’est pour offrir exactement les mêmes possibilités que sur le web ? Et en voyant le potentiel ainsi que le trafic - qui devient supérieur au web - nous avons décidé de monter une team en interne et de voir les apps mobiles comme une priorité dans nos réflexions.</p> <p><strong>Qu’as-tu pensé du Design Thinking de prime abord, lorsqu’on vous a proposé cette méthode comme solution à votre problématique ?</strong><br /> J’ai tout de suite été enthousiaste! Cette méthode collaborative nous a permis d’aller au plus proche des besoins de nos QoQasiens. Cette démarche a pris du temps, notamment l’identification des personas, mais cela nous a fait beaucoup de bien. Notre parti-pris, c’est “On Qiffe tout le monde”: mais même si QoQa ne doit exclure personne, nous avions pas mal d’idées préconçues sur notre public. Pour nous, l’important était donc de pouvoir se retrouver avec des QoQasiens de tous horizons et d’en connaître leurs besoins. C’était vraiment ultra-motivant!</p> <p><strong>A quoi t’attendais-tu comme résultat de cette journée de workshop (avant de la faire) ?</strong><br /> Dur à dire! Disons que je pensais ressortir de cette journée avec des centaines d’idées mais ma grande interrogation était: “Est-ce que nous pourrons en faire quelque chose de concret ?”</p> <img src="https://liip.rokka.io/www_inarticle/82845c/qoqadesignthinkingcocreation.jpg" alt="La co-créativité comme élément central de la journée"> <p><em>La co-créativité comme élément central de la journée</em></p> <p><strong>Comment as-tu sélectionné les personnes qui ont participé au workshop ?</strong><br /> On a d’abord fait une analyse de notre “clientèle”. Même si nous ne sommes pas trop fanas de la démarche, je dois dire que cette analyse nous a fait du bien. Au final, nous avions 6 types distincts et avons trouvé pour chaque persona deux personnes dans notre entourage.</p> <p><strong>Où as-tu décidé d’effectuer le workshop, et pourquoi ?</strong><br /> Il fallait un lieu qui représente QoQa, qui nous sorte du bureau et qui nous pousse à être créatifs. Ce n’était pas considéré comme une journée de travail, mais comme une journée de détente, de fun et d’éclate. Nous avons donc décidé d’aller au bar TA CAVE à Lausanne, un lieu communautaire et atypique que nous avons pu privatiser une journée. Bons vins, bonne bouffe, super chaleureux… C’était le reflet parfait de notre philosophie!</p> <p><strong>Comment s’est déroulée la journée ? Qu’est-ce qui t’a surpris ou déçu ?</strong><br /> Hyper bien, à certains moments je pensais halluciner. Surtout quand j’ai compris que nous allions travailler avec des Legos! Mais en fait l’ambiance super créative était vraiment motivante. Ce workshop a même créé des nouvelles amitiés! Des idées un peu folles en sont ressorties, mais elles répondaient toutes à un réel besoin. Les échanges ont permis de trouver des solutions créatives, et de répondre à chaque persona et ses propres problématiques. Donc autant vous dire que nos apps mobiles sont aujourd’hui juste le début d’une belle aventure!</p> <p><strong>Quels impacts a eu cette journée de workshop sur la stratégie digitale de QoQa pour les apps mobiles (ou web/digital plus globalement) ?</strong><br /> Nos apps mobiles sont considérées comme un nouveau canal et non pas un simple device qui nous permet de faire la même chose que sur la version web. Cette journée nous a permis de valider — ou pas — nos prochains développements. Et notre stratégie reste simple, à savoir répondre aux besoins de nos QoQasiens et donc continuer à les impliquer dans nos futures réflexions.</p> <p><strong>Concrètement, quels sont les projets innovants qui ont déjà été implémentés — ou qui vont être implémentés (tu nous donnes un petit teaser sur la semaine anniversaire ?)</strong><br /> Je peux difficilement parler de nouvelles features. Mais par contre, je peux vous dire que tous les aspects communautaires seront bientôt dans nos apps mobiles. Je parle des Qdéfis, des sondages, des chasses au trésor, etc. Nous avons également décidé de passer plus de temps pour de la R&amp;D afin de tester des idées résultantes du workshop, et soyez sûr que de belles choses se préparent pour 2018… La réalité augmentée nous intéresse beaucoup !</p> <img src="https://liip.rokka.io/www_inarticle/170e3f/qoqadesignthinkingprototype.jpg" alt="Un prototype répondant à une problématique concrète"> <p><em>Un prototype répondant à une problématique concrète</em></p> <p><strong>À quelle société en Suisse romande recommanderais-tu ce type de workshop, et pour répondre à quel problème ?</strong><br /> À toutes les boîtes qui ont besoin d’évoluer et d’écouter leurs clients. Nous vivons une période étrange avec cette transformation digitale… Je pense que c’est le bon moment pour se poser les bonnes questions. Car l’objectif ne sera pas de juste numériser, de faire un site web ou une app, mais bien de répondre à un vrai besoin et de se transformer pour évoluer dans le bon sens.</p> <p><strong>Pourquoi as-tu fais confiance à Liip plutôt qu’à une société de consulting en stratégie qui aurait pu proposer le même type de workshop ?</strong><br /> Car vous êtes des pointures, et en plus vous mettez l’ambiance aux apéros !</p> <hr /> <p>Vous pouvez retrouver un résumé vidéo de ce workshop de Design Thinking QoQa qui retranscrit bien l’ambiance de cette journée d’idéation.</p> <figure class="embed-responsive embed-responsive--16/9"><iframe src="//youtube.com/embed/ntESv3lfFY8" frameborder="0" webkitallowfullscreen="true" mozallowfullscreen="true" allowfullscreen="true"></iframe></figure> <p>Chez Liip, on adore cette énergie créative et collaborative qui ressort de chaque workshop de Design Thinking. C’est grisant de voir des idées innovantes qui fusent et prennent forme grâce à un judicieux mélange de personnes du “business” et d’utilisateurs réels venant d’horizons différents.</p> <p>Pour le client ou la marque concernée, c’est à chaque fois le même refrain qu’on entend en sortant du workshop : “On a enfin pu prendre le besoin à sa source, et se reconnecter avec nos clients finaux dans la vraie vie (vs. sur nos Analytics) !”</p><img src="http://feeds.feedburner.com/~r/liip_blog/~4/BzMH9-oj5OY" height="1" width="1" alt=""/> https://www.liip.ch/en/blog/design-thinking-chez-qoqa-un-retour-d-experience Liip achieved the top 5 medium-sized companies and therefore “Top Arbeitgeber 2018” http://feeds.liip.ch/~r/liip_blog/~3/2-w9Ik3Mx2Y/liip-unter-den-top-5-der-mittelstaendischen-arbeitnehmern https://www.liip.ch/en/blog/liip-unter-den-top-5-der-mittelstaendischen-arbeitnehmern Tue, 12 Dec 2017 00:00:00 +0100 <p>In November 2017, Focus-Business distinguished the top employers of the DACH region. To determine the ranking of the 1,300 companies, Focus has worked closely with kununu.com, the employer evaluation platform and Media Market Insights as a research company. The ranking is based on approximately 13,000 data sets with more than 324,000 employer evaluations. After companies had fulfilled the regional criteria, they had to gain a rating above 4.12 on kununu.com aswell to reach the final selection. The final placement was awarded by a score value that is composed of the average rating, the number of ratings on Kununu and the number of employees. LIIP is the fifth best medium-sized employer with a score of 92.5 and is awarded second place in the Internet sector.</p> <p><strong>Commitment to self-determination </strong><br /> In October 2017, the company won the Prix Balance and now it is one of 5 in the Top Medium-sized Employer 2018 makes LIIP proud. &quot;To receive such international recognition verifies us with the quality of our working conditions,&quot; says Gerhard Andrey partner and co-founder. At LIIP employees follow the Holacracy principle: there are no traditional hierarchies, but a sociocratic decentralised form of authority instead. &quot;This shortens the decision-making process and prevents the creation of networks for the mutual furthering of careers,&quot; explains Gerhard Andrey. LIIP invests in its employees and they’re giving back a lot. The focus is on the atmosphere, the joint advancement of ideas and the implementation of projects. There are no external co-owners, therefore Almost half of LIIP's shareholders are employees. &quot;We are financially independent,&quot; says Gerhard Andrey.</p> <p><strong>Liip - a top notch employer</strong><br /> &quot;At LIIP we offer our employees motivating working conditions, this promotes the work-life-balance&quot;, explains Gerhard Andrey. In addition to gender equality, individually definable part-time hours, options for unpaid time off, it is the autonomy of all employees that creates a highly productive and at the same time considerate atmosphere. In order to avoid inequities in pay, the wage system at LIIP is transparent and is applied equally to all employees. &quot;We are not finished by any stretch of the imagination! We will continue to increase the wellbeing of our employees,&quot; confirms Nadja Perroulaz, partner and co-founder after receiving the title Top Medium-sized Employer 2018.</p><img src="http://feeds.feedburner.com/~r/liip_blog/~4/2-w9Ik3Mx2Y" height="1" width="1" alt=""/> https://www.liip.ch/en/blog/liip-unter-den-top-5-der-mittelstaendischen-arbeitnehmern L’agilité chez QoQa : interview avec Joann Dobler http://feeds.liip.ch/~r/liip_blog/~3/9e5uULQETkY/l-agilite-chez-qoqa-interview-avec-joann-dobler https://www.liip.ch/en/blog/l-agilite-chez-qoqa-interview-avec-joann-dobler Tue, 12 Dec 2017 00:00:00 +0100 <p>En décembre 2014, on recevait un appel de Joann Dobler qui est en charge des pôles multimédia et digital chez QoQa. Dans les grandes lignes, ça disait quelque chose comme “Salut Liip, on est en train de refaire tous nos sites et apps mobiles, et on cherche un partenaire pour nous aider à lancer le projet dans la bonne direction niveau méthodologie et techno. Ca vous tente ?”<br /> En voyant l'opportunité de pouvoir pratiquer Scrum sur un chantier immense comme QoQa.ch, nous avons accepté sans hésitation.</p> <p>Trois ans après cette discussion, leur nouvelle plateforme au nom de code “QoQa4” est désormais en ligne après de nombreux sprints, coups de gueule, montées en stress, sans oublier les fondues et choucroutes au Café Romand.<br /> En voyant le chemin parcouru niveau méthodologie agile après plus de 70 sprints, je me suis dis que ça serait intéressant d’interviewer Joann pour avoir son retour d’expérience concret sur l’Agilité et Scrum, quelques années après avoir écrit sa première User Story.</p> <p>Bienvenue à Joann Dobler, celui qui a introduit Scrum et ses outils assez carrés dans un environnement QoQasien où on pense que les règles sont plutôt faites pour être enfreintes !</p> <p><strong>Pourquoi toi, Joann, tu as pensé à l'agilité pour QoQa fin 2014 ? Quelles conditions t'ont amené à considérer cette méthodologie ?</strong><br /> En fait, je connaissais déjà l'agilité, et je savais qu’au vu de l'ampleur du projet et donc au temps de sa mise en place, nos priorités business et technologiques allaient évoluer. On devait donc choisir une méthode qui nous permette de nous adapter. De plus, pour une question d’état d’esprit, de partage, et de dynamisme au sein de l'équipe, on devait s’adapter, et donc dynamiser notre façon de travailler. </p> <p>En résumé : il nous fallait un truc pour mieux nous adapter au business, faire face aux changements de priorités, offrir de la transparence, et amener un réel échange au sein de l’équipe.</p> <p><strong>Quelle méthodologie de gestion de projet utilisiez-vous avant chez QoQa ?</strong><br /> On utilisait une méthode traditionnelle, genre un agenda par étapes et jalons. Une fois les maquettes graphiques terminées, on débutait avec l’HTML… Pour les petits projets, ça pouvait jouer, mais dès que c’était plus conséquent, on finissait avec des délais jamais tenus, aucune flexibilité, et surtout un gros manque de dynamisme avec les équipes.<br /> Si quelqu’un peut m’assurer un délai d’un gros projet un an à l’avance, je l’invite pour une bouffe afin qu’il m’explique sa technique — no joke !</p> <p><strong>Pourquoi avoir choisi Liip pour vous accompagner plutôt qu’un coach agile ? Autrement dit, quelle stratégie de montée en compétence recommanderais-tu à quelqu’un qui veut se lancer pour de bon dans Scrum et l’agilité ?</strong><br /> J'avais besoin d'experts dans le domaine pour nous accompagner à l'implémenter.<br /> Je voulais une agence qui a de la bouteille, qui vit agile et qui connaît les avantages et les inconvénients de cette méthode. Je cherchais à ce qu’on se trouve en totale immersion.<br /> Par dessus tout, je voulais bosser avec une agence “no-bullshit”. Du coup j’ai appelé Liip.</p> <img src="https://liip.rokka.io/www_inarticle/eee33f/qoqascrumproductbacklogcreation.jpg" alt="Création du backlog QoQa4 de 300+ stories"> <p><em>Création du backlog QoQa4 de 300+ stories</em></p> <p><strong>Comment se sont passées les premières semaines avec Scrum ?</strong><br /> Au début c’était assez excitant, on avait nos post-its, notre board Jira, on faisait nos rétros/reviews et on pouvait se la raconter en interne : “Regardez on arrive avec une méthode révolutionnaire !” Mais c’est seulement après trois mois qu’on a rencontré nos premiers véritables soucis ; c’est une fois que le projet est 100% agile que tu comprends ce que veut dire agile.</p> <p><strong>Combien de sprints a-t-il fallu pour que tu te rendes compte de l’impact et de la réelle valeur ajoutée de Scrum ?</strong><br /> C’est difficile à dire...je dirais aux alentours de 4 sprints (i.e. 8 semaines) pour la communication et l’échange entre les équipes. Par contre bien plus en terme projet, je dirais environ une dizaine de sprints de deux semaines chacun.<br /> Les premiers mois furent très difficiles car on n’avait pas compris ce que Scrum et l’agilité demandaient, à savoir faire preuve d’une énorme rigueur, et adopter un vrai changement philosophique (vs. “simplement” faire des sprints).<br /> Concrètement, on a du beaucoup plus échanger, se dire les choses de manière transparente. La hiérarchie aussi en prend un coup.</p> <p><strong>Comment aurais-tu géré ces premières semaines si tu étais resté avec ton ancien modèle de gestion de projet ?</strong><br /> C’est simple, je n’aurais tout simplement plus de job ;)<br /> J’aurais fait un magnifique planning, j’aurais découpé mes tâches, et j’aurais attribué mes tickets. Du coup, peu d’échanges, pas de mise à profit des compétences de tous les membres de l’équipe. Je pense sincèrement que cette méthode nous a permis d’écouter nos utilisateurs, d’analyser leurs vrais besoins, et de s’adapter au fur et à mesure.</p> <img src="https://liip.rokka.io/www_inarticle/0ed73d/qoqascrumestimationmeeting.jpg" alt="Premier meeting d'estimation Scrum"> <p><em>Premier meeting d'estimation Scrum</em></p> <p><strong>Comment s’est passé l’adoption de l’Agilité/Scrum en interne ?</strong><br /> Au début, c’était super facile car ça paraissait tendance. Mais c’est quand les premiers problèmes surviennent qu’on se rend compte de la difficulté d’intégrer cette méthodologie. Pourquoi ? Car par exemple, lors de nos premières retros/reviews, on a dû se parler en toute transparence ; cela paraît ridicule mais ça change tout.<br /> On n’avait plus de titres mais des rôles à jouer, alors la hiérarchie est rapidement mise de côté au profit de l’échange. On est passés par des périodes difficiles car le projet sur lequel on a démarré est simplement le plus gros de projet de QoQa de ces dix dernières années. Pression, choix à faire, décisions à prendre, implication de plusieurs départements, merci à la méthode qui nous a obligés à rester calme, à partager nos problèmes, et à trouver des solutions ensemble.<br /> Et je dois dire qu’on a eu la GRANDE chance d’être soutenu par la Direction, enfin par la Loutre in Chief qui nous a fait confiance.</p> <p>Je dois avouer que les débuts furent plus que difficiles, j’avais la sensation de griller du cash en meeting. Le rôle du PO n’est pas simple car on a le budget en tête et un planning que le business attend avec impatience. Alors moi qui suis un impulsif, j’ai vraiment eu la sensation de bosser avec une méthode à la mode. Mais là encore, grâce au soutien, j’y ai cru, j’ai changé ma façon de penser, et aujourd’hui j’en suis heureux. Il faut laisser le temps que tout se mette en place, faire confiance, garder la rigueur, et se faire épauler.</p> <p><strong>Si tu ne devais citer qu’une valeur ajoutée que Scrum a apporté à QoQa dans son ensemble, qu’est-ce que ça serait ?</strong><br /> La COMMUNICATION !<br /> Sans déc, c’est incroyable les silos que ça a fait péter. Même les gars de la logistique ont adopté des outils de Scrum avec des meetings courts de synchronisation chaque matin</p> <img src="https://liip.rokka.io/www_inarticle/36793c/qoqascrumgroomingmeeting.jpg" alt="L'équipe cross-fonctionnelle QoQa-Liip"> <p><em>L'équipe cross-fonctionnelle QoQa-Liip — incluant développeurs, POs, et designers</em></p> <p><strong>Si tu ne devais citer qu’une valeur ajoutée que Scrum a apporté à toi le PO, qu’est-ce que ça serait ?</strong><br /> Apprendre à couper dans le gras ! Autrement dit savoir mettre des priorités et ne pas partir la tête dans le guidon en se disant que tout est indispensable.</p> <p><strong>Qu’est-ce que tu penses de la qualité délivrée par un projet en mode agile (i.e. la correspondance entre besoins utilisateurs et le produit développé) comparé à un projet en mode “waterfall” ?</strong><br /> Alors c’est tout simplement différent. Avant c’était moi le pro du web et je savais mieux ce dont l’utilisateur avait besoin. Maintenant, c’est l’utilisateur qui dicte mon métier. On y va étape par étape, on commence par le minimum, on analyse, on implique tous les acteurs. Toutes ces discussions font que tu économies du temps de production car tu testes, tu récoltes des infos du terrain, et seulement après tu construis par dessus. C’est fini la belle époque où on se disait “Je sais une année avant ce qu’il te faudra”.</p> <p><strong>Est-ce que Scrum a solutionné tous tes problèmes ? Si non, qu’est-ce que ça ne couvre pas ?</strong><br /> J’ai envie de dire OUI — ce que je ne disais pas il y a deux ans — même si on a encore beaucoup à expérimenter. Ce qui est vraiment cool c’est qu’on a un scénario agréable avec un gros projet en interne sur lequel on peut réellement prendre le temps d’itérer, et non juste se contenter de lancer des fonctionnalités l’une à la suite de l’autre. </p> <p><strong>Combien de sprints avez-vous fait jusqu’à maintenant ?</strong><br /> 69 ;)</p> <p><strong>Rétrospectivement (on est agile après tout), quelles sont les raisons qui font qu’après une soixantaine de sprints vous n’étiez toujours pas en production au printemps dernier ? Et qu’est-ce que tu ferais différemment aujourd’hui avec les connaissances que tu as acquises ?</strong><br /> On aurait dû couper dans le gras. On a fait la pire des erreurs de vouloir tout, tout de suite, et en mieux qu’avant.</p> <p><strong>Quid de la visibilité ? Mieux ? Moins bonne ? Niveau planning ?</strong><br /> Ce fut mon principal problème quand on a commencé l’intégration de l’agilité, avec tout le monde qui venait me dire “Alors on lance quand ces nouvelles plateformes ?”<br /> J’ai dû geler le business pendant plus de deux ans, donc la question était tout à fait prévisible et je devais pouvoir y répondre. Mais au début, je n’en avais aucune idée avec notre backlog long comme le bras.<br /> Grâce à Liip et leur méthodologie, j’ai pu finalement avoir ma réponse après ce qu’ils appellent une “speed estim”. En gros, on a pris les 300+ User Stories du backlog, et on les a estimé en moins de 3h30. C’était incroyable, j’avais enfin de la visibilité pour moi et les parties prenantes au projet.<br /> Par contre, je me suis pris une grosse claque une fois qu’on a eu la somme totale de Story Points. Si je me fiais au estimation, on en avait pour deux fois plus de temps que notre roadmap initiale sur une année… Mais j’ai fini par comprendre qu’encore une fois je voyais trop gros, et que même si ça faisait mal, il fallait encore plus couper dans le gras.</p> <img src="https://liip.rokka.io/www_inarticle/debabd/qoqascrumreviewdemomeeting.jpg" alt="Le meeting de review Scrum amène de la visibilité sur le travail réalisé, et ce chaque deux semaines"> <p><em>Le meeting de review Scrum amène de la visibilité sur le travail réalisé, et ce chaque deux semaines</em></p> <p><strong>Quid de la communication au management/reporting en interne ? Toujours Gantt ?</strong><br /> C’est quoi un Gantt !!? Ca répond à ta question ?</p> <p><strong>Sinon, vous avez eu des changements au niveau scope/business en cours de projet ? Comment les as-tu gérés ?</strong><br /> Yes complètement ! Je dirais que quelques mois avant la mise en production, on a dû faire des choix car il fallait bien se lancer un jour. La méthode permet une telle transparence que ces choix furent pris de manière vraiment cool. Je pense qu’on pourrait encore être en train de développer à l’heure qu’il est, et encore pour quelques années au vu de tout ce qu’on veut faire. Mais non, on s’est lancés à l’eau. Comment ? En gérant nos priorités et qui de mieux placé que nos QoQasiens pour nous dire ce qui leur manquent ? Du coup, pas mal de fonctionnalités abandonnées dans une première version, et on a tellement bien fait !</p> <p><strong>Niveau priorités des parties prenantes dans le projet, comment as-tu géré ça ? Intégration des besoins du chef, des départements ?</strong><br /> Après avoir défini les grandes lignes du scope de la V1 du projet, on a impliqué tous les utilisateurs par département dans les choix, les priorités, le design, et surtout les testing. Les grands axes eux furent validés lors de nos COPIL. La méthode permet une vision très détaillée de l’avancement du projet, ce qui facilite la prise de décision.<br /> Mais c’est important de souligner qu’après environ 6 mois de projet, on était totalement perdus... On sera prêts dans un an, deux an, trois ans… Aucune idée et je peux vous avouer que je faisais pas le malin, et c’est là qu’il faut faire confiance à la méthode, et rassurer les équipes avec un peu de bullshit…<br /> De nouveau : speed estim, couper dans le gras, se faire accompagner, et elle est belle :)</p> <p><strong>Quid de la rigueur de l’agilité (oui oui l’agilité c’est beaucoup de rigueur malgré le nom !) chez QoQa qui est plutôt freestyle d’habitude ?</strong><br /> C’est ce qu’on n’avait pas compris au départ : il faut de la rigueur sinon c’est mort. Pour moi qui suis un créatif, la rigueur fut difficile à accepter. Mais maintenant je peux le dire, cette rigueur nous rend plus créatif !!! Mais il faut le vivre pour comprendre.</p> <img src="https://liip.rokka.io/www_inarticle/c564f5/qoqapingpongbreak.jpg" alt="Pause ping-pong, ou comment allier rigueur et freestyle !"> <p><em>Pause ping-pong, ou comment allier rigueur et freestyle !</em></p> <p><strong>Un mot sur les cérémonies Scrum de début de sprint, estim et planning ?</strong><br /> C’est le début d’un projet ou d’une nouvelle itération, alors c’est cool et motivant.<br /> Côté estim, on ne parle plus d’heures de travail, mais de complexité. Ca parait fou mais c’est juste top — ce qui me paraissait irréaliste il y a encore deux ans.</p> <p><strong>Un mot sur les cérémonies Scrum de fin de sprint, review et rétrospective ?</strong><br /> C’est la fin du projet donc ça dépend du résultat, mais normalement c’est top car il n’y a jamais de surprises. Si surprises, c’est qu’il y a eu une mauvaise communication durant le sprint. C’est un vrai moment d’échanges et de partage. On se dit les choses et on essaie de les améliorer ; c’est dingue mais ça marche ! Au début quand je recevais des post-its rouge, j’avais de la peine à l'accepter... mais aujourd’hui j’adore, on s’améliore sans cesse.</p> <img src="https://liip.rokka.io/www_inarticle/87cd2ba/qoqascrumretrospectivemeeting-2.jpg" alt="Le meeting de rétrospective Scrum, un élément crucial pour l'amélioration continue"> <p><em>Le meeting de rétrospective Scrum, un élément crucial pour l'amélioration continue</em></p> <p><strong>Et le grooming en cours de sprint ? Vous l’utilisez ? Pourquoi ?</strong><br /> Le grooming est essentiel, il peut faire gagner tellement de temps comme on implique l’équipe très tôt dans le processus de création des User Stories. On détaille et on réfléchit ensemble, c’est très créatif. S’il y a un doute, alors la story n’est pas claire et ça nous pousse à être plus précis, et donc éviter les surprises. La boucle est bouclée.</p> <p><strong>Question finale: Si aujourd’hui tu devais recommencer un projet (pro ou perso d’ailleurs), tu t’y prendrais comment ?</strong><br /> Je débuterai par un Gantt évidemment ;)</p> <hr /> <p>Encore un grand merci à Joann d'avoir pris le temps de partager son retour d'expérience.<br /> Chez Liip, ce qu'on retient le plus de cette aventure, c'est que &quot;couper dans le gras&quot; est l'une des clés de la réussite d'un projet.<br /> On se réjouit de continuer à collaborer avec l'équipe des loutres pour échanger sur leurs expérimentations de Scrum.</p><img src="http://feeds.feedburner.com/~r/liip_blog/~4/9e5uULQETkY" height="1" width="1" alt=""/> https://www.liip.ch/en/blog/l-agilite-chez-qoqa-interview-avec-joann-dobler Speeding up Composer based deployments on AWS Elastic Beanstalk http://feeds.liip.ch/~r/liip_blog/~3/x_A36ZnsHpg/speeding-up-composer-based-deployments-on-aws-elastic-beanstalk https://www.liip.ch/en/blog/speeding-up-composer-based-deployments-on-aws-elastic-beanstalk Mon, 11 Dec 2017 00:00:00 +0100 <p>Some of our applications are deployed to <a href="https://aws.amazon.com/de/elasticbeanstalk/">Amazaon Elastic Beanstalk</a>. They are based on PHP, Symfony and of course use <a href="https://getcomposer.org">composer</a> for downloading their dependencies. This can take a while, approx. 2 minutes on our application when starting on a fresh instance. This can be annyoingly long, especially when you're upscaling for more instances due to for example a traffic spike.</p> <p>You could include the vendor directory when you do <code>eb deploy</code>, but then Beanstalk doesn't do a <code>composer install</code> at all anymore, so you have to make sure the local vendor directory has the right dependencies. There's other caveats with doing that, so was not a real solution for us.</p> <p>Composer cache to the rescue. Sharing the composer cache between instances (with a simple up and download to an s3 bucket) brought the deployment time for composer install down from about 2 minutes to 10 seconds. </p> <p>For that to work, we have this on a file called <code>.ebextensions/composer.config</code>:</p> <pre><code>commands: 01updateComposer: command: export COMPOSER_HOME=/root &amp;&amp; /usr/bin/composer.phar self-update 02extractComposerCache: command: ". /opt/elasticbeanstalk/support/envvars &amp;&amp; rm -rf /root/cache &amp;&amp; aws s3 cp s3://rokka-support-files/composer-cache.tgz /tmp/composer-cache.tgz &amp;&amp; tar -C / -xf /tmp/composer-cache.tgz &amp;&amp; rm -f /tmp/composer-cache.tgz" ignoreErrors: true container_commands: upload_composer_cache: command: ". /opt/elasticbeanstalk/support/envvars &amp;&amp; tar -C / -czf composer-cache.tgz /root/cache &amp;&amp; aws s3 cp composer-cache.tgz s3://your-bucket/ &amp;&amp; rm -f composer-cache.tgz" leader_only: true ignoreErrors: true option_settings: - namespace: aws:elasticbeanstalk:application:environment option_name: COMPOSER_HOME value: /root</code></pre> <p>It downloads the composer-cache.tgz on every instance before running <code>composer install</code> and extracts that to <code>/root/cache</code>. And after a new deployment is through, it creates a new tar file from that directory on the &quot;deployment leader&quot; only and uploads that again to S3. Ready for the next deployment or instances.</p> <p>One caveat we currently didn't solve yet. That .tgz file will grow over time (since it will have old dependencies also in that file). Some process should clear it from time to time or just delete it on S3 when it gets too big. The <code>ignoreErrors</code> options above make sure that the deployment doesn't fail, when that tgz file doesn't exist or is corrupted.</p><img src="http://feeds.feedburner.com/~r/liip_blog/~4/x_A36ZnsHpg" height="1" width="1" alt=""/> https://www.liip.ch/en/blog/speeding-up-composer-based-deployments-on-aws-elastic-beanstalk Liip recognised in the Meilleur du Web awards http://feeds.liip.ch/~r/liip_blog/~3/0isAJcYZDd4/meilleur-du-web-2017 https://www.liip.ch/en/blog/meilleur-du-web-2017 Thu, 07 Dec 2017 00:00:00 +0100 <h2>The Meilleur du Web awards: an unmissable event</h2> <p>The Meilleur du Web awards have rewarded the work of digital agencies in the French speaking part of Switzerland since 2011. The prize shines a spotlight on numerous projects. It is a source of inspiration for businesses in French-speaking Switzerland, and gives companies the opportunity to explore projects in digital communications, e-commerce and performance.<br /> “We are delighted to see our work rewarded! These prizes are a mark of recognition for the teams involved in these projects. It is a celebration of teamwork, which includes our User Experience,Design and Development teams,” explains Laurent Prodon, Product Owner for the tooyoo project.</p> <h2>QoQa: working agile and collaboratively</h2> <p>The collaboration between Liip and QoQa started three years ago. Liip and QoQa worked together closely, particularly to train QoQa’s teams in working agile. QoQa employees spent two months with Liip’s development team in the Lausanne office. Liip shared each stage of its agile methodology, reflecting its commitment to offering long-term support to its client.<br /> The QoQa application won the prizes of the category Technology, Business Efficiency and Mobile.</p> <h2>Tooyoo: sensitive support for bereavement</h2> <p>Tooyoo is a sage, online storage platform, dedicated to secure wills. It uses targeted questionnaires to define its users’ final wishes. Sensitive data are only communicated after the person died.<br /> Tooyoo supports the relatives of deceased persons through the various procedures step by step. Therefore making the administiv process as simple as possible .<br /> Ease of use and security are at the heart of the project. We have implemented a complex encryption system to ensure the security of the data transmitted. Using tests and methods such as empathy maps, we have worked in stages using a user-centred approach.<br /> Our tooyoo project reaches the finals in the category Technology.</p> <figure class="embed-responsive embed-responsive--16/9"><iframe src="//youtube.com/embed/V0NcrdxGudc" frameborder="0" webkitallowfullscreen="true" mozallowfullscreen="true" allowfullscreen="true"></iframe></figure><img src="http://feeds.feedburner.com/~r/liip_blog/~4/0isAJcYZDd4" height="1" width="1" alt=""/> https://www.liip.ch/en/blog/meilleur-du-web-2017 Shapefiles - Of avalanches and ibexes http://feeds.liip.ch/~r/liip_blog/~3/WwVGHzOJRyk/shapefiles-of-avalanches-and-ibexes https://www.liip.ch/en/blog/shapefiles-of-avalanches-and-ibexes Wed, 06 Dec 2017 00:00:00 +0100 <p>At Liip, we recently completed an application for architecture students that uses shapefiles as its backbone data to deliver information about building plots in the city of Zurich. They are displayed on a map and can be inspected by the user. A similar project was done by a student team, of which I was part, for the FHNW HT project track: A fun-to-use web application that teaches children in primary school about their commune.</p> <p>But not only can shapefiles help to enhance the user experience, they also contain data, that, when brought into context, can yield some interesting insight. So let's see, what I can find out by digging into some shapefiles and building a small app to explore them.</p> <p>In this blog post, I'm taking a practical approach to working with shapefiles and show you how you can get started working with them as well!</p> <h2>Alpine Convention</h2> <p>The first hurdles of working with shapefiles are understanding what they actually are and acquiring them in the first place.</p> <p>Shapefiles are binary files that contain geographical data. They usually come in groups of at least 3 different files that all have the same name, their only difference is their file ending: <code>.shp</code>, <code>.shx</code> and <code>.dbf</code>. However, a complete data set can contain many more files. The data format was developed by Esri and introduced in the early 1990s. Shapefiles contain so called <em>features</em>, some geometrical shape with its metadata. A feature could be a point (single X/Y coordinates) and a text of what this point is. Or a polygon, consisting of several X/Y points, a single line, a multi-line, etc.</p> <p>To acquire some shapefiles to work with, I have a look at <a href="https://opendata.swiss/en/dataset?res_format=SHAPEFILE">OpenData.swiss</a>. OpenData offers a total of 102 (as of November 2017) different shapefile data sets. I only need to download and start to work with them. For this example, I chose a rather small shapefile: <a href="https://opendata.swiss/en/dataset/alpenkonvention">Alpine convention</a> consisting of the perimeters of the <a href="http://www.alpconv.org/en/convention/default.html">Alpine Convention</a> in Switzerland.</p> <p>Since these files are binaries and I cannot look at them in some text editor, I need some tool to have a look at what I just downloaded.</p> <h2>Introducing QGIS - A Free and Open Source Geographic Information System</h2> <p><a href="http://www.qgis.org/en/site/">QGIS</a> is an extensive solution for all kinds of GIS. It can be downloaded and installed for free, has a lot of plugins and an active community. I'm going to use it to have a look at my previously downloaded shapefile.</p> <p>For this example, I installed QGIS with the <a href="https://plugins.qgis.org/plugins/openlayers_plugin/">OpenLayers plugin</a>. This is what it looks like, when started up:</p> <img src="https://liip.rokka.io/www_inarticle/f498c7/1blank.jpg" alt="1blank"> <p>To get some reference on where I actually am and where my data goes, I add OpenStreetMap as a layer. I also pan and zoom the map, so I have Switzerland in focus.</p> <img src="https://liip.rokka.io/www_inarticle/8f4fb0/2osmlayer.jpg" alt="2osmlayer"> <p>The next step would be to actually open the shapefile, so QGIS can display it on top of the map. For that I can simply double-click the <code>.shp</code> file in the file browser on the left.</p> <img src="https://liip.rokka.io/www_inarticle/2ffcf0/3alpineconvention.jpg" alt="3alpineconvention"> <p>This view already gives me some information about the shapefile I'm dealing with, on what area it covers, and how many features there are. The Alpine Convention shapefile seems to only consist of one feature, a big polygon, which is enough, given that it only shows the perimeters of the Alpine Convention in Switzerland.</p> <p>To see, what areas and/or details it covers, I can alter the style of the layer, making it transparent. I also zoom in more, to see if the shape is accurate. Its edges should exactly cover the Swiss borders.</p> <img src="https://liip.rokka.io/www_inarticle/fb586b/4layerstyle.jpg" alt="4layerstyle"> <p>Marvelous. Now that I've seen the shape of the feature, I'll have a look at the metadata the shapefile offers. They can be inspected by opening the attributes table of the shapefile in the bottom left browser.</p> <img src="https://liip.rokka.io/www_inarticle/4814d8/5attributetable.jpg" alt="5attributetable"> <p>This file also doesn't offer much metadata, but now I can see that there's actually two features in there. Anyways, there might be more interesting shapefiles out there to work with. </p> <p>But I'm going to stick with the alpine topic.</p> <h2>Of avalanches and ibexes</h2> <p>Digging through OpenData's shapefile repository a bit more, I found two more shapefiles that could potentially yield interesting data: <a href="https://opendata.swiss/en/dataset/verbreitung-der-steinbockkolonien">The distribution of ibex colonies</a> and <a href="https://opendata.swiss/en/dataset/stand-der-naturgefahrenkartierung-in-den-gemeinden-lawinen">the state of natural hazard mapping by communes for avalanches.</a></p> <p>As awesome as QGIS is for examining the data at hand, I want to build my own explorer, maybe even built upon multiple shapefiles and in my own design. For this, there's multiple libraries for all kinds of languages. For web development, the three most interesting ones would be for <a href="https://packagist.org/?q=shapefile&amp;p=0">PHP</a>, <a href="https://pypi.python.org/pypi/pyshp">Python</a> and <a href="https://www.npmjs.com/search?q=shapefile">JavaScript</a>.</p> <p>For my example, I'll build a small frontend application in JavaScript to display my three shapefiles: The alpine convention, the ibex colonies and the avalanche mapping. For this I'm going to use a JavaScript package simply called <a href="https://www.npmjs.com/package/shapefile"><em>&quot;shapefile&quot;</em></a> and <a href="http://leafletjs.com/">leafletjs</a> to display the polygons from the features. But first things first.</p> <h2>Reading out the features</h2> <p><strong>Disclaimer:</strong> The following code examples are using ES6 and imply a webpack/babel setup. They're not exactly copy/paste-able, but they show how to work with the tools at hand.</p> <p>First, I try to load the alpine convention shapefile and log it into the console. The shapefile package mentioned above comes with two examples in the README, so for simplicity, I just roll with this approach:</p> <pre><code class="language-javascript">import { open } from 'shapefile' open('assets/shapefiles/alpine-convention/shapefile.shp').then(source =&gt; { source.read().then(function apply (result) { // Read feature from the shapefile if (result.done) { // If there's no features left, abort return } console.log(result) return source.read().then(apply) // Iterate over result }) })</code></pre> <img src="https://liip.rokka.io/www_inarticle/38c897/log1.jpg" alt="log1"> <p>Works like a charm! This yields the two features of the shapefile in the console. What I see here already, is that the properties of each feature, normally stored in separate files, are already included in the feature. This is the result of the library fetching both files and processing them together:</p> <img src="https://liip.rokka.io/www_inarticle/66d7b1/log2.jpg" alt="log2"> <p>Now I have a look at the coordinates that are attached to the first feature. The first thing that occurs is that there's two different arrays, implying two different sets of coordinates, but I'm going to ignore the second one for now.</p> <img src="https://liip.rokka.io/www_inarticle/8deff6/log3.jpg" alt="log3"> <p>And there's the first pitfall. These coordinates look nothing like <em>WGS84</em> (Latitude/Longitude), but rather something different. Coordinates in WGS84 should be some floating point number, ideally starting with 47 and 8 for Switzerland, so this shapefile confronted me with a different coordinate reference system (or short: CRS). In order to correctly display the shape on top of a map, or use it with other data, I would want to convert these coordinates to WGS84 first, but in order to do that, I need to figure out, which CRS this shapefile is using. Since this shapefile is coming from the Federal Office for Spatial Development ARE, the CRS used is most likely <a href="https://en.wikipedia.org/wiki/Swiss_coordinate_system">CH1903(+), aka the &quot;Swiss coordinate system&quot;.</a></p> <p>So in order to convert that, I need some maths. Searching the web a bit, I can find <a href="https://raw.githubusercontent.com/ValentinMinder/Swisstopo-WGS84-LV03/master/scripts/js/wgs84_ch1903.js">a JavaScript solution to calculate back and forth between CH1903 and WGS84.</a> But I only need some parts of it, so I copy and alter the code a bit:</p> <pre><code class="language-javascript">// Inspired by https://raw.githubusercontent.com/ValentinMinder/Swisstopo-WGS84-LV03/master/scripts/js/wgs84_ch1903.js /** * Converts CH1903(+) to Latitude * @param y * @param x * @return {number} * @constructor */ const CHtoWGSlat = (y, x) =&gt; { // Converts military to civil and to unit = 1000km // Auxiliary values (% Bern) const yAux = (y - 600000) / 1000000 const xAux = (x - 200000) / 1000000 // Process lat const lat = 16.9023892 + (3.238272 * xAux) - (0.270978 * Math.pow(yAux, 2)) - (0.002528 * Math.pow(xAux, 2)) - (0.0447 * Math.pow(yAux, 2) * xAux) - (0.0140 * Math.pow(xAux, 3)) // Unit 10000" to 1" and converts seconds to degrees (dec) return lat * 100 / 36 } /** * Converts CH1903(+) to Longitude * @param y * @param x * @return {number} * @constructor */ const CHtoWGSlng = (y, x) =&gt; { // Auxiliary values (% Bern) const yAux = (y - 600000) / 1000000 const xAux = (x - 200000) / 1000000 // Process lng const lng = 2.6779094 + (4.728982 * yAux) + (0.791484 * yAux * xAux) + (0.1306 * yAux * Math.pow(xAux, 2)) - (0.0436 * Math.pow(yAux, 3)) // Unit 10000" to 1 " and converts seconds to degrees (dec) return lng * 100 / 36 } /** * Convert CH1903(+) to WGS84 (Latitude/Longitude) * @param y * @param x */ export default (y, x) =&gt; [ CHtoWGSlat(y, x), CHtoWGSlng(y, x) ]</code></pre> <p>And this I can now use in my main app:</p> <pre><code class="language-javascript">import { open } from 'shapefile' import ch1903ToWgs from './js/ch1903ToWgs' open('assets/shapefiles/alpine-convention/shapefile.shp').then(source =&gt; { source.read().then(function apply (result) { // Read feature from the shapefile if (result.done) { // If there's no features left, abort return } // Convert CH1903 to WGS84 const coords = result.value.geometry.coordinates[0].map(coordPair =&gt; { return ch1903ToWgs(coordPair[0], coordPair[1]) }) console.log(coords) return source.read().then(apply) // Iterate over result }) })</code></pre> <p>Which yields the following adjusted coordinates:</p> <img src="https://liip.rokka.io/www_inarticle/bcbc96/log4.jpg" alt="log4"> <p>A lot better. Now I'll throw them on top of a map, so I have something I can actually look at.</p> <h2>Making things visible</h2> <p>For that, I add leaflet to the app together with the Positron (lite) tiles from CartoDB. The Positron (lite) theme is light grey/white, which provides a good contrast to the features I'm going to display over them. OpenStreetMap is awesome, but too colourful, so the polygons are not visible enough.</p> <pre><code class="language-javascript">import leaflet from 'leaflet' import { open } from 'shapefile' import ch1903ToWgs from './js/ch1903ToWgs' /** * Add the map */ const map = new leaflet.Map(document.querySelector('#map'), { zoomControl: false, // Disable default one to re-add custom one }).setView([46.8182, 8.2275], 9) // Show Switzerland by default // Move zoom control to bottom right corner map.addControl(leaflet.control.zoom({position: 'bottomright'})) // Add the tiles const tileLayer = new leaflet.TileLayer('//cartodb-basemaps-{s}.global.ssl.fastly.net/light_all/{z}/{x}/{y}.png', { minZoom: 9, maxZoom: 20, attribution: '&amp;copy; CartoDB basemaps' }).addTo(map) map.addLayer(tileLayer) /** * Process the shapefile */ open('assets/shapefiles/alpine-convention/shapefile.shp').then(source =&gt; { source.read().then(function apply (result) { // Read feature from the shapefile if (result.done) { // If there's no features left, abort return } // Convert CH1903 to WGS84 const coords = result.value.geometry.coordinates[0].map(coordPair =&gt; { return ch1903ToWgs(coordPair[0], coordPair[1]) }) console.log(coords) return source.read().then(apply) // Iterate over result }) })</code></pre> <p>This already shows me a nice looking map I can work with:</p> <img src="https://liip.rokka.io/www_inarticle/71b463/map1.jpg" alt="map1"> <p>The next step step is to hook up the map with the shapefile loading. For this, I create leaflet polygons out of the coordinates I transformed to WGS84 earlier:</p> <pre><code class="language-javascript">// ... // Convert CH1903 to WGS84 const coords = result.value.geometry.coordinates[0].map(coordPair =&gt; { return ch1903ToWgs(coordPair[0], coordPair[1]) }) const leafletPolygon = new leaflet.Polygon(coords, { weight: 0.5, color: '#757575', fillOpacity: 0.3, opcacity: 0.3, }) leafletPolygon.addTo(map) // ...</code></pre> <p>And I have a look at the result:</p> <img src="https://liip.rokka.io/www_inarticle/9019b4/map2.jpg" alt="map2"> <p>Nice! </p> <h2>The end result</h2> <p>With some more UI and adding a toggle for the multiple shapefiles, I downloaded earlier, I can build a little app that shows me the hazard zones for avalanches and where in Switzerland ibexes are living:</p> <img src="https://liip.rokka.io/www_inarticle/7767b5/map3.jpg" alt="map3"> <p>We can see the two shapefiles in action: The light green, green, yellow and red polygons are communes with some hazard of avalanches (light green = low, green = mid-low, yellow = mid, red = high), the darker polygons on top are the ibex colonies.</p> <p>This map already gives a good insight on the behaviour of ibexes: apparently they're living in low-hazard to mid-low-hazard zones for avalanches only. They also tend to avoid mid-hazard and high-hazard zones. Since ibexes prefer alpine terrain and such terrain usually bears some danger of avalanches, this is plausible, but now I've got some visible data to actually support this claim!</p> <p>The finished app can be found in action <a href="https://liip.github.io/shapefile-blog-example/">here</a>, its source code can be found <a href="https://github.com/liip/shapefile-blog-example">in this repository</a>.</p> <h2>The pitfalls</h2> <p>Although shapefiles are a mighty way to handle GIS data, there's some pitfalls to avoid. One I've already mentioned is an unexpected CRS. In most cases, it can be identified at the point of usage, but checking, which CRS a shapefile uses when inspecting it, is recommended. The second big pitfall is the size of the shapefiles. When using some shapefiles with JavaScript in the browser directly, the browser might crash while trying to handle the huge amount of polygons. There's several solutions, though: One can either simplify the shapefile by removing unnecessary polygons or pre-process it and store its polygons in some kind of database and only query the polygons currently in sight.</p> <h2>Takeaway thoughts</h2> <p>Personally, I love working with shapefiles. There's a lot of use cases for them and exploring the data they hold is something really exciting. Even though there might be a pitfall or two, in general it's a bliss, as one can get something up and running with little effort. The OpenData community is using shapefiles quite a lot, so it is a well established standard and there's a lot of libraries and tools out there that make working with shapefiles as awesome as it is.</p><img src="http://feeds.feedburner.com/~r/liip_blog/~4/WwVGHzOJRyk" height="1" width="1" alt=""/> https://www.liip.ch/en/blog/shapefiles-of-avalanches-and-ibexes