Re: IndexedDB, what were the issues? How do we stop it from happening again?

On Tue, 12 Feb 2013 01:02:38 +0100, Brian Kardell <bkardell@gmail.com>  
wrote:

>
>> Or, thinking of it from the perspective of a working group chair, and  
>> then again from the perspective of someone who teaches developers  
>> simple stuff about >>APIs, it would help with testing. It would also  
>> provide good material to assist uptake, at least to the point where  
>> "end-user developers" (by which I mean simple >>folk like me) could  
>> have meaningful conversations with people who can make their own  
>> libraries that are good enough for other users (by which I mean clever  
>> >>folk like Yehuda), where the "end users" could explain their problems  
>> and the designers could clearly explain whether this is an issue in the  
>> API they have >>created, or just a missing bit of library code that  
>> "can probably be done in a couple of days"... which is of course an  
>> invitation to spend the couple of days and >>prove it.
>>
>> [...]
>>
>>> For the bad design bit, well, we've been missing a manual on how to  
>>> write good APIs for a long time.
>>
>> Yes. An important aspect, as Marcos noted, is to identify what bits of  
>> "good" APIs are generally good, and what bits of them are good in the  
>> specific case of that >>API. And likewise, what things are not good.
>>
>
> While there probably are some good general rules, I think this is  
> somewhat like saying "good paintings are 20% yellow" or something.

Yeah, definitely...

> The best API is the one the most people are able to feel comfortable and  
> productive with - they'll know it when they use it. It seems that really  
> the best way to >know that is to get people involved and using early  
> (maybe even competing) and forward compatible versions of them before  
> they go so far as to become a >standard....
> I really think that the success of any one of them ultimately has very  
> little to do with how many people created it, what process they used,  
> whether it is high or low >level, etc. and more about the simple "will  
> people find this useful/intuitive and want to use it".  I'm not  
> suggesting it's just wild-west free-for-all or anything, just that  
> >those are important components of what I think a really excellent  
> solution looks like.  Something that can provide data to those questions.

"People will find this intuitive and want to use it" is pretty clearly one  
of the big clues to a great API. And I don't expect that there is a magic  
formula - in part because making things intuitive can be done by showing  
people what they have already seen, and that depends in large extent on  
where they have been before.

But explaining what has worked and what hasn't gives people something to  
think about, and some kind of frame to think in, which in turn can help  
them get right answers more often. (And asking people to rethink things if  
what they are doing looks like something that went wrong before is good  
too - even if it turns out that this time that thing is the right  
answer...)

cheers

Chaals


-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
chaals@yandex-team.ru Find more at http://yandex.com