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?.
Absolutely - See below.
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.
AFAIK AJAX doesn't provide any new widgets by itself - It's just a new way to interact with the server. And as far as I can see, AJAX is
not going to make the current forms any better. Beware the hype ;)
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?
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".
Whoah, that's a lot of work. I propose a different, bottom-up approach, which I think will be less work and fulfill a+b without the need for any others. The following should be done for each form:
- Work out which input we absolutely, positively need from the user, which are optional, and which would be nice to have. This is probably pretty much worked out already, but e.g. skill experience may not be interesting to some employers (they may be looking for a student or junior).
- Create a form with no _javascript_ to fill in all the data (even the "nice to have").
- Style the form for graphical browsers.
- Add _javascript_ to hide / show the "nice to have" and / or the optional fields*.
- Add _javascript_ to modify the markup + style so that it's nice and dynamic the way we want it.
Voilá! Working JS and non-JS forms, accessible and flexible.
* The point of this is to make sure nobody is scared off by the forms the first time they see them. I believe the "nice to have" fields should be hidden by default, but for the optional ones it depends on how big the form will be with them. Maybe they could always be shown.
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.
I strongly disagree. There are plenty of users which for various reasons won't / can't use _javascript_:
- Security policies / paranoia.
- Using a non-graphical browser, e.g. voice, braille, or text.
- Using a light-weight browser, e.g., on a mobile phone or PDA.
- Using a browser with a broken _javascript_ implementation (IE, anyone?)
Some reasons why a CLI application is a bad idea:
- Lots of duplicated work.
- Many open source enthusiasts and developers are still using Windows primarily. Some OSS projects, like TortoiseCVS, are Windows-only.
- If someone is unwilling to enable _javascript_ or get a _javascript_-enabled browser to view our site, why would they go through the bother of installing our application?
In conclusion, by building bottom-up, we make sure
anyone can use the forms, and that people with _javascript_ and CSS support get a nice experience. On the contrary, by locking onto _javascript_, we would completely exclude some people, and break
accessibility laws in several countries, including the U.S..