How to create a universal ReactJS application with Flux

Anna Ślimak December 10, 2015

Erstwhile in the series

flux logo In the last post we created a simple application, using just bare React.

Full code of the application is accessible here.

The important thing to notice is that we hold the state of the app in many places. In a more complicated application it can cause a lot of pain :)

In this post we will update our app to use a more structured pattern for managing the state – Flux.

Why Flux?

Using bare ReactJS was easy, but our application is simple. With lots of components, having the state distributed all over them would be really tricky to handle.

Facebook experienced such problems, from which a very well known one was the notification bug.

The bug was that you saw the notification icon indicating that you have unread messages, but when you clicked the button to read them, it turned out that there’s actually nothing new.

This bug was very frustrating both for users and for Facebook developers, as it came back every time developers thought they already fixed it.

Finally, they realized that it’s because it’s really hard to track updates of the application state. They have models holding the state and passing it to the views, where all the interactions happen. Because of this, it could happen that triggering a change in one model caused a change in the other model and it was hard to track how far to other models these dependencies go.

Summing up, this kind of data flow is really hard to debug and maintain, so they decided they need to change the architecture completely.

So they designed Flux.

General idea

First of all, you need to have in mind that Flux is an architecture, an idea. There are many implementations of this idea (including the Facebook one), but remember that it’s all about the concept behind them.

And the concept is to have all the data being modified in stores.

Every interaction that causes change in the application state needs to follow this pattern:

  1. create an action – you can think about it as a message with a payload
  2. dispatch the action to the stores using a dispatcher (important: all stores get the message)
  3. in the view, get the store state and update your local state causing the view to rerender

You can have many stores and there is a mechanism to synchronise modifications done by them if you need it.

I recommend that you read a cartoon guide to Flux, the architecture is explained really well there, and the pictures are so cute! :)

Smart and dumb components

A thing worth emphasising is that some components will require their own state. We will call them “smart components”. Others, responsible only for displaying the data and attaching hooks, we could call “dumb components”.

“Smart components” don’t modify their state by themselves – like I mentioned earlier, every state change is done by dispatching an action. They just update their state by using a store’s public getter.

“Dumb components” get the state by passing needed items through props.

Let’s fluxify our app

Let’s add new dependencies to our package.json by running: npm install –save flux events.


As I said, all state changes need to be done by dispatching actions. We need to create src/AppDispatcher.js then:

Action types

It’s good to have all action types defined in one file. Create a src/constants directory with ActionTypes.js inside:

Action creators

Now we will define the SubmissionActionsCreator:

SubmissionActionsCreator uses AppDispatcher to dispatch needed actions.

As you can see, an action is just a simple Javascript object with data that the store will need to calculate the state change.

An important key that will be always present in action object is actionType – one of the constants listed in the ActionTypes.js file.

Here we also need the submission id and sometimes rate.

Now we can update our smart SubmissionPage component to use SubmissionActionsCreator instead of just directly accessing the API:


And the last thing we need is to add the store where our state will live:

  • getSubmission – a public getter that we will use in our smart component to update its local state based on store state
  • addChangeListener – an interface for subscribing for store state change
  • removeChangeListener – an interface for unsubscribing for store state change
  • emitChange – a private store method for notifying about store state change

Notice also the AppDispatcher.register part, where we do the actual request to the API, update the store state on success and notify all subscribed components that the state has changed.

Now we can update our smart SubmissionPage component to use SubmissionStore.

The whole SubmissionPage class should look like this:

In componentDidMount we use SubmissionActionsCreator to dispatch requestSubmission.

Because in componentWillMount we subscribe for store change using addChangeListener, we will be notified when the submission is loaded from the API.

Remember to unsubscribe in componentWillUnmount.

Thanks to the subscription, the onChange method will be called on store state change. And in onChange method we can update the local state to the current store state then.

Exactly the same mechism is used in performRating.

That’s all!

We updated our application to use the Flux architecture. It’s definitely an improvement over using bare ReactJS. We have more control over the application state.

But it has some downsides too. If the application grows and there are a lot of stores it’s hard to synchronize changes, especially when the stores depend on each other.

I will write more about this in the next post, where we’ll introduce Redux to our application.

For now, you can practise a bit by fluxifying the rest of the application.

Full code accessible here.

See you next week!

Previously in the adventures series

react logo

In the last post we decided to use following tools:

  1. Server side Javascript rendering – Express as the frontend server
  2. JS written in EcmaScript6 syntax – transpiling ES6 to ES5 using Babel loaded through Webpack
  3. Stylesheets written in Sass – transpiling SASS into CSS using sass-loader for Webpack
  4. All Javascript bundled in one file and all stylesheets bundled in another file – Webpack
  5. To minify assets (js, css) for production – Webpack
  6. A mechanism to watch for changes and transpile on the fly in development mode, to speed up workflow – Webpack
  7. Something to handle external dependencies – npm

Now we’ll learn how to set them up.


We will be creating a simple application for rating submissions. This is a really simplified version of the application we used for evaluating submissions for a RailsGirls event.

We need a form for creating new submissions:

submission form page screenshot

We will display pending, evaluated and rejected submissions in separate but similar listings. All listings will have “first name” and “last name” columns, evaluated submissions will additionally have a “mark” column and rejected will have a “reason” column.

evaluated submissions page screenshot

The last view that we need is the detailed submission view with the rating.

submistion details page screenshot


Firstly, let’s create package.json with the application dependencies:

Take a look at the scripts key, it’s where we define the application tasks:

  • babel-node – to be able to write server.js file in ES6
  • start – for starting the server in development mode
  • build – for building production assets
  • production – for starting the server in production mode

To install the specified dependencies run npm install from the console, in the project directory.

Babel 6 requires also .babelrc file. Let’s create it then:

To start the server execute npm start.

To run in production mode execute npm run build first and then npm run production.


As you can see, we are running the server by executing server.js. We need to create it then:

Now let’s understand what different parts of this code do. This line creates an Express application:

Which we’ll configure later:

And then we start the actual server:


By default Express looks for the view to render in the views directory, so let’s create our index.ejs there:

There are two important things going on here. Firstly, this is the div where all of our app will be injected:

Secondly, we attach bundle.js (and bundle.css) only in development:

It’s important to do it only for development because in production we’ll have our assets minified with fingerprints (e.g. bundle-9bd396dbffaafe40f751.min.js). We’ll use the Webpack plugin to inject javascript and stylesheet bundles for production.


Development config

We included bundle.js, but we don’t have it yet, so let’s configure Webpack. Create a webpack directory and inside add the file development.config.js:

  • entry – defines entry points, the places from which Webpack starts bundling your application bundles (see the actual value in the shared config below – two entry points, one for stylesheets, one for javascript)
  • output – defines where the output file will be saved, how it will be named and how you can access it from the browser
  • module – defines loaders (for transpiling ES6, sass, etc.)
  • plugins – defines plugins (e.g. we use ExtractTextPlugin to extract the stylesheets to a separate output file)

Some parts will be shared between development and production, so I extracted them to default.config.js:

As you can see, here we configure:

  • how our bundle will be named,
  • on which port our server will start,
  • where our static assets will be served from (we use it in server.js),
  • entries which are the starting points for bundling,
  • loaders which we want to use:
    • babel-loader for ES6,
    • css-loader for ExtractTextPlugin
    • sass-loader for Sass

Production config

As I mentioned, for production we want assets to be minified and attached in HTML with fingerprints. That’s why we need a separate config:

Entry points

We specified entry points to our application as: src/application.js, css/application.scss – but we don’t have them yet. Let’s add them!

Create application.scss in the css directory:

Also download these two css files and save them in the css directory: main.scss, normalize.css. Then create an application.js file in the src directory:

This file is the entry point for our client side application. Notice the render method – it’s responsible for injecting your component tree into the specified element. For us, it’s the div with “app” id.


In application.js we imported the routes.js file that we don’t have yet.

Let’s create only two routes for now:

This means that when we go to /submissions/new, the SubmissionFormPage component will be rendered. But notice that the route is nested in the / route, which is assigned to the Main component.

It’s because we want Main to be some kind of layout component, with the menu, which will be visible all the time.

And all its child routes will be rendered inside the Main component thanks to the this.props.children directive:

And in SubmissionFormPage we would have the actual form:

Create the above components in src/components directory. As you can see, each ReactJS component has a render method which defines the HTML to be rendered. It’s not pure HTML, it’s HTML in Jsx syntax, to make it easy to write HTML in Javascript code.  

Connection to API

In the above file, you could also notice that when submitting the form we make a request to the backend API. We will use Axios to do this. Let’s create src/lib/Connection.js:

Displaying submissions

To check if everything works, it would be convenient to be able to see the pending submissions list, so let’s create PendingSubmissionsPage:

As you can see here, in componentDidMount we load submissions from the API and assign them to the local component state. Then we pass them to the SubmissionsList component which is responsible for rendering the table. SubmissionsList:


To have some kind of backend, you can clone and setup this very simplified backend app. Just follow instructions in the README.

Starting the app!

Now we can finally test if everything works. Run npm start in the console, and go to http://localhost:3000 in your browser.


Now we can implement the rating feature itself.
Let’s add SubmissionPage:

Again, in componentDidMount we load particular submissions from the API and assign them to the local component state. But the most important part is this:

We pass performRating handler as props to the Rate component:

And again pass performRating further, to the RateButton component, where we have actual rate value defined.

Here, finally, we have it bound to the onClick event because only here do we know the particular value for a rating – this.props.value

Thanks to that, when a user clicks a rate button, the performRating method defined in SubmissionPage is called and a request to the API is made.

Let’s add a route to the src/routes.js to be able to access the view:

That’s all!

We just created a simple application using bare React.
The important thing to notice is that we hold the state of the app in many places. In a more complicated application, this can cause a lot of pain :)

In the next post, we’ll update our app to use a more structured pattern for managing the state – Flux.

For now, you can practise a bit by adding the missing EvaluatedSubmissionsPage and RejectedSubmissionsPage.

The full code is accessible here.

See you next week!

Demistifying Modern Javascript Tools

Anna Ślimak November 26, 2015

The goal

ReactJS has become very popular recently, the community is growing fast and more and more sites use it, so it seems like something worth learning. That’s why I decided to explore it.

There is so many resources and so many examples over the internet that it’s difficult to wrap your head around it all, especially when you are new to the modern frontend stack.

There are examples with ES6 syntax, without ES6 syntax, with old react-router syntax, with new react-router syntax, examples with universal apps, with non-universal apps, with Grunt, with Gulp, with Browserify, with Webpack, and so on. I was confused with all of that. It was hard to establish what is the minimal toolset needed to achieve my goal.

And the goal was: to create a universal application with development and production environments (with minified assets in production).

This post is the first of the series describing my journey while learning modern Javascript tools. It has the form of a tutorial how to create a universal app using bare react, then Flux and lastly Redux.

Why universal? What does it mean? Do I need this?

The easiest way to create a ReactJS app is just to have an index.html file with ReactJS library included as regular Javascript file.

It seems easy, so why have I seen example applications which have their own frontend servers? I started wondering why would I even need the server if I can just have a simple HTML file.

And the answer is: sure, you can create a modern dynamic application just by using simple HTML file, but you need to keep in mind that it’s content will be rendered on the client side only.

It means that if you view the page source in the browser, or make a curl request to your site, all you will see is your main div where the app is injected, but the div itself will be empty.

If the above doesn’t convince you, then perhaps this will: Google bots won’t see the content of your app if it’s only rendered on the client side. So if you care about SEO, you should definitely go with a universal app – an app which is not only rendered dynamically on the client side but also on the server side.

To achieve this you need a separate server for frontend.

You can see people referring to these kinds of apps as isomorphic. Universal is just a new, better name.

Modern Javascript tools

My goal was to create a separate frontend app with following characteristics:

  1. Server side Javascript rendering. So we need a server for this.
  2. JS scripts written in EcmaScript6 syntax. So we need something to transpile ES6 to ES5 (ES6 is not fully supported in browsers yet).
  3. Stylesheets written in Sass. So we need something to transpile SASS into CSS.
  4. All Javascript bundled in one file and all stylesheets bundled in another file. So we need a file bundler of some sort.
  5. Assets (js, css) minified for production.
  6. A mechanism to watch for changes and transpile on the fly in development mode, to speed up work flow.
  7. Something to handle external dependencies.

After looking at many examples on the Internet, my mind looked like this:

JS word cloud

I didn’t know what all of these tools do exactly and which of them I needed. E.g. do I need “browser-side require() the Node.js way” if I already decided to use ES6? Do I need Bower if I already have npm? Do I need Gulp at all?

After lots of reading I finally managed to group the tools:

JS word cloud grouped

EcmaScript6 (ES6)

ES6 is the new Javascript syntax, standardised in 2014. Although it’s not implemented in all browsers yet, you can already use it. What you need it to somehow transform it to currently implemented Javascript standard (ES5). If you are familiar with CoffeeScript, it’s the same process – you write using one syntax and use a tool, e.g. Babel to translate it to another. This process has a fancy name – transpilation.

As ES6 introduces lots of convenient features which will soon be implemented in browsers, in my opinion there is no need to use CoffeeScript right now. That’s why I choose to use ES6.

Module definitions

One of many convenient features of ES6 is the ability to define modules in a convenient and universal way.

Javascript didn’t have any native mechanism capable of managing dependencies before. For a long time the workaround for this was using a mix of anonymous functions and the global namespace:

Unfortunately, it didn’t specify dependencies between files. The developer was responsible for establishing the correct order of included files by hand.

As you can suspect, it was very error prone.


That’s why the CommonJS committee was created with a goal to create a standard for requiring modules.

It was implemented in Node.js. Unfortunately, this standard works synchronously. Theoretically it means that it’s not well adapted to in-browser use, given that the dynamic loading of the Javascript file itself has to be asynchronous.


To solve this problem, a next standard was proposed – Asynchronous Module Definition (AMD).

It has some disadvantages, though. Loading time depends on latency, so loading dependencies can take long too.

Incoming HTTP/2 standard is meant to drastically reduce overhead and latency for each single request, but until that happens, some people still prefer the CommonJS synchronous approach.

While setting up Babel you can choose which module definition standard you want to have in the transpiled output. The default is CommonJS.

So when you define you module in new ES6 syntax:

It will be translated to the chosen standard.

If you’ve chosen CommonJS the above module would be transpiled to:

And for AMD:

Module loaders

Having standards for defining modules is one thing, but the ability to use it in the Javascript environment is another.

To make it work in the environment of your choice (browser, Node.js etc.) you need to use a module loader. So module loader is a thing that loads your module definition in the environment.

There are many available options you can choose from: RequireJS, Almond (minimalistic version of RequireJS), Browserify, Webpack, jspm, SystemJs.

You just need to choose one and follow the documentation on how to define your modules.

For example, RequireJS supports the AMD standard, Browserify by default CommonJS, Webpack and jspm support both AMD and CommonJS, and SystemJS supports CommonJS, AMD, System.register and UMD.


Your app usually depends on some libraries. You could just download and include all of them in your files, but it’s not very convenient and quickly gets out of hand in larger projects.

There are a few tools for dependency management. If you use Node.js, you are probably familiar with it’s package manager – npm.

Another very popular one is Bower.

Since I needed to use Node.js to implement the frontend server, I decided to go with npm.


In npm, all libraries are exported in the same format. But, of course, it can happen that the library you want to use is not available via npm, but only via Bower.

In such chase remember that some of the libraries may be exported in a different format than what you’re using in your application (e.g. as globals).

In order to use those libraries, you need to wrap them in some kind of adapting abstraction. This abstraction is called a shim.

Please check your module loader documentation how to do shimming.

Task runners

If you use npm you can define simple tasks in your top-level package.json file.

It’s convenient as a starting point, but if your app grows it may not be sufficient anymore. If you need to specify many tasks with dependencies between them, I recommend one of popular task runners such as Gulp or Grunt.

Template engines

Template engines are useful if you need to have dynamically generated HTML. They enable you to use Javascript code in HTML.

If you are familiar with erb you can use ejs. If you prefer haml, you would probably like Jade.


Last but not least I need a server. Node.js has a built-in one, but there is also Express.

Is Express better? What is the difference? Well, with Express you can define routing easily:

It looks really good, but I’ve also seen many examples using routing specific to ReactJS – implemented with react-router.

I wanted to use react-router too, as it seems more ‘ReactJS way’. Fortunately there is a way to combine react-router with Express server by using match method from react-router.


Summing up, here are my choices matched with characteristics that I defined at the begging of this post:

  1. Server side Javascript rendering – Express as the frontend server
  2. JS scripts written in EcmaScript6 syntax – transpiling ES6 to ES5 using Babel loaded through Webpack
  3. Stylesheets written in Sass – transpiling SASS into CSS using sass-loader for Webpack
  4. All Javascript bundled in one file and all stylesheets bundled in another file – Webpack
  5. Assets (js, css) minified for production – Webpack
  6. A mechanism to watch for changes and transpile on the fly in development mode, to speed up work flow – Webpack
  7. Something to handle external dependencies – npm

Additionally I chose Ejs for the layout template and since I’m using npm and Webpack we don’t really need to bother with grunt or Gulp task runners.

But of course, you can choose differently since there is a lot of other combinations:

Javascript tool combinations

Now that we know what we want to use, in the next post we will move on to creating the app. See you next week!

Update: Here is the next post.

Web Summit 2015 – Crowd, Talks & Toys

Basia Madej November 19, 2015

You might have already read the great review of Web Summit 2015 by Gosia (aka The Cheerful Designer) and be thinking about going next year? Well, maybe it is time to hear my (aka The Awkward Developer) opinion.

TL;DR Don’t go.

I knew Web Summit with 42k (!) attendees, gazillion startups and bazillion things might not be the best place for introverts or socially awkward individuals like myself. And that the event is not meant for programmers, but rather marketing people, entreprenours and startupers. Yes, I don’t even know how to spell “entrepreneurs”, but still decided to go when my great friends from Amazemeet invited me to join them. It sounded like one-of-a-kind experience. Plus, I wanted to see the “Toys” on show at Machine Summit.

The crowd at the Web Summit 2015 expo hall

Well, it quickly turned out the Web Summit crowd wasn’t only a problem for introverts. I’m sure 99.9% of attendees felt overwhelmed at some point (and the remaining 0.1% probably just skipped the event and went straight to the pubs). There were lots of helpful volunteers, team members and even law enforcement doing their absolute best to make the whole thing work as smoothly as possible. But with 9 main stages, 10 minutes walk between the 2 main buildings, 15 minutes walk to the Food Summit, no breaks between 15-20 minutes talks, queues and plenty of other attractions  – it was just not possible.

But I don’t give up easily. I decided to come up with (survival) strategies to best spend my time and enjoy the experience as much as possible. Since there were 21 different “summits” happening during the whole 3-day event, there was a lot to choose from.

1. Out of my comfort zone: Fashion Summit

My first idea was to go and listen to something I have no clue about and fashion was an obvious choice for me. I was hoping to see other points of view and hear some new stories. But after waiting for 35 minutes (and hardly moving) in the best-dressed queue ever I decided to crawl back to my little world (Code Summit). Still, I’m planning to use this idea during my next conference. And maybe wear nicer shoes.

Fashion Summit stage

2. Big names: Centre Stage

The second idea came from the obvious fact that big conferences have some big speakers from big companies. So, like many others, I decided to watch talks on the Centre Stage, where most famous speakers were invited. Sure, some of the talks (here and everywhere else) sounded just like shameless self-promotion, but generally the products & companies were interesting or the speakers were entertaining enough to keep me listening and enjoying it. And some were really good – just like Gosia, I absolutely loved Creativity by Pixar’s Ed Catmull, Mike Schroepfer talking about Facebook’s bold plans to bring the Internet to remote communities, and many others. On the Centre Stage, I also saw the worst presentation I’ve ever seen – “The CyberPsychology of CyberCrime”, which turned out to be… a cringe-worthy promo for the “CSI: Cyber” tv show, with (surprise!), the  overuse of word “cyber”, no real information and a mandatory Freudian-penetration-penis joke that all the 9-year-olds in the audience found hilarious.

3. The comfort zone: Code Summit

Code Summit might sound like a perfect safe haven for a developer like me, but I was afraid the talks would be too general or too basic for a rather experienced programmer. My plan was to go there only to listen about security, but I ended up attending a lot of presentations when the Fashion Summit idea didn’t work out. And yes, the talks were a little bit too general, with hardly any code, but the really passionate speakers made it worth the time (Jeff Pulver Remember to breathe, Bryan Liles Application ops ladder, Gautam Rege Gopher it). And then the talks about security started and I was absolutely blown away by Nico Sell, Mikko Hypponen, Eugeny Chereshnev – just to name a few.

4. The Heaven: Machine Summit


This was my primary reason to attend The Big Conference. The chance to see and maybe even play with Pepper the humanoid robot, Jibo the social robot, mini-drones, the latest wearables, try Audi Oculus Rift Experience, all the `fit-bits for cats` gadgets and so on. I love it all. Discussions about Not so uncanny valley or Robot ethics (which turned out to be about having sex with robots), Cynthia Breazeal’s talk about Rise of the social robots and the Keynote from Pebble were my absolute favorites. Sure, I was tempted to start counting the number of speakers telling the audience that what their company is doing is almost as exciting as Tesla :), but yeah – that was true most of the time.

Also, the WiFi and coffee were good. And Dublin has the best pubs and live music. But unless you enjoy shopping on Black Friday, barging your way through the crowd or you love networking so much even overdosing on it still sounds like real fun…

Don’t go.

Web Summit 2015 – Sketchnotes & Thoughts

Gosia Nowak November 16, 2015

Web Summit Dublin 2015 sketch

Yes. Basia and I were at Web Summit Conference this year. We went to Dublin – the land of Fairies, Guinness and a huge technology conference. Overall it was great and exhausting; the talks were interesting and inspiring, I discovered how varied the startup stage is and could confirm that, indeed, Guinness tastes better in Ireland.

I got my ticket by entering a competition organised by Amazemeet ( Thanks to that lovely initiative I got to meet two wonderful people: Mike – founder of Amazemeet, a person that has magic powers in finding out best stories from people he just met; and Nádia – also a winner, UX designer, passionate sketchnoter and great small talker.

Sketch of Gosia, Basia, Nádia and Mike

When there are 2 parallel tracks at a conference we often find ourselves making many hard choices. We try to assess what will be the most interesting topic or from which presentation will we gain more. At the Web Summit there were 7 parallel tracks and at least half of them sounded amazing. There were also dozens of interesting startups, new technologies like Oculus and on top of that plenty of fun people to talk to in the long coffee queues.

I like drawing and I like sharing my experiences, so I chose talks that were most interesting to me and combined some of my sketchnotes from them.


Illustrated notes from Web Summit Day 1

Day 1

Big Mistake – Andrei Herasimchuk

Should designers learn how to code? The answer given was Yes! While I’m sure we could have a debate about that, I liked the argument that coding gives you the ability to create something and that it’s a super power.

Chairman of the bored – Chris Moody

A reminder that creativity means being brave, it means to push the boundaries and innovate. Chris walked us through some popular “safe words” and proposed alternate terms that can activate a more creative approach to problem-solving.

Venture design: from zero to launch – Ethan Imboden

Talk about delivering a product in lean iterations; how to use venture design to find this rapid path from the idea to the market.

Why design is the new engineering – Neil Rimer, David Okuniev, David Tuite, Jeffrey Veen, Mike Davidson

How design will shape the tech startup ecosystem for years to come. This panel discussion was just full of great quotes:

What a product does is deeply affected by the design.

The design of the product should be its foundation.

Design comes from the team – co-designers of the UX.

Teach empathy at every end point.

Flat, fast and f*cked up – Marcus Woxneryd

My favourite talk from that day, from creators of Monument Valley, presentation about organisational culture put in 3 points:

1. Flat is Phat (organisation); we know that very well at Lunar, but it’s always nice to hear it from someone else, with a unique approach and ideas.

2. Fast (team); the importance of collaboration skills in teams, for good performance we need purpose, and trust in others. Marcus also pointed out the value of a celebration ritual, having time to appreciate good work, and achieving success (small and big); it’s something that helps to build good teams.

3. F*cked up (individual); everyone is different, we all bring something unique and valuable to the table.  Embrace that in others. Give others feedback, not only “high-five feedback” but also critical.

At the end we were left with the AFGO motto; when you find yourself in a difficult situation, when you feel that you failed at something, think about it as an AFGO – Another F*ucking Growth Opportunity. Because before you succeed you need to fail sometimes, experiment and learn from that. Exploration over strategy.

Illustrated notes from Web Summit Day 2

Day 2

Diplomacy in the digital age – Anne-Marie Tomchak, Jan Melissen, Jane Suiter, Patrick Smyth

A panel about how real-time citizen reporting, data leaks, memes and hashtags have influenced the political landscape. I went to because I didn’t know anything about this topic. It was interesting to hear journalists and diplomats share their experience of how digitalisation is shaping their work. Social media gave diplomats an opportunity to engage in conversation with people, to share information directly, but also created a space where politicians are challenged if they don’t deliver what they promised.

The art of tidiness – Marie Kondo

The author of the bestseller The Life-Changing Magic of Tidying Up talked us through her method of tidying up. At the end of her presentation (given in Japanese) it became clear why she is part of tech conference: Marie will launch her app next year, where you can document your progress in cleaning up, but also become a cleaning consultant. I guess it will mark the moment in the tech industry when there will be an app for everything.

The ultimate selfie – Jacklyn Ford Morie

A talk about what we leave behind in a digital world, how much of our lives we can already capture with quantified-self technology. Jacklyn presented a vision of avatars that we can leave behind us, avatars that were learning about us through our whole life and can continue to represent us after we die. For me, it’s a sci-fi idea that is still far in the future, but the talk showed me that actually a lot is being done in that area of virtual experiences.

Storytelling #emotification – Mary Lee Copeland

Storytelling is re-emerging in tech as a hot trend and buzzword. Great presentation based on a video of James Brown and his storytelling through singing and stage acting. Mary claims that all human beings are storytellers and stories resonate with us. We should use stories to create our branding and user experiences that are engaging and memorable. Tell a story to people, find them when they’re in trouble and make your product a turning point in that story.

Illustrated notes from Web Summit Day 3

Day 3

The sixth sense – David Eagleman

A presentation about how narrow our experience of reality is. Research in neuroscience and brain processes led David to create new interfaces, such as a sensory vest.

I highly recommend watching his ted talk about this topic: Can we create new senses for humans?

Dan Brown in conversation with Peter Kafka

I’m not really sure why Dan Brown was there, and I guess he didn’t know either. Nevertheless, it was interesting to listen to him talk about his relationship with science and religion, how it was influenced by his childhood and school experiences. How those two fields are in his opinion using two different languages to tell the same story. As a fun fact, he shared the title of his first novel (created when he was 5 years old) called Giraffe, the Pig, and the Pants on Fire, which definitely sounds like something I would read.

The magazine reimagined – Jefferson Hack, Matt Garrahan, Liam Casey

The story of creating a unique magazine. “Its blend of high fashion and world-class photography with features on the arts, politics and literature continues to make each beautifully crafted edition a collectors’ item.”

To me, it looks like something taken out from Harry Potter’s world. You can see it here: AnOther Magazine presents: ‘A View of the Future’

Creativity – Ed Catmull, Caroline Daniel

Ed Catmull – the President of Pixar, was in a conversation with Caroline Daniel about creativity. It was the closing talk and I was waiting for it the whole day. It was great to listen to him talk about friendship and how failure fuels creativity. “Every film Pixar works on always sucks at first”, so it’s important to create an environment that allows constructive criticism as well as evolving of new ideas, talents and solutions. Ed also spoke about his childishness needed to stay creative, and how having fun is a way to stay passionate.