The early user group for edgesense had the 1st hangout yesterday( 9th April ). This wiki is a documentation for the main points discussed during the hangout. Please update it with your own notes and add any missing info.
- One of the general questions that showed up was “How big is the database that could be used with edgesense?”
Sometimes it is better to have a special processing before hand in order to have a cleaner database to work on with Edgesense. This is the case of Lee-Sean’s community which consists of around a decade of emails.
The numbers on the right side (no of edges/modularity…etc) is calculated on the whole network, it is something to be aware of when hiding sub-communities because the numbers are not recalculated according to what’s shown.
For the 1st use of Edgesense by those with no background knowledge on network science and analysis, the tutorial helps to have a basic understanding of the structure underlying a network of interactions.
Moderators are always the black colored nodes (this wasn’t mentioned anywhere)
The general network is useful in explaining the community to people (“outsiders”) or for fund-raising purposes. It gives an idea on how big/complex/alive is the community, even without trying to deeply interpret the network. (Noemi)
The network could look very complex so trying to reduce the visual complexity is an issue. Although Noemi and Hazem said that once you know the network it’s not that complex any more, because they know it so well, first hand.
The algorithm is neutral in identifying the sub-communities, most algorithms do something similar to the Louvain, which is basically clustering people based on the links connecting them, this gives a better vision on who is actually talking to whom, rather than clustering them according to the groups on the platform. Alberto explained that the modularity value adds more info to the picture as the algorithm will always find some kind of sub-communities. In the case of Edgeryders network which is relatively modular (0.35) the number of sub-communities makes sense visually but in the case of a network with low modularity (0.1 for example) a lot of sub-communities will be there with a lot of different colours which could be confusing.
Lee-Sean mentioned that colours are sometimes confusing because it is similar in all the interface (same colours in the network and in the boxes around it). There is no clear cut number of sub-communities so there is no specific number of colours but it is possible to use a colour palette for the network which is not used in the boxes in the interface.
In order to zoom, you need to press the unlock button on the top right of the screen.( this wasn’t mentioned anywhere) Also zooming works better with a mouse.
On search feature
When searching for someone, the node itself isn’t highlighted differently inside its network which make it hard to identify, you must figure out which one it is manually.
On time slider
It would be useful to have an analysis and visualization for the last period of time (year / six months), in addition to the all time network. It gives an idea on the status quo and who is active now. Also it is useful for older communities as Sabrina explained in InnovatoriPA there were a lot of old nodes from the beginning which are not active any more and the shape of the network could be somehow different now with the only active ones. Also it is needed for activity management and in showing how each activity changed by time.
One of the missing info that could be helpful from a community management perspective is the time of changing the user to a node, or the little active node into an active one. Specifically, this is about finding a way to distinguish visually between more active users and less active ones, for a benchmark no. of edges, say 1, and for a given time since registration, say first month. Having this info in real time would be helpful in on boarding people and saving this info to check if there is a pattern in between signing up and contributing which could be helpful to know when to intervene as a community manager. The challenge would be the representation of this data in Edgesense. The live ones could be a separate floating box but what about the old data?
Having 2 time sliders technically is a computational problem but there are some alternatives that could work keeping the requirements on the server as low as possible.
One is to have an option to ghost out the nodes the nodes that are not active for a year for example.
Another one is using tabs for different representations of the network. One of them could use colours to show the freshness of the node/edge. Using green colour for the new ones and fading to grey when they are dead/inactive.