I haven't actually modified any code yet. I've really only looked at the examples and though about what it would look like when I do.
The body is basically just changing the images that are used, the text, and the background. The footer is really just adding the links. The header on the other hand, may be a but trickier but it should be doable.
I'll upload the files, change some of the code, and send you guys the link to it later today so you can take a look at it and help a little bit if need be.
Sent from my iPod
On Apr 18, 2013, at 4:48 PM, Elle Stone <l elle stone gmail com> wrote:
> 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
> location.
>
> On 4/18/13, Kasim Ahmic <kasim ahmic gmail com> 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 (
>> http://twitter.github.io/bootstrap/examples/carousel.html) 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 <l elle stone gmail com> 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
>>> (http://webaim.org/resources/contrastchecker/).
>>>
>>> Some useful addons for checking accessibility issues:
>>>
>>> https://addons.mozilla.org/en-US/firefox/addon/accessibility-evaluation-toolb/
>>>
>>> https://addons.mozilla.org/en-US/firefox/addon/juicy-studio-accessibility-too/
>>> https://addons.mozilla.org/en-US/firefox/addon/openajax-accessibility-exte/
>>>
>>> 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
>>> http://themes.googleusercontent.com/static/fonts/. 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:
>>>
>>> http://www.smashingmagazine.com/2011/10/07/16-pixels-body-copy-anything-less-costly-mistake/
>>> http://informationarchitects.net/blog/100e2r
>>> http://www.sitepoint.com/eight-definitive-font-stacks/
>>>
>>> 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:
>>>
>>> http://coding.smashingmagazine.com/2011/01/12/guidelines-for-responsive-web-design/
>>> http://mashable.com/2012/12/11/responsive-web-design/
>>> http://alistapart.com/article/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
>>>
>>>
>>> --
>>> http://ninedegreesbelow.com - articles on open source digital photography
>>>
>>
>
>
> --
> http://ninedegreesbelow.com - articles on open source digital photography