Purdue Online Engineering – Episode #321
Site Scores:
| Site | Visual | Information | Code | Overall |
|---|---|---|---|---|
| Purdue Online Engineering | 92 | 89 | 85 | (266/300) 89% B+ |
Today’s Tip:
If you do any adaptive layout at all focus on the desktop and the smartphone sized screen. Add an extra style sheet for the small screen and make modifications to at the bare minimum remove any requirement for :hover states and position everything vertically. This way at least items can be clicked on and the users isn’t forced to pinch zoom every time they visit a new page.
Show Notes
Like what you see? Subscribe to the video blog through RSS, iTunes or sign up to receive email updates when new episodes are posted.
Tags: episode

June 28th, 2012 at 4:20 pm
Nick, can you elaborate on your disappointment with the collapsible menus, even after you saw the responsive reason for them?
Because I thought it’s probably the most obvious answer to prevent the mega-scroll on the mobile-sized responsive versions of Higher Ed sites.
And worst-case scenario, on the resolutions where you don’t need the brevity, it’s just a little easier to scan?
July 1st, 2012 at 8:26 pm
Eric,
Are you talking about the select option menus that show up in the mobile view?
July 2nd, 2012 at 8:48 am
The collapsed content you point out at 7:30.
https://purdueonlineengineering.com/mechanical-engineering/admissons/
Way easier to scan in the mobile view. And I don’t really see a downside in the full-screen view. Right when I saw it, I thought, “That’s the answer!” But your aversion to the idea scared me…
July 22nd, 2012 at 7:00 pm
Eric,
I see what you mean. I was thinking you meant the menu going from desktop to mobile view.
My issue with these types of collapsable areas is that there is no need for them to be collapsed, who cares if the page is long. Add some anchors at the top of the page that look like a menu and jump the user down to relevant content.
For me it isn’t natural to have what are essentially menus in the middle of page content when the content behind the menus is already there. Not to mention it breaks the CTRL+F ability.
I can see the use if it was a really long page or if the content behind each area was intended for a different audience, but on that page in particular if a user was looking for admission information I am willing to bet they are going to look at as much as possible.
Just my two cents. I guess in the end it just comes down to user testing, if this works for their audience, more power to them, collapse away!