The amazon-for-source is a cool idea that could also be applied to navigating docs. It's a 1st order Markov process (predicting the next link based on the current link), but could be extended to 2nd order (predicting the next link based on how you got to the current link), or nth order, of course. This context might capture the reason you were looking at the current page. We could do a little statistical AI, and combine the predictions of different sequences that are similar enough.
The problem that source is changed (unlike books) as it is fixed/refactored/deleted, probably wouldn't hurt much.
True. There are a couple of good papers published on the concept of digital/computational wear, which is the basis for social filtering, that deal with document navigation.
Great writeup. I'd add a lesson I'd learned coming out of lab research as well. "Don't develop in a vacuum, involve the end users early and often." which is a bit of a corollary to "Lesson learned: Customers may have problems, but they also have solutions." I see this also outside of research, in general practice also. You seem to have figured this out naturally as part of your idea development process, but it's amazing how often this doesn't happen.
It surprises me how companies don't take full advantage of using the collective power of users to come up with ideas. Uservoice and GetSatisfaction are great initiatives, but they shouldn't replace 1:1 conversations.
I think that one of the keys is to incorporate the user's desires with some of your own special sauce to make what hey want. Basically give them what they want, but add a little to it, or give it a cool twist. If you constrain only to their desires you end up with all kinds of bad things because users often have trouble articulating what they want.
Agile methodologies seem to do an excellent job of targeting users. By moving from a monolithic development and release cycle to a faster set of more limited releases, you can get feedback from the users much more quickly. Instead of spending a year building feature x with all of the possible sub-features you can think of. Spend a month building a rudimentary form of it, and get users to provide feedback on it. It's amazing how guiding the users in this way gets you excellent feedback, plus it makes the users feel empowered, like they are helping design the software.
The problem that source is changed (unlike books) as it is fixed/refactored/deleted, probably wouldn't hurt much.