bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <>
Subject Re: Browser, HTML and JS support
Date Sat, 01 Dec 2012 21:43:24 GMT
On 01.12.2012 17:41, Olemis Lang wrote:
> 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 .

So, right now you're probably around 10% of the BH user base. I can
understand your pain WRT flaky connections, but unless you want to still
be that 10% in a years' time, I suggest you'll have to deal with it.

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

Really, is that all it takes? How hard can it be. ... famous last words.

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

This is /precisely/ what Peter is worried about: designing UX on top of
a dumb interface instead of the other way around. You're letting your
personal experience cloud your thinking.

You can say /now/ that it's "only this" or "only that", but you'd end up
with endless arguments before every release about whether or not another
week should be invested into making some widget or other work without

I see endless arguments on the dev list /today/ about trivial edge
cases, even when non-JS mode is not involved.

It's high time this project showed some real progress if you want to
attract a user base. Hanging an albatross around your neck isn't going
to help at all.

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

You're grasping at straws here. Even if the "JS mode fails under certain
circumstances" is possible, you're still talking about unlikely edge
cases. Why do you insist on optimizing edge cases when there's so much
else to worry about?

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

I think you should take a hint from Jira, which says:

" Warning: either you have JavaScript disabled or your browser does not
support JavaScript. To work properly, this page requires JavaScript to
be enabled."

My best guess at the reason for this is that it's /hard/ to write a
Javascript-less fallback for a good UI. The 80/20 rule would certainly

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

I believe you're drastically underestimating the effort that's needed
for getting Javascript-less functionality.

-- Brane

Branko Čibej
Director of Subversion | WANdisco |

View raw message