On Sep 26, 2008, at 1:43 PM, Owen Winkler wrote:
> > Arthus Erea wrote: >> >> In themes we would encourage the use of displaying a 'footype.item' >> within the foreach loop of the multiple list – thus allowing plugins >> to define templates for use _within_ the multiple listing. > > That is how Drupal works. You create a wrapper "page.tpl" template, > and > then each content type has a template that is used to display it > within > that template. So I understand. > I think it's important to point out the dichotomy of theme > construction > methods between WordPress and Drupal theme styles. Each method of > theming offers significant advantages over the other. Particularly in > the case of WordPress style themes, the theme developers for "blog > themes" are abundant, and they know only this way of constructing > themes. This isn't an evaluative judgment on choosing one over the > other -- It's a statement that we should support both ways if we > change > anything from what we already have, specifically because blog theme > developers will look to design for a WordPress-theme model (something > that fits in their idea of how a theme is constructed, which is > currently what Habari provides) but the flexibility of the Drupal- > theme > model can't be denied, and seems to be more prevalent in emerging > microblog platforms, such as Chyrp or Tumblr. Agreed: both have their advantages. That's why I actually think we should _support_ both, but encourage Drupal/Chyrp-style. That way, you can easily develop "blog" themes – so themes can proliferate. Likewise, "advanced" themes can come out (somewhat like K2), which support the full flexibility of my suggested approach. So, encourage flexibility but don't force it. >> Honestly, I don't think we need to make it as complicated as all >> that. >> Just one more field for each post and a dropdown to select that. > > We need to work within the system we're constructing, and not fight > it. > We're introducing a robust taxonomy system that can be used to do > exactly this without adding theme-specific controls to the UI. > Adding a > dedicated "where do you want this post to go" control is emphatically > not the way to accomplish this while still remaining flexible. Certainly agreed. I think we should definitely use the full power of the taxonomy system. I just don't think we should allow this to drop to the wayside due to perceived or actual difficulty. It is simply too compelling of a feature to do that. I envision this, combined with our powerful content-type support, being something we can very concretely point at as something which makes us different from the other platforms out there. >> A system where new content-types are isolated from each other (the >> current situation) just isn't what I think we need. When you see the >> kind of functionality which Tumblr and Chyrp are offering, I think we >> start to see why Habari could use this sort of flexibility. > > I retain my concern for being careful about this. We're not > rebuilding > Chyrp or Tumblr, nor are we trying to compete with their features. > Habari is its own thing. Agreed: we need to do this the Habari way. However, it is worth looking at the "hot" new competition to see the kinds of things people get excited about. > While their functionality might be useful to include in this case, > if we > continue to approach what features to add in terms of seeing an > application that we like and modeling Habari after it, what will > eventually stop us from including, for example, full-on Gallery > functionality? You can easily say that "Gallery is not a blog", but I > personally don't think Chyrp or Tumblr are traditional blog > applications, either. Maybe not, but I certainly think their functionality is close enough to blogging that it should be able to be done through Habari. If anything, I think what Habari needs to prove is how flexible we are. Yes, we will maintain our focus on traditional blogging: we only include one content type to start and most themes will only have two content "places." But it truly shows our power if we are able to support both traditional blogging and "new" blogging. I think new content-types should be implemented through plugins, but this functionality needs to be core if it is done at all. > I'm just saying that this slope is slippery, and others (WordPress) > have > ascended it in some ways to what I think is ill effect. Be careful. Agreed: we certainly need to look at every feature for its merit, not just to "keep up with the Joneses." However, I do think the Habari approach can be substantively different from WordPress in that we can focus on developing new _tools_ and _utilities_, rather than outright features. As an example, instead of implementing versioning (as WP chose to do), we simply implement the API to allow functionality like that. So, I guess our focus should be on adding and improving powerful APIs, rather than bloated features. --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
