Improvements on ApplicationForm #133
Replies: 8 comments 13 replies
-
|
Merging |
Beta Was this translation helpful? Give feedback.
-
|
From @JamesTheClarke Currently the Time Zone selection has a couple of issues which make it less userfriendly for applicants: 1.) Each single timezone has multiple representatives making the drop down field much longer than needed. E.g. UTC-7 is represented with 16 example cities. Each timezone should be represented with 1-3 examples max. 2.) Our community is mostly CET (UTC+1) / CEST (UTC+2) focused, yet the drag and drop field starts at UTC-11. Can we select by default CET / CEST and then have the drag and drop go up and down in sections? 3.) The Time zone selection menu should have a short explanation or question below it to clarify what we are asking. In our current application form on enjin this would be "What UTC time zone are you from?" as well as a link so people can find their timezone accurately: https://www.timeanddate.com/time/map/ Sidenote: does the Time Zone selection menu in the application form automatically update UTC according to summer time shifts? I.e. Central European Time (CET) is UTC+1 but Central European Summer Time (CEST) is UTC+2. Both are located in the Berlin/Paris region. |
Beta Was this translation helpful? Give feedback.
-
|
From @milivojm Hi! Timezone dropdown is created using data from here. This in turn is filled from https://docs.microsoft.com/en-us/dotnet/api/system.timezoneinfo.getsystemtimezones?view=net-6.0 |
Beta Was this translation helpful? Give feedback.
-
|
From @milivojm
It's unlikely. See https://stackoverflow.com/questions/2961848/how-to-use-timezoneinfo-to-get-local-time-during-daylight-saving-time for more. |
Beta Was this translation helpful? Give feedback.
-
|
From @JamesTheClarke
Is it possible for us to pull that data and then pre-select UTC+1 as the default option? Because as is the vast majority of our users will currently have to scroll down from UTC-11 to UTC-1, UTC+0, UTC+1 or UTC+2. Considering the amount of different options for each UTC in the list that's a lot of unecessary scrolling we could optimise for them. |
Beta Was this translation helpful? Give feedback.
-
|
From @milivojm Yes, it is. It's also possible to filter out unwanted time zones. |
Beta Was this translation helpful? Give feedback.
-
|
From @JamesTheClarke The nickname field in the application could be improved with the following changes:
Detailed nicknaming convention:
|
Beta Was this translation helpful? Give feedback.
-
|
From @enrico-ghidoni The help text was changed to
Concerning nickname validation, it already happens and all the checks are in place. It's not asynchronous (as in, the nickname is verified once you submit the form and not when you type in the nickname itself). |
Beta Was this translation helpful? Give feedback.
-
|
I agree that the suggested text is too large. I that case I still propose to change it to Then the automatic validation can handle the rest, tested a few combinations and the error message was always easy to understand, so it should suffice on it's own without further help text. Regarding odd capitalisation: as long as Interviewing Manager and SSgts can manually adjust their nickname on the Rooster we'll be fine. |
Beta Was this translation helpful? Give feedback.
-
|
From @JamesTheClarke https://rooster.carpenoctem.co/Roster/ApplicationForm/ListApplications Sidenote: I'd rename Main issue: currently there is no tracking of who accepted or rejected applications and why. The following features would be great to keep similar records to our current enjin application process.
|
Beta Was this translation helpful? Give feedback.
-
|
From @enrico-ghidoni Activity logs are a planned feature, see #131. The core idea is that every action performed either by users or by the system will get reported to allow for better tracing of who did what and when. From there it will be trivial to add those details to the list of application forms. Concerning private and public comments on the application form, we'll keep this on the to-do list. I'm wondering whether it's necessary for replacing the old Roster or not. |
Beta Was this translation helpful? Give feedback.
-
|
From @JamesTheClarke
This feature would definitely still be very appreciated. The onboarding process isn't always handled by the same person at the three different stages. Thus it can be very helpful to look up what another person has observed during an Interview for example or what kind of redflags were noticed in the application. For record keeping it was often also useful in the past when an escalation occured and I was able to check if anyone noticed something early on or if that person kinda flew under the radar. Currently enjin has some limitations in collaborative onboarding, thus interviewers mix the roster, the application comment section the interviewing discord channel and the forums to share information, however that means sometimes you have to look in various areas to get up to speed. If possible it would be ideal if the new roster could track the various stages of the onboarding process and become the single point of information storage / sharing for all involved staff members. |
Beta Was this translation helpful? Give feedback.
-
|
From @enrico-ghidoni Don't get me wrong I agree that streamlining the whole workflow is the end-goal of Rooster. I'm just trying to filter out features that are critical for v1 and those that will be a good addition later down the line. I noticed old Roster has a "Notes" section for each recruit (and member in general). Not a big fan of generic note text. We can use that a temporary solution if required and move to a more structured system as you mentioned in your first message. |
Beta Was this translation helpful? Give feedback.
-
|
I can agree with the private comments for a later version, though I still maintain that any new solution for our application process should ideally offer the same functionality as our current process before roll out - this would not be a new feature put on hold but an existing one temporarily removed which could impact acceptance from current users.
The last restricted tickbox is a nice-to-have feature for the deluxe version of the Rooster. In the beginning in could just be a rudimentary tickbox tag to complete the recruitment process. EDIT: scratch that, just accepted another test acccount and realised that those labels already exist. EDIT2: is there an undo-button for misclicks? all the label buttons are very close to each other and it can be easy to click on the wrong button by accident. EDIT3: there's no |
Beta Was this translation helpful? Give feedback.
-
|
From @JamesTheClarke When selecting
|
Beta Was this translation helpful? Give feedback.
-
|
From @enrico-ghidoni This wasn't implemented due to lack of time and focus being on other features. Personally I'd take out the help text (the one saying that by picking "other" you can specify the pronouns) for the time being as it's not a critical feature. What could fill the gap before the feature is implemented? Interviewer can ask the applicant what the preferred pronouns are and outline them in the recruit feedback on Enjin. |
Beta Was this translation helpful? Give feedback.
-
|
I agree that this could be done manually via the Recruit feedback thread by the interviewer, however, the reason we implemented it in the form is because sometimes sharing vital information like that gets forgotten, either by the interviewer asking during the interview stage or them forgetting to post the information later in the relevant thread. Not to mention that sometimes people post stuff on Discord instead of the feedback thread and information gets spread thin across several channels. In short, while doable via the forums it re-introduces several potential manual failstages that could be avoided by adding a custom text field. If possible we should include this for v1 to avoid headaches in the long run as it is an existing feature of our current enjin application form. |
Beta Was this translation helpful? Give feedback.
-
|
From @JamesTheClarke In my view the Application Form should be limited to what we need to initially process a recruit. If the form is too lenghty it can be intimidating and potentially deter people from filling it out. The following field should not be present in the application but instead be able to be edited by interviewers, interviewing manager, member manager and ssgts in the member profile during different stages of the onboarding process (similar to how interviewers currently add the BI account username after mod assessment & bootcamp):
This would cut six fields from the application form and the most important three (Discord, BI Account and TS ID) can be filled in by Interviewers at different stages of the onboarding process. |
Beta Was this translation helpful? Give feedback.
-
|
Minor bug: I've been testing out different combinations of Nicknames to ensure the automated check response are accurate so the end user knows what they have to change. The checks held true for every combination except one: managed to get this through with the wrong automated response.
|
Beta Was this translation helpful? Give feedback.
-
|
Possibly caused by the "letters only" condition in `src/Roster.Core/Domain/MemberNickname.cs:29. Should be updated to allow for white spaces as the white space maximum condition precedes the one under consideration. |
Beta Was this translation helpful? Give feedback.
-
|
Gonna summarize the proposed changes here so we have an overall view of how big of a task this could be as well as the decision to either implement the change before 1 Missing form fields and rewording of existing ones
2 Making the
|
Beta Was this translation helpful? Give feedback.
-
Currently only the fields
NicknameandEmailare mandatory to fill in, all other fields can be skipped because they are either not enforced or pre-selected (case for DoB, TZ and pronouns).The following fields should be mandatory to fill out for a complete application:
Where did you find us?currently missing application field, but very important to know where our recruitment efforts should be focused on. Could be improved over our current enjin application form by giving six drop-down options:Language skill levelshould be renamed toWhat is your English skill level?as most of us are non native English speakers - Language skill level is a bit misleading as it could be interpreted with regards to their native languageHow much experience do you have playing with Arma series?should be renamed toHow much experience do you have playing the Arma series? What was your first Arma game?because "playing with Arma series" is grammatically a bit wonky.Which Arma mods have you been using so far?Have you previously been a part of similar communities?currently missing application field, this is often used by interviewers to get a sense of two things a.) what type of communities they have frequented before (milsim, role-play, casual etc.) and b.) if they are potentially a "community-hopper", some folks who list 5 or 6 units and are 17 or 18 are potentially getting kicked out repeatedly and move from place to place. Obviously a subjective measurement, but a good potential red flag indicator nonetheless to have for interviewers.Where do you see yourself in the community, any specific roles or activities?Tell us a little about yourself.Owned DLCs (hold control for multiple selection)should be expanded with anoneoption in order to make the field mandatory.Beta Was this translation helpful? Give feedback.
All reactions