Habari Design Menifesto
Khaled Abou Alfa
I've been thinking about this for a week now and I was able to put some
of my ideas onto 'paper' so please have a read through this and add and
omit ideas as you see fit. Once we thrashed out some more ideas things
that people think we should include, then I might be able to start
making the mockups (which to be honest shouldn't be too difficult as
I've got my method of doing these things now and I'm genuinely pretty
fast as it nowadays).
Habari Design Manifesto.
I see Habari as the start of something special. We're all in the unique
position to be on the ground floor of what could possibly be the Debian
of the blogging world. Blogging has come a long way and has a long way
to go before people have said what it has they have to say, if that day
is ever to come(which I don't think it will). That's part of the reason
why it's as popular as it currently is and why I believe in many
respects it will continue to exist in one form or another.
We've seen over the years that blogging is no longer confined to the
world of writing your thoughts, adding a couple of links and that's
about it. The way in which people choose to blog has changed. Now people
leave videoblogs and audioblogs, photoblogs and sketchblogs. Effectively
blogging is about publishing your ideas in which every method or format
that you choose. With this in mind it is important for us as the
developers of Habari to take this point into account and no longer
confine ourselves to one method of publishing information. It should be
seen as a flexible and modular system.
If we build a flexible and easy system to use, then people will use it
for other things. We should have the forethought to be able to adapt and
allow them to customise their administration seamlessly without too much
hassle. The design of the user interface should reflect and ultimately
compliment these points completely.
As such I see that there are three pillars we should be considering.
Publish – I suppose we can try and be specific, although I think if
we're going to be forward thinking about this we shouldn't call it blog
or write, as write isn't really the correct way of approaching the
subject. It really should be a more generic description and Publish does
fit that bill. As expected this is all about taking the content and
putting it out there. From here it should be just as simple to publish a
post as it is to publish a page. Obviously there are defaults, that
being publishing a post rather than a page. This way you reduce the
number of pages that you have to flick through. It's all about how funky
and clever we can be with the code. Of course the number of times that
we actually need to create a page might not be all that often. However
this could be provided in such as way as radio option, as in post or
page.
Manage – It's all about managing your already published content. For
some reason in the past couple of months the word content really sounds
like a dirty word for me. It's like content is filler rather than our
memories, thoughts and ideas. Having said that it does encompass what
I'm aiming at. Posts, comments, links, pages etc.
Administration – This is for actually sorting out the admin panel itself
and all the inner workings of the backend interface and functionality.
You control user information, plugins, themes, and the actual look and
functionality of the admin panel itself.
Modular Design -
By breaking it down into three areas this focuses the user and keeps the
clutter away from them. Now there are several ways in which the actual
focus of three can be presented to the user. The first is that this can
be achieved right at the start which is the dashboard of sorts.
Obviously the only information on this particular page should be that
relating to the actual user themselves. I'm still undecided if it's a
good idea to have it right in the front page and maybe it's more
sensible in having all of this either as the front page for the manage
or the admin pages. When you log in, it should ideally take you to the
main publish page. it's one less click to get to where you need to be.
For current information regarding what is going on in the website we
might choose to have a text link at the top which takes you directly to
and activity page or something similar to that.
The main page should be as simple or as cluttered as the user likes it,
and I don't mean in the same way that WordPress allows the user to hide
and unhide the various options that are available to him. I mean
literally remove them from their site, unless the actually want this or
not. The number of various elements will be seen and added from within
the admin location. From there you'll be able to customise the look of
the admin elements through a series of radio buttons that you tick or
untick. Of course you should also include explanations about each one so
that the end user understands what it is that they are doing away with.
The idea is simple, what I would want to have in my write page could be
significantly different to what other people could want or need. For me
I need the title, the slug, tag, category and the post section.
Everything else is pretty much superfluous for me. However that's only
because I choose it to be this way. Some one else might want the
password option in there as well. The thing is you can't possibly cater
to everyone's needs. What you can do however is something slightly
different. You can allow them to pick and choose what they require here
and at the same time allow the code to be open enough so that when there
is a pretty popular plugin this can be integrated into the core code
without really modifying the code. The extension feels as if it were
part of the core code and in some cases it might actually make it into
the core code as well, thus keeping the ideals of the project about
openness at all times.
One other idea is that we can have full options for the user to
customise for themselves or we can have additional options which pick
typically used elements. We could have the beginner's general option
which allows for the full explanations next to the actual elements. We
could have the photoblogging general option which centres the need to
have the browse photos or whatever instead of the write post as that's
what's important, or the podcast tool at the top instead.
If we allow ourselves to think about these things right from the start
then we'll have an infinitely more flexible and powerful system that has
not been done before, which is why people will flock to the software
straight away, because it allows this level of flexibility and this
level of control which other software just doesn't allow unless you're a
programmer.
In a similar fashion the edit page for within the manage section should
also have the option that you can also add or subtract the number of
elements that you can add to that particular page. It's all about the
modularity.
Simplicity and full control should be what we strive for, because by
being simple we let people get on with the task of getting their ideas
down in the easiest and most fun way possible, and by giving the user
the control we also elevate ourselves above the rest by providing that
level of control.
Shawn Grimes
I've been on this for a little longer than you and have to produce
anything and here you come with all this! I really hope to get down
and dirty with this soon. Life has just given me a few hang ups over
the last week and a half. Anyway, enough excuses.
Khaled, I really dig the thoughts you've put in on this and I plan on
formulating my responses ASAP.
Scott Merrill
Your post was very thoughtful, and thought-provoking. Thanks!
You wrote:
> Publish – I suppose we can try and be specific, although I think if
> we're going to be forward thinking about this we shouldn't call it blog
> or write, as write isn't really the correct way of approaching the
> subject. It really should be a more generic description and Publish does
> fit that bill.
+1 I concur that we should build the system around a media-agnostic
metaphor. Whether someone wants to publish text, audio, video, or
something else, Habari should support it.
> From here it should be just as simple to publish a
> post as it is to publish a page. Obviously there are defaults, that
> being publishing a post rather than a page.
As the engine currently stands, there is no meaningful distinction
between a "post" and a "page". This is certainly up for discussion and
modification, but the current mechanism is simply to publish the text.
Our URL structure is site.com/post-title. We're not currently using
date-based URLs -- although we do plan to support them for people who
want to use them.
The reason I use date-based URLs is because my blogging software
recommended that as one of the defaults. I didn't think about it much
at the time, but since then, I've determined that my readers don't
navigate my site by date, so date-based URLs aren't really important to me.
> Manage – It's all about managing your already published content. For
> some reason in the past couple of months the word content really sounds
> like a dirty word for me. It's like content is filler rather than our
> memories, thoughts and ideas. Having said that it does encompass what
> I'm aiming at. Posts, comments, links, pages etc.
Can you elaborate a bit on your thoughts about management? In what way
will you manage your content?
Speaking solely for myself, I don't manage my content much once I've
published it. I occasionally update the spelling in a post, but that's
about it.
I assume comment moderation falls under your "manage" umbrella -- a
categorization with which I would not disagree.
What do you have in mind for this aspect of the software?
> Administration – This is for actually sorting out the admin panel itself
> and all the inner workings of the backend interface and functionality.
> You control user information, plugins, themes, and the actual look and
> functionality of the admin panel itself.
Makes sense. I like what Owen said in a different email,
"Habari should not strive for overcomplication
in its settings. It should also not reduce the
number of available options in a simple attempt
to reduce the complexity of the settings themselves.
Default options should allow the system to be
extensible without exposing too many complicated
settings to the user."
> When you log in, it should ideally take you to the
> main publish page.
This is what I would like to see.
> For current information regarding what is going on in the website we
> might choose to have a text link at the top which takes you directly to
> and activity page or something similar to that.
It's also possible to include a snapshot of some of the major stats of
the site directly in some admin element: a header, footer, or sidebar,
so that you can see and act upon anything you feel is important.
> The main page should be as simple or as cluttered as the user likes it,
> and I don't mean in the same way that WordPress allows the user to hide
> and unhide the various options that are available to him. I mean
> literally remove them from their site, unless the actually want this or
> not. The number of various elements will be seen and added from within
> the admin location. From there you'll be able to customise the look of
> the admin elements through a series of radio buttons that you tick or
> untick. Of course you should also include explanations about each one so
> that the end user understands what it is that they are doing away with.
I like the idea of this, but I've seen it implemented poorly in other
applications so as to limit its usefulness. Drupal has a mechanism for
adding and removing administrative menu links. It's cumbersome, and not
entirely intuitive. :(
> One other idea is that we can have full options for the user to
> customise for themselves or we can have additional options which pick
> typically used elements. We could have the beginner's general option
> which allows for the full explanations next to the actual elements. We
> could have the photoblogging general option which centres the need to
> have the browse photos or whatever instead of the write post as that's
> what's important, or the podcast tool at the top instead.
Interesting proposition. I don't think I fully understand your
examples, though. Could you explain them in a little more detail please?
--
ski...@skippy.net | http://skippy.net/
gpg --keyserver pgp.mit.edu --recv-keys 9CFA4B35
506C F8BB 17AE 8A05 0B49 3544 476A 7DEC 9CFA 4B35
Rich Bowen
On Nov 13, 2006, at 19:09, Khaled Abou Alfa wrote:
>
> Habari Design Manifesto.
> I see Habari as the start of something special. We're all in the
> unique
> position to be on the ground floor of what could possibly be the
> Debian
> of the blogging world.
Um ... the Debian of the blogging world? What does that even mean? To
me, it means "always a couple years behind, and overly complex, with
a fanatical and user-unfriendly community." Presumably you meant
something different?
> We've seen over the years that blogging is no longer confined to the
> world of writing your thoughts, adding a couple of links and that's
> about it. The way in which people choose to blog has changed. Now
> people
> leave videoblogs and audioblogs, photoblogs and sketchblogs.
> Effectively
> blogging is about publishing your ideas in which every method or
> format
> that you choose. With this in mind it is important for us as the
> developers of Habari to take this point into account and no longer
> confine ourselves to one method of publishing information. It
> should be
> seen as a flexible and modular system.
Certain other blogging solutions make me feel like an idiot whenever
I try to add non-textual stuff to a posting. We need to liberate
people from their tools, and make it easy to really say what you are
thinking.
>
> If we build a flexible and easy system to use, then people will use it
> for other things. We should have the forethought to be able to
> adapt and
> allow them to customise their administration seamlessly without too
> much
> hassle. The design of the user interface should reflect and ultimately
> compliment these points completely.
And the design of the code should be such that when folks attempt to
use it for things that we never intended, it rolls with it
>
> ... From here it should be just as simple to publish a
> post as it is to publish a page. ...
I don't really know what the difference is between a post and a page.
I have never figured that one out. The distinction seems very
artificial to me. We need to either clarify the distinction, or do
away with it.
>
> Obviously the only information on this particular page should be that
> relating to the actual user themselves. I'm still undecided if it's a
> good idea to have it right in the front page and maybe it's more
> sensible in having all of this either as the front page for the manage
> or the admin pages. When you log in, it should ideally take you to the
> main publish page. it's one less click to get to where you need to be.
> For current information regarding what is going on in the website we
> might choose to have a text link at the top which takes you
> directly to
> and activity page or something similar to that.
+1. When I log into the admin area of my blog, 98 times out of 97,
I'm there to post a new article. A dashboard is a useful feature, but
it's not the Main Thing.
>
> The main page should be as simple or as cluttered as the user likes
> it,
> and I don't mean in the same way that WordPress allows the user to
> hide
> and unhide the various options that are available to him.
The one useful thing on the WP dashboard - the ability to display RSS
feeds - was crippled by the fact that it displayed RSS feeds of blogs
in which I had zero interest. Having the ability to use this as a
micro-aggregator might be useful. But probably not. Let's stick to
stuff about the current website.
>
> The idea is simple, what I would want to have in my write page
> could be
> significantly different to what other people could want or need.
> For me
> I need the title, the slug, tag, category and the post section.
> Everything else is pretty much superfluous for me. However that's only
> because I choose it to be this way. Some one else might want the
> password option in there as well. The thing is you can't possibly
> cater
> to everyone's needs. What you can do however is something slightly
> different. You can allow them to pick and choose what they require
> here
> and at the same time allow the code to be open enough so that when
> there
> is a pretty popular plugin this can be integrated into the core code
> without really modifying the code. The extension feels as if it were
> part of the core code and in some cases it might actually make it into
> the core code as well, thus keeping the ideals of the project about
> openness at all times.
Yes. +1. And I have different requirements on different blogs. On
one, I post only podcasts, and I do them several days in advance, and
so those two things (podcasts, date stuff) need to be easy, and
everything else needs to be absent. On another site, I post text
stuff, and never touch any of the other options.
> One other idea is that we can have full options for the user to
> customise for themselves or we can have additional options which pick
> typically used elements. We could have the beginner's general option
> which allows for the full explanations next to the actual elements. We
> could have the photoblogging general option which centres the need to
> have the browse photos or whatever instead of the write post as that's
> what's important, or the podcast tool at the top instead.
Having a simple but useful media management system is essential.
>
> Simplicity and full control should be what we strive for, because by
> being simple we let people get on with the task of getting their ideas
> down in the easiest and most fun way possible, and by giving the user
> the control we also elevate ourselves above the rest by providing that
> level of control.
I've noticed an interesting phenomenon with non-geeks. If you ask
them if they want to blog (context: please blog on our university
website, because you have interesting things to say) the answer is
universally, no, I don't blog, I'm not a geek, I don't understand
that stuff. If, however, you ask them if they'd be willing to write
up a few of their thoughts, share some of their photos, show the
world what they are working on, they tend to be a lot more
enthusiastic about that. It would rock if we could create a tool that
totally gets out of the user's way, and lets them express their
ideas. Good software is invisible. Certain other blogging engines
seem to assume that you're a geek, want to tinker, and are delighted
about things like "enclosures" and "RSS" and "XML" and "HTML" and
other strange concepts. We need to free people from the tyranny of
technology, and give them a way to express their dreams.