Admin Flux

[Owen Winkler]

Since the topic was coming up in IRC, I figured I'd mention it
specifically more visibly.

The admin javascript (and CSS) is going to be removed and replaced. I
specifically mention the javascript because that's the part I'm planning
to involve myself in actively.

Obviously, others are welcome to help in this effort. The goals are to:

* Reduce the size of the javascript. This will aid in maintainability.
* Produce better general-purpose handlers from the onset. There are
some objects we use regularly that have some special cases that need to go.
* Integrate better with new form controls. There is at least one new
control designed to work on lists better than what we have already in
the admin javascript.
* Make use of the server-side ajax response classes. There is a useful
client-side script for interacting with the server that should be used
more, since it will give us the the ability to use simple, unified
notifications.

In particular, the publish page is in shambles due to some now-obvious
deficiencies in the markup/script. A particular symptom of the current
issues includes some weirdness in behavior when trying to publish a
draft. The publish button doesn't seem to do anything (it actually sets
the status selectbox of the post, but doesn't submit the form), and then
the save button generates a "are you sure you want to leave this page?"
message.

If our admin HTML was written more resiliently, this might not have been
a problem. Instead, the HTML is replete with idiotic class names, upon
which the script has become dependent. It is *imperative* that new
markup is, if not semantic, then at least *addressable by script in a
sane way*. It has been a factor of the FormUI rewrite to produce
absolute minimal HTML for this purpose.

Also in the works with javascript: Removal of the "cool but
questionable" loupe, to be replaced with a more GMail-like search box,
with autocomplete, like this: http://screencast.com/t/1qGp1As4uO

There is work in progress to return the admin both to a workable state,
and to re-style some things based on the new FormUI-supplied markup. I'm
not sure how we should be filing issues against the admin at this time,
since those issues are a distraction to that effort by having to deal
with continuous new issues on things that we are aware are in flux, and
also counterproductive to have passersby try to fix those issues when
we're replacing large sections of that code. (For example, it's largely
pointless to try to fix the javascript on the publish button, when the
javascript-generated publish button is going to be replaced by a real
FormUI one.) Suggestions on how to deal with issue tracking on this
topic are welcome.

Owen

[ringmaster]

Hello fellow Habari people,

This is just a reminder that the work for the admin in regard to FormUI in master (0.10) is still ongoing.  You should review the post I originally wrote on this topic to acquaint yourself with these changes.

If anyone has any comment, I'm still lurking.

Owen

[Konzertheld]

GitHub recently introduced issues that are split into tasks. You can add checkboxes to the issue text and use them as a todo list. That could be used to note all the small issues that we/you are aware of, such as the JS button. I don't see the problem in opening new tickets for larger issues. Also, I highly discourage the current behaviour not to use existing or open new tickets for admin rework stuff. That effectifely stops passersby and everyone not deeply involved from helping out. It's already hard enough to keep track of what is done. We had labels not long ago for issues, there was an admin label etc, if those were used, it would be easy to find multiple tickets regarding a larger code part.

And one more thing on working on stuff and using issues. We obviously are in a state of heavy flux. We have to take care not to lose track of all the ideas and at the same time we need to focus on some parts instead of working on all of them. Otherwise, we will not get back to a usable master before the end of the year. Example: There's discussion on GitHub for reworking the entire status system. Starting work on that would massively slow down work on the admin, even if it relates to some of the admin rework issues (like, wtf is going on when a post is published).

We have some milestones on GitHub. Maybe we should add some more fake milestones so we can assign more stuff to milestones and then actually work on the next milestone, and only the next one. So, what I am saying is: I don't have a solution on "how to deal with issue tracking on this topic" but I also don't think we need a different system than the GitHub issue tracker.

[Michael Bishop]

On Mon, Apr 15, 2013 at 9:38 PM, Konzertheld <christia...@gmail.com> wrote:

GitHub recently introduced issues that are split into tasks. You can add checkboxes to the issue text and use them as a todo list. That could be used to note all the small issues that we/you are aware of, such as the JS button

 

For reference to the task lists with the GFM https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-comments