As per #327, the media silos (and admin ajax in general) don't work if the json extension isn't installed. It is by default, but people do some wacky things.
Requiring JSON is just a matter of adding 'json' => 'http://php.net/json' to $required_extensions in the installhandler.
> As per #327, the media silos (and admin ajax in general) don't work if > the json extension isn't installed. It is by default, but people do > some wacky things.
> Requiring JSON is just a matter of adding 'json' => > 'http://php.net/json' to $required_extensions in the installhandler.
> Are there arguments against requiring it?
If we want the admin interface to degrade graceful for non-JS capable browsers, then I don't think we should require JSON.
On Wed, Jun 11, 2008 at 07:30:18AM -0400, Scott Merrill wrote:
> On Wed, Jun 11, 2008 at 3:23 AM, Michael C. Harris > <michael.twof...@gmail.com> wrote:
> > As per #327, the media silos (and admin ajax in general) don't work if > > the json extension isn't installed. It is by default, but people do > > some wacky things.
> > Requiring JSON is just a matter of adding 'json' => > > 'http://php.net/json' to $required_extensions in the installhandler.
> > Are there arguments against requiring it?
> If we want the admin interface to degrade graceful for non-JS capable > browsers, then I don't think we should require JSON.
Do we want that? I don't think we state that anywhere?
How will silos work if we don't have JS? There are also a number of pages in admin (tags, for example) that as they currently stand cannot degrade. Should our ultimate goal be complete degradability, given our cutting edge technology underpinnings? We are talking about the admin, so mandating a JS browser doesn't seem very different from mandating PHP 5.2.
On Jun 11, 7:30 am, "Scott Merrill" <ski...@skippy.net> wrote:
> If we want the admin interface to degrade graceful for non-JS capable
> browsers, then I don't think we should require JSON.
It's important to recognize this is not the client-side we're talking
about, it's the server. We already have high standards for the server
so I think it is reasonable to require another required extension. The
only reason we wouldn't do so is if we decided to abandon AJAX
entirely (which isn't happening anytime soon).
Michael C. Harris wrote: > How will silos work if we don't have JS? There are also a number of > pages in admin (tags, for example) that as they currently stand cannot > degrade. Should our ultimate goal be complete degradability, given our > cutting edge technology underpinnings? We are talking about the admin, > so mandating a JS browser doesn't seem very different from mandating > PHP 5.2.
Our cutting-edge underpinnings are for our hosting requirements, as a self-hosted option requires a level of knowledge that I think is compatible with requiring cutting edge installations on the host. The user can confirm what the host provide when they install. However the user cannot always control what browser will be used to access the admin. Mobile browsers, corporate environments, internet cafes... any of those could be used by even an advanced user, and not have JS functional. We need to keep that in mind. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
On Wed, Jun 11, 2008 at 8:45 AM, Arthus Erea <arthus.e...@gmail.com> wrote:
> On Jun 11, 7:30 am, "Scott Merrill" <ski...@skippy.net> wrote: > > If we want the admin interface to degrade graceful for non-JS capable > > browsers, then I don't think we should require JSON.
> It's important to recognize this is not the client-side we're talking > about, it's the server. We already have high standards for the server > so I think it is reasonable to require another required extension. The > only reason we wouldn't do so is if we decided to abandon AJAX > entirely (which isn't happening anytime soon).
> Michael C. Harris wrote: >> How will silos work if we don't have JS? There are also a number of >> pages in admin (tags, for example) that as they currently stand cannot >> degrade. Should our ultimate goal be complete degradability, given our >> cutting edge technology underpinnings? We are talking about the admin, >> so mandating a JS browser doesn't seem very different from mandating >> PHP 5.2.
> Our cutting-edge underpinnings are for our hosting requirements, as a > self-hosted option requires a level of knowledge that I think is > compatible with requiring cutting edge installations on the host. The > user can confirm what the host provide when they install. However the > user cannot always control what browser will be used to access the > admin. Mobile browsers, corporate environments, internet cafes... any of > those could be used by even an advanced user, and not have JS > functional. We need to keep that in mind.
I suppose requiring JSON isn't a big deal: chances are most users will use a fully capable desktop browser at least for installation and primary use of their site.
But as Sean points out, I would like to be able to perform _most_ admin functions from the Blazer browser on my Palm Centro. I don't expect I'll need to visit the /admin/tags page, but I'd like to post and manage content, as well as moderate comments.
On Wed, Jun 11, 2008 at 8:48 AM, Scott Merrill <ski...@skippy.net> wrote: > But as Sean points out, I would like to be able to perform _most_ > admin functions from the Blazer browser on my Palm Centro. I don't > expect I'll need to visit the /admin/tags page, but I'd like to post > and manage content, as well as moderate comments.
Maybe this would be a opportunity for a "Mobile-WG", to create an alternate non-JS based interface. As an example, GMail has an alternate html only interface for unsupported browsers, which allows you to do most of the admin tasks, without the funky ajaxy stuff. I see no prob with providing such an interface for Mobile, non-JS browsers.
I think people are clouding the issue with requirements on the client-
side: graceful degradation or alternate interface for clients without
JS is separate from the server. The only reason we wouldn't require
JSON (the PHP module) is if we decided to not use AJAX for *any*
clients. I don't think any of us want to do that, and we already have
some very strict requirements for the server so I wouldn't see the
harm in adding 1 more.
On Wed, Jun 11, 2008 at 05:45:25AM -0700, Arthus Erea wrote:
> On Jun 11, 7:30 am, "Scott Merrill" <ski...@skippy.net> wrote: > > If we want the admin interface to degrade graceful for non-JS capable > > browsers, then I don't think we should require JSON.
> It's important to recognize this is not the client-side we're talking > about, it's the server.
Granted there is more in the client-side discussion than just JSON. However, in the case of JSON, server-side and client-side can't really be separated. We use JSON to communicate with the client, and that client must be JS enabled.
> We already have high standards for the server so I think it is > reasonable to require another required extension. The only reason we > wouldn't do so is if we decided to abandon AJAX entirely (which > isn't happening anytime soon).
There seems to be a consensus that access to most of the admin should be possible without JS, at least for mobile devices.
I propose we include the JSON extension as a requirement. Additionally, we state that we will make every effort to have as much of the admin as possible degrade gracefully (we can do a lot better with the tags page, for example), but state that a JS-enabled browser is a requirement for the default admin.
Moving slightly OT, using the word 'default' though implies other possible admins. The obvious 'other' is a mobile admin, which seems to me to be essential, and I think the mobile WG to work through those issues is an excellent idea. But how far do we want that to go? Would it be harmful to offer a very simple JS-free admin as well?
On Jun 11, 7:53 pm, "Michael C. Harris" <michael.twof...@gmail.com>
wrote:
> Granted there is more in the client-side discussion than just JSON.
> However, in the case of JSON, server-side and client-side can't really
> be separated. We use JSON to communicate with the client, and that
> client must be JS enabled.
Not necessarily. If there's no JSON on the server-side, *no* clients
can use JSON. However, if some clients have JS and some don't we can
always have some request JSON and some not, but the server must still
be able to send JSON for the clients that want it.
> There seems to be a consensus that access to most of the admin should
> be possible without JS, at least for mobile devices.
I agree with this, and would go so far as to say most (all) of the
admin should be possible without JS or CSS.
> I propose we include the JSON extension as a requirement.
> Additionally, we state that we will make every effort to have as much
> of the admin as possible degrade gracefully (we can do a lot better
> with the tags page, for example), but state that a JS-enabled browser
> is a requirement for the default admin.
I support this, especially if we include a focus upon degrading
gracefully. Perhaps a compatibility working group should be formed,
with intention of working on degrading gracefully *and* making sure
the admin is compatible with browsers we select. (The WG would be
responsible for setting those standards.)
> Moving slightly OT, using the word 'default' though implies other
> possible admins. The obvious 'other' is a mobile admin, which seems to
> me to be essential, and I think the mobile WG to work through those
> issues is an excellent idea. But how far do we want that to go? Would
> it be harmful to offer a very simple JS-free admin as well?
I think there are two issues here: mobile admin and JS-free admin. I
firmly believe there shouldn't be a "JS-free" admin. Instead, we would
focus upon making sure everything still works in the default admin,
even without JS enabled. This would be for computers without JS
enabled. Thus, it would fall under the jurisdiction of the
compatibility WG.
A mobile admin is another issue, which I think deserves its own WG.
Fundamentally, the mobile experience should be different than that of
the default admin: when on our phones, we have very different purposes
from when on computers and the admin should reflect that.
OT, an idea was floated for an iPhone native app. I don't believe we
need this, since someone will probably develop a generic blogging app
which can hook into our APIs (and many other platforms'). If nobody
else ends up doing so, a WG could push it. Making an iPhone app would
generate good buzz for Habari.
On Wed, Jun 11, 2008 at 05:15:23PM -0700, Arthus Erea wrote:
> On Jun 11, 7:53 pm, "Michael C. Harris" wrote: > > Granted there is more in the client-side discussion than just JSON. > > However, in the case of JSON, server-side and client-side can't really > > be separated. We use JSON to communicate with the client, and that > > client must be JS enabled.
> Not necessarily. If there's no JSON on the server-side, *no* clients > can use JSON. However, if some clients have JS and some don't we can > always have some request JSON and some not, but the server must still > be able to send JSON for the clients that want it.
We're not talking about having JSON or not. We're talking about _requiring_ JSON or not. Should I not be able to install Habari if I know that I will always be using the JS-free mobile admin?
> > There seems to be a consensus that access to most of the admin should > > be possible without JS, at least for mobile devices.
> I agree with this, and would go so far as to say most (all) of the > admin should be possible without JS or CSS.
> > I propose we include the JSON extension as a requirement. > > Additionally, we state that we will make every effort to have as much > > of the admin as possible degrade gracefully (we can do a lot better > > with the tags page, for example), but state that a JS-enabled browser > > is a requirement for the default admin.
> I support this, especially if we include a focus upon degrading > gracefully. Perhaps a compatibility working group should be formed, > with intention of working on degrading gracefully *and* making sure > the admin is compatible with browsers we select. (The WG would be > responsible for setting those standards.)
Looks like we're taking on the WG idea in a big way :)
> > Moving slightly OT, using the word 'default' though implies other > > possible admins. The obvious 'other' is a mobile admin, which seems to > > me to be essential, and I think the mobile WG to work through those > > issues is an excellent idea. But how far do we want that to go? Would > > it be harmful to offer a very simple JS-free admin as well?
> I think there are two issues here: mobile admin and JS-free admin. I > firmly believe there shouldn't be a "JS-free" admin. Instead, we would > focus upon making sure everything still works in the default admin, > even without JS enabled. This would be for computers without JS > enabled. Thus, it would fall under the jurisdiction of the > compatibility WG.
Looks like I wasn't clear, but I was really talking about how we manage any kind of alternate admin. JS-free was just an example. But maybe the need is imaginary and we can just have one fully-degradable admin (and maybe a separate lightweight mobile-focussed one).
> I support this, especially if we include a focus upon degrading > gracefully.
I'll just state right up front, as unpopular as it might be to say, that it will be a long time before I support graceful degradation in Habari. For the core admin (and that's all I'm talking about) for now we should require javascript.
This is not saying that I think we should exclude UA-specific admin themes or work to eventually make the admin functional without javascript. I just mean to say that we should base our core on an A-grade user experience, not add js to a B-grade experience.
People should say that the admin works but sucks without the javascript, not that it works without the javascript and, oh by the way, it has some things in it that look neat when javascript is enabled. I think we're fairly clearly in that territory with the timeline already.
I agree with Owen here, and I think perhaps we should start writing some of these things down in a spec, which we can point to when this discussion comes up again (which it will, since it keeps popping up like a damn gopher).
We _will_ get a mobile non-JS admin. But it would be ludicrous to expect the current admin to degrade gracefully to the level where a basic phone is capable of using it. It wouldn't be practical in any way, shape or form. It's obviously a separate project, and I personally think it's something that can wait at least until well after .5, if not .6 and .7 :) -- But that's me.
Which reminds me: We need better roadmaps. The .5 roadmap is about as vague as can possibly be.
As for other admin themes, what would be good though, is if someone with some insight can elaborate on how easy it will be to create a 'theme' for phones or for the iPhone or PSP or whatever might be interesting. Is it as simple as doing a plugin or what? What's the structure and process for it?
On Thu, Jun 12, 2008 at 09:36:01AM +0200, Michael Heilemann wrote: > Which reminds me: We need better roadmaps. The .5 roadmap is about as > vague as can possibly be.
Vague in what way? An ACL system and podcast support. We probably should have included an admin upgrade. Those are the goals for 0.5, if we have them, it's time for 0.5.
We had much more in the roadmap for a while - now _that_ was vague.
On Thu, Jun 12, 2008 at 09:55, Michael C. Harris <michael.twof...@gmail.com> wrote:
Vague in what way? An ACL system and podcast support. We probably
> should have included an admin upgrade. Those are the goals for 0.5, > if we have them, it's time for 0.5.
Well, vague in the way that it doesn't specify what 'podcast support' contains. Is it as simple as detecting any links to .mp3/.mp4 files and making the feed work with that, or does it also mean a UI for handling time, author and rating data (and so on).
This information AFAIK exists only in the ephemeral space between the people who have talked about it (or you could try the wiki: http://wiki.habariproject.org/en/Special:Search?search=podcast), and so it's impossible for anyone to help implement this stuff, when that information isn't available. I don't even know where to look for any code might already exist...
Before I did Monolith, I got banged around a lot for the way I wanted to do the admin 'on my own', and someone, I forget who, told me that I should consider the fact that some people actually write documentation for their apps/features before implementing them. That way you know the path, you simply have to walk it.
And so I did that for Monolith, to the extend that it made sense and I had time. And it worked. And I suggest we do the same for roadmap features.
> On Wed, Jun 11, 2008 at 05:15:23PM -0700, Arthus Erea wrote:
> > On Jun 11, 7:53 pm, "Michael C. Harris" wrote: > > > Granted there is more in the client-side discussion than just JSON. > > > However, in the case of JSON, server-side and client-side can't really > > > be separated. We use JSON to communicate with the client, and that > > > client must be JS enabled.
> > Not necessarily. If there's no JSON on the server-side, *no* clients > > can use JSON. However, if some clients have JS and some don't we can > > always have some request JSON and some not, but the server must still > > be able to send JSON for the clients that want it.
> We're not talking about having JSON or not. We're talking about > _requiring_ JSON or not. Should I not be able to install Habari if I > know that I will always be using the JS-free mobile admin?
> > > There seems to be a consensus that access to most of the admin should > > > be possible without JS, at least for mobile devices.
> > I agree with this, and would go so far as to say most (all) of the > > admin should be possible without JS or CSS.
> > > I propose we include the JSON extension as a requirement. > > > Additionally, we state that we will make every effort to have as much > > > of the admin as possible degrade gracefully (we can do a lot better > > > with the tags page, for example), but state that a JS-enabled browser > > > is a requirement for the default admin.
> > I support this, especially if we include a focus upon degrading > > gracefully. Perhaps a compatibility working group should be formed, > > with intention of working on degrading gracefully *and* making sure > > the admin is compatible with browsers we select. (The WG would be > > responsible for setting those standards.)
> Looks like we're taking on the WG idea in a big way :)
> > > Moving slightly OT, using the word 'default' though implies other > > > possible admins. The obvious 'other' is a mobile admin, which seems to > > > me to be essential, and I think the mobile WG to work through those > > > issues is an excellent idea. But how far do we want that to go? Would > > > it be harmful to offer a very simple JS-free admin as well?
> > I think there are two issues here: mobile admin and JS-free admin. I > > firmly believe there shouldn't be a "JS-free" admin. Instead, we would > > focus upon making sure everything still works in the default admin, > > even without JS enabled. This would be for computers without JS > > enabled. Thus, it would fall under the jurisdiction of the > > compatibility WG.
> Looks like I wasn't clear, but I was really talking about how we > manage any kind of alternate admin. JS-free was just an example. But > maybe the need is imaginary and we can just have one fully-degradable > admin (and maybe a separate lightweight mobile-focussed one).
On Wed, Jun 11, 2008 at 9:16 PM, Owen Winkler <epit...@gmail.com> wrote:
> Arthus Erea wrote:
> > I support this, especially if we include a focus upon degrading > > gracefully.
> I'll just state right up front, as unpopular as it might be to say, that > it will be a long time before I support graceful degradation in Habari. > For the core admin (and that's all I'm talking about) for now we > should require javascript.
> This is not saying that I think we should exclude UA-specific admin > themes or work to eventually make the admin functional without > javascript. I just mean to say that we should base our core on an > A-grade user experience, not add js to a B-grade experience.
> People should say that the admin works but sucks without the javascript, > not that it works without the javascript and, oh by the way, it has some > things in it that look neat when javascript is enabled. I think we're > fairly clearly in that territory with the timeline already.
On Jun 11, 9:16 pm, Owen Winkler <epit...@gmail.com> wrote:
> I'll just state right up front, as unpopular as it might be to say, that
> it will be a long time before I support graceful degradation in Habari.
> For the core admin (and that's all I'm talking about) for now we
> should require javascript.
I am not in any way saying we should offer a B-grade experience.
Degrading need not be that way at all..
For the most part, I think it is fine for us to ignore the graceful
degradation when designing the admin: explore ideas, make the best
admin possible.
The degrading support can be added later. There is absolutely no
reason that the JS-enabled version should suffer due to the support
for no-JS.
> On Wed, Jun 11, 2008 at 02:32:01PM +0200, Michael Heilemann wrote:
> > On Wed, Jun 11, 2008 at 14:30, Michael C. Harris wrote:
> > We've talked about it before, and no one has ever had a problem with
> > requiring JS before, so...
> We might have talked about it but I don't think we've documented it.
On Thu, Jun 12, 2008 at 10:50:12AM +0200, Michael Heilemann wrote: > On Thu, Jun 12, 2008 at 09:55, Michael C. Harris wrote:
> > Vague in what way? An ACL system and podcast support. We probably > > should have included an admin upgrade. Those are the goals for 0.5, > > if we have them, it's time for 0.5.
> Well, vague in the way that it doesn't specify what 'podcast support' > contains. Is it as simple as detecting any links to .mp3/.mp4 files and > making the feed work with that, or does it also mean a UI for handling > time, author and rating data (and so on). > This information AFAIK exists only in the ephemeral space between the > people who have talked about it (or you could try the wiki: > [2]http://wiki.habariproject.org/en/Special:Search?search=podcast), and > so it's impossible for anyone to help implement this stuff, when that > information isn't available. I don't even know where to look for any > code might already exist...
I'm not saying that our roadmaps can't be improved, but they're not the place for these sorts of things. The specifics are in trac as tickets. If someone wants to help with podcasting, asking here or on IRC how to get involved will get you pointed to the appropriate places (for example, ticket #9, the podcast and RSS plugins, FormUI for adding enclosure data etc).
> Before I did Monolith, I got banged around a lot for the way I wanted > to do the admin 'on my own', and someone, I forget who, told me that I > should consider the fact that some people actually write documentation > for their apps/features before implementing them. That way you know the > path, you simply have to walk it. > And so I did that for Monolith, to the extend that it made sense and I > had time. And it worked. And I suggest we do the same for roadmap > features.
But no-one asked you to put Monolith documentation in a roadmap.
On Thu, Jun 12, 2008 at 12:06:13PM -0700, jaypipes wrote: > On Jun 11, 7:36 pm, "Michael C. Harris" wrote: > > On Wed, Jun 11, 2008 at 02:32:01PM +0200, Michael Heilemann wrote: > > > On Wed, Jun 11, 2008 at 14:30, Michael C. Harris wrote: > > > We've talked about it before, and no one has ever had a problem with > > > requiring JS before, so...
> > We might have talked about it but I don't think we've documented it.
> On Thu, Jun 12, 2008 at 09:55, Michael C. Harris <michael.twof...@gmail.com>
> wrote:
> Vague in what way? An ACL system and podcast support. We probably
> > should have included an admin upgrade. Those are the goals for 0.5,
> > if we have them, it's time for 0.5.
> Well, vague in the way that it doesn't specify what 'podcast support'
> contains. Is it as simple as detecting any links to .mp3/.mp4 files and
> making the feed work with that, or does it also mean a UI for handling time,
> author and rating data (and so on).
> This information AFAIK exists only in the ephemeral space between the people
> who have talked about it (or you could try the wiki:http://wiki.habariproject.org/en/Special:Search?search=podcast), and so it's
> impossible for anyone to help implement this stuff, when that information
> isn't available. I don't even know where to look for any code might already
> exist...
> Before I did Monolith, I got banged around a lot for the way I wanted to do
> the admin 'on my own', and someone, I forget who, told me that I should
> consider the fact that some people actually write documentation for their
> apps/features before implementing them. That way you know the path, you
> simply have to walk it.
> And so I did that for Monolith, to the extend that it made sense and I had
> time. And it worked. And I suggest we do the same for roadmap features.
I don't really see a correlation. Adding podcast support, in what ever
fashion, is not the on the same level of change as a complete UI
overhaul to admin, and isn't something being done by someone who asks
to formulate it outside the previously accepted manner of "by
committee".
As far as it not being in the wiki, that certainly could be improved,
however I don't know that we've ever explicitly said the wiki is where
that information should reside. As as I understand it, this mailing
list is for those discussions, and publicly archived for future
reference. I know I've seen at least one recent discussion about what
podcasting support might mean initially (http://pastoid.com/v8+).
Anyway, to the more germane question about JS and degradation, can,
for the love of all that is holy, development be focused on getting
the JS fully working on all of the pages before tackling that step.
If that means being able to release a .5, fine.
Whether it was a conscious community decision to use this much JS in
admin, is, at this point, moot. Too much hard work has gone into it
to turn back, there _was_ a general consensus to adopt monolith, which
obviously relied on JS to accomplish the new features, so if nothing
else, it was an unspoken acceptance, and can be dealt with in the next
round of development.
