[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interesting coverage of our project on the SQL-Ledger-users list



On 6/16/08, Luke <..hidden..> wrote:

>
> Isn't that rather like saying, that since no Ford truck drivers are
>  complaining to GM that GM isn't building trucks as big as Ford builds
>  them, that the GM engineers shouldn't bother with building bigger
>  trucks, because there is obviously no market for them?  All it really
>  says, is that truck buyers took one look at GM's lines, saw they didn't
>  have big enough trucks, and called Ford who did have them.  (As a side
>  note: this may actually be the way GM's engineers are thinking--it would
>  certainly explain their impending demise.)
>
>  The point is: If it doesn't work with IE, then IE users aren't going to
>  bother with it, if they have reasons to stay with IE, such as huge
>  corporate policy.
>  How many lists are you on for products you don't use?

 In general, the question becomes what is the cost of adding the
support vs what are the benefits.  The costs of adding support to the
point where we can say it is fully supported are quite high with IE7
and earlier, and I am not convinced that our product would be
attractive enough to IE users in general and in its current state to
make this a net win.  Personally I don't see that happening before
LSMB reaches 2.0.  By that point, I don't really see IE7 being any
more relevant than IE6 is today.

For IE8, it looks like the cost of that support will be dramatically
less.  Hence I am all for supporting that one officially.
>
>  On this list, we're dealing with a percentage of open source oriented end
>  users, small flexible businesses, and open source solutions providers.
>  None of these represent a great wide base of end userdom; and all of them
>  represent a level of willingness and tenacity to use open source software
>  which does not exist in the "get it done how ever we can, and in what ever
>  way causes the least trouble" world which is the eventual market for this
>  software imo.

I think that we ought to differentiate between IE7 and IE8 on this
matter, just as we differentiate between IE6 and IE7.  The question
is:  where do we draw the line on browser support?

My own answer is that this needs to be based on a careful review of
the facts including where the software is now and what it will take to
make it attractive to IE users.  In general, the simple solutions will
be ugly, UI-wise and therefore I see no point to them.  If we go with
a framework like Dojo, I would probably still prefer to list it as
unsupported due to the lack of non-JS usability and leave it to
person-to-person communication to state what the limitations are.  I
see non-JS usability as a requirement for being able to reasonably do
accessibility QA.

What this means is that we are best off saying "we will support IE8,
but not earlier versions."
>
>  Also: I'm a crappy marketer, but even I know that markets don't come to
>  you--you must go to them.  Absence of proof is not proof of absence.

Agreed, but when you have a coherent plan, things work better.  I am
not sure that supporting IE7 and earlier makes sense *especially* if
IE8 support will be easier and we can take the added time and effort
and use that to make the project better.

Best Wishes,
Chris Travers