Working on 2.0: Developer sprint

[Don Chambers]

I do not want the entire banner normally emitted in the admin suite, nor s9y & php versions on the login form.

While I second that from a design standpoint, it does have its benefits to emit the versions there. If somebody states his blog url in the forum, but omits the versions, we always have a quick way to look them up. I'm not saying this should be a deciding factor, it's just something to consider.

We can see the s9y version by viewing the page source.

What I meant is that I cannot uniquely identify all the admin pages by a predictable url... There is no single url for "manage styles"... it changes depending on what you are doing.

Of course, but now that (almost) all of the backend is smartified, you'll be able to have individual markup for those pages (actually, “just” for their content). Are you saying you would need i.e. an id for the body or something? What for?

In the simplest form, lets say I want these admin links (ie, new entry, edit entries, comments, configuration, media library, etc) to be buttons. And lets further say that I want to change the button appearance when it has been selected. I click on "Manage styles", and the url changes to "http://www.domain.com/serendipity_admin ... =templates". That's great, so in my smarty template I have something like {if $currpage="http://www.domain.com/serendipity_admin ... s_selected", and via css I change the appearance of that button.

Numerous problems exist because, if I select a different template, the current url changes based on the selected template, such as "http://www.domain.com/serendipity_admin ... heme]=2k11"... and now my conditional test for the templates page no longer works. If you select a template with options and save those options, the page refreshes to "http://www.domain.com/serendipity_admin.php", even though the page is still what we would mostly see by selecting "manage styles". See the problem?

Not sure if you caught it yet, but I see that one of your recent commits seems to have overwritten the frontend entries.tpl with your admin version in 2k11.

[yellowled]

We can see the s9y version by viewing the page source.

If the template chooses to emit it, yes. (I'm not saying we have to emit those, they could actually be confusing for non-technical users, and they don't provide any information we might need anyway. Just wanted to point out that it has its benefits as well.)

And lets further say that I want to change the button appearance when it has been selected.

That could be done with a currpage indicator. I'm just not sure we actually need that kind of indicator, it really depends on the way the whole navigation concept ends up. I'm not entirely sure our current navigation concept is the best solution in terms of usability. Try not to think of the new backend as the old one with a new style necessarily. It could still turn out to be a whole new concept in terms of how to interact with it.

Not sure if you caught it yet, but I see that one of your recent commits seems to have overwritten the frontend entries.tpl with your admin version in 2k11.

I haven't committed to the 2k11 repo in 9 days. The entries.tpl in the s9y-admin-tpl repo is still the same. Can you point me to the commit you're referring to on GitHub?

YL

[Don Chambers]

I'm not sure if we need the currpage concept or not - would just like to have it as an option. At the moment, we cannot, because any one page's url might have additional modifiers appended to it due to the selected action and therefore be unpredictable in a template logical test. In general terms, I would like to see as much flexibility built in as possible, allowing for any number of admin templates.

Disregard what I said about entries.tpl.

[Timbalu]

One set of icons that I would love to use is icomoon.

Very nice also!!

Just to add another very nice one used by bootstrap, linking origin to http://glyphicons.com/

[yellowled]

In general terms, I would like to see as much flexibility built in as possible, allowing for any number of admin templates.

That's definitely true. However, if the currpage functionality is feasiible is a question for the coders.

Just to add another very nice one used by bootstrap, linking origin to http://glyphicons.com/

I'm not a fan of Bootstrap, but that's a different discussion. The problem with Glyphicons is that the free license does not offer an icon font. Personally, I don't think it's that different from Font Awesome (which was used in Bootstrap before) to justify the price for the royalty-free license.

YL

[onli]

In general terms, I would like to see as much flexibility built in as possible, allowing for any number of admin templates.

That's definitely true. However, if the currpage functionality is feasiible is a question for the coders. :

It is. And we already have something like that in the backend to set the <title>.

[yellowled]

And we already have something like that in the backend to set the <title>.

Unfortunately, {$admin_vars.title} is not unique. I.e. it says “Entries” for both “New entry” and “Edit entries”.

YL

[onli]

True, but that should be possible to change.

Two more points for the next sprints:
1. Backend-related: I just lost an article I wrote for one and a half hour because of the damned timeout on preview. We should save the editor-content via localStorage automatically, or extend the plugin accordingly and activate it by default. And disable the timeout if possible (probably a php-setting though)
2. In the core, there is quite a lot of calendar-related code no one seems to use anymore. I'd like to remove all of it.

[yellowled]

I also have more points to discuss concerning the backend development. They sort of keep me from doing actual design work since I'm not good at doing visual design in Photoshop. I need markup to work with. I also keep stumbling upon markup which needs to be rewritten, but all in all, it's gone pretty well over the past week, also due to some pull requests by Timbalu. Still a LOT to do, though.

Here's what I remember:

* Media db: I already discussed this to some extent with Garvin. Bottom line is, the current media db is not ideal. We might want to replace it altogether (which could be hard due to licensing) or give it a serious rewrite (which I can't do on my own). I have, however, rewritten most of the media db to sensible HTML markup, so we wouldn't necessarily have to start from scratch.

* Navigation: I'm still not sure whether the current structure of the navigation is the best we can do. I have some ideas in my head which would also influence the possibilities in terms of styling it, but there's no clear vision of it yet. It could also be an issue with plugins which create their own navigation items like the static page or freetag plugin.

* “Reduced” backend: I still think it's a good idea to have certain areas of the backend emit or display a “basic” version of the interface which can be extended to an “advanced” backend, i.e. showing/hiding the more advanced options of certain pages. I think we need to discuss this further, though.

* Javascript: If we want the backend to be as flexible and accessible as possible (I think we should want that), it should work without JS enabled, at least its core functions (which I think is possible). Also, we do want to rewrite the JS parts to make use of jQuery. If we agree on both, it might actually be a good idea to strip all JS from the backend for the time being. That would make it easier for me to develop the markup and styling as well as to test the JS-less backend.

* Inline JS/CSS: There are some parts of the current inline JS/CSS which use Smarty variables (which is not possible in external JS/CSS). We could store these Smarty variables in elements accessible via the DOM (i.e. hidden inputs with an id), but I'm not sure whether that's actually a smart idea.

I think that's about it.

YL

[onli]

I hereby want to remember all of you that we wanted to meet again on sunday :)
As we didn't talk about the time, as far as I remember, i suggest 5 pm. Or is anyone here who would like to meet earlier/later?

As an agenda, we seem to have quite some stuff to do. There is the design of the backend, which this discussion shows, but we also have some other stuff (plugin-selection, calendar, caching) I listed in the first post of this thread.

We will probably talk again quite a bit, but in the ideal case we can distribute some things to work on afterwards and maybe have already worked together on a starting point for that work.

[Timbalu]

I hereby want to remember all of you that we wanted to meet again tomorrow

...did I miss something? Which Future or Planet?

[onli]

Corrected -.- Sunday. thanks

[garvinhicking]

Hi!

Sunday 17pm is fine with me. I could also arrange an earlier time on that day, whatever is best for everyone. I would have 3-4 hours available during 12am and 10pm, I can fit my personal schedule around the meeting.

Looking very much forward to hearing from you guys.

Regards,
Garvin

[yellowled]

Sunday 17pm is fine with me.

I can do 5 p.m., probably earlier as well. But I do think it would be good to have as many of us present as possible, so let's try 5 p.m.

YL

[Don Chambers]

I will again be available forcing everyone to again speak english as much as possible.