informatics-isi-edu / chaise Goto Github PK

Provide an annotation mechanism (or augment an existing one) so that table entities can hidden in the detail view. In particular, suppress FK traversals for such tables, such that for any given table that is to be hidden/excluded, automatic queries for that data are not performed when a key relation to that table is encountered in another table.

When clicking on a the Switch view button, the tooltip appears and remains visible even after clicking away. This behavior occurs in Firefox and Safari, but not Chrome.

We should be running tools that do static code analysis across the project.

Pull in dev deps from npm repo.

Without a license, this project isn't open source and no one can use the code.

Please use something like http://choosealicense.com/ to decide what license to use. I recommend MIT or GPL.

let bower pull in the runtime deps

These global vars are prefixed with 'psql' which is confusing because Chaise knows nothing of psql instead it knows of ERMrest.

Currently, the search results views only display data coming from the target table type (e.g., the one selected "search within" XYZ table). The search results views should include additional attributes from related entities. I.e., searching on table A, it should be able to display attributes that are also in table B, if table B and A are related by a foreign key reference.

More specifically:

• use annotations to determine what, if any, attributes should be included in the results view by default;
• and allow the user to add/remove attributes from the views.

Currently, we only can see matching attributes and have to drill down to see matching values. Investigate if we can show both attribute and values on slideout during search

We need to review and revise all annotations used by Chaise. These should follow the key/value pattern of "unique URN" : "value which may be json document". We should not reuse generic annotation keys. The annotation key should have some semantics.

1. first we need to define what are the annotations we need to support for our current use cases
2. draft a set of annotations
3. review with our internal stakeholders (i.e., other users of chaise/ermrest)
4. revise based on feedback from 3 above
5. then update the documentation and code

Users have expressed a desire to have a more obvious google search like first experience with interface. Need to figure out how to make an obvious search box that blends smoothly with faceting.

The code currently seems to largely map ermrest column types to presentation methods. However, some of the presentation models are equally valid for some types depending on use-case.

1. Conceptually, a slider can work for any ordered type including numbers, times, dates, datetimes, and even strings since they have lexicographic ordering.
2. A text-entry box can be useful for pretty much any type.
3. The pick-list is also valid for any small set of values.

In addition to the heuristic pick-list presentation, it would be helpful to allow a user to toggle different presentations at runtime or even save personal preference settings of some kind.

The search sidebar already toggles but we should add something in the UI to hide the sidebar when it's open and to show the sidebar when it's closed.

Sidebar should be pinned open by default.

The "Enabled X of Y filters" label should read "See all Y filters"

Search bar in the sidebar is a pill shape to make it look more like a search bar. The default text in it should read "Search filters by keyword"

I know I removed the magnifying glass in my prototypes but now that we're moving the "Enabled X of Y filters" link to the bottom, I actually think it's better if we keep the magnifying glass.

Right now, switch layout buttons appear in a drop down. We want these to be visible in a row and change state by toggling. See this for example:

http://store.apple.com/us/accessories/all-accessories/airport-wireless

Also, the label text should be turned into "tool tips". We do not want to have the labels in the buttons. Just little square buttons with icons.

The links to "Using the Data Browser | Send us your feedback" are hardcoded to one use case. These need to be either

1. generic: we could host a generic help page on github in a docs section and a generic feedback form, or
2. configurable: probably passed in as a javascript variable in the html page which should then be configured for each deployment / use case of the UI.

glyphicon-chevron-right doesn't show up in the browser. Only an empty box. Possibly related to the fact that glyphicons font file isn't loading (404).

We should have one of those spinning progress indicator icons displayed whenever the search results are being updated. Especially for clients on a bad wifi or wireless data connection, the latency can be fairly high and the site does not give an indication that anything is happening.

Make layout more logicial, perhaps moving add facits selector to be pinned on the bottom.

The new details (aka summary) page that is in the Chaise-Details repo should be integrated into this repository. We have the following options:

• integrate it tightly into the current chaise UI by making it an angular view with its own route
• integrate it loosely by keeping it as a separate page/app that is linked to by the current UI

Then we need to:

• refactor the current detail page and remove any dead code.

Since we cache our JS files (see #28), we should also cache our CSS files in the same way. I remember @svoinea also mentioned this in an email thread last week.

Factor out the detail view from the facet/search/browse/results part of the app. This means breaking the app into 2 distinct "pages" effectively. One for the search/browse functionality and one for the detail views. There should probably be reusable lower level libraries between them such as the logic to interact with the ermrest service. Also there will be some shared state probably coming from a cookie that both pages/apps can access.

The UI needs to be able to present "nested entities" (i.e., entities that are related by a foreign key or an association table) in a compact table view rather than a repeating list. That is, right now we embed them as lists rather than tables. There should be one table per nested entity type. So for example is you are searching on a model that has Experiments, and it has Samples and Slides, the display page for Experiments could have 2 tables for the nested Samples and Slides data. This feature should be generalizable to handle any data model. It should use schema annotations to determine whether the nested entity should be displayed in table vs list. By default we might even want to do with tables and only use lists if the annotation says so.

Is there a reason for the bootstrap scripts not under the vendor directory but under the scripts dir? I would think they belong under scripts/vendor.

The project lacks unit tests. This will require writing a lot of tests to resolve but we can start by getting a unit test framework wired into the project.

There are several kinds of statistic that could be rendered graphically in facet widgets to help users understand the data.

1. Distinct value distributions on sliders to help understand sparse ranges, e.g. dense areas where active values are clumped together vs. gaps where there is no further way to differentiate records with range filters.
2. Total value distributions which additionally show how popular certain values are. This could be used on sliders, pick-lists, or even date pickers.
3. For the above measures, there is a version that considers current filtering criteria and another that considers all records unfiltered. Some rendering methods might even display both statistics to highlight the difference between active and inactive records?
4. Some combination of curve plots, coloration, or heatmap rendering techniques could be used to present these statistics within the different presentation modes. E.g. a 2D curve or bar-graph behind a slider; a per-element bar-graph or color mapping for pick list entries; a different color mapping for day boxes in date pickers; or even some kind of 2D curve within each day box for datetime pickers...

When dealing with a large set of facets (e.g., hundreds) there are some usability issues in the facet selection pop-out. Lack of a "grouping" mechanism is a big one. Having an optional, collapsible header around facets at the entity level would be a big help here. This header could default to the currently annotated display value for the parent entity.

This would also help with the presentation of "duplicate" facet values in the selection pop-out, which can happen when more than one table entity has a column with the same name. Simply annotating these duplicate column names differently (e.g., by prepending the table name) is less preferable than having a grouping mechanism that properly reflects the source entity.

This is also a very common UI feature in filter selection components of large-scale ecommerce sites.

Whenever we redeploy Chaise and want to use it right away we have to use the browsers 'clear cache' feature otherwise we will just be using the browser's currently cached version of the .js files it loaded previously.

First, we need to identify the best strategy to avoid this problem. For instance, once basic approach out there is to always deploy your new code to a new path, e.g., path/to/v#/myscript.js where v# is some version number. Then we need to fix the deployment procedure for Chaise. This should be scripted so that with a single command we can (re)deploy Chaise. No manual steps should be involved.

Integrate a third party usage analytics service (e.g., Google Analytics). We should be collecting key user events, such as: faceting behavior, browsing behavior, what data is being viewed, what attributes are being used in searches, when the user has to "enable" more facets because the default list wasn't enough, how long they spend on certain views, etc. etc. etc.

1. We should first come up with the initial list of events we want to capture;
2. Come up with a plan for how we will integrate this;
3. Review the plan before executing on it.

Some additional constraints:

1. We should probably write our own wrapper API around the analytics provider (e.g., GA) so that we can integrate with different analytics vendors;
2. Account details (e.g., the Google Analytics account where events are sent to) should come from a configuration, it should not be hardcoded to one operators GA account.
3. Operators/Administrators should be able to disable user event collection entirely for their own deployments.

Need to consider layout in which slide out is pinned open, and make this an option for first access of interface.

We need documentation on all of the current annotations in use in Chaise. It should cover:

• key
• value
• a description of it, what it does, etc.
• where to apply it, on table, on column, etc.

It should give the reader enough understanding about what and how to use the annotation.

For background on this issue see:
https://developers.google.com/webmasters/ajax-crawling/docs/learn-more

This may be a challenge, but if our app is not crawlable then our sites will be hidden from much of the web. The suggestions in the google link do not provide much comfort. We need to evaluate the issue and propose some solutions first.

Not sure who wants to take this on: @svoinea @howdyjessie @crisaless

I would like to be able to annotate a schema in the same catalog being used by chaise as "excluded" so that all tables under that schema are not being processed by chaise. In this way I can use tables in that "excluded" schema for receiving data updates and then run in-database transformations to populate the actual tables used by chaise.

This should include, how to setup for various flavors of authentication:

• none
• session
• globus oauth
• google oauth (if known)

It should also cover how the default catalog and schema are chosen and how to configure that.

It is possible to have column display name annotations that are much longer than the current fixed-width of the facet slide-out. Instead of trying to wrap these strings to fit the width, it may be easier just to provide a horizontal resize function for the slide-out. It should at initially at least persist the setting for the session, but ultimately persist across sessions.

A checkbox to toggle facet selections

We're not sure if this is doable. As @robes mentioned: "... we might need to discuss this with @svoinea because we can’t have these lists blowing up (a) the Chaise URL now that we put all this in there, and (b) the underlying ERMrest URL. A lot of middleware (browsers, web servers, URL parsers) have limits to how long of an URL they allow."

A Chaise URL should represent much (if not all) of the state of the application. For example, the state of the app currently includes things like:

• the current collection (entity set) that the user is browsing,
• the facets that the user has selected,
• the current layout (list, card, or table),
• whether the slide out is shown and which panel is displayed,
• and if we had sort ordering that would also be part of the state.

All of this state could and should be represented in the URL. If it were represented in the URL then a user could:

• link directly to it from another web page,
• bookmark it for later viewing, or
• share it (email, text, etc) to a colleague for them to see the exact same view.

To do this properly, the state of the application should come in the fragment identifier portion of the URL scheme:
http://en.wikipedia.org/wiki/Fragment_identifier

That means that it should be after the "#" character in the URL like:
https://example.org/myapp?someoptions#fragment-id-here

In the facet selector, the listing is somewhat random or based on some internal implementation state. Users would like that ability to have a specific attribute type (e.g., organism) appear as the 1st facet in the list, followed by some other attribute (e.g., data type) appears as the 2nd facet in the list and so on.

We should have an annotation that lets the user say exactly what order an attribute appears in the facet control. When the order is not specified the UI can pick the order based on other heuristics.

Enhance the chaise/record app with ability to edit individual attributes in place. Should be able to pick or enter values from a data type appropriate entry control (e.g., a date picker for date fields).

Based on conversations with @carlkesselman @crisaless @howdyjessie we want to make a few mostly cosmetic changes to the search/filter experience to address some of the feedback we have received.

• make the facet slide out ‘pin-able’
• by default display the facet slide out (by default make it ‘pinned’)
• make the facet slide out search box more obvious (too subtle right now)
• drop the 'filter' button since the slide out will be pinned by default
• hide the facets chiclet box when it is empty before the user has made any facet selections
• don't outline the chiclet box, which confused people by making it look like you can enter search strings in it
• don’t gray out the search results listing when you are faceting, just reflow them on the page
• reposition the “enable more filters” to the bottom of the facet slide out
• instead of "enabled X of Y filters" just say how many filters are available
• change the text from "Search data" to something else (maybe "Type here to filter" or "Type here to search for filters" something)

Additional functionality that we should document in other issues:

• ability to specify the exact order of filters in the facet control (addressed by #51)
• facet control should show the keyword hits when the user types something like "'msx' in mouse genotype" (addressed by #43)

Instead of including the files with chaise, we should let a CDN host it for us to improve site speed, especially for popular tools on popular CDNs — like using Google's hosted jQuery.

Not sure why we have a js file called facebase.js in our scripts.

This block references a specific use case and data model. It should be removed and any other code that depends on it.

Some of the types are not ever returned by ERMrest. We should prune those that are invalid from the lists and also remove any conditional and other code branches that depend on these types.

We should be minifying the project source into a single script for the package.

... to avoid cluttering the global scope.

IIFE: http://benalman.com/news/2010/11/immediately-invoked-function-expression/

Below the facet chiclets, as indicated in this prototype:
https://jessiew.proto.io/share/?id=907ab706-2096-4091-ac10-3e37f2f2cdd7&v=3

Create a branch to link in new details page. Need to resolve formatting differences

The project lacks a build script. We should have a scrip that drives the important tasks for building, testing, packaging of the project.

"TypeError: $(...).tooltip is not a function" appears in the console. The error prevents the page from loading completely.