New Idea: Content Types and Content Places
Randy Walker
types again
[04: 15am] michaeltwofish: yes, we must reinvigorate that discussion
[04: 16am] RandyWalker: michaeltwofish: instead of having "post" and
"page" be content-types... we could just have an option "show in
chronology" <-- if checked, it shows up like a "blog" entry,
otherwise, it's stand-alone. that way, you could, have, say a "page"
of video, and a "post" of video without 2 separate content-types
[04: 16am] RandyWalker: michaeltwofish: does that make sense?
[04: 16am] michaeltwofish: RandyWalker: what does that gain us?
[04: 19am] RandyWalker: I think it streamlines things... you just go
to write. you have some cotent. So you just go to the write page, add
your content. You want it to show up as a post so you click the
checkbox. Then you publish it. A few weeks later, you determine you
want it to be a more prominent part of your blog. So, instead of
copying and pasting into a page, you just clear the checkmark and it
gets added to your site's nav and pulled out of the chronological list
[04: 20am] michaeltwofish: RandyWalker: I will allow you to speak to
ringmaster about conversion between content-types
[04: 20am] RandyWalker: it wouldn't be a conversion
[04: 21am] michaeltwofish: so you're saying remove content types?
[04: 21am] RandyWalker: no
[04: 21am] RandyWalker: just remove the "page" type and have that be
an option for any content, instead of a separate type
[04: 24am] michaeltwofish: RandyWalker: I'm not seeing a strong
benefit for what would be a fair amount of work.
[04: 24am] michaeltwofish: I don't see that happening very often
[04: 24am] RandyWalker: michaeltwofish: I'm working on something
[04: 24am] RandyWalker: I'll show you in a sec
[04: 34am] RandyWalker: ok
[04: 34am] RandyWalker: lemme 'splain this to y'al
[04: 34am] RandyWalker: http: //randywalker.net/misc/pictures/
habari-20080409-043416.png
[04: 34am] RandyWalker: you go to your blog
[04: 34am] RandyWalker: you want to add some content
[04: 35am] RandyWalker: you decide what kind of content (can add more
types just like now), for example: just text, a list, a form, a
video, whatever
[04: 35am] RandyWalker: after you write
[04: 35am] RandyWalker: you have an option
[04: 35am] RandyWalker: do you want this to show up as a blog entry?
[04: 35am] RandyWalker: or a page?
[04: 35am] RandyWalker: or in a different location (sidebar, for
example)
[04: 36am] RandyWalker: so if a blog, it would be in the red area, if
you want it a page (outside the list of entries), in the green area,
or sidebar in the yellow area
[04: 37am] RandyWalker: so, if you decide to put it in the sidebar, it
would be like a WP widget
[04: 37am] RandyWalker: otherwise, they would either be an entry or a
page
[04: 37am] RandyWalker: this would eliminate page as a content type
[04: 37am] RandyWalker: and instead "page" would be an option
[04: 38am] RandyWalker: so this gives you versatility in where you
want to put content
[04: 39am] RandyWalker: capite?
[04: 42am] RandyWalker: ;_; is anybody paying attention to me?
[04: 42am] iMassimiliano: RandyWalker: yes : P
[04: 42am] RandyWalker: iMassimiliano: opinion?
[04: 43am] iMassimiliano: none, really.
[04: 43am] RandyWalker: do you understand?
[04: 43am] iMassimiliano: yes, you are reverting (reversing?) the
process
[04: 44am] RandyWalker: er
[04: 44am] RandyWalker: huh?
[04: 44am] iMassimiliano: now, you first choose the place (entry or
page), then you fill it with content
[04: 44am] iMassimiliano: you are suggesting to create content first,
then to choose the place
[04: 45am] RandyWalker: well, kind of
[04: 45am] RandyWalker: right now, we have "entry" and "page" as
content types
[04: 45am] RandyWalker: they should be locations
[04: 45am] RandyWalker: where other content types (text, video, audio,
event, form, list, etc) can go
[04: 46am] iMassimiliano: you make me think that creating a "podcast"
content type is not a great idea
[04: 46am] iMassimiliano: because a podcast is also an entry
[04: 48am] RandyWalker: iMassimiliano: a "podcast" would just be a
collection of entries of the audio (or video) type
[04: 48am] RandyWalker: well
[04: 48am] RandyWalker: you would need an "episode" type because it
needs more info than regular audio content
[04: 56am] h0bbel|wrk: iMassimiliano: no, he's perverting the
process. Get used to it. ;-)
[04: 56am] dmondark: RandyWalker: it's a good idea IMO, you are
directing the main focus to the main content. Then its only a matter
of where to display it. This also means that you can easily change the
"type" of your content as you redesign and/or reorganize your blog
[04: 57am] RandyWalker: dmondark: yes.
[04: 57am] RandyWalker: w00t
[04: 59am] dmondark: indeed, this would appear more useful if you
consider having 5 more content types
[04: 59am] RandyWalker: yes!
[04: 59am] RandyWalker: dmondark is on board the train!
[04: 59am] dmondark: heh
[05: 00am] dmondark: Besides, its a non-conventional feature that you
cannot call odd
[05: 01am] dmondark: RandyWalker I am really in for this, are you
planning to post on -dev about it?
----------
Basically, we we merge our exising "entry" and "page" content types
into a "text" content type
And then each content type would have an option of into which Content
Place to put it:
-in the blog chronology
-as a separate page
-into another content area (sidebar, etc, similar to like WP widgets,
themes can have more than 1)
Want to write?
Choose a content Type
Add content
Choose a content Place
Publish
What do you all think?
--
Randy Walker
emai: randy....@mac.com
phone: 989.906.3626
AIM: randy....@mac.com
Gtalk/Jabber: randy....@gmail.com
Yahoo! (Windows Live/MSN) randywalker83 (@yahoo.com)
Scott Merrill
> Basically, we we merge our exising "entry" and "page" content types
> into a "text" content type
>
> And then each content type would have an option of into which Content
> Place to put it:
> -in the blog chronology
> -as a separate page
> -into another content area (sidebar, etc, similar to like WP widgets,
> themes can have more than 1)
>
> Want to write?
> Choose a content Type
> Add content
> Choose a content Place
> Publish
>
> What do you all think?
Why have content types at all? Why not just have a single "content"
container into which we store all the content?
To answer my own question: I think we want to have discrete content
types because logically they each represent something different, and
in theory one can do different things with them.
For example, you can currently get an Atom feed of entries. It ought
to be possible to get an Atom feed of pages. In your proposed
construct, how would someone obtain an Atom feed of entries? Or an
Atom feed of "aside" type elements?
Someone might want a specific post to be displayed in the blog
chronology while simultaneously adding it to the menu navigation.
With a single checkbox like you propose, that might be difficult.
ringmaster
> Basically, we we merge our exising "entry" and "page" content types
> into a "text" content type
>
> And then each content type would have an option of into which Content
> Place to put it:
> -in the blog chronology
> -as a separate page
> -into another content area (sidebar, etc, similar to like WP widgets,
> themes can have more than 1)
>
> Want to write?
> Choose a content Type
> Add content
> Choose a content Place
> Publish
>
> What do you all think?
types and how we choose to place them.
Different content types exist because they would presumably contain
different data. A Page wouldn't necessarily have comments, for
example. Likewise, a Podcast would have extra data that an Entry
wouldn't that pertains to the media being published.
Currently, placement is achieved by the theme. The theme selects a
set of posts, usually based on content type, and sends them to a
template for display.
Really, the only difference in this suggestion is that we provide an
additional criteria for each post that indicates where in the theme it
is to be published. This presents some difficulties.
First, not every theme will be geared to display output at every
potential place that is indicated in the post entry. If you write
posts that are destined for a "sidebar" area, and then you activate a
theme that has no "sidebar" area to display them in, what happens?
How free-form is the positioning field? If we let people enter
whatever they want, it'll be confusing when typos cause things not to
display.
Second, it is an additional control that would need to be primary on
the publish page, otherwise the content wouldn't display anywhere.
The process is really streamlined now, and I have negative feelings
about adding an additional control to that page.
Third, how does this affect feeds? Currently only Entries are output
in the feeds (or should be, anyway). Would we have to add another
field to determine if the post should be included in the feed? What
do we do with content types that don't present the required fields
(title, description, link, pubdate, etc) for a feed?
It sounds like I am against this idea, but I think that it merits
discussion. Output disposition could make using Habari as a CMS much
easier.
Being able to pre-define where content should appear or how to
categorize it for output seems like something that would make theming
better. Personally, I would attack this feature using tags, or to be
more grand about the change, converting the tag system to a taxonomy
(something I'm thinking we should really do soon anyway) and letting
themes select posts based on the location defined in the "location"
vocabulary of the taxonomy.
Owen
Randy Walker
>
>On Wed, Apr 9, 2008 at 5:11 AM, Randy Walker <randy....@mac.com> wrote:
>> Basically, we we merge our exising "entry" and "page" content types
>> into a "text" content type
>>
>> And then each content type would have an option of into which Content
>> Place to put it:
>
>container into which we store all the content?
>
>To answer my own question: I think we want to have discrete content
>types because logically they each represent something different, and
>in theory one can do different things with them.
>
>For example, you can currently get an Atom feed of entries. It ought
>to be possible to get an Atom feed of pages. In your proposed
>construct, how would someone obtain an Atom feed of entries? Or an
>Atom feed of "aside" type elements?
This sounds like a technical thing and I don't do technical. :) Seriously, though, I don't know how people get a feed of my entries. I would imagine it couldn't be too dissimilar to do pages instead?
>Someone might want a specific post to be displayed in the blog
>chronology while simultaneously adding it to the menu navigation.
>With a single checkbox like you propose, that might be difficult.
If we use checkboxes, I don't see why a person couldn't check more than one :) (Again, there might be a technical reason against this. I dunno.)
Randy Walker
>
>On Apr 9, 5:11 am, Randy Walker <randy.wal...@mac.com> wrote:
>
>> Basically, we we merge our exising "entry" and "page" content types
>> into a "text" content type
>>
>> And then each content type would have an option of into which Content
>> Place to put it:
>> -in the blog chronology
>> -as a separate page
>> -into another content area (sidebar, etc, similar to like WP widgets,
>> themes can have more than 1)
>
>types and how we choose to place them.
>
>Different content types exist because they would presumably contain
>different data. A Page wouldn't necessarily have comments, for
>example. Likewise, a Podcast would have extra data that an Entry
>wouldn't that pertains to the media being published.
>
>Currently, placement is achieved by the theme. The theme selects a
>set of posts, usually based on content type, and sends them to a
>template for display.
Placement would still be dependent on the theme. The theme author would designate 0 or more areas in the theme as Places for content.
>Really, the only difference in this suggestion is that we provide an
>additional criteria for each post that indicates where in the theme it
>is to be published. This presents some difficulties.
>
>First, not every theme will be geared to display output at every
>potential place that is indicated in the post entry. If you write
>posts that are destined for a "sidebar" area, and then you activate a
>theme that has no "sidebar" area to display them in, what happens?
>How free-form is the positioning field? If we let people enter
>whatever they want, it'll be confusing when typos cause things not to
>display.
There would obviously have to be some sort of fallback, perhaps hide all Content that is assigned to a Place that doesn't exist; or, each Content that would display in a Place that doesn't exist would be shown as a Page instead. (Two possibilities: hide stuff or show it all)
Second, I don't imagine options to be free-form; the active theme would have to be parsed for Places and then each Place in addition to the defaults would have a checkbox.
>Second, it is an additional control that would need to be primary on
>the publish page, otherwise the content wouldn't display anywhere.
>The process is really streamlined now, and I have negative feelings
>about adding an additional control to that page.
There's plenty of room for a second column of controls on the "Settings" tab. In fact, I think it looks a little lop-sided right now.
>Third, how does this affect feeds? Currently only Entries are output
>in the feeds (or should be, anyway). Would we have to add another
>field to determine if the post should be included in the feed? What
>do we do with content types that don't present the required fields
>(title, description, link, pubdate, etc) for a feed?
I would say still that only entries would show up in the feed or perhaps "feed" could be another Place.
>It sounds like I am against this idea, but I think that it merits
>discussion. Output disposition could make using Habari as a CMS much
>easier.
>
>Being able to pre-define where content should appear or how to
>categorize it for output seems like something that would make theming
>better. Personally, I would attack this feature using tags, or to be
>more grand about the change, converting the tag system to a taxonomy
>(something I'm thinking we should really do soon anyway) and letting
>themes select posts based on the location defined in the "location"
>vocabulary of the taxonomy.
This should probably be a separate thread but here's my two cents on this issue: I think our current tagging interface would have to change for this. A big open field where you just type everything seems very, very unfriendly and our "Tags" tab would have to be pre-populated with all the control-type tags so people who don't want to type everything or who don't know what they are could just click them, but I imagine that this list could get very long and we'd want to separate them out somehow, anyway. Having the list merely exist in Documentation would be unacceptable, in my opinion.
>Owen
Arthus Erea
other settings based upon content type.
However, I think positioning should be a plugin. It is not something
the average user would require and would complicate the publish page.
A plugin could:
- add a tab to publish page with "location"
- on that tab, list all locations which the theme has registered
(themes can register locations for wherever they display content)
- allow for multiple selection of different locations
- on an options page, allow defaults for each content type to be
chosen (entry defaults to "blog", page defaults to "page", link
defaults to "link")
Randy Walker
plugins but that the ability to define where something goes (defined
by the plugin/theme) should be core since, right now, it is, basically
(pages/entries).
~Randy
Matthijs
1. Content types: what can I store? Now this is entries and pages. And
images.
There's something to say for expanding those. Being able to add custom
fields or being able to upload media. But making it too flexible also
makes it harder to understand, when in 95% of the cases people will
just have "posts" and "pages".
However which way you do this, it should be independent of positioning
(as in the Model and View layer of the app)
2. Positioning: were to place your content?
For the positioning there are two models:
2.1. Push model.
You are able to decide were something goes on the publish page. I'm on
a post/entry/page and somehow a list of available templates or "places
to put content in" is shown and I can pick one or more.
2.2. Pull model.
The theme/template pulls the data from the system. I create a new
template and somewhere in that template pull all latest entries in
category X and tags Y, sorted by date. Or whatever.
I think it's difficult to combine them. Thinking in MVC terms, you
would create a 2-way direction: the Model now has knowledge about were
and how it goes in the View, and the View decides what to pull from
the Model and how it displays that data. I'm no expert programmer, but
I have a feeling that something like this combination is hard or
impossible to do. Or at least will be difficult and limiting. So then
you have to choose. And if I had to choose it would still be the Pull
model. You have some content in your system and you can pull it out in
all sorts of ways.
Arthus Erea
On Apr 16, 5:26 am, Matthijs <matthijsena...@gmail.com> wrote:
> 2.1. Push model.
> You are able to decide were something goes on the publish page. I'm on
> a post/entry/page and somehow a list of available templates or "places
> to put content in" is shown and I can pick one or more.
>
> 2.2. Pull model.
> The theme/template pulls the data from the system. I create a new
> template and somewhere in that template pull all latest entries in
> category X and tags Y, sorted by date. Or whatever.
easier for users to "drop in" new content types. If we build core
functionality for content types, then themes can take advantage of
this and support a plethora of unseen content types. Meanwhile, if we
use a pull model that will force users to manually edit their
templates just to include the content.
What's more, I am thinking we might want the ability to combine
multiple content types into a single template. That is, content types
of both "poll" and "entry" could appear in the index. I envision this
working through content templates being separated out from view
templates; every content type would have its own bare-bones template
(either defined in theme or plugin) which is used for the content
type. Then, when an index is loaded the appropriate posts are fetched,
with each one being displayed using the matching template.
Matthijs
a different one from the one about how to get data from the Model in
the View (from the db in the templates). The discussion about content
types is one solely dealing with what you have in your Model. Or how
you call it.
Then, how to get that out on your bog is another thing. I think the
Push model only works well if you have a fixed theme and fixed
templates. Because if you decide that the latest 10 entries in the
category Y should go in the sidebar of the Archives page, that
template should be there in the first place, including the right
template functions. As soon as you switch a theme things will break.
I think it's easier if you just have a bunch of entries in the db, and
using a few template functions pull those in your template wherever
you want.
Michael C. Harris
>
>
>
> On Apr 16, 5:26 am, Matthijs <matthijsena...@gmail.com> wrote:
> > 2.1. Push model.
> > You are able to decide were something goes on the publish page. I'm on
> > a post/entry/page and somehow a list of available templates or "places
> > to put content in" is shown and I can pick one or more.
> >
> > 2.2. Pull model.
> > The theme/template pulls the data from the system. I create a new
> > template and somewhere in that template pull all latest entries in
> > category X and tags Y, sorted by date. Or whatever.
>
> I would advocate for a push model, simply because it will make it much
> easier for users to "drop in" new content types. If we build core
> functionality for content types, then themes can take advantage of
> this and support a plethora of unseen content types. Meanwhile, if we
> use a pull model that will force users to manually edit their
> templates just to include the content.
That's not correct. Templates degrade, so you can have entry.single
and single, entry.multiple and multiple. As things stand, you can
support a plethora of unseen content types just as effectively by
providing single and multiple templates.
I believe a push model is actually placing extra cognitive load on a
user. Where do I want this? Much better to just be able to hit publish
and have the theme put it where it should go.
> What's more, I am thinking we might want the ability to combine
> multiple content types into a single template.
As above, that ability is already there with multiple. Connections
search shows both pages and entries (iirc).
> That is, content types of both "poll" and "entry" could appear in
> the index. I envision this working through content templates being
> separated out from view templates; every content type would have its
> own bare-bones template (either defined in theme or plugin) which is
> used for the content type. Then, when an index is loaded the
> appropriate posts are fetched, with each one being displayed using
> the matching template.
I fail to see how this is different to now. Maybe I just haven't had
enough caffeine.
--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog
Arthus Erea
> enough caffeine.
support the new content type. The way I envision it, when I install a
new plugin to provide the "poll" content type, it should be able to
define a template for use *within* the multiple section. Basically,
plugins should be able to define templates within templates.
rick c
the blogroll and creditdue plugins. Granted, you have to change your
theme to tell it where to output the template, but is a simple matter
of inserting a call, not copying the entire template into your theme.
In addition, if you want to change the template, you can do so and
copy the changed version into your theme directory. This seems
preferable to confusing data with its presentation.
Plugins can also add templates to themes. An example is the partytime
plugin. If I understand it correctly, no changes in your theme are
needed for these templates to display properly.
Rick
http://sagrising.cockrumpublishing.com
Arthus Erea
> Plugins can define templates to use for their output. Two examples are
> the blogroll and creditdue plugins. Granted, you have to change your
> theme to tell it where to output the template, but is a simple matter
> of inserting a call, not copying the entire template into your theme.
> In addition, if you want to change the template, you can do so and
> copy the changed version into your theme directory. This seems
> preferable to confusing data with its presentation.
content types which must be displayed in the feed? Yes... you *can*
get it work by inserting a switch, etc. - but isn't that mixing
business logic with presentation logic? The way I envision it, the
system would work almost exactly the way you describe, except there
would be core hooks for themes to select a particular template for
display of a content type.
> Plugins can also add templates to themes. An example is the partytime
> plugin. If I understand it correctly, no changes in your theme are
> needed for these templates to display properly.
it does so on its own pages (with a plugin defined template) What's
more, the content doesn't show up in the standard stream (no way to
access it), so it is relatively in accessible.
Really, I think this might be something which can be done just on the
theme level (using a particular template for each content type with
streams). I'll try pulling something together and post my results. If
it can be done, I recommend we offer it on the theme page of the wiki
and integrate that functionality into existing themes.
For anyone wondering how this whole templateable content type
situation started, we were checking out http://chyrp.net/ in IRC and
noticed that you can easily install new plugins to add content types.
When you do so, the content is displayed on the main index using the
appropriate template from the plugin. Ex, you can have a poll about an
entry simply by installing the poll and entry plugins (no mucking
around in themes required). If we can figure out how to do this, I
think it would be a valuable sell for people wanting to break away
from plain-text blogging (vodcasters, podcasters, photo blogs, etc.)
Michael C. Harris
Plugins can control how a content type is displayed. The plugin can
filter the post content. There's no need to modify the multiple
template.