Future concept for an ajax driven way to book and edit efforts.
Currently editing efforts is not user centric. Booking new efforts is only possible in a project where other efforts are not displayed. Entering the separate effortEdit - dialog additional detracts focus from the actual task. Reason for this being the relatively simple implementation for single projects, ajax (or ajah) frees us from this limitation.
One Single pageπ
I propose a single page for following purposes:
- View / Check recently booked efforts
- Book new efforts
- Edit / Delete old efforts
Workflow / Createπ
Editing efforts strongly relies on getting Information via ajax and type ahead dialogs similar to google suggest and google calendar. The workflow could look like this:
- select New Effort... - link
- The link is replaced by an edit form
- If there already is an effort for this day...
- initialize start time for last end
- initial Project and Task from last effort
- set keyboard focus either to "end" or "duration" field which provides a good suggest list with times in 30 minutes steps (compare to google calendar)
- if day is today initialize "end" with current time
- The amount of time booked for the day in being adjusted on each change.
- If user changes project, query open tasks and folders with ajax. This should only be done once for each project.
- If user enters the Task list google suggest box if available tasks. The list should be hierarchically indented.
- User goes to Comment field and enters some description
- He could click the "Add detailed comment" to display an edit area for detailed description
- Clicking Save stores the new effort with ajax (no page request). If the effort was the last of this day, automatically provide an edit form for the next effort below, with start time and project being initialized.
- User clicks Cancel. Form is being replaced by New effort link.
Workflow / Editπ
Already entered efforts have an hover effort (compare to inline wiki edit in current streber head revision) to suggest that they can be edited. Clicking an effort, changes the line into the edit form. The editing process is identical to creating new efforts.
Some ideas on implementationπ
- contains list of Efforts - objects rendered as table-rows
- NOTE: having a table for each DayBlock will cause layout problems, because TDs will have different width. (ups!)
- Assing click() handler on TR
- Replaces TR with Form (could be completely rendered by HTML)
- could return actual TR on failure
More Ideas on implementationπ
What's required to build a interactive efforts list:
- replace table row with a short html-form
- detect number of columns for colspan
- render table with inbetween headlines similar to a grouped list (actually this IS a grouped list, which reminds me that Grouped Lists should be restyled sooner or later.)
- insert headlines
- render html table with unique tr-ids that can be rebuilt on the server
getting updates from the serverπ
- find a unique way to define a list (filter set) to request changed values
- ask for updates for certain rows ala:
- The big question here is where to insert the rows that are coming back?
- The whole function should also have some benefit for the collapsing and expanding of tasks lists.
If this would return a valid <TR> anything would be fine. But a non styled json-feedback would be much more flexible.
Always store the valid table-layout at the server-side! But way if the users opens several tabs and the list styles is been changes. When goes back to the old tab and requests some rows he will get them in the from sort order.
Keeping track of list styles on the client siteπ
There seems to be several possibilities:
1. add a fractional url-request part as custom attribute to the tableπ
The table at
might start with the following html code:
from example code
<table updaterequest="go=projGetTasks&sort=name%20DESC&style=grouped&group_for=type&columns=__select__,name,description,modfied" ... >
The information given in udpaterequest would be sufficient to render the table with the correct style, columns and ordering. Since all of this information should be available when rendering the list anyway, adding to additional data should not be difficutlt. This assumption excludes problems with encoding and special chars, though.
... try to get a clue on how the request should look like. The thought of potential problems with this approach gives me the creeps.
3. Reduce the number and layout of columns to a fixed number of presets.π