msysgit.github.com Site Redesign

[BaconRanch]

As discussed in msysgit/msysgit#99 I have redesigned the Git for Windows project site and am submitting my idea for the new site here. I expect that the textual content of the site will need revision as I have made some assumptions when writing it. As for the site design, I welcome any requested modifications and / or commits by others.

Feel free to edit!

As I could not get http://htmlpreview.github.io to display SVG images or custom fonts, I have left the latest version of the redesign hosted here for review:
http://dl.dropboxusercontent.com/u/40538551/gwhtml/index.html

[sschuberth]

First of all, I think the page looks really great. No comparison to what we currently have. Design-wise I have no further comments, but I think we need to discuss a few more last things:

1. The text "Git SCM" in the first paragraph (not in the title) should probably link to http://git-scm.com/.

2. The "Download" button does not link to the latest release but to the list of all "Full installer for official Git for Windows" item on the Google Code page. This is fine with me, I just wanted to point that out.

3. The "Download msysGit" button however links to a list which shows the "net installer" only. I'd suggest to link to http://code.google.com/p/msysgit/downloads/list?q=installer+hack+on+git instead to also list the "full installer".

4. There's the general question of whether we should link to https://github.com/msysgit/git or https://github.com/msysgit/msysgit, e.g. for the "Repository" and "Issue tracker" links. IMHO it should rather be the latter than the first. The difference between the two is: Our "git" repository is just a fork of upstream Git with some Windows-specific patches that we strive to send back upstream. This is not where currently the major work of the Git for Windows project goes into. On the other hand, our "msysgit" repository contains the whole environment (MSYS, Inno Setup installer, resources) that we ship with Git for Windows. This is what makes up the Git for Windows project. That's why I think we should usually use links that point to "msysgit" and its sub-pages. However, for issues, there's almost a 50/50 chance that bugs might be in upstream Git (and should go to https://github.com/msysgit/git/issues) or in our Git for Windows distribution (and should go to https://github.com/msysgit/msysgit/issues). Most people are unclear about this difference, but if there's a good / concise way to describe that difference so that everybody understands I think we should in fact link both issue trackers form the main page.

[kblees]

@sschuberth 4) I don't think end users will be able to make that distinction. Having multiple issue channels (i.e. an issue tracker per submodule + mailing list + old google issue tracker) only leads to lots of duplicates. See the long filenames issue or the recent git-cheetah missing-menu-items bug. In addition, we can't honestly expect users to search all available issue trackers before filing a new bug report. If we can't disable submodule issue trackers, we should at least not advertise them.

[dscho]

Overall much better than I feared: it works without Javascript (my biggest fear). However, the choice of .svg was probably not the best. See these photos taken from my phone:

[dscho]

The previous comment also pointed to the problem of screen estate. While phones are really hard to target, tablets (even seven inch ones) should have enough resolution to fit the complete page (but of course it does not hurt to use more -- when available):

Finally, there is a funny thing going on with the images in the bottom part: I cannot see them in Safari:

Compare to Firefox:

[dscho]

As to the source code:

• you might want to decide between spaces or tabs (my tabs are 8-spaces, so the mix looks pretty awful)
• why not use the newest lightbox?
• why not use the lightbox and jquery from Lightbox' page?

Another funny thing I stumbled over: when I loaded Lightbox' page into my phone's browser it looked pretty awesome, even in portrait mode...

[dscho]

@sschuberth @kblees I agree that it is too much to ask Windows users to discern which of the three places (msysGit/issues, git/issues, vger) they need to report their issues to.

I would vote of giving them a lot of slack and recommending git/issues for all issues, to be redirected by the helpful volunteers of the Git for Windows project.

Hmm?

[sschuberth]

@dscho @kblees OK, so let's stick to one issue tracker then, but IMHO that should then be this one and not that one. We should then move all issues from the latter to the former (with proper labels) and remove the issue tracker for msysgit/git completely (fortunately, that's possible on GitHub in contrast to Google Code).

[BaconRanch]

@dscho A note on Lightbox: On Lightbox's Releases page, you can see that the latest version, 2.6, was relased just 5 days ago. You happened to post your observation about it the day after the release. :) I'll update to the latest version of lightbox and jQuery.

[BaconRanch]

@dscho I chose to use SVGs because they could be scaled and redrawn by supporting browsers without the "soft" looking smoothing algorithm that browsers run raster formats through like PNGs when the page is resized. While I understand the need for PNGs in non supporting browsers, using a vector format to represent digital artwork on a webpage is becoming more popular and will only have increasing support on mobile and desktop browsers in the future.

To keep the best of both worlds, I created a solution that loads PNGs by default but switches to SVGs if supported by the browser. I added a branch called pngsvg in my fork and committed this change. The hosted site on Dropbox has also been updated. Images now display on my Android browser. If you could test this out on your devices and you approve, I'll merge it in.

By the way, what version of Firefox were you using for the last picture you posted, where one of the SVGs looked stretched? Also, was that on OSX or Windows?

[dscho]

FWIW this is my attempt at demonstrating where I think this must go: https://github.com/msysgit/msysgit.github.com/compare/pngsvg

It would be good if the style sheet could be less restrictive: there are quite a few absolute pixel sizes encoded there, and quite a few places where the screen is assumed to be substantially wider than 480 pixels. It would be nice if the design could look real nice even on handhelds. I could imagine that this can actually be achieved by less rather than more CSS...

Remember: http://quotesondesign.com/antoine-de-saint-exupery/

[BaconRanch]

I have added stylesmall.css which should take care of smaller screen sizes. Granted, I haven't tested it on lots of small devices (I've been trying to get a copy of the iOS SDK for the iOS emulators but the Apple developer site is actually down) so there may be some slight bugs that need revision but I think it's a good result. stylesmall.css is only about 40 lines long, but as far as revising style.css I can think of two things:

1. Move common CSS style definitions into CSS classes
2. Consider replacing fixed font sizes, margins, and paddings with em or rem units

I noticed your take on the PNG & SVG idea and it seems that it excludes Javascript in favor of using IE conditional comments. The only problem with this is that we will only exclude SVGs on IE, not on mobile browsers that don't support them. Unfortunately, it seems that the only way to truly determine whether the browser supports SVG is using Javascript- conveniently through the Modernizr library.

I have recently been re-thinking my decision about insisting on SVGs. If you prefer avoiding heavy use of Javascript for the site, I would be just fine using PNGs only as the git logo at the top of the page doesn't resize at all and stylesmall.css has the images in the Contribute section disappear at smartphone screen widths (they are purely cosmetic- easy to get rid of when screen space is at a minimum.)

[sschuberth]

Just to throw in my two cents in here: While from a design point of view I can perfectly understand to favor SVGs over PNGs as they scale resolution-independently, from a performance point of view rasterizing SVGs in order to display them takes a reasonable amount of time / CPU power. If we are looking at small devices currently, in this context it IMHO makes much sense to revert to PNGs only. If that gets rid of a significant amount of JavaScript code, the better that is. @BaconRanch, so I think we should do as you've proposed in your last paragraph.

[hvoigt]

I can confirm that whats current on the dropbox link works well on iOS. The only minor thing I can see is that it could use some margin around the borders. Currently the letters start directly on the edge of the screen.

This already looks really awesome. Compared to our current site its such a vast improvement design wise! How about we merge this soonish and then iron out any leftover stuff later? I think we should not do to much bikeshedding.

Regarding small devices and SVG I am not sure whether it actually takes more computing power to rasterize a vector format or to decompress png.

Comparing BaconRanchs design with http://git-scm.com on my phone even looks way better, so I think the goal of making the site mobile compatible has been reached.

[sschuberth]

@hvoigt Experience taught me that "merge now, improve later" just does not work. People tend to think that getting merged means to be done, and are happy to not touch the code anymore. So let's just clean the JavaScript code by using PNGs only, and then merge.

[BaconRanch]

@sschuberth As of https://github.com/BaconRanch/msysgit.github.com/commit/ae33aaf5055ba25b1e88e521c46ed1f6cd153bee which is the latest commit to my fork, the site is PNG only. I have left the SVGs in the images folder as they make good sources in case you want to generate larger PNGs later for whatever reason.

I think the only thing left to do is "Include a portable download among the official ones:" #5
I was thinking we could have a small link below the large "Download" and "Contribute" buttons that says "Download the Portable Version"

Oh. We also need some margin on the small version of the site, as @hvoigt suggested. I'll do that too. Let me know what you think about the Portable Version Download link though.

[BaconRanch]

@dscho @sschuberth I've added horizontal text padding and the portable download link. At this point, it looks like all the requests outlined in earlier portions of the discussion have been met!

Not to jump the gun, but it looks like we're very close / altogether finished!

[dscho]

@BaconRanch as I pointed out, I'd like the design to be leaner. The most obvious setting that disagrees with my notion of a lean design is the hard-coded absolute pixel values in the .css, such as min-width and height specified in inflexible px units. While I think that we will always have to have a small screen-specific .css, I also firmly believe that over-specifying dimensions for the general case will always break common expectations, such as "I want to resize my browser but the page no longer looks nice." or "It looks nice in the browser, right until the point when I print it.".

I also see that no commit was rewritten, but commits were added that undo other commits in the pull request. However, in the interest of getting this on https://msysgit.github.io/ already, I tend to propose that we should not be as strict with this pull request as we usually are with our code.

[BaconRanch]

Hey guys! I'm still here. I know it's been awhile but I've just gotten all moved back to college. I will work on this during this weekend and see if I can't optimize it. I know some explicitly set heights are required based on the design, like the height of the white gradient page header before the "Tools & Features" and "Contribute" blue parts of the page. I hope I can remove many fixed measurements from the page though. I will let you know if I run into problems.

[dscho]

I finally know what is bugging me, after reading this post. The visual design looks fine, but the HTML design is mixing form with substance. That is the reason why the same content looks awesome on a desktop but not so awesome on a tablet, and why the fixes for the tablet do not fix it for a 4 inch screen.

So I am tempted to ask for a reimplementation based on proper separation between content (in index.html) and form (in the .css). For example, I would like not to read anything like smallscreenfullwidth in index.html, and I would to strike <meta name="viewport" content="width=480px, maximum-scale=1"> from it, too, and I would like the default .css to contain only relative measurements, and only when necessary.

In other words, I would like to ask to strip every style definition down to the bare minimum, so that the style is defined in the most generic way possible.

[BaconRanch]

@dscho I have made a start by replacing px values with relative values in the CSS styles. The entire page can now be resized using the first CSS rule in style.css, the html rule.

I agree with the idea that HTML should describe the content of the page, and that this idea should extend to CSS classes that are built based on how they should be used rather than how they look. smallscreenfullwidth for example describes a visual characteristic that the element should have rather than describing what it is or implying what it does- and that's a violation. I will try to organize my style definitions in a way that is more appropriate to this principle.

Finally, I will see if there is a way to reduce or minify the style definitions and still achieve the same design.

[dscho]

Superseded by pull request #10.