Category/Section Structure
Eric
mean for Penny Press.
I personally think that sites should have simple page structures.
Newman thinks that deep hierarchies are the way to go.
What we thought of was a simple categorization system with a model
like so
Category:
title
slug
parent = Category
These are used for classification more than site layout.
Sections are more rigid. One story can have only one section on the
site.
We're not going to mimic Ellington's definition of a section as a
collection of categories. We don't think that stories should live in
multiple sections.
One example we had was a story such as. "High School football player
arrested for DUI", that's really a crime story but it's also related
to High School football. So which section should it live in?
Obviously the Crime section. Though fans of high school football will
want to see it as well, even though it's not directly related to high
school football.
The question really is how can we have a story in only one section but
still be included when it overflows into another section.
E.
Michael Newman
gives you the ability to create special categories and generate a feed
for the special section. So think of a newspaper that wants a very
specialized election coverage. Obviously there would be a /news/
election/ category, but then you can take it even further and create
a /news/election/candidate/obama and instantly they have an API to
organize all their election pages and section pages (see below).
I like Eric's layout for Category and I have something similar, which
I will upload as soon as I get a little time to clean it up for
generic sake. I think that each category can easily then create a feed
and provide an API to build other pages. Also I think that each
category should automatically create a archive so that if someone
wants to see all of the stories that were created inside the category
'/news/elections/' in 2008 they could go to '/news/elections/2008/'
and we can use Django pagination to provide simple pages.
I think that we should think of sections as glorified flatpages that
have a many to many relation to categories. They will work as the
minipages inside the main website. I think the pages should be served
before the category pages via middleware, so you can call a section
news, sports etc. and override the default category page. These
sections can also be the hook for the urls of the stories, so if a
story is in the section news the url for the story would be '/news/
2008/mar/31/slug' or '/sports/2008/mar/31/slug'. The section would
also be what determines what wrapper goes around the story, because a
generic wrapper is important.
If a section page overwrites a category we can still get to the
archives of that category by using the '?page=1' argument at the end,
which would match the pages that django pagination will provide to
us.
There should be a simple templatetag library that can easily pull
stories based on category, by number and by date. I think that we
should also build the site's API into the categories, where you can
hook into the site and pull stories down for free. I propose the url
structure for feeds and the api for '/news/election/' should be '/news/
election/rss' and '/news/election/api' with '/rss/' and '/api/' being
general site API and feeds.
Mn
Eric Moritz
i.e
class Story:
...
section = ForeignKey(Section)
...
Categories are used for categorization not display. We'll use those to relate stories together, but not in the direct path to the story. We need to reduce the number of paths and forks to a story to simplify the user-experience.
Speaking of simplification. Since Penny Press is going to be geared towards local news, do you think we should stop using /local/sports/ shouldn't it just be /sports/ and it'll be assumed to be local? What do you think? /local/sports/ seems to be way to specific for no good reason. That's just me.
E.
What I described was situation where a category had no direct representation on the site. I.E. the category /local/sports/ would not be the url /local/sports/. There can be a section called /local/sports/ that a story can be assigned to. Though this has nothing to do with categories.
i.e
class Story:
...
section = ForeignKey(Section)
...
Categories are used for categorization not display. We'll use those to relate stories together, but not in the direct path to the story. We need to reduce the number of paths and forks to a story to simplify the user-experience.
Speaking of simplification. Since Penny Press is going to be geared towards local news, do you think we should stop using /local/sports/ shouldn't it just be /sports/ and it'll be assumed to be local? What do you think? /local/sports/ seems to be way to specific for no good reason. That's just me.
E.
Michael
> What I described was situation where a category had no direct representation
> on the site. I.E. the category /local/sports/ would not be the url
> /local/sports/. There can be a section called /local/sports/ that a story
> can be assigned to. Though this has nothing to do with categories.
>
> i.e
>
> class Story:
> ...
> section = ForeignKey(Section)
> ...
I agree with you on how the sections should work. I think that makes
perfect sense.
>
> Categories are used for categorization not display. We'll use those to
> relate stories together, but not in the direct path to the story. We need
> to reduce the number of paths and forks to a story to simplify the
> user-experience.
I think that sections should be used to provide the direct path to the
story. I agree messing with the category beast for a structure in a
story url is too messy and doesn't really provide a good way to have
one story to be placed in multiple categories. I think that categories
and their structure lead to a very good method to have archives and
possible APIs to the site. The structure of categories works perfectly
with a url structure and could be provided for free with a few lines
of generic views.
I imagine a small paper that has news, sports and entertainment.
Obviously they would need to create news, sports and entertainment
sections for there site to look complete. I see news/politics being an
interesting category for readers, but not necessarily one that most
small newspapers could be able to create a page for and to maintain.
Django gives us generic archive views that can automatically make an
archive politics page without needing to create a section to go along
with it.
There is no need for there to be any links to these archive pages that
would confuse or fork the readership, but it could provide a valuable
resource to the reporter and if the paper so feels fit, they can link
to a deep category without needing to set up a section for it.
I don't see this as a main way to navigate the site. It's just
utilization of categorization to make things easier for free.
> Speaking of simplification. Since Penny Press is going to be geared towards
> local news, do you think we should stop using /local/sports/ shouldn't it
> just be /sports/ and it'll be assumed to be local? What do you think?
> /local/sports/ seems to be way to specific for no good reason. That's just
> me.
I think that this should be left up to the Penny Press users. Why tie
our hands now?
Mn
Eric Moritz
E.
Glenn Franxman
categories should not be used directly to drive display/breadcrumbs/urls
categories should work like tagging, but be disambiguated through hierarchy
articles should have a single home section
article urls should be relative to their home section
articles should inherit their look-n-feel from their home section
Things I don't agree with:
sections should not be defined by categories
sections should be flatpages
I think that there really should be emergent sections -- sections
driven by metadata.
I'm also not convinced that the section/date/slug style of url
building. I think I prefer section/section/slug/sequence where
sequence is just used to disambiguate articles with the same slug that
are in the same section. Consider: /sports/local/cubs-win/1/ which
might be the url for the first article where the cubs win the world
series. Years later, they do it again. THe paper chooses the same
slug ( possibly intentionally ). The system assigns the url
/sports/local/cubs-win/2/. THe cool think here is that you can drop
the sequence from the url, and get a mini-section of sports stories
slugged 'cubs-win'. This is especially useful for a lot of coverage
of court proceedings, columnists, etc where the slugs are always the
same, but the dates are not neccessarily predictable. If we are
convinced of the semantic value of the date in the url, then perhaps
the date should be used instead of the sequence. The point is to
group articles painlessly. And I've never wanted to browse a
newspaper site purely by date as it is in ellington.
Michael
giving the editor the ability to define the template, like in
flatpages, so they can fully customize a section, but maybe they can
get a section for free out of a generic template just by defining a
category.
I think sections won't be tied to a specific category, but instead
tied to stories that are placed inside of the section. This will allow
for a story to be in multiple categories and then have only one home
and section on the site. I think that I can be convinced otherwise on
this.
I really dislike the idea of the urls. I really think that if you want
special story pages like the one you just described you can accomplish
this by providing more in-depth categories, or by creating a section
page. Also when I surf the Web, I hate with a passion urls that make
absolutely no sense to me. When I look at /sports/local/cubs-win/2/
what does the 2 mean? I know you already explained this, but as a user
do I know what happens if I take the two off. What happens with 99% of
the stories that look like /sports/local/cubs-win/1/ what happens when
you take the 1 off? Does it provide an index of one story or does it
redirect you back to the /1/? This system will also take a level of
documentation to the editors in order for them to understand. And
there is no chance the end user will ever understand this schema.
On the other hand I see /section/2008/apr/2/cubs-win/ making sense in
that the slug matches the headline and each parent url provides an
archive of the index for the date, month year, section. It's logical.
Django is set up to easily handle this. The urls are clean for both
the end-user and the editor.
URL structures are one of the most important parts of a CMS to me. I
have seen what a good url structure can do to a newspaper site at
Athensnews.com and I have also seen how much users actually 'navigate
through url' by deleting parts of a url looking for archive pages. I
know I do it a lot and can only imagine it will happen a lot more as
good url structures are used more and more.
Eric Moritz
personally think that making the story url
/news/cubs-win-2008-world-series/ is fine. Needing the date to make
the story unique works in this case, but is it needed all the time?
Making the user remember the date the story occurred seems abusive.
I think duplicate story slugs shouldn't be allowed, the /1/ or /2/
thing seems silly. I'm assuming that's something that happens often
when importing content from publishing systems? Do pub systems not
make the slug unique?
The thing I think we need to stress when developing this system is to
try to not make the same mistakes that had to be made because we were
dependant on publishing systems. We should make the system conform
to good web practices and then make the other systems comform to penny
press. For instance, one of the goals of penny press is to have
import routines for NTIF. I think that the import routines should
conform the data to penny press, not have penny press conform to the
data.
What do you think?
E.
> > > OK, that sounds good to me. Glenn have you been following this?
>
> > > E.
>
>
> > > > On Mon, Mar 31, 2008 at 10:12 PM, Eric Moritz <e...@themoritzfamily.com>
>
> > > > > > > I see having categories that allow users to go as deep as possible
> > > > > > > gives you the ability to create special categories and generate a
> > > feed
> > > > > > > for the special section. So think of a newspaper that wants a very
> > > > > > > specialized election coverage. Obviously there would be a /news/
> > > > > > > election/ category, but then you can take it even further and create
> > > > > > > a /news/election/candidate/obama and instantly they have an API to
> > > > > > > organize all their election pages and section pages (see below).
>
> > > > > > > I like Eric's layout for Category and I have something similar,
> > > which
> > > > > > > I will upload as soon as I get a little time to clean it up for
> > > > > > > generic sake. I think that each category can easily then create a
> > > feed
> > > > > > > and provide an API to build other pages. Also I think that each
> > > > > > > category should automatically create a archive so that if someone
> > > > > > > wants to see all of the stories that were created inside the
> > > category
> > > > > > > '/news/elections/' in 2008 they could go to '/news/elections/2008/'
> > > > > > > and we can use Django pagination to provide simple pages.
>
> > > > > > > I think that we should think of sections as glorified
>
>
> read more »
Eric Moritz
be a field in the database or even /news/sections/
<section_slug>_details.html or something. Since the story is mapped
to a single section, it can use the template
<section_slug>_story_detail.html or something.
> > > OK, that sounds good to me. Glenn have you been following this?
>
> > > E.
>
>
> > > > On Mon, Mar 31, 2008 at 10:12 PM, Eric Moritz <e...@themoritzfamily.com>
>
> > > > > > > I see having categories that allow users to go as deep as possible
> > > > > > > gives you the ability to create special categories and generate a
> > > feed
> > > > > > > for the special section. So think of a newspaper that wants a very
> > > > > > > specialized election coverage. Obviously there would be a /news/
> > > > > > > election/ category, but then you can take it even further and create
> > > > > > > a /news/election/candidate/obama and instantly they have an API to
> > > > > > > organize all their election pages and section pages (see below).
>
> > > > > > > I like Eric's layout for Category and I have something similar,
> > > which
> > > > > > > I will upload as soon as I get a little time to clean it up for
> > > > > > > generic sake. I think that each category can easily then create a
> > > feed
> > > > > > > and provide an API to build other pages. Also I think that each
> > > > > > > category should automatically create a archive so that if someone
> > > > > > > wants to see all of the stories that were created inside the
> > > category
> > > > > > > '/news/elections/' in 2008 they could go to '/news/elections/2008/'
> > > > > > > and we can use Django pagination to provide simple pages.
>
> > > > > > > I think that we should think of sections as glorified
>
>
> read more »
Eric Moritz
any of them.
>
> read more »
Eric Moritz
> > OK, that sounds good to me. Glenn have you been following this?
>
> > E.
>
>
> > > On Mon, Mar 31, 2008 at 10:12 PM, Eric Moritz <e...@themoritzfamily.com>
>
> read more »
Glenn
as a result of the metadata attached to stories. Like using delicious
queries to create sections.
>
> read more »
Eric Moritz
The idea is basically like del.icio.us' idea of tag unions
So taking our example of "High School football player
arrested for DUI" the categories would be
"high-school", "sports", "crime", "football"
A user could then goto the url:
/news/high-school/sports/ and that would get them all the stories
used both the high-school and sports categories
The problem with that idea is we still need a hierarchies.
Example, the category "ford" could represent a ford dealership, or if
there's a "ford" county. Simply using "ford" wouldn't work.
The off the cuff solution would be to use :
so for instance:
/murder/dealership:ford/ would get you all the stories about murders
at ford dealerships
/murder/dealership/ would get you all the stories about murders at all
dealerships
Stories would still have their parent section that would allow custom
templates, etc but this would be an alternative way of creating lists
of stories.
E.
>
> read more »
Eric Moritz
Sites probably shouldn't be forced to use either method, if someone
wanted their site to look like del.icio.us and not use sections at
all, they should be able to.
If a site wanted to not use categories and only use sections, fine by
use.
If a site wanted a hybrid solution, they could as well.
>
> read more »
Glenn
probably use the date instead if that appeals to you.
What I'm interested in here is making sections dynamic and making the
url useful for traversing and grouping the articles with as little
work as possible.
I have never in my life found myself at a page like:
http://newspaper.com/news/2007/aug/14/business-closings/ and said to
my self 'lets see all of the other stories published on that
date'
I could theoretically see my self at a page like:
http://newspaper.com/business/closings/2007/aug/14/ and wonder to my
self if I could see all of the business closings, and merely chop off
as much of the date as I want. Essentially, I am treating every
slug like a mini section.
The reason most sites include the date in the url of a story is
because most newspapers allow slug reuse. Some papers re-use some
slugs as frequently as daily, but most I have worked at used
monthly. This helps them with their editorial budgeting. Now, you
could create a business section and a closings section, and come up
with a new slug for that column every day. But if you do, you'll
likely be putting the date into the slug. I'd argue that's even
worse.
> > > OK, that sounds good to me. Glenn have you been following this?
>
> > > E.
>
>
> > > > On Mon, Mar 31, 2008 at 10:12 PM, Eric Moritz <e...@themoritzfamily.com>
>
> > > > > > > I see having categories that allow users to go as deep as possible
> > > > > > > gives you the ability to create special categories and generate a
> > > feed
> > > > > > > for the special section. So think of a newspaper that wants a very
> > > > > > > specialized election coverage. Obviously there would be a /news/
> > > > > > > election/ category, but then you can take it even further and create
> > > > > > > a /news/election/candidate/obama and instantly they have an API to
> > > > > > > organize all their election pages and section pages (see below).
>
> > > > > > > I like Eric's layout for Category and I have something similar,
> > > which
> > > > > > > I will upload as soon as I get a little time to clean it up for
> > > > > > > generic sake. I think that each category can easily then create a
> > > feed
> > > > > > > and provide an API to build other pages. Also I think that each
> > > > > > > category should automatically create a archive so that if someone
> > > > > > > wants to see all of the stories that were created inside the
> > > category
> > > > > > > '/news/elections/' in 2008 they could go to '/news/elections/2008/'
> > > > > > > and we can use Django pagination to provide simple pages.
>
> > > > > > > I think that we should think of sections as glorified
>
>
> read more »
Eric Moritz
kidding.
I'm not completely against the date thing, but it still leaves a dirty
taste in my mouth. Could we do the sequence thing, but only when
necessary? I'm not sure how that would work.
For things like columns I think having the date as the slug isn't that
bad of an idea. The idea of a column is like a podcast where it's
episodic. Maybe we can come up with a better way of storing columns
than in sections?
E.
On Apr 2, 6:26 pm, Glenn <gfranx...@gmail.com> wrote:
> I'm completely open tided that categories are tags that can have a parent tag. How do we query this? o dropping the 'silly' sequence. We can/should
>
> What I'm interested in here is making sections dynamic and making the
> url useful for traversing and grouping the articles with as little
> work as possible.
>
> read more »
Eric Moritz
Should we restrict categories to only having one level of depth?
Do we really need:
cat1:cat2:cat3?
E.