bahnzumberg / zuugle-suchseite Goto Github PK

At the moment there are over 10k Tours in the database. The promise to the visitor is to show him/her only those, which are relevant for him/her. How do we determine "relevant"? It means from where the visitor lives, there is an existing route (An- und Abreise Fahrplan) to the hike with public transportation. So we need the city the visitor is living in, to be able to fulfill this promise.

But when he is visiting the page for the first time, we do not know where he is from. So this is our weak spot. On www.bahn-zum-berg.at we decided to show him some hikes anyhow. They might as well be not relevant to the visitor (no connection).

Ideally the visitor chooses a city by him/herself. Then the results are refreshed and only the relevant are shown. Easy peasy.
The visitor clicks on any of the initial presented hikes. This might be a hike, which is not reachable for him/her. We show the result anyhow - which means in fact, that we break in this case our promise. On www.bahn-zum-berg.at we wait till the visitor scrolled a little bit down and show him then a list of cities to select from. The cities are filtered on the country (derived from the domain) and ordered by two dimensions. Starting with the cities with an existing connection, then the cities without. Second dimension is the distance from the starting point of the tour, or the public transportation stop, the hike is starting at.

This way the visitor is nudged to select the city, we store the city in the cookie and show him after that only relevant hikes.

Please test the process (without cookie) as a new visitor at www.bahn-zum-berg.at. The process should work at Zuugle in the same way.

Footer like described in Figma for Mobile & Desktop: https://www.figma.com/file/qM4hoaxmGrrEEuTv4lL2lD/zuugle-redesign-2023-v3.0?type=design&node-id=0-1&t=g3UdMU8w26zmTY3s-0

Design the left top button including the symbol (which you can export from Figma):

Figma Design of the left top button for country change and link to 3 pages: https://www.figma.com/file/qM4hoaxmGrrEEuTv4lL2lD/zuugle-redesign-2023-v3.0?type=design&node-id=0-1&t=g3UdMU8w26zmTY3s-0

The 3 links to the pages are:
Über Zuugle: https://www.bahnzumberg.at/
Impressum: https://www.zuugle.at/imprint
Datenschutz: https://www.zuugle.at/privacy

menu_lang is two characters long. It defines the language the visitor gets the surface, the menu shown in.
It can be one of these values: de, ch, fr, it, sl
(Attention! sl = SL)

country_code is two characters long. It defines the top level domain.
It can be one of these values: AT, DE, CH, FR, IT, SL
The country code is stored as UPPER carachters in the database, to distinguish the value from menu_lang.

Both values should be logged with each search of the user into the table "logsearchphrase". The click on a detail page for one hike, should not be logged there.
The existing comlumns should continue to be filled.

After this issue #17 can be implemented.

This issue is depending on #18

I can switch between different zuugle domains: zuugle.at, zuugle.de, zuugle.ch, zuugle.it, zuugle.fr, zuugle.si to change the way the content is presented to me, as a visitor. I will be presented with the most popular / most selected cities and results.

In the PostgreSQL Database, there is a table called "logsearchphrase". There are all performed searches (by users) logged with a timestamp. This table should be used to create a result set, if there is no cookie yet and to create a result set, which is a good guess based on the information we have of the new visitor (e.g. domain name, menu language setting, and so on)

The new design is about to be finalised, need to activate the new file

Tracking issue for:

• https://github.com/bahnzumberg/zuugle-suchseite/security/code-scanning/1

The select of the new version of search bar is not performing. This happens only when we use the TEXT input on the modal

Since the last emergency restore of www.zuugle.at Matomo seems to be disabled again. Can we restore it somehow? There is a branch covering this topic. Can we merge this into the current development and create a hotfix for production?

After finishing the Upgrade of the used Javascript version (#7) we can create mobile apps using Capacitor https://capacitorjs.com/solution/react as recommended by https://github.com/angelika94

Need to improve the design of the modal/overlay to match the Figma design below:

https://github.com/orgs/bahnzumberg/projects/2?pane=issue&itemId=28717158#:~:text=https%3A//www.figma.com/proto/1PpoRQVVo1C59QnfODpNv1/zuugle%2Dredesign%2D2023%2Dv2.0%3Fnode%2Did%3D110%2D5679%26starting%2Dpoint%2Dnode%2Did%3D110%253A5679

https://user-images.githubusercontent.com/105971399/239732090-fe0e3120-402e-4ff6-b0f3-c6c6199bf533.png

PDF content should be in menu_lang as the website is.

There should be a new url parameter introduced, which defines/sets the menu_lang. Example: https://www.zuugle.at?city=wien&l=en

Use of the columns "internal_status" and "connection_url", "return_url" in table fahrplan should be removed.
In table tours the use of column "children" and "internal_status" should be removed. Is "publishing_date" used?

The follow up issue in the backend is https://github.com/orgs/bahnzumberg/projects/2/views/1?pane=issue&itemId=31349571

Matomo is already in place, but it tracks too little. We want the full logging, ideally without the need to set a cookie. If it is absolutely necessary to set a cookie, we will habe to introduce a cookie consent as well.

Production ID (9) should be used only on production, in all other cases use the Test project ID (11).

Matomo Production ID = 9
Matomo Test ID = 11

Searchbar, like described in Figma. Only the white bar. Search functionality as it was till today. The overlay while typing should be altered: The functionality till now can be removed and the autosuggest function will be implemented later with #12.

If the user has already a cookie set, which tells us his preferred menu language, we will take this language and present zuugle (regardless of country domain he is using) in the menu language.

If there is no cookie there yet, we try to guess his preferred language, by looking at the former combinations, which we logged in the database. This functionality is not available at this moment.

We are offering Deutsch, Italiano, Francais, English, Slovenski

Mobile:
https://www.figma.com/proto/1PpoRQVVo1C59QnfODpNv1/zuugle-redesign-2023-v2.0?page-id=0%3A1&node-id=28%3A1001&viewport=293%2C449%2C0.09&scaling=scale-down&starting-point-node-id=28%3A1001

Desktop:
https://www.figma.com/proto/1PpoRQVVo1C59QnfODpNv1/zuugle-redesign-2023-v2.0?page-id=110%3A5678&node-id=110%3A5679&viewport=545%2C804%2C0.16&scaling=scale-down&starting-point-node-id=110%3A5679

Version 3: Mobile & Desktop: https://www.figma.com/file/qM4hoaxmGrrEEuTv4lL2lD/zuugle-redesign-2023-v3.0?type=design&node-id=0-1&t=g3UdMU8w26zmTY3s-0

o Domain switch
o Language switch
o Search:

• Styling in Main/Result Page + Detail
• Dropdown styling

The filter gets extended by one section: Via a multiselect all available Languages can be selected in any combination. Firing this search will filter the search result on the selected languages (table "tour", column "text_lang").

o Fallback images (for map and tour image, see Figma “Fallback” section)
o “Öffi-Fahrplan” button in mobile view
o Styling for download buttons, when no connection was found for the selected day (currently, the buttons are not clickable and a error message is displayed down below)
o Testing of the design with long strings (for example: What happens if a value is so long that it has to be in a new line, does it break the design?)
o Testing fallback cases (what if one field is empty, is it displayed correctly in the UI?)

www.alpenvereinaktiv.com is using this feature: You can filter the results by zooming in and out on a specific region. This should work on Zuugle, too.

The objective is to increase security on Zuugle. We do not want anybody to link directly to the page, especially not to a detail page.

I found this text about CORS, which was already implemented by Clemens in V1.1. Maybe we should give it another try?

"Look into CORS. And make sure your server only allows access to specific origins.

If your JS is requesting data via XMLHttpRequest than on the backend - check if the X-Requested-With header is present and set to XMLHttpRequest. Without a proper CORS handshake this header will be absent.

That being said, this will only protect your API from being used by other front-end apps or from being accessed directly from a browser address bar - because browsers respect CORS. People can still forge requests programmatically/CLI and set headers to whatever they want.

So this is not actually "securing" just a way to prevent abuse & hotlinking"

The search bar is working as it should at the moment. The design has to be adapted on desktop and mobil version to match the figma design (https://www.figma.com/file/qM4hoaxmGrrEEuTv4lL2lD/zuugle-redesign-2023-v3.0?type=design&node-id=0-1&t=g3UdMU8w26zmTY3s-0)

As long, as not all translations are in place, the possibility to create a PDF should be limited to the languages the PDF is fully translated to. In the moment this is only German. So the PDF button should be only available, when the menu_language is DE.

Once https://github.com/orgs/bahnzumberg/projects/2/views/1?pane=issue&itemId=30353679 is implemented, this feature has to be deactived.

Remove old code and delete files, which are not used anymore.

Bearingpoint wrote: "Cleanup of old code and files (we did not delete the old files intentionally so there is a possibility to switch back while the new design is not yet finished)"

Translation in some places (e.g. “Öffi-Fahrplan”, “Für diesen Tag wurden keine Verbindungen gefunden.”, metrics of the Tour details, …)

After https://github.com/orgs/bahnzumberg/projects/2?pane=issue&itemId=31488652 is implemented, we have the information at hand which tours are duplicates of another. We should mark the duplicates, so that the visitor knows it is a duplicate and which is the original.

The visitor is opening one of our pages and we have to decide which language we should show him the surface/menu in:

1. The visitor has a cookie in which the menu_lang is already stored. Please use this value to present him the page. ("The customer is always right")
2. We have to guess, which language to show him. The query below shows the menu_lang we shozuld use. In the "where"-clause the top-level domain has to be set (e.g. www.zuugle.fr -> 'FR'). Now that we have the menu_lang we use it AND store it for the next visit in the users cookie or local storage.

SELECT
menu_lang,
COUNT() AS anzahl
FROM logsearchphrase
WHERE country_code='AT'
GROUP BY menu_lang
ORDER BY COUNT() DESC
LIMIT 1

We have a new design , see issue #41, but clicking on GO currently does not display the tours on the Main.js .

The index.html should contain dynamically changing information:

• < html lang="de" > (Description: The value should always show the two character code of the menu_lang: de/it/fr/sl)
• Translation: zuugle_description
• Translation: no_javascript
• Translation: helmet_title
• Translation: zuugle_description

The city selector is a very important overlay, which should help getting as quickly as possible the city (Heimatbahnhof) of the visitor. Only if we have this city, we can show the relevant results for the visitor).

The overlay should be used at the header, to select or to change the city. Additionally it should be used - accompanied with additional text - at all other situations, where there is a city value missing.

The basic list contains only cities of the country the vitor is visiting at the moment (Somebody using www.zuugle.de, would only see cities located in Germany). If he/she wants to see a city from another country, he/she has to switch. That should be offered, too.

Starting to type, is giving the visitor options of cities, which start with the already typed in characters. ("w" gives "Wien" and "Wr. Neustadt")

After the visitor selected an available city, the city is stored on the visitors computer, so that he/she does not have to select it once again. If he/she wants to change the city, he/she can do that via the same procedure.
The city is stored as described in #22

Figma: https://www.figma.com/proto/1PpoRQVVo1C59QnfODpNv1/zuugle-redesign-2023-v2.0?node-id=110-5679&starting-point-node-id=110%3A5679

Design language change button in the top right corner on all pages to match the design on figma (https://www.figma.com/file/qM4hoaxmGrrEEuTv4lL2lD/zuugle-redesign-2023-v3.0?type=design&node-id=0-1&t=g3UdMU8w26zmTY3s-0) on desktop and mobile devcices.

this is the 2nd step after City selector/functional/start-page:
City selector/functional/start-page

description:
In the case the user did not select a city and moves on from the start page to the result page or a detail page, we want to wait for a movement (scrolling) of the user and show him on the overlay explaining to him why it would be better to select a city . The overlay includes the cities as shown in Figma to select from.

Remarks:
done on Main page /
use the same component as in #24 except that the overlay would appear upon scrolling down the first time AND will contain additional text to encourage the user to actually select a city after searching for it.

Question : is there a real need for the detail page to be included? please explain the use case

The detail page of one specific hike is https://www.zuugle.at/tour?id=33427&city=wien&sort=relevanz&datum=2023-05-18
A precondition to this issue is, that the id for one tour stays unchanged. This is not yet secured and has to be ensured in the MySQL database. Nevertheless we can implement this feature with the current state of the PostgreSQL databse.

In the future the url should be https://www.zuugle.at/tour/tr676f55fdre465drr
Internally there should be a new table, which holds the key "tr676f55fdre465drr" and datetime, till it is valid. If it is still valid, it should show the result https://www.zuugle.at/tour?id=33427&city=wien&sort=relevanzdatum=2023-05-18 would have shown. So in the table additional infornmation has to be stored.

The whole idea behind this is to hide the id of the tour and the other parameters. We want to do that to enable our vistors to share the link among friends (via social media, mail, etc). The shared link should hold exactly the day with the time table ("Fahrplan") the visitor choose. As we do not want people to link to our result page from their website and implement a cheap way for them to get access to the time table we calculated with high effort, the shared url should expire after 20 days.

There should be a clean up job "npm run clean-database" which will be run once a day via cronjob, which deletes all outdated links (older than 20 days).

In the first version we offered several possibilities to sort the results. This was not used by the visitors, therefore we removed this feature in the "Drop Slovenia". Therefore the parameters still in use are not necessary anymore. They should be removed, if present (if called from the outside). Our own calls should not use them anymore.

Bearingpoint wrote: "The query param “sort=relevanz” is automatically appended for the detail page, but it’s not needed"

We will create a new page on Zuugle, which gets the coordinates from the browser. Maybe we will restrict it to mobile devices, as desktop coordinates over the landline are unreliable.

With this coordinates the page will search for hikes, crossing this point, or being very near this point. It will show these results in a list and alternatively on a map.

As the internet connection of the user could be slow, we will first test his internet speed and return very, very lightweigt html output. If it is strong, we show the results immediately. If it is slow, we will ask him to insert his e-mail address on a completely simplified and lean page and mail him the results.

The buttons PDF and GPX download should only be active, when the visitor has already selected his city. If not, the click on either of PDF or GPX button should be possibly, but should open up first an overlay, asking the visitor to select his or her city. See #24

When the database connection is lost an error message is shown - see screenshot.

Instead of this error message, the maintenace mode should be activated in Header.js (see below)

if (totalTours==0) {
return <Box className={"header-container"} style={{backgroundImage: backgroundImage}}>
<Box className={"header-text"}>
<Box sx={{display: "flex", alignItems: "center", marginBottom: "16px"}}>
<img src={/app_static/img/logo-white.png} height={"16px"} width={"29px"}/><Typography style={{fontSize: "16px", color: "#FFF", lineHeight: "16px", marginLeft: "5px"}}>{getDomainText()}

<Typography variant={"h1"}>
{t('start.wartungsmodus')}



}

Bearingpoint wrote: "Warning: “react_devtools_backend_compact.js:2367 Warning: Each child in a list should have a unique "key" prop.” - somewhere in the arrival component there are missing “key” props"

o Styling for arrival (“Anreise”)
o Tour-duration info
o Returns (“Rückreisen”)

Not in scope of this issue: Links to external sites (eg. ÖBB)

This is a question to be passed to Stefan, should the search remain the same way as in sigma or change it ? Another possibility : the upper limit of the search bar should match the upper border at the results overlay.

When I, as a visitor, start typing my search phrase(s), I want to be supported by the system. The system should show me similiar search phrases and next search words, based on the table "logsearchphrase" from similar visitors (same city, same menu language and so on).

Up to 5 autosuggest values will be offered below the search bar, when visitor starts to type.

This PostgreSQL query returns up to 5 results. The bold parts are the variables, which have to be set.
SELECT
lower(phrase) AS search_phrase,
COUNT()
FROM logsearchphrase
WHERE 1=1
city_slug = 'WIEN'
AND menu_lang ='DE'
AND search_time > CURRENT_DATE - INTERVAL '12 MONTH'
AND phrase LIKE 'XYZ%'
GROUP BY phrase
ORDER BY COUNT() DESC, phrase ASC
LIMIT 5

Desktop: The visitors can share the link via social media or e-mail. After the users clicks on the button, a selection of available options apears, from which he can select one. Facebook, Instragam, E-Mail should be covered.

Mobile: Ideally the standard sharing options on the mobile (iOS and Android) should be available and used.

Tracking issue for:

• https://github.com/bahnzumberg/zuugle-suchseite/security/code-scanning/2

Welchen Umbau wir auch immer vornehmen, die jetzt gültigen Links müssen weiterhin funktionieren, oder mittels Umleitungen berücksichtigt werden.

Beispiele:
https://www.zuugle.at/suche?p=alpenvereinaktiv&sort=relevanz&map=true
https://www.zuugle.at/?city=wien&sort=relevanz
https://www.zuugle.at/suche?city=wien&sort=relevanz
https://www.zuugle.at/suche?city=wien&sort=relevanz&map=true
https://www.zuugle.at/bischofshofen