Version 0.51
Khaled Abou Alfa
This way people can add as many additional services as they want and
it's not going to clutter up anything. You can browse from external
services while all coming from one location. I think it's a really neat
solution to handling all these elements.
Re Publish drop down
I'm not sure how we could do this and keep the button as is. I really
think that having the save button or the publish button or whatever as
simple and clear as possible, avoid confusion. Also I'm not sure how
we'd go about adding that function without modifying the button (as the
attach button), and this particular element should be kept untouched and
left for the OS to handle.
Also the delete button should be separate I think for complete clarity.
Re Post versus Page.
I'm a bit lost here. Why are we not allowing for the distinction between
a normal page and a post page? Surely these things are different?
Shouldn't there be a distinction?
The thing is though if we don't allow for that distinction then we'll
have to build it into the options somehow? So I've got my site, I post
things, it creates new pages and automatically puts them
under /archives, meanwhile I might want to have an about page, so I have
to create the about page (which will automatically go under
the /archives) and then move it to /home ?
Is that how we're thinking about dealing with it? Could I get some more
direction about this?
Scott Merrill
> Owen, I've shown what the drop down in the attachment could look like.
> This way people can add as many additional services as they want and
> it's not going to clutter up anything. You can browse from external
> services while all coming from one location. I think it's a really neat
> solution to handling all these elements.
Very slick.
> Re Post versus Page.
> I'm a bit lost here. Why are we not allowing for the distinction between
> a normal page and a post page? Surely these things are different?
> Shouldn't there be a distinction?
Why should there be a distinction? You're accustomed to a distinction,
because the tool(s) you currently use enforce a distinction. That is
arbitrary, and ultimately -- we feel -- unnecessary.
How often do you navigate a site -- any site -- by date? How often do
you visit http://somesite.com/2006/12/02/some-post and then trim off
some portion of the URL to see what else was posted that day / month / year?
I _never_ do that. Judging from my logs, visitors never do that on my
site, either. So, what value does the date in the URL provide to me or
my visitors?
So, assuming we remove dates from URLs, and just serve posts right from
the root of the site, what value is there to distinguish between Posts
and static Pages? In Habari, everything becomes a post _and_ a page.
Ask yourself this: aside from the URL distinction, what is the
difference between a post and a page on your site?
> The thing is though if we don't allow for that distinction then we'll
> have to build it into the options somehow? So I've got my site, I post
> things, it creates new pages and automatically puts them
> under /archives, meanwhile I might want to have an about page, so I have
> to create the about page (which will automatically go under
> the /archives) and then move it to /home ?
Incorrect.
It is (currently) a goal of Habari to have all posts available from the
root of the site. So, if you create an About page, and give it a title
of "About", Habari will make that page available at site.com/about
There is no /archives/ URL construct in Habari. Other blog tools use
this construct because they have no way to tell the difference between
"pages" and "posts". Because Habari removes the distinction, there's no
need for the URL construct.
--
ski...@skippy.net | http://skippy.net/
gpg --keyserver pgp.mit.edu --recv-keys 9CFA4B35
506C F8BB 17AE 8A05 0B49 3544 476A 7DEC 9CFA 4B35