[isf-wifidog] Picking an AJAX library for wifidog
janes.rob at gmail.com
Sam 29 Avr 13:34:17 EDT 2006
First of all, here's some links:
Dojo - http://dojotoolkit.org
json - http://en.wikipedia.org/wiki/JSON
ajaxian - http://www.ajaxian.com
prototype - http://prototype.conio.net - there are php libraries for
this, probably mvc
scriptaculous - http://script.aculo.us - derivative of prototype
mochikit - http://mochikit.com/ - derivative of prototype
rico - http://openrico.org - also a derivative of prototype - i've heard
this is buggy
Now, here's my two cents.
The drag and drop features of prototype would be really nice to have on
the content layout page. I really dislike the current form based page.
Benoit to start this thread. So, I'll explain what I did and try to
separate my stuff from the ajax bandwagon.
First of all the prototype library is great, and I am totally on for
that. I'm actually using it in other projects, so I know of what I
speak when I say that I think it's great. However, the prototype
library has nothing in it for form usability. There are some handy
things for forms, like the $F function which really helps when you don't
want to mess with the dom for select form elements, and Form.getInputs
or getElements is really nice for generic loops and some quick json or
query building. There's also short cuts for setting the focus field,
disabling the entire form, yada yada yada. But, all in all we've just
for a prototype one liner that might be a bit easier to read, and comes
(prototype is full of constructs that trigger warning messages).
Rather than being guided by some misgiven attempt to fix things right,
it was instead driven by complaints by actual hotspot owners, one in
particular, who when turning on the wifidog gateway was inundated with
complaints from customers about the unusable forms wifidog-auth throws
up. The complaints were fair and plainly obvious when they were pointed
Issues pointed out by vendors:
* buttons should look like buttons and shouldn't be hard to find.
* links that do a button's job should look like buttons.
* errors need to look like errors and not loose their context.
* login and signup pages need better help text.
* navigation help.
I'll admit that some of the issues were exacerbated by customizations we
had made earlier. Throwing in a buggy checkout from the bleeding edge
certainly didn't help. (mental note: verify all pages of a new checkout
before cutting over). Setting those aside, the issues were still there
in the stock pages.
People seemed to be having trouble with the forms, and traversing the
login/signup and portal redirection process. The ancilliary functions
of change password, resend validation, i need help, i forgot my
password, i forgot my userid, were confusing and not especially
helpful. The i need help throws up a faq page that assumes you already
know what you are doing. We at Wireless Toronto find that an large
number of newcomers never bother to validate their account. That seems
to strongly suggest by itself that there are usability problems with the
website, let alone the complaints from the innundated hotspot owners.
On the form usability side I'd add
* rollover actions where there is an action (lets the user know
something is there)
* forms should validate themselves. Gives immediate contextual help.
* form fields in error should get the cursor focus.
* links that go to another website should open another window and not
leave the portal page. Given the lack of navigation aids throughout the
website I think this is important. Lack of navigational aids is another
point, but not one related to forms.
* click actions should have a visible response, always. I found a lot
of pages gave no notice that anything was done after you clicked the
* form navigation
* form validation
* error messages
There are a few things in prototype and other libraries to help out with
this, but not a lot. Mostly you replace one set of problems with
another, and a dependency on an external library of limited support. In
my experience, the above four issues in environments like ours (non-mvc
templating) are always custom built. Prototype shines in the mvc
environments like ruby on rails and jsp. It's strengths are cross
browser support, ajax, asynchronous event handling, and special effects
like drag and drop or nifty magic for making things appear and
disappear. Prototype is all about making (asynchronous) dynamic content
feasible and usable. Oh - it's also for people who like ruby style
There is really nothing in prototype for the above four things.
Prototype really only makes sense if you have your own dynamic content,
and at this time wifidog-auth doesn't have any of it's own dynamic
content. Sure, there's the google maps and some rss stuff, but all this
is cookie cutter stuff embedding content and putting other website
servers in the drivers seat. I mean, prototype is great, but until
wifidog-auth starts off in a new direction I'd have to say that
prototype is of limited utility.
François Proulx wrote:
> huh ? script.aculo.us in itself provides some cool special effects
> and some advanced Web UI elements that we might consider, but I doubt
> Wifidog really needs that, maybe as a bonus, but Benoit is asking for
> an AJAX framework.
> Ideally I would suggest something that is based upon Prototype
> (script.aculo.us already uses it), since it's the most active, most
> complete, cross browser and efficient library out there, but there it
> only provides the client side part. There are a few good framework
> out there, but they are solid state and cannot be used sporadically
> (Symfony for example is a PHP clone of Ruby on Rails and Zephyr is
> very similar).
> This page lists the PHP frameworks for script.aculo.us
> So there is no out-of-the-box solution for Wifidog, we will probably
> have to code our own server-side responder, but let's make it very
> flexible and scalable by abstracting in classes the parsing logic. So
> one entry point with a few parameters to load the appropriate
> responding class...
> Documentation : http://wiki.script.aculo.us/scriptaculous/show/Prototype
> Prototype dissected : http://www.snook.ca/archives/prototype1280.png
> The biggest advantage of using Prototype is the richness of its
> client side libraries and it abstracts all common crossbrowser
> problematic calls by choosing the appropriate equivalent. Prototype
> also enables us to use the Event-Selector library for managing very
> elements) using a clever CSS-selectors based system.
> On 24-Apr-2006, at 6:40 PM, Benjamin Crulli wrote:
>> Scriptaculous ?
>> On 4/24/06, Benoit Grégoire <bock at step.polymtl.ca> wrote:
>>> We have to pick one, and only one soon, before UI hacking
>>> degenerates in a
>>> mess of libraries and custom implementation.
>>> I have no strong opinions on which one to chose.
>>> Important factors I can think of:
>>> -Good PHP integration
>>> -Can be integrated in our class and UI separation properly
>>> (especially when
>>> setting up it's responders).
>>> -Good documentation
>>> Benoit Grégoire, http://benoitg.coeus.ca/
>>> WiFiDog mailing list
>>> WiFiDog at listes.ilesansfil.org
>> Ben Crulli
>> WiFiDog mailing list
>> WiFiDog at listes.ilesansfil.org
> WiFiDog mailing list
> WiFiDog at listes.ilesansfil.org
More information about the WiFiDog