incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: Browser, HTML and JS support
Date Sat, 01 Dec 2012 16:41:45 GMT
On 12/1/12, Branko Čibej <> 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 ? => I don't know
private e.g. in an intranet ? => 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="/newticket" in create ticket shortcut button ?

Instead of «supporting non-JS clients» maybe it's more accurate to say
«not to turn non-JS clients unusable» since the idea is not to spend
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ïve 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 .



Blog ES:
Blog EN:

Featured article:

View raw message