Company - centric networks


Actor specific networks:

  • user has a company in mind whose tentacles s/he would like to see across countries / markets
  • user can chose one or more companies according to a fulltext search in the company name (clean company names from Digiwhist!)
  • other choices are the same as in the market-centric network (year range, country, CPV (market)). This needs a smart design solution @Chut_Ko

(Chut Ko) #2

ok, i gave it lot of thought. i have split my ideas into sections, looking forward to some answers :smiley:

  1. Terminology
    right now, what kind of networks are we visualising? :slight_smile: are they country-centric, or market-centric? it seems they are none of these (as multiple countries and markets can be selected. btw is that even useful?). therefore i am wondering how to introduce concept of current networks comparing to company-centric network to the user in the Query Builder.

  2. New network types?
    we can also consider introducing Market-centric networks (can select only single market) AND Country-centric networks (can select only single country) along. that would bring some order and boundary to the rendering time. (I doubt about usefulness of network rendred across 3 countries and 12 markets…)

  3. Query Builder as a wizard
    selecting the type of network should be the very first step on which other selectable options will depend. visually we can treat this as a wizard with three steps: Network type selection -> Network criteria (e.g. coutry, year, market) -> Rendering options (-> Visualisation).
    OT: right now, we are displaying Year, Country and Market selects all at once. They should appear one after another as user sets the criteria if they depend on each other (example: Year might depend on Country and Market - some years might not have any data in that country or market)

  4. Company search
    when the user selects he wants a Company-centric network, what kind of input do we need from him to get to the visualisation? is an input with suggestion search enough to get to the desired company name? (see the attachment)

  5. What about other selects?
    I am confused about other inputs - can you explain why the user needs to select
    a) Market - most companies are from specific market. if they aren’t, i presume displaying procurement from all markets would not be such a big performance problem
    b) Country - each company in our database is registered in a specific country. even if it is doing business with institutions from other countries, that is what this type of network is about - seeing all the countries.

  6. The simplest possibility
    however, if the only difference with Company-centric network is specifying the company name and all the other options remain same, we can just leave everything as it is and add a search input for specifying the country name (if the user doesnt want country-centric network, he can leave this blank).

(Georgiana B) #3

Little input on your points:

  1. Right now it is kind of country-centric because the user first has to choose a country and all the other available criteria are filtered by that: the users sees only the years available for that country and only the cpvs available for that country in those years. So, unless market = cpvs in space-time context, we can’t really say it’s market centric since the users can’t choose only cpvs.

  2. That’s probably how people are going to use it but I think we should give as much flexibility as possible at market choice considering how peculiar the CPV standard and it’s usage in practice is.

  3. We now express order by disabling fields until the filter they depend on receives a value: you can’t do anything until you choose a country. Also, there are visual clues to suggest that one field filters the next: when you choose a country the years bar changes range.

  4. I hope so :slight_smile:

5&6. From the last usecase here it sounds like a company centric network is just a network but filtered by company first. I think we should also allow people to choose only companies or only cpvs (without other filters, as I explained in point 1.)

(Georgiana B) #4

@zufanka Just to clarify, do we want to have this only for suppliers or also for procurers?


good question @georgiana_b !
I think it should be also for procurers.
Would that require two input fields @Chut_Ko ?

(Chut Ko) #6

@zufanka one is enough. list of all entities can be searched upon, visually we can just put color dots with them or a label “procurer/supplier”

(Georgiana B) #7

@Chut_Ko We just had a talk and we found some things that need to be considered when designing this:

  1. An actor can be both supplier and procurer, how do we visualize that actor’s network?
  2. There are situations when we have multiple names that represent the same company. So, people should be able to select multiple entities for company centric networks. Should me offer them the option to see the companies they chose directly clustered?


@Chut_Ko designer to the rescue! ^

(Chut Ko) #9

hmm, it gets more and more complicated, great! :slight_smile:

  1. so who is this actor? how come some entity can be supplier and procurer?
    anyway, the best visual representation of such entity would be a pie chart of 2 colors or a circle within circle, size of the circle representing the total sum of income and outcome.

  2. i understand usefulness of this but it also brings complications - what if the user selects 2 completely different companies? due to this problem, probably we should automatically cluster all selected companies and leave it to the user - if he creates mess, he will have to cope with it :slight_smile:

  1. an actor is a node. Sometimes governments procure from each other. I think representing the circle sizes is not necessary. If it is a government organization it should have the colour of government organization.
    This gets more complicated if government companies are privatized, but let’s leave that out for now.

  2. I agree, we should warn about this at the beginning though. We can later evaluate how it is used.

(Chut Ko) #11
  1. that is a good point about the colour. it might be enough for the user just to see the arrow/flow coming from one government organisation to another, no matter the colour.

what concerns me is that until now, we have been associating colours to procurers and suppliers all around the system - not institutions and companies. now, procurer not necesarilly equals institution and supplier not necessarily equals company. we will need to incorporate this thinking into the system, otherwise we will hit the wall with unclear visual language