 Okay, according to my watch it's one o'clock, so let's start. Welcome everybody. And instead of me talking here for one hour about some important business case, we have lined up 11 speakers here who will all talk about something they are passionate about. The subjects they will cover are pretty diverse. Some people have technical subjects, some of them are more business oriented and some of them might be even philosophical. My name is Huldemister and in the coming 60 seconds I will tell you a little bit more about my company. We'll explain the format of this presentation and finally give you a quick overview of who is going to talk about what. Our company, Wunderkraut, has roughly 150 people working across nine countries and speaking 23 languages. That makes us pretty unique in a way. And we basically deliver online solutions in an agile way. We build websites that just work. About the Ignite's introduction here, as you might have noticed, my slides are on auto advance here, 50 seconds for each slide. We have 20 slides for each presentation and a quick calculation gives you roughly 300 seconds is five minutes for each presentation. When I'm done talking here, Steve is going to be talking about risk. Thomas here will be talking about predicting the future. Janik and Benedict will tell us something more about custom layouts. I think Anne will be shouting about herself. James will talk about the balance between theory and practice. Mark knows about managing expectations. Mike about install profiles, Becht about his love for the community, Bernd about learning a new language. Roy talks about responsive design. And finally, Emma talks about giving hugs. Okay, thank you and enjoy the upcoming 55 minutes. Next up. Thanks very much, Rool. We have a great team of people here and we're going to try and make it entertaining, fast paced, a great way into lunch here at Drupalcom. Now, my name is Steve Parks. I'm the managing director of the London office of Wonderkraut, where we're called Wonderroot, just to be a little bit different. We do the same across Europe and all our different offices. One of the things that we do a lot of in the UK is coaching for agile projects, working with large organizations. So today I want to talk about one of the things we talked to clients about, a reasonable approach to risk, handling the unforeseen. Because has anyone ever had anything unforeseen happen on a project they've been on? Yeah, any surprises? Yeah, you know what, it happens. And no matter how much corporates try and make sure their projects are risk-free, something still goes wrong and the projects can go down like the Titanic. And so what happens? They respond to that, not in a healthy way, but in a way that actually causes more damage. They make rules. They set rules. We can't have another Titanic. Let's set a rule, no drowning. That will solve the problem. So the procurement department steps in, the legal department steps in. Contracts get thicker and heavier and more weighty. Rules get more petty and tiny. And these rules multiply across the organization. Everyone is trying to keep track of them all of the time and obey every single thing. And it means you can't stick to the contract anymore. And so what happens is then people get things done in the organization are the mavericks, the ones that are willing to just go beyond the rules a little bit. So the rules are then seen as meaningless. Because the only way to make the project happen is to bend the rules. But worse than that, what you also have is people that won't bend the rules. Corporate life is full of these. So you get people coming to a complete standstill when they perceive there may be some kind of small rule that they could fall foul of. And it could be damaging to their career or their prospects. Then people take the rules even further, enforcing them in crazy ways that are damaging to the project. And this just causes massive amounts of damage. So they put in more rules, more rules all the time to try and prevent these things happening. In Wales, they have the language Welsh. Of course, very few people speak it. The government insists all signs are in both languages. They email off a translation, a request for translation. That request comes back with the translated text in Welsh. And this road sign says in Welsh, I'm out of the office at the moment, but we'll respond to your request for translation tomorrow. And yet they have contracts full of rules and full of regulations to try and prevent things from going wrong. So all the time warnings get more and more crazy. The rules, the regulations, they weigh things down all the time and it causes massive damage. And the key is that something is missing. Something has gone from the way that projects have run. There's an emptiness. There's a vast emptiness of trust. Trust is what makes web projects work. And for trust you have to have a number of things in place. You as an agency have to demonstrate responsibility. You have to show you have the right people for the job with the right level of training and expertise that they can execute it properly. You have to show that you have the right tools and professional practices for the job so that you're not doing crazy things like a hacking core or this. You have to have that professional approach that clients respond to and build trust. And that's the only way to get things done. Then of course you have to have some element of planning. And too often people think agile means no planning when in fact it means responsible planning. These workmen were hired to put up bollards to stop people parking in this space. Can you see what they've done wrong with their lack of planning? Someone here was watching them from their apartment trying to get out for hours after they'd done this until they had to dig that up. You also have to put users at the center of what you're doing rather than rules and regulations. Consider what the end users need, not just what the rules and regulations say because you can do all you want upfront as the contract says, but users will want something over here and that's what's best for the client and the project. Transparency. Transparency is key to stopping bad behavior. Don't put rules in place. Just make sure that when people are doing things wrong when something's going wrong on the project, it's really, really easy to see and live what you believe. Show an example. If you're believing in certain ways of working, do them all the time and be seen to do them all the time and then have a healthy attitude to risk. That means there will not be no risk. You have to have a sensible attitude. Go in brave, go in with the right equipment and go and get that cheese, that project cheese because it is worth it, but you have to take a reasonable, responsible approach to risk and not try and pretend there'll be no risk ever. That's me. Feel free to follow me on Twitter, tweet me with questions or anything like that. Thank you very much. Thank you, Steve. Entertaining as always. My name is Thomas. I represent the Stockholm office of Wunderkraft. I work with web strategy and I will talk to you about a concept that we call impact mapping or it's called impact mapping. And it's really something that we practiced for some time in Sweden now and we really love it. And it's a way to manage agile and project expectations, I would say. And first of all, I'm really happy because we've been practicing agile for quite some time now and it's creating great results for us both as a company, but for our employees and we're more efficient and agile is really, really, really cool. But agile is not really enough when it comes to managing projects. Especially if you look at Scrum as a process, it will help you to prioritize but it won't really help you to tell which features it's better than the other. So what is impact mapping? Well, the easy answer is four words and it will give you a simple way to visualize your project and its goals. And it starts with why. It always starts with why. Why is the best tool we have in our daily work? You always need to know why you need to do something to really be able to help someone. So don't forget to say why. The next one is who. And who helps it, why? If you don't know that, it will be hard to tell what kind of features or what you need to do in a project. Who can be a role or a system or a persona? Next thing is how. We want to know how, who helps us with why? How can a person or a system produce the desired effect of a project? The next thing is what. We love what. We love to talk about what in a project. Features is what we are passionate about. But this is the gender zone. This is where you can crash a project. So I will give you a small example of how you can do this in a project. It's an online magazine and their business is driven by ads, basically. Quite standard way to do it for an online magazine. So we start with why. They want to increase their incomes to one million euros per year and they want to have a fixed deadline to this in 2016. This is quite different from just saying increase traffic or release a new brand. And specifically when you look at it as this, you need to define a KPI for your project. What is it really you want to achieve and how do you measure that? So in this case, we come up with a KPI that is saying that, well, to generate this income we need this amount of page views. So the next level is who. Who will help us reach this goal? We have visitors, editors, advertisers, sales department. They all can produce something to help us reach this goal. So the next level is how. In this case, we just look at the visitors. Well, how can they produce more page views? Basically, registering on a site, sharing articles, staying longer on the site. We can assume that these activities will help us. The final level is what? Now we're into something that we normally discuss in projects. Maybe a lot of uses to connect through Facebook or just a simplified registration form. The result of this is maybe something that we're really used to see. A user story or an Epic user story. And the thing is that if you start with this, it's really, really hard to see if you're really bringing any value to the project. So this is a simplified picture of how it might look in the end. It's really, you should keep this really simple. The less, the better. And as you see here, a good project is not that complicated if you visualize it. And the awesome thing is that everyone will understand this. A visualized picture of your project and what you wanna achieve. And you can do this in a few hours. If you wanna read more on this topic, I recommend you looking into these links. It's really awesome. It changed my life in projects, basically, to do this. We even do this for our internal management right now. Thank you very much. Next. Thanks a lot, Thomas. So my name is Spennyk and this is Janek. We are from the new Berlin office of Wunderkraut. And we want to tell you something about custom website layouts. So what is this all about? The layouts we think of as some kind of product or page layouts which differ on every kind of page. So you have every product should display in a different way. You have different headers. Even a content should be displayed in some kind of different way. So we came all the way to Amsterdam to show you some kind of new way to building this. Let's basically build on some stuff you already should know. So Janek might want to show us something about that. Yeah. Group 7 is almost four years old and we think it's time for something new and we want to show you new techniques to create fancy websites with a gorgeous editor experience. And yeah, today we are going to present you something and we have a solution for you and we are using common contract modules which everybody of you may know and we also created for small modules which you can download on Drupal.org and yeah, our solution is not a big thing. It's just, yeah, they're not big modules. It's based on standards, you know and there are no cross dependencies and it's highly customizable and it's also possible to implement new things, surprise, implement cool things like, you know and yeah, thanks to our committers who made this possible. Okay, so just to make this a little bit more graphical, so we have to Drupal Core. Basically we are using just nodes, entities and fields to all know about that. Combine this together with some display suit magic. Magic is a bit much, it's just some custom few modes and together with anti-reference we can all combine the content. So in the end, you got all on the same page. Usually you have a separate page for the design, one for the content and maybe some more other pages. We are connecting it to one node which is currently displaying the page. So you can see it like here, you have the node as the auto wrapper. It contains all the meter data for example at a product or product price, the country where you can buy it and so on and the content itself is separated in sections and sections itself can contain contents. So like I said, you can store all the meter data in the nodes itself and the good thing, also good thing is it's just listed on the content page so you don't have a lot of different entries on admin content so you'd have just one. Next thing is you have sections and Janik will tell us about that. Yeah, the content is divided into sections and you can put different type, different kind of content into these sections. So imagine you have a section and in the section I can put an image and a text and you can also create three texts or one image and two texts and yeah, everything is possible and we have reusable, we can use them in multiple places and yeah, you have the droopy power. So just create a new content and content type and then you can add feeds and you can create new contents and you can also put views into it or blocks and yeah, for custom coding you can also create C2 content types and everything is possible with this solution and without panics, it's core plus the SN. Okay, so like Janik just said you need no custom content to achieve this. You can just use basic modules and some small happen modules we created and it's just below 1000 lines of code and this is not much for droopy modules and all the modules together, not each one and in the end we have a win-win situation. We try to use the droopy way to achieve this so if you want to improve the idea we have it's not the final thing. You can contribute to droopy itself, create patches for modules already accessed and improve that way droopy is working. So for droopy 8, we have the good thing, we use the basic stuff so we should be possible to port this and yeah, might not be that special but here you can see we have some kind of. You can test it. Yeah, you can scan it and test it so we have an discrete version for that and there's also default content in it. It's responsive, CO-optimized and yeah, also a lot of other droopy Wunderkraut best practice in it. Thank you very much. Check out the box later. And we have a box here later so you're welcome to join. Good afternoon. My name is Anne. I am CMO and partner for Wunderkraut in the binelogs. We're based in Ghent, Antwerp and Utrecht. I live in Ghent, which is a great city. You should come and visit whenever you can. I'm often on the road and what I like to do is I like to share ideas about how to make complex things simple and preferably I do that over a cup of coffee or a glass of wine. Where do we come from? Actually, we own a strategic marketing agency with a strong focus on two things and that is taking into account and user needs and simplifying business propositions. Since a few months, we've been teaming up with Wunderkraut because we believe that a combination of strategic thinking with smart web building can generate a complimentary offering into the market and that helps our customers grow. How do we do that? We always start from the business perspective because a website, even when it works from a technical point of view, that doesn't mean that it is a great website. It's only great when you have a digital strategy just like building a house. You don't build a house without an architect either. You need to have a plan and successful companies know that they need that type of plan. And that plan consists of three things. The first is successful companies understand that customers do not buy products but that they want to fulfill a specific need. For example, people go to Starbucks not for the great coffee but to have a meeting space. Secondly, successful businesses never copy others. They never copy others because they know that it is better to stay truthful and to stay close to their own DNA because if you copy, you're only a shadow of the other one. And third, successful businesses create content. They create content and they think transactional. They make their content shareable and they create lots of call to actions. Did you know that today about over 50% of all business decisions are being taken online? And that is why we believe that a website should function like a mirror. What do we do? What do we mean by that? A website should work like a mirror. We mean that people should recognize themselves in the content you bring. You should connect with their experience and they should find exactly what they want. In other words, a site should never be too much about you. It must not reflect your company structure or say that you are the best. And if you do so, it may well be that that is the reason why you don't have too many visitors. Same is true for persons. Did you ever trust a person that says I'm a great manager or I am a fantastic entertainer? No, well the same goes for great companies. Companies that are great never say so. They only prove it. And to prove that you have great content and that you have a great company, you have to offer experiences and you have to earn your customers. You have to turn them into advocates and then they even become a channel and they tell everyone how great you are. And this is what I actually learned from having worked very long in the airplane industry and that these planes are planes. It is the airline that makes the difference. The same is true for websites and for companies. Being recommended is the best you can get. And I think if Confucius would come back today, he might as well add a sentence to his famous quote. So this brings me to almost the end of my presentation. So content and consistency is really important. And actually I would like you to remember three things and that is most decisions are being prepared online even in an offline business. People don't buy products but they want to fulfill their own wants and needs. And third, a website only adds value when visitors recognize themselves in what you say. So I would like to thank you and I would also like to invite you to our one on a boot to further discuss this type of ideas or to come and discover our healthy web approach. And I'm now happy to give the floor to my colleague James from Estonia. Hi, I'm James Nesbitt. It says Estonia, I'm actually from Latvia. But no, no, no, it says Estonia, what can you say? But maybe I'll come to Estonia too. So I'm gonna do a bit more of a developer-oriented presentation. As you'll see from my slides, I'm a backend developer. But I thought I would try and talk a bit more about our practices when it comes to being a developer. And I'll do it a bit from a case study perspective from something interesting that happened to me in a project this year. So I finally did my first, these single page app applications this year. So the one I did was Marinette, but so I'm talking about Angular and this kind of stuff, which I was really excited to do. I'd been waiting for this kind of thing. And the experience was great. It was conceptually what I wanted. I wanted to get away from this old concept of we're serving documents. No, we're writing apps. And these two pages, they look the same, but they're actually completely different and refreshed. And there's a wide space in between. All the things I didn't like, I got to get away from. So the problem was is we had all these concepts that we wanted to do. And when we got there, we realized we had only one problem. We're actually incredibly lazy developers. And that's kind of good. We had this complex interaction that now happens. And we thought we understood it, but all these really complex things were happening. What happens is that we had, it's really fast. So we thought we knew what it would be, but things moved around really fast. And in particular, what happens is things last a lot longer. And when they last a lot longer, we had these really interesting problems that were realized. And what I've been doing is I've been relying on this refresh or request as a reset. And it was actually pretty damaging for us. So the thing about lazy is that it's good. We all know that developers are supposed to be lazy. We're supposed to minimize effort and minimize cost. But when we got into this kind of thing, we found that, I feel like this lies in the wrong order. So here's an example of what would go wrong in a single-page app. You have all these things that are connected that are in space at the same time. And they move around. Events are connected across aspects and it gets really confusing. So I'll just, I'll slow down and skip one, actually. The thing is that our developers outside of the web, they already know this stuff. Desktop developers, app developers, they don't have refresh and requests. And I was thinking, as a developer, I don't wanna change my practices too much, but maybe I can look for tools that other developers might have. I don't innovate, but I do need some kind of solution that can come in. So, and of course, I don't mean just technologies, but approaches and concepts as well. So I was working on this app and trying to figure out actually what's going on in the time and debugging. And I found this really interesting thing which you can't read. It says a state controller. I thought about that. I'm like, state. I have no idea what that state controller is. And then it dawned on me. This complexity problem that I was having in my application was actually really a state problem that reminded me of all of these computer science classes I had talking about state. In there, there was a state controller and state models. The only purpose of this thing was to handle changes in state. And I realized that we can switch to an approach of thinking about state. This developer concept, programmatic approach. And instead of having views, the trigger events that happen in controllers change models and go back to views, we can tie everything into single, single, single. Single, right. So single changes that happen only in these state controllers. And give us this great single place where everything can connect into. Instead of this view, this model, and this controller, changes that happen go directly into only these state controllers and models. You want to, for example, if you want to initialize a root, you just initialize the state. You respond and display state. If you need to re-initialize it, it's the same process that happens again. It was a small change for us. We didn't require a massive change in thinking, which was great, but it solved our complexity problem. And it helped us write apps that were actually smarter. They knew what they were. They could self-heal. And they had a really much easier approach to get into, to develop. So, and I attempt to just stay as a developer and solve client problems and not completely revolutionize it. What I did was I pulled in small amounts of tools and used small changes to slightly change the way I work. But I tried to stay focused on being a developer. Hi, I'm Agnes, Managing Director at the Stockholm office of Undercrow. And I will switch topics again and now into something that correlates to what Steve said earlier about managing expectations and the importance of using the steering group of your project as a tool for doing that. First of all, I think everyone here has been in a failed web project because web projects fail. They failed regardless of your project model, your process. I would say agile projects fail a little bit less than other projects, but some of you may disagree. Projects fail for a number of reasons. But what's interesting is they almost never fail for technical reasons. It was too hard. That almost never happened. But the highest reason for failure is lack of communication in the project. And I want to address a specific topic here and that is my feeling is that when the project fails, the reason is it didn't deliver what was expected by the client. So why didn't we deliver what was expected? What the client expects is really simple. They expect the scope to be delivered on time and on budget. Could it be any simpler than that? It couldn't be harder anyway. Well, I've been through this, but the problem is, as you all know, many small decisions are made through the project from day one to the last day of the project. But not everyone is normally involved in those small decisions. And that's why we're using, why we're using the steering group to do that. And what we use to talk about something we call the expectations gap. In the beginning of the project, we all have a picture where we headed. We as an agency have almost the same, hopefully, ideas on where we're going. The client have hopefully similar ideas. But then through the project, all these decisions are made and requirements are changing. And the expectations are changing. So we end up here, especially the high up in the client side, their expectations are still where they were in the beginning of the project. So what we want to do, and we do in all our projects right now, we use the steering group to set expectations and to manage them through the project. The first thing we do is have a workshop with the steering group and see that all the important persons are in the steering group and we meet regularly. In this workshop, we agree on the business objective of the project. And then we talk about this. So we say, what do you expect? You can have the scope, you can have it on time, you can have it on budget, but you can't have them all at the same time. Please prioritize. And then we do a simple thing. We draw this on a whiteboard and then we give everyone in the steering group a bunch of post-it notes and they need to put these with a name on it somewhere on this triangle. This is a really, really good way to really start talking about the priorities of the project. And you often end up with the editor guys, they're here, finance guys over here and then you have some other, but this is really a good discussion and we can't come back to this every time we meet and we often meet every second week in the steering group because don't summon the steering group when you are in trouble. Summon them regularly. We used to say every second week, make sure you have the decision makers there and always inform them about your progress and where you are in the project right now. Be transparent, use it to manage risk. As Steve said earlier, we use this way of displaying it or every steering group meeting, we present this and focus the steering group on making decisions to minimize the risks we have in this project. But meetings with the steering group are expensive, lot of people involved, a lot of important people and me too, often can't well prepared. We use a fixed agenda, fixed presentation we use all the time and we really feel that this way we can make the expectations gap a lot smaller and minimizing the risk for a project failure due to missed expectations. And if you meet expectations, you don't fail projects, basically. Thank you. My slides come up, thank you. Yeah. Solution of a filter, maybe not, but I'm a developer and working in Sweden as part of the support team and now my notes went upside down. If you can't install it, it's broken. I'm going to tell you this like 20 times now because the subject here is like, when you install Drupal from the first beginning, you can do it, but you need to have the workflow working in the end of the project also. So the site should always be installable. It should always, you can load the project, you should could install the site and yeah. So to have this workflow, you need to use profiles. Most of the projects I haven't seen use it, so that's good, but also with the profile, the project is version controlled and that's really, really important. Also, if we work with Agir in Wundercut, Sweden to deploy our sites, so and we need to have profiles to do that. And workflow we have is like install the site, develop, deploy. Sometimes we use the database from production, but that's only sometimes. When we have this kind of workflow, we know what we are going to deploy. Configuration should always be in code. I have the rant about this last night, but yeah, this is really important to have an install workflow on the site. It's easier to see what the configuration is when it's not in code. Don't activate business critical models, manual on production. That's, yeah, it should be like really crucial to not do that, because you need to control that also and don't deactivate models either manually. You have to put that in code. All new configuration can be done in features and you can deploy it with update hooks or something else, but if you use the install profile, you have control of them. Also, the best practice of doing a site, I think it's building a site and do it from the beginning again, but that's not possible. So if you have code in your code base that you're not using anymore, throw it away because all code sucks. It's, if it doesn't do anything good, it's just smelly and yeah, it's not good. Yeah, so I come back to this, but if you have a profile and you can install it, it's better version control because you know what models you're using, you know what you have put out on production. If you have the dependencies in the code, you will know that early on when you install it locally, when you do all the stuff, when another developer added some dependency and the site breaks. If you want to roll back, if something went wrong on production, it's much easier to do that if you have a version controlled configuration and it's, yeah, it's better than, oh, sorry, notepad. Yeah, this is crazy, but we have some clients that don't want us to access their production database at all. We have some financial clients that don't allow us to do that. So if you should work with their website, we need to install it without a bit of this. Yeah, and it helps and it proves stability. You don't get surprises. You get surprises, but not so very often. Less, it works locally, more happy customers, because if I can install a site in any time in the project on my local computer, it's, I'm guessing it's going to work for the client also when we deploy it, but we have deployed the code that we should do. If you can't install a site from the beginning, you have a code problem. There's nothing, you need to solve that. You need to figure out what is wrong in your code. So to have this, you have to have configuration in code. You need to solve problem before you give it to the customer. And this workflow we're installing a site that should be done in every stage, it's really, really important. So thank you. Hello. So how do you like Amsterdam? Okay. You know we've been here before. Amsterdam 2005 was DrupalCon here as well. I organized it. It's a long time ago, it's a long time ago. My user ID is 188. I can't code, I'm sales, right? So that makes me, yeah, that makes me probably the first end user of Drupal and probably the first end user in the community. And that's what I wanna talk about. You know, we have a saying, come for the code and stay for the community and it's wrong. Customers should come for the community, not for the code. Now we look at ourselves, but we're actually, as a community, we're a beast, right? We're not as open-minded as we think we are and our shadow tells stories about us we don't wanna know. So why should customers come for the community? Well, they don't come for headless Drupal. I mean, if you have your bullshit bingo card today, I don't know. If it all says headless Drupal, you would be all hands will be in the air. They come for the love, the love we have and the passion we have for our tool and that we come together and work for semi-free. So our community is really full with rich colors and genders and political and sexual preferences and all kinds of other stuff. And that's okay, that's what we are. And we should be proud of that. So, but we are also a bit scary where Herbie's watching Herbie. We are afraid of watching ourselves and we are afraid of ties. They will take over our system. What we said at this keynote is in fact very important because it's not about mobile first. Mobile first is a new internet explorer only. I don't like the slogan. It's business first, it's user first and maybe it's Drupal last, but still if it's Drupal last, the customer makes his money using Drupal from the money. It's built on the web and it's built on Drupal. So you can't say Drupal last, that's okay. But still it is Drupal and he needs to know the tool and he needs a party that's implementing the tool for him that understands, holy shit, I love you. This is the time that you, it's okay to hug someone next to you and say, holy shit, I love you. Do it, you will be fine. But that's what we are. So, and how do you bring that love of the, we feel for each other to the customer? Companies have learned to do that. Wunderkraut for example, knows how to align with the community, right? So, all we have to do is tell you and our customers how we can align with the community. Now this guy is not falling, he's not holding a board but he's not falling really. So why should you do that? I like buy-in versus lock-in. Property systems have a lock-in. We have a buy-in, the customer comes for us. If you turn around the Wunderkraut logo, have people seen that? It is in fact a Drupal con. So if this is the customer, the person we're all afraid of, the tie, the suit, the commercial entity, how do we turn our love and let him in the community? Well, four solutions. First solution is use his knowledge, the knowledge you have from the project and bring it in the community. 2014 and we still don't have an editor in core. That's strange because every customer asked for it, right? An HTML editor, that's weird. So, your second way is bring his code and his time in the community. So you all make modules for your customer. Donate them, ask him to donate them. And the third way is bring him towards the community. There are a lot of customers of Wunderkraut here present. And it sounds scary, customers not, but customers to your competitor. It sounds scary, but it's not, it's okay. And the fourth solution is even better, use the customer's resources to bring the community to the customer. He's got, if you organize scams, he's got a venue where you can go. So there are four easy ways of aligning your customer with the community. Now this is the tradition of you, right? We have the community and we have the commercial ecosystem. And that's not a healthy point. And that's what Dreech is. I think as we wanted to say, it should not be one first or the other. We should really think community includes commercial entities. And I think we're up at this point where this is a given fact and we should embrace it. There's nothing wrong with making money. Right? Okay. So these are our customers. You can see them walking around here. But really, customers are just humans as well. So it's okay that they are part of our community. And it's okay if they wear a tie or not. I'll drop the tie later. So my name is Bert Boerland. If you have enough time or too much time, follow me on Twitter at Bert Boerland. And thank you very much. Hello everybody. My name is Bang Tendres Drange. And I'm the Norwegian guy in the Finnish office. I moved to Finland two years ago. At that time, I knew a few Finnish words, which I cannot repeat here because that would be a major violation of the Drupal Code of Conduct. And during those two years, I've been able to pick up enough Finnish to be able to have a more or less sensible conversation. And what I'm going to do now is show you how I've been studying Finnish because I've also learned how to learn a new language. So many people ask me if Finnish is difficult to learn. And I have to say it's kind of language from a different planet. And still it's possible. The first thing I did was ask a lot of friends about how you say this, how you do this, how you, why is this written like this? And nobody could really answer it because people just speak the language, right? Native speakers, they don't know. But when I registered for a course, I found out that teachers are great at explaining languages. They managed to structure things and information in a way that's actually possible to follow. And they also gave us a lot of homework, like studying words for a chapter in the book. And I started using old-style flashcards, meaning that I wrote the Finnish word on one side and the Norwegian translation on the other side of this piece of paper. And I started memorizing them. And it's kind of nice until you have hundreds of words. Then a course might tell me about Anki, which is an app for the phone where I can do the same thing. And it uses a technique called spaced repetition, which actually is quite neat because it not only lets me go away with all the pieces of paper, but it also spaces out how much I repeat the different words so it knows what I know and what I need to study more. And this technique can be used to study anything. You could also probably study all the Drupal hooks if you want to remember them by heart. And it's really great at optimizing learning. There is just one thing that this type of studying, it's not a panache. You cannot study things that you don't already know. I'm on the wrong slide. And that's fine. So vocabulary is just one part of learning. And of course, if you memorize all the Drupal hooks, it's not going to help you unless you know how to use them and what they're for. And then next slide is that I also figured out that it's very good to study between Norwegian, my native language, and Finnish. Instead of downloading lists that other people had made of words that I wanted to study, I made my own because Norwegian is so much stronger wired into my brain. And also when I make my own lists, I know the words are more important for me so they're more relevant. And then there's the thing that you need to learn to speak as well. And it's kind of difficult because people tend to know how to speak English in Finland and they're always very helpful. So they might switch to English to help you. But then I figured out that there are some people out there who are actually quite helpful. Some people I met in parties, some girls that found me so cute that I was able to speak a little bit of Finnish so they talked with me all night and they were adapting the vocabulary and the language that we're using so I could actually follow. And during those kinds of conversations, I got to practice and now I can even speak with more and more and more people. And step by step, I've become more fluent. And then you need to start reading and it's very tempting to read text very careful and you know, you underline all the words then you look them up in the dictionary and it's really takes a heavy effort. And I did it and I put the words in Anki so it's been helpful. But I also try to just read stuff. I found some old 70s spy novels translated into Finnish. Very simple. And you know, just read and make sure that you get the idea and maybe not all the sentences. And then I've tried to listen to different news broadcasts in Finland. There is a brilliant one which is called Simple, with the Ulin news in Simple Finnish. They read slowly. It's great. Some tools I've been using, this is WebAxicon. It's based on the Wiktionary which is Wikipedia's dictionary project. And it has also conjugations of words which is very important when you're studying Finnish. And the other tool I've been using is Glaspi.com. It also has a dictionary. But the best thing here is it shows you the words in context. So they have loaded in EU legislation which is translated into quite many languages including Finnish and English. And movie subtitles which tend to be translated and they're great to see how the words are used. My first rule when I started studying Finnish was to never give up. And I realized after a while that actually the most important thing is to believe that you can. If you believe you can learn the language then you will not just block out every time you read something difficult. So what I've been gaining from this is now I'm more independent in my workplace. I'm not still able to speak super fluently but I can at least understand tickets, support tickets in Finnish. I don't need to ask my colleagues. And also I can survive more easily socially. And then I just want to thank my employer that actually paid for all my language courses and my books and everything and I want to thank you guys for listening. And just get in touch if you want to know more about stuff because five minutes short time I can tell more. Almost done. So yeah, my name is Roy. I work for both the Dutch and the Belgian offices as a UX designer. And today I want to talk a bit about our approach to making existing larger, largest websites available to on smaller devices, you know. Responsive design is a thing but you have a site out there. And it's not only that you have to consider the small screens that you have to make things work on. And there's the other side of the spectrum as well. Larger monitors, big TVs, outside public display systems and who knows whatever futuristic new devices will come out that we don't know yet what they will do. Because it's not only about screen sizes, it's also about different capabilities that we have to consider when going responsive. So you remember those mock-ups with an iMac and an iPad and an iPhone and then that was responsive design. Turns out it's not that obvious and it really never was. But it does make sense to start with the smaller screens because you have to admit it, your website's too fat. And that's not healthy, so we have to lose the fat. And that means you have to make decisions about what needs to go. And for that, whoa. Too much. You need to prioritize your content. And this means that you have to have a framework for how to prioritize your content. So one of the first things is know your customer. We've heard this a couple of times now but dig deep into who's coming to your site, what are they trying to do there and to what goal, so why are they doing that? Yes, no way around that. You have to know your customer. Second part of it is, okay, find all the layouts in your site, in your current site. There's different kinds of page templates that I use and you want to take an inventory of those. And then for each of those, decide how to reflow, how to stack that content. You know what the customer's coming to do, so now you can prioritize because small screens need simpler layouts, first things first. And along the way, you'll find some interesting challenges, light boxes, two big forums, tables, videos, maps that just won't let themselves fit into a small screen just like that. So you have to make another decision there. And there it's, do we go for a quick fix? Like maybe simply hiding it or removing it from the site altogether? Or is it so important that we have to rework these tables to become responsive? And for that, go back to your users, what are they going to achieve for making that decision and you can support your argument with analytics. If people don't use it, it's probably not necessary so we can cut it. So quick recap, no thy customer and based on those priorities, reflow your layouts for smaller screens. That also means that this is a process that not necessarily should you focus yet on creating device-specific features. You want to establish a baseline first. And don't confuse it with a redesign. This is, don't redesign at this point. What you want to do is focus on designing the right content because you're finding out about what works and what does not work. And that's what you really want to achieve when you retrofit this existing site. What you want to do instead of redesign is simplify the visual language. Probably, there's probably over-designed pages there where you have to make smaller tweaks that simplify so you get a more consistent look and feel. And with that, you establish a more generic, a more shared baseline for your content in a way that makes this stuff work across all devices and then maybe start thinking about device specifics. So in doing this, you've created, you've learned a lot about what content works and what does not work. And the stuff that you want to now have fixed, you want to create a process and a data model that you can use to, that you can apply when creating new content. So it's a learning process. And from that, thank you. Thank you, Roy. I'm so happy that there are still people here, so my colleagues did something right not to bore you. I'm Emma Macin and I work from our Finnish office and our Helsinki office. And today I'm going to talk to you about something very different and unique that we use. We have different kind of bonus system where hugs, in fact, turn into money. And we are not just bunch of dorks who hug each other. We do that as well, but we use virtual tool for that. So basically we wanted to have a business, a bonus system that would emphasize how important our people are to us, employees and managers alike. But traditional bonus systems, they simply don't work. They are basically unfair, targeted to a smaller group of people like sales or something like that. And then people start expecting to get money at a certain period of time, for example, around Christmas, so it can turn into negative. And we wanted to introduce a different kind of bonus system that is unique and positive in a form of the hug system. So basically this is more positive, it's fair and employees and management decide amongst themselves who they want to assign bonus and based on what reasons. So basically the hug system works that every single one of us has up to five hugs per week to assign to their colleagues or charity if they want via online tool. And then those hugs that people get turn into money based on company revenue. And we pay these hugs out randomly so there are no false expectations and distribute the hug comments regularly so that people actually know why they were hugged. And reasons for this and value for the hug system for the company is that we actually get very valuable feedback and peer reviews out of the employees. They get to decide themselves who to hug, who earn the money and the employees themselves, they of course get the positive feedback, they get the comments distributed by our manager himself and extra income never hurts anyone. So basically we have been using this hug system since November 2013. It started out as an experiment and we really very early on noticed that the true value of the hug system are the comments themselves. So basically when we distribute the hug comments to our employees, they get valuable feedback and that's the actual positive thing and of course there's money in it as well. People really liked the hug system. It's been a really positive thing and people talk about the hug system and people seem to prefer virtual hugs over physical ones for some reason because you get money out of that. But basically because we have used the hug system a long time now, we have very extensive data out of the hug comments and we did an analysis of that. And here you can see the distribution of how and why people hugged. So 52% of all hugs given were given based on performance. So basically people got rewarded by how well they did their job, how well they functioned in a team and how others thought that they actually did their job. And then 29% was given based on support and encouragement. People noticed that someone is stressed out with multiple projects, for example, they give money encouragement in a form of hug system. And then 14% of all hugs were given based on personal reasons. Getting married, having a baby, new haircuts or an inventive lunch idea, for example. So basically whatever reason people wanted to give each other hugs, they can do so. There's no limitation. And this is the only thing that's left. So 5% of all hugs were given with no comment at all. And because the comments are really the core of the hug system, these types of comments should be kept minimum. And we are currently improving the hug system all the time. We are making the hug system responsive with mobile app and it gives sense out reminders to people. So that they can actually know when and why they have hugged. So basically what I want you to learn from this is that positive feedback is really the core. And us get money from giving positive feedback. So that basically never hurts. So thank you so much. This was my presentation, more internal one. You can find me on Twitter as well. And I'll finish now. Thank you. OK, we're done here. Everybody is still in the room apparently. So that might mean something. All of us will be around at the Drupal Common in the coming days. So if you see someone wearing a strange carrot, just approach them if you have any questions about all of these topics. And all you can come to the Windencrow booth if you have any more comments. Are there any small questions at this point? We still have three minutes left. Any questions you want to handle now? Please state the name of the person you want to ask the question to. No? OK, thank you all. Bye.