They can't. IMO, the interface should be completely restructured. It's an unfamiliar way to fill in such information, which is bound to confuse users (it sure confused me, especially the several steps necessary to fill in a single skill) and turn away business as a consequence. Also note that sites like
Monster and
JobUp
accept web pages as job posts, with a couple extra values for contact information and a website link.
A little brainstorming:
We could give employers the option of sending us a file (accepting only certain extensions), and then use an iFrame or DIV with the right MIME type to include the file in the page. If we allow this, we'll have to be able to check the files for exploits or otherwise bad (
e.g., crashing browsers) content automatically. Is this possible with current open source tools? Some additional data should be mandatory, with the option to add clarifications using an interface which does a similar job to the current one.
To enable non-_javascript_ users for any form like this is easy, you just have to accept that they'll need to click a button every time the markup should change, and program thereafter. For example, to enable the secondary selection fields for the skills, you'd have a button to push (preferably near the field) to push after selecting a value to reload the page with the secondary selection fields enabled. This button would be removed by the same _javascript_ which enables the functionality without the need to reload the page.
We should give the users the possibility to fill in other skills
than the ones we have made available. There is no way we can keep our
lists exhaustive, and
Jakob Nielsen has found huge drop-downs to be a big annoyance and error-prone, so some users will probably be more comfortable filling in text.
Why do we have so many currencies? If we keep them, we'll
have to have some way to compare values in different currencies automatically, using current exchange rates from a reputable source. If the search doesn't convert currencies, users will stop searching or get the wrong information. If users have to go somewhere else to convert values all the time, they'll stop using GNU Herds. If we use a single currency the users will have to convert when inserting new values, and the exact value will normally be slightly incorrect, but at least we don't have to do a metric ton of programming to get around it, and users won't have to scroll through a huge list to find their own currency.
Alternative skill selection designs if users have to fill in our values:
Multi-select lists (grouped by category) and a second page where users specify their proficiency in each of the previously selected skills.
Pros:
- Enables fast selection of skills.
- Enables quick editing of skill levels (pre-selection of the skill (as in the current interface) is not necessary).
- Doesn't require _javascript_.
Cons:
- Users unfamiliar with multi-selection lists would require a notice saying something like "Hold down CTRL or the Apple button to (un-)select several skills".
- Some users will still have problems selecting correctly. It's easy to forget holding down the correct button.
- Two pages, with the extra programming and browser navigation that requires.
- Long lists. Scrolling multi-selection lists are even more annoying, so they should be avoided.
A single page listing the skills (grouped by category) with one skill per line, including the description and the knowledge / experience selection lists.
Pros:
- The whole list can be skimmed and searched, CTRL-f style.
- Minimal widget interaction (two per skill)
- Very easy to program (no navigation needed).
- Doesn't require _javascript_.
Cons:
- Not quite as fast to get an overview of the selected skills as with the previous solution
- The page would be quite long.