Platform
Owen Winkler
thought I would throw it out there for the sake of having it talked
about and maybe get some opinions on the matter.
It seems that in the circles I travel, many people use WordPress as a
framework for their development work. I know that other people on
this list do the same thing, and I have been guilty of this myself on
several occasions.
I've been wondering lately how Habari could improve on what WordPress
offers as a platform for creating non-blog sites. It's the question
that I get asked most by developers I know, and my response has
usually been "we're building blog software on a good foundation, and
if our foundation is solid, then you should be able to easily do
things with it other than blogging". And I believe that's true, but
should we be considering foundation/framework features in Habari for
the benefit of customizers and developers of non-blog sites? I think
that the answer is "yes", and for particular reason.
One of the things that really attracted people to WordPress was when
back in version 1.2 (I think) they officially started adding plugin
hooks -- a way to easily add functionality to the software.
Developers started to build on that code, offer suggestions, and make
plugins that extended the software in ways that it was never really
intended to go. One of the things I think made WordPress the force
that it is are the contributions of developers in this regard.
Habari is in a unique position today. While I don't think we should
stray from our core target of providing the best blogging platform we
possibly can, I do think that many of the developers involved in the
project are working from the perspective of having modified WordPress
for clients to do something that it was not intended to do. That
being the case, we have unique knowledge in how to build Habari so
that what issues we might have had during our trials with WordPress
are not issues on our new platform of choice.
Hopefully, by making Habari that much easier to customize, we can lure
those additional developers to our platform and gain additional
advantage from their contributions, just as in the "golden days" of
WordPress development. I think this will be an advantage not just to
Habari as a platform to other kinds of development, but specifically
to Habari's core purpose of being blog software.
I do not want to be left in the position of abandoning my beloved
Habari for client-specific customization tasks simply because Habari
is too blog-focused. I see great advantage to being able to code
Habari on company time for commercial clients, which can do nothing
but improve the Habari codebase.
Do you think this is a worthwhile cause, and if so, what suggestions
do you have that might be useful for achieving this goal? Do you
think we can do this while remaining true to our original intent of
providing the best blogging package that we can?
Your thoughts are appreciated.
Owen
Scott Merrill
> I do not want to be left in the position of abandoning my beloved
> Habari for client-specific customization tasks simply because Habari
> is too blog-focused. I see great advantage to being able to code
> Habari on company time for commercial clients, which can do nothing
> but improve the Habari codebase.
>
> Do you think this is a worthwhile cause, and if so, what suggestions
> do you have that might be useful for achieving this goal? Do you
> think we can do this while remaining true to our original intent of
> providing the best blogging package that we can?
What WordPress and Habari (and Drupal, and S9Y and Textpattern) all do
is basically the same: web based publishing. The "blog" moniker -- to
me -- signifies the target audience of the default product: people who
want to run a blog (personal or professional).
That WordPress and other systems can be made to do stuff for other
audiences is, as you observe, a function primarily of plugins. If we
want to demonstrate that Habari can be more than "just a blog", then I
think a few dazzling plugins should suffice for that purpose.
habariproject.org is a great opportunity to demonstrate how Habari can
be used to power a complex, information-rich site. If we can publish a
"how we did it" tutorial, that would go a long way toward helping others
see the power of Habari.
What other plugins might be necessary to demonstrate Habari's
flexibility? A podcasting plugin might help. A news aggregation plugin
might help.
Ask yourself this: what site(s) do you consider exemplary of the
"WordPress used as a platform" model, and what plugins were used to
accomplish that?
--
GPG 9CFA4B35 | ski...@skippy.net | http://skippy.net/
Chris J. Davis
be on to something as well. There are things that should be easier
to do with a plugin. I know that there have been times when hacking
WP MU into submission that I have been cursing the decisions of the
developers to make information so hard to get to. This is where I
would like Habari to really shine. Our API should be second to none,
and be aware, even in the beginning, that plugin and theme developers
are going to want to get to all of our information, not just some of it.
Does that make sense?
Chris
Andrew da Silva
Other than that, I think Habari is on the right path, adding more hooks will help, maybe a couple of helper functions and formatting functions..
Sean T Evans
blog? Just looking at the sites of the people who are already running
Habari on their personal sites, we see a lot of different things going
on. We will never create a core product that does everything people want
even for "just blogging", so we need to look at what we can do to allow
people to carry out their own ideas of what a "blog" is. In doing so,
we'll (most likely) also allow people do a lot more than just blog.
I think the attitude we should have in regards to this is one of the
core product being stable, fast, and easy to use for typical blogging
functions, while having the flexibility to allow others to expand Habari
with ease.
We should, in my opinion, make every attempt to make all of the data
within habari accessible to plugins in some form. How realistic this is,
I don't know. That's why I like hanging around all you smart people. I
throw out crazy ideas, and you people make them happen. Neato.
Owen Winkler
>
> That WordPress and other systems can be made to do stuff for other
> audiences is, as you observe, a function primarily of plugins. If we
> want to demonstrate that Habari can be more than "just a blog", then I
> think a few dazzling plugins should suffice for that purpose.
Let me share what I think of as the primary hindrance to eschewing the
"blog" moniker for a generic "CMS" moniker: The admin.
Our admin is very blog-focused. The dashboard content includes drafts
of posts, recent comments, and number of posts. The admin navigation
focuses on creation of posts and moderation of comments. Of course,
this is natural for blog software, and is certainly not wrong for
Habari.
The question is, for a customized product that is to be delivered to a
client, is the blog-oriented stuff useful, and do we have a way to
replace it if the need is required? I think that while we're serving
our blog-oriented goals well, we might be limiting our adoption by
customizers because we don't allow this flexibility. Ultimately, it
might be nice to have a CMS package that turns a baseline
blog-oriented core Habari into a CMS platform, and rather than have
individual developers figure out the workings of that for themselves
(what combinations of plugins make that happen, etc), it could be
something we have in mind from the beginning.
Perhaps this is just an indication of an area that we can provide more
plugin hooks to achieve this alteration, but I want to see if it's
worthwhile or wanted to have these features as part of a checklist of
things we're trying to accomplish ("Make Habari very
contractor/customizer-friendly.") while building our blog software,
and aren't something separate from our main goal.
Owen
Scott Merrill
> On 8/16/07, Scott Merrill <ski...@skippy.net> wrote:
>> That WordPress and other systems can be made to do stuff for other
>> audiences is, as you observe, a function primarily of plugins. If we
>> want to demonstrate that Habari can be more than "just a blog", then I
>> think a few dazzling plugins should suffice for that purpose.
>
> Let me share what I think of as the primary hindrance to eschewing the
> "blog" moniker for a generic "CMS" moniker: The admin.
>
> Our admin is very blog-focused. The dashboard content includes drafts
> of posts, recent comments, and number of posts. The admin navigation
> focuses on creation of posts and moderation of comments. Of course,
> this is natural for blog software, and is certainly not wrong for
> Habari.
One of the long-standing complaints against WordPress is that the admin
dashboard is, for the most part, locked in. There are some clever (and
some crude) ways to make one's WP dashboard look like they want, as
opposed to the way the WP developers want; but this is not something
that WP easily supports.
I agree that our admin interface is blog-oriented. It ought not be too
hard to make the admin interface leverage the power of user-class
overrides in order to present a customized interface.
I think that's cool, and I'd like to see work toward that kind of
extensible framework from which one could customize the admin interface;
but I don't want all the other necessary improvements / development to
suffer as a result. Let's plan out how best to implement a customizable
admin experience, and work it slowly into the code alongside all the
other improvements we've yet to write.
Andrew da Silva
What I am going to try is to have the dashboard use "panels" which are basicly plugins but for the admin area... but that's nothing to be "committed", just something I'm trying out eh
Geoffrey Sneddon
On 16 Aug 2007, at 14:09, Scott Merrill wrote:
> One of the long-standing complaints against WordPress is that the
> admin
> dashboard is, for the most part, locked in. There are some clever
> (and
> some crude) ways to make one's WP dashboard look like they want, as
> opposed to the way the WP developers want; but this is not something
> that WP easily supports.
What about styling the admin area?
- Geoffrey Sneddon
Yellow Swordfish
download the latest every now and then and am looking forward to the
next developer release. But I have to put my oar in to the waters on
this thread! And I have said most of this stuff before here and
elsewhere.
Owen is absolutely right. By all means make Habari the 'best blogging
platform' around but that is no reason to disregard the even bigger
user-base who want the ease of use and extendibility of such a
platform for non-blogging use. It is both a bigger market and, in the
long term, a much more stable one and here the options are much more
limited. Yes there are great systems around but most are not so easy
to customise or extend as WordPress and with careful planning and
design you can make WP do some awesome stuff. And that, in my humble
opinion, is exactly what Habari should be targeting. Because where and
when WP does let you down - it seems to let you down big-time without
a net.
It starts with the schoolboyish "Howdy" on the dashboard (and I know
of people who have not taken it seriously just for that one word
alone! Luckily they never got to see the "Cheatin' huh?" message!) And
it works it's way up to the deplorable developer documentation. But
the biggest gripe I come across from the non-blogger community is the
half-hearted and seemingly abandoned implementation of 'pages'. (I
haven't looked at what you guys are doing with this yet but I do hope
you are taking them seriously). There is a whole organisational
structure that needs to be put in place around pages - not unlike
exists for posts - which the WP team refuse to consider.
So - for my money - I would advocate the following - no use of the
word 'blog' in the actual interface; promote pages to their rightful
place; add developer hooks everywhere (how many times have I needed a
do_action in WP that doesn't exist?); and above all - decent, up to
date, developer documentation so that the great stuff in the core
get's used. And I know documentation can be an insidious task but so
can trawling thousands of lines of php trying to find the bit you
want!
And, of yes, actually being able to customise the admin interface
would be a boon. I have spent hours trying to explain what's what on a
WP admin page to a user who just wants to do stuff and doesn't need to
see half the junk.
OK - nothing new but sometimes I need to shout off and I am so looking
forward to getting my hands wet on Habari when the time eventually
arrives.
Andy
h0bbel (Christian Mohn)
On Aug 16, 2:01 pm, "Owen Winkler" <epit...@gmail.com> wrote:
> I've been wondering lately how Habari could improve on what WordPress
> offers as a platform for creating non-blog sites. It's the question
> that I get asked most by developers I know, and my response has
> usually been "we're building blog software on a good foundation, and
> if our foundation is solid, then you should be able to easily do
> things with it other than blogging". And I believe that's true, but
> should we be considering foundation/framework features in Habari for
> the benefit of customizers and developers of non-blog sites? I think
> that the answer is "yes", and for particular reason.
I have never really considered my own site a blog. I call it "my
site", not "my blog". This might also very well be why I want my
theme, if I ever finish it and get migrated over to Habari, to be more
magazine-style than blog-style.
I for one would very much like to see and treat Habari as a framework
rather than a blogging platform, but all in all thats pretty much just
semantics. Perhaps Habari should be positioned as a blog framework
with the potential to expand on that as you see fit? After all, thats
what it really is, isn't it?
> One of the things that really attracted people to WordPress was when
> back in version 1.2 (I think) they officially started adding plugin
> hooks -- a way to easily add functionality to the software.
> Developers started to build on that code, offer suggestions, and make
> plugins that extended the software in ways that it was never really
> intended to go. One of the things I think made WordPress the force
> that it is are the contributions of developers in this regard.
Definitely. Wordpress strength has more to do with the plugin
developers that it has to do to with how the core product is evolving.
That being said, they did a good job in getting people interested in
developing plugins etc. for them, which they can utilize on
wordpress.com (cunning plan, Baldrick).
> Habari is in a unique position today. While I don't think we should
> stray from our core target of providing the best blogging platform we
> possibly can, I do think that many of the developers involved in the
> project are working from the perspective of having modified WordPress
> for clients to do something that it was not intended to do. That
> being the case, we have unique knowledge in how to build Habari so
> that what issues we might have had during our trials with WordPress
> are not issues on our new platform of choice.
>
> Hopefully, by making Habari that much easier to customize, we can lure
> those additional developers to our platform and gain additional
> advantage from their contributions, just as in the "golden days" of
> WordPress development. I think this will be an advantage not just to
> Habari as a platform to other kinds of development, but specifically
> to Habari's core purpose of being blog software.
To get people involved, they need to find a reason to do so. If Habari
provides a better framework than the alternatives, that should
certainly help as far as interest goes. Especially in custom work that
people do, as the PHP5 requirement will eliminate many of the casual
bloggers due to the current ISP PHP5 adoption rate.
> I do not want to be left in the position of abandoning my beloved
> Habari for client-specific customization tasks simply because Habari
> is too blog-focused. I see great advantage to being able to code
> Habari on company time for commercial clients, which can do nothing
> but improve the Habari codebase.
Of course, and the more people who can make real money of developing
custom solutions based on the Habari project, the more "professional"
development will happen. Habari will benefit from that.
> Do you think this is a worthwhile cause, and if so, what suggestions
> do you have that might be useful for achieving this goal? Do you
> think we can do this while remaining true to our original intent of
> providing the best blogging package that we can?
YES! Make the basic package a great blog platform, but make it
customizable enough for people to change it around as they see fit.
This doesn't mean that everything should be a configuration option, as
that would probably overwhelm people, but make it possible to display
the content in just about any way people would want. There is probably
a lot of different things people will come up with, if the platform
provides them with the possibility to do so.
I haven't been reading this list closely enough to know what has been
discussed before, but I would like to see a couple of things:
* Custom content templates:
The ability to register a custom template, that has access to specific
data. Why do I need a custom plugin to register the /archives rewrite
and to link it to a template in my theme? Why not just make that a
config option that lets me register /archives and then link it to a
specific template in my theme? Eg in theme.php (or even in the admin
section) set up a mapping between a rewrite rule and a template that I
want used when it's accessed? Give the template access to $posts and
hey, we have a publishing solution that would allow of easy
integration of other content or just a different view of existing
content. Simple and easy, and pretty powerful.
* Make "everything" pluggable:
Ship Habari with a very basic function set, and let people pick and
chose what they want activated. If someone doesn't want comment
support, feeds, file uploads etc, let them completely disable that
functionality. As far as I can see, this would help speed up
installations AND probably also limit security issues as the default
install wouldn't have as many bells and whistles as you potentially
could have.
* Easy plugin download/installation
As most probably know, I'm pretty involved with the Gallery project.
Gallery 2 currently has a system called "Downloadable Plugins", that
allows users to download/install/upgrade Gallery 2 plugins directly
from the site admin interface. You can chose which repositories DP
should have access to (Official, Expermental, Community) and you get
one-click installs for them. Works very nicely, and it's a great way
to keep the initial install lean and clean and let people expand on it
as they see fit.
Thats all I could come up with right now, I'm sure there is more once
I start thinking. Is there a TODO list somewhere that I should check?
Get good developer documentation readily available. I am no master
PHP, and I'm having problems figuring out how things work and how to
get it to work as I want (recent example is a simple archive page).
The better the documentation, the easier the customizing process will
be, and the more custom solutions Habari will see. Provide a good
basis for people to work from, and good stuff will happen.
> Your thoughts are appreciated.
Well, you _say_ that. ;-)
Christian
silverwing
Structure" post
http://groups.google.com/group/habari-dev/browse_thread/thread/aae6c2dae3208ff1/#
when I said Habari should be able to "go beyond" its basic premise.
~silverwing