Posts labeled "Graph Drawing Contest"

‘Game of Thrones’ Relationship Graph

yFiles for HTML layout Graph Drawing Contest

Popular Blog Posts

yWorks releases version 2.2 of yFiles for HTML!

With the new 2.2 release of yFiles for HTML yWorks again proves to be the leading provider of professional high-quality graph diagramming software libraries. The new release contains new features, unmatched in the industry, that will both delight existing customers and will open the product to a wider audience range.In this post I want to talk about some of the highlights that we included in the new 2.2 release. Since the focus is mostly on new features, for those looking for a more general introduction to the library and its capabilities, we suggest to take a look at the features page, instead.We always make sure that any major new release brings improvements and new features to all areas of the product: There are less visible improvements that developers will benefit from, but also end-user visible features like improvements to automatic layout, and several improvements relating to the visual and interactive API parts. Still the API has remained stable and mostly backwards compatible to older releases. Both, developers new to yFiles and existing applications can benefit from the new release.Improved and New Demos Of course, we also improved and reworked many of the demos and also added some more for you to get inspired from. Here are some of the new demos and feature updates: Improvements for Automatic Layout Of course, the 2.2 release contains some features for our most flexible and most widely used graph layout algorithm for hierarchically structured graphs. But there are also nice improvements to the generic edge routing algorithm and the generic tree layout styles. Hierarchic Layout Improvements For the very wide layouts in flat hierarchies, there is now a perfect option to produce more compact bus-like drawings for the successors and predecessors of specific elements. As can be seen in the example, such an arrangement is especially suitable for star-like substructures (i.e., a node connected to multiple nodes with degree one) which can otherwise consume a lot of space and make the layout less compact. The new layout results in better legibility for the labels and makes better use of the screen real-estate in typical use-cases. Edge Router Improvements The generic edge routing algorithm can be used in those situations where the locations of the nodes are fixed and where there is no layout algorithm that does not perform an integrated edge routing along with the arrangement of the nodes. For the edge routing algorithm, two major new features have been added to the release:Integrated Labeling Integrated edge labeling allows the algorithm to choose edge routes that consider one or more labels and their size of an edge. This ensures perfect legibility of even longer labels. If necessary, the edge will be routed using a different path so that it passes through areas that can hold the label's visualization without producing overlaps.Support for Bus Structures In addition, we added support for bus structures to the generic edge routing algorithm. The routing of such buses is like the results produced by the bus routing algorithm and combines the routes of multiple edges that form a bus. Also, the edge routing algorithm is able to optionally consider user-specified bus locations and provides more options for solving other constraints.More Tree Layout Variants Our versatile tree arrangement algorithm received a number of new arrangement strategies. The first one supports the distribution of nodes into multiple branches (a kind of vertical bus) that are placed next to each other. Of course, any orientation and distribution is supported by the implementation and the strategy can be applied to parts of the diagram, only. The second new strategy is based on the existing grid placement facility and allows to create a symmetric bus-style featuring multiple rows or columns respectively.RUN DEMOView and Interaction There are many smaller and incremental improvements for the view and interaction part in yFiles for HTML 2.2. We both increased performance in many areas of the visualization and added more customization options for the developers to choose from.More Built-in WebGL Rendering OptionsWebGL had been added to yFiles for HTML with the 2.1 release as an optional third rendering technology, next to SVG and HTML5 Canvas. The 2.2 release now provides more WebGL visualization options out of the box. For the visualization of very large networks, the overview visualization, the grid visualization, and the visualization of the default manipulation handles can now be rendered using either SVG, Canvas, or WebGL, bringing together the strengths of the three technologies in a single diagram visualization.Hide DescriptionOpen in yEd LiveDownloadAdvanced CSS Styling and AnimationFor the 2.2 release we made it significantly easier for the developer to change the default color schemes and the animations for the various controls in the diagram: Tooltips and the integrated label text editor can now open and close using sophisticated CSS3 animations with minimal effort. The coloring and styling of handles, selection, focus, and highlight indicators, as well as the selection marquee is now as easy as changing a line of CSS code.RUN DEMODeveloper Highlights With every release we improve the productivity of the developers working with our software library. This means not only adjusting to new trends in the web development world, but also improving the way our APIs work and how the huge amount of features our libraries offer can be combined by software developers to create new, fascinating end-user applications.ECMAScript Modules Loading The last release paved the way for ECMAScript module loading , and it has proved to be a blessing for modern web development and the support in web development IDEs has improved dramatically for this technology. In this release we switched the complete documentation to use the more concise syntax throughout the code, samples, tutorials, and demos. All demos and existing code snippets have been rewritten and refactored to use ES modules, and we added tools that help with the automatic migration from older module loading systems to ES module loading and the other way around.import { GraphComponent, GraphEditorInputMode, ShapeNodeStyle, HierarchicLayout, } from 'yfiles' const graphComponent = new GraphComponent('#graphComponent') graphComponent.inputMode = new GraphEditorInputMode() const graph = graphComponent.graph const blueNodeStyle = new ShapeNodeStyle({ fill: 'blue', shape: 'ellipse'}) graph.nodeDefaults.style = blueNodeStyle graphComponent.morphLayout(new HierarchicLayout()) yFiles for HTML as a Node Module With the growing popularity of CLI tools like create-react-app , Angular CLI , Vue CLI , and other webpack and rollup.js based tools, the support for node and npm modules also improved a lot with the various JavaScript and TypeScript IDEs. yFiles for HTML 2.2 can now be bundled as an npm module, making integration into a large amount of build systems as easy as writing npm install --save yfiles. Currently, yFiles for HTML is not available on any public NPM repository and instead needs to be installed once, in a private repository, first.Integrating yFiles for HTML into a build tool-chain becomes almost trivial with the node module support Setting up a new project now barely requires any configuration steps anymore and code completion, build-optimization, and source code transpilers work out of the box with both TypeScript and JavaScript projects.{ "description": "My custom yFiles for HTML App", "private": true, "name": "yfiles-diagramming-app", "version": "1.0.0", "scripts": { "production": "webpack --mode production", "dev": "webpack --mode development", "start": "webpack-dev-server --mode development --open" }, "devDependencies": { "@yworks/optimizer": "^1.0.0", "webpack": "^4.22.0", "webpack-cli": "^3.1.2", "webpack-dev-server": "^3.1.10", "babel-loader": "^8.0.5", "@babel/core": "^7.4.0", "@babel/preset-env": "^7.4.2" }, "dependencies": { "yfiles": "git+https://yguy@repository.internal/npm/yfiles.git", "@babel/polyfill": "^7.4.3" } } Starting with this release we provide a webpack plugin that automatically optimizes, obfuscates, and minifies the yFiles library in production mode. We also worked hard on making the library more resilient against overly-aggressive tree shaking implementations. The chances that a buggy optimization tool-chain now breaks the functionality have been reduced and unused yFiles modules are automatically stripped from the build. We restructured the ES-modules so that now every type is available from a top-level yfiles module, making it much easier to use the available functionality.Hundreds of New Code SamplesWe worked hard to ensure that the most important parts of our API now contain code snippets and example usage code that is accessible right from the API browser and via code completion in the IDEs. More than 600 new code snippets have been added to the documentation, totaling in more than one thousand code snippets.SHOW APIFor the new release more than 1000 code snippets and examples have been added or rewritten We also updated our YouTube Playlist for Developers, of course, to feature the newest versions of APIs and tool-chains.Enhanced Collection APIGraphs are all about data and working with the elements in the data structures has always been key to the API. All collections of elements in the yFiles data structures (lists, sets, maps, collections of nodes, edges, ports, labels, bends, adjacency lists, etc.) now support additional functionality to perform frequent tasks like grouping, filtering, sorting, mapping, reducing, flattening, projecting, combining, etc. with a concise and efficient API:const widestNodes = graphComponent.graph.nodes // group nodes by their width .groupBy(n => n.layout.width, (width, items) => ({ width, items })) // and order the groups by their size .orderByDescending(entry => entry.items.size) // consider the largest two groups only .take(2) // and take all their items .flatMap(entry => entry.items) Stream-lined Graph Algorithm APIyFiles always provided the broadest range of efficient graph analysis algorithm implementations for the web platform. But the API wasn't as easy to use as the layout API and parts of it required advanced algorithm knowledge. The new release contains a completely new facade to the existing algorithms, making configuration, execution, and result interpretation consistent and simple. The new API makes it easy for developers to leverage the power of graph analysis algorithms for their visualization, layout, interaction, and analysis purposes.// configure the shortest path algorithm const algorithm = new SingleSourceShortestPaths({ // single source source: startNode, // add edge cost mapping which returns the actual length of the edge costs: edge => edge.style.renderer .getPathGeometry(edge, edge.style) .getPath() .getLength() }) // run the algorithm: // calculate paths from startNode to all nodes in the graph const result = algorithm.run(graph) // for each end node for (const targetNode of targetNodes) { // set its distance to the startNode as label text graph.setLabelText(targetNode.labels.get(0), `${result.getPathTo(targetNode).distance}`) // and mark the edge path from start to the end node for (const edge of result.getPathTo(targetNode).edges) { graph.setStyle(edge, highlightPathStyle) } } The new API makes it easy for developers to leverage the power of graph analysis algorithms If you haven't done so, go ahead and evaluate yFiles for HTML, today! Happy diagramming!EVALUATE NOW

yFiles and Neo4j: Custom Visualization Solutions

Neo4j is great for storing and processing large amounts of connected data. For example, in web analytics, where click-paths and custom events get logged, it is easy to get that data into Neo4j. Once the data is in the graph database, complex queries may be executed that help both site administrators and site owners get a good understanding of how their users and visitors use the website or ecommerce store.Sure, the results are used to improve the predictions of recommendation engines. Gut with that knowledge, shop architects can also then optimize the structure of their sites and further optimize customer experiences.However, one aspect that is often overlooked is how the visualization of graphs helps in understanding the query results and the automatic decisions of recommendation engines, as well as in planning for optimizations of customer journeys.The Neo4j browser is an invaluable tool for experimenting with Cypher queries and refactoring the schema of your database contents. The developer tool also comes with a visualization component that displays query results in a graphical manner.The simple, low-level interface is great for developers, but less technically inclined end-users prefer less-generic, highly-customized solutions that suit the exact requirements of their specific use-cases.There are several aspects that need to be considered to get the most out of data visualization and the best end-user experience:Rich VisualizationBeing able to visualize connected items and their properties in diagrams helps a lot in understanding the data and processes. For the best user-experience rich element visualizations should be used. Many generic solutions provide a master/detail view of the graph, where mainly the structure of the visualization is presented in one part of the screen. The details behind each of the elements are seen in a separate, mostly textual detail window beside the main visualization. This quickly becomes difficult to use once the diagram is explored in more detail. Users have to manually select each of the elements one by one to find more information about the element. Exporting such a diagram for reports becomes almost impossible, because the detail information is missing from the visualization or is only available for a single element. With rich item visualizations, more information can be put into the diagram and included in the visualization for every element on the screen or later in the report. For example, in a customer journey diagram, not only the name or ID of the page could be shown in the visualization, but also numeric data like “time spent on page,” “drop-off-rate,” “average page value” and “number of visitors.” These values can be added to the visualization of each element. They don’t need to be represented as naked numbers either, but data can be implemented via color-coding, gauges, level-meters, varying sizes and so on. Of course, auxiliary textual data is displayed just as well as one or more badges that indicate a certain state of the page or event (“high-performer,” “needs-attention,” “data-anomaly”). These techniques result in drastic improvements in the user experience. Just like in Neo4j, where different node labels depict a different type of entity in the database, the visualization should make it easy for the user to tell the difference between the different kinds of elements. Not all elements need to follow the same visualization scheme. Instead, the visualization should make it easy for the user to recognize which types of elements are visualized.Sometimes there is a problem with having many details shown inside the visualization: If the number of elements in the diagram or on the screen gets large – if the user needs to zoom out of the diagram to understand the bigger picture – that additional information can become distracting and make the graph impossible to decipher. In this case, sophisticated visualization solutions can use a technique called “level of detail rendering.” Depending on the number of elements on the screen, or the zoom level, element visualizations of varying detail can be employed. Once the user zooms into the diagram, more information becomes visible. If the visualization permits, switching between those levels can be animated, resulting in smooth transitions between the various levels of detail. Arranging Elements MeaningfullyAnother aspect to diagram visualization, that’s just as important as how to render the elements on the screen, is where to place those elements. For many applications, the location of the elements in the diagram can encode additional information for the user right into the visualization. Simple solutions only try to reduce the distance between elements that are interconnected by relations. More advanced placement algorithms can encode additional information into the layout of the diagram. That information could be importance or a total ordering of elements. More important elements could be rendered on top of the drawing. Or, if there is a flow of data or goods, a common main direction of the connections in the diagram helps a lot in understanding the flow through the data.But there are more subtle things than flow and order. Alignment and different connection routing styles help just the same – not all relationships must be visualized by an arrow pointing from one element to another. Especially for hierarchically nested structures and relationships, using container visualizations or partitions in the background often are the better choice and lead to less cluttered, more enjoyable diagrams. Sometimes there isn’t a single aspect or layout that suits the application domain, and sometimes the diagrams’ contents change over time. For these scenarios, it’s important to have versatile layout algorithms, as well as smooth transitions between the various visualizations. The latter helps the users keep their mental maps of the diagram data. Watching the animations is a pleasure, too.Interaction and AnimationFinally, interactivity is king when it comes to complex visualizations. If you can give the user the option to interact with the visualization, they will not only enjoy navigating and exploring the database; they will be able to do this a lot more efficiently, too.This is not just about being able to pan the drawing area. Even for the simple use-case of exploration, things like mouse-hovers, highlights, tool-tips and context menus, contextual filters, guided view port animations, etc. can improve the user-experience dramatically. A Perfect Match: Neo4j and yFilesNeo4j is the right tool to store and query your data, and the built-in browser is great for developers. For end-user facing applications, more elaborate visualization solutions should be used. For connected data, the graph visualization library yFiles is a perfect match, since it provides all the possibilities described above.Here’s how yFiles is employed in the above scenarios:With yFiles, you don’t need to just render the raw data in the database. With software-defined mappings you can show more useful abstractions of the data stored in Neo4j.Create perfect item visualizations, specific to the data that will be displayed on the screen. Level of detail rendering and custom reactive displays of the data result in easy-to-understand-and-follow diagrams and visualizations.With the right layout, the structure of the data and their dependencies and relationships can be highlighted. Clever edge-routing and labeling algorithms ensure that no information is hidden behind other items. This removes the need for the user to manually untangle the diagram. The yFiles library comes with the most complete set of diverse automatic layout algorithms for you to play with and choose from.Interactions and built-in animations help the user understand and navigate the diagram more easily and increase the user-experience.You can add user interactions and the ability to edit both the structure and the properties of the diagram. Let interactions trigger updates in the Neo4j database or in external systems.Embed the visualizations into new or existing end-user applications as a white-label solution. Create standalone applications or integrate the functionality into larger dashboards and tools. It is important to understand that yFiles is much more than an off-the-shelf application with only limited customization options. yFiles is a powerful tool for developers to create applications that meet even the most advanced requirements. Explore the demos and download yFiles today and enjoy the endless possibilities you get when combining it with the power of graph databases like Neo4j. Happy diagramming!

‘Game of Thrones’ Relationship Graph

Every year, the Graph Drawing conference organizes a contest which sets the task to visualize predetermined graph data. This year, the data consists of a graph that presents the relationships between 84 characters from the popular TV series ‘Game of Thrones’. Since our yFiles diagramming library is designed to arrange and visualize graph structures, we decided to participate in the contest. The image above shows a preview of our contribution. Read on if you want to find out how we created it or skip to the final result.Getting to know the dataFirst, we used yFiles to quickly parse the provided GraphML file into a graph in which each node represents a character and each edge between two characters indicates a specific relationship.Hide DescriptionOpen in yEd LiveDownloadApplying different yFiles layout algorithms to the graph provided insight into the overall structure of the connections. However, the data contains more information which is not depicted in these standard views:The full name of each character, its affiliation to a house, family, or group, and whether they are alive or deceased.The type of relationship; this can be a killing, an allegiance, or a family tie. In the latter case, the type further differentiates between spouses, parents, siblings, and lovers.In addition some parts of the graph are tightly connected which surely makes it difficult to follow the paths of the connections.Introducing structureSo how do we restructure the data such that a more structured arrangement can be achieved?Since the story of the TV series is all about different families and groups which are competing for power, we decided to divide the characters by their affiliation to the different houses/families.We introduced new nodes that represent the houses and connected every member of a house to the respective house node. Allegiances and family relationships between members of two different houses are redirected to the house nodes to keep them from spanning across the whole graph. Furthermore, we sized the nodes according to the number of allegiance edges to which they were incident initially. This makes more important characters easily recognizable.Graph layoutThe next step was to actually find a good way to arrange the data. We implemented a custom layout algorithm on top ofthe available algorithms from the yFiles diagramming library.To emphasize the affiliation of the characters to the houses, we made the algorithm place the house nodes in a circle and arrange the members of a house in the according sector.The families get placed on concentric circles around the center of the inner circle. Children are placed further outside than their parents while we tried to set spouses and lovers on the same circle. Characters that are associated to just one house, like servants, dragons or direwolves, are also assigned to the respective house.There are two characters (High Sparrow, Night King) located outside the sectors because they do not belong to any house and are only connected through a kill.There are three types of edges: family ties, allegiances, and killings. We used different edge routing algorithms for those edges so they became easily distinguishable. Edges that describe family relations or allegiances are straight lines when they appear inside a house sector. Inside the inner circle they get routed in arcs whose thicknesses represent the number of edges between two houses.Finally, the kill edges were quite a challenge. They connect characters from all parts of the diagram and there are many of them. After some experiments, we decided that they must run outside the inner circle. They were implemented as two straight segments and an arc. This way they can easily be distinguished from the other types of connections. Of course, we tried to minimize the number of crossings to make it easier to follow the edges.Styling the diagramCreating a clear arrangement of the characters and routing the connections between them was the first important step. But a diagram where nodes are only simple, colored shapes and edges are black lines with an arc is not really an eye-catcher. Using yFiles with its many styling options we were sure it would be easy and fun to change that situation. The nodes on the inner circle carry the emblem of the house or group they represent. They mark the sector as well as the end points for the inner edges.Characters are visualized using a picture of a person or animal along with their name. The border shows the color ofthe house to which the character belongs by birth.Since there are three different kinds of edges, we decided to give them different colors. Edges that represent family relationships are drawn in the color of the family’s house. In case those edges connect to two house nodes, theychange color in the middle. Allegiance edges are drawn using dark blue, dotted lines, independent of where the edge is located.As previously mentioned, kill edges are routed in different style. To separate them even more from the other edges, they have a dark red color. Their direction, i.e. who killed who, is indicated by port icons. The source is marked with a bloody knife while at the target a skull is shown.The final resultBelow you find the final diagram created by our algorithm which combines all described features.So now that we have a concise layout of the data and also a nice visualization of the diagram elements, what can we learn from the visualization? We think that the diagram provides a lot of information at a glance. Important characters can easily be recognized by their size and by the amount of relations they have. The large, most important houses immediately stand out.Even though someone who is very familiar with ‘Game of Thrones’ will probably not learn something totally new, our diagram makes it very easy and efficient to get an overview over the involved groups and characters.How do you like the results? Let us know! Just leave us a message in the social media or using our contact information.

Automatic Metro Map Generation

Metro maps are a very important tool when it comes to illustrating routes of a public transport system. The history of metro maps or, more generally, transport maps, goes back to the famous 'Tube Map' created by Harry Beck in 1931 which shows the London Underground. Nowadays they exist for almost every larger urban area, making it easy for passengers to quickly gain an overview over the possible routes and reachable stations. Simply put, metro maps consist of stations or stops which are connected by lines. So we thought that they are a perfect match for the visualization using our yFiles diagramming library. Our goal was to automatically generate maps from data retrieved online and to polish the results using styles similar to the ones found in official maps. As the computation of a new metro map layout is quite CPU intensive, the goal was not to create maps in real time.The automatic computation of metro maps is very CPU intensive.Getting dataFirst, we needed to get the transport line data. We solved this by using OpenStreetMap and overpass-turbo which uses the Overpass-API to query data from OpenStreetMap. It allowed us to quickly and automatically query data for public transport systems of any desired area, parse it, and create a yFiles diagram from it. What we got is basically a diagram that shows the transport system in a geographically precise way:Hide DescriptionOpen in yEd LiveDownloadModeling and solving the problemOur maps should satisfy a few general visualization rules, shared by most of the official maps, too. The lines should only be either horizontal, vertical, or diagonal at 45 degrees. Such a line layout is referred to as octilinear. Metro maps must preserve the main geographic character, like the relative location of stations, but they do not need not to be geographically precise. Generating metro maps following these rules is a rather well-researched topic. Our solution follows the approach from Martin Nöllenburg ('Automated Drawings of Metro Maps', 2005). Shortly put, the approach models the problem using a mixed-integer linear program (MIP). The solution of the problem yields the coordinates of the stations.Metro maps preserve the main geographic character, but do not need to be geographically precise.In our implementation we mainly created constraints as proposed by Nöllenburg and applied an MIP solver (via API) to get a solution to the problem.We tried both lpsolve and the CPLEX Optimizer. The latter provided us with good results a lot quicker than the former. The solution of the MIP program is then interpreted and transferred to the yFiles diagram created in the first step, yielding a metro map layout. To improve the runtime and results we applied some additional heuristics, too.Visualizing the resultsNow we already had a metro map drawing, but we also wanted to make it look great. Here, our powerful yFiles visualization API came into play and made it fun to style the metro map diagram. For the lines we use the colors from the OpenStreetMap data, if available. Station nodes are automatically drawn smaller or larger, depending on the number of adjacent metro lines.The last challenge was the labeling of the metro stations (modeled as node labels). This is quite a difficult problem by itself, because in larger maps, there is often little space available for sometimes long label texts. With the help of the generic labeling algorithm (available out-of-the-box from the layout library) this challenge became manageable. To make results more similar to real-world maps, we tried to place labels as uniformly as possible and automatically used word-wrapping if there is little space available for a label.Labeling of the metro stations was a challenge, but easy with yFiles. Looking at our final results, we think that the maps can already keep up with some of the official metro maps! And clearly, the results of our automatic approach could be the base for a designer to further fine-tune the maps in some aspects. But have a look yourself: below you will find some of our results. Click the images to see the complete gallery of scrollable and zoomable high-quality vector graphics metro maps for more than a dozen cities!What do you think? Is this something we should include as an algorithm in yFiles? Let us know! Just leave us a message in the social media or using our contact form. The complete algorithm we implemented here is not currently part of the yFiles library. The labeling and visualization part is included in yFiles, but the linear programming part currently depends on third party software. If you are interested in using the algorithm for your own diagrams, please contact our support team for options.

Visualizing Neo4j Database Contents Like a Pro!

There are two major use-cases for the visualization of data in graph databases like Neo4j: Visualization can help database administrators and developers understand their Neo4j database schema as well as browse the contents and verify their queries using tools like Cypher and the Neo4j Desktop. But not only developers and backend devs can benefit from visualization: Many end-user applications that let the users work with data that is stored in graph databases also benefit a lot from a more visual interface to their data: Hide DescriptionOpen in yEd LiveDownloadEnd-user applications that let the users work with data benefit a lot from visual interfacesCreating a user-friendly, well-performing, and informative visualization for end-users is all but trivial and the simple visualizations that developers use for their tools often simply don't cut it. In this post I am going to present a tool that can help you with that task. With it, you can create high-quality graph and diagram visualizations for end-user applications, that perfectly convey the information contained in your database to the end user. With only slightly more than 60 lines of code we will create an interactive web application that renders a unique diagram of your data. This is what it will look like when used with the movie sample database: Professional Diagramming: yFiles for HTML The tool I am using for this is yFiles for HTML - a generic graph visualization programming library for the web platform that can help you realize those last ten or twenty percent of your requirements that you won't be able to implement with other tools: yFiles is a whole family of graph visualization programming libraries that have been available commercially for various target platforms for more than 15 years now and which are used by companies and corporations around the world coming from a wide range of diverse industries. The variant for the web platform is not exclusively meant to be used as a visualization front-end for Neo4j, however in this post I will show you how well yFiles for HTML and Neo4j play together. yFiles for HTML can help you realize those last 20% of your requirements that you won't be able to implement with other tools The single-page web app that we are about to build uses yFiles for HTML and the Neo4j JavaScript Bolt driver to query your very own Neo4j database. The query results will be displayed in a graph visualization with a unique automatic layout, customized item visualizations and user interactions. To follow the instructions in this post, you can download a free evaluation version of the yFiles for HTML software package and you should have a Neo4j database running that you can use for testing. In this post we are only going to briefly touch the surface of the yFiles API and vast array of possibilities and features that yFiles offers, so if you are interested in learning more, be sure to look at the various demos and online resources, too, or see this YouTube Playlist on that topic. Also, as an existing Neo4j user, be sure to check out the free online Neo4j Explorer web application that will help you visualize your database without all the coding! Let's start coding! We begin by scaffolding a bare minimum WebPack powered ES6-sources-based yFiles for HTML application that does not depend on any third-party software at runtime. We could also be using UI frameworks like Angular, React, VueJS, or anything similar, but for the sake of simplicity we are going to use plain vanilla HTML, here. After unzipping the yFiles for HTML library to some directory in our computer we can use npm or yarn and yeoman to scaffold the application. More detailed instructions are available in a separate screencast. On the console we do: > npm install -g generator-yfiles-app > yo yfiles-app And yeoman will ask you some questions. Here are the answers I chose for this task: ? Application name Neo_post ? Path of yFiles for HTML package C:\Path\to\your\yFilesForHTMLPackage ? Path of license file (e.g. 'path/to/license.js') C:\Path\to\your\yFilesForHTMLPackage\demos\resources\license.js ? Which kind of yFiles modules do you want to use? ES6 Modules ? Which modules do you want to use? yfiles/algorithms, yfiles/layout-hierarchic, yfiles/view-component, yfiles/view-editor, yfiles/view-layout-bridge ? Which language variant do you want to use? ES6 ? Which webpack version would you like to use? 4.x ? What else do you want? WebStorm/PHP-Storm/Intellij IDEA Ultimate Project files ? Which package manager would you like to use? yarn Then yeoman will do its magic and after a few seconds it will have scaffolded a shiny new web application that uses yFiles for HTML and Webpack 4 with ES6/EcmaScript2015 to load, layout, and render a trivial graph that you can edit interactively with the mouse, keyboard, and on touch devices. And this is what the app will look like when we use `npm start` or `yarn start` to compile, serve, and run the code in our browser:You will agree with me that this is not really an outstanding visualization, yet, and what we really want to do is inspect our Neo4j database contents! Introducing Cypher and Bolt To connect Neo4j with yFiles for HTML, we first add the JavaScript Bolt driver to our application. On the console we do: > yarn add neo4j-driver Then in the code we simply load the Neo4j driver by adding the following import statement at the top of the file:import neo4j from 'neo4j-driver/lib/browser/neo4j-web' Make sure you have the credentials and IP address available for the Neo4j database that you would like to explore, because with the next line of code, we can already connect to the database:const neo4jDriver = neo4j.driver("bolt://1.2.3.4", neo4j.auth.basic("theusername", "theS3cr3t")) (Of course, you will need to adjust the IP address, the user name and the password.) We are now going to simplify the scaffolded code first that yeoman created for us. Strip it down so that it looks like this: const neo4jDriver = neo4j.driver("bolt://1.2.3.4", neo4j.auth.basic("theusername", "theS3cr3t")) const graphComponent = new GraphComponent('#graphComponent'); loadGraph(); async function loadGraph() { let nodeResult = await runCypherQuery("MATCH (node) RETURN node LIMIT 25"); } async function runCypherQuery(query, params) { const session = neo4jDriver.session('READ'); try { return await session.run(query, params); } finally { session.close(); } } This will result in a boring empty graph view, because we only queried the database for the nodes, but we are not doing anything with the results, yet. At this point it is important to understand that the core yFiles for HTML library does not know how to interpret the results of a query returned by the Neo4j Bolt connector. However, there are utility convenience classes that will help us with the import of any kind of structured data that we have access to in our JavaScript environment. The data could be fetched from a file, from the network, via REST, WebSockets, or created dynamically on the client and of course, the Neo4j data works with this, too: All we need to have is some understanding of the way the Neo4j response data is structured. For the simple query above the resulting JavaScript object looks like this: { "records": [{ "keys": ["node"], "length": 1, "_fields": [{ "identity": { "low": 0, "high": 0 }, "labels": ["Movie"], "properties": { "title": "The Matrix", "tagline": "Welcome to the Real World", "released": { "low": 1999, "high": 0 } } } ], "_fieldLookup": { "node": 0 } } We can use the following Bolt JavaScript API to obtain an array of all the nodes queried: const nodes = nodeResult.records.map(record => record.get("node")) Now that we have the nodes, we can use the convenience class GraphBuilder from yFiles to get the graph onto the screen: graphBuilder.nodesSource = nodes graphBuilder.buildGraph() That was easy! But the result still leaves a lot to be desired from a visual and interactive perspective: Let's improve that: we assign a nicer style for the node visualization and a simple label mapping: If the node has a property named "title" or "name" we use this for the label. And instead of leaving all nodes at the default location, we apply an automatic layout algorithm to arrange the nodes nicely on the screen. import {GraphBuilder, GraphComponent, ShapeNodeStyle} from 'yfiles/view-component' import 'yfiles/view-layout-bridge' import {RadialLayout} from 'yfiles/layout-radial' graphBuilder.graph.nodeDefaults.style = new ShapeNodeStyle({shape:"ellipse", fill:"lightblue"}) graphBuilder.nodeLabelBinding = node => node.properties && (node.properties["title"] || node.properties["name"]) graphBuilder.buildGraph() await graphComponent.morphLayout(new RadialLayout()) The graph looks nicer, now, but we still don't see any relations. Let's change that with another query to the database! We query all the edges between the nodes that we have queried before using this code:const nodeIds = nodes.map(node => node.identity) const edgeResult = await runCypherQuery( `MATCH (n)-[edge]-(m) WHERE id(n) IN $nodeIds AND id(m) IN $nodeIds RETURN DISTINCT edge LIMIT 100`, {nodeIds}) This is what a result looks like in JSON form:{ "identity": { "low": 7, "high": 0 }, "start": { "low": 8, "high": 0 }, "end": { "low": 0, "high": 0 }, "type": "ACTED_IN", "properties": { "roles": ["Emil"] } } As you can see, the relationships reference their source and target nodes via the identity property that was attached to the nodes. We can use the toString function provided by Bolt, to obtain a representation of the identities that can be consumed easily by GraphBuilder. We tell the helper class to use this information to resolve the connections end points and build the in-memory graph for the display: const edges = edgeResult.records.map(record => record.get("edge")) graphBuilder.edgesSource = edges graphBuilder.sourceNodeBinding = edge => edge.start.toString() graphBuilder.targetNodeBinding = edge => edge.end.toString() graphBuilder.nodeIdBinding = node => node.identity.toString() Putting it all together this is what we have now in our loading function:async function loadGraph() { let nodeResult = await runCypherQuery("MATCH (node) RETURN node LIMIT 25") const nodes = nodeResult.records.map(record => record.get("node")) const nodeIds = nodes.map(node => node.identity) const edgeResult = await runCypherQuery( `MATCH (n)-[edge]-(m) WHERE id(n) IN $nodeIds AND id(m) IN $nodeIds RETURN DISTINCT edge LIMIT 100`, {nodeIds}); const edges = edgeResult.records.map(record => record.get("edge")) const graphBuilder = new GraphBuilder(graphComponent.graph); graphBuilder.graph.nodeDefaults.style = new ShapeNodeStyle({shape:"ellipse", fill:"lightblue"}) graphBuilder.nodesSource = nodes graphBuilder.nodeIdBinding = node => node.identity.toString() graphBuilder.nodeLabelBinding = node => node.properties && (node.properties["title"] || node.properties["name"]) graphBuilder.edgesSource = edges graphBuilder.sourceNodeBinding = edge => edge.start.toString() graphBuilder.targetNodeBinding = edge => edge.end.toString() graphBuilder.edgeLabelBinding = edge => edge.type graphBuilder.buildGraph() await graphComponent.morphLayout(new RadialLayout()) } And this is what the visualization looks like in the browser:We still need to work a little on the interactivity, the layout, and the visualization. Right now, we are hardly any better than most other tools. Let's say we want to show some details in a tool-tip, let the user select elements and react to clicks in the graph. For this we add the so-called GraphViewerInputMode to our component: const inputMode = new GraphViewerInputMode() graphComponent.inputMode = inputMode This enables the user to select elements, pan around conveniently, and use the keyboard to navigate the graph.We can now also easily specify rich tool-tips for our elements: For this we use the information that the database provided us with and we list all the properties in a very simple HTML list:inputMode.addQueryItemToolTipListener((sender, args) => { if (args.item && args.item.tag && args.item.tag.properties){ args.toolTip = `<ul> ${Object.entries(args.item.tag.properties).map( e => '<li>' + e[0] + ' : ' + e[1] + '</li>').join('')} </ul>` } }) And in order to better understand the structure of the graph, we add the option for the user to center the layout around a given item that she double-clicks:inputMode.addItemDoubleClickedListener(async (sender, args) => { if (INode.isInstance(args.item)){ args.handled = true; const radialLayoutData = new RadialLayoutData() radialLayoutData.centerNodes.items.add(args.item) const radialLayout = new RadialLayout() radialLayout.centerNodesPolicy = "custom" await graphComponent.morphLayout(radialLayout, "0.5s", radialLayoutData) } }) That's it. Check out the final code, again:I guess you can see that with only very little customizations you are now able to adjust the Cypher queries to your specific databases and create rich, interactive, visualizations of your data! That's it already for this very short introduction on how to use yFiles for HTML to visualize your Neo4j databases. You will find a commented version of the sources for this demo on GitHub. What next? Of course, there is a lot more functionality that has not yet been covered in this post. Take a look at the many online demos for yFiles for HTML to get an idea what else you could do with the yFiles libraries and Neo4j! I leave it as an exercise for you to improve the visualization to look like this :wink:: And to give you more ideas about the possibilities, with some coding, yFiles for HTML, and Neo4j you can: use WebGL, Canvas, and SVG together with templating and databinding to create richer visualizations with animations and just the right information your users require connect to third-party data-sources and services to enhance your visualization with live data and let the user trigger actions in remote systems when interacting with the visualization embed the graph visualization as a white-label component into your very own apps, possibly using Angular, ReactJS, VueJS, or whatever framework you prefer interactively explore the database and incrementally add new elements to the visualization using incremental automatic layouts use different, more compelling layout styles and provide more sophisticated layout constraints to highlight certain structures, components, or elements in your dataset in the visualization use nesting, filtering, and drill-down techniques to let your users interactively explore your data enable users to edit your graphs using the mouse, keyboard, pen, and touch devices So, what are you waiting for? Go and visualize your Neo4j database like a pro! Happy diagramming! This post was originally posted on Medium in cooperation with our friends at Neo4j.There is a screen-cast available on YouTube that goes through the steps in this post.