Your point is very helpful. The scroll mode support is in the next update bucket list and hope that will help you copy the content properly.
For bookmarking purpose, your can just bookmark the page you're looking at and then visiting it later will bring you the same (or almost same depending on device side) page. Hope that is of any value to you.
All of these Wikipedia browsers miss a very important point: A web page is not a book. Wikipedia "pages" already suffer from skeuomorphism: the presentation of data reflects offline materials to the point where the online functionality is compromised. "Pages", "articles", "page turning", lists of "references" are not well-suited for the web. More about Wikipedia's UX issues here: http://newslines.org/blog/wikipedias-13-deadly-sins/
Take a look at Wikiwand - http://www.wikiwand.com/. IMO a better implementation of the same concept. Not to discourage you as I think there is still plenty of room to do more with this, especially when you start thinking about expanding this beyond Wikipedia.
But some of the basics you have in place right now like the pagination simply do not work.
Wow, wikiwand is impressive. I need to learn from this site. :) By the way, do you think pagination doesn't have any value or the current implementation of buk.io doesn't do pagination as expected?
Strangely, I don't necessarily mind pagination on mobile devices. I think it's the form factor.
However, I've been doing some testing of different reading ideas and I've found that I like a long vertical scroll, broken up into screen-high pages, even better. Finish a page? just scroll down to the next one.
For some reason it feels more like reading a book to me, and I think it's because on a physical book, I don't turn the page when I finish a page, I get my finger under the page early and start to prepare to turn it quickly, slightly revealing the next page and providing continuous reading as quickly as possible.
With the paged-vertical scroll, I find that as I near the end of one page, I'll start scrolling early and put that bottom of that page at the top of the screen so I can jump to the next page without a break.
This seems to work better than just one long vertical scroll (without pages), and I think it's because I subconsciously note the page breaks and they give me a moment to pause per unit of text.
I've spent an inordinate amount of time thinking about this problem lately and haven't found a good answer. The need for pagination seems to stem from:
1. The desire to limit the size of HTTP responses.
2. The lack of the ability to notify a browser that you're done loading/rendering async content.
Aside from page-flip-metaphor apps like the one posted here, it doesn't seem like a desirable UX pattern.
Have there been recent (or not so recent) developments in either of those problem areas?
To be clear, I'm not generally a fan of infinite scrolling either.
I'm not sure it is possible to talk about this in general terms - the specific use-case needs to be considered. In the case of Wikipedia, I think that the page size of a typical Wikipedia page isn't problematic.
I suspect it's actually pretty rare that the HTTP response size for text documents is big enough to be a problem. 1M of text is pretty large in terms of text, and most pages would have more than that in embedded images.
'ctrl-pgup'/'ctrl-pgdown' - when switching browser tab the content page also switches.
scrollwheel doesn't advance to next page
can't select text for copy / paste.
on a small resolution the right hand side doesn't scroll with main content.
middle click doesn't open a new tab (if the mouse doesn't have middle button, the scroll wheel often is clickable and performs the middle click). In same vein, ctrl-click doesn't work (I think in IE world, shift-click also is used to open in a new window).
search for text is broken. For example: on the opened up starwars page I want to search for 'Boba Fett'. I press ctrl-f, type in 'Boba fett', and I get nothing.
I do miss the buttons for: edit/view history/view discussion/other languages. I don't need new functionality behind the buttons, just a way to see them, they can be linking to the real wikipedia for that.
- "Space": next page - very good point. I missed that.
- scrollwheel for page navigation - will look into it
- text selection : "scroll mode" is being implemented to properly support text
- right hand side doesn't scroll(?) : will take a look. Do you mean TOC doesn't scroll in small screen devices?
- ctrl-click or middle click on a link : very good point which I won't be able to think about without your feedback
- search for text is broken : right. no way to support this browser functionality at this time.
- edit/view history/copryright notice and more will go to the first page of an article. I failed in complying to the wikipedia standard and this got my attention. Also real link to the wikipedia will be provided.
Thank you very much!
Minsu minsu@bbdbu.com please contact me for any discussion.
This is definitely one of the cleaner implementations I've seen of this idea, but why not allow for traditional (vertical) scrolling? The swipe method is unnatural on a laptop browser.
Not only that. It's pretty much impossible to see where you are in the text. If one is going to get rid of scrolling, it should be replaced by something better. I just find this to be unusable.
Am I alone in this, or are there actual arguments why paging is better than scrolling?
Page information on the bottom may help? Good point. Paging has its pros and cons. One feature that is not obvious is to bookmark or share the URL that has the location within the content. (Though anchor may do the similar thing).
The URL has all the location information if that is of any value. Thanks.
It looks to me as if "unseen" refers to the UI being "invisible" or "unobtrusive" to the user. One might be tempted to use words loke "obscured" or "obfuscated" if one was less charitable.
Ugh.. I really consider putting every swipe-page as its own history in back-forward to be gruesomely annoying, especially on mobile. Yeah, I saw the point and played with it after five swipes, but getting out of the site shouldn't be a bad UX either.
Good point. Will consider putting URL history per article instead of pages. Did you try it on Desktop with keyboards (left/right)? Though it works on mobile devices, I thought the first target is to be desktops with keyboard. Hope to hear more from you on usability. Thanks (minsu@bbdbu.com, Chief Engineer at buk.io)
In addition to breaking pagination as mentioned in other comments, this site breaks "open in new tab" functionality, whether by ctrl-click/cmd-click or by "right click, open in new tab".
When reading Wikipedia to learn quickly about something, I frequently "open in new tab" a raft of pages so that I can continue with the main subject then quickly go to the additional information of interest.
On this site, cmd-click simply acts as click (open target in current tab), while "right click open in new tab" just opens a blank page - as I found out to my irritation upon closing the original tab....
This hard-crashed my browser (Firefox 35 Window 7). Not the "script is taking a long time" or even the "(Not responding)", but some obscure little Windows fail intervention box that I can't say I've ever seen before.
If I open it in Chrome (where I have cookies enabled), then it's about the experience others describe.
I keep thinking that I've hit the bottom of how bad the cookies-blocked experience can be on a web site, but this is actually a new low.
With all that said, I think alternate front-ends to Wikipedia are a great idea, and I happen to be working on one right now, notwithstanding that I am here.
The service is in its early preview state. The "Scroll" mode will be there soon to enable users to copy & paste the content properly.
I understand that it is a bit cumbersome to use from phone side devices. Please try the service from your desktop and use keyboards "left/right/pgdn/pgup".
All your feedbacks are great and hope that I can pull the level of the service to higher and higher.
Please contact me at minsu@bbdbu.com if you need to further discuss anything.
I loved the horizontal scrolling idea! I hate to read in desktop just because of the vertical layout of posts. It is very difficult on the eye (like a non-stop panning shot in a film). Give us a more enriched experience ad you are there! Great job.
That was horrible. Aside from the terrible pagination mentioned elsewhere, the site leaves out the all important infobox which includes the very import picture of the star wars logo.
Mobile wikipedia looks quite nice on desktop and is much more out-of-your-way than this.
Right "infobox" is removed from the content window even for the desktop size screens for now. The mobile wikipedia also hides it for real mobile devices (please try that) but not for big screens.
The plan was to add "infobox" table to the TOC as a tab instead of fiddling the cumbersome table in small devices. (under construction)
or We can put it back to big screens content window. What do you think?
What is the point? Is the original ui so poor?
The paging is annoying. It makes the graph almost unreadable since the titles are on one page and the graph is multiple pages long. Plus it is clipped.
Not sure why there is a magnifying glass in the bottom left.
Increasing the text size past 150% hangs Firefox (on OS X).
Specifically, the cursor turned into a beach ball and the whole browser became unresponsive and stayed that way until I killed Firefox about a minute later.
Very nice. For long form reading, I believe paging is a more fluid reading experience than scrolling because the location of the next line is consistent. Any chance of open sourcing the code?
I couldn't scroll down, so I clicked randomly. Pages turned after a short delay and on occasion never so it took me
a) a while to figure out the relationship between clicks and things happening on the screen
b) no idea how to go forward or back, it seemed to be occurring essentially at random until I remembered some mobile apps that put page turn forward back onto the left and right halves of the screen, until I read the comments in this post, it never occurred to me to use the keyboard since that's unlike the rest of the web.
the lack of scrolling was problematic when pagination is poor, I see just the header of the Film table, but it cuts off after that, until I figured out how page turning worked I thought scrolling was broken
I can't tell if this is intended for mobile or desktop, but comments below seem to indicate it's for desktop. If so, it's not very good for it. The regular WP page is a far better usability experience. If it's for mobile (I haven't tested it), it might be "ok". But some recent experience I'd had with readers has made me think that a continuous scroll makes for a better reading experience on tablets/phones than page flipping.
I think it's trying to mimic the use-flow of the internet archive e-book reader, but without separate pages you can't figure out how to turn them, and without a single-page vertical scroll mode it's equally confusing.
When the pages turn, the next page does a weird little slide in also, I guess this is supposed to look like a page flattening out in a book or something, but there's no 3d effect to indicate this and instead it looks like my browser is struggling to figure out where to position the content on the page...it looks broken-ish, or as the kids say "janky".
Hitting page up/down makes my browser do something really crazy for a minute (fold proteins, factor primes or something), I suspect the page is prefetching content, it smoothed out after the initial whatever it was doing. I still have no idea where in the article it goes.
Somehow this is confusing both single page viewing with two-page layup user interface.
It also somehow manages to show less information while taking up more screenspace (no infobox and instead a table of contents).
It's almost like somebody went through and wherever there was a choice of worse or better, they always chose the worse way to do things.
Some people say that the difference between Star Trek:TNG and the newer Battle Star Galactica series is that when faced with the same ethical dilemma, Adama always chose the opposite of what Picard would choose. This is kind of like the BSG of text readers.
Don't take it too harshly, BSG was still a great series. With a bit of work this could be a great mobile interface for WP.
Edit:
Yeah, much better on my tablet. If the desktop experience is a 3/10 mobile is a 6.
I see. The table thing is a bit hard to solve at this moment but may try to solve by applying a bit of responsive table stylings.
"Back Button" is also a bit tricky. ^^ As the other commenter said, it may be better to record URLS per articles instead of page unit. Will that be more natural? Thank you again.
Yeah, I think back button should be tied to the article. As an experiment, I flipped through a half dozen pages, then back a couple, then forward another half dozen, then back a few, then forward a few, etc. like I was doing research and correlating information from different part of the article...escaping the article was pretty exhausting after all that ;)
The progress bar on the bottom is amazing. Chapters (sections) in a text are noted with, you can click anywhere on the progress bar to "fast-forward" and as you turn pages, it progresses, giving you a sense of where you are in the text (which would help with your page-up/down behavior).
They also offer several ways of turning pages, click (to turn left, right), left-right GUI buttons and left-right on the keyboard (page-up/down turns only one page).
More importantly, they offer 1-up with a vertical scroll, which I'm finding as a metaphor I love on mobile, which lets you drag to scroll (and the left-right GUI buttons and progress bar all still work), though they change the keyboard controls to up-down to scroll.
I wish I could find the example, but I can also tell you that their reader handles different widths of pages. So in 1-up mode, most pages can be book-paged size, but if there's an extra-wide page (like a poster or a fold-out) it will expand to accommodate that...which could be a useful metaphor for handling wide tables.
Just some ideas.
edit
I noticed mobile also changes pages on tap, but the behavior wasn't consistent. I had to tap 6 or 7 times to get it to work if it worked at all.
Great! Thanks. This service needs huge room for improvement and feedbacks like these are helpful. The archive site is very useful, too. Have a good day. Minsu minsu@bbdbu.com
The UI is not "unseen" either: there are grey divider lines between UI components, and the expected interaction is not even hinted at.
How do I copy a paragraph that spans page boundaries? How do I bookmark a section of interest in a longer article?