Feedback
Ben Lagoutte
I've been playing with 0.6.1 release of Habari for the last few days. First thing I'm impressed and enthusiastic about the overall cleanliness and structure of the project, it's refreshing, well done.
I'm coming from a background of a lot of Wordpress and CodeIgniter, it's great to be given something that feels in between the two (or above maybe :).
A couple of comments, or questions I guess... I know there is plenty to do and this is only version 0.6 and i'm looking forward to the future releases but I thought i could open this discussion (if it's been discussed already apologies, I couldn't find a full discussion about it).
As a background first:
We use Wordpress a lot with our clients, but not in the blog-centric standard way it is normally used. A lot of our client need a website more than a blog and we tend to build it around the WP concept of 'pages', keeping the 'posts' for featured news item.
The reason we use WP so much is that our clients seem to 'get it', it's simple to explain to them, the interface can be obscure on the edges (custom fields, etc) but the bulk of the editing is simple. It can be a messy nightmare for us developer to code with but the clients don't care about that, they just want something simple to use...
And I very much like Habari for its simplicity too. I think you guys have done a great job with the interface usability, and as an added bonus for us developers, you have surpassed yourselves with the development environment.
However, at the stage habari doesn't seem practical for building a 'website' like we normally do with Wordpress.
The two main things that seem missing for us is the page structure:
* There is no nesting of pages. I cannot see any way to nest a bunch of pages together below another. Without that we can offer our clients a way to organise their website structure.
* There is no easy way to order the pages. I know it can be done by modifying the publication date but this doesn't fit that ease of use I mentioned above. Seems overly complicated for a client to have to do that just to order a few pages.
Basically at the moment the pages system feels more like the entries, in some kind of isolated custom category.
Are there any plans to extend that behaviour? For me, that's almost the show-stopper for being able to use habari with our clients... which is frustrating because I'm really excited about it and I really want to be able to use it for a project.
I understand it's a 'blogging' platform but from a developer point of view it could do so much more just those couple of things in.
Otherwise, wow, genius!
Cheers,
Ben
Michael C. Harris
>
> The two main things that seem missing for us is the page structure:
>
> * There is no nesting of pages. I cannot see any way to nest a bunch of
> pages together below another. Without that we can offer our clients a way to
> organise their website structure.
The next version of Habari will have taxonomy support, allowing for
the description of all sorts of relationships between objects, and
there will be a subpage plugin that uses that. There is actually a
subpage plugin at the moment that lets users define a page as a child
of another page, but it's incomplete and not production ready.
> * There is no easy way to order the pages. I know it can be done by
> modifying the publication date but this doesn't fit that ease of use I
> mentioned above. Seems overly complicated for a client to have to do that
> just to order a few pages.
I'm not really sure what you mean here. How and where do you want to
be able to order pages ? In a way, pages are designed to be standalone
for display rather than ordered. There is a page menu plugin that's
specifically for ordering page menus.
You can also pass an orderby parameter to Posts::get() that can order
by any column in the database. A silly example.
Posts::get(array('content_type'=>'page', 'status'=>'published',
'orderby'=>'title DESC'));
It may be that taxonomy is the answer to your page ordering issues too.
> Otherwise, wow, genius!
I have nothing to say to this point, but I can't snip it :)
--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog
IRC: michaeltwofish #habari
Ben Lagoutte
Thanks for taking time to reply.
That is great to know that the page nesting is coming up. I don't think we can use habari for our clients until that's in. looking forward to it.
Is that going in version 0.7?
In regards to the ordering. I agree with you that some ordering can be achieved by using the right query, but that's a fairly rigid implementation. There should be some easy way for a client, as a site admin, to choose an arbitrary ordering that's not based on a content field like the title or the id or the publication date.
In the situation of using habari as a website cms, if we have a given page section - say 'Our products' to pick a common example - and below that a bunch of sub-pages for each product, the ordering might not be alphabetical by title, or by id, it might just be the client's choice to have one item before another (say if they want to push a new product at the top of the list). They likely will also want to be able to change that order at any time... they can pay the developer to edit a menu every time they add or change something in the admin. I reckon the administrator should be given a way to do so through the interface.
WP for instance did introduce a 'menu_order' field to their page system, which I actually really don't like, it requires people entering numerical values in a field to specify the order - seems they really didn't try very hard with that feature (there you go, here's a free field) - but that does at least give the ability to specify an arbitrary order.
The WP comparison stops here. I guess if habari was to have something like that, it should be a smarter approach than just a free field like Wordpress did. That would put habari above WP in that area too.
I guess in a way i'm speaking on behalf of our clients - which will drive our potential use of habari - and this ordering thing has been a requirement over and over. I can't think of any website that we did where they didn't want to do this one way or another.
I think this would be a great addition if it's thought through and integrated a-la-habari :)
Ben
Arthus Erea
Hi Michael,
Thanks for taking time to reply.
That is great to know that the page nesting is coming up. I don't think we can use habari for our clients until that's in. looking forward to it.
Is that going in version 0.7?
In regards to the ordering. I agree with you that some ordering can be achieved by using the right query, but that's a fairly rigid implementation. There should be some easy way for a client, as a site admin, to choose an arbitrary ordering that's not based on a content field like the title or the id or the publication date.
Chris J. Davis
Owen Winkler
>
> The WP comparison stops here. I guess if habari was to have something
> like that, it should be a smarter approach than just a free field like
> Wordpress did. That would put habari above WP in that area too.
Habari will probably not have a "page order" field. The in-development
code for Taxonomy allows the system to define multiple MPTT (modified
preorder tree traversal) structures that describe trees of organization.
Each of the structures in the taxonomy is called a "vocabulary" and has
a name. A Vocabulary can be defined with a required one-to-one
relationship with posts.
What this lets you do is define a Vocabulary named "products", and then
create a tree of Posts, each with its own title (it can just be the
Post's title, or it can be something else entirely). Using the
functions in the Taxonomy-related classes, you should be able to
retrieve a list of posts that have been associated with that vocabulary,
and in an order that allows you to build a menu or a structured
ul/ol-type list.
The call for Posts::get() should also be modified to return posts that
qualify for specific taxonomy characteristics, but will probably not
return posts in a tree structure (although they may be properly
ordered). A separate call (as I mentioned above) using
Vocabulary::get_term() will return a term that has methods to iterate
through the tree of that vocabulary and obtain the linked Post to each
term. A helper method like Vocabulary::get_object_tree() could probably
return the Posts with an ordered "children" property.
The evolving API definition for Taxonomy is here:
http://wiki.habariproject.org/en/User:ringmaster/Taxonomy
The implications of this are that you could create multiple
vocabularies, one for each menu you want to create. Each vocabulary can
contain any posts, so a post can exist in a single menu more than once
and a post can exist in many menus.
You could do crazy things with this system like build one primary menu,
then build multiple secondary menus, and only display one secondary menu
based on the Scope (using our blocks/areas/scopes features) of the page
displayed.
As an example, if you're Nike, you'd have a primary menu with "Shoes"
and "Sportswear", which are also complete secondary menus unto
themselves. When displaying pages that qualify in the "shoe" scope, you
could display the "Shoes" secondary menu in a sidebar block, and
likewise use the "Sportswear" secondary menu instead on a page showing
basketball shorts.
Building the underlying system properly is really important to us right
now. What you'll find missing in the system so far is a way to use the
UI to set any of this. Suggestions for this are welcome, although I
think for our first iteration (although the more I think about it, the
more I think this may be a permanent condition) the only UI for Taxonomy
will be via plugin. That means that if you want a menu that you can
configure, you'd activate a plugin for that.
Eventually, we'll probably include a default menu plugin in the
distribution, but because the system I've described above is so
flexible, we'd want to give users the option to disable any native menu
system completely to replace it with a custom system that either comes
pre-packaged from the extras repo or from a custom code developer.
The conversation I've had many times with many people is that "Taxonomy"
as an idea is much too complicated to expose some kind of generic
interface and let the end-user sort it all out. We'll include some
basic plugins that make use of the underlying system, but we'd probably
be well off to never have an interface element that says "Create a new
vocabulary", since that could mean many things depending on how it's
implemented.
I hope that gives some impression of the plan that we're trying to
implement with sub-pages and navigation. There are still some sticky
bits, as I said, with UI and also with URLs. I know everyone says that
they want /grandparent/parent/child URLs, and figuring out a clean way
to both allow and generate those (and in my opinion, whether you'd even
need them) is also an interesting challenge.
Pitch your ideas here.
Owen
Chris J. Davis
system with a custom one, I don't agree that the only UI should be
from a plugin. This is a core feature of Habari and as such there
should be a well thought out UI for interacting with it. I think that
this should be a simple system, that shows the power of the taxonomy
system. Since subpages are such an oft-used feature, I think it makes
a great deal of sense to have the core UI we build for taxonomy
implement that feature.
Chris
Owen Winkler
> While I agree that we need to allow the user to completely replace the
> system with a custom one, I don't agree that the only UI should be
> from a plugin. This is a core feature of Habari and as such there
> should be a well thought out UI for interacting with it. I think that
> this should be a simple system, that shows the power of the taxonomy
> system. Since subpages are such an oft-used feature, I think it makes
> a great deal of sense to have the core UI we build for taxonomy
> implement that feature.
As with all of the features in Habari already like this (undelete, core
dashboard modules, local media silo, pingback, etc.), this feature
should be a plugin that the installer suggests to enable by default.
I think it's sad that we've already got "tags" in core (which will use
the Taxonomy API) that we can't remove that to a plugin also when
Taxonomy is complete. It's a feature I'd love to implement in a
different way (like, omitting the tags admin page entirely).
Subpages are a mere subset of the functionality of Taxonomy. By their
nature, they don't demonstrate the full force of the underlying feature.
There will always be something better, or something more custom
required, and I can't imagine a default UI (perhaps that's my
limitation, but I suspect it's not) we could design to accommodate all
of those alterations.
Owen
Arthus Erea
a core plugin.
Once taxonomy approaches a truly usable state (is it there?), I'd be
happy to write the plugin for it.
Chris, I definitely was thinking a "drag and drop" UI for the page
reordering. This'd probably branch off either the plugin page or the
theme page.
Michael C. Harris
>
> Chris J. Davis wrote:
>> While I agree that we need to allow the user to completely replace the
>> system with a custom one, I don't agree that the only UI should be
>> from a plugin. This is a core feature of Habari and as such there
>> should be a well thought out UI for interacting with it. I think that
>> this should be a simple system, that shows the power of the taxonomy
>> system. Since subpages are such an oft-used feature, I think it makes
>> a great deal of sense to have the core UI we build for taxonomy
>> implement that feature.
>
> As with all of the features in Habari already like this (undelete, core
> dashboard modules, local media silo, pingback, etc.), this feature
> should be a plugin that the installer suggests to enable by default.
[snip]
> Subpages are a mere subset of the functionality of Taxonomy. By their
> nature, they don't demonstrate the full force of the underlying feature.
> There will always be something better, or something more custom
> required, and I can't imagine a default UI (perhaps that's my
> limitation, but I suspect it's not) we could design to accommodate all
> of those alterations.
After having worked on and thought about the taxonomy system and a
subpages plugin for a while now, I agree with Owen. A generic 'Manage
Vocabularies' page wouldn't be useful, because in and of themselves
vocabularies aren't useful, they need something extra. The appropriate
place for that extra is in a plugin, which needs to supply its own UI.
As things stand, the subpages plugin doesn't use a UI at all, there's
simply a drop-down in a Page's settings tab where you can choose a
parent. I can see that a hierarchical drag and drop would be a useful
addition to it, but I don't think core is the place for it.
I think with tags reimplemented as a taxonomy, and a subpages and
maybe pagemenu plugins, that would be a good suit of examples.
Ben Lagoutte
Damn, you really kept busy over the weekend. It's great to see such activity in the project.
I'm not sure if I can add much to the already in-depth discussion...
In terms of interface, i think it's really important to keep a non-tech savvy user in mind (the wp free field is starting to push it for some clients). Drag and drop seems like a good solution, quick and intuitive (most people have at some stage dragged files or folders in their finder/explorer/thing-for-files).
I'm looking forward to see the taxonomy system in action in 0.7.
This discussion is making me feel I really should study the plugin architecture in the mean time :)
Cheers,
Ben