[isf-wifidog] Picking an AJAX library for wifidog

Rob Janes 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.

I suspect that my recent checkin of javascripting is what prompted 
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 
traded a standard pure javascript one liner with cross browser support 
for a prototype one liner that might be a bit easier to read, and comes 
with a whole bunch of warning messages in the javascript console 
(prototype is full of constructs that trigger warning messages).

The javascript checkins I put forward were all about form usability.  
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 
out.

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 
submit button.

The javascripting I did was all about
* form navigation
* form validation
* error messages
* navigation

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 
iterators.

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.

-rob

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
> http://wiki.script.aculo.us/scriptaculous/show/IntegrationWithPHP
>
> 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...
>
> http://prototype.conio.net/
> 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  
> cleanly Javascript events (click, drag, timer etc... on html  
> elements) using a clever CSS-selectors based system.
>
> http://www.encytemedia.com/event-selectors/
>
> 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
>>> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
>>>
>>>
>>>
>>
>>
>> -- 
>> Ben Crulli
>> _______________________________________________
>> WiFiDog mailing list
>> WiFiDog at listes.ilesansfil.org
>> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
>
>
> _______________________________________________
> WiFiDog mailing list
> WiFiDog at listes.ilesansfil.org
> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
>



More information about the WiFiDog mailing list