Re: [GNU Herds service]: Set of options: JavaScript (yes/no), AJAX, CLI app, desktop app, ...

[Davi Leal]

Victor Engmark wrote:
> MJ Ray wrote:
> > So how do users of non-JavaScript-enabled browser use that page?
>
> 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.

I forget to comment that currently, besides to manage the Skills, JavaScript 
is being used to manage a lot of others things.  Will we actually be able to 
remove completely the JavaScript requirement?.  If so, we should find 
a 'solution' to each one of the below uses:

  $ ls -l Layer-0__Site_entry_point/scripts/

    job_offer_Address.js     -- .disabled = true/false.
    job_offer_evalDisplay.js -- Enable or disable the display
                                of AcademicQualification and
                                EstimatedEffort divisions.

    job_offer.js           -- Skills, Languages, and others initializations.
    job_offer_Languages.js -- Similar to the skills management but simpler.
    job_offer_Skills.js    -- What you have exposed in your previous email.

    job_offer_VacancyTitle.js -- To show to the employer the automatically
                                 generated title which will get her job
                                 offers. It is a RMS requirement, that the
                                 employer be unabled to free-fill the job
                                 title;
                  VacancyTitle = ProfessionalProfileList + SkillList + ...


    popup.js  -- It is an additional help which we offer to the user,
                 but only if he has JavaScript enabled.


    qualifications_Contributions.js -- Add/Delete contributions.

    qualifications.js            -- idem than JobOffers
    qualifications_Languages.js  -- idem than JobOffers
    qualifications_Skills.js     -- idem than JobOffers


    utils.js  -- Used to raise the PopUp of the Skill Guide or map.



I have read the below Victor's comments and my current conclusion it that 
removing the JavaScript requirement we will get very large forms, less 
friendly, and more complexity, due to the above functionality which I will 
have to take into account too.  That could turn away business too.  Anyway, I 
agree with Victor that filling the current JobOffer form  sucks :P

I have even thought, as Antenore exposed some months ago, about developing a 
CLI application which would make it easier to 'define' JobOffers and  
Qualifications; sending the final XML file to a GNU Herds web service.

As pointed at one of the Victor's links, the set of widget to develop a webapp 
are very limited. AJAX has been the proposed solution by Google.

The GNU Herds service could offer a set-of-option, as previously commented by 
Antenore.  Choose any combination of the below options:

 (0) Webapp which uses AJAX only for complex forms
 (a) Webapp which requires JavaScript (as the current one)
 (b) Webapp without any JavaScript (as MJ & Victor propose?)
 (c) CLI application to connect to web service (as Antenore proposed)
 (d) Desktop application
 (?) any more?

Note that in any way we will keep the classic web site for the static content 
and simple forms. As Google does. Google does not use AJAX for the form which 
change the settings.

If we had 50 developers I would choose to develop all: (0), (b) and (c). That 
is to say, (0) and (b), and (c) via the gnuherds API, as Google has done. 
Note that Google has its "Google API".

I do not like the option (d) due to there are a lot of operating systems; so 
would be needed to be a portable desktop-app.



But the main point is know what the *users* want. It depends on the 'kind' of 
user:

  * Normal users will have not any problem to use a webapp which
    requires JavaScript (a).

    Note that anyway we should analyze the 'unfamiliar' problem
    of the JobOffer and Qualifications forms, exposed by Victor.

  * The 'kind' of users used to browse with JavaScript disabled,
    or from a browser which does not support JavaScript, could
    use the CLI application (c). Taking into account that almost
    all that users will use Unix, developing such CLI app will
    not be too much works. Just an script.


Abstract:

  Each time we say we are using JavaScript, one guys says:
      How do users of non-JavaScript-enabled browser?

  My reply would be:
      Use the CLI app



P.S.: All this is guessing. Of course, I am not sure.


I will reply to the below subjects after we decide what set-of-options we are 
going to develop. I think we are not in a hurry.

> A little brainstorming:
[...]

> Alternative skill selection designs if users have to fill in our values:
[...]

> Somebody else is sure to come up with something better, but after reading a
> lot of usability advice, I'm pretty sure that one of our requirements
> should be to avoid any novel interaction models.

Davi