Jobs pages

[friep]

could we have a job page next to newsletter or alternatively under "about us"?

we need to post job postings soon (early next week). Is this doable before the end of the week? Sorry for the short ETA. otherwise I can also just put them on the blog.

design proposal:

• /jobs : List of cards (similar to blog, can even keep the language indicator as "language requirement")
• individual pages: no special design necessary, just wysiwyg

[friep]

if we feel fancy we can have fields (and spots on the cards) for:

• FTE (text field)
• salary (text field)
• location (text field)

[KonradUdoHannes]

I think we can manage timewise. I'll can do most of the implementation and get back to @jstet if there is any major issues with setting up the new directus schema, which I havn't done before.

[KonradUdoHannes]

I created a first schema for Jobs and will now make up some fake positions as example data. @friep if you already have a real example, please try to enter it in directus when you have a chance and we can use it to start iterating over the schema design.

[KonradUdoHannes]

I made a draft PR to help with iterations, as the PR offers a link to a cloudflare preview page. So far the implementation contains basic scaffolding for the job pages, but essentially no details. In order to see the job pages on the preview site one has to manually navigate to /jobs as the jobs are not part of our navigation menu yet.

Otherwise the following ToDos/Open Points should be addressed next in my opinion

• [x] Add some sort of "How to apply" or "How to contact" filed to the data model. I guess this might be best suited as free text as it might be quite different from job to job
• [x] What kind of slugs to use for the jobs. Currently is simply uses the database ids of the jobs which are not readable at all. We could change this although it would remain questionable whether users would really navigate to specific job pages manually. On the other hand there might be value if the user can recognice the uri in the browser history.
• [x] Job slug pages still have to integrated in the static page building (essential for prod but not preview)
• [x] We need to decide where to put jobs in the navigation menu
• [x] Flesh out the design of the job cards
• [x] Flesh out the design of the job slug page

[friep]

awesome! thanks for the PR that's very helpful.

navigation and slugs

• navigation menu: further thinking about it, i think the footer would be ideal? typical location for "jobs" to appear, yet not too prominent (since we rarely have jobs).
• slugs: i'd vote for a slug field, similar to the blog posts

design of cards I like the current design. We could add/change:

• after thinking about it, we can omit the language identifier and field in directus. This will be obvious from the job posting itself and i would not "trick" English-only speakers by posting an English job ad which then requires very good German skills.
• info to put below the title, maybe with icons: FTE ( 🕐 ), Salary ( 💰 ) and location ( 📍)
• optional: add the tags that we also use for blog posts (and podcast episodes?) if that's possible. Then we could directly use something like "data literacy".

design of job slug page

• not sure whether we need to "how to a apply" as a separate field. It can just be a paragraph in the text.
• optional: a "future colleagues" section which is many-to-many people relation to add some faces to the anonymity.

[friep]

@KonradUdoHannes could we adapt the css for this subpage somehow to reduce the spacing between individual bullet points? Job descriptions tend to have bullet point lists by design and they currently take up so much space - see job description for the upcoming position: we'll still shorten it quite a bit (this is WIP) but it'll still have more than one bullet point list with several points each.

[KonradUdoHannes]

I looked into the line spacing issue and we can definitely do something about this in general.

For the particular real job post that we currently have in directus, there is however, some issue with the markup itself. For this post the list items don't just contain text, but each list item contains an html paragraph (<p>). I suggest to use more standard markup by removing the paragraphs from the lists and not work around the non-standard markup usage with more complicated css. This means that we should discuss what the goal behind these additional paragraphs was, check whether that goal is still important and if so find a different solution for it. For instance, when looking at the raw data in directus, it seems that the paragraphs contain some attributes, although I don't know what they are used for. If we need to maintain the attributes, we could maybe replace those paragraphs with <span> tags that don't carry styling by default.

Once the job post is in more standard form we can easily tweak the spacing until we are happy with it and it will apply the same way to other posts that are created with the WYSIWYG UI.

[KonradUdoHannes]

I updated the PR again and think the current situation is as follows

• We now have rough design for bot the job cards and the job pages including tags, colleagues
• [x] We still need to polish the details, such as deciding on exactly what summary information to display for cards and for detail page and decide where to use text and where to use maybe icons in the overviews. I think Icons are generally fine, but I'm struggling a little bit with distinguishing different dates (start date, application deadline, posting date) via icons.
• Jobs are part of the footer nav now
• We have verbose slugs
• [x] We still need to implement how different languages for jobs are displayed. I don't think I fully understand this yet in particular wrt. the German and the english page of our site.
  • Shall the site language affect which jobs are shown?
  • Shall the english page show jobs that are only available in German?
• [x] We still need to implement static build for jobs (I'll probably do this next to have it out of the way)
• [ ] We need a way to handle current/active job announcements and old ones. We might want to allow for a situation where an announcement does not accept new applications anymore, but is still available so it can easily be reviewed by candidates that are already in the application process. (This is maybe less of a priority and could also be done next week)
• [x] Address the list item spacing issues discussed above
• [ ] Address accessibility considerations with respect to the job page (probably also lower priority)

[KonradUdoHannes]

Jobs are now included in static build. This means that from a technical perspective we have everything essential to deploy the feature to production. There should therefore not be a problem by getting the feature done in time if we scope all the polishing work we still want to do accordingly.

[friep]

I updated the PR again and think the current situation is as follows

* We now have rough design for bot the job cards and the job pages including tags, colleagues

* [ ]  We still need to polish the details, such as deciding on exactly what summary information to display for cards and for detail page and decide where to use text and where to use maybe icons in the overviews. I think Icons are generally fine, but I'm struggling a little bit with distinguishing different dates (start date, application deadline, posting date) via icons.

The mix of bold text and icons is fine by me. my suggestions:

• omit the publication date (see answer to current/active announcments below).
• omit the ":" after each icon.
• also omit the organization for now: If we want to feature jobs from other organisations in the future, we could recycle the organization element from the project cards (i.e. in green above the title). but i feel, for now the header should be "Jobs at CorrelAid" and we should limit ourselves to "internal" jobs. If we want to cross-post jobs from other social organizations in the future (like a job board), that'd be a different use case imo.

* Jobs are part of the footer nav now

awesome! maybe we have to split into two lines? looks suspiciously low on margins on mobile preview on firefox.

* We have verbose slugs

thanks! ✅

* [ ]  We still need to implement how different languages for jobs are displayed. I don't think I fully understand this yet in particular wrt. the German and the english page of our site.

  * Shall the site language affect which jobs are shown?
  * Shall the english page show jobs that are only available in German?

My approach would be to draw inspiration from the technical implementation of the blog posts where @jstet implemented some sort of logic that uses the text of the available language if there is no translation available. in my head, we would..

• see all jobs on both pages listing regardless of language (blog post approach)
• omit the language indicator on the card because it'd be confusing as to whether it indicates language requirements or just availability of translations, replace with 🗣️ icon in the card that shows the required languages. I think that'd make it less confusing
• job subpage draws content from the available translation or translates if there is a translation (but i don't see myself translating job ads into German if the job is in English or into English if the job requires German

* [x]  We still need to implement static build for jobs (I'll probably do this next to have it out of the way)

* [ ]  We need a way to handle current/active job announcements and old ones. We might want to allow for a situation where an announcement does not accept new applications anymore, but is still available so it can easily be reviewed by candidates that are already in the application process. (This is maybe less of a priority and could also be done next week)

similar to events , i'd put postings under "past job postings" if the application deadline has expired. this should make it clear which job postings are "current".

* [ ]  Address the list item spacing issues discussed above

i removed the additional classes/css - thanks for the hint: I assumed the "remove formatting" button in directus would remove all google docs formatting but apparently some things are sticky or make sense that they stick around (extra paragraph tags ). I'll document this in the directus docs that i want to put into docs.correlaid.org. still i feel we could reduce the spacing a tiny bit.. also for the other pages? but if the current state is best practice, i'm fine with it.

* [ ]  Address accessibility considerations with respect to the job page (probably also lower priority)

would this mean splitting the text into multiple fields to enable easier aria label tagging? or what's the problem? :)

[friep]

other issues: card titles are not translated yet (Published --> Veröffentlicht etc.)

[jstet]

@KonradUdoHannes do you need help with this? I can work on this Monday for some hours.

[KonradUdoHannes]

I made a couple of updates as discussed.

• publication date removed
• organization removed
• title -> "Jobs at CorrelAid"
• footer wraps at small width
• removed language icon and display the job language with the speaking head
• language handling similar to blog posts
• adjusted list item line spacing. I only adjusted this a little because I found it looks very crowded otherwise on small screen sizes where individual list items span several lines. But if desired we can try to reduce it more.

I still see the following open points

• [ ] Aria labelling (lower priority)
• [x] Current/Old job announcements (lower priority)
• [x] Adjust the queries to only retrieve published jobs (I'll do this tomorrow. Its the easiest way to get rid of the test jobs but keep them for local testing)
• [x] We could discuss whether we are happy with the job details on the cards vs. the summary box on the job page. Originally I assumed that the card would display less information, but right now the only difference is the salary. We could align both or keep it separate if we think the summary box might eventually end up with even more information.
• [x] A bit of code cleanup related to now pretty much finalized data models.

I'll finish up the points relevant for go-live tomorrow and would then be ready to push this to prod. That way any job that is then turned to published state should display on the webpage (after rebuild that happens automatically every night)

@jstet Regarding help, I think the lower priority tasks can be done next week and I could either use active help or simply some explanation regarding the aria labelling as I've never worked on these before.

[friep]

thanks @KonradUdoHannes ! looks super slick already :)

• I think "Art" would be better than "Vertragsart" (then we can also leave open the possibility to post volunteer "jobs").
• i played around with different mobile views in firefox. most of them look good but iphone 11 does still have the margin problem. maybe you can look into it again? (but if it's too tricky, i don't really care :D)
• talking of margins: the blue box on the subpage does not have padding (that's the stuff outside of it right?) on certain devices.
• i think adding the 💰 is a good idea: i like transparency and also would be good if we end up extending it to unpaid "volunteer opportunities" (ugh)

i agree with you on pushing this to prod and then creating follow up issues with priorities accessibilty > active/old

before you push to prod, could you please also un-publish the actual job then - publication will be on Wednesday. re development: i think you can always publish / unpublish during development and because of the static build it wouldn't end up on prod?!

[KonradUdoHannes]

@friep I'll address the issues and push it to prod then without any jobs.

As a general issue we might want to consider introducing a status such as preview to all jobs/events/blogposts etc. and set up a configuration option whether or not to show preview (in addition to published). That way we could set up dev deployments to show previews but make sure that they don't show up in prod.

Regarding the box, I'll noticed that too and I think its a general Issue of our Box component, which we also use for Event subpages. I'll see whether I can get an easy fix that works for both. Otherwise I'll leave it as a separate issue.

[friep]

yes to preview - that issue came up with regards to blog post previews on slack yesterday as well. yes to all other points!

[KonradUdoHannes]

I created an issue for the preview functionality #500

[jstet]

@jstet Regarding help, I think the lower priority tasks can be done next week and I could either use active help or simply some explanation regarding the aria labelling as I've never worked on these before.

I will take a look at the UI on monday and see what kind of aria labeling we could need. in general, i tried to use https://www.deque.com/axe/devtools/ to check accessibility.

[KonradUdoHannes]

Functionality so far is merged with main without any published jobs. Once a job is published it should go live with the next static build.

[jstet]

Thanks a lot for the quick implementation of this feature!

Suggestions regarding design:

• I would left adjust the text like we do it for events:
• I vote for just writing "Jobs" instead of "Jobs at CorrelAid" because i feel like this redundant and other page titles are one word as well.
• Comparing the card of a job to other cars, i feel like there is too much padding below the details part (starting with bewerbungsschluss)

• We should probably unify our icons. I would also enlarge the job icons a bit to highlight them.

Aria labeling:

I reasearched and i think we are using the aria label wrong, as its only supposed to be used with interactive elements. I think this would be the correct way:

<span class="watch-icon" aria-hidden="true">[Watch icon HTML here]</span>
<span class="sr-only">Event start time</span>

[KonradUdoHannes]

I was also wondering about unifying our icons. But am wondering about the following considerations. @jstet what are your thoughts on this.

• The svgs seem to have the disadvantages
  • we have to get them somewhere (do we have a good source?)
  • They generate a little bit more clutter in the codebase with extra files and imports which makes it more complex to add a new one.
• Emojis have the disadvantages
  • doesn't scale at will (but scales with font size. Doe we realy need more)
  • Less Control over the exact appearance (for instance color)

With these considerations I'm not sure of what's actually the better choice. But I think if we decide for svg we should document the creation/process for the svgs so we could easily keep it uniform in the future.

[KonradUdoHannes]

I'll implement #512 first before continuing with this. This should working with jobs easier and less error prone wrt accidental publishing of test data for jobs.

[KonradUdoHannes]

I looked a bit into aria labelling and I don't think it applies to the job page as all the content is explained pretty well by the displayed text. With that I'll close this issue.

I'll move the topic of unifying svg/emojis or events and jobs to a separate issue (#519).

I adjusted padding mentioned above slightly. If we want to do further slight adjustments that can probably be done outside of an issue. The same is true for the pages heading (Jobs vs Jobs at CorrelAid). @friep and @jstet had different opinions on this but either way its very easy to change as its part of the directus page design.

[jstet]

I looked a bit into aria labelling and I don't think it applies to the job page as all the content is explained pretty well by the displayed text. With that I'll close this issue.

Wouldnt it be best practice be to add labelling to stuff like the location icon?