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.
|
- Re: [Dynapi-Dev] Light widgets. (or "remember the user... Doug Melvin
- Re: [Dynapi-Dev] Light widgets. (or "remember the... Raymond Irving
- Re: [Dynapi-Dev] Light widgets. (or "remember... Doug Melvin