text:
21 December 2015 21 December 2015 by Mathieu Bastian
Gephi 0.9 released: Play with network data again
0.9, github, performance, release
We're proud to announce the release of the next major version of Gephi! This 0.9.0 version has been more than three years in the making but today brings an exciting new life to this project, and the graph/network analytics community at large. You can download it here for Windows, Mac OS X and Linux.
Gephi is the leading graph visualization software – known as the "Photoshop for networks" and is open-source and free. It has been downloaded more than a million times and is used by many scholars and data scientists around the world. This new release brings new features in the area of dynamic networks (i.e. network over time) and major compatibility and performance improvements.
Since the last release in 2013, users were facing compatibility issues with Java, which have been resolved with this release. Development had slow down three years ago but had never stopped. In fact, in March 2013 the time had come to think about what Gephi 1.0 would look like and realize it needed a new core. This was by far the most complex project the team had to overcome but developers had a long-term vision and know that future developments will now rely on a robust and extensible core, with world-class performances.
The world is increasingly complex and interconnected. Gephi's purpose is to unfold this complex relational data in a way anyone can understand them. It allows you to visualize graph data as a map and create the visualizations to support your narratives. State-of-the-art algorithms make readable layouts, highlighting communities or influential nodes. Visual tools tweak colors and shapes to reveal hidden patterns in the data, helping solving complex problems. More and more network-maps are pictured in online, offline press and other communication media. They spread from science to business, art and activism. People are increasingly exposed to them and learn how to read them. Gephi aims to accelerate this commoditization process by providing free and easy-to-use tools.
What's new in Gephi 0.9?
The list is too long! The complete changelog for this version can be found on GitHub's release page.
There are a few immediate next steps coming up right after this release. Following-up on the recent plugin development announcement we'll get in touch with plugin developers and start migrating plugins to this version. There's more than 80 plugins to update!
Then, we'll identify and resolve new issues that appeared with this version. A future Gephi 0.9.1 release will come next year to address those.
A Gephi Toolkit release will also be made very soon so developers can update their application built on top of Gephi's modules. In the meantime, we're interested in users' feedback and want to hear from you on Twitter or Facebook. Issues can directly be reported on GitHub as well, where the developers are.
Finally, thanks to all contributors and the community for supporting this project!
Plugin development gets new tools and opens-up to the community
Announcement, Community, Plugins
developer, github, maven, plugin
Since the introduction of the Gephi Marketplace and tools such as the Plugins Bootcamp we've seen more and more plugins being developed. Even developers with little experience with Java give it a try and succeed in creating their first plugin. We want developers to be productive and make it as easy as possible to get started with plugin development and find help along the way. As the release of the 0.9 version is near, it's time to review our plan on that matter and upcoming improvements. Here's the summary:
The gephi-plugins base repository (i.e. repository plugin developers fork) is now using Maven for building and is simpler. It contains only 4 files versus 890 for the Ant-based system.
All Gephi modules are published on Maven central, making it very easy to inspect and extend.
Introduction of a custom Maven plugin designed to facilitate plugin development.
The submission and review of plugins will be entirely based of GitHub, making it more scalable and transparent.
A new online portal for plugins is coming up with an easier edit experience and new features.
From Ant to Maven
Before diving into plugins, let's first review what has changed on how Gephi is compiled, built and packaged – as this directly affects plugins as well. Since the Gephi 0.8.2 version we have migrated our build system from Ant to Maven. This is in line with what the Netbeans Platform (i.e. which Gephi is based on) community recommends. It already has increased the level of automation we're capable of as a result. The main benefits are (compared to Ant):
Maven is great at dependencies management. It's now very clear what version of what library Gephi depends on, making it simpler to integrate. Dependencies are also downloaded automatically instead of being checked in the codebase
Unlike the Ant-based system, it's independent from Netbeans. This allows developers not using Netbeans to develop Gephi and produce a build entirely from the command-line.
Gephi modules can now be placed on Maven Central (i.e. global repository where Maven finds its dependencies). This allows plugins to automatically find the Gephi dependencies online, reducing the manual steps at each Gephi upgrade.
Build assistant
There are a few critical steps we want to help plugin developers with and as a result started the development of a custom Maven plugin. This new tool will work behind the scenes when developers build their plugin. No installation or configuration is needed as it comes already as dependency of the gephi-plugins module. It already addresses common pain points and hope to automate more and more of the steps in the future. This is what it can do as of today:
Plugin validation: The assistant reviews the plugin configuration and metadata at each build. This allows for instance to check if the plugin depends on the correct Gephi version or remind the developer to define an author or license in its configuration.
Run Gephi with plugins: A single command allows to run Gephi with the plugins pre-installed. This makes testing faster than ever when developing plugins.
New plugin generator: A step-by-step command-line tool that creates the correct folder structure and configuration to get started.
In the future, we want to rely on this build assistant to further automate the process and for instance do easy migration or code generation. For instance, you could ask to generate a Layout plugin code and configuration. Afterwards, all needed would be to fill in the blanks in the code.
A new way to review and submit plugins
As the number of plugins grows, it's important to have a clear process how plugins are reviewed and updated. We also want this process to be transparent and open to the community. So far, the process was based on the submission of the plugin binaries with a manual review done by the team. This helped us get where we are today, but we want to get it to the next level and propose to entirely move this process to GitHub – using the pull-request mechanism. This has multiple advantages, listed below:
Reviewing new/updated plugins can scale because any developer can read the code and contribute to the pull requests.
Developers are already asked to fork the gephi-plugins repository so submitting the plugin via GitHub is a natural extension to it.
There's a clear history of each version, comment and what code has changed from one version to another.
It makes it easier to test plugins and detect issues before the plugin is approved.
As part of this migration, we'll no longer add plugins with closed source code but all existing plugins for Gephi 0.8.2 will remain available. For security and stability reasons, it's essential that each plugin's code can be inspected before approval. In order for this to work, all existing plugins not already on GitHub or not forking the gephi-plugins repository will need to migrate. For those already set up, the migration will be easier but Ant-based plugins will still need to migrate to Maven.
To summarize, this is what the new 4-steps process looks like for developers:
In the current submission process we ask for additional information such as description, author or license as well as allow the upload of images. Going forward with GitHub, all of these data will directly be defined in the plugin's configuration making it easier to update.
A new home for plugins (again)
Plugins are currently available online from the Gephi Marketplace, where users could also reach people providing teachings and support. We have ideas on how to improve these community services and will be migrating them to a new architecture, starting with the plugins. We will tell you more about these changes in an upcoming post but for now our focus is on developing a new lightweight plugin portal that can directly be connected with the data source on GitHub.
Here is a preview of what it will look like for plugin pages:
The content of this website will be automatically updated when plugins are published or updated. The way it works is with Travis CI (i.e. continuous integration platform) simply refreshing the JSON file after changes to the plugin repository on GitHub. Developers can even embed images and write the description in Markdown. This will remove entirely the need for plugin developers to login to the marketplace, update NBMs and metadata.
Migrating plugins
This new Maven-based repository along with the new submission process will be introduced with the Gephi 0.9 release. Let's review what plugin developers need to know to bring their plugin to this new major version.
As with all major Gephi release, plugins compatibility needs to be evaluated as APIs may have changed. In fact, given this new version is based on an entirely redeveloped core it's very likely code changes will be required. Hopefully, these changes will often be minor and actually simplify things (i.e less, more efficient code). Documentation will be published on these API changes and core developers will be available to answer questions as well.
Plugin developers will also get contacted regarding moving their code to GitHub with a step-by-step guide. We're considering adding a migrate command to the new Gephi Maven plugin to facilitate the transition from Ant but that's an unfunded project at the moment (if you're interested contributing to that, please let us know). Stay tuned for details right after the release on the path to migration.
And again, thanks for all your hard work on bringing your ideas to life though new Gephi plugins!
4 December 2015 4 December 2015 by Mathieu Bastian
Gephi boosts its performance with new "GraphStore" core
Design, Functionality
0.9, architecture, dynamics, graphstore
Gephi is a graph visualization and analysis platform – the entire tool revolves around the graph the user is manipulating. All modules (e.g. filter, ranking, layout etc.) touch the graph in some way or another and everything happens in real-time, reflected in the visualization. It's therefore extremely important to rely on a robust and fast underlying graph structure. As explained in this article we decided in 2013 to rewrite the graph structure and started the GraphStore project. Today, this project is mostly complete and it's time to look at some of the benefits GraphStore is bringing into Gephi (which its 0.9 release is approaching).
Performance is critical when analyzing graphs. A lot can be done to optimize how graphs are represented and accessed in the code but it remains a hard problem. The first versions of Gephi didn't always shine in that area as the graphs were using a lot of memory and some operations such as filter were slow on large networks. A lot was learnt though and when the time came to start from scratch we knew what would move the needle. Compared to the previous implementation, GraphStore uses simpler data structures (e.g. more arrays, less maps) and cache-friendly collections to make common graph operations faster. Along the way, we relied on many micro-benchmarks to understand what was expensive and what was not. As often with Java, this can lead to surprises but it's a necessary process to build a world-class graph library.
We wanted to compare Gephi 0.8.2 and Gephi 0.9 (development version) so we've created a benchmark to test the most common graph operations. Here is what we found. The table below represents the relative improvement between the two versions. For instance, "2X" means that the operation is twice faster to complete. A benchmarking utility was used to guarantee the measurements precision and each scenario was performed at least 20 times, and up to 600 times in some cases. We used two different classic graphs, one small (1.5K nodes, 19K edges) and one medium (83K nodes, 68K edges) . Larger graphs may be evaluated in a future blog article.
Benchmark / Graph
SMALL (n=1490, e=19025)
MEDIUM (n=82670, e=67851)
Node Iteration 23.0x 34.6x
Edge Iteration 40.1x 109.4x
Node Lookup 1.6x 2.1x
Edge Lookup 1.2x 2.3x
Get Edge 1.1x 1.2x
Get Degree 2.5x 2.3x
Get Neighbors 3.4x 1.2x
Set Attributes 2.3x 0.1x
Get Attributes 3.3x 4.0x
Add Nodes 6.2x 5.7x
Add & Remove Nodes 1.4x 2.9x
Add Edges 7.7x 3.8x
Add & Remove Edges 3.3x 1.8x
Create View 2851.0x 4762.3x
Iterate Nodes In View 2.7x 1.5x
Iterate Edges In View 11.6x 7.3x
Save Project 2.4x 1.7x
Load Project 0.6x 0.6x
Project File Size 1.9x 1.5x
These benchmarks show pretty remarkable improvements in common operations, especially read ones such as node or edge iteration. For instance, in average it takes 40 to 100 times less CPU to read all the edges in the graph. Although this benchmark focus on low-level graph operations it will bring material improvements to user-level features such as filter or layout. The way GraphStore creates views is different from what we were doing before, and doesn't require a deep graph copy anymore – explaining the large difference. Finally, only the set attribute is significantly slower but that can be explained by the introduction of inverted indices, which are updated when attributes are set.
And what about memory usage? Saving memory has been one of our obsession and there's good news to report on that front as well. Below is a quick comparaison between Gephi 0.8.2 and Gephi 0.9 for the same medium graph above.
Gephi 0.8.2
Gephi 0.9
Simple graph 115MB 52MB 2.2X
Graph with 5 attribute columns 186MB 55MB 3.4X
This benchmark shows a clear reduction of memory usage in Gephi's next version. How much? It's hard to say as it really depends on the graph but the denser (i.e. more edges) and the more attributes, the more memory saved as significant improvements have been made in these areas. Dynamic graphs (i.e. graphs that have their topology or attributes change over time) will also see a big boost as we've redesigned this part from scratch.
All of the GraphStore project benefits are included in the upcoming 0.9 release and that's the most important. However, the work doesn't end and there's many more features and performance optimization that can be added.
Then, we count on the community's help to start collaborating with us on the GraphStore library – calling all database and performance experts. GraphStore will continue to live as an all-purpose Java graph library, released under the Apache 2.0 license and independent from Gephi (i.e. Gephi uses GraphStore but not the opposite). We hope to see it used in other projects in the near future.
GraphStore API, represented as a graph
2 November 2015 by Mathieu Bastian
Announcing Gephi 0.9 release date
Announcement, Community
0.9, release
Gephi has an amazing community of passionate users and developers. In the past few years, they have been very dedicated creating tutorials, developing new plugins or helping out on GitHub. They also have been patiently waiting for a new Gephi release! Today we're happy to share with you that the wait will come to an end December 20th with the release of Gephi 0.9 for Windows, MacOS X and Linux.
We're very excited about this upcoming release and developers are hard at work to deliver its roadmap before the end of 2015. This release will resolve a serie of compatibility issues as well as improve features and performance.
Our vision for Gephi remains focused on a few fundamentals, which were already outlined in our Manifesto back in 2009. Gephi should be a software for everyone, powerful yet easy to learn. In many ways, we still have the impression that we've only scratched the surface and want to continue to focus on making each module of Gephi better. As part of this release, we've undertaken one of the most difficult project we've worked on and completely rewrote the core of Gephi. Although not very visible for the end-user, this brings new capabilities, better performance and a level of code quality we can be proud of. This ensure a very solid foundation for the future of this software and paves the way for a future 1.0 version.
Below is an overview of the new features and improvements the 0.9 version will bring.
Java and MacOS compatibility
This release will restore Gephi's compatibility with the latest Java versions on all platforms. This will resolve issues our users encounter with Java 7 and 8. Compatibility issues with Mac OS will also be resolved and full support for Retina display screens added.
New redeveloped core
This release will improve performance and reliability by a large margin. The graph structure at Gephi's core has been redeveloped from scratch and will bring multiple new features, better performance and lower memory consumption. On benchmarks, simple operations such as reading nodes or setting attributes see performance improvements ranging from 2X to 100X. This new core will make many operations in Gephi faster and push the envelope even further in large graphs exploration. Reducing memory usage has also been an area of focus and we have measured a 2X reduction compared to Gephi 0.8.2 on a medium-size graph.
New Appearance module
We're introducing a new user module named Appearance designed to combine and replace Ranking and Partition modules. Appearance will group in one place all controls acting on the node or edge appearance. The partition capabilities will also greatly improve as part of this new module and a new palette selector is being added. In addition of the default palettes, we're also adding a cool palette generator designed to find the optimal colors (i.e. partitions can be differentiated from each other). Moreover, it will be possible to "Auto-apply" partitions as well, which is a feature that was only available for Ranking so far.
Timestamp support
This 0.9 release adds a new way to represent networks over time: timestamps. So far, users could only represent time using intervals and that was cumbersome when the underlying network data was collected at fixed time intervals (e.g. one network per day). Starting with this release, Gephi will support both intervals and timestamps to represent evolving network topology and/or evolving attribute values.
GEXF 1.3 support
The GEXF format is also evolving to its 1.3 version. This version improves the support for graphs over time and introduces the ability to represent time using timestamps rather than intervals. In addition, it's now possible to set a timestamp or an interval for the entire graph, allowing building collections of GEXF files where each represents a "slice". This is a common request from the community and we hope this will greatly facilitate the exploration of longitudinal networks.
Multiple files import
With the 0.9 version users will be able to import multiple files in Gephi at the same time. Once the files have been read, two choices are offered, either to import each file into a separate workspace or merge them into the same workspace. The latter is a powerful option when used with dynamic graphs. Indeed, a collection of GEXF files representing the same network over time will be imported in Gephi in a single step.
Multi-graph support
This release will bring support for multi-graphs, where multiple edges can exist between two nodes each with a different relationship. Users will be able to import, filter and run algorithms on these graphs but the support for visualizing these graphs will come in a further release.
New workspace selection UI
We've heard users' feedback and the workspace selection user interface will be improved. The new interface will be a "tab-style" interface where each workspace is a tab and switching from one workspace to another only requires a single click. Tabs will be located at the top just under the perspective selection. The previous interface is located at the bottom right corner and will be entirely removed.
Gephi Toolkit release
A new release of the Gephi Toolkit, based on the 0.9 version will be made soon after December 20th.
We've done a serious bug squash and already addressed many difficult issues, more to come until the release date.
Follow us on Twitter or join the Facebook group to get the latest news. If you want to know more about this upcoming release, or want to help out please send us a note.
2 June 2015 2 November 2015 by Mathieu Jacomy
Improving the Gephi User Experience
Design, roadmap
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.
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.
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
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.
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.
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.
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.
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.
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.
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").
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.
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.
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 🙂
25 February 2015 25 February 2015 by Mathieu Jacomy
Gephi is asleep and up to awaken
Gephi has been almost inactive since quite a long time: we did not release, we did not fix issues, we did not post on the blog. This lack of recent updates creates an increasing amount of difficulties, including installing Gephi on a recent Mac computer. A lot of users ask if the project is still alive. We understand why you wonder and decided to write this post to explain where we're at and provide to the community a preview of what's next in Gephi's lifecycle.
In short, Gephi is still alive yet asleep, but its reawakening is in sight. However, a series of issues prevents us from doing better right now.
The ambitious yet incomplete 0.9 release
The next planned release is Gephi 0.9 and promises to be a major release with a complete rewrite of Gephi's core module. Performance, and especially memory usage for large graphs has been a lingering issue since the first version of the software. As explained in this article written by Mathieu Bastian – Gephi's lead developer – the solution resides in a more efficient graph structure implementation that we named "GraphStore". This technology brings many new features and significantly reduces the memory usage but is a large development effort and requires all modules to be adapted. Indeed, the module which stores and manages the graph is pretty much used by every other module (e.g layout, filters, preview etc.).
This work on the core graph module was initiated as part of a larger vision focused towards a 1.0 release, which aims to address a much larger set of problems, missing measures and bugs. As you may know, the current version has a various set of problems. Some issues are preventing the normal use of the software, like the difficulties to install it on a recent Mac OS X (Yosemite and Maverick). Others are incomplete or missing features, such as various user interface design issues or the improper management of categories' colors. Finally, some internal problems are hidden in the code but nevertheless real. For example, the technology used to code the user interface (Swing) has been replaced by a more modern technology named JavaFX. For the most part, these problems require a deep rework of the code. The good news is that the most difficult part in this 1.0 vision is probably the rewriting of Gephi's core graph module, which is what the 0.9 version focus on already.
The current 0.9 developments have reached around 80% completion and many modules, but not all, have already been adapted to GraphStore. A stable version can't be released until this reaches 100% and all the modules are converted to the new core implementation. Other important issues such as installation issues on recent Macs have already been addressed in this development version. Finally, a series of bugs will be fixed along with minor features and improvements. Finishing the last modules and releasing the 0.9 version is our current priority.
Like many other open source projects, Gephi's development is for the most part unpaid and remains an activity on the side for all contributors. The notable exception is the Google Summer of Code, which sponsored students multiple years in a row to work on the project. Therefore, the project's progress depends on the contributors' professional and personal situations. Although individuals are ready and willing, time is limited and there was just not enough of it lately to make significant progress. Mathieu Bastian is Gephi's architect and has been behind the software's key iterations since 2007. This time again he holds the keys to its future and has been involved in the GraphStore project. This complex project requires all of his knowledge of Gephi's code and is hardly a task someone else could do at this point. Therefore, a part of our development depends on his free time, and we accept it. This situation is temporary though. Indeed, Mathieu will eventually obtain more time to conclude the work on the 0.9 release and Gephi's development will be less dependent on him in the future.
In addition, we are working on stabilizing some resources in the long run, but our strategy requires a readjustment. Gephi needs time and energy from good java developers, clear-minded designers, and seasoned software architects. We have to entice skilled people, support their involvement and get the best from their contributions. We aim to improve the management of our limited workforce to make the development more attractive and dynamic. This evolution is organized by our team but benefits from external support. For instance, the Sciences Po médialab, the institution I belong to, provides resources for organizing the project, rethinking the user interface and some coding. These changes may not be immediately visible but we're committed for the medium and long term.
Releasing the Gephi 0.9 version is the immediate next step. This version will include compatibility fixes and the whole new core based on GraphStore. Then, an important project to rework the overall user experience will be kicked off. It requires a technology switch (from Swing to JavaFX) and the overhaul of a majority of the modules but aims to make Gephi simpler and more intuitive to use. We already have a good diagnostic of the user experience issues in Gephi but need to explore different designs. In an upcoming blog post, I will explain our thought process on this topic with the help of Professore Donato Ricci, senior interaction designer. Eventually, the 1.0 version will be worked on and released.
Gephi is almost 10 years old. It is usable but still plagued with many well-known issues. Though sometimes frustrating, it allows users to do incredible things. We think Gephi is still relevant to research, journalism, civil society and more. We are going to give it the renewal it deserves.
Mathieu Jacomy
15 April 2013 1 February 2015 by Sébastien Heymann
It's a great news, Gephi has been accepted again for the Google Summer of Code for the 5th year! The program is the best way for students around the world to start contributing to an open-source project. Since 2009, each edition is a great success and dramatically boosted Gephi's project development.
What is Gephi?
Networks are everywhere: email systems, financial transaction systems and gene-protein interaction networks are just a few examples. Gephi began as a university student project four years ago and has quickly become an open source software leader in the visualization and analysis of large networks. It is an important contribution to the ecosystem of tools used by researchers and big data analysts to explore and extract value from the deluge of relational data and disseminate a better understanding for people to think about a "connected" world.
Gephi is a "Photoshop" for graphs: designed to make data navigation and manipulation easy, it covers the entire process from data importing to aesthetics refinements and communication. Users interact with the visualization and manipulate structures, shapes and colors to reveal the properties of complex and messy data. The goal is to help data analysts make hypotheses and intuitively discover patterns or errors in large data collections.
Gephi's project aims at providing the perfect tool to visualize and analyze networks. We focus on usability, performance and modularity:
Usability: Easy to install, an UI without scripts and real-time manipulation.
Performance: Visualization engine and data structures are built scalable. Supporting always-larger graphs is an endless challenge!
Modularity: Extensible software architecture, built on top of Netbeans Platform. Add plug-ins with ease.
Learn more about Gephi, watch Introducing Gephi 0.7, download and try it by following Quick Start Tutorial.
Gephi's project is young, the growing community is composed of engineers and scientists involved in network science, datavis and complex networks.
List of ideas are availabe on our wiki. They cover various skills and level of difficulties:
* Completing Legend module – Complete the Legend module, which was started in last year GSoC.
* GraphStore benchmark and tuning – Optimize and tune GraphStore based on a serie of new well-defined benchmarks.
Please also propose your ideas on the forum. They will be considered and discussed by the community. Have a look at our long-term Roadmap.
Students, join the network
Students, apply now for Gephi proposals. Join us on the forum and fill in the questionnaire. Be careful, deadline for submitting proposals is May 3 (timeline)!
Hélder Suzuki, student for Gephi in 2009 and now software engineer at Google, wrote:
At Gephi students will have the opportunity to produce high impact work on a rapidly growing area and be noted for it.
View our previous Google Summer of Code projects here and read former students interviews.
Follow Gephi on Twitter
5 March 2013 3 February 2015 by Sébastien Heymann
Rebuilding Gephi's core for the 0.9 version
Announcement, Design
0.9, architecture, code, roadmap
This is the first article about the future Gephi 0.9 version. Our objective is to prepare the ground for a future 1.0 release and focus on solving some of the most difficult problems. It all starts with the core of Gephi and we're giving today a preview of the upcoming changes in that area. In fact, we're rewriting the core modules from scratch to improve performance, stability and add new features. The core modules represent and store the graph and attributes in memory so it's available to the rest of the application. Rewriting Gephi's core is like replacing the engine of a truck and involves adapting a lot of interconnected pieces. Gephi's current graph structure engine was designed in 2009 and didn't change much in multiple releases. Although it's working, it doesn't have the level of quality we want for Gephi 1.0 and needs to be overhauled. The aim is to complete the new implementation and integrate it in the 0.9 version.
In November 2012, we started to develop a completely new in-memory graph structure implementation for Gephi based on what we've learnt over the years and our desire to design a solution that will last. The project code-name is GraphStore and we focus on four main things:
Performance: The graph structure is so important to the rest of the application that is has to be fast and memory efficient.
Stability: The new code will be the most heavily unit-tested in the history of Gephi.
Simplicity: The Graph API should be documented and easy to use for developers.
Openness: If possible, we want GraphStore to be used in other projects and keep the code free of Gephi-specific concepts.
Gephi is known to use a large amount of memory, especially for very large networks. We want to challenge ourselves and tackle this issue by redesigning the way graphs are encoded and stored. Besides memory usage, we carefully analyzed possible solutions to improve read/write performance and optimize the throughput. Stability and simplicity are like food and shelter, and whatever we try to do at Gephi should be simple to use and stable. As we're going towards a 1.0 version, we're putting more and more efforts to testing and code quality.
Since November 2012, we have been working on GraphStore separately from Gephi's codebase and will start the integration fairly soon. The Graph API is very similar to the existing API. However, it isn't entirely compatible and several core things changed like attributes, views or dynamic networks and will require a lot of work in some modules. On the other hand, because the GraphStore code is decoupled, it could be leveraged in other projects. For instance, it could serve as a Blueprints implementation as an alternative to TinkerGraph.
Graph structure
A graph (also called network) is a pair of a set of nodes and a set of edges. Edges can be undirected, or directed if the direction of the relation matters. Edges may also have weights to represent a value attached to the edges, like the strength of a connection or the flow capacity. Edges may also point to the same node (i.e. self-loops). Gephi currently supports these features, but they are not sufficient to describe the variety of problems graphs can be helpful with. Multigraphs permit several relationships between nodes and is for instance commonly used to represent RDF graphs. Multigraphs with properties (i.e. ability to attach any property to nodes and edges) have recently become the standard representation for graph databases.
The next version of Gephi will support multigraphs and therefore allow multiple edges between nodes to be imported. The rollout will be done in two phases. The first phase is to allow this new type of graph to be imported, filtered and exported. We will update the importers and add new options to support these graphs. The second phase is to update the visualization and the way multiple edges between nodes look like.
Hierarchical graphs
Since the 0.7 version released in 2009, Gephi has supported hierarchical graphs. Hierarchical graphs let the user group or ungroup nodes so it forms a tree. Nodes which contain other nodes are named meta-nodes and edges are collapsed into meta-edges. Groups obtained from clustering algorithm (e.g. modularity) could also easily be collapsed into meta-nodes in order to study the network at a higher level. We initially recognized the potential of this idea for network analysis and developed a hierarchy-enabled data structure. However, we realized we didn't completely fulfill the vision by not providing all the tools to fully explore and manage hierarchical networks. Although the data structure allows it, the software still lacks many features to really make hierarchical networks explorable.
Recently, we are more focused on networks over time and plan to continue to do so. In the past years, users have shown steady and continuous interest in dynamic networks and we haven't really seen a strong interest in hierarchical networks. Therefore, we propose to remove this feature from next releases. On the developer side, cutting this feature will greatly simplify the code and improve performance.
Dynamic networks
Networks that change over time are some of the most interesting to visualize and analyze. We have heavily invested in supporting this type of network, for instance by developing the Timeline component. However, dynamic graph support was added after the current graph structure implementation was conceived and therefore remains suboptimal and difficult to scale. Now that we have enough hindsight, we can rethink how this should be done and make it simpler.
One pain point is the way we decided to represent the time. Essentially, there are two ways to represent time for a particular node in a graph: timestamps or intervals. Timestamps are a list of points where the particular nodes exist and intervals have a beginning and an end. For multiple reasons, we thought intervals would be easier to manipulate and more efficient than a (possibly very large) set of timestamps. By talking to our users, we found that intervals are rarely used in real-world data. On the code side, we also found that it makes things much more complex and not that efficient at the end.
In future versions, we'll remove support for intervals and add timestamps instead. We considered supporting both intervals and timestamps but decided that it would add too much complexity and confusion.
Graph structure internals
Graph structures design is an interesting problem to solve. The objective is quite simple, yet challenging: how to best represent an interconnected graph so it's fast to query and compact in space? Also, how to keep it simple and serve a large number of features at the same time?
Graph storage
Our goal is to develop a thread-safe, in-memory graph structure implementation in Java suitable for real-time analysis. You may ask how this differs from a graph database or a distributed graph analysis package. In a few words, one can say the requirements are quite different.
Graph databases like Neo4j, OrientDB or Titan store the graph on local disk or in a cluster and are optimized for large graphs and large number of concurrent users. Typically, the networks are much larger than what can fit in memory and these databases mostly focus on answering traversal queries. In the environment where graph databases operate most of the needs can be converted in some sort of traversal query (e.g. friends of X, tweets of Y). Traversal queries are also the reason why graph databases scale to billions of nodes. Indeed, for each traversal, only a subset of the graph is accessed. This is quite different from Gephi, which by its nature of being an analysis software needs to access the complete graph. For instance, when a layout is running Gephi needs to read the X,Y position of each node as quickly as possible. Although reading from the disk can be very quick as well (e.g. GraphChi), it's limited to sequential access and things become more complex that way.
Because of the real-time requirements, we want to keep our graph data in memory accessible at all time. However, we want to make it easy to connect to external data sources, and graph databases in particular.
Reducing overhead
In computer science, overhead is any combination of excess or indirect computation time, memory, bandwidth, or other resources that are required to attain a particular goal.
GraphStore heavily relies on Java primitives, arrays and efficient collections library like fastutil. We are reducing overhead by simply avoiding using too many Java objects, which are very costly. Instead of using maps, trees or lists, Nodes and Edges are stored in large arrays which can be dynamically resized in blocks. For instance, iterating over the graph should be extremely fast because the CPU caches array blocks. This may sounds obvious but performance optimizations are tricky in Java because of the JVM and the uncertainty of what makes a difference and what doesn't. In his "Effective Java" book, Joshua Bloch writes "Don't guess, measure" and that's still true today. For our project, we rely on well-defined micro-benchmarks to see where the bottlenecks are and how to make our data-structure more cache-friendly and more compact in memory. When the graph contains millions of edges, every byte saved per edge can make a large difference at the end.
In terms of speed, we focused on optimizing the most common operations, which are iterating over all the elements and consult nodes' neighbors. Typically, a layout algorithm needs to read the neighbors of every node at each iteration. Neighbors can't simply be an unsorted list because of the removal complexity: to remove a node, you need to know where it is. The current Gephi graph structure uses a binary tree to store the node's neighbors. Although the complexity is logarithmic, every node in the tree takes extra memory and logarithmic complexity is still suboptimal. After isolating the problem in a benchmark, we found that using a double linked-list is the best solution for our requirements and achieves a O(1) complexity, as it fulfills both a quick iteration and quick update. Here is a snapshot of the solution:
Every edge has 4 integer pointers to the next in/out predecessor and successors and a separate dictionary would help to find the right edge based on the source and destination pointers. Each node has a pointer to the first edge in the linked list (i.e the head). Node ids are integers (32 bits) so one can easily create a long->Edge dictionary by encoding the source and destination node into a single long number (64 bits). The diagram intentionally leaves out the multigraph support for simplicity. In reality, nodes can have multiple head pointers, one for each edge type. Each edge type is represented by a integer index.
Views are one of the most useful aspects of Gephi's graph structure and are mainly used behind the scenes in the Filter module. A view is a graph subset (i.e. a subgraph) which remains connected to the main structure, so if a node is removed from the graph, it's removed from the views as well. For instance, when users create a 'Degree Filter', Gephi creates a view and removes all the nodes which don't fulfill the degree threshold. Multiple views can co-exist at any time in the graph structure. In the current graph structure, a node tree complete copy is done for every view and we found that this can be very inefficient.
In the new version, the way views are implemented is very different and should yield to better performance. Instead of doing a copy of the nodes, we maintain bit-vectors for nodes and edges. Because these elements are stored in large arrays with a unique identifier, it's easy to create and maintain a bit-vector. When developers obtain the 'Graph' object for a particular view, the bit-vectors are used behind the scenes to adapt iterators and accessors. This solution should make filtering for large graphs much quicker. One drawback is that whereas the current implementation copies and then trims the view, GraphStore work with bit-vectors but continues to access the complete graph. In other words, if the view represents only 1% of the original graph, it still needs to iterate over the 100% to find which elements are the 1%. Even though this sounds bad, our benchmarks show it's a very fast operation and we win overall because of the reduced overhead of duplicating the graph. Moreover, we can introduce some caching later to optimize this further.
Inverted Index
When you're using the Partition module in Gephi, you're manipulating some sort of inverted index. Nodes and edges have properties like 'gender', 'age' or 'country', and these properties are contained within the nodes and edges objects. An index is a simple data structure which allows to retrieve the list of elements for a particular value. For instance, the partition module needs to know what is the number of 'male' or 'female' nodes for the 'gender' column. When the column is a number like 'age', it also needs to know what is the maximum and minimum value. Unlike the Ranking module and its auto-apply feature, the Partition module is not refreshed in real-time and therefore difficult to use when the graph is changing a lot. We have decided to invest in this feature for the future release and are building a real column inverted index in the graph structure. The index will simply keep track of which values exist for each column and which elements are holding this value. The index will be updated in real-time as elements are added, removed or updated.
The ability to quickly retrieve elements and counts based on specific values will be very useful in many different modules like Filters, Partition or Data Laboratory. New APIs will be added for developers to use the newly created index interface. As we're working on attributes storage and manipulation, we'll also merge the Attributes and Graph API because they are so interconnected that it doesn't really make sense to have them separate. The interfaces that developers are familiar with like Table or Columns will remain the same.
In software programming, events are a common way to inform other modules that something changed. In Gephi, we also use events to convey graph updates events to inform other modules about updated nodes or edges. In the new GraphStore, we'll stop using events to transport graph modifications because of the large overhead due to the creation of event objects. Indeed, when 10K nodes are added to the graph, the existing structure literally creates 10K event objects and puts them in a queue. Although the event queue is compressing objects of the same type, the overhead to create, queue, send and destroy large amount of small Java objects is too large.
Instead of a push model (i.e. the emitter is pushing updates), we want to rather promote a pull model (i.e. the listener pull updates from time to time) for future releases. A similar system is already in place to link the graph and the visualization module and it has been working without a glitch. We'll develop the tools to easily calculate graph differences between a listener module and the graph structure. By removing the bottleneck, write performance should greatly improve.
As said earlier, we'll add timestamps support to represent dynamic networks. Instead of using a time interval, a timestamp array will be associated with nodes and edges. For element (node/edge) visibility, each timestamp represents the presence of the element at that time. For example if a network snapshot is collected every month for a year, each node will have up to 12 different timestamps. The timestamp itself is a real number and can therefore represents an epoch time but also any other value in a different context. For a dynamic attribute, the time+value is simply represented as a list of (time, value) pairs.
To support the timeline and dynamic networks algorithm, we're developing an inverted index for timestamps so we can make time filtering very quick. One good thing about intervals is that it's very easy to know if two intervals overlaps with each other. With a flat list of timestamps, one can't avoid to go through the entire list. The index will essentially map timestamps to the nodes and edges elements in the graph and therefore solves this issue. The Interval tree implementation which we are currently using to store intervals is based on a binary tree and is very costly in memory because of all the Java objects overhead. Using simple arrays should reduce overhead and improve performance for large dynamic networks. When computing a dynamic network algorithm (ex: Clustering coefficient over time), we're using a sliding window over the graph so the ability to quickly filter is critical as it impacts how fast the graph refreshes.
Saving/Loading
Saving and loading the graph structure into into/from a file (or a stream) is another critical feature. When a user saves a project in Gephi, the graph data structure is serialized in XML and compressed into a .gephi file. If you worked with project files in Gephi, you may have experienced corrupted files issues or errors when loading a file. We've done our best to fix these problems but some still remain. We're rethinking how this should be done in GraphStore and are making a call to rewrite the code from scratch. Our approach will rely on a lot of unit tests to make sure the code is stable so we don't repeat the same issues in future versions. Please note that this concerns the .gephi files only and existing importers (e.g. GEXF, GraphML) will remain the same.
Concerning the GraphStore serialization, we're abandoning XML in favor of pure byte arrays. That should yield to better performance and reduced project file size. We'll create a custom reader for previous Gephi versions so you can still open your existing projects. Other modules like Filters or Preview will continue to use XML as it's working just fine.
This is the first post about the Gephi 0.9 version and more will come soon. We're excited about the current developments and hope to hear from you. Please join the gephi-dev mailing list to learn more about ongoing projects and contribute. We need your ideas!
20 February 2013 3 February 2015 by guillaumegcs
A month of Gephi Marketplace
Announcement, Community, Website
marketplace, plugin
Computer Science & Engineering Graduate from the Compiègne University of Technology, Guillaume Ceccarelli has been Gephi's SysAdmin since 2008 and Web Developer since 2012. When he's not by day working in the financial world, he freelances and stays close to ongoing entrepreneurship ventures.
Four weeks ago, we launched the Gephi Marketplace.
Haven't taken a look yet? Didn't know it existed? Take a few minutes to check it out now! It's right here, waiting for you.
Why the Gephi marketplace?
For a long time, we felt like we lacked a central point of access when it came to what everyone was doing to improve or build upon Gephi. On one hand, our forums allowed for discussions to happen but they didn't really enable anyone to share their work easily or to find out about one another. On the other hand, the wiki as well as our main site, served more as official portals to spread the word or to explore knowledge around Gephi, but they didn't seem like a good fit to showcase the work our community was doing.
A little while ago, we decided to fix that.
The spirit behind the marketplace is simple. When we started, our idea was:
To provide Gephi users with easy means to find and learn more about what the community was building for and around Gephi
To give creators and people working with Gephi a way to publish their work and make them known to the entire community, without the overhead of a complex and lengthy process
This meant creating the central point for Gephi Plugins and what we call Gephi Services, which eventually became the Gephi Marketplace.
Before the marketplace existed, plugins were submitted and downloaded through the old plugin center, which required authors and the Gephi staff to go through a tedious process, creating a lot of work and unnecessary frustration for everyone. In addition, the system didn't allow authors to update their own plugin pages, or to submit a different plugin for different versions of the Gephi application, a feature which was long requested before we finally became in a position to deliver it to you.
A new world of plugins
Now, every plugin download, even from the Gephi Application itself go through the marketplace! It means that as soon as a plugin goes live on our new platform, it's directly available to every Gephi user around the world. Even if you haven't made a plugin yourself, chances are you've already used the marketplace without realizing it!
Speaking of around the world, here's a geographic breakdown of Gephi plugin downloads within the past 30 days:
Isn't it impressive? 1169 plugin downloads and every continent is represented! (ok, not every single one. Props to the first Gephi user who'll download a plugin from Antartica!)
It makes us extremely proud to help and foster such a vibrant community of Gephi users around the world. Remember that this map is for the last 30 days alone!
Today, we have 38 plugins listed on the marketplace, and we've made sure you can post your creations as easily as possible. It takes no more than 5 minutes to first fill in the plugin upload form, and we usually get back to you within 24 hours, so you can make your work available to thousands in record time!
A world of services
As briefly mentioned before, we're also listing Gephi Services on the marketplace.
Over the years, we've noticed that a community of professionals and enthusiasts started providing services to the community. We've seen people doing trainings on Gephi, others integrating Gephi into data analysis workflows, or even create studies using Gephi as their tool of choice. We thought it was about time these fine folks got easier to find!
Every service provided by the community, for free or with a fee, is welcome to be listed. We already have a few, and to be honest we would love to see more of them!
Listing the services you provide on the Gephi marketplace is easy, and like with listing plugins it's completely free, regardless of what you choose to charge for your work. We're not here to collect fees. We just want to help other people know about your work, and to help you easily be found and easily be reached.
Following the same simple form submission process you can use for plugins, you give us all the info on what you've got for the community, you click 'upload', we get back to you, and then you have yourself a listing!… Which you can then customize to your liking, and for which you can include every single bit of information you want, and even a great copy! So not only can you let everyone know about what it is that you do, but also how truly wonderful it is to work with you and your expertise. So?
And now back to you.
Any question? Feel free to comment below! We'll be glad to help you get started. And if you'd like to be kept in the know of what's newly getting posted on the Marketplace, the RSS feed is this way.
In the meantime, thank you for your continued trust and your use of Gephi as your Graph Exploration and Manipulation tool of choice! It is our humble pleasure to serve you all.
See you soon on the marketplace! 🙂
12 February 2013 3 February 2015 by Sébastien Heymann
rgexf: An R library to work with GEXF graph files
gexf, library, r, rgexf
George Vega is an economist working at the Chilean Pension Supervisor and cofounder of nodoschile.org. His research interests are Statistical Computing, HPC, Complex Systems and Public Policy.
The first R library to work with GEXF files, rgexf allows both writing (exporting) and reading (importing) .gexf files.
Writing and reading GEXF files
Writing dynamic graphs
Writing graphs with attributes (boolean, numeric, char)
Writing graphs with VIZ attributes (color, size, shape)
Building GEXF graphs from scratch (node/edge by node/edge)
rgexf is written in such a way that it is not necessary to have knowledge about XML.
# Installing from CRAN and loading
install.packages("rgexf", dependencies=TRUE)
library(rgexf)
# Reading lesmiserables graph (and summarizing)
lesmiserables <- read.gexf("http://gephi.org/datasets/LesMiserables.gexf")
summary(lesmiserables)
# Building a GEXF class object (includes data frames of nodes/edges +
# XML representation of it) from two two-column data.frames
mygraph <- write.gexf(nodes=people, edges=relations)
# Exporting to some place
print(mygraph, output="mygraph.gexf", replace=TRUE)
# Creating a GEXF object from scratch (and adding a node)
mynewgraph <- new.gexf.graph()
mynewgraph <- add.gexf.nodes(mynewgraph, id=1, label="George")
The source code plus more examples can be found on the project website.
For suggestions, bug reports or support (any) ask me through Twitter @gvegayon or just write me an email to george [dot] vega [at] nodoschile [dot] org
George Vega Yon


text:
Powell Manufacturing Company (PMC) was a company based in southern California, widely known for its line of motor scooters that peaked in popularity in the late 1940s. From September 1954 to March 1957, Powell manufactured "Sport Wagon" pickup trucks and station wagons.

In the 1960s and 1970s, they manufactured the "Powell Challenger" trail bikes.

The company originally began operations in 1926, and manufactured radios, then moving on to build approximately 1,200 pickup trucks, 300 station wagons, and three motor homes, and tens of thousands of scooters and trail bikes. The manufacturing address was listed as 2914 North Alameda Street in Compton, California, which was two miles south of the General Motors South Gate Assembly factory, and they had a showroom listed at 12700 S. Western Avenue.

History

The Powell Brothers, Hayward and Channing Powell, started manufacturing radios in the mid 1920s, immediately after they graduated from Manual Arts High School in Los Angeles in 1924. Their first company, Winner Radio, produced expensive radios which did not sell well and then inexpensive radios which did.

During 1925, Hayward Powell developed appendicitis, and in early 1926 had an appendectomy. During Hayward's recovery, the brothers took a five-month cross-country trip. When they returned to Los Angeles, they started Powell Manufacturing Company in 1926 to make battery eliminators, soon also making box-style table radios typical of the 1920s.

By 1930 they were part of the reputation of Los Angeles as the "midget capital of the world", making what are now referred to as cathedral-style table radios (midget in comparison to earlier floor-standing consoles and large-box table radios). In 1931 they were also selling the even-smaller "pee-wee" cathedral-style table radios which had become popular. Before they exited the radio business in 1932, they produced an innovative radio that was just nine inches square and thirty-four inches high, which was perhaps the forerunner of the chair-side style radios.

In the mid 1930s, they moved into scooter production. The Powell manufacturing facility in Compton, California, switched to war production in 1942.  After World War II, Powell again returned to scooter production with the C-47, P-48, P-49 step through models. The Powell Streamliner model, used by U.S. Airborne troops during World War II, was copied and served as the basis for the original Fuji Rabbit scooter in June 1946 (six months before the first Vespa scooter).

In 1949, the Powell company moved into the lightweight motorcycle market with the introduction of the P-81 model, which was a direct competitor of the Mustang (motorcycle) produced in nearby Glendale.  All four of these post-war Powell models used the same single-cylinder four-stroke 24-cubic-inch (393 cc) engine which was developed in-house.  Powell again switched to war production for the Korean War in the early 1950s and never returned to scooter production.

PMC was also an early innovator in pickup and SUV design with several models produced in the 1950s using modified 1941 Plymouth chassis recycled from junkyards. The pickup was sold as the Sport Wagon and the SUV as the Station Wagon. Powell's designs were later echoed in the Ford Ranchero and Chevrolet El Camino models which appeared a few years later. Motor Life magazine, in its October 1955 issue (with a photo of the Powell Sport Wagon on the cover), called it "an obvious choice as one of the most interesting and unique automobiles in the U.S." In the February 1956 issue of Motor Trend, magazine co-founder Walt Woron concluded his article: "The Powell Brothers, then, have succeeded in their purpose: to provide a vehicle that '... can't be beat for general utility...[that makes] the perfect runabout or 2nd family car...'".

In the 1960s, the company reorganized as Powell Brothers, Inc., and manufactured the "Powell Challenger" trail bikes. During this period, the company relocated to a larger facility at 5903 E. Firestone Boulevard in South Gate, California. Hayward Powell died in March 1978, and with Channing Powell retired, the company officially dissolved and closed its doors in April 1979. Channing Powell died in 1988.

References

External links
 US Scootermuseum

Defunct motor vehicle manufacturers of the United States
Scooter manufacturers
Minibikes
Compton, California
Consumer electronics brands
Amateur radio companies
Buildings and structures in Los Angeles County, California
1926 establishments in California
1979 disestablishments in California
Vehicle manufacturing companies established in 1926
Vehicle manufacturing companies disestablished in 1979
Defunct manufacturing companies based in Greater Los Angeles
Motor vehicle manufacturers based in California

redpajama_set_name: RedPajamaWikipedia


HARLEY TRIKE AXLE CONVERSION KIT + SWINGARM FITS HARLEY TOURING BAGGER 2002-PRESENT. AXLE COMES BUILT COMPLETE WITH SWINGARM (SWING ARM COMES RAW). POSITIVE TRACTION WITH GEAR DIFFERENTIAL. OVERALL WIDTH: 42.5 WIDE. AXLE COMES WITH 3 DIFFERENT BOLT PATTERNS: 5 ON 4.5/4.75/5. ZERK FITTINGS FOR EASY LUBRICATION TO ELIMINATE DRY BEARINGS.
If there is a issue with your order we will try to contact you as soon as possible. Item must not be used, mounted, or damaged and in sale-able condition. Mototeks is not responsible for any charges for labor, repairs, materials, down-time or lost profits due to returning any merchandise.
Also, provide us with the invoice number, order number, and order date. Mototeks has continuously supplied top of the line after-market products parts for the powersport industry for over 15 years. We strive in providing the best customer service experience as well as quality after-market parts. We appreciate your business and look forward to doing business with you.
Join Our Exclusive Newsletter For Up To Date News, Special Offers And New Arrivals. Speak to a Mototeks Sales Rep.
The item "HARLEY TRIKE AXLE CONVERSION KIT + SWINGARM FITS HARLEY TOURING BAGGER 2002-PRES" is in sale since Tuesday, November 21, 2017. This item is in the category "eBay Motors\Parts & Accessories\Motorcycle Parts\Body & Frame\Frames". The seller is "mototeks" and is located in California.


text:
Male guest stars, Real World Articles, 1945 births,
Self-voicing guest stars
Deceased cast and crew
Not to be confused with Howell Huser, whom Howser was the basis of.
This article is about the guest star. For the character, please see Huell Howser (character).
Guest Star Information
Huell Burnley Howser
Gallatin, Tennessee, U.S.
January 7, 2013 (aged 67)
Palm Springs, California, U.S.
"O Brother, Where Bart Thou?"
Huell Burnley Howser (October 18, 1945 – January 7, 2013) was an American television personality, actor, voice artist, and comedian, best known for his PBS documentary series California's Gold and as the voice of the Backson in the 2011 Winnie the Pooh film.
On The Simpsons, Howser appeared as himself in "O Brother, Where Bart Thou?", where he hosted Under the Wrapper, a program similar to Food Network's Unwrapped.
On November 27, 2012, Howser retired from making new shows amid speculation in the television community that he was seriously ill.
On January 7, 2013, Howser died at his Palm Springs home, at the age of 67. He had been battling cancer for several years and his death certificate listed metastatic prostate cancer as the cause. Howser's body was cremated and his ashes were scattered at sea off the coast of Los Angeles County. The episode "A Test Before Trying," which premiered on January 13, 2013, was dedicated to him and even featured his character.
On January 15, 2013, a memorial was held for Howser, who said before his death that he did not want a funeral as he did not want attention.
Howser's parents were Harold and Jewell Howser.
2.1 California's Gold
2.2 Other work
3 Retirement and death
4 Legacy and influence
5 In popular culture
Howser was born Huell Burnley Howser in Gallatin, Tennessee on October 18, 1945.[1] He received his first name from a portmanteau of his parents' names Harold and Jewell, as revealed in the California's Gold episode "Smartsville." Howser received a B.A. in history from the University of Tennessee, Knoxville, where he also served as student body president. After serving in the U.S. Marine Corps and on the staff of Senator Howard Baker, Howser began his television career at WSM-TV in Nashville, Tennessee. He began a series of "human interest" stories for WSM.
After working in New York as the host of WCBS-TV's Real Life show,[2] he moved to Los Angeles in 1981 to work as a reporter for KCBS-TV. During 1982-83, he served as weekend host and correspondent for Entertainment Tonight. In 1985 he joined Los Angeles television station KCET, then a PBS affiliate, as a producer of Videolog, covering short topics including lint artist Slater Barron[3] among other topics relevant to Los Angeles and adjacent communities.
California's Gold
Since 1991, California's Gold highlighted small towns, landmarks, events, or places of interest throughout California which aren't well known to the general public, with Howser conducting informal interviews with the locals. He also produced the shows California's Communities, California's Golden Fairs, Downtown, California's Water, California's Green, California's Golden Coast, California's Golden Parks, Road Trip, Visiting... with Huell Howser, California Missions, Palm Springs, Our Neighborhoods, The Bench, and various specials.
Articles written by Howser have appeared in Westways, the magazine of the Automobile Club of Southern California.[4]
In 1997, Howser featured prominently as himself alongside Tracey Ullman in character as Ruby Romaine in Tracey Takes On... Hollywood.
Howser at the Nisei Week Grand Parade in Los Angeles, California on August 19, 2007
He spearheaded an unsuccessful effort to save buildings by African-American architect Paul Williams at the Long Beach Naval Station from being demolished.[5]
Howser riding in a tandem IndyCar race car at the 2009 Long Beach Grand Prix
Howser appeared in Who Killed the Electric Car? in his capacity as a reporter, witnessing the demolition and shredding of a Honda EV+.[6]
In 2011, Howser voiced the Backson in the post-credits scene of Walt Disney Animation Studios' 2011 feature film Winnie the Pooh.
Retirement and death
On November 27, 2012, the Sacramento Bee reported that Howser was forced to retire from making new shows, amid speculation in the television community that he was seriously ill.[7]
On January 7, 2013, Howser died in his home at 2:35 AM in Palm Springs, California at age 67, 9 months shy of his 68th birthday. He had been battling cancer for several years and his death certificate listed metastatic prostate cancer as the cause of death when it was at first thought to have been natural causes. Howser's body was cremated and his ashes were scattered at sea off the coast of Los Angeles County.[8]
Legacy and influence
In 2011, Howser donated his videotaped collection of California's Gold episodes, as well as those of his other series, to Chapman University. He also donated his personal papers, and a large collection of books on California history to the university.[9] The school established the Huell Howser Archive, which, when completed, will offer the public free access to the entire digitized collection of his life's work. The archive can be accessed at Chapman University, as well as on the Internet. He also gave his extensive art collection, which consists mostly of "found-object" art collected during his travels, to the university, and endowed the California's Gold Scholarship Fund. Upon his death, he bequeathed his remaining two homes to the university, the proceeds from the sale of which will be added to the scholarship fund.[10]
Testimonials to Howser's unique contribution to the celebration of California history and culture immediately were acknowledged in numerous media sources upon word of his death. OC Weekly editor Gustavo Arellano called Howser "the greatest Californian since Hiram Johnson,"[11] noting that for Howser, California was the "ultimate temple of the American dream".[12] Such an assessment reflects the high regard, in which some Californians hold Howser's achievement of a very media savvy and unabashedly enthusiastic promotion of their state's heritage.
Howser's distinctive style as host of his various travel shows led to him being impersonated and lampooned by many different comedians and radio personalities, such as Adam Carolla,[13] Dana Gould, and James Adomian.
Matt Groening has stated that he is a fan of Howser[14] and has featured him in two episodes of The Simpsons: "There's Something About Marrying," where a character named Howell Huser falls off a turnip truck, and "O Brother, Where Bart Thou?," where the real Howser presents a program similar to Marc Summers' Unwrapped television program. Howser received a voice credit for the episode. "A Test Before Trying" marked his death with a quick cartoon memorial shot at the end of the episode, stating: "In Memory of Huell Howser, Friend of the Simpsons and a friend of California."
Episode – "O Brother, Where Bart Thou?"
Episode – "A Test Before Trying" (dedication)
↑ Template:Citation
↑ Hevesi, Dennis. "Huell Howser, Folksy Public TV Host, Is Dead at 67",. Retrieved on 11 January 2013.
↑ Sources:
Videolog Classics #2. KCET.org. Retrieved on January 10, 2013.
Huell Howser's retiring: An Off-Ramp remembrance. SCPR.org. KPCC - Southern California Public Radio (July 6, 2011). Retrieved on January 10, 2013.
Classic Huell: Farmers' Market. KCET.org. Retrieved on January 10, 2013.
↑ Road Trip with Huell Howser articles in Westways Magazine (outside Southern California: enter zip code 90210 to access articles)
↑ Long Beach Naval Station Falls: Court throws-out celebrity appeal. DailyRepublican.com. The Daily Republican (July 7, 1998). Retrieved on January 10, 2013.
↑ Chris Paine. "Who Killed the Electric Car?", Plinyminor / Sony Pictures Classics{{{date}}}.
Lindelof, Bill (November 27, 2012). Huell Howser, maker of PBS shows about California, retiring. sacbee.com. Sacramento Bee. Retrieved on January 10, 2013.
Collins, Scott. Huell Howser quietly retires from public TV's 'California's Gold'. Los Angeles Times. Retrieved on 12 January 2013.
Goolsby, Denise. TV host Huell Howser spent final days at Palm Springs refuge. The Desert Sun. Retrieved on 11 January 2013.
HUELL HOWSER: Prostate cancer was cause of death. pe.com. The Press-Enterprise (January 17, 2013). Retrieved on January 15, 2013.
Braxton, Greg. "Huell Howser dies at 67; TV host profiled California people and places",.
Howser Didn't Want Memorial, Died of Cancer. Retrieved on 9 January 2013.
Romero, Dennis. Huell Howser Dead. LA Weekly. Retrieved on 9 January 2013.
↑ Huell Howser: Highlights from 'California's Gold' online. LATimes.com. The Los Angeles Times (January 7, 2013). Retrieved on January 10, 2013.
Chapman University, Huell Howser Archive. blogs.chapman.edu. Retrieved on January 8, 2013.
Chapman University Remembers Huell Howser. blogs.chapman.edu. Retrieved on January 8, 2013.
Doti, James L.. Huell Howser's vault of 'Gold'. The Orange County Register. Retrieved on 12 January 2013.
↑ Remembering Huell Howser, Fan of OC Weekly, Lover of OC, Antagonist of OC Republicans. OCWeekly.com (January 7, 2013). Retrieved on January 10, 2013.
↑ "Remembering Huell, California's great adventurer", Los Angeles Times{{{date}}}. Retrieved on January 8, 2013. NOTE: quotation is from embedded video at 3m 40s.
↑ April 2, 2008 - Mark Wahlberg and Artie Lange call into the studio; Dana Gould is in the studio. Adam Carolla (April 2, 2008). Archived from the original on 2012-07-07. Retrieved on 2008-05-08.
↑ Lloyd, Robert. "The wonder and awe that make up Huell Howser", Los Angeles Times,.
Huell Howser at the Internet Movie Database
Huell Howser at Wikipedia
Guest stars in Season 21
Mitch Albom • Angela Bassett • Wren T. Brown • Neve Campbell • Kim Cattrall • Sacha Baron Cohen • Bob Costas • Simon Cowell • Ellen DeGeneres • Kara DioGuardi • Anne Hathaway • Jonah Hill • Eddie Izzard • Randy Jackson • Eartha Kitt • Gary Larson • Chuck Liddell • Cooper Manning • Eli Manning • Peyton Manning • Chris Martin • Jackie Mason • Jordan Nagai • Yael Naim • Seth Rogen • Ryan Seacrest • Sarah Silverman • Smothers Brothers
Retrieved from "https://simpsons.fandom.com/wiki/Huell_Howser?oldid=859649"
Male guest stars

redpajama_set_name: RedPajamaCommonCrawl


The Federal Court of Australia has declared that residential aged care providers cannot charge additional service fees that are known as 'asset replacement charges' or 'capital refurbishment fees'.
A study has revealed that regular antipsychotic use in residential aged care has decreased, however medications to treat agitation and sleeping problems have increased.
The Aged Care Financing Authority (ACFA) has begun a review into respite services in the community care and residential aged care sectors.
The new Industry Reference Committee (IRC) has been launched to address the aged care workforce issues identified by the Aged Care Workforce Strategy Taskforce.
Virtual reality is being used to help minimise the pain and discomfort experienced by aged care recipients during painful procedures, such as wound dressing.
The Federal Government will contribute $400,000 to the innovAGEING program, which is aimed at driving innovation to meet growing aged care demands.
The $33 million Boosting the Local Care Workforce Program has been designed to increase the amount of jobs available to meet the growing disability and aged care sector.


text:
BUSINESS BUZZ: Local briefs about local businesses
Money-managing class for students
The Manatee Chamber of Commerce, with the Manatee Community Federal Credit Union, is helping educate local high school students about money management with a program called the Big Bank Theory.
The program includes the importance of budgeting, saving and deciding which spending is the highest priority. It has been presented at Braden River, Southeast and Manatee high schools and will be given today at Lakewood Ranch, Oct. 20 and 21 at Bayshore and Oct. 31 and Nov. 1 at Palmetto high schools.
Job-training grads hired full time
Ten people have graduated from the Bridges to Careers workforce-readiness training, and seven of the 10 previously unemployed trainees already have full-time jobs with a local manufacturer, according to CareerEdge Funders Collaborative Manatee Sarasota.
The seven program graduates were hired by Berry Plastics Corp., and the company has asked CareerEdge to recruit and train another class of workers this month.
CareerEdge's training is funded with grants from Microsoft Corp. and Jane's Trust.
Octex expanding production facility
Octex LLC has broken ground on a 26,000-square-foot expansion at its production facility at 901 Sarasota Center Blvd.
The company said the $7.6 million expansion, funded in part with a $200,000 development grant from Sarasota County, will give it a total of 60,000 square feet. The work is expected to be finished by next March, the company said.DooleyMac Constructors of Sarasota, The Schimberg Group and AM Engineering are involved in the project. BB&T is providing project financing though a Sarasota County industrial revenue bond.
Octex produces precision injection-molded plastic components for several industries.
AT&T upgrades 45 cell towers in area
AT&T has improved 45 cell sites in the Sarasota and Bradenton areas this year.
The company said it added "backhaul connections" and High-Speed Packet Access+ equipment at 19 cell sites, enabling 4G speeds.
It also added layers of capacity to 26 cell sites in Bradenton, Bradenton Beach, Longboat Key, Sarasota, North Port, Osprey and Englewood, enabling those towers to handle more calls.
AT&T said it has spent more than $425 million on its Florida networks in 2011.
Red Cross honors work of 2 women
Two people with the American Red Cross's Florida West Coast Region received the agency's 2011-2012 Presidential Award of Excellence.
The winners were Jeannie Slater, chairwoman of the board of directors for the Southwest Florida chapter, and Natasha Salazar, chapter and youth program manager for the Tampa Bay chapter.


Historic St Mary's Church at Battle will provide the setting for an afternoon of high quality chamber music.
The Primrose Piano Quartet was founded ten years ago by four of the UK's leading chamber musicians, members and ex-members of the Lindsay, Allegri and Maggini String Quartets.
The group had regular performances in London's leading concert halls, commissions from some of the UK's top composers, six CDs released on the Meridian and international tours.
Two of the Quartet's members, violinist Susanne Stanzeleit and cellist, Andrew Fuller, live in the Battle area.
The concert will raise funds for Demelza Hospice Care for Children.
Tickets are available online at www.battleconcerts.co.uk or in person from "Spoilt Rotten" in Battle.