#1798 Move wiki right sidebar data to the top [18407]
https://sourceforge.net/apps/trac/sourceforge/ticket/18407
Hi,
https://sourceforge.net/p/scipad/wiki/Tested%20on/
There seem to be an invisible limit in the width that a wiki page can support.
The preview of my page (when modifying it) is OK (try Edit, then Preview). But after saving, the page is truncated down to a far too small width which is independent of the screen or browser window width, therefore truncating content like tables far too early.
Note that this seems to be quite general:
https://sourceforge.net/p/scipad/home/
shows snapshots that are now truncated (whereas they were not at the beginning of my SF2.0 project).
On wiki pages, it seems like the authors and attachments which go in the right sidebar should go into the left sidebar. The right sidebar takes up a lot of space and doesn't have much in it.
We can probably just kill the sidebar and put metadata in a section at the top like on the tracker pages. The sidebar hasn't turned out to be that valuable in practice.
Changes are on js/1798. To test:
1) View a wiki page.
2) Note that Authors, Labels, and Attachments (if they exist) are now shown in the top bar and there is no right sidebar.
3) Go to the tool admin for the project and toggle the wiki option "Show metadata".
4) Go back to the wiki page and observe the metadata at the top is now hidden.
Looks good.
Originally by: fvogelnew1
Thanks for considering my report ( https://sourceforge.net/apps/trac/sourceforge/ticket/18407 ) and fixing it so quickly.
Is there any way to see the fixed version before it gets deployed?
Besides, let me add that apart from this right margin that you just fixed, a lot of blank space is wasted on both the left and right side of all pages of SF 2.0. This is true for the very page I'm writing to now, or check it for instance at the homepage of my project:
https://sourceforge.net/p/scipad/home/
There is a useless blank column on the left side and another one on the right side, the sum of which eats something like one third of the available width on the page. Can this be fixed as well ?
Francois, the changes are live now, so you can see them on your project.
Regarding the additional whitespace, I'm not sure exactly what parts you're referring to. Do you mean the space I've marked with red arrows on http://screencast.com/t/sX4Xz2vHiX ? If so, that is because we have a constant width of 960px. So if your resolution is small or large, you see the same 960px, no stretching of content.
Originally by: fvogelnew1
Right I can see the margin moved now. Looks OK.
Regarding the additonal blank space, yes I meant what you have marked with red arrows. I understand that this is a design choice, but... why this?
One can get 24-inch monitors for just a few hundred bucks now.
Moreover, stretching the useful width to the size of the browser window would be good simply to maximize the amount of information displayed.
Also, this would help in displaying snapshots in native resolution (as opposed to compressing them in size) that do not fit in the available space, see for instance the homepage of my project, showing a truncated snapshot:
https://sourceforge.net/p/scipad
Take a look at: http://webtypography.net/Rhythm_and_Proportion/Horizontal_Motion/2.1.2/
Wider isn't inherently better. Right now most of our content has about 785px, which works out to a measure of ~100 characters for a base font size of 13px (rule of thumb is that characters are half as wide as they are tall). If we stretched content any wider readability would suffer.
On the other hand, we're very interested in CSS media queries and potentially using those to optimize the layout to both high and low (mobile) res displays. See http://hicksdesign.co.uk/journal/finally-a-fluid-hicksdesign for an example in action. With that said, even in a hypothetical high res optimized layout I don't see content areas getting much wider than they currently are.
Another option for dealing with things like images is to have a gallery or image macro that would display the full res image in a lightbox. The beauty of a lightbox is that text content can continue living in a comfortable measure and images can be viewed at whatever resolution the browser can display.
Originally by: fvogelnew1
I understand your points and they look valid to me.
Just one more thought: each time this discussion goes on in the present tracker, reply to reply to reply to... each time reduces the available useful space (width) since the reply is left-indented and the right margin does not move. Anyway.
I look forward to a solution for displaying images in SF2.0, be it in lightboxes or whatever. I have opened a ticket about exactly this 6 months ago:
https://sourceforge.net/apps/trac/sourceforge/ticket/14577
but got bounced by the support who asked me to file this as a request for enhancement, which I did:
https://sourceforge.net/apps/ideatorrent/sourceforge/ideatorrent/idea/823/