Skip to content

WIP: Responsive project site #860

Merged
merged 41 commits into from May 2, 2013

5 participants

@cobyism
Jekyll member
cobyism commented Mar 15, 2013

Just kicking off a pull to improve on the new site design by way of making it a bit more friendly for smaller screens. I don’t anticipate huge portions of the audience will be viewing it on phones or tablets (chances are most people looking up the docs will be on their laptop/desktop, developing with Jekyll and need to look something up), but I’d rather it worked a bit better regardless.

:construction: Very much an early WIP. As it stands, this PR beats the site around a bit with an ugly stick. It’ll all come together eventually though…

soon

@zachgersh

@cobyism throw up a screenshot of your WIP! I want to see what it looks like from the phone / ipad.

@cobyism
Jekyll member
cobyism commented Mar 28, 2013

@zachgersh I appreciate your curiosity, but right now these are all mostly structural changes rather than anything worth looking at visually yet. Also, the tablet sized ones will (hopefully) look basically identical to the site as it currently stands—the only thing I really want to re-organize is how the top-level navigation and the docs/secondary navigation works on phones (as well as stacking overview page content when screens aren’t wide enough).

@parkr
Jekyll member
parkr commented Mar 28, 2013

@cobyism Just so you know, we're going to be updating a lot of the content of the docs so you will probably have a painful rebasing/merging in the future (if we want to use built-in GH PR merge here).

@cobyism
Jekyll member
cobyism commented Mar 28, 2013

@parkr Thanks for the heads up, but content shouldn’t be an issue. Most of my changes will be to the layout/include files and CSS :grin:

@parkr
Jekyll member
parkr commented Mar 28, 2013

@cobyism Awesome. :-)

@cobyism
Jekyll member
cobyism commented Apr 4, 2013

Aight this is getting much closer. Tables still don’t really work on mobiles, but there’s ways around that.

Screenshots are an inherently bad way to share responsive designs with people, so anyone who wants to check this out for themselves should check it out using shapeshifter instead (use the icons on the right to preview the site in different devices :grin:). Shameless plug: shapeshifter is another project of mine, and what I’m using to work on this design.

Would :heart: to hear any feedback people have!

@mattr-
Jekyll member
mattr- commented Apr 4, 2013
@cobyism
Jekyll member
cobyism commented Apr 4, 2013

@mattr- You mean more like this?

Screen Shot 2013-04-04 at 8 07 15 PM

@mattr-
Jekyll member
mattr- commented Apr 4, 2013

Yes! That is awesome!

@cobyism
Jekyll member
cobyism commented Apr 4, 2013

Well, we can certainly change that, the downside is that it brings the nav out of line with the thirds sections on the overview page:

Screen Shot 2013-04-04 at 8 48 11 PM

That’s only a small issue though—I do notice I’m hesitant for some other reason I can’t quite put my finger on though, but it’s probably a worthwhile change, since the majority of the time it’s the docs pages people will be looking at. On larger screens some extra space probably wouldn’t go astray either.

@cobyism
Jekyll member
cobyism commented Apr 4, 2013

There, made the change. It can always be changed again later if need be :+1:

@mattr-
Jekyll member
mattr- commented Apr 4, 2013

hmm. Now I see this on shapeshifter

Screen Shot 2013-04-04 at 3 07 52 PM

which makes me

sad-panda

The original is probably better.

@jwebcat
@cobyism
Jekyll member
cobyism commented Apr 5, 2013

@mattr- Do you have your browser viewport zoomed (in or out) at all? If so, what you see won’t be an accurate reflection of the viewport behaviour for tablets/phones. You do highlight a bug for viewport sizes in-between tablet portrait and mobile landscape though, so that’s something I’ll need to fix anyhow—thanks for that :smile:

@jwebcat Thanks for the suggestion, but I have a couple of reservations about doing that for the primary menu. Here’s my reasoning:

  • The navigation for the documentation section is already a dropdown on mobiles, so I’d be very reluctant to make the primary navigation menu into a dropdown on mobiles too. Doing so would mean that two navigation dropdowns are visible at the top of all docs pages—you could combine them, but I feel that keeping them separate and only showing the docs navigation on docs pages is a better option.
  • Chances are, most people land on the overview page, and click through to the documentation—after which I don’t imagine them really need to use the primary navigation again (unless they’re done with the site and want to view the GitHub repo). I imagine it’d be rare people will click back to the overview page once they’re in the docs. Also, since there’s enough space to display all three of these links on tablets anyway, the off-canvas layout would be being implemented just for mobiles. Given this combination of factors, I don’t feel like adding an off-canvas layout for the primary nav is warranted.
  • I’m reluctant to hide the links to the docs, and to the GitHub repo, for another reason though: they’re the two most likely things people will want to do when they land on the main page, and requiring an action to be taken (tapping on the off-canvas layout) to just see that there are direct options available to get to those locations seems like a bad move from a discoverability point of view.

As always, I’d be happy to rethink my position, but I feel like I’d need to hear a really convincing argument for why a different choice would be better for this site :grinning:

@mattr-
Jekyll member
mattr- commented Apr 5, 2013

I don't believe I had my viewport zoomed in any way.

With your fixes though, I have massive amounts of :+1: for this. :shipit:

@jwebcat
@cobyism
Jekyll member
cobyism commented Apr 5, 2013

@jwebcat The primary menu is already full width at the top on mobiles:

IMG_1239

The way I see it, using an off-canvas layout for this would:

  • take up the exact same amount of space
  • add in an unnecessary step for people to use the menu
  • negatively affect the discoverability of seeing what the primary nav menu contains just by looking.

I might be missing something here, but what is the advantage you see of hiding that behind an off-canvas toggle?

@jwebcat
@cobyism
Jekyll member
cobyism commented Apr 5, 2013

it could solve the layout issue on tablets

I’m not sure which layout issue you’re referring to. The bug @mattr- got sorted out by making the menu collapse more intelligently in 972b67c. Is there another spacing issue somewhere on tablets?

I'm wondering why don't you combine the two menus and have the navigate the docs menu a drop-down of the main menu.

I feel quite strongly that the menu for jumping between documentation chapters doesn’t belong in the primary nav. Nesting and hierarchy is the enemy of discoverability, and there are already section headings in the docs navigation to group chapters, so I’m really reluctant to nest all that under yet another level of required interaction to achieve the same net effect.

it also leaves room for
another main menu option(s) as the need arises.

Future flexibility should always be a goal, but we’re not shutting any doors here, so I’d rather design for what I believe the website needs right now. If the need arises, future additions to the site can always be addressed as subsequent issues and pull requests.

@cobyism
Jekyll member
cobyism commented May 2, 2013

Alright, just pushed some fixes that will (with a wrapper .mobile-side-scroller class around a table) make it so that:

A) Tables on mobiles break out of the column to take up more of the the viewport width. A screenshot:

screen shot 2013-05-02 at 2 08 19 pm

B) Tables that need more room than the viewport allows will be able to be scrolled sideways to view the rest of the information. An example:

jekyll-responsive-tables

Haven’t added the wrapper divs to the rest of the pages yet, but hopefully I’ll get to that later today. Unless I’m missing something, that should be the last thing needing tweaked for making the site responsive.

@parkr
Jekyll member
parkr commented May 2, 2013

@cobyism Would you mind rebasing on the current master? I can deal with the merge conflicts if you would prefer not to. Once you've got the wrapper divs for the rest of the pages done, please let me know! Nice work :)

@cobyism
Jekyll member
cobyism commented May 2, 2013

@parkr Sure thing. No worries, I’ll sort out the conflicts and have it mergeable for you in approximately 2.58 minutes. :grinning:

@cobyism cobyism merge in changes from latest master
conflicts:
- site/_posts/2012-07-01-permalinks.md
- site/css/style.css
- site/index.html
6a57d52
@parkr
Jekyll member
parkr commented May 2, 2013

@cobyism You :guitar:, thanks! :octocat:

@parkr parkr added a commit that referenced this pull request May 2, 2013
@parkr parkr #583 has been merged, but should wait for #860. 4c7b9cb
@cobyism
Jekyll member
cobyism commented May 2, 2013

@parkr Aight this should all be good to go. Anything else that turns up can be fixed/tweaked in subsequent pulls :grin:

@parkr
Jekyll member
parkr commented May 2, 2013

HUZZAH :cake:

@zachgersh
@parkr
Jekyll member
parkr commented May 2, 2013

Just checked this out and it's amazinggggggg

@parkr parkr merged commit 1404a97 into jekyll:master May 2, 2013

1 check passed

Details default The Travis build passed
@parkr parkr added a commit that referenced this pull request May 2, 2013
@parkr parkr Update history to reflect the merge of #860 1c4f5b4
@cobyism cobyism deleted the unknown repository branch May 3, 2013
@cobyism
Jekyll member
cobyism commented May 3, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.