For those who don't know, this disables user scrolling on every standards-compliant mobile device. The reason is a bug on iOS, that causes test to flow off screen when changing orientation on non-default zoom levels. http://adactio.com/journal/4470/
I really wish more sites would enable it by default, then use javascript to disable it for iOS devices. I have come across many sites with small text that I want to zoom, but can't (this is especially bad for people with poor eyesight). Disabling it for everyone reminds me of the days of IE5 and 6, when other browsers were hampered by IE's bugs; we are only starting to see what having no bug-ridden, dominant browser on the Desktop can bring.
Before anyone says that browsers shouldn't implement this feature, they should. For better or worse, it is a part of the standard. Using browsers that don't implement parts of the standard would bring about situations even worse then this.
A few weeks ago I made a bookmarklet for iOS that re-enables zooming and also sets the viewport width to the device-width (this is useful for pages that use the whole width, which leads to small fonts. E.g. Hacker News).
I agree. Responsive design itself is not difficult. But the sell must have been a difficult one. I'd love to hear it as well. My guess is it was based on a prototype. Seems everyone these days expects you to build one :-S
Having designed www.mogotix.com, which is completely responsive, I can say that fluid layouts absolutely create challenges that fixed layouts do not. That said, they're not insurmountable, and the benefits are substantial.
Elaborating: some things that are simple in a fixed layout can become very difficult in fluid ones.
Two brief examples:
1. Try embedding a YouTube video into a fluid layout. You'll need a JavaScript solution to remove the ugly black bands that will appear above and below your video.
2. IE 6-8 do not support media queries, which form the basis for fluid layouts. When we relaunched MogoTix in March 2011, I had to include a jQuery script to get IE to understand media queries (that script is now included by default in the 1140px grid at cssgrid.net).
If anyone has questions about implementing a fluid layout, feel free to ask.
I don't know about the person you're replying to, but I'll inject interactive components after page load (blocking them out so as not to cause reflowing, and hiding those blocks via media queries on inapplicable devices). Images, etc. are certainly trickier, I haven't found a good way to do that.
The fundamentals are solid (the line height is perfectly alright, about one hundred characters per line are within the range of empirical results on optimal readability).
I suspect the font is so small because the design is so old. As far as I know it hasn’t been updated in ages. It’s old but by no means bad design.
Ethan, the author of the RWD article, was actually on the team who worked on The Boston Globe site. He's been giving talks on the project and the process. I don't know if it is anywhere online, but it's very interesting.
I agree. The local newspaper here recently redesigned its website[1] with "social" rubbish baked right in, to the point where the paper's own news feed is now interspersed with the random ramblings of website users, Tweets, rants and ads disguised as articles. I particularly love the way reporters now have their Twitter names instead of actual bylines under their articles (hello, "moontunes1", "lexis1234" and "elksie"!)
It's a pointlessly "social" horror--they seem to have been reading too much trendy babble on TechCrunch or Mashable and too little UX literature. Who told them any of this was a good idea? We visit the local newspaper website to read the stories published by the professional journalists at that paper. If I want to read a stream of tweets and rants, I'll visit Twitter or a forum. What a mess.
It's worth noting that the Boston Globe is owned by the New York Times Co. I'd be somewhat comfortable (and admittedly, somewhat hopeful) venturing a guess that they're pushing this design as some sort of skunkworks project for their bigger brands.
That's an interesting idea. I'd be surprised if this was true on the simple grounds that this kind of cross fertilization and business unit coordination is very agile and the times doesn't strike me as agile as a parent company.
BUT... if it is true it's a very canny maneuver. Again, this kind of inside view of the process (the business end of getting this through) would be great to hear about.
(are the times ad sales coordinated across BUs? this would be the big tipoff... if so then I can see the redesign being coordinate)
one member of the backend dev team was posting in /r/web_design over on reddit. if you're really interested, it couldn't hurt to post a reply and ask him about things.
I'm seeing the right hand adverts chopped off on the right hand side. Both of them. That's not good business if you are relying on advertising revenue to support the financial costs of running a site.
That's one of the drawbacks of this responsive design drive, they don't take into account content that needs to be at a fixed and known size. When an advert gets chopped off or disappears from above the fold - that pushes down the value of advertising on that site. Too much of that and the revenue generated this way drops.
There's no point having the surprised face on declaring that I don't understand the web and it wasn't designed for pixel-specific rectangular spaces. That requirement drives the sustainability of a large number of organisations, there's no point pretending it doesn't exist.
Yes, it's not just the flowed columns. Notice also: the masthead logo, the weather bug, the section menus (which switch to collapsed "Sections" at narrow width), the photo sizes.
Actually, it's the weather bug and the logo that really do it for me. There's a lot of love that went into this design.
It's not the transition from one layout to another that is graceful. Under normal circumstances, you're not resizing your browser to use a site. What's graceful is the fact that the layout is well suited for each and every resolution you throw at it, whether you're on a full-screen desktop or a mobile phone.
They should release a video of shim in action. A video explains it much better than words can. (I was lucky enough to get a sneak peak of all their new stuff a little while ago.)
Yes, but it's purpose isn't to resize on the fly as you change your browser window. It's to have one set of HTML that reflows to your device correctly depending on the viewport width. I just checked it on an iPhone 4 and iPad (both portrait and landscape) in addition to a desktop, and it works astonishingly well across screens sized from 3.5" to 27".
Are the media queries a little laggy? Sure. I'll tolerate that over having to hunt down a stupid "view full version"/"view mobile version" link (and I'm sure some optimizations can be done).
I think this will set a new standard for the term "mobile-friendly"
Interesting trick, but I don't think (could be wrong) that's applicable in this instance. I noticed immediately that this doesn't work in the place where you're most likely to see a resize/dimensions-change event: a tablet or phone. When you switch orientation on either, it just resizes the entire page itself. So it's not super useful in the place that most needs it.
Also, though this is much more subjective, I think that really looks terrible. Too much stuff is moving.
I have terrible vision, and utilize the browsers zoom function a lot. On their new site, I can zoom without having to do a lot of horizontal scrolling (just in Firefox though, doesn't seem to work as well in Chrome). So, aside from the aesthetic for the masses, there's an element of accessibility here that shouldn't be overlooked.
I agree, except that they totally break zooming on mobile devices (or at least iPhone). I hate it when I rotate my phone and the text reflows at the same size instead of zooming to fill the wider viewport.
On the plus side, you don't have the issue of links breaking because they send iOS devices to their mobile ghetto that ignores everything in the URL after the domain name.
Keep in mind that the point isn't to be flashy when you resize your window, it's that the site will work just as well on tiny mobile screens, medium tablet screens, and large computer screens without separate domains, crappy shim layers (I'm looking at you, wp-touch), etc.
Or for people with high resolution monitors who dislike the fact that a lot of web pages have more white space on the sides than they do content in the middle when their browser is fullscreen or close to it.
Granted, I realize that making any specific column of text too wide hurts readability, but most sites could benefit from being more multi-column (size permitting) and getting some of the ads and other non-text elements out to the sides more.
Going to a website and seeing one fixed bit of content at 1024px or whatever in the middle is so very lame. I am glad to see some websites starting to move away from this, and now that working examples can be seen hopefully other sites will be shamed into following suit.
Very true. I've done layouts for newspapers before and I've noticed a few things:
1) White space looks wonderful, but for some reason we lend more 'serious creedance' to text that is small and crammed together.
2) Design is good to a point, but then drops off when it begins to feel 'commercial' I think after a hundred years of reading sloppily put together papers chalk full of the latest news, we sort of associate bad design with its 'genuineness' and overly clean design with something desceptive.
In the late 1980s there was a nice study that was produced with the advent of the then nwe-fangled laser printers. It showed that journalists were less likely to read a press release if produced in a neat, attractive sans-serif font, and more likely to read it for news content if produced in slightly distressed Courier.
I kind of get that feel too, and I think it might be related to the fact that many spammy/scraper news sites and amateur operations use designs off of themeforest or popular free WP themes, which tend to be fairly minimalist and white space heavy. Whereas pretty much all high end news outlets have extremely busy designs, and we have been conditioned to associate that with trustworthiness.
It is very strange how that works in our minds. You associate sites and immediately discriminate against the content because they look or 'feel' like other sites with less substantial content. For eg. the padding in Google+ gives me a feeling of amateur content (which it is). Same with sans-serif fonts - I got huge push-back at Techcrunch when I wanted to change the default reading font to a serif font, the feedback internally was that the site feels 'too serious'
The business of sites like NYTimes and WSJ make them feel 'authentic' for some reason. I have known this for a long time but couldn't really put my finger on what it was. I remember one of the first client websites I did back in 97 - we laid out absolutely everything that we needed on the page, but there was a lot of space, the client said that the site doesn't feel 'authentic' and I spent a lot of time simply thinking of things to throw onto the page to make it look busier.
I think this is something that a lot of developers and web designers know about, but for some reason I can't recall ever reading anything about it. If anybody knows if this phenomenon has a name or has any more information about it, please share. I have been reading a lot of design books this year and none have made mention of the link between a site being 'busy' and feeling professional
I used a similar technique on my web-based timeline-software. The aim was for the timeline to work at almost any size. Not quite perfected it but getting close.
That app would be really cool if you could visualize data that imports from other sources. Imagine documenting your facebook pictures instantly through time via the site's meta data and links to the pictures themselves, etc.
Well done. I noticed that the navigation gets borked when the screen gets really small. I think the choice here is to show a different navigation menu (rollover menus?).
It could also benefit from better copy. "Everything from a timeline's colour scheme and date range to its background image and intro text can be changed in the Settings tab." -- a wall of badly-punctuated text, really unappealing.
Kudos for the app though, it does look nice. More auto-importing and some iPhone action please :)
Not wanting to be confrontational but what are you talking about. There is nothing wrong with the punctuation of that text. It might not be Dostoyevskian in its elegance but it is grammatically correct.
I've lost my breath trying to read it... would use a comma or two. It's also completely useless and out of context -- that's a help box, not a sales pitch.
Of course, I am aware of Memolane. Significantly different product than ours. They are aimed at creating a timeline-based life history by importing all your social media.
We're aimed at allowing people create highly-customisable timelines on any subject for presentations. embedding on websites etc. We 're much more like TimeGlider, Preceden and BeeDoc's Timeline 3D than Memoland.
But just letting you know, background is way too busy :) Text is hardly readable in some parts. I have no idea what's going on and I'm a power-user who designed and used different types of UIs from MS-DOS shells to Kinect-based NUIs.
Text isn't selectable on the items in Safari which I think is a big deal. Hyperlinks on top right aren't underlined, I didn't even know they were hyperlinks before I hovered on them.
It's like a splash of colors of all sorts, different fonts and text in my face.
The [More->] windows scroll too slowly. A full finger movement of the wheel only advances the text by a single line. It feels sluggish and frustrating.
We are aware of this issue but it is difficult to solve because each mouse works differently. For instance, the apple touch mice cause scrolling many times faster than the average mouse on a Windows machine.
If we speed up the scrolling for the average mouse, then scrolling will be ridiculously (unusably) fast with the Apple Touch mouse.
We have to achieve a balance -we may not have achieved the best balance but that is quite tricky to do. Bloody technology!
I am IN LOVE! It has been years since I've seen a mainstream site that didn't force itself wider than my default window (usually 600-800px, a bit less than half my screen). A lot of the sites that "try" to "address" the issue of multiple resolutions still focus on two targets: mobiles, and full-screen 1024+ monitors. Some of us are in between!
I loaded this and thought, "What's the big deal?" I'm sure many people, on many different browsers/platforms/resolutions, thought the same exact thing, which is what makes it so brilliant.
Did you actually play with the url? It pulls in the dependencies in one file, in any order. The genius part is that it's creating cached custom dependencies for each page that could potentially be shared by other pages. This is the most efficient dependency management approach I've seen. For sites that could have hundreds to thousands of pages, css/js asset & dependency management is so critical.
Something doesn't need to be difficult to implement to be extremely useful.
If you like that idea, you might want to take a look at library I am developing in my free time.
The idea is that you specify things you need (for example Mootools:Core and Mootools:More:FormValidation) and dependency manager pulls the required code with dependencies in correct order. It is in ruby, though (rack middleware + standalone packager).
Nope, by what I can see. Basically all CSS[3]. The JS they have seems to be for libraries like Modernzr (HTML5 related) and some other things.
Basically, in the CSS there is code like "@media screen and (min-width: 480px) {}" where everything within the curly braces is ONLY for browser windows that are > 480px. So, you can do all sorts of combinations like max-width: AND min-width:. When the window is resized it uses new rules.
AFAIK people refer to this as 'Responsive web design' and thankfully is being picked up by a lot of designers/developers. There's a ton of ready-made CSS frameworks and the like available for people to use.
(People, feel free to correct/clarify my explanation)
You don't have to be a huge web design shop to successfully build fluid websites. A good place to start building sites like this is the 1140 grid[0]. We've knocked out a couple of client sites with it [1]. Getting the basic layout to resize is super easy...it's the positioning details for the media queries that can take hours.
I assume they are testing the waters for something similar for the NYT. I think it's very successful visually, and certainly a nice use of this new technology. My only nitpick is that I wish there was more letter spacing on the headlines. I don't know why the type has to be so squished.
That is very nicely done. I am glad they didn't go for the temptation to put the display add in the laft column so that as the page shrinks it re-flows to putting only ads above the fold.
This is a great responsive design. This works, in part, because it is a news site with predictable image sizes, headline sizes, and very limited GUI.
If you want to build something that is more graphically intensive, with more focus on visual appeal in traditional browser sizes, it gets more and more complicated. I'm working on a project now actually, and it's pain. I'm not saying it can't be done (it can with a lot of work). It's just more difficult and time-intensive the more graphics you use.
This is great stuff for adapting to different screen sizes, but it's hard to see it as the perfect solution to the varying needs of different devices. It works reasonably well on mobile, but still results in a fair amount of wasted bandwidth. And some pages (looking at you, registration interstitial) serve up 150kb+ images that aren't displayed at all on mobile devices.
It may be responsive to my screen size, but it certainly isn't responsive to my data plan.
I would have liked to see the resize use additional space by bringup an additional column of headlines instead of just expanding the already useless picture.
Here's a nice thread on newspaper designs, shamelessly jumping to my head-to-head of above-the-fold comparisons of the top 10
The real success here - if it is successful - will be convincing readers that have previously had free (for registered users) access to Boston Globe content at Boston.com to pay $208/yr simply for the new interface. It will be the same content, with a few exceptions, simply rehosted at a new site with a new URL.
If they're able to convert even a subset of their current audience over, journalists everywhere will rejoice.
Definitely. Still I am not sure if subscription is adapted on the net - do they also offer single issues? As a buyer, I rather pay single issues. At the time where there were only paper issues, we used to take a subscription for the local or national newspapers. Now that the net has so much diversity, I want to multiply my sources. The single issue order that many iPad apps offer seem more comfortable to me.
I think it is worth pointing out that this is not a redesign but an entirely new site. That probably made the website easier to develop. The old site, boston.com, hasn't changed.
Apologies, I posted before drinking my coffee. You're absolutely right.
What I meant to comment on was the fact that the menu displays when you hover, and then you have to be extremely careful to move your mouse vertically first, lest you accidentally hover over another top-level menu.
It's a question of ease of content-browing v ease of navigability. Having to click on a top level menu item would make the former slower, but would speed up the latter, personally I find the hovver-bother quite annoying.
This looks great. It's awesome that we can make sites like this that theoretically allow us to serve the same pages to desktop and mobile browsers. I'm curious though, is there any significant overhead to having mobile clients parse 1600+ lines of HTML, or is that a non-issue these days? Anyone have any data points on this?
Aside from having a great design, what's excellent about this is that they're working with new design concepts and implementing them well. Responsive web design is huge for newspapers and other sites with lots of text and images. The Boston Globe is hopefully the first of many great redesigns using this method.
Seems to compare favorably to the Andy Rutledge redesign (http://andyrutledge.com/news-redux.php) save for the ads. The ads on the story pages don't work as well resulting in horizontal scrolling.
I think responsive design that changes when resized like this is a bit annoying and unexpected. When I'm using the page and I resize it, I lose my place on the page and all the content reflows. There's nothing in traditional media that works that way.
>> There's nothing in traditional media that works that way.
And that is exactly the point - it feels like we are finally waking up to what the web can really do that traditional media cannot. I'm sure in a few years having the content reflow will be something users expect of every website (not that it is something people do all the time - see the comment that guywithabike made).
To answer your question: to make the page more readable, if resizing changes column width.
But your question is the wrong question. The reason to have a fluid layout is to have a single version of the page that looks good on screens of all sizes, computers, tablets, and phones.
Nice design and a layout that I'm sure will be mimicked by a number of other traditional paper outlets - if they're smart. Now to figure out how to do it myself! hehe
I really wish more sites would enable it by default, then use javascript to disable it for iOS devices. I have come across many sites with small text that I want to zoom, but can't (this is especially bad for people with poor eyesight). Disabling it for everyone reminds me of the days of IE5 and 6, when other browsers were hampered by IE's bugs; we are only starting to see what having no bug-ridden, dominant browser on the Desktop can bring.
Before anyone says that browsers shouldn't implement this feature, they should. For better or worse, it is a part of the standard. Using browsers that don't implement parts of the standard would bring about situations even worse then this.