Roadmap 0.3
Owen Winkler
we should be ready for our next release by October 15th, at latest.
Line items to potential completion of 0.3:
* Completed ACL class, including management interface.
* Permissions implemented throughout.
* Initial core media management classes.
* Pingbacks.
* Enable Ajax in installer, with installation error messages.
* Additional manual entries and TiddlyWiki styling.
* Basic developer docs.
* Move core rewrite rules out of the database.
Perhaps for later milestones:
* Admin interface refurb.
* Initial core media plugins.
* "3rd Post Type" as described in a prior thread.
* SQLite dbdelta.
* Complete developer docs.
What is missing from these lists? Please add. Is this too ambitious?
Note items for pushing back.
Should we maybe make a wiki milestone page?
I would like to aim to release 1.0 early in 2008. My current highest
risk factor for not meeting that goal is the admin design refurb.
What say you all?
Owen
Andrew da Silva
- Plugin hooks (add more, especially in the admin)
- Review the scope/visibility of methods/functions in core classes.
- Add more methods/functions to power the plugin devs ;)
As we move closer to 1.0, the plugins will be vital to a complete blog, so we should make sure everything is in place to have, as suggested in an early thread, the top 20 plugins for Wordpress ported to Habari.
The list you made seems reasonable, pingbacks are mostly done, only problem I am having is the InputFilter that does not seem to work properly (for the code I have), so I'll open an issue later..
Good work ;)
Scott Merrill
> Line items to potential completion of 0.3:
* Log viewer, complete with controls to sort and search log entries.
* Support authentication plugins
> * Move core rewrite rules out of the database.
What do you mean by this?
> Perhaps for later milestones:
> * Admin interface refurb.
Let's make this a little more specific.
* Support filtering on content listings
* Paginate content listings
* Support filtering on comment listings
* Paginate comment listings
* Paginate user listings (might as well be prepared)
> * Complete developer docs.
This will be an on-going item, and will always need to be updated with
each new release in order to document new functionality, problems fixed,
and changes in underlying logic.
--
GPG 9CFA4B35 | ski...@skippy.net | http://skippy.net/
khaled Abou Alfa
As a hint, it plays on the idea of 'Hi!' and then 'Habari' which I've always really liked.
Regarding the plugins and the themes, shouldn't we be concentrating on the systems that integrate with habariproject to update the user as to whether or not there's been an update to that particular plugin/theme etc? You know, laying the groundwork?
Owen Winkler
>
> What do you mean by this?
The rewrite rules in the database have been nothing but a bother. As
we add new required features, we have no way to add them to the
rewrite table. Every plugin so far that interacts with the URL has
added its rewrite rules directly rather than inserting them into the
database. Relying on the rules in the database just complicates
things.
If we make the core do what plugins have been doing, and provide an
easy way to override specific rules (even for use with plugins that
insert their rules), then I think we'll end up with a better system.
Also while we're at it, let's consider being rid of the themes table.
> > Perhaps for later milestones:
> > * Admin interface refurb.
>
> Let's make this a little more specific.
> * Support filtering on content listings
> * Paginate content listings
> * Support filtering on comment listings
> * Paginate comment listings
> * Paginate user listings (might as well be prepared)
This also needs to include a design. The consistency between pages in
the current admin is unimpressive. I like that people think our admin
is "simple", but a word I would prefer our interface to imply is
"nice".
Owen
khaled Abou Alfa
The admin interface is far far from over, hell in my mind, the work on that hasn't even begun yet. By version 1.0 I wouldn't be happy if people imply our interface is simply nice. In my mind that would be a failure on the design team's efforts. No, it's got to be functional, intuitive and beautiful, all contributing to the final element which is that it should be fun to use. That is our aim and I'm confident we'll achieve it :)
Owen Winkler
> Owen,
>
> The admin interface is far far from over, hell in my mind, the work on that
> hasn't even begun yet. By version 1.0 I wouldn't be happy if people imply
> our interface is simply nice. In my mind that would be a failure on the
> design team's efforts. No, it's got to be functional, intuitive and
> beautiful, all contributing to the final element which is that it should be
> fun to use. That is our aim and I'm confident we'll achieve it :)
From American Heritage dictionary:
Nice (nīs)
...
6. Showing or requiring great precision or sensitive discernment;
subtle: a nice distinction; a nice sense of style.
7. Done with delicacy and skill: a nice bit of craft.
Owen
Root
doing what.
Khaled is doing great work in every respect in this regard. Are you
coding it Khaled as well?
Is there any incremental coding that can be done now?
My question is really about layers of abstraction:
Functionality:
This is really a primary dev issue.
UI:
This is a useability / coding / accessibility issue:
Style:
Style is just that. A style laid on top of a and b.
For some time I have had the feeling that these three items have been
conflated.
I would like to help out in admin but I do not want to cross over
anyone elses lines.
I myself do not see refurb of admin as something that needs to be
milestoned for one release or another.
It could be ongoing. Plus it will need to evolve as extra
functionality comes on stream. I would like to see any faux entries
like notional numbers of links removed until they are really ready.
Sketches and mockups can go elsewhere.
On Aug 12, 10:35 pm, "Owen Winkler" <epit...@gmail.com> wrote:
khaled Abou Alfa
Once I've got apache playing nice with Habari on windows then I should be able to hammer this out for the next release, since I've been playing with it for the past week or so and really find it incredibly easy and intuitive to use.
chrisjdavis
post. While I agree that the admin redesign needs to be ongoing, for
all the reasons you offered up, it does still need to be milestoned so
we can have something to work toward. I see the admin area as a soft
milestone for that reason.
I am looking forward to seeing what you have Khaled. And as always I
can help with the coding if/when you need it. I really would like to
see some of your stuff come across the lists as soon as you can!
Chris
On Aug 13, 7:26 am, "khaled Abou Alfa" <brokenk...@gmail.com> wrote:
> Never had anyone quote the American Heritage Dictionary before lol :). Hell
> I didn't even know that one existed :). In anycase, the plan is that yeah I
> would get my hands dirty with the coding, but I'm really keen on using the
> blueprint framework because it really does make my life seriously easy with
> respect to putting things where they should be placed and allowing us to
> concentrate on styling aspects, functional aspects and implementing grand
> ideas :).
>
> Once I've got apache playing nice with Habari on windows then I should be
> able to hammer this out for the next release, since I've been playing with
> it for the past week or so and really find it incredibly easy and intuitive
> to use.
>
Root
On Aug 13, 1:59 pm, chrisjdavis <chrisdmi...@gmail.com> wrote:
> Welcome back to the list Root, been awhile since I have seen you
> post. While I agree that the admin redesign needs to be ongoing, for
> all the reasons you offered up, it does still need to be milestoned so
> we can have something to work toward. I see the admin area as a soft
> milestone for that reason.
>
The thing that concerns me a bit is that the CSS Blueprint states
itself that it works in *Firefox*.
Chris J. Davis
back to another project. Our work implementing Blueprint in Habari
should be sent back to the project to make it that much better.
Chris
Root
Scott Merrill
> Is this agreed then? We are going ahead with the Blueprint?
I think it's safe to say that we all agree that Khaled is free to
present to us his proposals / beta implementations using Blueprint; and
we as the developer community will discuss those submissions in turn.
In the same way that we encourage experimentation / fringe development
in the code, so too should we permit some amount of freewheeling in the
design side of the house. That does not mean that the results of such
freewheeling will necessarily be adopted for inclusion.
Chris J. Davis
but there hasn't been any formal vote as far as I know.
Chris
Root
browsers.? I propose something on the Yahoo model.
So: My ideal admin panel will give a Class A user experience in IE6,
IE 7, and FF 2.0, Opera 9, without Javascript enabled.
How does anyone feel about that?
Chris J. Davis
need to have the discussion of js support. Some people in our
community are firmly on the side of not requiring JS for
funcionality, while others are more of the "we require high levels of
technology for our server side, we should for the client side as
well" camp.
We need to have this discussion and come to a consensus, as well as
talk about what browsers we support and to what experience grade.
Chris
khaled Abou Alfa
Seriously, let me get somethings out of my hair at the moment and I'll be chucking some code round everyone's way to test out all the browsers Root listed. Oh and definitely bring in Safari into this as well.
As for Javascript, well I've got to say that probably, what 90% of people using Habari will have js enabled without them even KNOWING about it. Sure there will be the odd number that don't have it, so we should make sure it degrades nicely. The only MAJOR issue I can think of where this could be a problem is in mobile browsers that don't have JS enabled. This would be a huge faux pas on our parts if we didn't think of the mobile technologies in our 1.0 release. We should have a stylesheet ready and the systems ready so that you can update easily from a mobile device, which is where the JS question becomes more important.
Sean T Evans
requiring... er... taking advantage of... the latest options on the
server side, I feel that requiring them on the client side is a bad
decision. I think we should make functionality as widely accessable as
possible. Many of us write blogs that are read by people who are not as
far down the technology road as others (my grandmother reads mine, and
I'm pretty sure she's still got a WebTV). We need to think long and hard
before we require something that may break Habari for a lot of people.
For the same reason, I think testing in Safari and Konqueror is
important as well.
--
Sean
Chris J. Davis wrote:
> I feel like Safari is left out, and I am not a fan of that. We also
> need to have the discussion of js support. Some people in our
> community are firmly on the side of not requiring JS for
> funcionality, while others are more of the "we require high levels of
> technology for our server side, we should for the client side as
> well" camp.
>
> We need to have this discussion and come to a consensus, as well as
> talk about what browsers we support and to what experience grade.
>
> Chris
>
<SNIP>
Owen Winkler
>
> To spin off this thread... I feel that while it's great that we're
> requiring... er... taking advantage of... the latest options on the
> server side, I feel that requiring them on the client side is a bad
> decision. I think we should make functionality as widely accessable as
> possible. Many of us write blogs that are read by people who are not as
> far down the technology road as others (my grandmother reads mine, and
> I'm pretty sure she's still got a WebTV). We need to think long and hard
> before we require something that may break Habari for a lot of people.
> For the same reason, I think testing in Safari and Konqueror is
> important as well.
I think that Root's idea to use something like the Yahoo compatibility
grades is a good one.
Regarding what level of support we give to browsers, I agree that we
should optimize for reading by anyone, but wouldn't scoff at some
additional requirements for browsers that are going to do content
creation.
I think that the ability to use Habari from a mobile browser is a good
idea, primarily because I have one and wouldn't mind using it. But
maybe that's just me.
Owen
Root
of issues that need to be thrashed out
and eventually embedded in community values and hopefuly formalised
into a statement. That way any serious coding of the admin UI can be
benchmarked against a defined standard. My proposal has of course
triggered two weighty questions. Whether JS should be needed by
default to access admin. And whether we support Safari and if so on on
what platforms and versions. I would just courteously invite Safari
users to consider the implications. Other than the fact they use it -
what does it mean to Habari to support any rogue browser?
Root
Just reviewing the <a href="http://developer.yahoo.com/yui/articles/
gbs/#gbschart">Yahoo Browser Grid</a> they support Safari 2.0 for Mac
10.4.
I don't really know what the Mac 10.4 qualification means in terms of
metrics, stats of users etc. The Mac community can no doubt advise. :)
I am beginning to think we could just adopt their grid for browsers /
OS wholesale as is.
JS is a different issue.
drac
> JS is a different issue.
http://docs.jquery.com/Browser_Compatibility
In summary:
* Firefox 1.5+
* Internet Explorer 6+
* Safari 2+
* Opera 9+
too high? too low? I'd like to see IE 7 onwards instead of IE 6, but
that's probably unreasonable.
Geoffrey Sneddon
Steve Jobs claimed (during the WWDC 2007 Keynote) that 2/3rds of OS X
users were running OS 10.4. It is likely there will be similar
adoption rates for 10.5 when it comes out in October.
- Geoffrey Sneddon
Geoffrey Sneddon
On 14 Aug 2007, at 11:06, Geoffrey Sneddon wrote:
>
> On 14 Aug 2007, at 10:14, Root wrote:
>
>>
>> On Aug 14, 7:13 am, Root <atthe...@gmail.com> wrote:
>>
>>
>> Just reviewing the <a href="http://developer.yahoo.com/yui/articles/
>> gbs/#gbschart">Yahoo Browser Grid</a> they support Safari 2.0 for Mac
>> 10.4.
>>
>> I don't really know what the Mac 10.4 qualification means in terms of
>> metrics, stats of users etc. The Mac community can no doubt
>> advise. :)
>>
>> I am beginning to think we could just adopt their grid for browsers /
>> OS wholesale as is.
>> JS is a different issue.
>
> Steve Jobs claimed (during the WWDC 2007 Keynote) that 2/3rds of OS
> X users were running OS 10.4
Also, it's worth noting that after Leopard comes out in October,
anything older will be unsupported.
- Geoffrey Sneddon
Michael Bishop
would be nice. A simple function for listing all tags, perhaps by
count, as well as a tag cloud I think would be a "nice" feature for
end users, and something I think they'd like to see sooner than later,
especially considering tagging is such an integral part of Habari.
~miklb
Root
license.
Scott Merrill
> Let's all make a new thread for a 0.3/0.4 roadmap, shall we? I think
> we should be ready for our next release by October 15th, at latest.
I advocate for a 0.3 alpha release before the end of September, so that
we have something with a little more substance to display at the Ohio
LinuxFest.
> Should we maybe make a wiki milestone page?
http://wiki.habariproject.org/en/Roadmap