cayleygraph / web Goto Github PK

Currently, the query results panel doesn't expand to the full height when resizing a window.

OWL Union of Classes are classes that represent the union of two classes. They are represented as an ID pointing to a list of classes.

• Unions should have a special entity page.
• In many cases, the union class is a blank identifier. In those cases, a special rendering should be used in class instance properties.

Currently, the graph view ignores literal values. It should display them like IRIs.

Similar to a "Write" tab, we should allow dumping quads from a database.

It probably doesn't make sense to have a editor in this case - the dataset can be relatively large, so we should focus on saving the dump to a file instead (downloading it in the browser?).

The list of supported formats is exposed via /api/v2/formats endpoint.

Also, given that this functionality is literally a button and a format switch, we should consider merging it with a "Write" tab. Call it "Data" maybe? Later we can allow uploading the dataset from a URL.

Switching from "Query" to other main views clears the query results, which is very inconvenient when using Write/Visualize tabs extensively.

Currently, UI saves your last query, which is good. However, it saves the query globally, regardless of the query language.

Instead, saved query should be bound to a query language, so changing the query language should load the last query in that language.

Not that it's different from #5 that allows saving arbitrary number of queries and is not bound to the query language.

The only way to write data in the new UI is the editor, which is a regression from the old UI.

Note that old UI used a Write API v1, which accepts only multipart requests. The new UI should use Write API v2 instead.

Currently, you can only write data in nquads format in the UI. We should allow switching the format.

All available formats are exposed via /api/v2/formats endpoint. Note the binary field: it shouldn't be possible to write data in editor for the binary format.

All the views with two panels currently place them vertically (two rows). This uses the screen space inefficiently on wide displays, especially for long queries and large number of query results.

I propose changing the layout of those panels to horizontal (two columns), at least for wide screens.

@iddan mentioned that the new UI was designed to resemble the BigQuery which done a lot of UX research and picked the vertical design.

I believe this is still not exactly a fair comparison: BigQuery operates on a tabular data, so seeing all column names is more important than seeing more results, thus vertical layout makes more sense.

However I think it's not true for Cayley: results are shown as JSON and are usually <10 levels deep, so the horizontal space is not used at all. Making the layout horizontal will address this issue.

Datatypes are entities that represent atomic data types. They should have a special entity page.

Since the UI is now a separate project and requires a separate build process, we need to setup an automated build (in Travis CI) for all releases.

This will help embed the UI in Cayley as well: instead of hacking build scripts in Cayley to build UI, we can instead download an archive with the latest UI release, unpack and embed it directly.

The Query API allows to set a limit for a number of query results returned. We should probably allow setting it from the UI as well.

A small thing, but the logo is missing in the new UI :)

In our previous experiment for the UI we added a cool dev-oriented feature: the "Write" and "Dump" views were showing how you can make the same request as the UI on your own.

For example, for "Read" we showed something like this:

GET /api/v2/read?format=nquads

It was written in a tiny grey font, so it wasn't too distracting, but gave a clue how you can achieve the same from other systems. I think this was a great way to emphasize that the focus of the project is on the application developers.

For the new UI, I think it doesn't make a lot of sense to add this grey text. Instead, we can add some kind of button that brings up this tip. In this case we will have more space for information and can add a curl command that does the same request as well.

For most use cases the Cayley instance will not be publicly accessible.
OpenID is a standard for accessing private servers through an identity provider.
The web client should conditionally implement it to support servers protected by open ID.
Cayley servers can be easily protected with Pomerium.

I propose to make the "Visualize" view a tab in the query results. It's definitely more convenient and is a more standard way of doing it (see Neo4j and Dgraph UIs).

Clicking "Run" when the "Query history" tab is selected should switch the tab back to the "Results" tab.

When an operation fails an error message should appear.
cayleygraph/cayley#110

When there are too many results, the result panel cannot be scrolled with a mouse wheel when using Firefox (tested on 69.0.1 and 70.0b12). It works perfectly fine in Chrome. Scrolling with mouse by dragging the scroll bar works on FF as well.

Display the time it took for the query to execute in the Query tab.

Allow saving queries

Clicking on the item in the result history should set the query and the language to the query editor.

I think it makes sense to make the "Query Shape" view a tab in query results view, similar to #12.

The way it can be done is to add another button called "Explain" or "Profile" that will run this query shape request and switch to a "Visualize" tab automatically. Alternatively, the "Run" button can be switchable and show this option in a drop-down menu.

I think it will make it more familiar to users, since it's similar to how SQL does it.