On Tuesday 02 September 2008 01:09, Ian Clarke wrote: > On Mon, Sep 1, 2008 at 6:35 PM, Florent Daigni?re > <nextgens at freenetproject.org> wrote: > > The main complain is that freenet is slow... do we know how to address > > that? > > Not according to the current survey results. Only 12% complained that > it takes too long to retrieve content, as compared to 29% who claimed > that they couldn't get it running. > > This argues strongly for more attention to be devoted to the > installer, and to bootstrapping. > > > I don't think that putting a search box in front will help matters; > > Let's assume the nodes bootstrap in seconds instead of minutes: > > current indexes aren't maintained and if they were they would be *huge*. We > > can't possibly expect the first search to be answered in seconds if it > > involves downloading the huge index! Of course we could bundle the > > indexes too... but if we go down that road it's not freenet anymore. > > A good point. I think my goal was to provide an interface that users > would intuitively understand, a search engine is an example of such a > thing. > > Perhaps the index could be downloaded in stages - a small initial file > for the most popular stuff - to get quick responses - and then > progressively larger files with additional info. > > Of course, what we really want is proper support for search in the > protocol, but that is a tall order.
IMHO users expectations and what we can realistically provide at this point (especially through fproxy) are a *LONG* way apart. There are numerous complaints on the write-in parts of the survey about either the lack of a GUI, or the lack of a search engine, or people saying they've tried other P2P etc etc. What they mean is they want us to reimplement Napster, not Google! If we put XMLLibrarian on the home page, it will only search the freesite web. It will not search Thaw indexes, it will not search FMS, it will not ask people to insert files which aren't currently available (often a good tactic), and to top it all off it will probably take around a minute to return no results because 1) the network is small, 2) most of the "filesharing" content isn't visible from the freesite part of the network, and 3) users don't know this and treat it as a classic p2p search box. This is the fundamental problem: Freenet simply doesn't do what most users want, when they figure that out they will uninstall it. So I don't think it is likely that minor usability improvements will bring us dramatically more users. We do need to know whether this is the problem or whether we really do have 30% of our would-be users having error 1067 etc etc. IMHO that is very unlikely, and in terms of write-ins, there are more complaints about no GUI or it being slow than about specific install failures that we know about. We are left with the following strategies: 1. Concentrate on what we're good at, and dramatically improve performance, both in terms of speed and in terms of reducing system cost, so that those users who are interested in what we *can* do will stick around. 2. Make those things that we're reasonable at but aren't part of fproxy more visible and easier to use. Three sub-options: a) Make everything important part of fproxy. In particular, FMS, Thaw, and jSite/Thingamablog (if users want to contribute content, it's especially important to keep them). b) Make it *really* easy to launch the external GUI Freenet apps. I'm not sure how, that's the problem: even if we implement a quicklaunch rabbit icon, there are so many on a typical XP desktop now that XP hides them and users ignore them. Which brings us to the third option... c) Build what the users want - an all singing all dancing windowed GUI application mostly centered on filesharing. Thaw is some way to this, but its chat is based on Frost and therefore non-functional, our devs are likely not competent to make it into a world class filesharing GUI, and it has no web presence nor any independant marketing, so it's not going to be the Killer App that we can hang off the coat-tails of. But even if we do focus on what users expect - filesharing - the network will still be so small and so slow that it will be a mirage: it won't deliver what it promises. > > Ian. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080902/d3a460a4/attachment.pgp>
