Matthew Toseland a ?crit : > 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.
Maybe informing the user could be a first step. If he only downloaded a small index, tell him. A warning like : "you only downloaded a small index, you will only be able to search XX freesites. Index download is still in progress and the number of visible sites will increase soon." Freenet can't be as fast as Google, but if we tell the user, he would know, and choose to wait or not, instead of thinking it simply doesn't work. > 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. There is a French user (sich) that is working on an insert-on-demand tool that can achieve that. It works on top of the WoTplugin. For now, it is a standalone app, but we agreed on rewriting it as a Freenet plugin as soon as it is proven to work. Such a tool could address that problem : users who type something in the appropriate searchbox will actually get a list of what is available. Of course, files would have to be inserted and we need to warn them that the download can take a long time... > 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). My preference goes to this one. I'm not saying all client apps should disappear, but IMHO basic functionnalities (chat, search, filesharing, blogging) should be accessible though Fproxy, right after Freenet is installed. > 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. >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Devl mailing list >> Devl at freenetproject.org >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080902/33477adb/attachment.pgp>
