Reflect the changes in our dataset in the UI


(Georgiana B) #1

The Digiwhist dataset contains information about tenders, procurers, suppliers etc. that we previously didn’t have.
The old Digiwhist schema, although slightly outdated, gives a pretty good picture of what info we will have available.

This dataset gives a clearer picture of each tender, its lots, the bids in each lot and the bidders in each bid. How these are related can be seen in the new database design.

Do we want to include any extra info in the interface?

Proposals I have so far:

  • include address_of_implementation in tender details i.e. the physical location where the tender services/goods are deployed
  • currently the Tender Details section on contract details page (e.g. this one) contains a section with “Other contractors in this tender”. I think it would be better to replace that with “other contracts in this tender” that would contains contracts from the other lots, if any. That way people still have access to the “other contractors in this tenders” without pulling them out of the context of their contracts
  • add to contract details the bidders that didn’t won

If you have more ideas, bring them on!


Changest to tender details page
#2

The old Digiwhist schema2, although slightly outdated, gives a pretty good picture of what info we will have available.

Are you sure this is the right link? I see a project application namely.

How these are related can be seen in the new database design

I would need some clarification on how to read this :slight_smile:

include address_of_implementation in tender details i.e. the physical location where the tender services/goods are deployed

yes!

currently the Tender Details section on contract details page (e.g. this one) contains a section with “Other contractors in this tender”. I think it would be better to replace that with “other contracts in this tender” that would contains contracts from the other lots, if any. That way people still have access to the “other contractors in this tenders” without pulling them out of the context of their contracts

not sure why we chose for other “contractors” here … but seems also a legit point. Perhaps we can keep both? @Chut_Ko ?

add to contract details the bidders that didn’t won

yes, this would be awesome to have!


Changest to tender details page
(Georgiana B) #3

The old Digiwhist schema2, although slightly outdated, gives a pretty good picture of what info we will have available.
Are you sure this is the right link? I see a project application namely.

You’re right, that is the wrong link but probably for the best since I’m not sure we are allowed to share that schema publicly. You can find the Digiwhist API documentation on https://storage.tenders.exposed.

I would need some clarification on how to read this :slight_smile:

It’s not final and I’m not completely happy with it so I’m eager to explain it and get some feedback.

not sure why we chose for other “contractors” here … but seems also a legit point. Perhaps we can keep both?

“Other contractors in this tender” implies you are currently watching a contractor and you can check out the others. But this is not a contractor details page, it’s a contract details page so you are currently watching a contract and you can watch other contracts.

I think in the contract details should include:

  • tender details
  • other contracts in the tender
  • the procurers
  • the suppliers that bid for the contract and won
  • the suppliers that bid for the contract and didn’t won

This way, if people want to see the suppliers from the other contracts in the tender i.e. “Other contractors in this tender”, they can just click on those other contracts and see who the their suppliers are in their details page.


Changest to tender details page
(Georgiana B) #4

@zufanka @Chut_Ko We also have to incorporate the fact that a contract can have multiple procurers and multiple suppliers.

This was always the case but so far our consortia were “trapped” inside an entity and looked no different than a normal node.

We have to think how to treat the consortia in the network, in the sidebar, in the contract details page and in the contracts list from supplier/procurer details.

The obvious answer would be to make each consortium a cluster.
Pros:

  • we would already know how to visualize it in the network, sidebar and cluster details page
  • we would use existing infrastructure
  • we would use existing logic that users are familiar with for calculating metrics for the consortium

Cons:

  • we consider a cluster to be a single entity so we don’t expect the actors in the cluster to also appear independently in the network. With consortia this is not the case because an actor can “play” on a market both on its own and in consortia. How will we accommodate this case?
  • it would be harder to use clusters as an indicator for entity reconciliation because a cluster would no longer mean its actors are probably the same entity

I would prefer to have a separate concept for consortium that would share many similarities with a cluster but also some differences:

  • a consortium expresses a temporary collaboration of individual entities; we can’t alter it
    • a cluster is a way to express that multiple nodes are in fact the same entity and it’s ultimate purpose is to become a single node
  • when the user finds a consortium masked as a supplier and “breaks it” into multiple entities they create a consortium
    • when the user makes a cluster and then breaks it (uncluster), the entities go back to being individual nodes
  • a cluster always has a name because the user who makes it gives it one whereas a consortium just means there is a group of companies, sometimes it has a name, sometimes it doesn’t.

I’m not yet sure how to incorporate these differences in the UI. The obvious implication would be that clusters can be more opaque about their individual parts whereas consortia should be as transparent as possible.


(Victor Nițu) #5

How about we tie a contract to multiple suppliers, when it’s a consortium? In order to reflect this in the UI, we would have to:

  • put all the consortia members in the network
    • and draw edges to them
  • each contract would appear as attributed to a consortium:
    • look at the contract / edge details, see the procurer and a generic name “consortium of x and y” and the members displayed somewhere visible
    • look at one consortium member, see contracts attributed to it and contracts attributed to consortia it’s a member of
      • for consortium contracts, the sum is undivided in the UI and database, we just have to make clear a member didn’t get all the money and we don’t know who got how much
  • we can even mark consortia on the network in some discrete way

As far as the database schema goes, I am thinking of “contract -> has many -> suppliers” and we can put some logic in the backend to mark those as consortia.

It’s a rather incomplete thought, I realise this. But so far, does it make any sense? Is there any sense in thinking more about it this way, or is it a completely wrong path of thought?


(Georgiana B) #6

each contract would appear as attributed to a consortium:

  • look at the contract / edge details, see the procurer and a generic name “consortium of x and y” and the members ?>displayed somewhere visible
  • look at one consortium member, see contracts attributed to it and contracts attributed to consortia it’s a member of
  • for consortium contracts, the sum is undivided in the UI and database, we just have to make clear a member didn’t get all the money and we don’t know who got how much

I think it’s a good proposal for showing consortia in contract details.

To show consortia in the network we could do the following steps:
1, draw all suppliers that are part of the consortia in the network
2. draw a node for the consortia
3. draw edges between suppliers and the consortium that look different than normal edges and signify “node belongs to consortium”
4. draw normal edge between consortium and procurer

This way we don’t have to worry about:

  • how to split the money among suppliers
  • how to show both the contracts that a supplier had individually (edges from that supplier to procurers) and the contracts that a supplier had as part of one or more consortia (edges from that supplier to consortia)

On the negative side, it might make the network too complex.


(Georgiana B) #7

Another proposal to draw consortia in the network would be to make them look like clusters but have another color. This means people have to click on details to see exactly what companies are part of it.
The suppliers who are part of the consortium would not appear on the network unless they also have individual contracts but you could still see their details via: consortium details - members.


(Georgiana B) #8

And ofc there is the possibility of not showing consortia at all. Just split the contract into equal contributions for each member and add those up to the score each member made individually. This means everything would look exactly the same except for contract details that still needs to show multiple suppliers.

TBH I don’t like this because:

  • we don’t show the potentially useful info of suppliers being in “coalition”
  • splitting the amount of money in the contract equally doesn’t necessarily reflect reality

(Victor Nițu) #9

Making them look like [immutable] clusters would mean some suppliers are likely to appear multiple times in a network. Once for every consortium they’re members of, and potentially once more as individual entity. This if we won’t have duplicate entities in the database. I’m not sure how would this affect everything, I’m just raising it as a potential source of confusion.

I also like the clusters idea though, if we could have “frozen” clusters that cannot be split. It would probably reflect reality the most, anyone seeing any pitfalls to this?


(Chut Ko) #10

considering the above mentioned, this is how i think about it:

  1. i personally dont like treating consortia with same logic as clusters:
    a) clusters can be created and edited by the user. also, they act as a single in the whole network and especially in the contrats
    b) consortia consist of suppliers and each of their children can appear separately in the network. also, supplier can be part of consortium AND be also a cluster (what a fun). in the contracts and relationships, it is important to display which entities belong to the consortium (comparing to cluster, whose contents are only relevant in the clustering dialogue)

so from my point of view, what consortium and cluster doesn’t have much in common. they are both structures grouping network entities which is too general to treat them same.

  1. i think consortium is more similar to supplier - it is connected to a procurer with 1 or more contracts. the only difference is it has child suppliers (they can also be separate network entities) which need to be displayed in contract’s winners/bidders

from design point of view, for consortium node type, we can have slightly different visual (with icon or something) AND display which suppliers are inside it at several places like contracts and relationships (which else?)

what troubles me a bit is how to display the huge name consisting of several suppliers in the network view. but we can also display consortia with simple name like “4 suppliers consortium” and show its contents in a popup or something.


(Georgiana B) #11

I just made a small diagram to see how much visual complexity the idea I outlined here would add to the network.

The yellow dot is a consortium and doesn’t have a name unless the consortium does (sometimes they do) but that’s ok because you can see who is part of it on the network:

consortium_on_network


#12

@Chut_Ko
I tried to draw all the possible scenarios that we were talking about today during the call.
We did not make a choice yet, we would really like your input.

@victor @ca1yps0 @georgiana_b please have a look as well and comment!

I am not sure I got everything right, so mixing and matching is possible!

We will make a definitive choice next week.
(click to see a larger version)





(Chut Ko) #13

i mostly like the very first image titled Situation and the Giraffe scenario.

“Situation” (i know its a situation description but this is actually how simple could it be) is what i proposed in an earlier post here - just putting all suppliers in a consortion together and treating them as a single supplier.

“Giraffe” is interesting and more informative, although seems a bit complex, i think in most cases it will be just too much visual rubbish. maybe i would go for an option to have the option to switch Giraffe and Situation view


#14

Scenario is also the current status quo.

To be honest, I also think splitting consortia is a task for an apart funding tranche and another 6 months. It’s namely quite complex in theory already (how to split the tender, etc)

@georgiana_b how much do you need to know about this future possibilities for splitting consortia in order to do the new backend?


(Georgiana B) #15

@georgiana_b how much do you need to know about this future possibilities for splitting consortia in order to do the new backend?

I can just skip consortia completely in the new backend if that’s what we want but tbh it would be quite ironic since that’s one of the main reasons to make the new backend.
I already started building the other parts of the backend in parallel with this discussion.
TBH I think we’re making this look harder than it is. We’ve come pretty far in this discussion and we have things pretty clear and fresh in our heads. Let’s just choose one of these and make the infra for it.

We can change it in the future after user input which will be a lot easier to give if users have something already built to start from.

@Chut_Ko Situation is just the hypothesis so the first scenario is Giraffe, the name is under the photo for each :smiley_cat: But anyway, I like this proposal you made, edited with the correct names:

maybe i would go for an option to have the option to switch Giraffe and Anteater view

A variation to :point_up: I find cool is to double click on the consortium to show/hide it components. This would be even cooler if the consortium node would have a small clue that it is a consortium.


#16

Discussion was a difficult one, there is not really that strong reasons to lean one way or the other. Important thing for the backend is that we chose between G and A/V. There was little willingness to make choices, so I chose for Anteater. Protest now or forever hold your peace.


(Victor Nițu) #17

On mobile here, so not much writing capacity. But can’t we build the infrastructure for Giraffe and skip splitting entirely, save for some manually processed entries?

This way we provide a proof of concept, we pave the way for potential future funding related to the splits and we don’t improvise any data in the db.

@georgiana_b, would it be much more difficult to do Giraffe than doing Anteater?


#18

Please note that we won’t be doing anything about the splitting during this funding tranche.
If implemented we need to find more funding.

Georgiana needs to build the backend for either Giraffe or the Anteater tho, so there is no room for proofs of concepts as I understood it.

I am happy to go for Giraffe if others agree that is a superior solution.


(Georgiana B) #19

TBH after drawing each scenario with an additional consortium A-D I’ve also come to prefer Anteater for displaying :slight_smile: