Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Additions and Enhacements #3

Closed
Guttz opened this issue Aug 21, 2019 · 2 comments
Closed

Additions and Enhacements #3

Guttz opened this issue Aug 21, 2019 · 2 comments

Comments

@Guttz
Copy link
Contributor

Guttz commented Aug 21, 2019

During the development of the GUI a couple of enhancements popped up:

Macro features

Add graph interaction events/actions support

We've used vis.js as our graphing library and it enables a range of events in its API. We can use this to make the user experience better. The basic idea would be populating the right form/buttons according to clicks in the nodes. But there's much more that could be done, the library enables hover, selection, doubleClick, dragging and etc. Link for the library events api: https://visjs.github.io/vis-network/docs/network/#Events

Raw command concept

This is an idea I discussed with Akshay and Vishal and would be a cool feature to have in the GUI. Basically, right now the raw command is a representation of the command built in the GUI. It would be nice to actually make it a two-way biding with the UI and enable the user to input whatever he wants and try to request to the server so the GUI is also an easy to try "free console". I don't know the best way to do this while making it generic. The ideal would to make it in such a way that new additions to the Agent do not break the raw command input processing in the GUI.

Processing Hydra Doc

Right now, the GUI processes the Entrypoint and then for each hydra:Link endpoint available it uses the range property to know which node it's connected to. For non-collection Endpoints, this goes directly to the respective class. However, for the Collection endpoints, there are a couple of ways to do it. Right now the solution is to basically try to find the class which is related by extracting Collection from the Collection name and then showing the supported properties for this class. A more robust solution would be to get the range from the members' property in a collection, but this is not quite yet developed in the Spec. Another solution suggested by Vishal would be to get the expect property from the PUT operation in the Collection node. Either way, right now you can use all the classes operations and also use GET collection as default by simply not inputting properties in the form.

Improve responsiveness

I've added some basic support to responsiveness which breaks some components depending on the resolution. However, it's pretty basic so buttons/fonts sizing as well as spacing between elements should be more responsive

Deploy hydrus servers and input them in the Server URL input as a dropdown

So when the user launches the UI he can already try some online ready server. Similar to how we have one already deployed now.

Micro improvements

UX Enhancements

There are some things which could make the experience a little bit cleaner:

  • Default operation now is the first one listed in the Hydra Doc. Making the GET as default would be better to fast querying around Endpoints.
  • Saving Operations State. Properties have their own state so you can go around and come back and the values will be there. States are lost when you switch endpoints.
    -Button to clean properties. If you need to clean the form now you have to erase property by property.

UI Enhancements

  • Server URL input label placement
  • Set Node colors as the default secondary color(which is yellow for now)
  • Add Github icon to source repo
  • Change favicon to hydra icon

Clicking on links in the Output console could automatically fetch them

Or at least select the proper Endpoint, GET operation and fill the Resource ID field.

@Guttz
Copy link
Contributor Author

Guttz commented Aug 21, 2019

I've listed everything I think would be good as future additions.

In the end, the issue is too big so I'm thinking I'll break it in unique issues so it's easier to tackle. Some of these are nice for beginners too.

@Guttz
Copy link
Contributor Author

Guttz commented Aug 25, 2019

Separate issues were open: #5 #6 #7 #8 #9 #10 #11 #12, closing this.

@Guttz Guttz closed this as completed Aug 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant