||1 year ago|
|poobrains||1 year ago|
|themes||5 years ago|
|.gitignore||4 years ago|
|MANIFEST.in||5 years ago|
|README.md||2 years ago|
|example.py||1 year ago|
|fill.py||3 years ago|
|setup.py||1 year ago|
poobrains is a python webframework with a DIY datajournalism twist
born out of a fundamental dissatisfaction with how the modern web
works vs. what the initial promise of it was.
Once upon a time, reader privacy was a thing that journalists actually
took to heart – but if we look at how modern news sites operate, we can
see that, on the modern web, reader privacy is dead while surveillance
capitalism has become the de-facto modus operandi for most, if not all,
poobrains aims to depart from that, offering an integrated solution for
DIY data journalism and publishing capabilities that honor the privacy
and time of developers, writers and readers alike.
Obviously this provides a fair bit of challenge and some hard
decisions had to be made.
One of the goals of poobrains' design is making things friendly for developers
with very little boilerplate needed to create a site – the current minimum
SLOC count to create a site that folds out to a fully working CMS with media
uploads, commenting, data visualization & analysis, powerful markdown
integration allowing inline-rendering of other content, user notifications
that are optionally sent as PGP-encrypted mails and a nice theming system
with granular overrides, inheritance and SCSS integration being 3 – yes,
three, with the main .py file of the site acting both as WSGI entry point
and CLI that amongst other things, generates everything needed for
Logins are done via TLS client certificates to take advantage of public key
cryptography on the web. The permission system is granular and extensible,
but more importantly restrictive. Sessions are stored server-side, but
encrypted with a symmetric key stored in a client-side cookie.
But the biggest difference from other frameworks lies with the decision to
no WebAssembly, no Google Fonts, Maps API or, more to the point, tracking
services. This is additionally enforced by CSP headers.
This of course makes UX challenging, as many modern UX patterns on the web
are based on client-side scripting in one way or another – still, poobrains
aims to deliver the best possible UX the combination of HTML, CSS and SVG can
offer and in my quest to deliver on this, I might just have become one of the
most distinguished experts on how to do things without client-side scripting.
The upshot however is that a lot of attack vectors on the web simply
disappear if you can enjoy the full functionality of sites while having
JS deactivated and that any resources published by a site powered
by poobrains can stand on its own, i.e. is properly "offline enabled",
which is much closer to the initial promise of hyperlinked documents
the web was supposed to be.
Data analysis & visualization
Current data visualization and analysis tools on the web are either almost
completely implemented as client-side scripts (often loaded from third parties),
extremely rudimentary or offer very poor usability – poobrains aims to avoid
all three of those properties and as such comes with its own data visualization
system to output partially interactive visualizations combining SVG, CSS and
In tandem with this works the Data Editor, which harnesses poobrains' powerful,
custom-built form system to enable collection and analysis of data.
This is where I'm currently at and is very much a Work-In-Progress. As I'm
writing this, adding the visualization of and analysis of geodata is what's
on my plate with the first alpha release finally being on the horizon – see
the official milestone for progress on that:
But as work on the project has me in progressively precarious
situations with me keeping working on it even while being homeless for over
a year now. A grant would enable me to keep working on it for another year
without always having to worry about where I spend the next few days or weeks
while working towards bringing poobrains to production quality.
Besides adding more polish in general, my plans for poobrains' further
development feature these points:
Finish the base system for data analysis and visualization
Overhaul the default theme, which, while technically responsive down to
480x320 still has a host of issues I would like to fix.
Fix various performance issues. poobrains is currently completely
unoptimized and some endpoints are just unreasonably slow.
Document everything – even though poobrains boasts its own documentation
rendering system, it is currently glaringly underdocumented. I aim to
rectify this by writing proper inline documentation as well as a series
of articles to introduce people to poobrains various subsystems.
Add more data sources for the analysis system, especially in terms of
external APIs and some automated crawling.
- Expose the data of the analysis system as an API
and integrate consumption of that API into poobrains
itself so that different sites powered by poobrains
can easily share data and thus further collaborative
analysis over site borders.
- Expose the data of the analysis system as an API
As a more lofty long-time goal I would also like to enable readers to
explore datasets used in articles themselves so that readers can
evaluate the presented data independently and arrive at possibly
The end goal of poobrains is enabling individuals or small groups without
prior experience in data journalism to start doing independent DIY data
journalism while keeping close to the webs original promise of hyperlinked
documents which can be shared online as well as offline.
But even if poobrains never sees many adoptions, its goal will still be
fulfilled if it succeeds in inspiring other developers to approach the
web in a way that is more along those lines.