[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 Wed, 11 Jun 2008, Chris Travers wrote:

> On Tue, Jun 10, 2008 at 10:14 PM, Luke <..hidden..> wrote:
> 
> > This is one of the things I have been wanting to contribute to this
> > conversation.  It's all well and good to say that people using Open source
> > accounting software, are going to be using OS browsers as well.  I in fact
> > made a similar argument regarding the move to PostGreSQL, over in the
> > SQL-ledger list thread about LedgerSMB.
> >
> > However, this is not really the same issue: the database thing is a
> > radical back end case, whereas the browser is a UI case.  Once you decide
> > that a web interface is your primary interface, standardizing on a single
> > browser, or even a standard set of browsers, if that browser/those
> > browsers is/are not the majority case (IE is the majority case), is
> > sounding the death knell for the software in my opinion.
> 
> I just want to make sure my point is clear:  we standardize on HTML
> practices that we find maintainable and make a reasonable effort to
> support various browsers.  However, we aren't going to sacrifice a
> great deal of maintainability to support browsers which pose major
> problems.

I am all for standardizing on standards (HTML, etc.), and the idea of 
bending that to fit what M$ requires to work with IE is anathema to me.  
The only case in which I deem doing so acceptable, is the case wherein we 
are trying to break a large and entrenched market.
I see LSMB as trying to do that.  Not right now, necessarily, but in the 
near future.

> Currently IE8 looks like it will be supportable* which is a good thing.

But what is the suggested release date?  (Recognizing that MS release 
dates are somewhat malleable)

> The big thing is that the <button> element has to be properly
> supported.  If browsers aren't going to do this, then we can't handle
> localization properly while allowing the application to work
> gracefully without Javascript.  Or rather if we do this, we end up
> with an unmaintainable mess.
> 
> * supportable meaning supportable in the standard distribution.
> Custom solutions can of course be done differently depending on
> customer needs.

I was suggesting that, if it can be done in a vacuum (meaning that no 
internals of the app must change, but only the UI), detecting IE7 (or IE8 
in non-standards mode), and having particular UI hooks (javascript, if 
that's what will do it) to properly rewrite the elements, or just serving 
a slightly different version of the form, is not unreasonable.

You talk about maintainability...  My question there would be: how long 
would this actually have to be maintained?  IE7 will eventually go away, 
and I am choosing to ignore IE6 completely for the sake of this 
discussion.  When it does, with it can go the customization.

> There are other issues to consider as well.  At the moment, as Trevor
> notes below, LSMB has some significant issues for many businesses.  It
> is currently a niche product.  Hence at the moment requesting the
> change is not a problem.  However, as we fix these issues and broaden
> our appeal, it will become a bigger issue.  Hence there is a
> legitimate question of where we draw the line.

I might make the opposite argument: at the moment, there is no great need 
to support IE7, exactly because this is a niche product.
I am looking at this from a post 1.3 prospective.

If a significant number of the issues can be worked out while IE7 still 
represents a sufficiently large segment of the market, adapting to handle 
it as discussed above, is reasonable in my opinion.
Doing so right now, while there are still so many other usability matters 
on the table, would not be as reasonable, since the potential user base 
who would also insist on retaining IE, is probably quite low.

> > Requiring a particular browser or set of browsers, has a certain feel of
> > proprietary which I tend to associate with MicroSoft, not with OSS.
> >
> Well, I don't think we can support every browser out there.  The QA
> involved is tremendous and some browsers just don't support everything
> we need.

You're right, of course--that was a bad choice of phrasing on my part.  I 
am suggesting that we bend on the IE issue, for one reason and one reason 
only: its footprint among potential users.

 > Why should we rearchitect the application to support W3M?  Is it
> *that* important to support IE6 and 7 fully if IE8 support is there?

Only if any one of those represents 40-50% or more of the potential target 
market, at the time when targeting that market is wise (which it is not 
currently).

I am thinking of the future with my comments that we should add 
workarounds for IE7--a future which may never exist, depending on the 
status of IE at the time when a less problematic version of LSMB is 
available.

> Saying "we will fully support IE6 and above" thus doesn't just
> volunteer the core team for a *lot* of extra work but also impacts
> translators.   In all fairness, I don't see that happening.

I am only talking about IE7, which is, I believe, the most common version 
installed currently.

> This isn't a political decision-- it is based solely on

Nor did I think that it might be.

Let us clarify: is the button issue the only one known with IE6 or IE7?

> >> > More later--I think that's a Stallmanian OSS purist hit squad at my door,
> > to explain why compromising is a bad idea.
> 
> Compromising on what?  This isn't ideological.  It is a technical
> problem.  Microsoft has addressed the technical problem so I expect
> IE8 can be fully supported.  I don't foresee doing a lot of work to
> support earlier versions though given the maintainability cost.

(1) That was intended as humor, nothing else; and (2) I was speaking of a 
technical compromise--in particular, compromising the requirement for 
standards compliance, enough to support the most commonly installed 
browser.

All of this said, I am fond of the "Install FireFox: it is the client for 
the accounting app" way of handling this, especially if the Prism idea 
gains ground.

Regards,

Luke