Force-directed graphs (as in the WikiWeb "node view") tend to fascinate but then frustrate me.
They seem to show so much, in the relative placement/distances/angles of nodes and edges. But when you get right down to it, almost all that eye-catching detail is random noise. The same "spokes" could be in any radial order. The relative above/below/right/left positioning could be reversed with no loss of meaning. Often dragging a cluster can result in a completely different set of 'nearnesses'. And as andymangold mentions elsewhere in this thread, for WikiWeb even the set of nodes that are expanded from any origin are randomly chosen... so you can't even follow the same path twice.
So these graphs tempt with their visual connotation that they are information-dense and stable like a real map, but then turn out to be splatter-art, pretty but with most of the ink being random noise.
These problems might be fixable with extra layout constraints. What if shorter articles were always up and longer ones down? More-inlinked to the left and less-inlinked to the right? What if edge lengths or thicknesses were correlated to other notions of bidirectional similarity? Of course doing this, in an automated fashion that continues to look nice and meaningful in every corner of the dataset, is quite hard.
Something forcing a little more of a 'tree' feel, at least when moving in certain directions, could help pack more deterministic meaning and text into a small area. (Think vague intimations of Miller Columns within a rendered graph.)
Thanks for taking the time to write this out, Gordon.
One of our biggest concerns with the node view was that it would imply more significance than is actually present, as you mention. Like you point out, the radial order of the nodes, their relative proximity, and which nodes are actually shown are completely arbitrary. At the end of the day, you're right: it is far more aesthetic than it is informative.
However, we do think there is something to be said for aesthetics and how the app feels. Our goal was not to expose all sorts of new data and information, but rather to make the browsing of Wikipedia more fun. While I concede the node-view does not convey a whole lot of meaning, my hope is that is stimulates curiosity and delights the user.
I agree. More and more people are latching on to the richness of graph-oriented thinking, but I don't think anyone has a good theory of graph-oriented UX.
Although I wouldn't be too surprised if someone found the solution at Bell Labs in the 80s and we're just waiting to rediscover it.
The app itself looks gorgeous, but I dont understand the primary use case. I've been writing papers and researching for years now, and I've never found the little idea cloud thing -- it seems more like a way to connect suspects in cop movies than an actually helpful way of visualizing discrete data.
Indeed. I watched the video on the front page, and I couldn't work out how the application was actually helping the end user. I couldn't work out what the chap with the pins and string was actually trying to accomplish either.
It's extremely pretty, though I question some of the UX desicisions.
Double-tapping an item makes it vanish. Due to the seemingly random selection of nodes that appear when re-searching for a parent node, that item may never be seen again...
Seems odd that a gesture like double-tapping, while not often used in iOS, would result in the exact opposite action of the familiar double-clicking to drill down or expand of other UIs.
Thanks for taking the time to leave some thoughtful feedback.
To pull back the curtain a bit, you are right that the nodes that show up when a parent node is tapped are randomized. As you can imagine, many Wikipedia pages have thousands of links which would be unwieldy for both the hardware and the user. For this reason, we gave up on the idea that users would be able to search for a specific page through the node view. Our hope is that someone who is looking for a specific page will use the search feature, while the node-view will be used for more serendipitous browsing.
As far as the double-tapping is concerned, you may be right about it not being intuitive. It will be interesting to see what people's reactions are. We decided to go with it because, like you mentioned, it is one of lesser used gestures in iOS, and deleting a node is the least important way to interact with it. We felt that expanding and bringing up the article itself were more important, so we tied them to the more standard gestures.
It's interesting how often ideas have to happen at the right time to really work. Light Table is another example of a set of ideas that was waiting for the right conditions to reincarnate.
If you want something like this, but more generic than Wikipedia-only, have a look at PersonalBrain (http://www.thebrain.com/, no iPad version?). To be honest, I could never make it work for my main intended use (academic papers & citations), but I really think it is a cool app with lots of potential.
Reminds me that if you keep clicking the first link (ignoring anything in brackets) of the article on a wikipedia page you will eventually hit philosophy and then get in a 3-4 page loop.
edit: Having just checked, the loop is now a 2 page loop between reality and philosophy.
I've tried a few Wikipedia apps... I always end up not using them since I find Wikipedia pages via Google and there is no way to redirect you from the web to an app. (Wikipedia could choose to do it on their end but they don't.)
How is Wikipedia supposed to know you'd like to be redirected to some random app downloaded from an app store?
There actually is a way to redirect from the web to a random app (intents on Android) but that's not available on iOS. Lay the blame at Apple's feet not Wikipedia's.
MediaWiki/Wikipedia has a skin feature where a user can set their own custom user-specific JS to be added to each page. (Think of it as a server-side Greasemonkey or auto-triggered-bookmarklet.) See...
I suspect you could use this to implement a bounce-to-other-app-via-URL-handler mechanism, for any logged-in user who could be coached to cut&paste the right Javascript into the right place.
Does anybody know (or is anyone willing to guess) whether the force-directed-layout is done by some available library or whether they rolled their own?
There was a program like this, specifically for Wiki articles, for Mac OS X, called Pathway, but it seems to have been abandoned. It hasn't been updated since 2007.
As nobody said it yet. I'm always very wary of phrases like "a portion of all proceeds will be donated...", and in this case it caused me to stop looking.
The reason is that we don't know how generous or not that portion is, and what the definition of Proceeds is.
Better to state that clearly as in "20% of the price".
It doesn't have to be a large percentage, but we do need to see it as fair.
I'm glad you brought this up, Lance. Frankly, I'm surprised that no one else has.
Due to tax complications, the percentage of money we're going to be able to give is going to vary drastically depending on how many overall copies of the app we're able to sell. We were advised by our lawyer to use the term proceeds as opposed to profits or revenue as a small means of protection.
Additionally, I would challenge your expectation that we should give a "fair" amount to the Wikimedia foundation. We're the only one of the many paid Wikipedia apps that chooses to give any money back to Wikimedia (as far as I know, at least) and we certainly don't feel as though we have any obligation to do so. We CHOOSE to give back because we want to support Wikipedia and free, open knowledge.
We're committed to giving back, we just don't want to back ourselves into an unsustainable corner or make promises we can't keep.
gojomo|13 years ago
They seem to show so much, in the relative placement/distances/angles of nodes and edges. But when you get right down to it, almost all that eye-catching detail is random noise. The same "spokes" could be in any radial order. The relative above/below/right/left positioning could be reversed with no loss of meaning. Often dragging a cluster can result in a completely different set of 'nearnesses'. And as andymangold mentions elsewhere in this thread, for WikiWeb even the set of nodes that are expanded from any origin are randomly chosen... so you can't even follow the same path twice.
So these graphs tempt with their visual connotation that they are information-dense and stable like a real map, but then turn out to be splatter-art, pretty but with most of the ink being random noise.
These problems might be fixable with extra layout constraints. What if shorter articles were always up and longer ones down? More-inlinked to the left and less-inlinked to the right? What if edge lengths or thicknesses were correlated to other notions of bidirectional similarity? Of course doing this, in an automated fashion that continues to look nice and meaningful in every corner of the dataset, is quite hard.
Something forcing a little more of a 'tree' feel, at least when moving in certain directions, could help pack more deterministic meaning and text into a small area. (Think vague intimations of Miller Columns within a rendered graph.)
andymangold|13 years ago
One of our biggest concerns with the node view was that it would imply more significance than is actually present, as you mention. Like you point out, the radial order of the nodes, their relative proximity, and which nodes are actually shown are completely arbitrary. At the end of the day, you're right: it is far more aesthetic than it is informative.
However, we do think there is something to be said for aesthetics and how the app feels. Our goal was not to expose all sorts of new data and information, but rather to make the browsing of Wikipedia more fun. While I concede the node-view does not convey a whole lot of meaning, my hope is that is stimulates curiosity and delights the user.
taliesinb|13 years ago
Although I wouldn't be too surprised if someone found the solution at Bell Labs in the 80s and we're just waiting to rediscover it.
jmduke|13 years ago
Angostura|13 years ago
Consequently my money remained in my pocket.
Tycho|13 years ago
d5tryr|13 years ago
Double-tapping an item makes it vanish. Due to the seemingly random selection of nodes that appear when re-searching for a parent node, that item may never be seen again...
Seems odd that a gesture like double-tapping, while not often used in iOS, would result in the exact opposite action of the familiar double-clicking to drill down or expand of other UIs.
andymangold|13 years ago
To pull back the curtain a bit, you are right that the nodes that show up when a parent node is tapped are randomized. As you can imagine, many Wikipedia pages have thousands of links which would be unwieldy for both the hardware and the user. For this reason, we gave up on the idea that users would be able to search for a specific page through the node view. Our hope is that someone who is looking for a specific page will use the search feature, while the node-view will be used for more serendipitous browsing.
As far as the double-tapping is concerned, you may be right about it not being intuitive. It will be interesting to see what people's reactions are. We decided to go with it because, like you mentioned, it is one of lesser used gestures in iOS, and deleting a node is the least important way to interact with it. We felt that expanding and bringing up the article itself were more important, so we tied them to the more standard gestures.
robinhouston|13 years ago
taliesinb|13 years ago
zatara|13 years ago
taliesinb|13 years ago
It's for when you want to grab a small portion of the full Wikipedia graph without cutting yourself on the 30-odd gigabytes of XML the dumps provide.
mysterywhiteboy|13 years ago
xlance|13 years ago
http://www.thewikigame.com
andymangold|13 years ago
Lockyy|13 years ago
edit: Having just checked, the loop is now a 2 page loop between reality and philosophy.
smackfu|13 years ago
kachnuv_ocasek|13 years ago
justincrane|13 years ago
There actually is a way to redirect from the web to a random app (intents on Android) but that's not available on iOS. Lay the blame at Apple's feet not Wikipedia's.
gojomo|13 years ago
http://en.wikipedia.org/wiki/Help:User_style#JavaScript
...and the 'Custom JavaScript' links of...
http://en.wikipedia.org/wiki/Special:Preferences#mw-prefsect...
I suspect you could use this to implement a bounce-to-other-app-via-URL-handler mechanism, for any logged-in user who could be coached to cut&paste the right Javascript into the right place.
joshhepworth|13 years ago
pohl|13 years ago
joshhepworth|13 years ago
hhimanshu|13 years ago
nchaimov|13 years ago
http://pathway.screenager.be/download
chuinard|13 years ago
andymangold|13 years ago
lancewiggs|13 years ago
andymangold|13 years ago
Due to tax complications, the percentage of money we're going to be able to give is going to vary drastically depending on how many overall copies of the app we're able to sell. We were advised by our lawyer to use the term proceeds as opposed to profits or revenue as a small means of protection.
Additionally, I would challenge your expectation that we should give a "fair" amount to the Wikimedia foundation. We're the only one of the many paid Wikipedia apps that chooses to give any money back to Wikimedia (as far as I know, at least) and we certainly don't feel as though we have any obligation to do so. We CHOOSE to give back because we want to support Wikipedia and free, open knowledge.
We're committed to giving back, we just don't want to back ourselves into an unsustainable corner or make promises we can't keep.
alexpenny|13 years ago
rcsorensen|13 years ago
Chocolator|13 years ago
jgamman|13 years ago