incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
Subject Re: Making Bloodhound's layout responsive [ticket #217]
Date Thu, 04 Oct 2012 17:29:45 GMT
On 10/4/12, Gary Martin <gary.martin@wandisco.com> wrote:
> On 03/10/12 19:06, Olemis Lang wrote:
>> On 10/3/12, Joachim Dreimann <joachim.dreimann@wandisco.com> wrote:
>>
>>> My suggestion is to enable it using an opt-in mechanism in the Admin
>>> settings of any Bloodhound deployment, showing a clear 'Responsive
>>> layout
>>> beta' banner at the top of pages where the responsive stylesheet is in
>>> use.
>>>
>> There's a suggestion about how this could be done ... **IF** a generic
>> translation is possible at stream filters level .
>
> If we are trying to get to something close to the wide view in the
> pre-responsive layout considerations, I am not sure that we need much
> extra at the stream filters level. For the purposes of responsiveness
> (that is dynamically responding to changes in width), would it be better
> for this to be handled in js and css? I could of course be
> misunderstanding your point.
>

I don't know whether there's a misunderstanding . I was thinking of
using fluid layout (rather than current fixed layout) if responsive
features are enabled . That's what stream filter would be for. Besides
it could help with including responsive CSS classes in elements
initially found in non-responsive layout. Of course we could write
different Genshi templates for responsive layouts

> I wonder how much of a need there will be for opt-in and beta banners
> for this as well but I look forward to finding out.
>

IMO it's ok as long as we dedicate some effort to improve significant
features we decide to incorporate .

GMail is a beta release ... so ...
;)

>>
>>> Responsive Ticket view
>>> mockup<https://www.dropbox.com/s/c7hlp2n01ntwqfa/Bloodhound%20responsive%20ticket%20layout.png>
>>>
>>
> Is there a place for reply and edit buttons on comments (assuming that
> these are still required).

afaicr they should be hidden by default . Nonetheless I've been
thinking about this and the classes used in the patch submitted for
#182 only consider screen size . Nonetheless touchscreen devices
having big dimensions exist . In those cases the same problem will
happen and it will be hard (impossible?) to see reply/edit buttons .
CMIIW

> I can imagine that some kind of click event
> could bring up a small context menu for these if space is at a premium
> but I am not sure that would work well on touch screen devices.
>

something like a dropdown ? e.g.

Actions ↓
 ___________
| Edit      |
| Reply     |
|___________|


-- 
Regards,

Olemis.

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

Featured article:

Mime
View raw message