HTML Layout under different screen sizes

Issue #66 resolved
b created an issue

The current (July 2, 2015) application really only works on a fairly large monitor with a good portion of the horizontal space dedicated to the knowledge.bio browser window.

Even on a 15 inch screen (large for a laptop), the layout buttons start getting squashed together, the 'categorical filtering' button gets shifted over to a new line as does the initial concept search. As the window is made smaller, the interface falls apart due to overlap problems.

Leaving this open for a future run at the UI. Would really like resizable areas. Suspect we should be moving out of the realm of hand crafted javascript asap...

Comments (20)

  1. b reporter

    I'm bumping this up to implicitome critical because there are some really minor changes that would make this work much better on the 15 inch laptop where I will be showing this off this week. Just need to tweek the bootstrap column styles a little bit and it can work at this size. Another screenshot at full-screen on my laptop below with three problem areas highlighted.

    Screen Shot 2015-07-06 at 10.48.06 AM.png

  2. Richard Bruskiewich

    I've tweaked all the screen elements a bit to make them perhaps a bit more palatable, but after such an afternoon of tweaking, I thoroughly endorse the sentiment that we ought to generally get away from "...the realm of hand crafted javascript asap...". It's a major pain in the but at the best of times. There ought to be a better way (or platform) out there.

  3. Richard Bruskiewich

    I don't think we can afford more tweaking between now and the Implicitome release, but I won't completely close this issue, so it remains in our psyche.

  4. b reporter

    Still works much better on a big screen, but I've been happily tinkering with it on my 15 inch for a while now. Still want resizable panes in the future... good enough for now.

  5. b reporter
    • changed status to open

    I opened it up this morning and saw the attached. Reloaded, no change.
    My window was open to about 900 pixels wide.

    Screen Shot 2015-08-31 at 9.41.04 AM.png

  6. Richard Bruskiewich

    I just checked this, and found out something bizarre: the problem is bimodal. That is, when the screen is wide enough to show the concept map side-by-side with the data tables, things are fine. Narrowing the browser window smaller (i.e. your 900 pixels), one observes the above image, but then... wait for it... narrowing the browser window even further renders the data table normally again, but of course, the concept map and some of the menu buttons are bumped to the bottom of the screen.

    Note that resizing the window with your browser (i.e. control +/- on PC, apple command +/- on Mac) can mitigate the issue by reducing the window size small enough to properly display the desktop.

    I sense that we are somewhat stuck with this cosmetic issue as long as we depend on Bootstrap Javascript to manage such a complex screen.

    Our initial explorations of the Java/Vaadin rich client interface framework for use in KB-TNG will help us overcome many of these UI display warts.

  7. Richard Bruskiewich

    The reported issue appears to be a limitation of Bootstrap Javascript. Resizing the browser window mitigates. I will document this in the user documentation as the suggested workaround for now.

    The "next generation" interface will try to more permanently fix this "ugly" behaviour.

  8. b reporter

    This comes up too often by accident for me to ignore. I think we should use something like the "min-width" CSS attribute http://stackoverflow.com/questions/3802455/min-width-in-window-resizing to set it such that you always have to have both panels side by side. If you go smaller than that, you would just have scroll horizontally. I think you could accomplish this by putting both panels into a new div and assigning the min-width property to that div at about 1205 pix .

    Would rather have it fixed like that and give up the stacked view as I think this version is just not going to work well for mobile users anyway.

  9. b reporter
    • changed status to open

    sorry, I think this is important to improve on. see most recent comment with regard to a potential solution.

  10. Richard Bruskiewich

    Oh... aalllll riiight. I'll have Farzin look at this later this afternoon when she comes in.

  11. Log in to comment