chop-dbhi / cilantro Goto Github PK

This will ensure we are taking advantage of various screen sizes and optimizing the layout.

To better support reverting changes, the page should also update in place.

Since we have a uniform view of a concept's interface, all of the logic necessary to switch between views and update each other's state is no longer necessary.

To ensure users don't get confused about the report they are currently viewing, the currently active report name should be displayed on the right hand side of the navigation bar.

The Dagnosis browser viewset is fetching the javascript and css with no errors, but does not see to be rendering. I am unsure where the issue lies.

The hard-coded label of "Patients" on the results screen should be easily changed by a project setting.

This will include simply instruction for install the Google Chrome Frame or using a different browser.

The ability to create saved report must be turned off although existing public reports can still be accessible.

An extension of #2, this could be a drop-down menu all of saved reports and an option to start a new report (clears the session reference to the last report). When clicked, it will switch to the selected report.

One caveat to this is ensuring any unsaved changes to the current report are taken care of. An additional prompt may be necessary.

New columns added to a report do not have a header. A manual refresh of the page restores the headers.

Simple modal with useful info/images about saved reports.

Since the static/ directory gets collected by the project, it may be copying over an excessive number of source files. Also, now that we are using a Makefile, during normal installation via the setup.py file, a make command can be called to do all the dirty work of copy/building/compiling the static files as necessary.

The add condition button is becoming permanently disabled when the user changes the conditions on a concept.

So there are two schools of thought here:

• document-based - every change made to a saved report is recorded, but not immediately applied to the original report
  • pro - a user can revert to the report's pristine state in case they are unsatisfied with their changes
  • con - this requires an explicit action by the user to persist and unsaved changed made to the report
• WYSIWYG - any changes to the state of the currently active saved report will be applied and saved immediately.
  • pro - this, of course, does not require any explicit action by the user to save changes.
  • con - if a user performs a hefty destructive action that significantly alters the report's state (e.g. remove all data columns), there is no way to revert the change.

Ultimately, the latter experience is preferred, but only if there is a way to undo changes actions.

Includes, but not limited to:

• project name (used through out various places)
• email signature (used in various places, e.g. - The Foobar Team)
• header logo image or text (if no logo is available)
• footer text (markdown enabled)

The popover appears after a delay, but if clicked, before the popover appears, the popover appears afterwards. Obnoxious.

The JavaScript error is TypeError: Object has not method 'destroy' and looks like the culprit looks to be https://github.com/cbmi/django-cilantro/blob/features/saved-reports/cilantro/static/js/src/define/chart.js#L536

The add condition button is not changing to update condition when a condition is added.

In cases where the graph is too small to click on the actual bars, the numbers should be more obviously clickable (e.g. by changing the cursor to a pointer and by adding a hover color). Once selected they should change color (and possibly become bold??).

In order to make use of all the wonderful SCSS and various extensions that exist in a project, it needs to be broken out in it's own thing so if a project chooses to make use of mixins and such in their own SCSS code, this is available. This also serves as an avenue for creating Cilantro themes and integrating them into a project.

conceptmanager.js and criteriamanager.js (and fiends) should utilize the central pub/sub hub, App.hub. This will increase performance (no DOM bubbling) and make it consistent with the rest of the modules.

Use App.hub.publish(<topic>, arg1, arg2, ...) to publish content and App.hub.subscribe(<topic>, <handler>) to add a subscriber. The order does not matter since all late subscribers will be caught up in state once subscribed.

Currently if a concept is public, but contains no data, it still attempts to render and ends up looking like a bug. A catch-all view for lacking data should be implemented for a nice representation.

Currently modules are focused around each page which leads to fragmentation of models, collections and views for the major data elements e.g. Report, Scope, Perspective.

coffee/
    pages/
        workspace/
            main.coffee
        # etc..
    utils/
         log.coffee
         ...
    types/
         scope/
             models.coffee
             views.coffee
        # etc..

Each page will be responsible for implementing their own views, but should extend the types' views where possible.

The server reverts changes made to the saved report, but the page does not reflect his revert.

To keep up with the latest and greatest versions of external libraries, Git submodules can be used to keep a reference to the origin repositories. They can be scripted to update to the latest stable tag and copied from the submodule to the vendor directory.

Add a subscriber that handles queuing up and rendering messages published by various objects. To prevent message/notification fatigue, only one (prominent) message should be shown at any given time e.g. "Report X has unsaved changes".

For example, all of the session objects may publish a message when they have unsaved changes.

/report/31 → /report

The logic should simply reset the session report to the state of the requested report.

The directory structure for types look like this:

types/
    domain/
        models.coffee
        views.coffee

My proposal is to collapse the output of each submodule in a main.coffee which allows for only needing to import a single module for a given type.

types/
    domain/
        main.coffee
        models.coffee
        views.coffee

They need to be converted to SCSS and have a few classes for colors. http://www.red-team-design.com/just-another-awesome-css3-buttons

With the new polling features, the session never expires. After a certain amount of inactivity the polling should stop which allows for the session to timeout as normal. If the activity is detected, the polling should begin again.

For new users, this lower the barrier to having to understand and click through to the Define page. A user should only go to this page post-login if they have saved reports.

If a user comes back from a siesta and does not remember what about their report, "Awesome Report", has changed, it would be useful to show the differences.

This is simple: https://github.com/jrburke/require-jquery

Includes ability to edit metadata (name, description, keywords), create a copy, and delete.

Various parts across the app may contain "Learn more" links that should easily link to a section of documentation (preferably elsewhere on the site in a nice cohesive way).

Each of these links would open a modal with the relevant content.

The button needs to send a PUT of the current state of the session report to the reference URL. This will return the updated state of the report (and thus having no differences with the session) and will trigger the message to be dismissed (via change:has_changed.

The second part is to allow for choosing a new name for this changed report. Clicking on the "give it a new name" link in the message could slide down a input box for entering a new name. On enter or if the user clicks "Save Report", it will save changes (or create a new report).

• "added condition" message
• no conditions are defined

The stub classes are here: https://github.com/cbmi/django-cilantro-pre/blob/backbone-port/cilantro/static/coffee/pages/define/condition.coffee

Every time a condition is added or removed, a PATCH request should be made.

For new users, this lower the barrier to having to understand and click through to the Define page. A user should only go to this page post-login if they have saved reports.

This may not be a race condition in JavaScript, but rather subsequent requests are not yet uncached on the server. It may be worth looking into using a single resource for the session object to remove the need to reference each component.