The physical book is something designers get. It’s got a lot going for it, not the least of which is the fact that it’s physical. The boundaries are there, right before us. No guess work is necessary. And so there are a lot of great examples of well designed books. You needn’t look far to uncover a mountain of beautifully typeset and balanced pages.
But what about digital books?
Tablets are in many ways just like physical books—the screen has well defined boundaries and the optimal number of words per line doesn’t suddenly change on the screen. But in other ways, tablets are nothing like physical books—the text can extend in every direction, the type can change size. So how do we reconcile these similarities and differences? Where is the baseline for designers looking to produce beautiful, readable text on a tablet?
This essay looks to address these very questions. This essay also marks the release of an HTML baseline typography library for tablet reading. It’s currently iPad optimized. It’s called Bibliotype and the hope is for it to provide a solid base atop which we can explore. It’s very rudimentary, but rudimentary is a damn fine place to start.
The simple page #section2
Designing a book is largely an exercise in balance: Balance of letterforms and surrounding space in relation to the physicality of a book. In Hochui and Kinross’ Designing Books, they discuss the uniqueness of book symmetry:
The axis of symmetry of the spine is always there; one can certainly work over it, but not deny it. In this respect book typography is essentially different from the typography of single sheets, as in business printing, posters, and so on.
The spine gives book reading a kinetic motion not found in unbound sheets of paper. Forward and backward movement within a book happens because of the spine. And so designers erect scaffolding—text blocks and running heads and other literary accoutrements—around this keystone axis. It is the natural balance point of a spread. The implicitness of this means publishers have largely achieved functional book design right from the beginning: the forty-two line columns of thick type in the Gutenberg bible, even today, are quite a marvel of typographic balance.
If the axis of symmetry for a book is the spine, where is it on an iPad? On one hand, designers can approach tablets as if they were a single sheet of “paper,” letting the physicality of the object define the central axis of symmetry—straight down the middle.
On the other hand, the physicality of these devices doesn’t represent the full potential of content space. The screen becomes a small portal to an infinite content plane, or “infinite canvas,” as so well illustrated by Scott McCloud.
Fig 1. The infinite canvas
Regarding iPad book design, designers are left with a fundamental question they must answer before approaching this device: Do we embrace the physicality of the device—a spineless page with a central axis of symmetry? Or do we embrace the device’s virtual physicality—an invisible spine defined by every edge of the device, signaling the potential of additional content just a swipe away?
Fig 2. Every which way is up
Presently there’s a clear rift in iPad editorial design. There are those applications—iBooks, Kindle, New York Times, Wired, The New Yorker—that attempt to transpose a type of print design built around physical cues to a screen lacking those same cues. They treat the boundaries of the iPad screen like the edges of a printed sheet of paper—sometimes awkwardly forcing content into columns which aren’t optimized for the canvas.
These applications are often characterized by an imposition of arbitrary, non-semantic breaks in content in the name of pagination. Oliver Reichentsien, in his essay iPad: Scroll or Card breaks down use cases for the two models. He provides metrics for determining when to scroll or paginate, and also how the very experience of reading changes between them.
Inconsistent metaphors#section3
Fig 3. The New York Times app: swipe to the left to continue reading this article
Fig 4. The New Yorker app: swipe up to continue reading this article
The inconsistency in which the physical page is mimicked on a tablet leaves readers disoriented, unaware of their position in the context of the greater whole, and unable to easily scan back.
On the other side we have reading applications like Instapaper and Mobile Safari (Mobile Safari being the most fundamental of reading applications on our iDevices) that embrace the boundless nature of the iPad screen. The physical edges don’t bind the text blocks.
Very rarely does one find an application that masterfully merges these two schools. Inkling, however, is one such example of a reading application that straddles the new and old—chunking content in an intuitively predictable and consistent manner within and across chapters, thereby grounding the user via thoughtful navigation. And doing so beautifully, with a confident awareness of the container.
What’s so exciting about all of this is that even now—at the start of 2011!—we’re still refining and iterating on optimal reading solutions to these issues of digital editorial design.
As designers, we need to ask ourselves: Where does our axis of symmetry most rationally lie for the content at hand? From where is the kinetic element of this content born? What’s the rationale behind specific layout and navigation choices for this content and will they be thoughtlessly intuitive to the reader?
We can start with these questions. Then, we can take our content, and—piece by piece—place it back onto this new canvas with considered awareness. These are the first steps to treating the iPad as more than a simple page.
The future and now: books and HTML#section4
In October 2010, I attended the Books in Browsers conference at The Internet Archive. It was a conference with a singular vision: that reading in the “browser” is the future.
I place browser in quotes because, well, browser specific rendering engines are popping up in the darndest of places these days. They can be embedded in iOS apps, eReaders, on desktops, or on mobile or tablet devices. Which is to say: a “book in a browser” does not necessarily imply a book viewed in Internet Explorer (although it most certainly can mean that too).
That conference confirmed what I had long suspected (and had trumpeted privately to anyone who was willing to listen)—that we should be building our books with HTML.
Some of the most popular ebook readers are iBooks and Google Books on the iPad, and the Kindle (both the apps and the device). Google Books and iBooks both use ePub as their format. The Kindle uses an
An ePub is a zipped package of
In fact, I had a chance to chat with the iBooks team. iBooks is just a wrapper for WebKit. We’re already doing books in browsers on a high-level commercial scale.
At Books in Browsers, Bill McCoy gave us a first peek at the ePub3 spec: It’s a convergence of
With WebKit and Mozilla renderers becoming more mature and precise with every release (the latest Mozilla build brings with it discrete ligatures, for example), and with @font-face baked into the ePub3 spec (as a requirement), it’s not hard to imagine ePub3 becoming as robust and nuanced as InDesign for digital book layouts.
With a little more imagination, you can jump one step further: With the inclusion of HTML5, CSS3, and JavaScript in ePub, plus smart rendering engines like WebKit powering our e-readers, iOS and Android style apps for interactive digital books may no longer be necessary. Everything—even the tough interactive stuff—may be possible within the ePub itself. This would have the added benefit of simplifying the current bifurcation of digital book formats (even complex magazines layouts would be possible). It would also help open points of sale: interactive books wouldn’t necessarily have to funnel through an app store.
Regardless of where we see things in a few years, the reality right now is that we (especially those of you reading A List Apart) know how versatile
It’s also worth noting that there is now a generation of designer for whom working with HTML and CSS is more intuitive and quicker for design iterations than using specialized software like InDesign. This is the generation of designers that will be most capable of bringing the best of print aesthetics to the web with nuance, balance, and mastery of implementation.
Fig 5. Tablet typography. A long form reading HTML library.
Bibliotype: a template#section5
We need a starting point. We know
I worked with the wonderful folks at Enhanced Editions in the summer of 2010, helping them design and think about long-form reading on the iPad. I’ve also had the humble pleasure of working with the iPad publisher (and I do see them as a publisher, albeit a new kind of publisher), Flipboard, since the fall of 2010. This template and some of the ideas I’m presenting here are a product of the thinking and design work born from those collaborations. Bibliotype wouldn’t exist without their support and the opportunity to work together.
Point your iPads (or browsers) here for a demo.
The most important point to consider in tablet editorial design is that tablets are some of the first digital screens to be engaged at a variety of distances. Until now, a desktop screen was always a few feet away from one’s face. Or, with smart phones, at arms length. No longer with tablets.
I break tablet reading distances into three main categories—Bed, Knee, and Breakfast—and define the categories by generic use case:
- Bed (Close to face): Reading a novel on your stomach, lying in bed with the iPad propped up on a pillow.
- Knee (Medium distance from face): Sitting on the couch or perhaps the Eurostar on your way to Paris, the iPad on your knee, catching up on Instapaper.
- Breakfast (Far from face): The iPad, propped up by the Apple case at a comfortable angle, behind your breakfast coffee and bagel, allowing for handsfree news reading as you wipe cream cheese from the corner of your mouth.
So: distances near, medium, and far.
I believe all serious tablet reading software should typographically account for these three use cases. Accordingly, I’ve built Bibliotype to do just that.
Fig 6. Bed, Knee, and Breakfast in portrait mode
(An aside: when I showed this to one friend, his first interpretation was Bed, Knee, and Breakfast as definitions for types of content. The content you read in bed isn’t the same content you read on your knee or over breakfast. Very true.)
Furthermore, these three use cases need to be treated differently depending on orientation. This means we have to define six typographic styles: margins, line lengths, and line-heights do not seamlessly transpose from one orientation to the other.
Our final base template has the following qualities:
- CSS media queries to detect device orientation,
- rules for both serif and sans-serif fonts (using Georgia and Helvetica),
- hyphenation via Hyphenation.js,
- font-size, line-height, margins (and, implicitly, line-length) defined for three tablet reading categories in both orientations,
- ability to toggle both ragged right and justified text,
- Settings for low and high contrast backgrounds, and
- turning on and off a grid to see body and title block placement
- footnote styles
The Structure#section6
These templates are based off the most fundamental approaches to the iPad canvas. We define the axis down the middle of the screen and build our text blocks as centered with even margins to the sides. Even though these templates are basic, they should shave hours of first-movement pain from further explorations and experiments.
The content components are:
- running head
- title block
- intro paragraph
- chapter text (composed of several paragraphs)
- final paragraph
- fleuron
- footnotes
- running footer
The underlying goal as designer is to achieve comfortable readability in all sizes for each orientation. I started with what felt like the most agreeable font size for each reading category. I then set the line-length for that text size at whatever length allowed for approximately 12-15 words per line. With font size and line-length defined, I built up the leading until the text blocks felt comfortably whole.
The basic compositional goal is to “hang” our text blocks within the frame of the iPad. As with many things design, this is an exercise in the balance of mathematical proportions and gut intuition. Depending on the font-size, some title-blocks want to sit higher or lower in the frame. I like to imagine the title block as being the nail onto which you hook a string holding up the body text.
To help find the right spot into which this nail should be driven, I created simple grids for the two orientations. This lets us quickly see where elements are falling within the canvas’ mathematical balance points.
Fig 7. In landscape mode with the grid turned on
The template provided here is also meant to be a quick environment for debugging long form tablet typography. You can test hyphenation, assess grid position, play with typographic variables, and see those results quickly as you edit the HTML.
Fig 8. In landscape mode with the menu invoked
This is all very simple. Book design isn’t a black art—like many things it’s a matter of deliberately considering micro-nuance in the context of a greater whole. We add each piece slowly and thoughtfully, punctuating decisions with coffee breaks, whiskey, and neighborhood walks.
The iteration of Bibliotype released with this article is by no means hyper-exhaustive, but it is a fine start. I can read that chapter of Flatland at those three sizes, in those three states (bed, knee, and breakfast) more comfortably than I can with most other available iPad eReading software. Yes, the bar really is that low!
We are, of course, ignoring the whole “card” vs. “scroll” debate. Whether content scrolls (like traditional web pages) or treats the canvas of the iPad like a well-defined sheet—breaking the content into swipeable cards—is both a technical and editorial matter. The margins, line lengths, font sizes, running headers, and footers don’t change (much) between cards or scrolling. They are defined by horizontal space. And horizontal space stays the same in either context.
Using the templates#section7
Bibliotype is released under the MIT License. So nobody owns it. Meaning, you can use it as a base for anything—commercial or free—that you want to build. The only stipulation being that if you build off of it, keep the copyright notice (http://craigmod.com) in your application or book’s copyright/about page.
Bibliotype is hosted on github. You can grab a copy here:
https://github.com/cmod/bibliotype
There are an endless number of use cases and devices for which Bibliotype can be adopted and I’m happy to open it up for the community to extend and build upon together. (For example: pagination via Joseph Pearson’s great Monocle ePub Javascript library might be a fun project with which to mash Bibliotype’s styles.)
If you’re testing new fonts—looking for the right balance of size, leading, and margins—I might suggest turning on two JavaScript functions which are commented-out by default: swipe right to reload the page, and swipe left to show the grid.
On a desktop we have tools like Firebug that allow rapid visualization of changes to
Still looking#section8
iPad reading typography is defined by two things: The visible portion of the canvas (is it occluded by any images, columns, menus, or chrome?), and the way someone is reading (bed, knee, or breakfast?). The canvas can be thought of as extending in any number of directions, as having any number of axes, but we’ll forever be bound by what the reader can see, and that space defines how—on the most basic level—to format the text for a comfortable reading experience.
Take Bibliotype and play. Transpose the axes of symmetry, shift text blocks around, paginate, imagine content extending in all directions with small visual cues to guide the reader. How will the typography keep up with these scenarios? What modifications will a base like Bibliotype require as we explore this space? And most importantly, what feels most natural, most effortless for the reader?
I look forward to seeing where we go from here. Knowing wherever it is, the text will be comfortable to read, and that HTML is at the heart of it all.
An interesting article, and a good looking framework. One nit, though; near the top of the master CSS file I see:
bq. font-size: 62.5%; /* — Sets 1em to equal 10px — */
No, no it doesn’t; it means that 1em might be 10px on some browsers and configurations, but might be all kinds of other things, but whatever size it is, it will almost certainly be too damn small.
This bit of CSS is particularly pointless here as the CSS file then goes on to define the font sizes directly in pixels (which is the correct thing to do, if you want specific pixel sizes); so it probably has no effect, but if it does have any effect, it will be a negative one (because it is based on the false premise that 62.5%=10px).
Setting the font size to 62.5% is a kind of CSS cargo cult, included due to a mystical belief that it has some useful effect, without any understanding. I hope that 2011 can be the year in which we finally break free from its grip.
“Or, with smart phones, at arms length.”
This is not true. And the perception that mobiles are just tiny desktops—the whole “tiny glowing rectangles” understanding—is flawed and explains why lots of mobile web design is badly flawed.
Mobiles are also contextually used. Video tends to draw people in, and they pull it close enough to their head to simulate TV viewing angles, as I exemplified here:
http://www.littlespringsdesign.com/blog/2010/Mar/video-on-the-second-third-and-fourth-screen/
This was before anyone normal had an iPad, hence it’s not included.
And bed is a good tablet context, because it’s been a good mobile use context for years. Analytics for a lot of sites (especially social ones, like Facebook) see a slow drop off in use as people hit bedtime in their timezone. Then there’s another peak as everyone checks in one last time before they go to sleep.
This is a different distance, often in the dark, and probably is different content being checked. You can design around that.
I have be working this version of the Tale of Genji which is as readable on my Droid as my desktop and my iPad.
http://www.personal.psu.edu/jxm22/genji/
(I still have some corrections to make in the last 30 chapters.)
What would you change to make it more useful?
Thanks for your work and attention to these details! Looking at the demo, I was immediately struck by the lack of orientation once I got into the heart of the text. On a customary page, I am always *positioned* somewhere, like one side, bottom, etc. This is critically important in going back to a remembered passage, or resuming reading after taking a drink of tea. In your browsing system, no landmarks provide this help, since the text is continuously scrollable.
I guess I would have two suggestions. One is to supplement the paragraph breaks with blank lines. That might lessen the sensation of being adrift in a sea of text. This method is common on web sites now. Second would be to provide some kind of graphical landmarking system, like colors that darken as one moves through an article or chapter, or small symbols, etc. Some anchor for the reader to find their place other than counting page numbers, or recognizing the actual text they were reading.
I know you’re handing this off as a template for others to do with as they please, so might not be interested in this, but I found it non-intuitive to determine which buttons were the currently selected ones in the menu. I don’t think the darkened buttons have the effect you desired, which I think was to represent a pressed-in button. In contrast, the white buttons, which are actually my options for changing the current display, jump out at me as “the ones currently in use.”
This is really exciting. Since that article on hyphenation and justification a while back, I had been thinking that hyphenator.js might be a tool best used for mobile devices. That article got a lot of flack for promoting hyphenation and justification without a purpose other than aesthetics. It seemed to me that if hyphenated and/or justified text should be used only when space is at a premium, unlike on a desktop browser, then mobile devices are the perfect use for it. I was looking into the combination of those practices with media queries, so that a regular article on your computer becomes something best suited to a tablet or phone.
It seems like Bibliotype might be a great tool for this, I can’t wait to check it out.
@voyoudesoeuvre —
bq. font-size: 62.5%; /* — Sets 1em to equal 10px — */
bq. No, no it doesn’t; it means that 1em might be 10px on some browsers and configurations, but might be all kinds of other things, but whatever size it is, it will almost certainly be too damn small.
bq. This bit of CSS is particularly pointless here as the CSS file then goes on to define the font sizes directly in pixels (which is the correct thing to do, if you want specific pixel sizes); so it probably has no effect, but if it does have any effect, it will be a negative one (because it is based on the false premise that 62.5%=10px).
bq. Setting the font size to 62.5% is a kind of CSS cargo cult, included due to a mystical belief that it has some useful effect, without any understanding. I hope that 2011 can be the year in which we finally break free from its grip.
Interesting. Thanks for bringing this up, as it’s indeed a habit / relic of my CSS reset rules from eons ago.
Actually, 95% of the font sizes in the CSS are set in ems specifically for the sake of relativity. I mainly use px for a couple of specific elements whose size I don’t want to change.
If you want to submit an updated, working CSS file for the repository I’d be more than happy to take a peek and incorporate the changes!
Thanks,
Craig
@shoobe01
I said: “Or, with smart phones, at arms length.”
And you responded:
bq. This is not true. And the perception that mobiles are just tiny desktops—the whole “tiny glowing rectangles” understanding—is flawed and explains why lots of mobile web design is badly flawed. Mobiles are also contextually used. Video tends to draw people in, and they pull it close enough to their head to simulate TV viewing angles, as I exemplified here:
Great points. Although, video and text are very different beasts. Because the screen is so small on mobile devices there tends to be only *one* highly optimized reading size. Too small and the text is microscopic, too large and you only fit a couple words per line in a best case scenario. Not very readable. Certainly not for longform texts.
Considering that (optimal mobile device text size being fixed within a relatively small range), the optimal reading distance, too, is fixed within a relatively small range.
@Jerrold Maddox:
bq. I have be working this version of the Tale of Genji which is as readable on my Droid as my desktop and my iPad.
http://www.personal.psu.edu/jxm22/genji/
(I still have some corrections to make in the last 30 chapters.)
What would you change to make it more useful?
Looks great! I am a huge proponent of stripped down simplicity.
I don’t think Bibliotype is that complicated though. It’s attempting to achieve the most base level of reading optimization — three type sizes for the three general use cases, as applied to two orientations. You can’t get (much) simpler than that.
What you have with your Genji text is an instantiation of one of those text sizes for one orientation. And arguably for one device (it’s readable on all devices but perhaps feels most optimized for one more than the others? (I haven’t tested it so I can’t say.)).
With a few more CSS rules, Bibliotype could be extended to iPhones / Android and thus, a text, marked up as you have, combined with a pretty simple CSS file and some very simple Javascript would allow for a more optimized reading experience on a number of platforms.
It’s only a very small amount of complication (and almost no markup change) above what you present, but, I’d argue, brings with it tremendous benefit to the reader.
Thanks,
Craig
@jblaine:
bq. I know you’re handing this off as a template for others to do with as they please, so might not be interested in this, but I found it non-intuitive to determine which buttons were the currently selected ones in the menu. I don’t think the darkened buttons have the effect you desired, which I think was to represent a pressed-in button. In contrast, the white buttons, which are actually my options for changing the current display, jump out at me as “the ones currently in use.”
This is a great point. After staring at things for a certain time, you lose the ability to see with fresh eyes.
I’ve updated and pushed the CSS changes.
Try loading that demo up on an iPhone or other small screen device and it’s a mess. Text is jammed up against the edges with no padding, and font size is very small. The menu “tab” blocks content.
Maybe this is a great ipad design (I’ve never even seen one so I don’t know) but wouldn’t a better goal be to create a design that looks good on any device? Or at least a good chunk of them.
Perhaps I need to become a wealthy hipster who takes trains to Europe with my iPad before I can really appreciate this? 😉
I found some bugs with the demo menu. I click menu then clicked the hyphenation toggle. then closed the menu, and opened it again. When I click Georgia the hyphenation toggle button changes. Was able to repeat it many times. Using Chrome. Could make a video if you need.
But I’m a bit confused. This is a long-form text reader, but you only have one chapter in the demo? Why not show how to navigate around in the larger work?
Also find scrolling to be annoying, because it’s hard find your place again everything you try and scroll a full-page forward. I’d prefer some next page button, which shows the last 2 or 3 sentences from the previous page at the top.
>The inconsistency in which the physical page is mimicked on a tablet leaves readers disoriented, unaware of their position in the context of the greater whole, and unable to easily scan back.
really? Usually you can just swipe to go back. Page numbers, or bullets like the NYT example, let you know your relative position. Seems to be making an issue out of a non-issue. Most readers want a rough idea of the entire length. When they swipe I think they understand they are one page further than the previous page and one page closer to the end.
Regarding the menu, for “Size” I’d prefer to see “Small, Medium, Large”. ‘Bed’, ‘Knee’ and ‘Breakfast’ are less intuitive and require a much greater cognitive-load to decipher.
Also the terms “Ragged” and “Justified” are maybe unfamiliar to non-designers. Maybe use icons to show the difference like in most word processing apps?
Same thing with FAMILY. Would call it ‘Type-style’ or ‘Font’. Even though Font is not technically correct, it’s more familiar. “FAMILY: GEORGIA” is likely to sound unfamiliar to non-designers.
Finally, for Hyphenation: “TOGGLE”–how about a slider to turn it on/off like iphone. A toggle button is less clear especially when gray is not the disabled color but the selected color(?!) In the article BED and BREAKFAST are both white, so grey is the selected color? but in the App demo it seems the other way around. The menu really needs some work.
The latest ePub proposal is “a convergence of HTML5, CSS3, and ePub”.
Well, why the ePub part? Are browsers not ubiquitous enough?
Having discussed this with people knowledgeable about it, the best I can determine is that ePub is a spec that would have already died were it not for 1) the easy conversion of epub files to HTML for in-browser viewing and 2) DRM.
ePub was conceived when expectations about for-pay content were much higher than they are now. And while the publishers futzed, the web zoomed right past. (As for the DRM – you *can* always require a login and charge money on the web. It does work sometimes.)
And so, ePub has been two steps behind for years.
But there is a consortium dedicated to it – ooh, ahhh – and the meme of “electronics books”; the idea that a special format for books is somehow necessary in light of where web standards are today, resists extinction.
To some extent I get the feeling that ePub is a new twist on the debate about high-culture versus low-culture where “good literature” needs a *dignified format* of it’s very own. None of that lowly web site stuff.
And so, ePub trucks on to prove points that were thought to be relevant 10 years ago.
In other words, I don’t get it.
Yes, like Richard Fink: why ePub?
Also, I would reduce the menu options. Simplicity! The size options are a bit silly. I would never have guessed what they could mean without reading the article first. Justification, hyphenation and font-family are too geeky for most readers. Are readers (non-designers) really interested in changing those? A button that says ‘toggle’? (Don’t make me think!)
When you click in the text on a footnote, you land on the list with all footnotes. I miss a mechanism to return to the text where I left. Footnotes at the bottom of a page are so ‘print’. with a bit of javascript, you could open and close them inline, in the text.
Great article, Craig. And thanks for sharing your framework.
Another interesting aspect of the reading experience on screen is how reading progress is presented to the reader. We recently did a little lab project on this which might be interesting for you:
http://blog.intuitymedialab.eu/2010/12/22/ux-lab-how-can-we-enrich-the-reading-experience-on-a-screen/
It fits quite good to one particular aspect of your article:
bq. Presently there’s a clear rift in iPad editorial design. There are those applications—iBooks, Kindle, New York Times, Wired, The New Yorker—that attempt to transpose a type of print design built around physical cues to a screen lacking those same cues. They treat the boundaries of the iPad screen like the edges of a printed sheet of paper—sometimes awkwardly forcing content into columns which aren’t optimized for the canvas.
Very interesting post. And the framework is very good too!
Have you use it in your projects ? We use PX instead of EM. We will think about changing.
Thank you so much.
I found a bit confusing the layout of the page a bit confusing.
i’m glad people are not just
swallowing this article whole
as “the accepted word”, but
rather challenging every bit…
and i’m glad you’re big enough,
craig, to roll with the punches…
there’s a lot of stuff wrong here
— a lot — so much that i am
not even going to start in on it,
i’ll just hope that your openness
to feedback and your commitment
to thinking about this topic will
— in the long run — steer you
to a much better formulation…
-bowerbird
Love this stuff. It’s funny; we’ve got text-shadow and text-transform practically in the bag while the more foundational aspects of readability are much farther on the experimental side.
Re:why epub– awareness of things like epub3 and projects like hyphenator and bibliotype help to push forward development of the nitty-gritty details in typography like hyphenation, proportional small caps, etc. I have dreams of being able to set keep options and justification/hyphenation options and rely on some kind of browser “text composer”:http://help.adobe.com/en_US/InDesign/6.0/WSa285fff53dea4f8617383751001ea8cb3f-6d97a.html#WSa285fff53dea4f8617383751001ea8cb3f-6d96a
Despite the fact that I do prefer page listing for reading books, I just thought about using Bibliotype for blogs and other online content.
Thus I tried to create a Bibliotype Template for Blogger and “here is a working demo”:http://bibliotype.blogspot.com
I made few changes in your code, but otherwise it works and looks just fine!
Thanks for the article!
I noticed you mention of “Designing Books” by Hochuli and Kinross, and I have to mention you spelled Hochuli wrong. Though your discussion makes a point about designing for a tablet, well, tablets predate the codex, or books with spines. I find your use of references to say, grids as scaffolding and the like charming but a little distracting.
I found this blog on a search to Medialoper with mention of your typeface Bibliotype, I think it’s called, and I find it to be, and I know I am just judging from the one word sample, but it is enough to give me its visual style, rather compressed. The ascenders and descenders are so short. I assume this is to facilitate getting more lines on a page. But if we are to have text on tablets, why can’t they be modeled after some typefaces of elegance such as those of Jan Van Krimpen http://typocurious.com/jan-van-krimpen/ If you visit this page you will find samples of faces with healthy ascenders and descenders, like Van Dijck. Well proportioned typefaces will, I think, help to bring attention to your design as well as perhaps give the new tablets some readability as well as desirability.
This is a step forward in typography for the web (and not just tablets), great to see the nuanced approach this allows. Definitely going to try Bibliotype, and I’m wondering how it’s going to help reading/layout on smartphones too.
Still amazes me what people create for free 🙂
“Bibliotype: a template” part little comfused to my mind. but article have so much detail informations, thank you so much…
This was a really helpful article. I am a graphic design student and I am currently taking a web design class trying to find different ways to design an interactive digital book. While it may lack the experience of flipping the pages, folding a page down, it definitely has the potential to mimic such tangible experience.
However, I definitely agree with you the fact that by mimicking the book sometime only leaves readers disoriented and may limit the possibility of enhancing the reading experience that can only be done digitally. Hence we as designers must find ways in which the layout of the book fits accordingly to the tool (computer screen or ipad) and optimize reading experience of the user.
The beauty of digital book is that its flexible. Font sizes, margins, contrast backgrounds, the way the text is placed can be personalized according to user’s preference. I think its a great solution to have the reading experience change according to the place and time user is at (bed, knee or breakfast) It definitely humanizes the ipod or electronics and brings intimacy in a way different from a regular book.
I read every word, twice. Thanks for this, its good to see cogent effort for the true word, and more is needed for sure. For numerous reasons i have chosen a landscape swipe tactic ( video playback is part of what i do in there ) and have found the “baked-in” graphics as text the way to get it done… but i would love to escape that. ( a lot or “Magazine” Native ipad apps are in fact just a pile of PNG and i get lost in that easily. )
Its important to know where you are in any kind of Publishing, visual, text , multimedia or otherwise. After just getting http://ctnhd.com/amc/twd/ipad up and ready for a TV show promo, i am wishing that all these things you point out were available and ready standard frameworks, so i could do the showmanship without the CSS3 hacking and trial-error cycles being the prevalent workflow. I will follow this and possibly contribute when i have a solution that doesnt feel like a hack-to-get-done framework.
…and not getting any easier. For small business owners like me, who must do a lot of the work ourselves, we hunger for a simple, robust solution that doesn’t require a $10,000 programming project.
– Tim
“San Diego County In-Home Caregivers”:http://www.trustworthycare.com/services-for-the-elderly-in-san-diego-county/caregivers-in-san-diego-county/
“We add each piece slowly and thoughtfully, punctuating decisions with coffee breaks, whiskey, and neighborhood walks.”
That is one of the best quotes on art I have ever read.