On 04/11/2013 03:33 AM, Kasim Ahmic wrote:

Over at the Web List I've posted this redesign that I made from Mike Finch's mockup.

http://kasimahmic.koding.com/works/GIMP/

I like it! Great job!

Peace...

Tom

/When we dance, you have a way with me,
Stay with me... Sway with me.../

On 04/11/2013 06:33 AM, Kasim Ahmic wrote:

Over at the Web List I've posted this redesign that I made from Mike Finch's mockup.

http://kasimahmic.koding.com/works/GIMP/

It seemed to get very high praise and acceptance from the users in the list. Overall, I think the homepage is done and I just wanted to ask more users about their opinion on it as well as figure out what I have to do next in terms of getting the redesign on the official GIMP site (assuming the developers like it as well).

It's really hard to make an overall value judgment on a thing like this. I certainly see nothing to object to and some things I like, but I also see a couple of things that I would suggest tweaking...

At the upper left where it says "The Freely Distributed [etc]" I think I would have said "The Free Software [etc]", and I don't know what to suggest changing but I think the text could be at higher contrast with the background.

I note the doctype is "html" a.k.a. "quirks mode". Today some call that "html 5". I would specify xhtml 1.0 transitional, as per the existing GIMP site, for the production version. For my take on the state of html 5, see the bottom of this page:

http://pilobilus.net/web_design_resources.html

A few things to note:

- Currently, it is only the homepage - We MIGHT be redesigning the entire GIMP website. No idea as of yet. - The slideshow images will be changed soon. - The background of the header might change as well. - We will not use the current text that we have on the body (ex. Professional Level Filters). This was discussed on the Web List.

So tell me what you guys think of it so far! Any and all positive as well as negative feedback is welcome and much appreciated. It'll really help me make this into something that everyone can enjoy!

On the whole, at first viewing, I like it!

:o)

Steve

On Thu, Apr 11, 2013 at 5:33 AM, Kasim Ahmic wrote:

So tell me what you guys think of it so far! Any and all positive as well as negative feedback is welcome and much appreciated. It'll really help me make this into something that everyone can enjoy!

I'm not a huge fan of the black background. Overall, I do like the design though.

One thing is missing: mobile-friendly layouts. The current site is not fantastic at mobile size, but it's more usuable than your demo. Apologies if you were already planning to take care of this.

As for HTML5, I've seen my fill of browser-specific issues with HTML 4.0 and XHTML. Avoid the stuff that's still in churn (eg, canvas tag the last time I checked), and HTML5 is fine IMO, and a lot more fun to work with.

Chris

On 13-04-11 06:33 AM, Kasim Ahmic wrote:

Over at the Web List I've posted this redesign that I made from Mike Finch's mockup.

http://kasimahmic.koding.com/works/GIMP/

[snip]

So tell me what you guys think of it so far!

It looks good but you could tighten up the design. It uses a lot of space for little information, but that may be in part that it is a sample of the appearance of the front page without the final content.

The large text below the top nav bar uses a lot of space for so little text. The laptop cover on the right with the changing pictures seems a waste of space unless you have planned for something else to appear on there. The orange clickable buttons seems rather large.

It is nice to see someone looking at the website and thinking of ways to improve it.

Cheers!

Kevin.

http://www.ve3syb.ca/           |"Nerds make the shiny things that distract
Owner of Elecraft K2 #2172      | the mouth-breathers, and that's why we're
                                 | powerful!"
#include  |             --Chris Hardwick

On Fri, Apr 12, 2013 at 1:30 PM, Kevin Cozens wrote:

On 13-04-11 06:33 AM, Kasim Ahmic wrote:

Over at the Web List I've posted this redesign that I made from Mike Finch's mockup.

http://kasimahmic.koding.com/**works/GIMP/

[snip]

So tell me what you guys think of it so far!

It looks good but you could tighten up the design. It uses a lot of space for little information, but that may be in part that it is a sample of the appearance of the front page without the final content.

I don't think it's that big of an issue. We live in an age of high resolution monitors. Higher resolution images would be good to take advantage of that. Personally I like the current site design (on gimp.org); primarily because I enjoy reading the GIMP news as soon as I get to the site (which I avidly check even though it's not updated very often). For me it just means more clicks to get to news. I guess I'll just depend on my RSS feed as it's not that big of a deal.

However I like how Kasim emphasizes features on the front page which beckons users to try it out. The only thing I would like to see changed is the text, "Play with the Tools of the Trade." I don't like that because it implies that there is no need to take GIMP seriously as a professional editing tool or that it's a free trial to "play" with before using the real thing. I'm tired of hearing people say GIMP isn't as good as Photoshop. They just haven't used GIMP enough. You need to unlearn Photoshop to really take advantage of GIMP. I think GIMP is already ready for the prime time just industry doesn't take the time to learn a new tool. I would like to suggest you changing that text to, "Draft with the Tools of the Trade." This let's users know that it's there for the taking yet allows professionals to take it seriously as a tool to get work done.

If we're really going forward with this redesign thanks for considering any of my thoughts.

SAM

On Fri, Apr 12, 2013 at 1:41 PM, Sam Gleske wrote:

On Fri, Apr 12, 2013 at 1:30 PM, Kevin Cozens wrote:

It looks good but you could tighten up the design. It uses a lot of space for little information, but that may be in part that it is a sample of the appearance of the front page without the final content.

I don't think it's that big of an issue. We live in an age of high resolution monitors. Higher resolution images would be good to take advantage of that. Personally I like the current site design (on gimp.org); primarily because I enjoy reading the GIMP news as soon as I get to the site (which I avidly check even though it's not updated very often). For me it just means more clicks to get to news. I guess I'll just depend on my RSS feed as it's not that big of a deal.

However I like how Kasim emphasizes features on the front page which beckons users to try it out. The only thing I would like to see changed is the text, "Play with the Tools of the Trade." I don't like that because it implies that there is no need to take GIMP seriously as a professional editing tool or that it's a free trial to "play" with before using the real thing. I'm tired of hearing people say GIMP isn't as good as Photoshop. They just haven't used GIMP enough. You need to unlearn Photoshop to really take advantage of GIMP. I think GIMP is already ready for the prime time just industry doesn't take the time to learn a new tool. I would like to suggest you changing that text to, "Draft with the Tools of the Trade." This let's users know that it's there for the taking yet allows professionals to take it seriously as a tool to get work done.

If we're really going forward with this redesign thanks for considering any of my thoughts.

To add on to my previous statements I'd like the front page to be edited a bit more. I'll quote the previous text and then follow that with what I would like to see it say. Note:

*Professional Level Photo Filters* Make your photos picture perfect with with prefessional-grade color

filtering.

*Play with the Tools of the Trade* GIMP comes ready with everything you need to design like a pro.

--------------------------------- Suggested Changes....

*Professional Photo Filters* Make your photos picture perfect with professional-grade color filtering.

*Draft with the Tools of the Trade* GIMP has a robust set of tools and can be easily extended through add-ons.

--------------------------------- Notes....

On the second sentence of the first line I correct your misspelling of "prefessional."

Avoid the word 'comes' as it implies humans traveling (to come and go). Again emphasize that GIMP brings a lot to the table. Having a robust set of tools is good for both users and professionals a-like. Easily extending functionality through add-ons caters to real power users of the tool.

I try to think of the psychology behind the advertising since the first page is something everybody sees I think this redesign will ultimately make GIMP more popular. Especially with high bit depth editing coming to the table in future versions (which I look forward to!).

Thanks for taking the time Kasim to put a lot of thought into your design and asking for feedback.

SAM

On 04/12/2013 10:41 AM, Sam Gleske wrote:

On Fri, Apr 12, 2013 at 1:30 PM, Kevin Cozens > wrote:

On 13-04-11 06:33 AM, Kasim Ahmic wrote:

Over at the Web List I've posted this redesign that I made from Mike Finch's mockup.

http://kasimahmic.koding.com/works/GIMP/

[snip]

So tell me what you guys think of it so far!

It looks good but you could tighten up the design. It uses a lot of space for little information, but that may be in part that it is a sample of the appearance of the front page without the final content.

I don't think it's that big of an issue. We live in an age of high resolution monitors. Higher resolution images would be good to take advantage of that.

High resolution monitors might be frequently installed but many people won't use them at high resolutions. My point is assumptions should be avoided as much as possible. With that being stated, I agree that I don't think the use of space is that big of an issue.

Peace...

Tom

/When we dance, you have a way with me,
Stay with me... Sway with me.../

On Fri, 2013-04-12 at 11:22 -0700, Tom Williams wrote:

On 04/12/2013 10:41 AM, Sam Gleske wrote: We live in an age of high

resolution monitors. Higher resolution images would be good to take advantage of that.

High resolution monitors might be frequently installed but many people won't use them at high resolutions.

The answer to this is liquid, responsive designs using CSS media queries. This approach works in all modern browsers and is compatible with older browsers (and with Web crawlers).

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

On Fri, Apr 12, 2013 at 5:23 PM, Kasim Ahmic wrote:

How about if I add a "Recent News" section between the body and footer? Sort of a small feed that shows the 3-5 latest articles. I'll probably also add a twitter feed (should the GIMP devs want to tweet their progress) and a latest books feed or something along those lines. I've updated the demo with this but for now it's just to show where the feeds would go. No styling has actually been added yet.

That's a pretty cool idea. Considering the space allotted for it I think only 1 article would be enough. If I see that one article has changed I would go to the news feed to read more news :).

Oh and I'm not sure if you guys are thanking me for making the site or for

designing it. If it's for the latter, then please know that I had no part in it's designing. That was all Mike Finch.

Ah I forgot Mike Finch was the designer; nice shout out. I give props to both of you. Nice design and good conversion from template -> html.

One other thing I'd like to add. Your html doesn't pass the W3C Validation Service. I think we should follow the HTML5 standard. Here's a quick URL for your convenience.

http://validator.w3.org/check?uri=http%3A%2F%2Fkasimahmic.koding.com%2Fworks%2FGIMP%2F&charset=(detect+automatically)&doctype=Inline&group=0

SAM

On Fri, Apr 12, 2013 at 5:41 PM, Sam Gleske wrote:

One other thing I'd like to add. Your html doesn't pass the W3C Validation Service. I think we should follow the HTML5 standard. Here's a quick URL for your convenience.

http://validator.w3.org/check?uri=http%3A%2F%2Fkasimahmic.koding.com%2Fworks%2FGIMP%2F&charset=(detect+automatically)&doctype=Inline&group=0

I went ahead and changed your code so that it validates. I've provided both a revised validated file and a diff to show the changes. See the attached files index_validated.html and index_validated.diff.

I also recommend you validating your CSS if you can (sometimes that's not always possible).

http://jigsaw.w3.org/css-validator/

SAM

On Fri, Apr 12, 2013 at 4:23 PM, Kasim Ahmic wrote:

To be completely honest, I purposefully avoided mobile support. Considering that GIMP is a desktop exclusive program, I figured that adding mobile support would be a waste of time. If there is enough demand for it, however, I'll attempt to add it.

I would at least have a look at adding something like bootstrap. Adding a few classes to your divs and you'd be 99% done. Most elements would then scale to fit tablets/mobile, etc.

Use case A: I'm out at the bar and talking about design work. My companion mentions how all the software you need is expensive. I point out GIMP can handle quite a bit, esp when it comes to web and photos. My companion asks "can it do X"? I look it up on the site. Site looks bad == project looks bad.

Use case B: Loss of internet connection, no local help installed, but access to web via a mobile data plan. Easy to access the docs on the phone.

I doubt these cases are common, really - but using something like bootstrap or unsemantic doesn't take long and handles them nicely.

Just my opinion really - I see it as a relatively small amount of effort even if the gains are small.

Chris

Hey guys/Kasim,

First off, this is really great work. It's awesome seeing this come to life.

The original design I did (http://d.pr/i/LYn8) was intended to work within a responsive, flexible grid- specifically, Twitter Bootstrap (http://twitter.github.io/bootstrap/). Regardless of the content being for a desktop application, there's no reason to discount the use case of someone learning about GIMP while on the bus, and visiting the site on their phone. The awesome thing about Bootstrap is that the "mobile version" comes in the framework for free without the need for any extra dev work.

Regarding the background, I totally agree that a blurred, less distracting version would be more effective. Very good call.

Just wanted to pop in and say thanks for all the hard work! :) Feel free to hit me directly if you have any questions/concerns.

Mike Finch // 1sixty.com (http://1sixty.com)

Twitter // @160south

On Friday, April 12, 2013 at 3:01 PM, Chris Mohler wrote:

On Fri, Apr 12, 2013 at 4:23 PM, Kasim Ahmic wrote:

To be completely honest, I purposefully avoided mobile support. Considering that GIMP is a desktop exclusive program, I figured that adding mobile support would be a waste of time. If there is enough demand for it, however, I'll attempt to add it.

I would at least have a look at adding something like bootstrap. Adding a few classes to your divs and you'd be 99% done. Most elements would then scale to fit tablets/mobile, etc.

Use case A: I'm out at the bar and talking about design work. My companion mentions how all the software you need is expensive. I point out GIMP can handle quite a bit, esp when it comes to web and photos. My companion asks "can it do X"? I look it up on the site. Site looks bad == project looks bad.

Use case B: Loss of internet connection, no local help installed, but access to web via a mobile data plan. Easy to access the docs on the phone.

I doubt these cases are common, really - but using something like bootstrap or unsemantic doesn't take long and handles them nicely.

Just my opinion really - I see it as a relatively small amount of effort even if the gains are small.

Chris

On Fri, 2013-04-12 at 18:02 -0400, Kasim Ahmic wrote:

As for the CSS, I'm attempting to get it to pass W3C specs but it's proving difficult for whatever reason. I'll keep trying though.

If validator.nu or the W3C validator is complaining about prefixed properties, check with caniuse.com maybe, but the validators don't in general like prefixed properties - ignore those warnings & move on with life.

It *is* worth checking in the browser console (e.g. control-shift-k in firefox or chromiumuouioiouiouiuum) for CSS errors or warnings and understanding them.

If it's more than that, let me know if I can help.

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

On 13.04.2013 00:00, Kasim Ahmic wrote:

That's a pretty cool idea. Considering the space allotted for it I think only 1 article would be enough. If I see that one article has changed I would go to the news feed to read more news :).

Well we'll see when we actually implement it. I'll most likely have to use PHP for that which I have next to no knowledge about so it'll have to wait until we can get someone to help me out there.

If possible, I'd like to see a system that only uses whatever language to generate the site if there is an actual change. Anything important that is served to the user should be static, i.e. the site should continue working except for changes when we just plainly remove PHP/Python/Perl/Ruby/Go from the server or have to disable any dynamic features temporarily (0-day, anyone? ;) temporarily.

The current system is template files that are checked into Git and are run through make and python to create the static html files which get served.

Regards,
Michael

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

On Thu, Apr 18, 2013 at 11:50 PM, 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
(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?

Not using carousels would be a good start :) They are usability killers.

Other than that, it's generally advised to use Bootstrap wisely and

Here's some initial info:

http://webdesign.tutsplus.com/tag/bootstrap/ http://coding.smashingmagazine.com/2013/03/12/customizing-bootstrap/

And since Snashing Magazine is so awesome, here's some more useful info:

http://mobile.smashingmagazine.com/2012/10/24/beyond-common-media-query-breakpoints/

Alexandre Prokoudine http://libregraphicsworld.org

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 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 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

On 04/18/2013 04:31 PM, Kasim Ahmic wrote:

Well here's what I managed to get done today: http://kasimahmic.koding.com/works/GIMPB/examples/carousel.html

It's basically just a content swap. It still needs to be entirely restyled. Also, I found something out. If I change one of the classes, the body becomes fluid. The problem with that is the images (the browser icons on the page) and the text end up too far apart on the body.

This is the exact reason why I chose to go for a static design. The mockup that Mike made doesn't exactly work with a fluid design unfortunately. Unless we come up with something different, I'm afraid we'll be stuck with a static design.

This should actually be fairly easy to deal with. Either use the "max-width" property to keep the content from getting spread out too much and for browsers or user agents that display the page on a screen that's not very wide, the content can scale down to fit that size. The benefits of a fluid layout are worth the relatively little effort to make it work.

You're making great progress!

Peace...

Tom

/When we dance, you have a way with me,
Stay with me... Sway with me.../

On Thu, Apr 18, 2013 at 7:31 PM, Kasim Ahmic wrote:

Well here's what I managed to get done today: http://kasimahmic.koding.com/works/GIMPB/examples/carousel.html

It's basically just a content swap. It still needs to be entirely restyled. Also, I found something out. If I change one of the classes, the body becomes fluid. The problem with that is the images (the browser icons on the page) and the text end up too far apart on the body.

This is the exact reason why I chose to go for a static design. The mockup that Mike made doesn't exactly work with a fluid design unfortunately. Unless we come up with something different, I'm afraid we'll be stuck with a static design.

Also to pipe in my 2 cents. I checked the site in a mobile browser. I understand it's completely new and totally alpha code. That being said: I don't think it's useful for the Download link to show up in the mobile interface. Something to think about. I'm not sure how I'd handle that (maybe with JavaScript but that's still not desirable). UserAgents can easily be parsed on the server side but it sounds like static flat files generated is favored over server side execution for serving html.

I really like Elle's comments on accessibility. Just some thoughts and kicking around.

SAM

On Thu, 2013-04-18 at 20:25 -0400, Sam Gleske wrote:

[...] I
don't think it's useful for the Download link to show up in the mobile interface.

Why not? "Hey, Julie, do you have the download link for gimp?" "Yeah, it's... uh... I can't find it" "I wanted to run gimp on my iPad.."

I really like Elle's comments on accessibility.

+1

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

On Apr 18, 2013, at 8:39 PM, Liam R E Quin wrote:

Why not? "Hey, Julie, do you have the download link for gimp?" "Yeah, it's... uh... I can't find it" "I wanted to run gimp on my iPad.."

That's my point. GIMP doesn't run on anything but desktop applications. I don't see the need for a link to download files on a mobile in our case; iPad included.

SAM

On 04/18/2013 08:39 PM, Liam R E Quin wrote:

On Thu, 2013-04-18 at 20:25 -0400, Sam Gleske wrote:

[...] I
don't think it's useful for the Download link to show up in the mobile interface.

Why not? "Hey, Julie, do you have the download link for gimp?" "Yeah, it's... uh... I can't find it" "I wanted to run gimp on my iPad.."

+1

I really like Elle's comments on accessibility.

+1

That too!

In re changing page layouts per display, i.e. screen (the default), print, handheld (for mobile devices), etc, it can be done in "regular old" HTML & CSS:

http://www.w3.org/TR/CSS2/media.html

Support for the "screen" medium is always a given, support for "print" is almost so, and support for "handheld" seems to be good and improving.

What can CSS change in the way the same (x)html document is displayed? Oh, this and that:

http://www.csszengarden.com/

I don't have anything against Javascript, but I do believe it should only be used when/as markup language won't do the job, for better cross platform compatibility, lower client side overhead, support for secure networking configurations, etc.

:o)

Steve

On Thu, 2013-04-18 at 20:51 -0400, Sam Gleske wrote:

On Apr 18, 2013, at 8:39 PM, Liam R E Quin wrote:

Why not? "Hey, Julie, do you have the download link for gimp?" "Yeah, it's... uh... I can't find it" "I wanted to run gimp on my iPad.."

That's my point. GIMP doesn't run on anything but desktop applications. I don't see the need for a link to download files on a mobile in our case; iPad included.

I'm sorry I wasn't clear.

GIMP does run on some mobile devices today; that number is likely to increase. for example, Android, but you're right that it's not the main focus of development.

In addition, someone using a mobile device might look for the download link to give to someone else, or to save for later. Or I might want to download GIMP when I'm in a coffee-shop to take back to my home where I don't have good bandwidth.

Although it's common to make a mobile-specific Web site that's stripped down, the main functionality should all be there.

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

Liam R E Quin wrote,

On Thu, 2013-04-18 at 20:51 -0400, Sam Gleske wrote:

On Apr 18, 2013, at 8:39 PM, Liam R E Quin wrote:

Why not? "Hey, Julie, do you have the download link for gimp?" "Yeah, it's... uh... I can't find it" "I wanted to run gimp on my iPad.."

That's my point. GIMP doesn't run on anything but desktop applications. I don't see the need for a link to download files on a mobile in our case; iPad included.

I'm sorry I wasn't clear.

GIMP does run on some mobile devices today; that number is likely to increase. for example, Android, but you're right that it's not the main focus of development.

In addition, someone using a mobile device might look for the download link to give to someone else, or to save for later. Or I might want to download GIMP when I'm in a coffee-shop to take back to my home where I don't have good bandwidth.

Although it's common to make a mobile-specific Web site that's stripped down, the main functionality should all be there.

Liam

Agreed. Maybe my home internet has failed and all I have for the time being is a mobile device and I still want to download.

Bob Long

Rather than wade through the twitter bootstrap code, I reworked the original code to make *part* of it fluid, as a quick example of "how to". Here's a temporary link to the revised, partially fluid code: http://ninedegreesbelow.com/temp/gimp-site/gimp-redo-1.html

The original code is divided into header, body (not to be confused with ), and footer sections. The body section is divided into three subsections called "filters," "tools", and "downloads". Each body subsection has an image, a header, and a short paragraph. In the original code the images are background images, but I changed them to regular images. I set the various max-width values to the values indicated in the original code, and then at smaller screen sizes the images and text scale proportionately.

You can resize the page and the images and text in (only) the body section will resize to fit the available space, but of course the fixed width header and footer spill over into a scrollbar. In Firefox and Rekonq the fluid portion of the rewrite looks OK, but the layout is broken in Chromium (the slideshow drops down over the body section, haven't checked to see why; Kassim's original code doesn't have this problem).

With a fluid layout, at anything smaller than a 600px wide screen a media query should be triggered to start substituting different css code so that the images are full screen and the text slides under the images. Media query code works a charm, but I haven't put any in. How-tos on the web are readily available and I can supply some example code if it would help.

The apple-type icons are missing because I don't know where they came from. Personally I find the icons a bit distracting, but probably a lot of people like them.

Hope this example of "fluid rewrite" helps some!

Elle

On Thu, Apr 18, 2013 at 7:25 PM, Sam Gleske wrote:

Also to pipe in my 2 cents. I checked the site in a mobile browser. I understand it's completely new and totally alpha code. That being said: I don't think it's useful for the Download link to show up in the mobile interface. Something to think about. I'm not sure how I'd handle that (maybe with JavaScript but that's still not desirable). UserAgents can easily be parsed on the server side but it sounds like static flat files generated is favored over server side execution for serving html.

I don't think the link should be hidden. That being said, anything needed to be shown/hidden based on screen size can be handled quite easily with the utility classes, eg '.visible-desktop', etc: http://twitter.github.io/bootstrap/scaffolding.html#responsive

Chris

On Thu, Apr 18, 2013 at 6:31 PM, Kasim Ahmic wrote:

It's basically just a content swap. It still needs to be entirely restyled. Also, I found something out. If I change one of the classes, the body becomes fluid. The problem with that is the images (the browser icons on the page) and the text end up too far apart on the body.

This is the exact reason why I chose to go for a static design. The mockup that Mike made doesn't exactly work with a fluid design unfortunately. Unless we come up with something different, I'm afraid we'll be stuck with a static design.

There's a difference between the grid: http://twitter.github.io/bootstrap/scaffolding.html#gridSystem

and the fluid grid: http://twitter.github.io/bootstrap/scaffolding.html#fluidGridSystem

I've only given the proposed layout a once-over, but I'm pretty sure you want to use the default grid, not the fluid, for this layout.

Chris