[2.0] Restructuring the backend

[yellowled]

Currently, the S9y backend is a pain in the ass to style. I'm sorry, but that's just the way it is. The backend still uses tables (and lots of them!) for layout purposes, (i)frames, and most of it is not even smartified. I'm not saying we need to smartify all of it, but it would be nice to have a more accessible backend, and by accessible I mean for disabled people as well as for designers.

The way it is structured now, it is really hard to create nice admin themes, and as nice as Don's current admin theme is, I think our users would really appreciate it if they could choose from more than one or two backend themes. In order to make it easier to create admin themes, most of the stuff we're already discussing should be applied here: drop inline CSS and JS whenever it makes sense, make use of jQuery etc. I'm not saying we need an ajaxified backend -- I've seen something like that in MODx, and it can get pretty cumbersome in browsers with a slow JS engine (read: Firefox compared to Chrome).

Much like the in frontend, the backend is also not only the part created by the core, but also those pieces created by plugins or their configuration. There's a number of plugins which style their own configuration, which I think they shouldn't, at least not too much. Some layout styles here and there, okay, but the basic styling of the backend, including the plugin config, should be left to the admin theme. So there's probably some work to be done in the plugin section here as well. Sorry, folks.

YL

[Don Chambers]

I once mentioned the possibility of allowing users to select a backend theme, in addition to their front end theme. I would like to see that as an option moving forward... unless, we come up with a really kick @$$ back end design that everyone should be using. Mine is very graphical, reflecting my mood at that time. I like a lot of stuff I have seen from Yellowled, and will be more than happy to help to merge our different concepts together, or build on the concept that an admin can select from available admin designs.

What will be very difficult here is that the core emits most of the structured HTML. We went through this with bulletproof.

[onli]

What will be very difficult here is that the core emits most of the structured HTML. We went through this with bulletproof.

I once tried to rewrite the "comments"-section to not use tables anymore and it really was a mess. Of course, i had to patch the core, it was work to be done in the core.
So maybe it is a sound plan to smartify everything to have the option for real different admin-backends.

[yellowled]

So maybe it is a sound plan to smartify everything to have the option for real different admin-backends.

I sense a potential performance issue being mentioned very soon in this thread. We once talked about "smartifying it all" for the frontend and dropped that very quickly because of that.

At the very basic level, I don't even think it needs to be smartified. It just needs to be rewritten to emit sensible code following the basic rules we should apply to anything in the future: use as few inline CSS and JS as possible, use up-to-date semanctically correct HTML etc. Also, a lot of the backend code could use proper ids and classes to make it easier to style and access via JS.

YL

[garvinhicking]

Hi!

Not having Smarty in the backend is actually not due to performance. We could work around that. The real reason is that if we put core features in templates, we will never be able to properly update the core with new elements, because once people write backend templates, all the output would be part of the template, and we'd have a maintaineance nightmare...

I really hope that the backend could simply be "cleaned up" by default and not to outsource it as templates...

Regards,
Garvin

[Don Chambers]

The real reason is that if we put core features in templates, we will never be able to properly update the core with new elements, because once people write backend templates, all the output would be part of the template, and we'd have a maintaineance nightmare...

I really hope that the backend could simply be "cleaned up" by default and not to outsource it as templates...

Regards,
Garvin

... which is exactly what I ran into when I did the bulletproof admin template. I added a ton of classes and IDs, most of which I never really used, but then decided to only provide an admin stylesheet (not a smarty template) due to the potential maintenance nightmare Garvin mentions above.

[yellowled]

Is there an easy way to get or export a "scaffolding" of the backend in HTML/CSS/JS only so Don and I can dig through it and maybe provide a modernized prototype without having to smartify it or us having to dig through all the PHP we don't understand?

YL

[garvinhicking]

Hi!

hm, not really. I'd start with the browser HTML output and work from there manually.

Regards,
Garvin

[Don Chambers]

Something else to keep in mind is that the admin template, unfortunately, will probably continue needing to be elastic. This was another lesson from bulletproof. There are some admin notices that are really long, unbroken strings. I created both fixed and fluid width versions of the admin design. Initially, fixed width was default, but I soon changed it to fluid width due to these long unbroken strings breaking the layout.

[yellowled]

So i have actually put some thought into this lately. I think in order to actually improve the user experience in the backend, our first thoughts should not be about the look or the layout of the backend -- it should be about structure, organization of elements.

The key elements of the backend (of any web site, actually) are the navigational elements. They're also (apart from header and footer) the one thing all backend pages have in common. They are probably, if you will, the most used part of the backend. Just think about how often we have to tell people where to find stuff in the backend here in the forums.

So how do we make the navigation easier to use? I think the key is to simplify it by reordering it, changing the way it is split up into pieces or elements related to each other. Right now, the navigation is basically one huge thing which is technically an unordered list -- which is fine since it is the proper HTML element for navigation. We just need to nest it better, which isn't a big deal.

My idea is to first seperate the user-specific parts of the nav from the general elements. Stuff like personal settings, logout etc. should be put in some kind of "user nav", i.e. like this:

Logged in as: user (level)

• backend start page
• personal settings
• back to blog (new window/tab)
• logout

I'd also like to propose new sections for the rest of the nav elements as follows (starting w/ the elements present in a fresh installation but adding some plugin stuff to illustrate the organization better):

• Content: new entry, edit entry, later: static pages
• Media: media db, directories, add media, manage previews
• Taxonomy: categories, later: tags
• Feedback: comments, later: spamblock
• Extend: templates, plugins
• Admin: configuration, permissions
• Tools: import/export, integrity check

Another key factor to simplify the nav is to keep the titles of nav items as short, simple and "obvious" (i.e. self-explanatory) as possible. As a bonus, this will also make it easier to style the backend, especially in terms of multilingual consistency. We may or may not have to use icons to illustrate the purpose of individual nav items.

So, any thoughts on this? (A simple "Make it so" will suffice. )

Also, question: Is this gonna be a problem apart from the fact that we'll have to change, like, a gazillion lang constants? I have no idea how inserting new nav items in the backend works, will we have to revise every plugin which adds a new nav item as to where to put it's nav item?

YL

[onli]

I have no idea how inserting new nav items in the backend works, will we have to revise every plugin which adds a new nav item as to where to put it's nav item?

Jep. Atm, a plugin may insert a menu-entry only in the entries-section, at least as far as i know. We would have to add some hooks to the new menu and change the plugins accordingly. But that should be very easy.

I like your idea of restructuring the navigation. But i couldn't sort the word "Taxonomy" in.

[yellowled]

Jep. Atm, a plugin may insert a menu-entry only in the entries-section, at least as far as i know. We would have to add some hooks to the new menu and change the plugins accordingly. But that should be very easy.

Phew.

I like your idea of restructuring the navigation. But i couldn't sort the word "Taxonomy" in.

I was looking for a headline for "anything which sorts content", i.e. categories, tags etc.

technical : the process or system of describing the way in which different living things are related by putting them in groups [noncount]

(And yes, a lot of content management systems use the word to describe structures similar to cats and tags. )

YL

[Timbalu]

Right now, the navigation is basically one huge thing which is technically an unordered list -- which is fine since it is the proper HTML element for navigation. We just need to nest it better, which isn't a big deal.

• Content: new entry, edit entry, later: static pages
• Media: media db, directories, add media, manage previews
• Taxonomy: categories, later: tags
• Feedback: comments, later: spamblock
• Extend: templates, plugins
• Admin: configuration, permissions
• Tools: import/export, integrity check

I like thinking new to old things. But I also like (the/Dons) Admin screen as of now - it is nearly clean and simple. Despite this is good work, YL. But this is nearly what we have already.

Except: excluding categories and comments from entries block, building 2 new navigations blocks.
Except: renaming navigation header blocks.
Except: excluding Tools from Admin as a new block.
Except: having "user nav" things altogether ( which is really something to think new, including dashboard features and so on ).

The one thing which is good to have soon, is excluding all plugin backend administration from entry navigation block.

Why mix Plugin administration things (tags, staticpages, spamblock, and other event plugins, ....) into the nav to different places? I know about the coherencies, which told you to go this way. But this is not simple. Why not have them all in one Place like "Admire Addons", split into a core plugin and a 'user' plugin section, or equal.

What is IMHO more important to think of, is what is going on the next level(s). This is the reason of many question referring to the backend. ( Off the record: Like more direkt links to known problems somewhere easy to reach underneath the nav. )

Perhaps you can sort out which of these questions and remarks are good for further discussions.
I thought these little contradictions in some points would be better than writing: "Go on".

[onli]

Why mix Plugin administration things (tags, staticpages, spamblock, and other event plugins, ....) into the nav to different places? ... But this is not simple.

But it is simple :) The only thing needed for that is specialised hooks for each section, called upon creation of the menu.

Why not have them all in one Place like "Admire Addons", split into a core plugin and a 'user' plugin section, or equal

Don't think in terms of a programmer when you don't have to. A user shouldn't care about core- or third-party-origin of plugins. The "human computer interaction"-folks would say something like "Speak the users language" (and structure accordingly);)

What is IMHO more important to think of, is what is going on the next level(s)

I am not sure I understand what you mean with that sentence. Something like "more important to think about what is inside the menus"?
If I try to think about that, I automatically think "we need a better way to change the admin-interface".

The real reason is that if we put core features in templates, we will never be able to properly update the core with new elements, because once people write backend templates, all the output would be part of the template, and we'd have a maintaineance nightmare...

Let's think about that again. Take for example the comments-section. At the moment, the whole site is generated by include/admin/comments.inc.php. It acts as the view of the page, but also as the controller, calling core-functionality:

Code: Select all

/* We are asked to delete a comment */
if (isset($serendipity['GET']['adminAction']) && $serendipity['GET']['adminAction'] == 'delete' && serendipity_checkFormToken()) {
    serendipity_deleteComment($serendipity['GET']['id'], $serendipity['GET']['entry_id']);
    echo DONE . ': '. sprintf(COMMENT_DELETED, (int)$serendipity['GET']['id']);
}

Would it really be a nightmare if we split that up? If we define a controller the comments-section calls, and a separate view (html-page in smarty+css), we could add wrappers to the controller and functions to the core and would have to change all the views - but only if they incorporate this feature. They wouldn't break upon us because of this. And how often changes this area?

I admit it is lot of work to create this structure in the first place, but we would also benefit a lot, being totally free in desinging the backend. It feels like the way to go before rewriting the interface itself - but i am eager to hear your opinion.
(Sorry for switching subtopics, YL)

[Timbalu]

Why mix Plugin administration things (tags, staticpages, spamblock, and other event plugins, ....) into the nav to different places? ... But this is not simple.

But it is simple The only thing needed for that is specialised hooks for each section, called upon creation of the menu.

Thats not what I meant. Not the technical issue.
I mean a Users first view, first look to find intuitive and simple what he/she is searching for...

Why not have them all in one Place like "Admire Addons", split into a core plugin and a 'user' plugin section, or equal

Don't think in terms of a programmer when you don't have to. A user shouldn't care about core- or third-party-origin of plugins. The "human computer interaction"-folks would say something like "Speak the users language" (and structure accordingly);)

I think different here, maybe...
Normal Users dont really know core plugins are plugins at all. They see them as a core functionality which is as it is. Getting used to the system, they want more to have. That why they install plugins. They know they have done so, so it is easy to find them again in the 'Admire Plugins->user plugin' section. The core plugin section will show - self explanatory - that even some core functions are build as plugins, which can be customized furthermore. In the moment we have both in the plugin section, just split into sidebar and event plugins. By the way, this is one of the structures which I called more important underneath to care and think about.