Usability Showstoppers

[p-a-s-c-a-l]

Here we collect usability-related showstopper issues that have to be resolved before we can release the public BETA release of CSIS and perform the internal acceptance tests.

[p-a-s-c-a-l]

We have to remove or hide all non-working and dysfunctional study types:

In fact, the only study types that will soon become usable by external users are are Basic Screening: General and Automated Screening: Urban Infrastructure. Expert Studies are currently for our DCs only. So we have find a way, to hide those studies from the list.

@fgeyer16 Perhaps this has already been revolved in #115 ? ATM, I'm not able to test it because I cannot log in with another user due to #140

[patrickkaleta]

In fact, the only study types that will soon become usable by external users are are Basic Screening: General and Automated Screening: Urban Infrastructure. Expert Studies are currently for our DCs only. So we have find a way, to hide those studies from the list.

@fgeyer16 Perhaps this has already been revolved in #115 ? ATM, I'm not able to test it because I cannot log in with another user due to #140

Yes, this has already be resolved. A "normal" logged in user can see only these study types:

I will deactivate the "Advanced Screening: Transport Infrastructure" until the integration of the TM is done.

BTW: #140 is not happening to me anymore (I did have problems with the CAS earlier this morning).

[p-a-s-c-a-l]

Add Study and Edit Study Forms are different but probably they shouldn't:

Most of the information in the Edit Study Form are required for successfully performing or assessing a study (country, city, scenarios). But those important settings are "hidden" behind the "edit" Button of the study context page. So users will never know that they must enter this information and will get stuck e.g. here:

So IMHO this is a serious usability issue that could render the system impossible to use for anybody not involved in its implementation. A straightforward solution could be to use the same form for add and edit. But this does not solve the more general problem, that there isn't any workflow guidance as we intended to provide with help of the Step-by-Step Wizard. I think we have to put more emphasis on this now.

[p-a-s-c-a-l]

Coming back to country selection, there are two usability issues:

The first, more serious one is related to the recalculation of HC-LE input layers: The city selection box must contain cities only, that are guaranteed to be available (recalculated) for screening. So we have to periodically re-generate the cities taxonomy as @therter described here. I wonder, if there is a possibility to a) automate or b) simplify this process? If we could unpublish or hide some taxonomy terms, then it would still be a manual task to update the list of cities as new cities are becoming available, but it's still more efficient than doing the complete import process again and again.

The second issue is not that critical (showstopper) but it could still become frustrating for users: There are many countries without supported cities, so they shouldn't be shown at all in the countries selection box for Automated Screening: Urban Infrastructure studies.

[p-a-s-c-a-l]

users will never know that they must enter this information and will get stuck

O.K. I completely forgot that we've got those videos:

• The CLARITY methodology explained
• CLARITY CSIS: Create a profile
• CLARITY CSIS: Create a study

While this doesn't solve the most obvious usability issues, users can get at least an impression on how to use the system without getting stuck somewhere in between.

So we can put this issue on hold. But we have to link or embed those videos very prominently, e.g. before creating a new user profile or a new study.

[patrickkaleta]

I wonder, if there is a possibility to a) automate or b) simplify this process? If we could unpublish or hide some taxonomy terms, then it would still be a manual task to update the list of cities as new cities are becoming available, but it's still more efficient than doing the complete import process again and again.

It is possible to manage the City taxonomy by hand. Here you can check for all cities the status and either publish or unpublish them. But with each re-generation using the process implemented by @therter this manual configuration of the taxonomy will be lost.

[p-a-s-c-a-l]

Users are able to create invalid study scenarios, e.g. by selecting a RCP even if the time period is historical:

Is there any possibility to implement a quick and simple validation for that? Otherwise we have to find another solution. e.g. at least add a static warning message. Or maybe use another list with predefined and valid TP/RCP combinations (if it's possible to set two different values from one selection list)?

[p-a-s-c-a-l]

Vulnerability ... This is still kind of a black box. No vulnerability-related resources available in the European Data Package, thus Data Tab for VA step is empty. Moreover, the vulnerability functions in the table look just like examples, not like real vulnerability functions (TODO: add some text):

Apparently, those vulnerability functions are not (yet?) used at all for impact calculation in EMIKAT. Can anybody shed some light on this, maybe @humerh @DenoBeno @bernhardsk ?

If there aren't any real VA functions available, we should remove this step until the situation has changed.

[p-a-s-c-a-l]

Twins ....

We've invested quite some effort in the implementation of the twins functionality, but without ever having a clear concept for getting real content (Hazard Twins, Exposure Twins) into the system. I don't think that this has changed and that there plans for (automatically) importing some Hazard Twins and Exposure Twins from data sources in the near future (=ASAP) @Itsman-AT ?

Without data, this is just another "proof-of-concept" that "just works" but nothing that provides real added value for end users. Although it's a pity, but if the situation doesn't improve it may be better to remove the twins from PROD CSIS. We can keep it enabled in DEV CSIS just for demonstration purposes, and can enable it again in PROD when we have something to offer apart from some test and demo entries.

[p-a-s-c-a-l]

Not a real showstopper, but something that should be fixed:

Scenario Selection is not needed here, in fact, it has no influence on the list of adaptation options, so it should be hidden.

[therter]

Regarding this issue

So we have to periodically re-generate the cities taxonomy as @therter described here. I wonder, if there is a possibility to a) automate or b) simplify this process?

I have created the script republish.sh. This script unpublishes all cities, which are not contained in the city shape file or the field heat_wave is false.

To run the script, the following postgres function should exists in the db:

CREATE OR REPLACE FUNCTION public.publish_cities(
	)
    RETURNS boolean
    LANGUAGE 'plpgsql'

    COST 100
    VOLATILE 
AS $BODY$

declare
begin
	--publish/unpublish the cities. The data is contained in the table raw.cities
	update taxonomy_term_field_data r set status = case when exists(select 1 from raw.cities where name ilike r.name and heat_wave is not null) then 1 else 0 end where tid in (select tid from taxonomy_term_data where vid = 'cities_regions');
	update taxonomy_term_field_revision r set status = case when exists(select 1 from raw.cities where name ilike r.name and heat_wave is not null) then 1 else 0 end where tid in (select tid from taxonomy_term_data where vid = 'cities_regions');
        --publish/unpublish countries
	update taxonomy_term_field_data re set status = case when exists(
		select 1 from taxonomy_term_field_revision r  join taxonomy_term__field_country country on (country.field_country_target_id = r.tid) join taxonomy_term_field_data city on (country.entity_id = city.tid) where city.status = 1 and r.tid = re.tid
	) then 1 else 0 end where tid in (select tid from taxonomy_term_data where vid = 'countries');
	update taxonomy_term_field_revision re set status = case when exists(
		select 1 from taxonomy_term_field_revision r  join taxonomy_term__field_country country on (country.field_country_target_id = r.tid) join taxonomy_term_field_data city on (country.entity_id = city.tid) where city.status = 1 and r.tid = re.tid
	) then 1 else 0 end where tid in (select tid from taxonomy_term_data where vid = 'countries');
	return true;
end

$BODY$;

The republish.sh script can be found on the server csis.myclimateservice.eu in the directory home/thorsten . I have not executed it on dev server yet.

[p-a-s-c-a-l]

This footer should be removed as it is no longer needed.

[p-a-s-c-a-l]

No a real showstopper but still annoying: We should disable the quick edit module (which doesn't seem that easy).

Reason: Regular Users don't see it (but the JS is executed in the background) and admins don't need it. This module seems to inject a lot of AJAX stuff into the pages which makes page loading not only slower but interferes also with UI Integration Tests. This is a known problem, btw.

[p-a-s-c-a-l]

Toggle edit of Map Component can cause too many EMIKAT re-calculations. See also clarity-h2020/map-component#87

[p-a-s-c-a-l]

Re(Calculation) is a serious issue. There is no clear indication when and why a re-calculation was triggered or not, e.g. it is not triggered when no data package is set, it is immediately triggered when the user changes the box of the study area in the map, etc. So this feature has to be implemented before going live.

[patrickkaleta]

Users are able to create invalid study scenarios, e.g. by selecting a RCP even if the time period is historical:

Is there any possibility to implement a quick and simple validation for that? Otherwise we have to find another solution. e.g. at least add a static warning message. Or maybe use another list with predefined and valid TP/RCP combinations (if it's possible to set two different values from one selection list)?

For now, I've added a text under the emission scenario selection telling the users to select meaningful combinations. Other solutions would require changing the data model, which would also require changes in the CSIS helpers module, so that it could continue to provide the selected scenario in the $studyInfo object.
If we find the time, we can adress this issue at some later point.

[patrickkaleta]

This footer should be removed as it is no longer needed.

This footer is created in a custom block, which I've now disabled.

[patrickkaleta]

No a real showstopper but still annoying: We should disable the quick edit module (which doesn't seem that easy).

Quick edit module is now uninstalled (in the mentioned link, the person actually wanted to get rid of all edit icons, not just the quick-edit).

The error message "Uncaught DOMException: Failed to execute 'setItem'..." is now gone.

[p-a-s-c-a-l]

Most of the usability showstoppers are resolved now, but one big issue remains Twins. Apart form the lack of useful content, the Twins Map isn't working properly due missing API key:

@Itsman-AT Any chance that this can be resolved? If not, we have to hide the twins tabs in the public beta.

[patrickkaleta]

Most of the usability showstoppers are resolved now, but one big issue remains Twins. Apart form the lack of useful content, the Twins Map isn't working properly due missing API key:

We switched the Twins Maps to use Leaflet now instead, so no Google API key is required anymore.

Regarding the usefulness of the currently available Twins in the system, I don't know for sure how much added value they bring for the users. I don't think they are completely useless, so we might just keep them for now and await initial feedback from users.

[p-a-s-c-a-l]

Google Maps are also referenced in the Data package / resource views, e.g. here:
https://csis.myclimateservice.eu/study/35/view/data

At least for the data package view having a 2nd map which just shows the spatial coverage of the DP is somewhat redundant. So it might be better to remove at this GoogleMap instead of replacing it by leaflet.

[patrickkaleta]

You're right, there's no need to show the same info twice. I removed the Google map.