incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
Subject Re: [Apache Bloodhound] #146: Inline editing of objects
Date Tue, 27 Nov 2012 18:00:10 GMT
Joe,

If we don't we could potentially provide a site map if it is considered
useful more generally. I quite like that solution, though I could equally
imagine that those links could still be somewhere on the page for no-js
situations. I suppose it could even still be quite discreet. Anyway, we
shouldn't think this through too far. Let's just make sure that there is
some fallback for now.

Cheers,
    Gary


On 27 November 2012 17:14, Joe Dreimann <joachim.dreimann@wandisco.com>wrote:

> I like the fallback for the Quick Ticket button. For the Apps drop down,
> (we should really rename that to *More*) we could alternatively link to the
> site map (do we have a functional site map?).
>
> - Joe
>
> ________________________
> @jdreimann - Twitter
> Sent from my phone
>
> On 27 Nov 2012, at 16:54, Gary Martin <gary.martin@wandisco.com> wrote:
>
> > On 27/11/12 15:56, Olemis Lang wrote:
> >> On 11/26/12, Joachim Dreimann <joachim.dreimann@wandisco.com> wrote:
> >>> On 26 November 2012 06:49, Peter Koželj <peter@digiverse.si> wrote:
> >>>
> >>>> Not sure how much does support for javascript disabled browsers
> >>>> complicate
> >>>> things, but do we really care to support this when everybody is
> rushing
> >>>> to
> >>>> HTML5?
> >>>>
> >>>> I haven't that kind of requirement for a web application in the last
7
> >>>> years or so.
> >>> HTML5 and JavaScript are two different issues, most obviously because
> one
> >>> is a fix for the other: http://en.wikipedia.org/wiki/HTML5_Shiv
> >>> HTML5 will also take some of the weight off JavaScript going forward,
> for
> >>> example with contentEditable in this context:
> >>> http://html5demos.com/contenteditable
> >>>
> >>> Public sector organisations usually require all software to meet
> certain
> >>> accessibility standards, and I would suggest that we build to their
> most
> >>> basic standards at least. Screen readers often struggle with
> javascript, so
> >>> Gary's suggestion was to at least have JS-less fallback (the current
> edit
> >>> form). It's acceptable that this won't be pretty; most users will
> never see
> >>> it.
> >>
> >> Yes . Sometimes javascript solution is not available (e.g. disabled,
> >> blocked by firewalls, unexpected errors ...) and pages should fallback
> >> to non-JS behavior . There are even browsers like Netsurf built
> >> without JS support ...
> >>
> >> {{{
> >> #!sh
> >>
> >> $ apt-cache show netsurf
> >> Package: netsurf
> >> Priority: extra
> >> Section: universe/web
> >> Installed-Size: 1248
> >> [...]
> >> Description: Small portable web browser with CSS and Unicode support
> >>  NetSurf is a multi-platform lightweight web browser. Its aim is to
> provide
> >>  comprehensive rendering of HTML 4 with CSS 2 in a small resource
> footprint
> >>  while remaining fast.
> >> [...]
> >>
> >> }}}
> >>
> >> BTW , some parts of the site are not looking good on Netsurf . If that
> >> deserves some attention , please let me know to create a new ticket
> >> with screenshots .
> >>
> >> Unfortunately at the moment that also means that e.g. mainnav and
> >> create ticket shortcut menus won't work . We should take a look at
> >> that too .
> >
> >
> > Yeah, I suspected as much.
> >
> > Is there a particular reason that these buttons cannot fall back to
> being links? I wouldn't mind the Create Ticket button being a link to
> /newticket with the potential side effect of being able to open /newticket
> in a new tab. Actually, I can't think of a good place for the Apps to link
> to at short notice. Would there be any problems with having all the menu
> items visible, perhaps wrapping when there are too many, when js is not
> available?
> >
> > It does not need to be a particularly beautiful solution, we just need
> to let users access the links that they would otherwise lose. All without
> compromising on the experience for those with js enabled.
> >
> > Cheers,
> >    Gary
> >
>

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