Hacker News new | comments | show | ask | jobs | submit login
Wikipedia in unseen UI (buk.io)
24 points by minsu on Feb 4, 2015 | hide | past | web | favorite | 51 comments



I do not like sites that try to do pagination and page-turning. If I wanted that UX I would get the ePub version of the content.

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?


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.

Thanks.


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/


Very informative link. Thanks.


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?

Thanks. Minsu (Chief Engineer buk.io)


Pagination has the opposite of value.

It lacks affordance.

It means my tools don't work as expected (ie, the scroll button doesn't work)

It means I can't use long screens to view two parts of the same article at once.

One good thing about it is that URLs work well to link to specific sections.


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.


Probably I am not getting the exact point. Can you point me of any example site that implements vertical pagination? Thanks.


Yeah, the Internet Archive e-book reader does it in 1-up layout mode. To change pages you scroll up and down...

most PDF readers work the same way.

I'm personally finding that on mobile, it works better for me than the skeumorphic turn-pages-like-a-book metaphor.


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.


Good point. Can two column view for a wide screen be of any value to you? Thanks.


'Space' key doesn't go to next page.

'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.


Thanks for your taking time.

- "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.


I understand that some hint of usage must be there. Anyway, please use keyboard from your desktop. left/right/pgup/pgdn.


Took me a while to figure out what was going on.


Right. it is pathetic that the service doesn't hint the user what to do. Will improve it.

Thanks.


Does "unseen" mean something special in this context? Or does it simply mean that no one has seen it before?


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.


Very good ^^. will try to make it "visible" instead of obfuscated. Thank you for your feedback. Minsu (minsu@bbdbu.com, Chief Engineer at buk.io)


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....

Poor, poor design, poor, poor UX.


You have the points and appreciate your feedback sincerely. Thank you.


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.


Thanks. Handling cookie may have room for improvement. Definitely will look into that!


Thanks for the feedbacks.

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.

Minsu Chief Engineer buk.io


If you're going to use page up / page down, give me home/end as well.

DO NOT take my left/right keys. I use those to center text on page, not navigate.

If you navigate me off of an edit dialog losing work-in-progress I will hunt you down and pickle your petunias.


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.


I see. Will definitely try to minimize gimmicks for the sake of the eyes. Thanks for your encouragement!


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.

compare: http://en.m.wikipedia.org/wiki/Star_wars


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.


Thanks to all.

Good comments are good, negative comments are better. The service is in early preview so that it has huge room for improvement.

My apologies for your frustrations on several usage cases. I hope to make it better to serve you better in the next releases.

Have a great day.



The link gave me very good information. Will try to comply to the wikipedia standard in the service.


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?


Thanks for encouragement. we hope to release piece by piece to the open source community in the future.


It took me 22 steps to reach Philosophy.

Reference: http://xkcd.com/220/


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.


Great feedbacks. Sincerely appreciate it.


Sure thing. BTW the table of films is really broken on my tablet. It runs of the right of the reader and there is no way to see that content.

Also back button behavior is frustrating and when paging backwards the pages slide in in an unexpected way that breaks the book metaphor


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 ;)

For progress, you might want to consider checking out the internet archive e-book reader as a template. https://www.archive.org/stream/birdbookillustra00reedrich#pa...

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


i like the ui, good experiment. the page turning was impressive




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: