Github, why u no show more media files?

Break down of media files on GithubMaybe you’ve noticed, it’s impossible to search for media files on Github. Searching Github is for code only. You might find references to media files in code, but no more. This is pretty annoying although understandable for two reasons:

  1. Github targets developers and, as such, focuses on tools that are relevant to them.
  2. The open source licenses that Github promotes for its public projects are maybe not always the most relevant or friendly ones when applied to media content. So, it’s just a supposition but, by preventing search for media files, Github avoids getting in trouble for actually hosting content that stands in a the gray area of open source licensing.

Anyway, since I’m very interested in how designers are using Github for their projects, I conducted my own study and started indexing as many projects as I could, mainly storing references to the media files they contained. And after more than 2 weeks of constant querying their API − with a little help of my friend Olm– − I managed to store information from ~500.000 original public projects. That’s a little more than 1% of all the projects that exists on Github so far (44,444,444 at the time I’m writing this blog post).

1% is a pretty small number, but the API is limited to 5000 calls per hour. It would take me years to get the whole data and certainly more as Github growth seems accelerating. But for the purpose of this study, it should be pretty enough. The goal is to get a sense of what’s popular. These 500.000 projects are also what I call “original”, which means they are not “forks” of other projects. So it overall might represents more projects than this 1%.

Another disclaimer before getting into the data, when I say media files, I actually searched for files with certain extensions. I used a list of 210 popular and not so popular media file extensions, compiled with the help of Wikipedia and others. Again, a trade off here due to time and space constraints. I could have missed some big ones that I never heard of. Although I hope its unlikely.

Ok, so with 1% of Github in my hands, it’s starts to be interesting to make assumptions about the big picture.

Out of the 546,574 projects, only 52,564 have been forked at least once. That’s barely 10%. But those 10% have produced 276,118 forks. So maybe overall 30% of Github is forks and 6% is original projects that have been forked. Yeah, open source is hard. The rest is empty projects (20% of the originals I downloaded), deleted ones and the occasional spam.

Surprisingly, Github gets spammed, a little. And the not-super-smart spammers are just filling the description of projects with their trash content, which makes it easy for Github to spot, I guess. Why are those spammy repositories still available from the API is a wonder to me.

550,000 projects represents a total of 130,000,000 files of which 12% are media files. Extrapolate this and Gihtub might host more than 1,5 billion media files. Quite a resource if we could only search through it. Anyway, as expected, the most popular media files are the PNG, JPG, GIF and SVG.

This is understandable as Github is the go to place if you’re into web design, whether its javascript libraries, CSS frameworks or icon sets. Github also offers static website hosting that attracts a lot of people. But let’s have a deeper look at the “others”. What’s popular and how does it break down?

What’s interesting to see here is that after PDF, which Github allows you to view in the web interface, comes two font formats (TTF and WOFF) that are very popular with web designers also, but for some reason, Github is not displaying. Actually, the next format that Github offers a preview of comes on the 11th position in this graph, the famous PSD. In between, we have many formats that could easily be previewed in a browser, but Github does not seem to care.

The little surprise here for me is the amount of OGG, MP3 and WAV files available. I certainly did not expect that. Seeing also that the ASSET file type is quite popular (a file format used in game design with Unity) and considering that game development tools overlap web development tools these days, all of this starts to make sense. Sound is an important part of any interactive experience, being a web/app interface or a game. Again, these sound files could be easily previewed in a browser.

Lastly, let’s consider STL, the last file format displayed here (and 30th in position). It’s the common file format for exchanging object files used in 3D printing. Github has a preview for it and even shows some form of “3D diff” between commits.  Great, but on 13th position, we have OBJ, also an open 3D format, that counts 5 times more files on Github than STL. To my knowledge, it’s not more complicated to display an OBJ file in the browser than a STL one. So what’s the logic here?

To wrap this up, Github could do so much more with not so much effort to allow previews in the browser of some important media file formats for designers. Maybe the “licensing” trouble described at the beginning is not a bad supposition after all. I’d be certainly happy to hear Github’s take on this. If you know anyone working there, thanks for forwarding these questions, and if anyone there is listening, I’d be pleased to dig more deeply into your data to understand more how designers (could) use your product.

Collaborative tools for designers − part 5 : Adobe Creative Cloud

Adobe Creative Cloud App

Episode 5 already. Damn, so many collaborative tools for designers. Yes. And this post is about the one everybody talks about, but what they are actually referring to is something else: Adobe Creative Cloud. Let me rephrase that. When you tell people you are trying out Adobe’s cloud, they think you are using Photoshop or something. They don’t picture that what you are actually studying is the file hosting and syncing with Adobe’s servers. You know, the thing that works like Dropbox. Well, unless I’ve badly searched in the giant list of Adobe’s applications, the only tool they advertise doing collaboration and versioning, is Adobe Creative Cloud. Yes, the syncing app with the “real” cloud. No, not Photoshop. Your files, on their computer. You get it.

And don’t tell me it’s called Adobe Version Cue. Has anyone ever used this? I tried. A long time ago. And did not manage to make versions of my files with it. So I abandoned. And so did Adobe.

As I flew away from Adobe products since the first Creative Suite versions, I really thought that people were actually using the “cloud” services from Adobe, so I was surprised to hear none of my friends were actually using the 2Go of “free” hosting offered with their subscription. So to complete this review, I asked some friends if they wanted to test it. Sébastien Monnoye, teacher and designer, who also had never pushed files on the Creative Cloud before, answered the call and we started sharing folders together and explore the tool.

AdobeCC Hello World

One thing for sure, and you guessed it, is that it treats Adobe’s file format very well. The rest, not that much. You can, of course, see a preview of .psd and .ai files in the browser. But you can also break down that preview by turning on and off the individual layers for those files. Neat. With a click of a button you can extract certain elements from a .psd or a vector file and add them to a library of assets. These libraries are accessible right from inside Photoshop or Illustrator. So you could just drag and drop from those into a new design. It really speeds up the reuse of certain elements you might have made in your previous projects. (They also propose to buy and download existing libraries of assets. But I did not look into that too much or how you could submit your own designs.) And lastly, for all the elements in a design that you can select, they show you what are the CSS rules you need to write to have that same element behave the same way in a web page. Kind of nice. Especially for positioning.

Positioning from Adobe Creative Cloud

So, for every (adobe) file you upload, you can see some meta data, quickly access the major colors present in the design, leave comments for collaborators, extract assets, share the design on Behance and see the previous versions of the file. But don’t expect a reliable versioning system here. After 10 days, old versions are trashed.

After 10 days, we delete the past versions from the servers. If you know a version is going to be important, we suggest you make a copy of the current file you’re working on and save it with a new name. Then restore the original file back to the revision you care about. This way both copies become their own unique file that won’t be deleted automatically.

10 days is… ridiculous. And the solution proposed here kills all the benefits of using a versioning system. So let’s call this a short term memory backup, shall we. Nothing more. Why would you want to come back to a previous version of a design after 10 days, right?

Anyway, now on to the weird parts.

You know unix’s philosophy: everything is a file. Well, in the Adobe cloud, everything is an image. And if it’s not, it’s a blob. So yes, any .doc or plain .txt file is rendered as an image… Making it − if not unreadable, at least − unusable. HTML, CSS and Javascript are blobs. No way to see what’s inside them from the web interface. No versioning either (sorry, short term memory backup) for those. I’m not making this up. This is super strange. Adobe has a long list of tools related to web design, but displaying code in a web interface and versioning it, why would you want that, right?

AdobeCC file viewer

In the little application you install on your desktop, you get real-time notifications when a collaborator leaves a comment, but they don’t tell you which file has changed and who did the changes. So apart from the comments, the app is just there to do the syncing and let you access the Adobe market for apps, fonts, stock photos and assets libraries. You can also see a preview of what’s trending on Behance. (Mmmh actually, there is a way to see which files have changed, but good luck on finding where that is. Tip: it’s not in the notification window.) So to sum it up, this is more like a market place for the Adobe products than a tool to communicate and collaborate, as I thought it could be.

I’ve only tested graphic files. More tests could be made with InDesign files, Premiere, After Effects or Flash. But I’m kind of focusing from a web designer point of view. So I also tested some other file types: .odf (Libre Office), .xcf (Gimp) and .py (Python) and unsurprisingly, they are all treated as blobs. With SVG, it’s a special case.  They all are rendered correctly, but the features you can have with them are very different if you have saved them from Illustrator or from Inkscape, for example. The latter having the less feature, of course.

To wrap up, I’d say that the tool to extract assets is really a nice productivity improvement, but the syncing and collaborative features are behind what Dropbox is proposing. And since Dropbox just acquired Pixelapse, they really aim at offering an even better experience to designers, if they are not the tool of choice in that field already. Adobe is forcing its tool on everybody, of course, because you need that little app to install the Photoshop and others, but they need to polish it a lot more to get the designers to give them their files. And I don’t think that the “Publish on Behance” button is really a key here. But lets see how that evolves over time.

(Next episode: The Git Hosters )

Collaborative tools for designers: part 4

TL;DR: Tools I will not review and why.

Three weeks ago, I started a series of publications regarding tools that encourage collaborative practices for designers and that use some form of versioning at their core. You can read the previous chapters and especially the first one to understand what I’m looking for (links to part 2 and part 3). In this fourth episode, I’m just going to list tools I will not review thoroughly but that I felt I should mention because they exist (or existed) for certain reasons. If you have experience with some of them, I’d certainly be happy to hear about it.


Used by blockbuster media companies (such as Rockstar Games or Disney, for example), it’s a complete project, team, assets, source control management solution aimed at very large studios with hundreds or thousands employees and its apparently great at handling large (sets of) media files (at least, that’s how it was once presented to me). The licensing fee are relative to that description. It’s worth noting that the latest presentation of Perforce Helix mentions the integration of Git for the developers in the team. Maybe worth watching is this video showing how to handle their image diff tool.


Although, like Pixelapse, I had them on my watch list, I never took the time to dig deep into their product. And unfortunately, as I understand it from the description on their website, the company went bankrupt 6 months ago. Too bad, when you see Kelly Sutton present their product just 2 years ago, it looked very interesting. Their “wormhole” tool (at 6:00) is really a nice approach to get “what changed and when” in an image.


I hesitated for a while. Should I review this tool or not. They call themselves “The world’s leading prototyping, collaboration & workflow platform“, and looking at their client portfolio, they surely can pretend to this, I guess. But they focus mainly on screen based media and interactivity, or so it seems. and their level of version control is no better than Dropbox or similar. So the designers targeted here are “application” designers, UX/UI designers,… and I’m looking for a a less opinionated tool. Anyway. If you want to get a quick glance at what this tool does, here’s a quick introductory video. Certainly a great tool to review designs, manage projects & teams and test user experience. Not what I’m looking for atm.

Visual Culture

Visual Culture is a server software developed by Open Source Publishing to visualize git repositories. Since their design practice involves doing things open and in the open, their website runs on it and allows the visitor to browse into their latest projects and how those are made. Their intention was to turn it into a general tool for designers and they opened a crowdfunding campaign to achieve that goal, but this did not received enough support. I did try to install it and see how I could use it on my own projects. With the help from Colm, Stéphanie and Eric, I passed through a couple of bugs and misunderstandings on my part. And I could see a recap’ page of what I had in my folders. Unfortunately, that’s how far I managed to go. I lack some Django knowledge to adapt the necessary bits so it would behave nicely with my projects as, at this stage, Visual Culture is still very closely knitted to (how) OSP(‘s) work.

visual culture on my repos

Come back next week for another chapter.

Collaborative tools for designers – Part 3 : Pixelapse

Reviewing tools for collaborative practices and version control for designers, this is episode III. And to my surprise, I’ve discovered Pixelapse, an online tool that promises to do just that.

Pixelapse Homepage

It’s been a while since I had found about Pixelapse, but never took the chance to study it deeper until last week. Mainly because they require to install some software that only works for Mac and Windows. And since I use Linux, well…

So I borrowed a Mac without much luck either. Pixelapse software requires Mac OSX 10.7 and higher. The Mac was running on 10.6. I know designers have usually high end machines with latest software installed. But no Linux support and only a recent OSX, that’s 2 wall hits for me before even starting. But anyway, solved this by installing a Ms Windows running in a Virtual Machine under Linux because I really wanted to see how their tool worked. A pretty big setup just to sync files and not practical in the long term, but for the love of testing, it was fun enough.

Basically, what you are installing is a synchronizing software. Just like Dropbox, it creates a special folder on your machine, where you will keep your files synchronized with their servers and with the other computers you share that folder with. The other computers could be yours or from the designers that you want to work with. Apart from that, all the features proposed by Pixelapse run in the browser. Well, not every browser. Seems they only fully support Chrome. Internet Explorer is a no go and I don’t blame them for that (I tested IE11 only). Firefox seems to work ok, except for the “image inspector”, and that’s a pretty big feature being broken for no apparent reason.

visual comparison

About the features, they have really though it through. You can see their service as being between a version control, a project management and a reviewing tool. You can define roles for each projects, invite “clients” to review your graphic files and comment on them, or have collaborators with {full|limited} permissions. They support a wide variety of file formats for preview (mostly Adobe stuff), but also open file formats and even .xcf (Gimp files), although the latter did not render text properly. Version control is basic (no concurrent versions and they don’t allow custom naming your versions, so you’re stuck with version1,2,3,…) but at least they allow you to rename and move files around without losing their history and you can flag “milestones” in your project’s history. They also allow you to visually compare files or file versions in different ways. Commenting and reviewing design seems pretty well made, Although I could not test it on an actual project or with a team as I don’t know anyone who’s using this tool.

So my overall feeling is very positive, but something is bothering me.  Apart from the fact that it’s not open source, not working on all systems and that you have to trust them with your files, why did I not hear of them more? If I had to do a comparison, I’d say this aims to be the Github for graphic designers, but why don’t I see more of us use it? As a matter of fact, I will definitely find more graphic design projects on Github than on Pixelapse. Why is that? They do allow public projects for free accounts. They encourage in their communication to do open source design projects. They feature some on their homepage. But after going through what was available publicly, I did not see much collaboration going on (Googling through the website, I found one public project with 8 participants.  But can’t figure out if there was any collaboration at all. And then this UFO, which seems to put to good use the features proposed, but I’m wondering if this was really meant to be public). I know it’s a young service (2 yo), but Internet is pretty quick to embrace a pretty good idea when it sees one. Where is it not catching up?

Pixel diff between two versions

I don’t have a definitive answer, but my feeling is that the interactivity is a little oversold and that it unfortunately still enforces the digital divide between coders and designers.

This tool is for graphic designers only, coders will not feel at home. Yes they support the viewing of some code files (HTML, CSS, JS), but without line numbering and a basic text diff tool, this is useless, even scary. Also, why not support other languages like, Ruby, Python or Bash scripting? Where is the problem with that? There are some good ideas : like having a file and a cover image at the root of your project to automatically create a nice presentation page for your public projects. But then, without a proper way to see what changed in your markdown syntax, this becomes a little awkward to use.

Designers of pixelapse

The navigation has problems also. Exploring public projects is a pain. There is no search bar. You can add tags to your project’s description, but it’s like they forgot to implement it on the backend. No way to browse based on project type or keywords. No way to see the latest activity on the site resulting in no sense of community. Seeing the public projects they feature, it feels more like Behance − or any portfolio you can name − than an “Open Design Movement”, as they want to call it.

The interface is also a drag sometimes. It’s using animations here and there and this makes it all a bit clumsy. I want my tool to be fast and to the point. Animating between a thumbnail view and a list view of my files is not something I find important or informative. I wish also that space would be used more efficiently. The whole window is used when previewing files, comparing and reviewing them. And this is a good thing. But why do I feel that so much space is lost when I’m navigating folders and projects. Why not have the full screen used also for that too? I also found myself clicking a lot − where there was no button − expecting something to happen. At other times, I was completely lost and had to go back to the main page to start again.

Too much white space?

Maybe it also tries to embrace to much. Working with clients is not the same as working within a “private” team and not close to working with strangers on open source projects. Keeping designers distant from coders is a also counter productive approach in my opinion.

The good news (or the bad news, depends on the point of view, I guess), is that Pixelapse has just been acquired by Dropbox. So it could mean that Dropbox will improve or that Pixelapse will support more operating systems. I’m guessing Dropbox is interested in the visual reviewing tools since they’ve just started introducing a commenting system for their files. As for the future of Pixelapse, Here’s what they have to say about it:

Will Pixelapse continue to operate?

Pixelapse as a standalone product will continue to be available and supported for the next year as we work towards bringing the same kinds of collaboration and workflow experiences that you’re used to in Pixelapse over to the core Dropbox product.

That just sounds to me as “good bye and thanks for all the fish”. I don’t expect Pixelapse being updated for the next year and have not seen a post on their blog or twitter since the Dropbox announcement (and that was 6 months ago).

There is a ton of good ideas in Pixelapse. But it needs polishing and a different approach  regarding their community if they really want to be the repository platform of the “open design movement”. So for me, I’ll just pass and move on.

Collaborative tools for designers – Part 2 : Dropbox

rip dropbox

Last week, I promised I would be exploring some of the tools promoted as helping designers in their revision control and collaborative process and that I would do this by comparing them to a list of benefits I extracted from my use of Git. So in this post, I’ll be reviewing the (in-?) famous Dropbox.

As a foreword, I have to tell you I don’t use their service. I was forced to have an account, when some friends and coworkers wanted to share some files with me, but I never liked the idea of having my draft files on a computer I did not own. I use some third party services to share publicly some projects, as you will find on Github, for example. But by default giving to a stranger a work in progress, some first sketches or an unpublished project, is not something I find comfortable. How good or easy the service could be.

So as a start, this rules out the use of Dropbox if you work under an NDA, have company secrets or just care about the keeping your working process to yourself or your collaborators. But let’s analyze what they offer and see how that helps designers or not.

First of, it’s an easy set up. After a necessary software install, sharing a project between collaborators is as easy as moving around a folder in a file explorer. It’s also “operating system agnostic” as it will work on Mac, Windows or Linux and even Android or iOS. And if that’s not enough, there is always the web interface to rely on. Actually, the web interface is where most features are built in. (I’m testing this from a Linux computer, but I guess it behaves similarly on other systems).

On the “workstation side”, there is not much more than moving around files, renaming them, and modifying them with your software of choice. It will then synchronize those changes automatically with all the computers you share that folder with.

On the “web side”, Dropbox offers you some form of “versioning”. Everytime you save your file, Dropbox records a change. You can go back in the history of those changes in the web interface and see who made them, from which machine. But unless you know what changes where made and when, there is not much more info given.

dropbox file history
See for yourself, that list of versions is not that useful. If I did a mistake and saved over my file, I could use this to immediately revert to a previous version. But come back to that a week or a month later and who knows what’s hiding behind “version2”. If the file type is supported by Dropbox, I can see a preview by clicking on the version name in the browser. If not, I’m presented with a download button and have to open it on my computer. If somehow we could add a comment or a note with each version, that would improve this a little.

Also, there is no way to compare different versions (even if it’s a plain text file) except by viewing each independently − opening multiple browser windows − and figuring out for yourself what might have changed. Forget also about having different concurrent version of the same file. You’ll have to create different files for that and you’re back to your weird naming scheme. And if you rename your file or move it to a subfolder, your going to be losing all its history. Really? How useful is that?

So this revision system is more like a notification system of who worked on what and when, than a reliable way to store your changes as this can be wiped out by just renaming a folder. It does not help you get organized either. And I found the links in the “events” page confusing and practically useless, especially if you have a lot of files and subfolders in your main shared folder. (see screenshot below, all these files are located in different subfolders in a master folder called “libre-objet”).

dorpbox events
(For some reason, I notifies me of changes on some these files, but when I’m clicking to view the history of it, it only says “version1”. Was the file renamed at some point, or the containing folder, or because those modifications were done before the folder was shared with me,… I have no idea. But how can I trust this?)

I did appreciate though that I could get a 1:1 preview of some files like SVG, Tiff, Jpeg, png, ai or psd (I did not review all the possible files formats). That 1:1 preview also features a commenting system, where you can tag collaborators. But I did not see any tool to annotate a design for example. Maybe that’s coming… who knows.


It also shows a little thumbnail for some of those file types. That’s handy. But this is also something I get in my file explorer on my computer, so where is the added value here? Why not also have those thumbnails in the history page next to each version, or in the event page also? That would be a little more helpful.

As a conclusion, Dropbox is maybe, for most, an easy way to get a shared folder on many different machines but it can not be trusted. Neither on the conservation of files, nor on keeping a history of changes. If you don’t care about “versioning”, you’ll be better of with alternatives, such as BtSync (closed source) or SyncThing (open source) and all the other self-hosted “cloud” application suites.

I know I’m killing down here a great service for some of you. And Dropbox never pretended to be the git (or github) for designers, even if they seem to be heading in that direction somehow. But their versioning system is a joke. And I’m looking at all of this from a very particular point of view. Please, don’t hesitate to share your designer’s experience using Dropbox in the comments below, I’ll be happy to read it and it might help me understand parts I could have missed. Again, I barely use the service. And if you enjoyed this post, come back soon for part 3.

(Cover photo by Steven Caddy released under Creative Commons by-nc)

Collaborative tools for designers – Part 1

Soyuz Cockpit

Since I’ve discovered and used distributed revision control in my day to day practice, I’ve been amazed by how much it has helped me getting more organized, stop worrying about loosing files and also encouraged me to experiment more and thus try more options in my work. And I’m not even talking about how it eased the collaboration process with other designers and coders.

But one of the major drawback is to convince other people to use it. Convincing someone who codes already, or who is not afraid of typing commands in a console, was easy. But talking just pure GUI fanatics to jump into it, is a bit harder. And for a good reason. The tools needed to manipulate the usual revision control systems are mainly designed for coders. Yes, there are some GUIs (I don’t use them), but they look like a spreadsheet or a Soyuz cockpit. And that barely helps make sense when you are looking at the type of projects that graphic designers have to cope with.

So, I’ve been trying to put my head around this problem and come up with solutions. I had a first try at it with a project called “Design with Git” that I had the chance to develop at Medialab Prado, Madrid in 2013. But this was just a beginning, a short-time experiment, and although I’ve spent energy applying to other residency programs to continue on building it, I’ve yet to find a place that would allow me to dedicate some time improving this concept.

So, since this subject is not dead for me and for a lot of others, I’ve decided to start a series of blog posts, in which I would clear my head out and put into words and graphics my thoughts around this subject. And as a start, in the coming posts, I’m planning to review some available tools for “revision control” and collaboration between designers.

A word of warning here, maybe. I’m biased by my experiences, of course. And so far, the only version control system I’ve used extensively is Git. When I started being interested in these kind of tools, I got my hands on CVS, but then Git (and Github) quickly became the trending thing and I drank the Kool-Aid. Also, CVS needed a server, and that was too much to set up for me just to manage my own projects. I’m not a Git-guru either. I use it, almost daily, for almost all the things I produce. But I’ve not gone beyond the basics of cloning, branching, diffing, pushing and merging. When I have to do more complex tasks like going back to an older version of my files or completely erase a file from history, Stackoverflow is my friend.

So here is a list of what I find useful when using Git with my projects:

  • It allows me to view a history of changes, which files have changed and a written description about it (status / log)
  • It allows me to easily make different versions of the same project and to quickly switch between those versions (branch)
  • It allows me to work with an undefinite number of people (clone / fetch)
  • It returns precise and valuable information between the changes or different version of the project (diff)
  • It allows me to integrate the changes made by another person into my own project (merge)
  • It does not require a complex setup to start using it (init)
  • I do keep my folders tidy as I don’t have to invent complex naming formats for my files (No more Front-cover-v4a-TOPRINT2-validated.pdf)
  • It allows me to view the contributions of each participant on the project (log)
  • I’m not worried about loosing a file, erasing or writing over my previous work.
  • It eases the process of working with developers because we are sharing the same tool to keep track of the project’s advancement.

This list, I think, sums up for me what are the main benefits of using a distributed version system such as Git and these are the benefits graphic designers should get from using it also. The catch is this works well when you’re dealing with code or text files. But some points here are a little or very problematic when it comes to dealing with design files. Hopefully, there is some solutions or things that can be adapted. And I believe this is possible while keeping Git at the core of the process.

But before going further into this development, I’m planing to explore some of the tools promoted as helping designers in their revision control and collaborative process and I’ll do so using this list as a frame or a grid of evaluation.

So see you next time. (go to Part 2)

(Cover image: Soyuz cockpit by Christopher Michel under Creative Commons Attribution 2.0)

Atelier de construction de mobilier en palette


Ce samedi 15 novembre, de midi à 16h, venez participer à un atelier ouvert de construction de mobilier pour la cour intérieure de la Bibliothèque francophone d’Ixelles, rue Mercelis.

Suite à un appel de la Commune d’Ixelles, Maria Solé Bravo et moi-même avons créé un ensemble de mobiliers modulaires construits à partir de matériaux recyclés et publiés sous licence libre. Pour la construction proprement dite de ces éléments, différents ateliers sont prévus impliquant la participation des élèves des écoles avoisinantes, des employés de la bibliothèque ainsi que tout visiteur de cet espace public.

Ce samedi est donc ouvert à toute personne intéressée par le design libre, le démontage et l’assemblage de palettes ou simplement de participer à un projet de ré-aménagement de la cour intérieure de la bibliothèque d’Ixelles.