What’s your twitter mood?

The idea

  • Analyze tweets of a user for being positive, negative or neutral using machine learning techniques
  • Show how the mood of your tweets change over time

Why?

  • Fun way to experiment with Sentiment Analysis
  • Experiment with language detection

How

Gathering data

We analyzed tweets from Switzerland, England, and Brazil. We put extra care to make sure our model can do well against Swiss-German text.

Make awesome model in node

We created custom fast Natural Language Processor in node.js. Why node? It has very good run-time when dealing with lots and lots of strings. We used unsupervised machine learning techniques to teach our model the Swiss German and English writing model. Once we had a working model, we added couple other models using Bayesian inference to create an ensemble https://en.wikipedia.org/wiki/Ensemble_learning

Make nice front-end

portugese sentiment analysys

Once we got our server working we thought about adding some better UI. We asked our User Experience specialist Laura to suggest improvements. See for yourself:

mood-detector-graph1

Problems and learnings

Language detection is needed to use the right sentiment model

Design model for Swiss-German is especially hard: the language incorporates German, with a lot of French and Italian words. Also spelling of words changes from canton to canton. If we add that most people when writing tweets are forced to use abbreviation, we get the whole picture of the challenge.

An accurate model needs a lot of data

In order to get a good result we needed to incorporate data from various people and different nationalities. The good thing is that the more you use our model the more accurate it gets.

Training data is available

One of the problems is that for humans is hard to understand the irony or sarcasm. Especially in short tweets. So it’s also hard for a machine.

If you want to play with our results in this machine learning experiment:

https://twittersentiment.liip.ch

I would like to thanks Andrey Poplavskiy for his “css love”, and Adrian Philipp for his huge contribution and encouragement towards this project.

PS.

Some comments that we received, were not so nice, but as always we are happy to receive any feedback.

twitter-mood-not-so-nice

Swiss Confederation, the Styleguide version 3

What is a StyleGuide for ?

It is a long-term and flexible solution listing and exemplifying web components and tools useful to create a website. For instance, it explains how to use each component, how they should appear on the web and interact. It is a support for developers while integrating, and useful for designers, as it allows them to keep a general vision on the style and the system’s functionalities. It is obviously necessary to keep a StyleGuide up-to-date, anytime the Corporate Design or Corporate Identity is modified.

Why is it for the Swiss Confederation useful?

The Swiss Confederation is split in multiple departments, each of them owning one or more website. The StyleGuide supplies them a common ground for the creation and their websites, while ensuring a coherent visual identity for the user. The StyleGuide does not only offers web-component AA certified according to the Web Content Accessibility Guidelines’ recommendations about accessibility, it also provides additional information. The StyleGuide aims at ensuring a wide access to information to any kind of users, including disabled people (for instance sight or hearing disability). These recommendations are also useful to all users.

Swiss Confederation Web Guideline 3

Swiss Confederation web guidelines define the graphic guidelines of the Swiss Confederation on the web. It ensure coherence on the different websites developed under the admin.ch domain.

Innovations of the 3 version

  1. Change in the system generating the StyleGuide. Hologram (coded in Ruby) was replaced by Fabricator (identic but coded in Node). It facilitates its installation and development with Windows
  2. It is translated in the swiss national languages
  3. The components’ accessibility is improved (AA)
  4. Problems raised on Github solved

Who are the users ?

The StyleGuide is to be used by internal federal project manager and external service providers. The code is opensource, each can use, modify, solve issues or propose improvement. The StyleGuide is very convenient to use in all projects and easy to install with NPM or Bower. It is possible to download an archive or duplicate the project from Github. The whole installation process is available on Github.

The last version of the StyleGuide is built on a Fabricator. It is automatically multilingually generated with Gulp. Gulp is also gathers and improve all necessary files for the framework to work properly. The documentation is written in markdown, the components are dynamic templates Handlebars. The translation is performed with the support of a personalised Handelbars, referencing translated files in YAML.

Kanbasu: meet the bare CSS framework

Speaking of CSS frameworks today, the first thing coming to people’s mind is usually Bootstrap. It’s not surprising, Bootstrap is a great toolbox removing most of the interface pain for developers that are not really into, you know, front-end stuff. It comes with useful and flexible JavaScript plugins, many components but especially and essentially a lot of styling. Probably the reason of its popularity, it’s also the reason why I prefer avoiding it.

When you have to implement a custom design for a website, the default styling of the framework doesn’t really matter. Even worse, you would have to override it and adding an extra declaration to your CSS is never good. I’m not saying it’s always bad though; if you have to quickly build a private admin interface or a prototype, it can be very useful. Sadly that’s rarely the case for our clients projects.

Continue reading about Kanbasu: meet the bare CSS framework

Tags: , , , ,

Load client side resources in a content centric application

We saw in a previous post, best-practices to optimize the client-side resources load, and by the way, reduce our web page’s loading time. Let’s keep in mind these concepts and solutions and assume that we develop a content-centric application in Java/JSP.

This application contains components that have many renditions for multi-channel usage. (As explained in our previous webmardi about content-centric application.)

Let’s take a component with a “in page” rendition, and a “standalone” rendition. So this component can be displayed integrated to a page, for example by sling or the JCR api, and as standalone HTML by a direct HTTP request. And in both cases, this component requires some client-side resources to be well displayed.

In the “standalone” usage of the component: We must refer the resources inside the component’s “standalone” rendition script:

Then in the “in-page” usage: We refer the resources in our “container” page rendition’s script.

We see in this inclusion that we must specify a “in-page” rendition that doesn’t include the resource again. And here is this “in-page” rendition:

Again we include our script in our container page rather than in the component, exactly to manage coherence of the resources inclusions.

This content centric application model, doesn’t solve the problem described in previous post: We still have to find the golden mean between too much or not enough granularity in the categories of the client-side resources.

But we see that renditions of a component are not dependent each other. Meaning, we can choose what resource to load in “standalone”, “in-page”, or any else renditions.

Note that if it’s not a problem to make “standalone” and “in-line” renditions dependent each other, you can put all the common code (the ul and foreach loop) in a common script, and include it with standard JSP methods.

AEM ClientLibs

The JCR/Sling based CMS “Adobe Experience Manager” comes with a great feature, designed to automate all these inclusions and to ensure a good coherence of your resources categories. This is the “clientlib” system.

First we create somewhere in the JCR, a node with the primary type “cq:ClientLibraryFolder”. This node will have a property “categories” where we’ll name one or many categories (for example “my-internal-lib”). In this node, we put our scripts (JS and CSS), that we want to be loaded, when we call (in a rendition jsp) the previously named category. That is the basic concept.

Added to this, “cq:ClientLibraryFolder” have these very useful properties:

Property Type Description
dependencies String[] List categories this one depends on
categories String[] List the categories that this folder constitute
embed String[] Embed the code of listed categories, in the categories this folder constitute.
channels String[] List the channels (related to devices or sites) for which the constituted categories are valid

Here’s a client-library-folder for our carousel component example:

  • carousel-clientlib – cq:ClientLibraryFolder
    dependencies: modernizr, internallib → any dependencies you need.
    categories: carousel → We call it “carousel”.

    • carousel.js → any external library you need)
    • carousel-init.js → any custom specific code you need).

In the rendition JSP, I call this category with a jsp tag:

  • The HTML will contain inclusions of all dependent scripts.
  • The call order is automatically calculated by the system, base on the dependencies chain.
  • A script will never be included more than once.
  • We don’t need two different renditions anymore. This one works fine for “standalone” and “in-page” usage of the component.

Use of clientlib system is not required by AEM, but at Liip in the AEM squad, we find the feature great. So we use it.

Unfortunately there’s a little performance problem with this. We know that JS should be loaded at the end of the body. To stay compliant to the content-centric model while providing these features, or for any reason I don’t know, AEM decided to print the inclusions right where the tag is used.

The easy solution we found at Liip to resolve this last problem is just to encapsulate the AEM tag in a custom tag:

In this encapsulation, we buffered the output generated by AEM’s clientlib system, until we print this output with:

A way to do big, clean, and scalable content-centric application, with very good client side performance.