If you don't know how to open doors, how do
you get into a building? At best you might end up breaking a window
instead. Later on you'll figure out that tricky opening-a-door
idea, but that window is still broken. This is necessarily what
happens when intermediate developers work on projects: they have
insufficient knowledge and experience to get the design right from
the start, so they make and correct many mistakes in their designs
as they evolve.
The firt thing to acknowledge, is that LifeFlow clearly has some
bad design decisions. Like the analogy I started this entry with,
there are broken windows here.
When I started LF, I was deliberately bullish on the
app versus project distinction, because I wanted LF to
be a one-step deployment. Unfortunately, deploying on Django
is still prohibitively complex for the WordPress crowd
(vaguely a programmer on WordPress was who I was originally
targetting, by which I mean myself).
This was both a mistake and a failure.
LifeFlow has a ridiculous amount of
flexibility, but a lot of it is misguided flexibility that
overrides best-practice with arbitrary.
Flexibility will always be core to LF, but some of the existing
mechanisms need to be scaled back.
There are many ways to reach the same article.
Different people want different things, especially
as we move across cultures, there are simply different
ways for organizing and locating content.
LifeFlow wants to provide a wide cross-section of ways
to label and organize.
Support for skins, which make it easy for users to inject their
own custom CSS and JS.
Will be removed. (AOBP.)
Support for mods, which can add arbitrary functionality to
LifeFlow. The example mod is for setting up
Will be removed. (YAGNI.)
Text filters which allows all comments and entries to be
passed through arbitrary filters for modification.
This functionality is used to render comments and articles,
and also allows a tremendous amount of flexibility. You could
trivially implement a swear-word filter for comments, turn
the first occurance of
Django into a link in each article,
or do almost anything, really.
The LifeFlow Editor, which is a complete Ajaxy replacement
for managing LifeFlow deployments (similar to the Django admin,
but with a blogging-centric workflow).
There is a lot of functionality packed into the LFE. Previewing
article rendering, a 'draft' concept, which distinguish between
published and unpublished articles, and much more.
Simple content management system for files.
Several custom markdown enhancements, including dynamic blog context,
as well as a custom syntax highlighting mechanism, and a syntax for
injecting ReStructed Text, Textile and raw markup into Markdown.
This stuff adds huge value for me, especially the dynamic blog context,
which has a number of tricks (the most helpful is that it automagically
allows including named files/images across articles once you have uploaded
Breaks the 'blog' into multiple flows, which are meta-tags for
content. The idea is to host multiple blogs each with their distinct
content and topic within one LF deployment, while allowing complete
cross-polination of the content (share tags, share archives,
are intermingled on front page, etc).
Projects which are non-date based data.
This is functionality that I really want, but I really
dislike my current implementation as well.
Its own implementation of threaded comments with spam
fighting reverse-captchas. (My comments are completely
open, and I get no comment spam. I'd hardly argue that
my implementation is superior to others, but merely
that it is sufficiently different and the number of
LF users small enough that spammers haven't yet figured it
Article series are a first-order citizen, which allows
some really useful organizational tweaks. I think this is
a really helpful feature, and it saves me a ton of time
compared to what I needed to do in WordPress.
Archive view for entries based on generic date views.
Sitemaps integrated into app.
Ten distinct types of rss feeds (all, author, flow, tag, series, translations, proejcts, comment, comments for entry, language).
Multiple author support, where each article can have
0+ authors associated with it.
Can notify an arbitrary list of sites when an entry is published.
BlogRoll for linking to other authors.
I am going to begin this work in a new branch right this second.
We'll see where it takes us.