Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of olemis@gmail.com designates
 209.85.220.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50B9B90C.2000507@wandisco.com>
References: 
 <CAJSKAsijOt3s4SX2kRM925CH1+G-oYafBqBMjRzpXvrZ0z6iHg@mail.gmail.com>
	<CAGMZAuN65PGNQii2zoaT95Rok0Seg3-+_EQohPWgPTNtk99wCg@mail.gmail.com>
	<50B9B90C.2000507@wandisco.com>
Date: Sat, 1 Dec 2012 11:41:45 -0500
Message-ID: 
 <CAGMZAuNAvcKpxUgp+7UqmjhK9bHangRBmHTB-W60CDp7C0UW7w@mail.gmail.com>
Subject: Re: Browser, HTML and JS support
From: Olemis Lang <olemis@gmail.com>
To: bloodhound-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 12/1/12, Branko =C4=8Cibej <brane@wandisco.com> wrote:
> On 01.12.2012 07:41, Olemis Lang wrote:
>> -1 Reasons mentioned in previous messages. BH has to work even if JS
>> is not available , not 100% of the functionalities will be available
>> though .
>
[...]
>
> Can anyone point to even one BH deployment (OK, potential deployment)
> where working without Javascript would be important in the time frame
> of, say, a year? I don't think so.
>

public ? =3D> I don't know
private e.g. in an intranet ? =3D> yes , some ...

in some sense I'm one of the users often on non-JS mode since I have
to disable JS from time to time to make web sites load faster ...
considering the fact that sometimes my internet connection becomes a
PITA , btw .

> Getting bogged down on technicalities that aren't likely to affect even
> 1% of the potential user base is going to kill the project before it
> even properly gets off the ground. The perfect is the enemy of the good,
> etc., etc.
>

IMO the effort required to support non-JS clients is tiny as compared
to other major features like those developed and scheduled so far :

- dashboard & widgets
- multi-product (BEP 3)
- advanced search (BEP 4)
- advanced upload form (#195)
- ...

if we compare all those side-by-side , support for non-JS clients
should be more simple by far . For instance, what a big deal is to
insert href=3D"/newticket" in create ticket shortcut button ?

Instead of =C2=ABsupporting non-JS clients=C2=BB maybe it's more accurate t=
o say
=C2=ABnot to turn non-JS clients unusable=C2=BB since the idea is not to sp=
end
time developing a marvelous non-JS experience . The idea consists in
providing quick navigation paths so that such users will be able to
perform basic tasks . A na=C3=AFve approach is to design templates and ,
before anything else, check they work with nothing else on top . Let's
add the rest later.

There's another reason , and it is that if for any reason JS code
fails at some point under certain circumstances , non-JS behavior will
be handy as a last recourse option .

If we don't design with that goal in mind since the beginning then it
will always be a loose end . IMO there are other major obstacles when
it comes to analyze what might jeopardize the existence of the project
.

Of course , under certain circumstances if non-JS compatibility effort
turns out to be long to achieve , a low priority (starter?) ticket
should be enough and we move forward with something else .
;)

--=20
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article: