Okay. Maybe this is why the lightest widgets should be called widget_light.js
 
What I want everyone to understand is that not every user of the dynapi will be an advanced _javascript_ programmer. Nor are we desiging this soley for our use.
 
We are, after all, trying to define the next generation all-browser-all-platform _javascript_ library here.
 
But in order to get any level of acceptance at all, we have to remember the users.
 
A _USER_ is not us. 
A user has no intemate knowledge of the internal workings of the dynapi.
Nor do they want to.
A user can have any level of compentance.
Or none at all.
A user has the statistcal attention span of _7 seconds_
when looking at something new and shiney.
 
And where not just talking about people who find us through google either.
On more than one occasion I have landed a contract simply on the apperent strength of the DynAPI 2.
Not just that it's pretty and works, but that I could train any of their code monkeys to maintain the code I
would write for them.
 
Now comes DynAPI 3 and those contracts I did not get due to the api seeming 'slow' or 'heavy' now promise
to be a thing of the past. With tighter integration of inline creation, a smoother events structure, and ligher
acetecture this version actually has the portential to take off, to allow us to do greater thing, to let the _user_
do greater things, but none of this will matter if we forget to "remember the user"
 
:-)
 
Post Script: I am not saying more coplex widgets and components are bad, only that we need to maintain a base of simple widgets to allow for siple tasks to be completed by simple users.
 
Thus ends the official Doug Melvin Rant on Usability for DynAPI 3.. Had to come sooner or later right?
I just figured sooner would be better.
 

Reply via email to