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

["Chris Travers" <..hidden..>]

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.

Currently IE8 looks like it will be supportable* which is a good thing.
IE6 and IE7 are not.  Pocket IE is not.
W3M is currently not.
To my knowledge other browsers work.

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.

Now, there was some talk for a while that I was supporting relating to
support for IE *only with Javascript enabled* probably using Dojo or
the like.  While I still support AJAX-type interfaces being possible,
IE8 should be such that support without Javascript should be possible.

>
> Yes, I dislike IE.  Yes, I get my customers to switch to FireFox when
> possible.  However, it isn't always possible or reasonable to request
> this, and in fact why should they?  They've got something their people
> know how to use, even if it isn't the best, which means that they are
> currently experiencing maximum efficiency as far as they know, and
> starting over with anything is going to impede in the moment, even if it
> speeds later.

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.

With IE8 supporting buttons properly, I would suggest that the line
should continue to be proper support of the button tag.

>
> 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.

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

I think that we should continue to document which browsers are utterly
broken and make a reasonable effort to support any given browser.
Reasonable being defined as an effort which does not fundamentally
compromise maintainability of the codebase or translation set (moving
back to submit inputs would compromise the maintainability of
translations).

In short I think this needs to be handled on a case-by-case basis.

> In fact, I would go as far on this, as to say that if IE required the
> implementation of a set of browser sensing routines, and a set of dynamic
> alterations to pages, we should do that extra work necessary to make the
> software work with it.

Ok-- here is the technical problem:

SL used <input type="sumbit"> elements to submit forms.  The problem
with this approach is that the displayed value on the button is
submitted back to the web server.  Hence when you translate what is
displayed, you change what is submitted back to the server.  SL
handles this by maintaining 2 translation lists for every module-- one
for the strings, and one for back-translating button names.  If these
get out of sync, you get errors in the application.  In order to
prevent problems, we moved to a standard format for translation files
(.po files), moved to <button type="submit"> elements and thus
eliminated the need for back-translation.  This results in more robust
software.

The chief advantage of button elements is that the submitted and
displayed values are supposed to be separate. I.e. one writes <button
type="submit" value="save_entity">Save</button> and it displayes
"Save" but submits back "save_entity."  In this way we can translate
just the labels.  And most browsers work fine.

IE is an exception.  In IE6, when a button is clicked, it submits
*all* button labels to the web server.  Consequently, we don't have a
way to determine what the user was actually trying to do as long as we
use <button> elements, and it also submits the wrong data (the
translated label instead of the submission value).  In IE7, it submits
only one button, but submits the lable instead f the correct value.

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.

This isn't a political decision-- it is based solely on
maintainability of the software and translations.  If Dojo allows for
support, then this is still limited support and it would not be fully
supported even there.
>
> If we want to advance the cause of open source, by saying that "we are
> just as good as, if not better than, the big proprietary guys", then we
> have to make certain compromises.  We are trying to force a paradigm
> shift, and that means that some times we are going to have to bend now, in
> order to gain ground, knowing that the ends justify the means.
>
> 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.

Best WIshes,
Chris Travers