[isf-wifidog] Picking an AJAX library for wifidog
Max Horváth
max.horvath at maxspot.de
Dim 30 Avr 14:29:59 EDT 2006
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'll support any decision made regarding the AJAX library, as I don't
have any experience with any of those libraries ...
Cheers, Max!
Rob Janes wrote:
> 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
>>
>
> _______________________________________________
> WiFiDog mailing list
> WiFiDog at listes.ilesansfil.org
> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFEVQIo+BKgC+eQ3ooRAvVkAJ9x9UQB11N27DKV3zqoNac08XsN+ACdH+vf
xQrM0YFh9/AD9re2iyZsI4Q=
=GAm7
-----END PGP SIGNATURE-----
More information about the WiFiDog
mailing list