Yes. I see users saying they can't connect but in reality, limewire is

-either connecting but doesn't find a good host before the users give up and quits
-or not connected at all because user unchecked the 'connect at startup' checkbox

these are issues of users not understanding what's going on. limewire is not transparent.

or the people looking at the dropped i/o column and assuming that something is wrong since 90% incoming is dropped.

or the people looking at the transfer column wondering what the number before and after the / means, with no way of finding it out.

or the people wondering whether their uploads fail because they always only go to around 4% and then stop.

These posts have been there, I assume you've seem similar ones yourself. These are all interface issues.

The fact that a column is hidden by default does not mean users are not going to see it. And, IMO, users are entitled to know whether their uploads are succesful or not, actually, i think it's crucial. It's weird to leave your PC on 24/7 and giving your bandwidth without knowing what's going on.

Its sometimes easily solvable problems like naming a column 'attempted/succeeded uploads' instead of 'uploads' (I know, there's a space issue). Or removing a resume button, for that matter. There has been confusion about that in the forum, too.

It seems that programmers tend to have a hard time imagining that users see things with different eyes, because they lack the knowledge of underlying processes that make everything seem 'simple' and 'logical' to people who actually write software. That's why you use MLdonkey and people like me don't. Imagine what cars would look like if they were designed by engineers (I am talking about the styling, interior, positioning of the instruments, levers, knobs etc., not the mechanics). It would be a desaster in the market, despite possible superior technology. That's why voila's idea was good to get somebody to specifically deal with user experience. Preferrably somebody who is not tainted by an excessively deep understanding of the underlying technology.

I have been using Shareaza for a while (before it turned into a cult): Limewire (2.9.x) downloaded in chunks that are spread all across the file, so do other servents. I know that because shareaza's progress bar's reflect where the chunks you're uploading are located within the file.

Agreed. This would also save us a lot of work in the forum.

:-)

Yes it should - and LimeWire 3.0.0 *should* be using Java 1.4 on OSX. I thought the problems with Java 1.4 had been sorted out weeks ago.

The URN looks like this: "urn:<type>:<unique identifyer>" in the case of LimeWire and most other gnutella clients a string that looks like this is used: "urn:sha1:<sha1-hash>" -
Shareaza on the other hand uses "<urn:bitprint:<sha-1 hash>.<tigertree root hash>".

1) The compression stats show the bandwidth savings of incoming and outgoing compressions. Since older ultrapeers (2.9.9-2.9.11) have disabled outgoing compression by default, you will only see bandwidth savings in one direction.

2) The QRT (Query Route Table) is always empty if you are a leaf so "QRP %" shows 0. Only ultrapeers keep a QRT for the connections because they are shielding clients from traffic. - The higher the percentage, the more searches are forwarded to the connections (actually it's a little more complicated than that).
The QRT is sometimes a good way to identify freeloaders - although not everyone who has a very low "QRP %" value isn't sharing anything at all (except if that is 0) - the files he is sharing obviously just contain very few different keywords.

That's what a beta is all about. - (I suspect there is something else wrong with the installer because some files are not copied correctly on my system and LimeWire throws exceptions about some missing files all the time - since the cvs version works quite well I am confident LimeWire will sort this out).

* If LimeWire takes more than a few seconds to connect it usually doesn't connect at all. I have my doubts that users are so impatient to close LimeWire after a couple of seconds before closing LimeWire because it hasn't connected
* In the options it states clearly what this button is used for. If the user doesn't understand it, he obviously picked the wrong language when installing. And I think that most users who uncheck that checkbox in the options are bright enough to find the connect button.

Yes, unless they go to the www.limewire.com homepage where it clearly says in the help section that it's normal for the incoming value to be high.

Oh yes, there is a way of finding out. - Ask somebody who knows.

That's not an interface issue at all. It's a documentation issue. If this was an issue, the only solution was not to display that kind of information, because the LimeWire client for example has no way of knowing if an upload was successful if it stops after 4%.
I am not arguing that there are no interface issues at all (the resume button is one big example for such an issue) but what you list here are problems with understanding information Joe User would just care for - I mean I don't even care for it most of the time.
Plus, there is not much room in the Interface to write explanations for everything. - Most of it is explained on the www.limewire.com website, however. And for the rest you come here to ask people who know.

You are not going to compare MLdonkey to LimeWire, are you? I mean MLdonkey is a really good example for a bad interface. Even the command-line interface is worse than average.

2.9.11 downloads chunks as I described it. The uploading client, btw., has no way of knowing which chunks have already been downloaded by the client and leaving out a few chunks from one uploader is fairly normal, if the downloader is swarming.

Regarding Java 1.4 on os x and LW, The java 1.4 version of 2.9.11 works much better than the official 1.3.1 version LW compiles. Startup is faster and you don't have to hide LW to save ressources as it cosumes 0-10% in front like version 2.5.5, before LW began using too much processor because of a gui incompatibility with os x java 1.3.1 implementation. I hope 3.0 is for java 1.4, but the beta I tried yesterday wasn't , good news is that using a theme (a new feature), reduces gui cpu usage problems.

There was 1 minor bug I noticed when running limewire. I have Limewire Pro 3.0.0 on XP with Java 1.4.2. When I did a search and clicked d/l the bottom bar will no longer pop up to show the progress though I can drag it up. Also someone should tell the Lime dev the red theme looks nice but when you have the diff colored bars enabled one color is yellow on black(thats ok) and the other is yellow on white(blinding and do no sift well together) Well those were my meaningless comments now you guys can go back to discussing something I really no very little about. Later

Yep, noticed that too then read on the cvs mailing lists that sam already fixed it for the next release.
http://gui.limewire.org/servlets/Bro...vs&paged=false
http://gui.limewire.org/servlets/Bro...ev&paged=false

Hmmm--so using the Windows-like theme reduces cpu usage on OSX. High price to pay!

I do regularly build LimeWire for OS X and I do have some fixes in the code that are OS X specific and not yet accepted by the LimeWire developers. This version runs using Java 1.4 (it does not use any installer, just drag the app to your HD), reduces CPU load even if running with the Aqua look and feel and fixes some crashes relating to the use of many open files. You can find it at:

http://baghira.han.de/~jum/

Merci beaucoup Jens-Uwe. I didn't want to reveal your address because of traffic concern I would have caused you. I've used your builds of LW since late 2002, and they are great, especially since the java 1.4 builds work well.

Tx again!

trap_jaw,

I can only say that most of these issues have come up recently (last 2 weeks) in the support forum. Personally, I think a large documentation, esp. for a simple app is a sign of a badly designed app (not techically, but from a human factors p.o.v), but I realize that this is a hard point to argue than I thought.

If you research a bit about human factors, you will realize that the notion that users read manuals is one of the hardest to kill misconceptions of programmers and engineers. They don't. This issue comes up every single time a company employs human factors people to check their software. They find a cumbersome interface issue, and the engineer will reply that, well, it's all documented in the manual. It's fan users like the people posting in this thread that maybe bother maybe read the manuals. Not the average users. Particularly if they can switch to other apps, or bother the forum for support.

There are a few users every day who keep asking the same questions in the forums. It's not like there is somebody with good advice there 24/7. Some of these users give up and use other vendor's applications. If we could take care of some of these issues with interface improvements, that would make everybody's life a lot easier.

Let me give one example: When users start up limewire, they have no indication whatsoever that limewire is doing anything. If limewire doesn't connect, they have a red dot and a greyed dot as sole indicators. No text. They have to go to the connections tab to figure out in the first place whether limewire is at least attempting to find hosts. Why can't limewire clearly communicate it's connection status on the tab that shows when you open the program (search). Like:

a) can't reach the internet (with suggestions to check router/firewalls/etc)
b) connecting/waiting for good hosts

and once the light goes green

c) connected behind router/firewall (suggestion to forward port)
d) connected and everything running well

I know you can find these things out by looking elsewhere if you know what you're doing but a novice user maybe doesn't think of checking the 'connections' tab. If I remember correctly, the 'connections' tab is even hidden by default. Is that again information that's irrelevant to users?