Design guidelines

[jacomyal]

This document is here to help ruling what goes into gephi-lite and what doesn't, as well as how to design a given feature.

1. Gephi Lite features set should remain a subset of Gephi features set as much as possible

We do not want people to use Gephi Lite over Gephi because it provides features that Gephi does not.
One exception of this rule can be for things that must be different between a desktop app and a web app (such as files management).

2. One given business need should have one solution at most

This rule will help reducing the scope and simplifying the interface.
For instance: In Gephi, it is both possible to filter on a "Degree range", and to add degree data to nodes, and filter on the new "Degree" attribute. These two scenarii address the same need, so in Gephi Lite we can remove the "Degree range" filter.

3. As much as possible, Gephi Lite should be accessible and responsive

Culturally, accessibility and responsiveness are more expected of a web app, I think. So, what I mean here is:

• App should have proper aria tags and semantic DOM
• Everything that a user can do with a mouse should be possible to do with a touch / multitouch device as well
• The content should be readable both on large screens and small screens

Though, for technical reasons, Gephi Lite will always need a modern browser with JavaScript enabled.

[jacomyal]

@jacomyma @mbastian @Yomguithereal Any comment about this? I feel that this is the most important point to agree on.

[jacomyma]

1. Gephi Lite is a subset of Gephi: agreed

But it's not because we want to refrain people from using Gephi Lite over Gephi. I think that we are fine with people, even a majority, moving to Gephi Lite. Especially because the name and everything makes it very clear that you can move to Gephi if you want more. Gephi Lite is an entry point into Gephi.

The concern about simplicity is rather that we do not want to be simpler than necessary. In other terms, so simple that the wrong messages get across. Examples of unhealthy understandings: there is a best layout for a given network; there is a good/best community partition for a given network; Gephi can analyze the network for me and I should trust what the algorithms tell; etc. (I write this for the record). Takeaway: we want Gephi Lite simple but not oversimplified.

2. One way to do a given task. Agreed/indifferent

I agree insofar as I don't think it is productive to offer multiple ways to do the same thing. Let's keep the scope down! But at the same time, I think that situations may arise where having multiple ways to achieve a same task is in fact a simpler solution; if such situation arises, I would not complicate Gephi Lite just for enforcing this singleton rule.

3. Accessible and responsive: agreed

Usable on tablets: must have.
Usable on smartphones: nice to have.
I write this accounting for the fact that the gap between tablets and smartphones runs thinner and thinner.
Hot take on accessibility:
Gephi Lite being a viz tool, I would not care for blind people. BUT colorblindness is indeed a concern!

[paulgirard]

I feel like there is an implicit missing guideline:

0. Gephi Lite interface should be familiar for Gephi users

We don't want to redo the same UI but trying to give some landmarks for Gephi users.
What's in my mind right now about this is to reuse the default screen place for features:

• top left: viz parameters
• bottom left: layout
• top right: summary
• middle right: stats
• bottom right: filter

see #4

But :

• it should not be a strong rule more a smooth guideline
• the convergence can also later be on the other way if Gephi Desktop starts a UI revamp

To sum-up I would propose that designing Gephi lite UI should take the existing Gephi Desktop UI into account.

1. Gephi Lite is a subset of Gephi

I am so so about the way this is formulated. I nevertheless totally agree the simplicity objective over the completeness/expert scope left to GEPHI as Mathieu stated. We could reformulate as Gephi Lite doesn't aim at being as "complete" (not sure avout this word) as Gephi since it's targeting a lower level of complexity (in data and in users expertise).

2. One way to do a given task

A general good guideline but not a strong one for me.

3. Accessible and responsive

Yes although for graph editing small mobile phones are not suited at all (not true for graph viewer such as retina).

[jacomyal]

0. Gephi Lite interface should be familiar for Gephi users

Agreed.

[paulgirard]

While discussing #9 with @jacomyal we stumbled upon a important decision which is to be made about Gephi lite.
To introduce the issue let's remember what was Gephi moto at its early days : "a photoshop for the graphs".
I tend to believe that this moto is present in the way viz attributes are handled in Gephi: those are static attributes. An example of this is the feature which allow to color one node by hand.
On the other hand Gephi is also THE tool to drive Visual Network Analysis (VNA) where we want viz attributes to be tied with data. We use the visual to reveal data trends.

Now the question is should Gephi lite (by folowing rule 0) embrace the photoshop of graph mood or the VNA one.
I would vote for the later and thus would not include paint node feature in Gephi Lite. This decision is necessary to decide how to implement filters (#9), appearance (#5) and sizes/colors captions (gephi/gexf#18). By thinking about those we tend to put data attributes at the center of all features which would disable any arbitrary human decisions on appearance. The only exception would be node x-y positions which are data driven by layouts but those being not deterministic moving nodes around to help out the layout seems legit.

@jacomyma @Yomguithereal

[jacomyma]

@paulgirard I think we do not need a painting tool in Gephi Lite but I think that color is not necessarily tied to data. Some networks come with node colors for reasons, whether we like it or not. The question is then: what do we do with it? I am not satisfied with the "ignore it" solution.

In Gephi nodes really have a color, so applying a color from an attributes is definitive. It repaints the network. Doing so makes you lose the original color, but you did it, and it is sufficiently clear.

Other paradigm, the color is always the consequence of a pairing with an attribute; it is dynamic. In that case, I should still have the option to display the original color.

That being said, I think that Gephi Lite should use the same paradigm as Gephi, for the sake of consistency. But it does not mean that we want to offer the manual painting feature.