In a few weeks, we will have a unique opportunity to meet the Spanish web scene.

On the 13th, 14th and 15th of November, the biggest Spanish web event, Evento Blog, will occur in Sevilla.

Thanks to the continuous effort of Ramón Suárez, a Spanish expatriate well known in the little web arena of Brussels, a Belgian web mission will take place.

This will give the chance to a few Belgian start-ups to discover the Spanish market a little bit deeper and meet its main actors (medias, VCs, …).

Robin Wauters, writer for the famous blog Techcrunch, is joining the mission and will also be a keynote speaker.

If you are a Belgian start-up interested in the Spanish market, I can only invite you to join this wonderful opportunity. All the information is available here and there are still a few seats left: http://wiki.webmission.be/ebe09

For the others, I hope to see you there!

And thanks again Ramón.

Last week I discovered the tool I was looking for : WKHTMLTOPDF

By leveraging the power of the webkit engine through QtWebKit module, this thing is converting HTML with full CSS support to PDF the same way you “Save as PDF” from your browser

In this article, I’ll show you the very first prototype I did of a possible WKHTMLTOPDF integration with our application.

Let’s start by installing this nifty tool the easy way (tested on Ubuntu Hardy and Jaunty 64 bit):

Next, you’ll have to make a symbolic link pointing to WKHTMLTOPDF in /usr/local/bin.

Et voilà, we are ready to go!

Here is a way to post an arbitrary HTML portion of our current document to the server and have it converted as a PDF on the fly. We will use the following workflow:

1. Post the innerHTML to the server
2. Write a temporary HTML file with the posted data (file:write_file)
3. Convert this file to PDF using the command line WKHTMLTOPDF (os:cmd)
4. Read and store the PDF file content to a variable (file:read_file)
5. Delete the temporary HTML and PDF files (file:delete)
6. Send back the final document to the client using the ‘application/pdf’ content type header

We will be using Mochiweb as our web server (You can follow our tutorial about Mochiweb if you feel lost).

Just create priv/www/index.html and copy the following HTML in it :

http://friendpaste.com/7Kvh0SWRMyCgTMMEOy4×2B

and here is the Erlang server code which will handle the post request (myapp_web.erl):

http://friendpaste.com/538mWzeOfBKxiE2uScDjT4

No magic trick! Regarding the Javascript, I’m just filling an input text value with the innerHTML source and submit the form to the server.

The Erlang code is really straight forward. We defined a new case clause under the ‘POST’ part named ‘pdf’.

In order to generate the temporary file names, I’m simply concatenating the current date time. The important part here is to set the response’s content type to ‘application/pdf’.

Now, we can test our page by connecting to http://127.0.0.1:8000/pdf and clicking the ‘>>>PDF’ button (tested under Firefox).

I hope this was useful for you to start toying with that tool which is certainly going to replace their licensed versions counterpart

And now, a Version 2 is out for trial…

Well, enough reasons to decide to give a new and fresh look to the current website and also redesign the logo which, until now, looked like this:

But this time, we decided to ask for your help in the choice of our future logo.

Thanks in advance !

Please have a look at those new examples and download the version 2 for tests.

If you followed the story, you may know this new version is more about a change in the inner logic than a set of new features.

However we think this new architecture will enable us to go further with the library.

The main changes are described here: Version 2 Release Notes. You will also find in the article a mini-guide to upgrade your templates still using PURE version 1.

In the coming weeks, the wiki will be updated with a refreshed documentation.

Any suggestion, ideas about how to structure it in a better way is highly welcome.

Heads & hands to write some parts too

Please have a look at the material above and send your feedback.

They use it for their Campfire application which is a web-based messaging/chatroom solution and the performances prove one more time that Erlang is a killer language when it comes to build stable and scalable back end systems.

You can read their full article here.

37Signals, Facebook,…

What are you waiting for? Start developing your own web application with Erlang now!

And Guess what? BeeBole is in!

Geek ‘n Rolla was a day long (April 21, 2009) conference for startups created by TechCrunch Europe. As part of the day we asked startups around Europe to celebrate with a little rocking out. This video was created by Bonney and Klein, conceived by Stradbroke Advisors. GeeknRolla was sponsored by Viadeo, and supported by UK Trade and Investment, as well as NESTA, School for Startups and Bootlaw.

GeeknRolla – The Movie from Mike Butcher on Vimeo.

On Behalve of BeeBole, I have to thank Bonney and Klein and Inma Martinez from Stradbroke Advisors for inviting us to participate to the video and of course TechCrunch Europe.

It feels good to be considered as a rocking start-up.

As he states:

It’s easy as pie to create a good looking and intuitive user experience when your solution only includes a few functional areas, but as you roll out further functionality all of a sudden that simplicity and intuitive feel starts to lose out to nested menus, complexity and options.

In my opinion, you have to solve two main issues:

1. How do you combine keeping it simple for users with simple needs with offering a complete solution to power users.
2. How do you display and browse your data, especially when the amount of features becomes huge.

Before going further, I encourage you to watch our first video about the BeeBole interface and features illustrating a few of the points discussed here.

How do you combine keeping it simple for users with simple needs with offering a complete solution to power users.

This issue is one of the core issues we wanted to solve with BeeBole.

We often look with envy at the US where you find a huge market with companies presenting similar needs.

But as a European start-up we knew from the beginning that we had to handle very different needs/languages/country specificity…

Add to that, the needs from different activity domains (a lawyer doesn’t require the same functionality than a web developer for example) and you end up with the following mantra: “Your Company Is Unique, Why Not Your Business Tools”.

The truth is that you can easily turn your application into a huge factory that allows the users to do everything they want, still, most of them will never benefit from more than half of your features when you get to that point.

It implies that half of your tool features become noise to them.

Personalized homepages like Netvibes or iGoogle were, in our opinion, a direct solution to that problem. Of course, you need to add some magic to the widgets/modules so they can exchange information in your screen, but the basis was there.

The idea is to offer as many features as you want in a solution that allows the user to determine which of these features he wants to see on his screen.

The screen would match each user’s country/job/language context as well as his/her personal way of working and not what the software provider has decided for him/her.

In other words, a perfect tune for your ears, without the unnecessary noise.

How do you display and browse information, especially when the amount of features becomes huge.

Most of the existing solutions will present their features gathered per functionality in tabs, sub-tabs and in the worst cases, sub-sub-tabs.

This system has advantages and disadvantages but it doesn’t reflect how most people work.

A few ideas:

• Everyday, you need to perform certain actions with your tool.
  Other actions have to be performed on a weekly, monthly basis or once a year…
  So, it would make sense to present your daily actions in your dashboard and to let you perform those in the very first screen.
  Actions you don’t need to perform regularly would be available in sub-screens.
• That list of actions might evolve during the year and might be different for certain groups of people.
  Here, it comes down to your tool’s flexibility. Again, we think that a module/widget approach is the best solution to solve this.
• No tabs.
  Reichenstein (head of user experience at Mozilla) argues, speaking about the future of Firefox on ReadWriteWeb, that:

  tabs were a good solution for an earlier age of the Internet, when users hardly ever had more than ten tabs open at any given time. Now, however, as browsers are slowly turning into operating systems, a new paradigm for organizing this information has become necessary.

  Well, the same remains true for web business apps.
  Tabs are like writing in stone the direct access to data you need at all time, where your real needs might change depending on what you are doing with the tool at a given time.

I believe our approach definitively brings something different and encourage all of you to give us your feedback about this.

1. The design has changed. If you can’t see those changes or if the design looks weird, just hit the refresh button of your web browser.
2. The re-design includes a lot of new features, mainly in the side bar: direct access to the recent posts, pictures, videos, … and at the end of each post you will find a list of all the related posts.
3. The URL has also changed. Instead of http://beebole.com/blog/, it is now http://beebole.com/en/blog/. The old URL being redirected to here, it shouldn’t be an issue for the old links you might have in your favorites.

Don’t hesitate to give us any feedback about the new design/features or to report bugs via the comments hereunder.

http://twitter.com/beebole

For some reasons, the account was deleted 6 months ago and the “undelete” feature of Twitter was not working for the last 3 months.

Watch it in full-screen mode, it’s in High Definition (The maximize button can be found at the bottom right of the screen).

First Video Tour of BeeBole from BeeBole.