Admin Facelift. Take 3

hakjoon · 2006-06-27 13:05:14

Ace,

Have you looked at jQuery ? There is a plugin for it that will do rounded corners and jQuery itself is awesome for DOM ajax stuff, and smaller then prototype.

They’ll be square without Javascript but that seems like fairly graceful degradation if you ask me. Let me know if I can help.

TheEric · 2006-06-27 15:14:33

A javascript library, so that the interface can be prettier?

… I’de consider that bloat.

Last edited by TheEric (2006-06-27 15:17:01)

rloaderro · 2006-06-27 16:07:06

Ace of Dubs wrote:

Sorry guys, looks like I will have to go MIA on this project for a while as I have quite a few deadlines to meet. All your input has been taken into consideration though and I think we can come up with a viable solution for all. The biggest challenge right now is writing the semantic markup for thes pages…its proven to be a greater challenge than I anticipated!

I think maybe before we concentrate too much on details of the code, some thought should be put into the admin section on a broader, usable / functional level – maybe with wireframes even. That might also help with standardizing naming conventions in the CSS – which would carry over into any Javascript too and would help with the development of admin-side plugins, etc..

Some good sites for starters:

Of course if someone doesn’t lead the charge then nothing will probably ever get done :)

hakjoon · 2006-06-27 17:35:58

TheEric wrote:

A javascript library, so that the interface can be prettier?

… I’de consider that bloat.

well it’s only bloat if you only use it to do rounded corners.

But if you use same said library for drop downs, html, preview tab switching, show/hide advanced options, addEvent, ajax and it just happens to also do nice effects then it’s hardly bloat. I also don’t see how it’s anymore bloat then images to accomplish the same effect. The JS library at least has other uses while a images for sliding doors accomplish just that. Plus it would allow for a consistent JS library for plugin developers to tap into.

I don’t see most people complaining about ROR’s tight integration with prototype as bloat. And prototype is 38k vs jQuery’s 10k. But I’m talking beyond just an admin facelift now.

rloaderro · 2006-06-27 18:35:07

hakjoon wrote:

I don’t see most people complaining about ROR’s tight integration with prototype as bloat. And prototype is 38k vs jQuery’s 10k. But I’m talking beyond just an admin facelift now.

I haven’t personally used jQuery, but I am very impressed with the Moo libraries. They use a lite version of Prototype that is about 3k and the basic effects library is the same size. A simple <2k AJAX extension and a brilliant <4k DOM extension. Oh, and to give you an idea of how it all might look in action, they even have their own CMS too (user/pass = demo/demo)…

akokskis · 2006-06-27 18:54:11

I think that the biggest hurdle with everything JS related is the fact that there are still people out there who browse without JS on, either knowingly or not, and to make the TXP interface completely JS integrated would be a bad idea as it would alienate those people from using TXP. I’m not saying that anyone’s proposing this, but I think you all get my point.

rloaderro · 2006-06-27 19:50:56

akokskis wrote:

I think that the biggest hurdle with everything JS related is the fact that there are still people out there who browse without JS on, either knowingly or not, and to make the TXP interface completely JS integrated would be a bad idea as it would alienate those people from using TXP. I’m not saying that anyone’s proposing this, but I think you all get my point.

It wouldn’t alienate anyone from browsing a Textpattern-based site. It would require however that those who administer a Textpattern site do so with javascript turned on (and with a relatively modern browser). I don’t think that’s asking too much: Javascript = free; Textpattern = free; Browsers = free. Of course Javascript can also be degraded gracefully (if done well) – things won’t look / move so nice, but will function. Anyway, I think it is a big point to miss that we are not proposing anything that would affect the browsing patterns of the general public (what you choose to implement on your TXP site is up to you of course) but what would affect the 1 or 2 administrators of a TXP site shouldn’t be given too much weight when we are talking about the greater good of the community and evolution of the software.

hakjoon · 2006-06-27 19:53:06

rloaderro: The Moo stuff is really, really nice, and oh so small. Prototype, Moo.fx or jQuery, are all great and make javascript fun. jQuery just had the rounded corners thing which is why I used that (plus I think it’s pretty cool since it can do xPath style DOM queries). That MooCMS seems to have some similar ideas like sections.

Ako: I agree but I think there is a difference between the public face of a site and the admin interface. Either way it should all degrade in a functional manner.

As a plugin developer I just like the idea of TXP having sort of a default JS library. So everyone doesn’t have to spin their own or consolidate how to have multiple plugins all using multiple versions of protoype, or moo.fx because they needed an ajax library or something.

I didn’t mean to hijack this thread to talk about JS libraries. I just thought it was a degradable solution for rounded corners without tons of images, that could also have other uses.

Ace of Dubs · 2006-07-06 16:47:35

Some interesting ideas here. While I will be the first to agree that we want to make things as accessible as possible, I don’t see the harm in a little javascript or any other behavior enhancement as long as it degrades gracefully. I haven’t heard about mooFX, thanks for sharing that as it looks like a solution for other projects I have in the works.

As far as progress is concerned, I am still putting together small chunks of CSS when time permits, but I think we need to organize this effort as I am not sure if a more semantic admin was already in store for TXP 4.1. Am I the only brave soul willing to dig under the hood and untangle the mess of wires?

jamiew · 2006-07-07 03:19:09

I’ve been doing some admin area hacking in the course of writing my dub_write quasi-custom-article-types plugin and have been religiously adding id’d div’s… would love to share my code once work subsides.

While definately crockery material I don’t think a semantic admin interface would break any plugin worth their salt. And it would make it so much easier to remove junk elements and add things w/ the DOM! And, god forbid, no more tables. I’d be happy to lend a helping hand.

Ace of Dubs · 2006-07-12 20:11:25

Totally agree, jamiew

I will be swamped for the next month or so, but I am actually excited to get this going. It’s also cool that I will be able to take on the admin interface from a better perspective. I must say that after a solid month of hardcore TXPing, it’s not just the look I want to change, but also extending the functionality of how the admin interface is presented, and the logical grouping of tools that work best together.

Perhaps the admin should be presented differently depending on who is logged in…

For example, I think it would be neat to have an admin for the clueless. This way my tech-challenged clients will have an easier time adding content. Here is a rough sketch (pardon the drab gray…just threw this together)

You may ask why I would even include Step 1…

That’s just wishful thinking on my part. A lot of people here agree, it would be pretty rad to assign custom-fields to categories/sections. This way the user is only presented with the relevant info instead of the usual clutter. In the above sketch, the client chooses the category/section and automatically gets the associated fields.

Also notice how there is no Override Form either. Indeed…I believe this is an advanced feature for webmasters, and I am not sure how, but it would make TXP life a lot easier if you could assign form overrides to categories on a conditional basis of who is logged in and what priviledges they have. A more advanced user could switch forms, but a client would automagically get his form override just because of who he is… in this case, a drooling moron. :)

Textpattern CMS

Textpattern CMS support forum

#97 2006-06-27 13:05:14

Re: Admin Facelift. Take 3

#98 2006-06-27 15:14:33

Re: Admin Facelift. Take 3

#99 2006-06-27 16:07:06

Re: Admin Facelift. Take 3

#100 2006-06-27 17:35:58

Re: Admin Facelift. Take 3

#101 2006-06-27 18:35:07

Re: Admin Facelift. Take 3

#102 2006-06-27 18:54:11

Re: Admin Facelift. Take 3

#103 2006-06-27 19:50:56

Re: Admin Facelift. Take 3

#104 2006-06-27 19:53:06

Re: Admin Facelift. Take 3

#105 2006-07-06 16:47:35

Re: Admin Facelift. Take 3

#106 2006-07-07 03:19:09

Re: Admin Facelift. Take 3

#107 2006-07-12 20:11:25

Re: Admin Facelift. Take 3

Board footer