I came across Redub's "Don't Make Me Scroll" presentation embedded above, which looks at the current offering of magazine readers which are modeled after print layouts, are difficult to read, SEO-unfriendly, and which rarely use the full capabilities provided by web browsers, e.g. multi-media. Or they're modeled largely after blogs with articles are long and scrolling, are limited by the possibilities of HTML/CSS, and have layouts that aren't differentiated from blogs and which pale in comparison to the layout in the printed version of the original magazine article.
Redub is working on a magazine reader, built on Flash, with a keyboard-enabled UI (input devices work as well) that scales to any screen size, does not scroll, and provides designer-friendly layout possiblities. You can check out the GOOD magazine demo to experience the reader. There's some really interesting interface design happening there including unobtrusive menus and prev/next paging controls, a pagination bar that is scaled to indicate the amount of content on the page, great examples of interactive media in the content, e.g. interactive charts, and hints at personal options like annotations. It's very well thought-out and works better for reading magazines than any of the readers out there.
It seems like they're trying to do for online magazine reading what the Kindle does for ebooks. Exciting stuff to see the full potential of Flash being utilized to improve the magazine reading experience, rather than just port it over to an digital, PDF-like version that doesn't work as well on screen.
I was kind of amused to read "Don't Make Me Scroll" and then look at their demo app which has a large pagination / scrolling widget. Admittedly, it does seem to work a little better than pushing "space" on a vertically scrolled article. At least with this interface, it's really clear where to start reading from after hitting the "right arrow" key.
And just to keep on rambling - I don't necessarily buy that the visual language of publishing is limited because of HTML / CSS as the article implies. I say, look at Jason Santa Maria's blog:
http://jasonsantamaria.com/articles/what-the-world-needs/
http://jasonsantamaria.com/articles/shake-it-like-a-metaphorical-picture/
Or A Brief Message:
http://abriefmessage.com/2007/12/05/twemlow/
Yeah - this is the stuff that inspires me. And, importantly - it feels like the web. Not some strange thing that won't let me double-finger scroll...
As with books, some of the longer magazine articles that have layouts that break out of the vertical feel of the web newspaper and blog model seem like they would benefit from a different type of interface. The comparison to look at is the printed NY Times Magazine article vs. the web-version of the article. The web version loses all of the special treatment that the printed version gets. I think many people would agree about that.
I agree with you that HTML/CSS and JavaScript gives you almost anything you'd want/need to design the right experience. No doubt, CSS3's columnar layouts that approach something like John Weir's original IHT article layout (from 9 years ago!) will help with this. I'm also a fan of JSM and ABM, which you mention, but those examples don't (yet) show what they might do with longer format copy.
I appreciate your arguments, believe me, because I favor HTML over Flash. But I think redub is doing something worth taking note of. As a concept, redub's effort is attempting to question established solutions in terms of the core problem for designers--how do you give the web magazine article the same special treatment that the printed version gets, while still making it feel like the web. They're proposing re-framing the environment for reading on the web, and additionally providing the contextual controls for doing more with that (e.g. annotation, sharing pages, etc.).
Every few months a new reader seems to hit the scene, and the thing that seems to be the same with all of them is that they are trying to solve problems I (as a user or a designer) don't have. The problem is not one of layout or fitting the sinking-ship of ad sizes onto a page, it's about engaging users. That doesn't need to be done with Flash or bells and whistles, it can be done with beautiful, considered design.
If anyone is feeling limited by HTML and CSS, it's not the programming languages fault, it's the fault of your own imagination. These tools are flexible and highly accepted on most of the world's computer systems. What value is there in developing a new kind of interface for one type of content that visitors will have to learn again? Let alone one that uses Flash? What of all the standards we've pushed so hard for? Not only coding standards but standards of usability for visitors with varied mobility/disabilities?
I'd rather see more progress and experimentation being done in the native language of websites. What are the limits of HTML and CSS that they mention? It doesn't sound like they know.
> What are the limits of HTML and CSS that they mention? It doesn't sound like they know.
It may be more of a gap in experience or resources to use Javascript for a similar experience, perhaps. I perceive this product as an attempt to support designers that feel they do have problems porting magazine article design to the web, whether it's due to a lack of resources to hire either an external or internal web design/development team, or some other limiting situation. It feels like they're doing this for that audience primarily. Maybe these designers don't have the technical resources to make a CMS work with the flexibility to position things as easily as they could with InDesign. Remember that their product is a content management system that works with this reader. It's not just the reader alone.
Given that this is the front end for a CMS, and I'm hoping it's not just a CMS that lets you dump PDFs in (that's not what I read), this might be a considerable undertaking. If they succeed at creating an efficient workflow between print publication to web publication without necessitating a lot of hand-coding, wouldn't you agree that this would be something many people would like to dissect and understand? I certainly would.
It's too early to tell what this is beyond the demo, but the fact that it suggests something more is what I find promising.
I see what you're saying, but I just can't see this making all that much of a difference. And if the goal here is to allow people transitioning stuff from print to the web, I would much rather see Redub, or those designer, learning about the medium before throwing up their hands in frustration and creating a new style of browsing (another hurdle to the conventions of how the web is used).
I saw you also mentioned about the distinction between long-form articles online. I've done this a couple of times on my site, though not to the many-page levels of some magazine articles online (I just don't really write longer stuff). But, I actually don't think this is as much of a problem either, most magazines only keep up the heavily designed layout for half the article before skipping on to the continued story at the back that's just text. This figures on the assumption that you've read half of the article so you must be interested enough to keep reading, even if there aren't many pictures from here on out. The same could be true for the web.
At the end of this I just get hung up on the assumption that something is broken with regard to design in web pages. I've always felt like we haven't actually explored things enough yet to make that call. These readers have always rubbed me the wrong way, and I've yet to see one that does a good enough job to make me think differently about design on the web.
> At the end of this I just get hung up on the assumption that something is broken with regard to design in web pages. I've always felt like we haven't actually explored things enough yet to make that call.
Excellent point, Jason. It's one that I agree with. I put more stock (or maybe a more impressed by) developers who stretch the possibilities within the capabilities of browsers without plugins, which might be evident by what I post here.
In any case, thanks to you both, Justin and Jason, for this dialogue. As always, I gain and learn more from the exchange of ideas after the fact than from posting the intial entry. Maybe I should find more controversial issues to selfishly expand the range of topics.
All very interesting points in the presentation... up until the launch of the Redub demo which I think is *dreadful*. Not intuitive or pleasing to use at all.
NYT, Guardian, The Times, etc. are all very successful web ports in my opinion - it seems Redub are trying to fix something that isn't quite broken... yet.
As for magazine layouts/spreads, I think JSM achieves this very well indeed with a different look and feel for each article twinned with consistent navigation and structure. The articles don't feel constrained by fixed templates in any way to me. This isn't technically challenging, it just takes a little more technical and design effort.
Finally, what is actually the problem with scrolling? It feels natural and sensible to me. Check out this (fantastic) incredibly long post... it doesn't feel difficult to read:
http://www.cityofsound.com/blog/2008/04/monocle-design.html
I think the only thing to bear in mind with long posts is that you shouldn't need to scroll back to the top to reach the sidebar or top navigation.
Why is Flash vs. HTML even being argued over here? They are both simply means to display an interface online, each having pros and cons. The point of this has little to do with programming/development and more to do with the flaws of existing systems for digesting content online (particularly longer text pieces).
Something to note, what is commonly considered as usable online has grown out of the constraints of the web over the past decade or so (scrolling being the primary example). The scrollbar is usable and easily understood by any level of user, yes. However, that does not mean that is necessarily the best solution. The scrollbar is commonplace, that is what makes it a friendly navigation tool. The scrollbar grew out of the constraints of interface development on the web at its advent.
If you look at the printed word you can see that we found ways to evolve past one long lump of text, via pages.
Keep in mind, reading is not a race. The experience of reading should have an ebb and flow. There needs to be pauses, moments for the eyes to rest and the mind to relax. One long piece of text on a single page with lots of clutter does not allow for this.
Just to jump into the fray here, I'm the person behind the Redub Reader (along with Ryan Lauer, who is Redub's Design Technologist in charge of Flex). I just want to address a couple of assumptions being made here in the comments:
Assumption 1: Redub must not have done enough HTML/CSS coding to know how to design around its limitations.
"I would much rather see Redub, or those designer, learning about the medium before throwing up their hands in frustration and creating a new style of browsing (another hurdle to the conventions of how the web is used)."
Actually, I've done far too much HTML/CSS coding over the past 10 years (my first project was coding the HTML for the Discovery Channel Online site back in 1997, one of the first major content sites to publish daily, and, incidentally, before CSS was even conceived) and I'm tired of spending 75% of my time making CSS do backflips to deal with IE6 (not to mention differences between Webkit and Mozilla etc). This is not a boast. I want those years of my life back to get back to doing some actual design.
We actually came to GOOD through a proposal which we authored with Kiss Me I'm Polish to redesign their site back in 2008. We were responsible for the reconceptualization and information architecture, and we supplied the front-end HTML/CSS templates based on Agnieszka Gasparska's incredible designs which were then integrated into a heavily customized WordPress. You can see the result at http://good.is.
While I feel good about the resulting site as did the client, I knew that the editors and creative director still wanted more (this is somewhat anectodal but I will get actual confirmation from Casey). They wanted a more immersive environment, they wanted interactivity and a visual showcase for their Transparencies, which were their trademark luscious information graphics. But at the end of the day, they had to settle for an enhanced blog, if only because that was what could be developed and realistically maintained for their budget.
All this to say: we know what HTML/CSS/Javascript are capable of. But as designers, we have found ourselves getting perilously close to the point of contorting design to fit the constraints of the technology.
Assumption 2: Redub doesn't care about web standards and "conventions of how the web is used."
Firstly, the goal of this demo was to re-examine how we read on screen. We didn't want to limit this to "web browsers" because we are planning to deploy this as a desktop app where we think it will be most useful.
So, yes, we decided to compromise adherence to web standards like HTML and CSS (which versions are standard again? Are we at HTML5 yet? and which browsers' Javascript and CSS implementations are standard?) in order to get to the core ideas. To me there were specific limitations in these technologies that have been getting in the way of us looking at the ergonomics of screen-reading (e.g., auto-columnization and multi-touch ought to be web standard but aren't yet).
Why is it so tiring to read on screen? Is scrolling the only way to move around a document? What is a "page" anyways?
Hi Irwin,
It's always interesting hearing the "why's" behind a decision. I totally agree that the ergonomics of screen-reading are often broken. And, that inconsistent application of CSS and JS support in browsers makes development difficult.
But, I don't think that the second causes the first. What's good about your experiments with Redub Reader is that content is king. Once you're reading an article there are no calls to action, advertisements or related content links. The article is in focus simply and clearly.
I think fixing reading ergonomics is more about negotiating readability through cultural and business change than deciding between Flash or HTML/CSS. If we compare Redub with Good.is (which is great btw) - Good.is just feels like a nice blog implementation. If you click on an article the mechanics of the blog dominate - the organisational desire to brand, sell, get me to participate (rate, favourite, comment and share) and bounce me from one article to the next. Redub turns the volume down on all of this, and this encourages me to read (1).
But in Redub, I don't see an answer to the bigger challenges. How can we satisfy an organisation's business needs while achieving readability and immersion? How do we emphasise content while encouraging participation? How do we do this so organisation's make enough money to pay for the content?
Having said all that, I'll get back to the technical. I'm a HTML man biased against Flash after seeing one too many Flash intros and whole Flash sites with extreme usability issues. However - as I said in my original comment - your choices have engineered some definite positives:
1. Consistent typography for all platforms with lovely type-face choices.
2. Article column and page layout dependant on screen resolution.
3. Animation between page changes that act like a pseudo page turn, giving context to the navigation action, fixing the "where do I start reading from?" issue found when scrolling a long article.
I can think of ways to possibly achieve points two and three in HTML/CSS with a little server-side help, but no way to achieve point one yet (maybe soon Typekit? (2)). The bearded hippy in me says that these positives are not enough to throw out HTML & CSS. I like that these open languages make the web's content accessible in so many ways.
The only other negatives I could criticise Redub for have little to do with platform choice as most of the "naive" Flash issues (like inability to select text, lack of bookmarkability) you've already fixed. Instead they're more generic usability problems:
1. The article list view doesn't respond to scroll-wheel events.
2. Mouse navigation is awkward - back and forward are on opposite sides of the page.
3. Sentences are sometimes broken across multiple pages - the pagination algorithm could be cleverer.
Cheers, Justin
==================
(1) http://aworkinglibrary.com/library/archives/by_design/
(2) http://blog.typekit.com/
Justin,
Thanks for your thoughtful comments. I'm gratified that this experiment is at least leading to some discussion about the reading experience independent of the whole Flash v. HTML/CSS showstopper. (Which is not to say there's not a whole lively debate that still needs to be had about that.)
A few things I'd like to respond to:
I'm glad you pointed out a few features we took pains to develop (namely, typographic control, transitions, and resolution-sensitive layouts) but I wanted to just talk to something you also mentioned which is that we neglected the organization's business needs with the Reader, as well as sharing functionality (which we finally added in recently so you many not have seen it in action -- Facebook and Email).
We originally developed the Reader independent of any one publisher, as you can see in our earlier iteration of the Reader (at http://reader.redub.org), which allowed you to pull in any piece from the NYTimes.com, newyorker.com, and wired.com via URL, parse the content, convert it to XML, and allow you to read it in the Reader environment (example here, a short story by David Foster Wallace in the New Yorker). In this format, we naturally stripped out the ads since we hadn't built an ad server yet, but in the new GOOD example, you can see we're dynamically inserting ads occasionally as you're reading a longer article (this is one of the longer articles where you can see full page ads being shown). We're also showing ads on the end pages of every article as well. (I think this is less painful and interruptive to the reader than the current ad delivery model via HTML documents. What do you think? Good for the reader, good for the publisher, good for the advertiser.)
As Clay Shirky points out: "Long-form journalism is, ironically, one of the easiest things to sell display ads against." He was talking about print, here, but I don't see why this logic can't apply to the screen as well.
These are just some examples of ways publishers can take advantage of "pageviews" while not killing the user experience. As I argued in my presentation, there's a whole raft of squandered pageviews that aren't being seen because the user has already bailed. I wager that if we make the reading environment better, people will read further and longer, and also tolerate display ads the same way we tolerate them in print magazines.
I don't want to imply that we've "solved" anything with the Reader yet, but I think we've succeeding in asking some key questions about online publishing that are being ignored.
Comments