High degree of fragmentation of the individual forms

[JanEmde]

The very high degree of fragmentation of the individual forms makes filling out the forms quite complicated from the user's point of view. From our point of view, it would be highly desirable if certain groups and fields were combined.

For example, from our point of view, the BTs BT-262-Procedure and BT-26(m)-Procedure could be included in the GR-Procedure-Scope group. The GR-Procedure-Scope-MainClassification group could then be omitted without replacement. The same of course applies to the same BTs at lot level.

Further examples:

1. The BTs BT-765-Lot and BT-766-Lot each have their own group. From our point of view, they could be summarised in the superordinate group GR-Lot-ContractingSystem. Alternatively, BT-765-Lot could be included in the GR-Lot-FrameworkAgreement group.
2. The groups GR-Lot-EUFunds-Indicator and GR-Lot-EUFunds groups could be merged.
3. The groups GR-Lot-TendererQualification, GR-ReservedParticipation, GR-Lot-ExecutionRequirements, GR-Lot-ReservedExecution, GR-Lot-PerformanceTerms and GR-Lot-ElectronicSignatureRequired could be merged.
4. The groups GR-Lot-EInvoicing and GR-Lot-PostAwardProcess could be merged.
5. The groups GR-Lot-Requirements2SecurityClearance1, GR-Lot-SecurityClearance2 and GR-Nda could be merged.

Of course, we know that we can customise the user interface. However, in line with the metadata-driven approach, a generalised solution would be desirable.

[YvesJo]

Hi,
Thanks for the suggestions. The structure of the notice types and the inherent fragmentation are driven partly by the XML structure, the addition of some groups was required for an appropriate XML generation. The redefinition of Groups and their association to nodes may be reviewed on a case by case. The display or not of a group also affects the affordance having therefore an impact on the use of the form. Our colleague in charge of the notice type definitions will be made aware of your proposals and identify the best course of actions.
KR

[JanEmde]

Thanks!

[JanEmde]

Another - from a subject-specific point of view - somewhat strange grouping is the assignment of the GR-Procedure-Scope-MainClassification group to GR-Procedure-Scope. From our point of view, the group would be better placed under GR-Procedure-Description.

[encampaen]

Dear @GarrusMD,
unfortunately the fragmentation of the NTDs is due to the metadata driven aspect of the SDK. We have to follow the XML structure in order to allow for correct XML generation and interpretation of the (live) validation rules. In fact originally NTDs didn't follow the xml strictly due to concerns of usability, and this lead to so many issues that we had to change it in previous versions of the SDK. In some of these instances there is still a discrepancy, and this will probably be corrected in future SDKs when there are less priorities on the table. Expecting more fragmentation is an unfortunate reality, unless we change the xml structure.

Concerning your request about the Main Classification, this is something we could take into account, and I will check this further.
No promises at this point though.

[JanEmde]

This is really very unfortunate and misses the reality of the recording users.

[JanEmde]

Another example of the impracticality of fragmentation is the recording of winners.

I spoke to a user today who has to record the results of a large framework contract agreement. Due to the large number of lots, he now has to create and fill in more than 150 tender elements, more than 200 contract elements and a large number of tenderer elements. Including the mutual referencing of the elements, the result is a huge, confusing jumble of elements.

From the point of view of the person entering the data, there should only be one result element in which I can enter all the information (for a corresponding lot). If necessary, with an additional element for recording statistics etc.

[encampaen]

Yes, but eForms require all those elements, and if we are to make the correct links in a structured, codified way, while also providing seemingly all encompassing business validation - which many eSenders requested - we have to separate tenders, contracts, bidders, and link all of that to their referenced lots in the lotresults. Framework agreements add a layer of complexity which makes it more difficult for everybody.

We are actively thinking about ways to reduce this complexity for users while maintaining the granularity requested by the member states and policy makers, but as you can imagine it's an all encompassing effort, so not that simple.
We are also thinking of changing the UI (of eNotices2) to support a more interactive way to fill-in lots and results, probably starting with the business entities developed within the SDK. So we can expect some improvements in the future.