search

complexdatacollective / Server

A tool for storing, analyzing, and exporting Network Canvas interview data.
http://networkcanvas.com/
GNU General Public License v3.0
2 stars 2 forks source link

Feature/ego charts #255

Closed rebeccamadsen closed 5 years ago

rebeccamadsen commented 5 years ago

Resolves #252. This adds both ego and edge ordinal/categorical variables to the server overview screen, and to the settings screen to toggle which ones display.

It also fixes a bug where the counts were incorrect if you had two variables of the same name within the same entity (e.g. node: person with variable: catVar, and node: venue with variable: catVar).

wwqrd commented 5 years ago

I'm seeing the ego variables showing up in the settings panel, but getting nothing on the overview screen?

wwqrd commented 5 years ago

I'm seeing the ego variables showing up in the settings panel, but getting nothing on the overview screen?

Actually, I can't reproduce this. Closing the app and restarting seems to have fixed it, and now it works as expected. I wonder if it was just an issue with rehydrating the app state?

rebeccamadsen commented 5 years ago

One thing I wondered looking at these changes is if we should try to model the ego in the network as 'ego.ego' to make a lot of these transformations unified (would apply to other apps too)

Yeah, I've wondered the same thing in other apps as well as here. Though ego doesn't really have a type, it could simplify things to structure it like it did. Is it just that is makes no logical sense to have a type for ego, or are there some things that are better because we have no ego type? I mean, it really does make no logical sense to have an ego type. But this is not the first time the code work arounds were kind of ridiculous because there is no ego type.

jthrilly commented 5 years ago

I'm afraid I much prefer the duplication of code caused by ego not having a type, to changing the model to ego.ego or similar. I prefer the data model to be conceptually "pure" and accepting complexity in the app logic, rather than the other way around. Data interoperability is going to be lessened by polluting the model (by this I mean that our data model is now effectively a normalized graph model), and the schema would also (logically speaking) need to be updated.