GraphQL editor – Visual node editor for GraphQL(github.com)
github.com
GraphQL editor – Visual node editor for GraphQL
https://github.com/slothking-online/graphql-editor
24 comments
Thanks for that feedback. This is really valuable for me. I will correct everything you described here. I am not an UX designer to, so maybe this is the reason of bad UX and UI.
- I will correct drawing the lines - I will add a blinking cursor during renaming of the node - I will correct the query node to have input and output
So definitely there is lot of work to do. Deadline for these 3 - Thursday.
I used to work for Visual Effects industry 7 years ago. I was a TD and python scripts programmer. That's why you have spacebar menu ( similar to this in Maya - "Hotbox" ).
Your feedback is so constructive, THANK YOU Man.
- I will correct drawing the lines - I will add a blinking cursor during renaming of the node - I will correct the query node to have input and output
So definitely there is lot of work to do. Deadline for these 3 - Thursday.
I used to work for Visual Effects industry 7 years ago. I was a TD and python scripts programmer. That's why you have spacebar menu ( similar to this in Maya - "Hotbox" ).
Your feedback is so constructive, THANK YOU Man.
>Your feedback is so constructive, THANK YOU Man
I'm glad you take criticism so well :)
> I am not an UX designer to, so maybe this is the reason of bad UX and UI.
UX design is a bit like programing: if you just do stuff and never test it it's unlikely to work. The single most valuable thing you can do for UX is to grab somebody from your target group and let them use your program. If you don't explain and don't comment, you can watch how they will struggle with things you thought would be obvious. Then just change those parts and test with someone fresh until it really is obvious to someone not intimately familiar with the inner workings of the software.
I'm glad you take criticism so well :)
> I am not an UX designer to, so maybe this is the reason of bad UX and UI.
UX design is a bit like programing: if you just do stuff and never test it it's unlikely to work. The single most valuable thing you can do for UX is to grab somebody from your target group and let them use your program. If you don't explain and don't comment, you can watch how they will struggle with things you thought would be obvious. Then just change those parts and test with someone fresh until it really is obvious to someone not intimately familiar with the inner workings of the software.
I will try to show it to some project managers and business oriented people. Thanks again!
Be careful not to swing too far in the other direction. Users who are unfamiliar with your tool will immediately just want something easy and obvious. You shouldn’t be afraid of having a learning curve if the user can gain fluidity and efficiency. The tricky part is that learning curves will never survive a five minute new-user review, so you have to find more invested users who are willing to do expert reviews.
User interfaces that are forever stuck in beginner mode are just as annoying as ones that are too hard for beginners to start using. This is especially true for visual programming languages.
User interfaces that are forever stuck in beginner mode are just as annoying as ones that are too hard for beginners to start using. This is especially true for visual programming languages.
Hi I resolved some issues: blinking cursor added, connection possible both ways . Those were issues of
https://github.com/slothking-online/diagram
package, right now I am going to update this dependency in graphql editor :)
Good advice! I definitely don't want to make another layer of abstraction as I answered to another question. Maybe I will think about some examples and on-boarding. I will transfer your response to issues tomorrow :)
I wonder why we're still programming primarily in text - we ought to see more visual editors that operate on top of a source file, where changes to file sync immediately to editor, and vice-versa.
Also, that's the sexiest README I've ever seen.
Also, that's the sexiest README I've ever seen.
I would like to vote against having text rendered into an image in a readme. Screenshots in a readme are one thing, but describing the features and the roadmap of the project in a jpeg(!!!) is ... questionable.
Seconded. Great README.
Thanks guys! I'm part of the team. We were inspired by https://github.com/apex/up :)
I really like the concept, and think that visual programming is a great way to help understand data flows (I'm a big Node RED fan).
I wouldn't make the claim that this is usable by business managers; if one of the goals of this tool is to make it business-focused then you might want to add an abstraction and front-end it with BPMN as that's the general language understood by most folks familiar with process mapping. Check out Camunda's modeler for an example (https://camunda.com/products/modeler/). I have quite a bit of experience in this space as working with business-focused modeling tools and then building the full solution has been my career for the last 5+ years.
I wouldn't make the claim that this is usable by business managers; if one of the goals of this tool is to make it business-focused then you might want to add an abstraction and front-end it with BPMN as that's the general language understood by most folks familiar with process mapping. Check out Camunda's modeler for an example (https://camunda.com/products/modeler/). I have quite a bit of experience in this space as working with business-focused modeling tools and then building the full solution has been my career for the last 5+ years.
Hmm I don’t know how to put it, but in my opinion GraphQL is less complex than BPMN. I have a friend who works a lot with BPMN and for me it’s too complicated. We had been in product market fit with sloth king editor which has an abstraction over APIs. Later many people told us to connect it with GraphQL because many people use it already. I appreciate your opinion, but I think we are going in direction where business managers need to learn new tool. Thank you.
Looks very nice, although having some trouble with it on Linux Chrome browser. Space bar brings up menu but menu moves along with mouse pointer so you cannot select submenus. Saw this behavior running the visualizer on local Linux box and connecting to the live Demo. Running "Version 69.0.3497.100 (Official Build) (64-bit)" on Ubuntu 16.04. Chrome from Windows 10 to live site works nicely.
I’ll check it out on Monday , thanks for suggestion!
[deleted]
This is really cool. We already have a large GraphQL schema that we'd like to make some changes to. It'd be nice to be able to bring in our existing schema to visualize.
If you are just looking for visualization, you can use GraphQL Voyager [1].
Either set it up in your application, or you can use the hosted version passing in the URL of your API (you might need to configure CORS): https://apis.guru/graphql-voyager/?url=%20https://dog-graphq...
[1] https://github.com/APIs-guru/graphql-voyager
Either set it up in your application, or you can use the hosted version passing in the URL of your API (you might need to configure CORS): https://apis.guru/graphql-voyager/?url=%20https://dog-graphq...
[1] https://github.com/APIs-guru/graphql-voyager
Thanks for the tip! I’ll give that a shot
Thanks for feedback. I'm adding that to our list!
On a related note, can someone recommend a good modern library to build similar visual block editor? Blocky is good, but it shows its age. Preferably not depend on React.
You build the graph from right to left (unusual but ok), but if you try to actually draw your lines from right to left they don't connect, you have to draw them left to right.
To rename something you click the element and type the name. Fairly straightforward, except that the interface gives no indication that this is possible. No blinking text cursor or anything of the sort.
The "arguments" category actually has nothing to do with arguments, it's just "use stuff you named previously". Why is that not something that's connected on the graph?
Oh, right, that's because of the way queries/mutations work. The name of the query is combined from the name of the query node and the name of the output node. But instead of a query having two connectors, one for input and one for output, it just has everything at a depth of one as outputs, and the child nodes of the output are the inputs (actually, that's how types and everything else works too). I certainly wouldn't have guessed that.
Compare Blender's node editor: https://code.blender.org/wp-content/uploads/2012/01/node_gro...
Anyone can look at a screenshot of Blender's editor and knows what's going on: labeled connectors, no magic with different layers, etc. Creating them is also straightforward. In comparison, if you show a graph from this tool to a random developer that works with GraphQL he/she likely won't understand what schema the graph is supposed to represent.