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.)
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.
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.
Consequently my money remained in my pocket.
We also highly valued the reading experience and put just as much effort into making the presentation of the content better as developing the web.
However, that's not going to be for everyone. It's been a joy for us, and we're simply hoping others will find value there as well.
When I bought my iPad I wasn't really sure about my user scenario, but now I see that getting inspired by other people's work is a big part of it.
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.
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.
That said, this is a beautiful app!
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.
edit: Having just checked, the loop is now a 2 page loop between reality and philosophy.
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.
Details: http://mobiledevelopertips.com/cocoa/launching-your-own-appl...
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.
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.
