bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Dreimann <>
Subject Re: Browser, HTML and JS support
Date Fri, 30 Nov 2012 16:25:57 GMT
That suggestion seems sensible Peter. For tablets and smartphones we can
just say that the responsive layout will be optimised for their resolutions.

Javascript is the only area where I would recommend a different approach:
Yes, we should design and build assuming it is enabled. We should generally
provide a fallback though, even if this clunky. For example the quick
ticket button, which uses JS to show a form. As a fallback, it should
simply link to the New Ticket page.


On 29 November 2012 16:54, Peter Koželj <> wrote:

> The question of browser, html versions and no-JS support came up recently
> in a couple of threads.
> This deserves a thread on it own. Here is my proposal:
> We should migrate to HTML5. We are already using some of it and should make
> it official (HTML header)
> DESKTOP BROWSER ("official" support)
> - Google Chrome on Windows and OSX
> - Mozilla Firefox  on Windows and OSX
> - IE on Windows
> - Safari on OSX
> For all browser only major versions released in last 18months
> are officially supported.
> Compatibility with other or older browser is welcomed but we should not
> spend extra energy on it or even worse, design UI for it.
> Responsive layout is nice but to actually support specific devices/browser
> would require that we actually posses those devices for development and
> testing.
> For now I would not support specific devices or platforms. All we can say
> "screen size adaptable" or something.
> Is required! We should not spend time and energy on this right now. We have
> much bigger things to worry about.
> No javascript fallbacks can always be added later, and it also decreases
> the risk for designing to the minimal common denominator which is extremely
> low for non-javascript variant.
> Regards,
> Peter

Joe Dreimann
UX Designer | WANdisco <>
*Transform your software development department. Register for a free SVN
HealthCheck <> *

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message