Improving the Gephi User Experience

This is an effort to rethink the design of Gephi authored by Donato Ricci, co-founder of Density Design and senior designer at the Sciences Po médialab in Paris, and me, creator of Gephi and an engineer at the same lab (note that I am not Mathieu Bastian, our lead developer and actual powerhouse of the project for the past 10 years).

While this text presents possible improvements and practical solutions, it does not address practical considerations of available labor. Also, be aware that this is not a formal roadmap for future releases but rather a way to open the current state of our reflections for brainstorming. So feel free to share your ideas and comments with us.

There are five main categories that structure the improvements that we currently envision:

  • Design strategy: Ensure that a coherent design philosophy is applied across the entirety of the project
  • User interface: Identify and correct user-facing errors
  • Network-focus: Re-focus design and architecture around the network’s position of primary importance
  • Filling in the Gaps: Providing expected functionality
  • Miscellany: Other minor issues

In addition, we have drafted a UI mockup illustrating some of our propositions.

Design strategy

Gephi was built by engineers without a comprehensive design strategy. This situation is fairly common: engineers approach design in an ad-hoc fashion learning by trial and errors and through casual user observation but without a formal user-testing protocol. Should the tool succeed, it is mostly because the utility triumphs over the pain of use. Gephi is an embodiment of this phenomenon in its current state. Some computer scientists may find it simple, partly because using terrible interfaces is a part of their job, but for many users Gephi is confusing. Geeks of a masochistic tendency may love the tool as a result of digital Stockholm Syndrome, but the bulk of users that could benefit from Gephi find it to be confusing and opaque. In our defense, developing desktop applications is heavily constrained and the Java technology was not helping us to overcome this difficulty. What could a designer do to alleviate this situation? Apply a strategy.

A designer does more than treating the symptoms of poor usability; he or she approaches user experience from its fundamentals. Improving Gephi requires rethinking some of its longest standing features from a new standpoint. A design strategy is the solid foundation upon which we build both a satisfying user experience and underlying software architecture.

Our design strategy fits in five basic points: obtaining substantial and organized user feedback, giving Gephi a clear workflow, implementing a facet-oriented interface layout, reordering panels from the user standpoint, and removing unnecessary features. Each point is explained in further detail along with practical guidelines for implementing potential solutions in the future.

User feedback

We cannot build a sustainable user interface without a quantitative measure of user activity. These data are necessary to support and validate design choices. One approach to obtain this information is to log and collect feedback about interface usage.

An optional logger could be implemented in Gephi to allow users to opt-in to the collection of logs in order to improve the software. Data harvesting can be done as a campaign: for example, we may ask some users to activate it for one month to evaluate the usage of a new interface paradigm that we are testing.

A clear workflow

Users need a clear and visible path to start with Gephi, in particular when opening a new file. We need to remove information to allow users focusing on what is important.

Gephi involves not only the software itself, but also the installer, website and documentation. Our ultimate goal is to make the entry process as simple as possible by coordinating these different elements. We begin by focusing here on just the software itself. We propose to consider that there are only two proper ways to enter in Gephi:

  • Opening a file (constructing a network from a pre-generated file)
  • Connecting to a data source (embedded scraper or API connection)

We also need to clarify the roles of the “open” and “import” functions. We have to clarify that:

  • If the user has a file and needs to see it in Gephi, then “Open” is the right answer
  • If the user has an external data source he or she wishes to connect to, there is distinct menu option for this function

Use case: we have observed that some users try to get in Gephi with a table of nodes and a table of links, and do not succeed in finding the right path. The problem there is that it is not explicit that it is necessary to create an empty document, go to the data table, and then import the tables. Since the pattern is “I have files and I want to see them in Gephi”, then the answer should be under the “Open” menu item.

Facet-oriented interface layout

Rethinking overall design has the virtue of allowing for the reorganization of the interface from a user-centric perspective. The current interface relies on the panels system provided by the Netbeans Platform, which provides some beneficial properties for design. We were inspired by Ben Shneiderman’s motto of “overview first, zoom and filter, then details-on-demand” and it has been quite successful. However the different views are not articulated in a coherent way and the features sometimes struggle to find the right place in terms of visibility.

We propose three simple guidelines for a better organization of the panels:

  • The global hierarchy of containers should reflect the generality of the features
  • Some panels are not facet-dependent: they should not change with the facet
  • The network should occupy a single place whatever its facet, since it is always the same object

Panels guidelines

These guidelines have two consequences. First: facet-dependent panels should be contained inside facet-independent panels; which is to say that there is a single container for all facet-dependent features. Second: the facet selector (currently the three tabs on top) has to be inside this container.

We illustrate this with a comparison between a representation of the current layout and a new simplified structure.

Web

Reordering panels from the user standpoint

A part of our design strategy is to reduce visual clutter by grouping panels that are not used simultaneously. Though it is not intuitive, we prioritize separating panels that work well together over grouping similar features. For instance the following panels should be placed in different groups in order to be used combined:

  • Filters + Layout
  • Filters + Partition or Ranking
  • Timeline + almost anything else

With the current panels there are at least three obvious groups: one with filters, another with layout, and the third with the timeline. Generic contextual information is a fourth possible group, but could be placed in a non-intrusive location like the footer. Some panels, like statistics, could theoretically be at home in any group or even as a separate window that could be invoked from a menu.

Collapsing panels concept

Panels and groups of panels create two levels, so the “window” menu should have two levels too.

Removing unnecessary features

Reducing complexity can also be accomplished by removing features. We have detected at least one clear candidate for removal, but we may find more unnecessary complications to remove.

The “preview” panel of Gephi has been increasingly simplified over iterative updates. The goal of this feature is to provide a quick way to export cartographies. Users with competence in design tend to rely on third-party tools that provide finer-grained control over the visualization, like Illustrator and Scriptographer. Thus, the focus in Gephi is to provide a quick way to export images that can be manipulated in other tools.

We propose to further streamline preview functionality by removing some advanced label features: they infrequently used, complicated, and at times internally inconsistent with other preview settings. Furthermore, it is not necessary to facilitate changes to features like label and node size and color when such adjustments can be made much more easily using other tools.

User Interface

Donato Ricci has identified various flaws in the Gephi UI. Fixing them is a priority for the future.

User-centric features: reordering workflow

Users think in terms of results they want to obtain. They have an action in mind and they search how to do it. By displaying features according to their result, we can both improve user orientation and reduce the tool’s learning curve. A few examples of follow.

We propose to aggregate Partition and Ranking under the more accessible term “Appearance”, and to reverse the order of what is asked to the user. The current interface is organized in the following way: if the user has metadata that can rank the nodes then the user can visualize it using different attributes like color and size. The new interface inverts this approach: if the user wants to color nodes then he or she chooses which metadata to use. The panel may progress like a wizard to reduce cognitive load by drawing attention only to information that is necessary for a given step.

Unified panel appearance

Collapsing advanced layout settings

The current design of Gephi does not respect the general principle of drawing attention to information that is commonly used while obscuring information that is infrequently used.

Tools of the Overview: many problems to fix

The small tool buttons on the left side of the overview panel have a number of problems including:

  • Confusing icons that do not easily communicate the use of tools
  • Indistinct icons that do not sufficiently distinguish between different tools
  • Missing tools that are commonly expected

These issues are compounded by evidence that the tools themselves do not provide sufficient utility for common use.

We propose to alleviate some of these shortcomings by putting most of these tools in a collapsed panel and to have a normal panel dedicated to the settings of each tool. We also propose to implement a default tool cursor that draws on common mouse usage paradigms to provide intuitive functionality to users:

  • A click-drag starting on the background (or an edge) of the view makes a rectangle selection
  • A click-drag starting on a node moves this node
  • A click on a node selects the node, the shift key is used for multiple selection
  • A click on the background deselects
  • A set of meta-keys changes the click function, for instance the spacebar to switch to the view-panning tool (i.e. the hand in Photoshop)
  • The secondary-click works the same

Fixing highlight colors

Highlighting works by tweaking colors so that some nodes get more contrast than others. The contrast should depend on the background color, but this is not current implementation. At the very leastthe following should be done:

  • White background: highlighted nodes darker and other nodes lighter
  • Black background: highlighted nodes lighter and other nodes darker

Network-focus

As a network analysis tool, the network itself plays an obvious central role in Gephi. We have explored different ways to incorporate the network into the software’s presentation and have developed some suggestions for modifications that would increase interface coherency.

A different layout for the panels: network as background

In this approach, the network is contained by a “background sheet” and floating panels support functions. Such a philosophy has been successfully implemented in other systems like Photoshop or Google Maps. Using the root panel for the network, like grouping facet-dependent panels, fosters the feeling that we always deal with the same object, the network. This operates on the metaphor that we are always manipulating a primary canvas that consists of the network to be analyzed.

Network as background

Statistics as an invoked panel or window

Statistics tend to be used on demand, and thus do not need to be displayed permanently. Rather, a discrete menu or button could invoke the statistics panel when needed. Removing this visual information leaves more room to focus on what is important, i.e. the network.

Workspaces: more visible, on top

The workspaces need more attention. We propose to show them as tabs on the top of Gephi. It is more natural to have the workspaces above the facet selector in the hierarchy of panels. This is consistent with the prevalence of the “tab” paradigm in the browser space.

Workspaces-on-top

Filling in the Gaps: Providing Expected Functionality

In addition to the different aspects listed above, users need some well-known common features such as an “undo” function, even if they are complex to implement.

History and undo: feasible if limited to network structure

A visible trace of previous steps, like a proverbial breadcrumb trail, provides users with a sense of orientation and confidence when exploring and manipulating data in a speculative fashion. This also accelerates the learning process by alleviating cognitive load by not forcing users to have to remember a series of unfamiliar steps. This works in tandem with an “undo” feature, which facilitates experimentation without fear of permanently corrupting data.

History and Undo are complex to implement and burden the development of plugins and modules as these functions tend to be deeply embedded in a piece of software’s architecture. This partly explains why they are not currently available in Gephi. However a prudent approach in Gephi would be to focus recording and reversal of changes to the structure of the network: Nodes and edges, their attributes (including color, size and coordinates), but not the state of panels such as filters, statistics…

An initial approach would be to cover only a minimal set of modifications of the network structure. The history would then contain information about the type of the modification, but not its exact content nor the way it was done (manually, filter, data table…). For instance:

  • Modifying attribute X for node N / n nodes / all nodes
  • Modifying color / size / position for node N / n nodes / all nodes
  • Adding / removing: node N / n nodes / all nodes
  • Adding / removing: node attribute X / n attributes / all attributes
  • …and the same for links

The history would not include operations such as exporting files, taking screenshots, modification of views, changes to settings, or other changes that did not directly affect the structure of the network

Protecting irreversible operations

Some operations are irreversible: removing nodes, edges and attributes (and possibly more). Because these operations are definitive and may cause the loss of a certain quantity of work, they should be protected. A classical solution is to ask confirmation for any definitive operation. This is a simple guideline but the result is quite user hostile. We propose a better solution, as implemented in Photoshop: when an irreversible operation has been done, when the user tries to save the network the “Save as…” window appears instead and proposes a different name (with a suffix number or “Copy of X”).

Miscellany

A few additional points deserve to be listed, and are done so in no particular order.

Manual versioning

A basic versioning feature would be appreciated: just the opportunity to save with incrementing / adding a number suffix:

  • “My Network.gexf” is saved as “My Network 01.gexf”
  • “My Network 11.gexf” is saved as “My Network 12.gexf”

A common shortcut for this is Ctrl+Alt+S.

Generalizing zoom options (more internal consistency)

We can currently set how the zoom impacts text labels. The same feature would be useful for edges, for instance to keep 1 pixel lines whatever the zoom, as well as for nodes, for instance to keep small points whatever the zoom.

Generalized zoom options

Size nodes according to area

Our eyes perceive areas. Setting a ranking to the diameter of nodes is less intuitive than to apply it to the area of nodes. We propose to offer an option to customize ranking by either diameter or area, but set the default to area.

Removing unnecessary settings about labels

Node labels and edge labels should help the user identifying nodes. However, using the color or size of labels to visualize attributes is confusing. Gephi presently contains settings to manipulate labels in this way, these settings should be removed and replaced with a simpler interface.

UI Mockup sample (work in progress)

We present here a possible approach to integrate some of the different suggestions made in this document. Consider the following image as a way to help imagine the future of the Gephi user experience.

MockupA-01

As we stated earlier, the purpose of this document is to open up the floor to brainstorming ideas about improving the Gephi UX. Please share your ideas in the comments!

PS: Thanks to Niranjan Sivakumar for his excellent proof-reading🙂

13 Comments

  1. I would be against removing features of any kind, especially the node, label, and edge coloring and sizing options in preview. Was the idea for a wholescale redesign of Gephi based on user feedback? The risk is that you don’t know exactly how users are using all of the current features and 90 % of them will not respond to this document. It’s typical nonresponse bias.

    Reply

  2. Thanks, Mathieu and Donato, for the good news and for being willing to work on this. I’m sure hundreds of other people will appreciate it, too. Maurice has a good point, though, about removing features without knowing how much others rely on them. It’s one thing to remove a redundant functions; it’s another to remove functions and expect users to use third-party software to perform that function. I’m not a big user of the Preview Window myself, but I can see how having Gephi (rather than other tools) provide control over node size, node color, and label might be important–especially for big graphs. Perhaps you’re just proposing to use the node size, node color, and node label settings from the other windows.

    On another note, is there a place where people can go to make suggestions for features, functions, modifications, etc., that would be convenient for you and other developers to track? That might be helpful.

    Again, thanks so much for being willing to do this!

    Reply

  3. Having used gephi for a class I have a few comments/complaints
    1) The macOS seems like the only first class citizen in the gephi world. I run linux and many things were either different from the mac version or didn’t work. One example is window scaling which on my smallish (1366×768) dialogs would pop up and need to be enlarged before I could see everything in them.

    2) Why not openJDK? Seriously why can’t I use it?

    3) (General comment) The UI seems… inconsistent. I’m not sure if this is just the linux port or not, but there doesn’t seem to be a common design between all the different modules and the program is just a pain to use as a result.

    Reply

  4. Wish this post was in medium or something similar, more simple to comment🙂

    I really appreciated your willingness to improve the user experience of Gephi, my only fear is that you focus too much on the easiness of use forgetting the core of the software – networks. So, few random remarks that comes in my mind as everyday user of Gephi (and as designer using gephi).

    *on the workflow*
    I would avoid to rework completely the interface: Gephi is one of the few softwares enabling visual network analysis: IMHO its improvements should be focussed on providing more (or better) actions on a network.
    Some patterns, even if awkward, are now widely known, as the ‘import from csv’.
    It would be better to have it under file->import, i agree, but it would be more useful to reduce the needed operations.

    Now you should:
    * create a new document
    * go to data lab
    * import table
    * select node table
    * select the file
    * define the data type for each column (which is really painful, as you need two or more clicks for each column)
    * import the second table
    * select edge table
    * select the file
    * define data columns

    I would try to reduce the number of operations, which is the real pain using Gephi. Painful for two reasons. The first one is the time needed, as often you identify errors in the data after importing, and repeat all the operations. The second reason is that for each action, probability of errors increases.

    *Removing unnecessary features*
    I’d avoid to remove any function, as I have used at least once all the functions you cited.
    Most of the times, i used them to hack/tweak the result making it more simple to edit, for example, in Illustrator.
    In general, I agree on merging “appearance” settings under a unified preview panel.

    A suggestion would be to work on the exported PDF/SVG structure:
    – make text anchor points centered on the node, and the paragraph alignement centered.
    – divide items on levels/groups
    – export a vector legend of used colors

    *Tools of the Overview: many problems to fix*
    +1 for panning with space – it would save half of the time i spend in gephi (well, not really half but it would be a great thing).

    *Generalizing zoom options (more internal consistency)*
    this seems to me a solution more complex than the problem.
    I would keep a unified zoom, while sizes are set with absolute values. already now it is someway complex the relationship among mapping and the exported network.

    What is really missing now is a zoom-based filter of labels, like in sigma. That would help, at least in my workflow. With a very dense/large network, if you enable labels is useless, as they overlay each other, still, if you disable them, is difficult to make sense of the network.

    Reply

  5. I’m glad you are not entirely gone. It might be nice if you released a java 7 compliant version of gephi for mac though…the longer I have to go without gephi, the more I have to look seriously at alternative solutions.

    Reply

  6. I love where this is headed.
    The current GUI really doesn’t allow an optimised workflow: access to functionalities require way too many steps.
    Among the things I would love to see implemented:
    – A fisheye effect on a node’s neighbourhood when you mouse-over.
    – The possibility to combine existing layouts and filters to create custom layouts
    – Dealing with meta-nodes and meta-edges should be (a lot) more intuitive. It’s an extremely useful feature but at the moment it’s a bummer to use
    – Fuzzy meta graphs (so that one can define meta-nodes using fuzzy membership functions)
    – Rule-based dynamic graphs (where you can define the link formation law as a function of time, attributes, graph statistics)

    Reply

  7. I like to leave a contribution to improve the Gephi software.
    How I can fit the labels under the nodes, or aligned on the right, or left… but always out of the nodes.. not over the nodes. Because, the labels like is now, is very difficult to do graphics readable in order to put in scientific articles.
    I’m looking for an option to adjust the text’s labels out of the nodes.
    Can you help me? Exist some solution for this?

    Reply

    1. There is no easy option in Gephi right now. We will consider this feature in the future. Many designers use Scriptographer, a plugin for Adobe Illustrator, to deal with this kind of issue (it requires minimal coding skills).

      Reply

  8. That blog post is a joke regarding your previous one. Is it really reasonable to redesign everything from scratch? Gephi 0.9 will not be out before at lease one year…

    It is already poorly maintained, although you have so many pull requests pending… Why don’t you focus on the current issues, instead of creating new ones?

    You don’t want to make the dev open source and want to keep full control. I think this is a big mistake and goes against the open source philosophy.

    You should take care of all these pending pull requests first, then fix these critical issues. After that, when you have the time, you can start to look at redesigning your tool.

    To conclude, Gephi is dead, and will never be alive again except if the dev core wakes up.

    Good luck, but I’m switching to other tools.

    Reply

    1. Thanks for this critique. We may have missed something when writing this post, since you did not see that our goal is not to keep control but to initiate a new collective effort. I personally think that an effort on Gephi is still worth it, and with a few other motivated contributors we try to do our best. You have my sincere best wishes with alternatives to Gephi, though!

      Reply

  9. It’s great to see that Gephi is still alive (I was clearly wondering), and I hope the 0.9 version will come out very soon!
    I know it’s not the place, but because there the forum is dead i’ll try to get some answer here : can someone tell me of there is a way to compute weighted degree in dynamic graphs? And what is calculated exactly with the Avg. Weighted Degree statistics when the edge weights are in dynamic format?
    Good luck with the project and thanks if someone can reply!

    Reply

  10. Mathieu – Thanks so much for your work on Gephi together with the work of others. I’ve used Gephi to analyze and visualize citation networks and the structure of academic communities. When it works, the program is accessible, relatively intutive, and produces beautiful visualizations.

    Now, as I am trying to teach network analysis to a group of bright undergraduates, I find that the program cannot be loaded on the latest version of the Mac OS, and can only be loaded in Windows with an older version of Java. Further, many requests for help on the web for other problems have gone unanswered. I found your blog in searching for “alternatives to Gephi.”

    My sense is that if you don’t fix what you have (before, or in addition to moving forward), your user base will disappear to other programs.

    A few requests though:

    – as you move forward, it would be great if you could somehow combine batch and interactive mode – so that every step of the creation of a visualization can be more readily reproduced. This is critical for scientific uses.

    – Incorporate the community analysis work of the Hungarian group using the clique percolation algorithm. If your groups could combine forces it would be great; communities generated using this approach are more robust than the Louvain-based partitions in Gephi, and, further, the visualizations in Cfinder are perfect…

    – In an ideal world, this would all be a package for R, too…

    Thanks regardless.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s