Hmm, looks like twitter bootstrap is a grid framework with fixed and
fluid options. I've worked with fluid grid frameworks before (not
twitter bootstrap). If you like, send me your modified css/html (or
post a link for download) and I'll take a look at it to see if I can
figure out why it isn't fluid all the time. It's probably something
very simple but the relevant code might be buried in a non-obvious

On 4/18/13, Kasim Ahmic <> wrote:
> Thanks for the tips! I'll make sure to keep all that in mind when getting
> back to the overall look of the site. Right now, I'm focusing on using
> Twitter Bootstrap to recreate the site with a more fluid layout. I found
> that the Carousel Example (
> slightly
> resembles the current design. I can easily redesign it to look like the
> current site but the only issue I'm having is that the body still seems to
> be fixed (aside from on mobile devices and tablets) which is what I'm
> trying to avoid. I've never worked with Twitter Bootstrap or anything
> similar before so I don't really know what I'm doing. Any suggestions on
> what I can do here?
> On Thu, Apr 18, 2013 at 1:22 PM, Elle Stone <> wrote:
>> Hi Kasim,
>> Designing/implementing a website is hard work and you are an amazing
>> person for being willing to take on the job. In response to your
>> request for feedback, already many have chimed in and given excellent
>> advice. I wanted to add "useability/accessibility" to the list of
>> things to consider, and then ask about the intended audience and goal.
>> Accessibility guidelines and contrast:
>> The "gray on gray" text has a contrast ratio of 3:1, which doesn't
>> meet useability/contrast guidelines (WebAIM
>> (
>> Some useful addons for checking accessibility issues:
>> Unfortunately the color contrast tests provided by the above links
>> don't work on the mockup because for some reason all the tools assume
>> the background for the text is solid black, when really it's gray
>> (according to Firebug, the actual background is transparent; the text
>> is on top of a tiled textured gray background image - a pure css
>> background would weigh less and perhaps be less distracting for those
>> of us with less than perfect eyesight).
>> I used Colorzilla to sample the gray text and background and got a
>> contrast ratio of 3:1 (according to WebAIM, #efefef for the
>> background, #888888 for the text gives 3:1 contrast ratio). 3:1 is
>> minimum for large text, 4.5:1 is suggested; 4.5:1 is minimum for small
>> text, 7:1 suggested (18px is not large text, especially not when you
>> get older and your eyes start to not let in so much light and you need
>> to be farther from the screen to focus, etc).
>> Font type and size:
>> The font stack specifies Open Sans, Arial, and Helvetica, none of
>> which are included in "out of the box" Linux distributions such as
>> Ubuntu, Debian, and openSUSE.  The css/html code pulls 6 variants of
>> the Open Sans font from
>> A suitable cross-OS
>> font stack might be better than calls to an external website.
>> The links at the bottom of the page use a 12px font, and Arial and
>> Helvetica are "smaller" sans-serif fonts (at the same font size, the
>> various fonts have radically different actual screen sizes, Verdana
>> for example being much bigger than Arial). So the 12px text is doubly
>> small.
>> The current Gimp website doesn't go any smaller than 13.333px. Current
>> recommendations are pushing towards 16px for the base font:
>> People who can't comfortably read the smaller font have the option to
>> set a minimum font size with their browers. When I set a minimum size
>> of 16px, the design breaks: "Download" is shoved under "Gimp" at the
>> very top of the page. The "Linux" download link takes two lines
>> instead of one, so the box is twice as tall as the Windows/Mac boxes.
>> The best way around this problem is to use a fluid layout, which I
>> think you are already working on because of mobile browsing (mobile
>> browsing already accounts for 20% of all web browsing and the numbers
>> are accelerating). If you aren't already, you might also consider
>> "responsive" web design:
>> Time to download and assemble the page on the screen:
>> The redesign takes a noticeable amount of time to load on my computer.
>> Before the page is fully loaded, for a brief moment the page looks
>> disorganized, then the images and text rearrange themselves into their
>> intended positions. I poked around a bit trying to locate what might
>> contribute to the time it takes to get the page on the screen; here
>> are some possibilities:
>> There are several shadow effects in use. In general, the more shadows,
>> the longer it takes to load and assemble the web page. Personally I
>> find the white shadow under the text to be distracting: the shadow is
>> almost too small to see and on my low-end laptop screen the white
>> shadow appears/gets smaller/disappears as I change my angle of view.
>> Probably you haven't resized the images for "production", but at 450kb
>> for the header image, plus approx. 225kb each for the slideshow
>> images, the images are much larger than they need to be, and there is
>> a noticeable lag in image display when returning to/refreshing the
>> page.
>> The slideshow has continously changing images, which personally I find
>> a bit distracting. I'd prefer the option to start the slideshow
>> voluntarily rather than have it download "whether or no" and then
>> constantly going in the background.
>> There are two javascript files (the jquery.js file is a whopping 90
>> kb), but many people avoid javascript as partly annoying and partly a
>> security risk. A pure css slideshow/gallery would lighten up the
>> required download. Although the existing Gimp website uses 5
>> javascript files (including jquery), it works just fine with
>> javascript disabled.
>> Anything that causes the page to take a somewhat longish time to load
>> and assemble would put a strain on browsing the Gimp website for
>> people with older computers, lower bandwidth and/or monthly download
>> limitations (most mobile devices, plus desktop computers with caps or
>> slow internet connections). Also, these days when ranking websites
>> Google does consider download size and other
>> efficient-browsing-related items.
>> I'm curious as to the "use case" for a blogging engine, which would
>> add its own additional weight to the download, along with possible
>> security issues and possibly further reliance on javascript for full
>> functionality.
>> Intended audience:
>> Who's the intended audience and what's the goal of the redesign? As a
>> long-time Gimp user, I visit the Gimp website often to catch up on the
>> latest news and to follow links to IRC, documentation, downloads, etc.
>> As others have noted, it's nice to have the news on the front page.
>> The existing website is perhaps too heavily weighted toward people who
>> already use Gimp and the proposed redesign seems to be aimed mostly at
>> attracting new users. Will it be effective at this goal? Trying to
>> view it as a potential new user, it somewhat feels like I'm viewing a
>> product advertisement - high on nice visuals and lead-ins, but perhaps
>> not enough concrete information.
>> I don't claim expert status (far from), but I'm responsible for
>> several small websites and possibly I can help if you run into issues
>> with trying to code up the fluid and/or responsive layout, creating
>> font stacks, etc.
>> Kind regards,
>> Elle Stone
>> --
>> - articles on open source digital photography

-- - articles on open source digital photography
gimp-user-list mailing list

Reply via email to