Working on 2.0: Developer sprint

[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.

[onli]

Log:

• fixed spartacus-bug (only 2.0-template), should be able to install external plugins now
• We want a selectable admin-template in the end (so we'll move tpls currently under include/admin/ to template/admin/templatename at one point)
• navigation in the backend: trying to go with YLs concept (fewer entries in total, but more important ones), but adding quick-access to the dashboard. Maybe a quick-access-bar in the header for important items like new entry.
• YL will design one backend-page "properly" so we can design the other ones, too (and commit his changes so far to 2.0)

[yellowled]

[*] YL will design one backend-page "properly" so we can design the other ones, too (and commit his changes so far to 2.0)[/list]

If this is okay with everyone, I would like to write the “backend style guide” or codex first. I think that will make it much easier to build a consistent, coherent backend as a team.

YL

[yellowled]

I started writing a codex/style guide. It's on GitHub – is that (as little as it is) roughly what you guys had in mind?

YL

[Don Chambers]

That is definitely moving in the right direction, but my personal preference would be to see that contained on our technical documents.... could add it to the existing "best practices/coding style" page, or start a new page specific to admin.

My personal desire was to document/suggest the html structure of page content emitted in <div id="content>.

I forgot to mention yesterday that I spoke to the author of icomoon icons, which I happen to really like. We are welcome to include up to 400 icons within serendipity if we want. I think we would need the essential pack for all our needs, including media library icons. I would be happy to pay the fee as a contribution to the continued development of 2.0 if there is a mutual desire to use this icon pack.

[yellowled]

That is definitely moving in the right direction, but my personal preference would be to see that contained on our technical documents.... could add it to the existing "best practices/coding style" page, or start a new page specific to admin.

I hate the current wiki system. As long as I still write this thing, I'll pick a platform which is comfortable (which means iA Writer; GitHub is just a place to store it and track the progress).

My personal desire was to document/suggest the html structure of page content emitted in <div id="content>.

I'm not sure I get what you mean by that …?

I forgot to mention yesterday that I spoke to the author of icomoon icons, which I happen to really like. We are welcome to include up to 400 icons within serendipity if we want.

I just today started to integrate the FontAwesome icon font.

Integrating icon fonts can be a pretty tedious copy & paste job, so I haven't gotten that far. I'll take a look at icomoon later and see if we can get along with the free set.

YL

[Don Chambers]

I hate the wiki too, but still believe documentation should be centralized. A frequent complaint regarding s9y is a lack of, poorly written, and/or outdated documentation. I think what you have started is fantastic - I just think it should be saved in the same repository as our other documents. I would love to see the wiki replaced, but that is a project for another day.

[yellowled]

I think what you have started is fantastic - I just think it should be saved in the same repository as our other documents.

It can still be. While writing it, keeping it in a GitHub repo is just way more comfortable for me.

I still need more input as to what you guys would need from such a codex document. What I've laid down so far is not much more than some general best practises plus specific instructions as to how to apply them in our new backend. What other questions are open, what other aspects of the backend are unclear to you?

YL

[Don Chambers]

I'm a little uncertain of what I can be working on. Any suggestions?