Hey everyone, I'm Michael, a product engineer at Hyperink. Over the past month or so, I've been developing a rich, social reading experience for our content, freeing us from the stranglehold of MOBI and EPUB file formats. Today, Jeff Atwood generously granted us permission to release half of his book completely free on this Crowd Reader (paid customers get to see all of it there).
The problem: paperback/print always wins over digital and arguably e-ink.
Our solution: make reading a unique and asynchronously social experience.
I've love to get some beta feedback and hopefully some suggestions for how to improve the UI/UX. Thanks, and happy reading!
UPDATE: forgot to mention. This app is 100% JavaScript with Node and my own JS makeshift library on the front. MongoDB for database. Madness.
Scrolling is severely buggy in Chrome (20.0.1132.57 on OS X) and partially buggy in Firefox (13.0). I did some screen captures.
#1 (https://www.dropbox.com/s/bczmu8kjfhn6ymr/bug1.mov): Scrolling is actually faster in the upward direction than the downward direction. In this video, I continuously move my fingers on my trackpad up 1cm and down 2cm. You would expect the same movement to scroll equivalent distances, but it does not. In fact, you will see that sometimes it stutters or will not scroll at all. (There is nothing wrong with my trackpad, and the problem only affects your site.) This problem affects both Chrome and Firefox.
#2 (https://www.dropbox.com/s/x9zzd298v85atf9/bug2.mov): The viewport is often mysteriously constrained and refuses to scroll any further, even though there is more text. In this video, I opened a fresh window, immediately clicked on one of the chapters, and tried to scroll downards. You'll see me struggle for a bit, then scroll to the previous chapter and then back to the original chapter. Only after doing this am I able to scroll downwards. Seems to affect Chrome only.
Looks promising aside from these rather severe issues.
I can confirm this. My scroll wheel is very easy to move one increment at a time, and repeatedly moving down one then up one increment results in text moving upwards about 4 lines per cycle. When testing on this site: http://www.javascriptkit.com/javatutors/onmousewheel.shtml I can confirm that scrolling up and down provide a delta of 1200 and -1200 respectively, the way it's being handled on your app must not be even.
I'm a little baffled by this report, but I don't at all suspect it's inaccurate. I'm on the same version of Chrome on OSX on a macbook air (where I developed the custom scrollbar). Programmatically, I'm using the "scroll wheel"'s delta increment to determine the distance to scroll--the same amount in both directions. If anyone with relevant experience developing JS interaction with the scroll wheel has any hints or related knowledge, I'd love to hear it.
Thanks for the thorough feedback and videos. Looking forward to making the scroll bar perfect!
You guys really did create a wonderful UX for a very separate market segment. Admittedly, we did draw some conceptual inspiration from your reader. In my defense, I will say that UX/UI is very constrained by a set number of factors which make "sidebars" necessary/obvious/essential and the organization of them preferable over other organization possibilities (TOC on left, misc on right). I'll admit that you executed this arrangement visually much better than I did, in my attempt not to scalp.
I'm a big fan of Inkling, and you guys make me wish I was still in school so I could use your reader. Major props.
The UX is so constrained that you had no choice other than to straight up copy: a) a control to hide the table of contents with a semi-transparent strip hover; b) a table of contents with a near-identical layout; c) a "next page" bumper with opacity-on-hover; d) an annotation stream in a third, right-handed column; d) a cute octopus mascot; etc. etc.
That's not to mention the store.
I mean...imitation may be the sincerest form of flattery, but I draw a line at copying Otto the Octopus.
The UX is so constrained that you had no choice other than to straight up copy: a) a control to hide the table of contents with a semi-transparent strip hover; b) a table of contents with a near-identical layout; c) a "next page" bumper with opacity-on-hover; d) an annotation stream in a third, right-handed column; d) a cute octopus mascot; etc. etc.
That's not to mention the store.
I mean...imitation may be the sincerest form of flattery, but I draw a line at copying Inky the Octopus.
You should really be upset they had no interest in stealing any of your content, like those great articles about France (blocked behind a login). Value is in content, not some arbitrary public js + html. I draw the line on drawing porky the platypus, the other hidden inkling mascot which doesn't appear on inkling
Hi Michael. Congratulations on building a very good product. It's probably the best web-based e-reader I've seen, apart from the 'social' bits. No doubt the great majority of your users like them, but they're a useless annoyance to me. If you could add an option in the user preferences to suppress all the social stuff, you'd have me as a user right away.
A small note: the scrolling code seems to break mouse-gesture history navigation in Chrome 20.0.1132.57 on OS X - my attempt to go back just scrolled the page up...
The scroll is different from OS Scroll. It is much slower, moving at a pixel per scroll wheel event. Also [space] doesn't do page down. Running Chromium 18.0.1025.168 (Developer Build 134367 Linux) Ubuntu 12.04, with smooth scrolling enabled (in about:flags )
Good call, and easy enough. Added spacebar support live, and the scroll should be twice as fast as previous. Let me know if that's more livable. Thanks!
Looks good. The "heart" on paragraphs is cool -- now just make it so you can sort by hearts for a quick view of highlights. You could then jump to a selected paragraph in the correct ordering, if you want to read more of the context.
I second this. Being able to pick out the most hearted segments across an entire chapter, even the entire book, would make it easy to skim chapters. I could look at the top snippets, see if they're compelling, and then commit to reading an entire chapter based on that impression.
I have grown used to being able to click in the scrollbar background area to page up or down, which I tried to do when I determined the mouse wheel scroll down was going too slow.
And when the scroll indicator widget is over the dark part of the first graphic in the introduction, it is lost. Since there are no up and down arrow keys at the ends of the vertical scrollbar, if I did not know where the position indicator was, I am not sure I would be able to find it.
If it helps, the differential in the scrolling direction to click of the scroll wheel is two to one. Scrolling up one click covers the same territory as scrolling down two clicks.
And when I toggle the left pane open and closed, the text apparently reformats for the difference in widths, leaving me to have to scroll back up or further down to find where I was last reading. Any way to track current line and scroll to that point when the left pane is toggled on or off?
That's a very good point. I've long considered tracking last-loaded position and using local storage to reload the last-unloaded scrollTop position. I could simply track that on the sidebar collapse to maintain it. Good feedback! Thank you!
The most overrated writer in the history computing. It always made me scratch my head why Joel Spolsky, who, say what you want, but I think is a very legitimate writer said so many praises for Atwood's writing. But Spolsky also said Yegge wrote beautifully, which I cannot fathom; it is definitely a different standard for writing than the rest of the world. There's more to writing than using correct grammar, but in the standard of programming blog writing I guess that's amazing. :) Really, I'd rather have wonky grammar and good content on programming blogs than just a series of pictures and backlinks with ideas that make no sense.
That being said, I was not familiar with hyperink at all but it is actually a very pleasant reading experience (it was just the actual words that upset/annoyed me :) )
The reading experience is a bit cumbersome on the iPad, in portrait mode. I'd kill the social sidebar if in iPad mode...I'm not likely to use the social bar when at my iPad, but I do judge the overall reading experience based on how effortless it is on the iPad, or any other tablet
Franzus, isn't this statement a little arbitrary? While I wouldn't claim to be a huge visual basic fan, I think (at least from my experience reading Jeff's book) there's a lot more one can get out of this resource than insight into programming languages.
For instance, Jeff has a great section on protecting users' data, writing test cases, and building community (like that of stackexchange).
I wouldn't be so arrogant as to presume I know what information you're interested in learning, I just wonder if not reading a resource by a smart programmer due to a programming language bias might actually work to your disadvantage?
The problem: paperback/print always wins over digital and arguably e-ink. Our solution: make reading a unique and asynchronously social experience.
I've love to get some beta feedback and hopefully some suggestions for how to improve the UI/UX. Thanks, and happy reading!
UPDATE: forgot to mention. This app is 100% JavaScript with Node and my own JS makeshift library on the front. MongoDB for database. Madness.