aMule Forum

English => aMule News => Topic started by: wuischke on November 16, 2007, 05:30:04 PM

Title: A new look for aMule 2.2.0
Post by: wuischke on November 16, 2007, 05:30:04 PM
As already mentioned a couple of times, we aim to have a new look for aMule 2.2.0.

You know, coders are not artists (yes, I drew that rabbit in the attached skin myself), so we are looking for your help. C'mon, among all these Mac users there have to be a couple of artist. ;)

People like Treviño, deloun and mischamajskij have already done good work on a new look and we are shipping some skins with the daily tarball, but there are still some things we would like to see improved.

Criteria/improvements:

The easiest way to try out a new look for aMule is to create a skin. A skin is a simple zip file with png files inside - just download a existing one and modify it, zip the file again and put it in your aMule skin folder to test the look!

You'll find more about skins in the wiki: http://www.amule.org/wiki/index.php/Skins

P.S. I've attached my attempt at creating a skin - unfortunately not very multiplatform.

P.S.S. No, aMule 2.2.0 will not be delayed because of the new look. When the showstopper-bugs are fixed, we will release, the new look can wait - but I prefer it not to.
Title: Re: A new look for aMule 2.2.0
Post by: brainnolo on November 18, 2007, 12:08:03 AM
I'm using aMule on a Mac and toolbar icons have text here. Anyway I doubt any skin will fix the aMule usability problems, the interface needs to be completely redesigned, a little makeup won't do ;)
Title: Re: A new look for aMule 2.2.0
Post by: wuischke on November 18, 2007, 11:49:00 AM
Hi brainnolo,

I agree. But a complete interface overhaul requires a lot of work whereas a new default skin can be implemented between breakfast and lunch while still improving the look of the application.

Well, actually that's not true. I'ld have to install 32bit compatibility libraries first or use OpenBSD's linux compatibility to be able to use wxDesigner again. I offered Robert Roebling to help with a 64bit binary, but he didn't answer me to date. A pity, he was a very nice contact.

I think you can expect a new interface (probably using another toolkit) in the next non-bugfix version after 2.2.0 and you are welcome to give us design ideas for a new UI.

kind regards
Title: Re: A new look for aMule 2.2.0
Post by: brainnolo on November 18, 2007, 04:09:38 PM
I will be glad to help. Although I'm no usability expert, it is the field of my studies so the matter interest me a lot ;)
Title: Re: A new look for aMule 2.2.0
Post by: Cimmo on November 18, 2007, 04:18:42 PM
can you change the black on grey colors in the homepage? It has asked tons of times by a lot of people, but never happened.
Really it's difficult to read, use a lighter grey for example, I think it's easy and fast to change for an immediate eye relax.

I don't think to be OT because you are talking about usability, and this is usability also, so let's start from the home!

thanx
Title: Re: A new look for aMule 2.2.0
Post by: westcubegeek on November 18, 2007, 08:16:09 PM
Hello!
The icon themes in aMule CVS makes aMule much nicer ;)

But i have a little proposition...
Because i don't know the english word for this thing, i indicated it in a screenshot:
(http://img240.imageshack.us/img240/3366/capturexj8.th.png) (http://img240.imageshack.us/my.php?image=capturexj8.png)

It would be nice to change them to inline GTK equivalents...
These are rounded and i don't find them very smooth! :(

I hope you understeand! :D
Title: Re: A new look for aMule 2.2.0
Post by: Kry on November 18, 2007, 09:34:51 PM
I think you can expect a new interface (probably using another toolkit) in the next non-bugfix version after 2.2.0 and you are welcome to give us design ideas for a new UI.

I don't think so and would appreciate not giving such hopes to users.
Title: Re: A new look for aMule 2.2.0
Post by: natsirt on November 19, 2007, 01:01:38 AM
I think something really useful would be to have the correct file icon (for each file type) in front of every file of a list, so it would be much easier to find what we are looking for...
(something like in emule)

Even if the icon is not the one of the application witch is supposed to open the file (but that would be great !), I think that the different file types should be more clearly visible (for an "all types" research for exemple)

Good luck for the amule project...!
I'm hardly waiting for this version

thx
Title: Re: A new look for aMule 2.2.0
Post by: apo758 on November 19, 2007, 01:51:36 PM
All icons should be changed with more polished ones, not only toolbar icons. Sometimes they remind me Windows 98. Tango icons are great.

For usability, the real problem is that it has to look good on every platform but that's impossible! Windows, MacOS X, Gnome, KDE, etc… they all have different UI guidelines. Now it's good only on Linux and maybe on Windows: on MacOS X it looks like a mess.

But…

1) I'm not a developer but is it really so difficult to set different actions for the close button on different OS? On MacOS the close button quit the application ONLY when it makes no sense to have the application opened but no window (iLife suite, for example), but when you have an application that you need to use often (like Safari or iWork suite) or that you need to leave open while you are doing other things (like all the other P2P apps) the close button should only close the window, not the application.

2) As said by natsirt, different icon for different files. At least for the most common shared files (movies, archives, etc…).

3) Toolbar customization: I don't use messages, importer and I have never understood why there's a button for the about window. I have set the auto connection so I don't need a button on the toolbar. It would be great to decide what icon is useful and what icon is not. Flexible spaces would also be great but it's secondary.

4) Integration: if I'm downloading a movie, I can see the preview with VLC. But I can't see any preview for other files.

5) File rename don't need to have a button that confirm the action. You change the name in the textfield and it's automatically saved when you close the information window.

6) I don't know if this is a request for the GUI or not, but it's frustrating to see that a file is corrupted/fake because someone is using HyperMule (it sets all the file comments to corrupted/fake). Is it possible to have a filter for the comments?
Title: Re: A new look for aMule 2.2.0
Post by: lfroen on November 19, 2007, 04:29:25 PM
Quote
3) Toolbar customization: I don't use messages, importer and I have never understood why there's a button for the about window. I have set the auto connection so I don't need a button on the toolbar. It would be great to decide what icon is useful and what icon is not. Flexible spaces would also be great but it's secondary.

Useless waste of time. I personally hate such programs (MS Office, hello). Toolbar should be nice-looking, and fit on the screen of 800x600 (think about portable device).

Quote
4) Integration: if I'm downloading a movie, I can see the preview with VLC. But I can't see any preview for other files.
And how exactly you expect to preview ZIP file, for example? Hint: you can not.
Title: Re: A new look for aMule 2.2.0
Post by: apo758 on November 19, 2007, 06:46:41 PM
I don't know if it's ZIP or RAR, but one of these archives for sure can. If you have a partial download you can decompress it and see a part of the compressed files.
I don't understand the reason of your first sentence. Customization doesn't mean that the toolbar will look ugly and it doesn't  mean that it will be larger than 800x600. Ok, you hate programs that leave the freedom to choose what buttons you can have on toolbar, but someone can love them. You can leave the toolbar as is and others can change it, what's making it useless?
Title: Re: A new look for aMule 2.2.0
Post by: phoenix on November 19, 2007, 09:22:14 PM
Quote
4) Integration: if I'm downloading a movie, I can see the preview with VLC. But I can't see any preview for other files.
And how exactly you expect to preview ZIP file, for example? Hint: you can not.
At least looking at the zip directory would be already something interesting, and IIRC, the directory has a well known place, either the first or last part of the file. I have read around that it is possible to decompress part of the file, there is probably an application to do that on windows, though I cannot confirm that.
Title: Re: A new look for aMule 2.2.0
Post by: brainnolo on November 19, 2007, 10:46:10 PM
For usability, the real problem is that it has to look good on every platform but that's impossible! Windows, MacOS X, Gnome, KDE, etc… they all have different UI guidelines. Now it's good only on Linux and maybe on Windows: on MacOS X it looks like a mess.

This is not true. Right now the aMule interface is simply not good at all. The main problem is actually that it is not centered around anything. It is using the toolbar as a tab-switcher, where every tab has the same "weight", although the application should be centered around searching&downloading. There are too many useless options. A real interface redesign comes at a cost: reduced feature set, at least initially (main candidates imho are chat, messages and stats).

As far as preferences go, is there any reason for which I shouldn't want to automatically connect at startup, reconnect after connection is lost? Why should I want to disable one of the possible networks? Heck do I really need to know about UPnP? it is meant to be transparent! (if you *really* want to keep the option at least label it something like "Bypass Router/Firewalls") . Do we really need separate download/upload settings for stats and limiting? What is slot allocation? there is no help for that. Did anybody ever change ports or maximum file limits (and if you do, do you get any real advantage?). Here we could remove entire PANES of options, relabel a few more and stop cloning eMule. I really think I could go on forever, given the interface looks like it is designed to test features and not to be used.

If the developers are interested in changing the interface I can try to help, but again, it won't be painless at all at the begin. The benefits would be huge. The application won't "look good" on every system but it will at least be easier and more pleasant to learn and to use. wxWidgets are not a problem at all.

aMule is a great application written by great developers, I've had the chance to collaborate with phoenix on a little patch and he was great. But developers aren't the best interface designers ;)
Title: Re: A new look for aMule 2.2.0
Post by: apo758 on November 19, 2007, 11:29:09 PM
I agree with you, brainnolo, but I think that the problem is that every OS gives some habits. MacOS makes you want all integrated, all look very good and all look easier and cleaner (for the GUI). Linux makes you want al the possible options to tweak and other great things. Windows makes you want to format. This is just an example based on my experience.
Remove every not-so-simple panes… I don't think that it's the good chioce. It's the better choice for Mac users like me, IMHO, but not for the average Linux user.
The best would be drop wxWidgets and find an alternative way to draw the GUI, a more native and OS-different way, but I think it's impossible, right?
An option is to release a GTK version for Linx, for example, and a version for Mac based on amuled and a good, Mac-like, interface and make them work seamlessly as the classic aMule works. amuled and an official frontend. Is it possible? What would be the problems in it?
I think that a lot of Mac users would prefere this way and it would not affect Linux users because there would be no change for them.

However I especially agree with brainnolo on a thing: stop cloning eMule. aMule is powerful, for something it's a great application, but I think that it's strong and mature enough to take its road, to get some differences in usability.
aMule can conquer a large number of Window users but it have to be different from eMule.
Title: Re: A new look for aMule 2.2.0
Post by: Kry on November 19, 2007, 11:32:39 PM
Either you use gnome or MacOS. Either way, we like flexibility in the options we present to the user, and as much control over the features as possible. If you don't understand an option or won;t use it, fine by me, just don't use it. But don't prevent other people from ahving the possibility to use it just because you see no need for it. The whole "let's dumb down the interface as much as posisble and make assumptions about what people want" gnome-like mentality is, for me and for most people I know, wrong on so many levels.

Most, if not all, of the options you mention are not only used daily by most people, but some are essential to the program usage. Ignorance about how the program works is not an exuse to contest the existance of such options.

I'm always for finding better default values, but never for removing the possibility for the user to tweak the program at his/her will.
Title: Re: A new look for aMule 2.2.0
Post by: Kry on November 19, 2007, 11:34:11 PM
As for you, apo, wxWidgets ALREADY uses GTK on linux and native toolkit on MacOS (Carbon/Cocoa). Releasing different interfaces for every platform would be disastrous on so many ways, starting by support.
Title: Re: A new look for aMule 2.2.0
Post by: natsirt on November 19, 2007, 11:41:30 PM
Kry, do you think it's possible to add a file type icon in front of every file, as I mentionned before?
I know it's getting closer to emule GUI but I think this would really be useful...
Title: Re: A new look for aMule 2.2.0
Post by: apo758 on November 19, 2007, 11:54:35 PM
That's why I asked. I'm not a developer so there's a lot of things that I don't know how they work and why they do. I read something about wxWidgets an now I think to understand the way they work but what I was talking about concern design guidelines.
For example,
(http://img413.imageshack.us/img413/7797/immagine2ai4.png)
the arrows in the picture show three things that look bad on Mac but I think they look good on other OS. That's what I meant with my post. Now I know that it's impossible or at least very difficult and I hope there will be a solution to make aMule look perfect on every OS. Anyway, thank for the reply! ;)
Title: Re: A new look for aMule 2.2.0
Post by: brainnolo on November 20, 2007, 12:29:16 AM
Kry: why one should know about how an application works? All I know is that I want to download my favourite linux distribution (although I am a Mac user) like everybody and I want to do be able to do that without any hassle. The program should just work without setting anything, except the things one should care about, like where to download and what to share. I AM ignorant of how the application works AND I want to remain ignorant about it because it is just a mean to an end, and I think my time is better spent watching the installation of the linux distro I just downloaded instead of trying to squeeze the last byte of performance.

What puzzles me even more is why you say they are so vital when I didn't touch any setting and it just worked.

I respect your desire to keep the aMule interface the complex monster it currently is, especially cause I saw work is done toward EC (libamule would rock too) and anyone can roll its own interface based on it (and I will try to accomplish said task if I get enough time). Keep up the good work, under the hoods aMule is surely a great application and it shows that constantly. I do not like at all the way it interacts with me, but one can only ask so much for this price I guess.


BTW: The reason for which I do not want all those options is because they confuse me and divert the attention from the important parts. I wonder if you would be at least open for a re-organization of options and functionalities (with some re-labeling maybe). Still painful change to accept for sure, but hey :D
Title: Re: A new look for aMule 2.2.0
Post by: apo758 on November 20, 2007, 12:37:13 AM
I think you're right, brainnolo, but there are people who wants to squeeze the last byte of performance. A show advanced features check box?
Title: Re: A new look for aMule 2.2.0
Post by: phoenix on November 20, 2007, 04:10:08 AM
Well, it seems to me that you are talking about different things and both sides are not hearing the other.

I totally agree with Kry: the gnome way is stupid. Because of one simple thing: you loose your freedom to choose. I sometimes want to know all and sometimes want to be ignorant. But I need no stupid programmer to tell me I cannot choose the options I will use when I print. "Oh, lets hide this from the poor stupid ignorant user, he does not know what he is doing..."

That said :) I agree with brainolo that aMule interface is bad. It is a copy of eMule, which is originally bad. But in its root, aMule was designed to be a clone of eMule. To change that, would be to write another program.

Usability has nothing to do with configuration options. You can tweak a thousand options, as long as there are sane defaults to them. Or even if the program tries to figure out sane default values. And of course, buttons to restore sane default values :) . When I say the interface is bad I mean the way things were originally designed, and here wxWidgets does have an influence.

So, to be practical, this is a list (unpublished until now) of things I consider bad in aMule GUI:
1) There should be a menu interface. Even if just to use the keyboard. I am a keyboard fan, I just use the mouse when I don't know how to use the program. There could even be an option to hide the menu bar for those who like "aMule Classic".
2) aMule should use tabs to swich the views. Code sucks as a result of not using the proper control at the proper place. Not to mention that the user does not exactly expect that behaviour from buttons.
3) The button to clean downloads is a surprise the first time you click it. But you get used to it. I'd rather have it in a toolbar. Maybe with a broom or a mop icon :P
4) Swiching the upload queue is also in the level of guessing that the program has this feature.
5) Looking at the sources is also a guess that a double click will do something that is not in the right button menu. The mid-button click is also a nice undocumented feature that I use all the time.
6) We rarely use common dialogs where we should, notably to enter file names.
7) The "network" windows is a mess, it mixes servers with networks and application logs. A single connect button is not very appropriate if we have two different networks to connect. Enabling or disabling a network should be in this window, not on "preferences".
8) Preference windows should have buttons to restore sane defaults
9) And I could go on and on...

aMule/eMule are *very* complex applications. And there has always been programmers that help and/or join the team doing the most amazing things. But where are the programmers that do GUI? In my oppinion, we do not receive many interface contributions from the community because to change aMule interface you need wxDesigner. And in spite of the kindness of the author of the program to give aMule developers a license, the program is not free, so it is not like anyone with an idea can help.

So, yes, I would like to change aMule. But how are we going to prototype? I have real life issues, I can't keep showing a lot of ideas that people can criticize and improove. It will be a long way, but in my oppinion we will have to switch toolkit if we want to go one step ahead. And the only reasonable option I see is QT, a trully multiplatform toolkit with a nice interface designer that could be used to prototype the interface way before its core has been written. Then we could start receiving contributions in that area.

aMule 2.2.0 is delayed. And guess what is the problem? GUI bugs on windows and Mac. How come??? GUI is delaying the app? With so many other complex things to go wrong, aMule core works perfectly, most problems are with the GUI.

We need help folks. We have our lives. We have to find a way to increase the community participation in the development of the application. Otherwise, aMule will fade.
Title: Re: A new look for aMule 2.2.0
Post by: skolnick on November 20, 2007, 04:17:58 AM
aMule is a complex application. It can be customized to work on many different environments. Its options allow it to work equally well on slow connections as on very fast connections, and on either cheap routers or good hardware, it has to have all the options so it can do its job properly. If you don't want to learn how to configure it, then it's your problem. Then go and find some peer to peer software that let you get all you want just by double clicking on it. I am sure all your software is simply plug and play, and it guesses all the options you need, and it works just out of the box without you touching anything. However aMule is not that kind of software, because internet connections and computers and network topologies are things that can have very different setups and aMule is supposed to be able to work on any of them. And just to inform you of some things: UPnP cannot be "hidden" because there are networks where it would either not work, or produce som misconfigurations. And I am one of the user of the "do not connect at startup option". Do not ask why, I simply need it to be there. And I am 100% with Kry, that stupid mentality of "let's assume what the user wants" is what makes some software useless for me, particularly gnome. And sorry about the aMule interface not being "centered" on a tab, or having "useless" options. I am pretty sure you can develop a software that does the same as aMule, with only an on/off switch and a search box (and obviously "centered" on it).

Regards.
Title: Re: A new look for aMule 2.2.0
Post by: Kry on November 20, 2007, 05:22:23 AM
phoenix, you're falling int the "But, if we were using QT, we would have no problems!" when the reality is, we would ahve different problems. That's just displacing blame. The bugs are not only not just GUI, but also quite probably our fault.\, not wxWidget's. And no, wxDesigner is not the problem in this case either, because no external coder will change the gui, only maybe propose changes to it. Can you imagine a complete revault of the GUI patch? Some of the things you propose might be valid and possible, but they're also trivial to implement and you can change them as much as I do.

Just saying.
Title: Re: A new look for aMule 2.2.0
Post by: lfroen on November 20, 2007, 07:28:22 AM
Quote
Well, it seems to me that you are talking about different things and both sides are not hearing the other.
That's because you're talking about things from two different perspectives. Kry, for instance, fail to see that from usability point of view, aMule interface is crap. On the other hand, brainnolo fails to comprehend, that even user have to have some idea about how application works. For example, every one knows, that Word save your text in file with '.doc' extension. Same way, every aMule/eMule user have to get an idea what is that stupid server list is about.

Quote
I totally agree with Kry: the gnome way is stupid
Reality seems to be different - a hole lot of people think that Gnome way is OK. I'm using Gnome at home and see no problem with their approach.

Quote
I agree with brainolo that aMule interface is bad. It is a copy of eMule, which is originally bad.
You messing cause and effect. aMule interface is bad, but similarity with eMule is good. It is widely accepted as most common p2p application. If you're about to redesign interface you've got two choices: either make it extraordinary good, or make it like something people already know.

Quote
Usability has nothing to do with configuration options
Absolutely. Nobody forces users to press "Preferences" button, given sane defaults. On the other hand, I have almost no complains about preferences GUI design. It is way better that other areas.

Quote
1) There should be a menu interface.
Agree.

Quote
2) aMule should use tabs to switch the views.
No. The hole idea here is broken. Have you seen Winamp interface? They're using docked windows where aMule using views. That's just an idea. Don't be trapped inside "we have X views, let's find out how to switch between them".

Quote
5) Looking at the sources is also a guess that a double click will do something that is not in the right button menu.
Why not in separate non-modal window? Why messing availability per-source with rest of files?

Quote
7) The "network" windows is a mess, it mixes servers with networks and application logs.
You so right. I never understand WTF log doing in network window.

Quote
And the only reasonable option I see is QT
After aMule 2.2.0 I will evaluate an efforts required for porting core.

Few words to skolnick:
Quote
that stupid mentality of "let's assume what the user wants"
Can you please drop some ignorance? "Assume what the user wants" is the way the whole economy works. If you got your assumptions right - people will be happy to use your product; wrong - and nobody want it. What your argument here? Complex application can't have decent GUI? I disagree, and other people as well.

Quote
phoenix, you're falling int the "But, if we were using QT, we would have no problems!"
Yes, Kry - we will. But we will not have problem of people that can't contribute to Open Source project due lack of license to development tool.
wxDesigner is a disaster. I would better prototype GUI in Power Point and than code it manually in C++ instead.
Title: Re: A new look for aMule 2.2.0
Post by: Kry on November 20, 2007, 07:43:57 AM
You're free to try and make the move to dialogblocks then.
Title: Re: A new look for aMule 2.2.0
Post by: lfroen on November 20, 2007, 01:49:12 PM
You're free to try and make the move to dialogblocks then.
I have yet to see decent GUI builder for wx. I may check dialogblocks, thow
Title: Re: A new look for aMule 2.2.0
Post by: phoenix on November 20, 2007, 02:06:27 PM
I have nothing against wxDesigner as an application, it does its job very well, but beeing non-free complicates our matters.

As for the object of our previous discussion, I want to add that I am not the gui kind of guy :), so it is true that many of my proposals are trivial, but this is a hobbie to me, and coding gui is not something that motivates me. Even then, I sometimes take the time to fix amulegui :)

As for wxWidgets, it sure has problems, and serious problems in my opinion. A toolkit that behaves differently in different platforms is not what I would call "multiplatform". Remember the OScopeControl problem? And why is GTK imune to the bugs we have today puzzles me.

I know, QT would certainly introduce other problems, it is not perfect. But the Trolls are accessible and sensible to your complaints. As sensible as a Troll can be :)

Cheers!
Title: Re: A new look for aMule 2.2.0
Post by: wuischke on November 20, 2007, 02:33:01 PM
One: Our current focus is a new icon set and that's the actual purpose of the thread. Please don't forget this.

Two: What's the point in moving from one proprietary GUI designer to another? If you want to move, please use at least an open file format, like (Kry, don't laugh) XRC. AFAIK, both wxDesigner and DialogBlocks get along with XRC and there are couple of free (wxGlade, XRCed) tools to edit these files as well, although they are not that good...

Frankly, I like the idea of using a core-gui model and I think this should be where we are heading. We already have a working core, now it's only a matter of good GUIs to go further down that path. And we don't even have to rewrite the whole application nor to change the toolkit.

Title: Re: A new look for aMule 2.2.0
Post by: phoenix on November 20, 2007, 02:48:00 PM
QT Designer is not proprietary. It is open source and fully functional without a license. Since version 4, even on windows. And the data file is XML, pure text.

I also like the idea of core/gui separation. But if we really had this separation, core would not need a toolkit. Ok, maybe for sockets, though I believe windows now supports decent sockets, not that WSAsync bullshit.

I vote for a core free of wx. Then anyone could code the GUI in whatever language and toolkit you want. That is why "External Connections Protocol" needs attention.
Title: Re: A new look for aMule 2.2.0
Post by: lfroen on November 20, 2007, 03:03:29 PM
Quote
core would not need a toolkit
Oh, really? Wait for it ...
Quote
Ok, maybe for sockets
And strings. And file access. And threads. And process start/stop. And interlocking. And .... The point is that either you're using toolkit which support all those things on all platforms or you're gonna build one yourself. Which I find quite useless idea. No need to re-invent the wheel.

Quote
That is why "External Connections Protocol" needs attention.
Anything wrong with protocol? What exactly needs attention?

Title: Re: A new look for aMule 2.2.0
Post by: phoenix on November 20, 2007, 04:46:41 PM
Ok, you are right in the sense that to support all platforms a toolkit is much simpler. But :)

Threads and processess are not really a problem. llibUPnP compiles and works in Windows, Mac, Linux, and other stuff, and they use no toolkit, just pthread support.

Strings could be a problem because std::wstring uses wchar_t, which is not guaranteed to be 32 bits. But again, in any of these platforms is wchar_t different from 32 bits? Look:
Code: [Select]
#include <string>

#include <stdio.h>

int main(void)
{
printf("sizeof (wchar_t) = %zd\n", sizeof (wchar_t));
return 0;
}

output on both x86_64 and i386:
$ g++ -Wall -o t t.cpp
$ ./t
sizeof (wchar_t) = 4
Please, someone test it in windows and Mac.

Filenames are another issue, but we already use a toolkit and filenames are still an issue, so the toolkit hasn't really helped us here.

So, to be quite frank, I do believe you can do it without toolkits. As I said before, there may be some platform dependent code for sockets, but very little. Other than that, we would need a routine to convert UNICODE to and from UTF-8, which is something simple and common.

GUI is a complete different story, I think we both agree here on the importance of a toolkit.

Oh, and I almost forgot, there is nothing wrong with EC. It needs attention because it is incomplete in the sense that aMuleGUI does not have the full functionality of aMule. Not a big deal, this is easy to add nowadays.

Cheers!
Title: Re: A new look for aMule 2.2.0
Post by: apo758 on November 20, 2007, 05:27:43 PM
Do you need PPC Mac, Intel Mac or it's indifferent? On my Mac Intel (32bit) it gives me "sizeof (wchar_t) = 4".
Title: Re: A new look for aMule 2.2.0
Post by: Kry on November 20, 2007, 05:38:44 PM
someone has never used pthreads
Title: Re: A new look for aMule 2.2.0
Post by: wuischke on November 20, 2007, 05:59:18 PM
phoenix: I was talking about wxDesigner and DialogBlocks, which are both closed source.

I don't think that it is a good idea to rewrite the whole core without a toolkit or rather with self-written functions to do the same job. It's too much work with little direct benefit.

I think it would be better to spend the time in the development of remote GUI related code, like e.g. an EC implementation using QT or Python to facilitate the development of a new GUI.

Quote
Anything wrong with protocol? What exactly needs attention?
The documentation. I still have the beginning of an EC implementation in Python on my old PC, which I gave up for a lack of time, because although the code is pretty well commented it is still not trivial to understand and takes quite some time to figure out.
Title: Re: A new look for aMule 2.2.0
Post by: brainnolo on November 20, 2007, 08:27:33 PM
Is not just about preferences, the GUI is bad for  many reasons. What puzzles me is why there is a setting for every damn protocol option and the search is rudimentary with no real option (filter by file type, filter by size) which would be useful for the task one wants to accomplish.

I still believe the wx is not at fault at all, although is not perfect is not really that much worse than Qt or any other toolkit. You cannot be native with any cross-platform tool, maybe you will always look bad on some platform, but you can make the thing usable at least.

However, I'm just empty talking and that's not some real help. If I get to do some work I will post sketches and then we can talk seriously about the matter.
Title: Re: A new look for aMule 2.2.0
Post by: skolnick on November 21, 2007, 02:31:13 AM
What puzzles me is why there is a setting for every damn protocol option and the search is rudimentary with no real option (filter by file type, filter by size) which would be useful for the task one wants to accomplish.
My aMule has such options and more, I just have to click the "Extended parameters" checkbox and they appear. However I have no idea since when is that available. I've always seen it.

Regards.
Title: Re: A new look for aMule 2.2.0
Post by: brainnolo on November 21, 2007, 09:40:07 AM
My aMule has such options and more, I just have to click the "Extended parameters" checkbox and they appear. However I have no idea since when is that available. I've always seen it.

Regards.

That's some way of hiding features! :P
Title: Re: A new look for aMule 2.2.0
Post by: apo758 on November 21, 2007, 09:58:46 AM
I think it's good the way aMule handle search options. You don't need it everytime and when you do you just need a click. This checkbox makes the interface clean but powerful. But it would be good to make aMule remember the last search mode (global, local, kad or file hash).
Title: Re: A new look for aMule 2.2.0
Post by: lfroen on November 21, 2007, 10:59:06 AM
Quote
Anything wrong with protocol? What exactly needs attention?
The documentation. I still have the beginning of an EC implementation in Python on my old PC, which I gave up for a lack of time, because although the code is pretty well commented it is still not trivial to understand and takes quite some time to figure out.
Pleeese, don't be ridiculous. Why ask for things you sure not gonna get? Documentation is one of them. Even very popular open source projects suffer from this very problem. No chance that aMule will be different.


Title: Re: A new look for aMule 2.2.0
Post by: phoenix on November 21, 2007, 12:25:31 PM
It is not ridiculous to ask for documentation. Ok, maybe you won't get it :D

If we are going to do something like libEC, it should have a nice documentation, like any library.

Besides, if we were using doxygen (and we are using doxygen tags in a few places), we would have a good start.

And besides #2, there is already some documentation.

Cheers!
Title: Re: A new look for aMule 2.2.0
Post by: lfroen on November 21, 2007, 01:27:43 PM
If we are going to do something like libEC, it should have a nice documentation, like any library.
I think that yours "like any library" is very precise. Most of open source libraries have bad or non-existing documentation.
Title: Re: A new look for aMule 2.2.0
Post by: EseNoy on November 21, 2007, 07:57:43 PM
Hi, I'm N0y a graphic designer from Spain.

I'm really interested in make that icon-set (I'm actually working  on it).  ;)
I'm triying to desing icons undertandable in any country, and working without text too...
I want to know what kind of style are you looking for.
And would be useful to contact directly with somebody via email so I can send examples and discuss it.

If you are interested, please, have no doubt in contact me.

Salud!!
Title: Re: A new look for aMule 2.2.0
Post by: EseNoy on November 21, 2007, 07:59:25 PM
P.D.: I love rabbits too!!
Title: Re: A new look for aMule 2.2.0
Post by: wuischke on November 21, 2007, 08:06:13 PM
Hi EseNoy,

It's very nice to hear that you are working on a icon set! It's hard to say what kind of style, but I would like to see something fresh and "serious", i.e. no bright colours or funny motives. I like the style of the tango project a lot.

If you need any help or want to discuss something, please contact me. (wuischke@amule.org)

kind regards

P.D. También hablo el Castellano bastante bien y si prefieres, puedes escribirme en Castellano.
Title: Re: A new look for aMule 2.2.0
Post by: Kry on November 21, 2007, 08:53:37 PM
How about a skins subforum?
Title: Re: A new look for aMule 2.2.0
Post by: wuischke on November 22, 2007, 12:11:56 AM
I think this is a good idea. I'll have a look at it tomorrow if you don't do it earlier.
Title: Re: A new look for aMule 2.2.0
Post by: asamule on November 28, 2007, 04:06:29 PM
There are too many useless options. A real interface redesign comes at a cost: reduced feature set, at least initially (main candidates imho are chat, messages and stats).
Except that I actually use stats, and messages.
Quote
As far as preferences go, is there any reason for which I shouldn't want to automatically connect at startup, reconnect after connection is lost?
Yes there sure is. Sometimes you just want check things without talking to the outside world, and if your connection goes down because aMule killed it, you don't always want it to reconnect again.
Quote
Why should I want to disable one of the possible networks?
Because comcast freaks out if I enable Kad, and some people don't like ED2K.
Quote
Heck do I really need to know about UPnP? it is meant to be transparent! (if you *really* want to keep the option at least label it something like "Bypass Router/Firewalls") .
And if you handle your own firewall? You don't always want aMule to use UPnP - or perhaps you want to be firewalled.
Quote
Do we really need separate download/upload settings for stats and limiting?
Of course you do, do you know anyone who has a symmetric connection?
Quote
What is slot allocation? there is no help for that.
Ok, that one doesn't do much.
Quote
Did anybody ever change ports or maximum file limits (and if you do, do you get any real advantage?).
I did.
Quote
Here we could remove entire PANES of options, relabel a few more and stop cloning eMule. I really think I could go on forever, given the interface looks like it is designed to test features and not to be used.
No, you can't. It's clear you don't use any of the advanced settings, but that doesn't mean no one does.

Try again - this time without removing ANY of the settings, just clearing them up and organizing them. Tell yourself: just because I don't use it/know what it is doesn't mean no one does.
Title: Re: A new look for aMule 2.2.0
Post by: tekwyzrd on December 09, 2007, 06:30:28 PM
Either you use gnome or MacOS. Either way, we like flexibility in the options we present to the user, and as much control over the features as possible. If you don't understand an option or won;t use it, fine by me, just don't use it. But don't prevent other people from ahving the possibility to use it just because you see no need for it. The whole "let's dumb down the interface as much as posisble and make assumptions about what people want" gnome-like mentality is, for me and for most people I know, wrong on so many levels.

Most, if not all, of the options you mention are not only used daily by most people, but some are essential to the program usage. Ignorance about how the program works is not an exuse to contest the existance of such options.

I'm always for finding better default values, but never for removing the possibility for the user to tweak the program at his/her will.

I agree wholeheartedly. I refuse to us gnome due to the fact that the devs insist on making decisions for me and have decided that I'm too dumb to understand any more than the simplest of options. Unfortunately kde has decided to follow this path as well. "Simplification" only benefits those too lazy to take time to learn and is a major insult to those who DO take the time to learn.

(aimed at the pro-simplification crowd about software in general) If a program is too complicated for you to use  go find another program that does the same thing. Don't complain when the fact is YOU CHOSE to use the program. I am tired of the attitude "I don't use it so it's not useful" and "I don't understand this option so it should be removed". To those people I say QUIT CRIPPLING MY SOFTWARE!

For aMule, one possible solution would be to do as boinc devs did and offer a choice of gui. Offer users the ability to select a simplified interface (for those complaining "Oh no... this is too confusing!") and an advanced interface (for those who want all of the options available).
Title: Re: A new look for aMule 2.2.0
Post by: rufus on December 14, 2007, 06:47:54 PM
It is evident that the gui is (still) a sore point.
May I suggest (again) to privilege function than form?

There are various applications that go straight to the point with their GUI,
avoiding clutter of any kind, which also saves a lot of time both when making
it and maintaining it. The following is just an example:

http://cabos.sourceforge.jp/
Title: Re: A new look for aMule 2.2.0
Post by: Padre Quevedo on December 16, 2007, 05:07:41 AM
I don't care about GUI design.Just make aMule good for Leopard.I promise my cat won't eat your mule.The only thing my cat doesn't like are bugs...
Title: Re: A new look for aMule 2.2.0
Post by: skolnick on December 19, 2007, 01:40:19 AM
It is evident that the gui is (still) a sore point.
May I suggest (again) to privilege function than form?

There are various applications that go straight to the point with their GUI,
avoiding clutter of any kind, which also saves a lot of time both when making
it and maintaining it. The following is just an example:

http://cabos.sourceforge.jp/

Sorry, but that will not happen. That's like you going to General Motors and telling them to remove from their cars the option to adjust the seat, the steering wheel and make them all automatic simply because you don't like complexities and will not learn how to shift gears on a manual gearbox. Most probably General Motors will tell you that their cars are OK the way they are. It's the same with aMule here. Developers will not throw away all their effort developing the lots of useful features aMule has simply because you don't like them or because your MacOS X looks "ugly" with all those buttons and checkboxes.

Regards.
Title: Re: A new look for aMule 2.2.0
Post by: IsA on December 23, 2007, 06:39:54 PM
It is evident that the gui is (still) a sore point.
May I suggest (again) to privilege function than form?

There are various applications that go straight to the point with their GUI,
avoiding clutter of any kind, which also saves a lot of time both when making
it and maintaining it. The following is just an example:

http://cabos.sourceforge.jp/

Sorry, but that will not happen. That's like you going to General Motors and telling them to remove from their cars the option to adjust the seat, the steering wheel and make them all automatic simply because you don't like complexities and will not learn how to shift gears on a manual gearbox. Most probably General Motors will tell you that their cars are OK the way they are. It's the same with aMule here. Developers will not throw away all their effort developing the lots of useful features aMule has simply because you don't like them or because your MacOS X looks "ugly" with all those buttons and checkboxes.

Regards.

On Mac OS X it looks ugly for other reasons. And removing all the less used options is not the only way to have a cleaner look. You can have a single checkbox that  show or hide the advanced settings, it's not a news and it's the only solution for all kind of users.
The reason it looks ugly on Mac OS X has been already said. I don't know if it's due to wxWidgets or other things but why does a native application look so different from a wxWidget application?
And again, why I cannot hide the toolbar? Why I have to close the application if I close the window? On linux is ok, on windows is ok, but on Mac OS it's not! Is it so difficult to change for Mac OS only?

And, really, I don't understand why this thread is here. Every change is not accepted. The only thing that can be changed are (perhaps) toolbar icons.
Title: Re: A new look for aMule 2.2.0
Post by: lfroen on December 24, 2007, 08:39:10 AM
Quote
The reason it looks ugly on Mac OS X has been already said. I don't know if it's due to wxWidgets or other things but why does a native application look so different from a wxWidget application?
Generally speaking, that's con of all cross-platform GUI libs. They looks ~same on all platforms, meaning, that on some platforms this gonna be ugly.

Quote
On linux is ok, on windows is ok, but on Mac OS it's not! Is it so difficult to change for Mac OS only?
No, it is not. However, vast majority of developers does not own Mac. Which means, that even if I completely agree with you on "let's do it as other Mac apps", I can't help. I can assure it works in some consistent way, doesn't randomly crash etc.

Quote
And, really, I don't understand why this thread is here. Every change is not accepted. The only thing that can be changed are (perhaps) toolbar icons.
That's because Mac's are rare. Most of developers doesn't live in US, Macs are expansive. Adding to this OSX which doesn't play well with VMWare we ending with situation when even trivial OSX-specific bugs can't be easy fixed. Except toolbar icons, which can be tested everywhere.

On the good side - I'm working to gen OSX to run on VMWare on my Linux.
Title: Re: A new look for aMule 2.2.0
Post by: wuischke on December 24, 2007, 11:38:46 AM
Quote
And, really, I don't understand why this thread is here. Every change is not accepted. The only thing that can be changed are (perhaps) toolbar icons.
I might have worded it a bit ambiguously, but I was actually only talking about new icons when starting this thread.
Simply because this improves the look of aMule already a lot without requiring too much work.

My vision is a native Mac client on top of amuled to solve this problem, but as most developers I don't own a Mac. (Hey, but I've finally started to use Vista...)
Title: Re: A new look for aMule 2.2.0
Post by: lfroen on December 24, 2007, 12:38:51 PM
Quote
Hey, but I've finally started to use Vista...
Let's not get started here
Title: Re: A new look for aMule 2.2.0
Post by: brainnolo on December 28, 2007, 12:18:14 PM
Quote
Except that I actually use stats, and messages.
You use stats? Is impossible to use stats, you can just stare at them. About messages, they may be useful but is full of spammers out there and is not the main purpose of the app

Quote
Yes there sure is. Sometimes you just want check things without talking to the outside world, and if your connection goes down because aMule killed it, you don't always want it to reconnect again.
aMule shouldn't kill your connection.

Quote
Because comcast freaks out if I enable Kad, and some people don't like ED2K.
You have a point here with the ISP (dislike for a protocol is not), but better solution is to get a decent one.

Quote
And if you handle your own firewall? You don't always want aMule to use UPnP - or perhaps you want to be firewalled.
I don't understand the problem. I didn't say that UPnP is required. If it finds a suitable UPnP device it works, otherwise you are left configuring your firewall. All it should do is report "firewalled"

Quote
Of course you do, do you know anyone who has a symmetric connection?
You didn't understand my point, separate download/upload are obviously needed, but separate "stats" and "real" limits are not.

Quote
Did anybody ever change ports or maximum file limits (and if you do, do you get any real advantage?).
And which advantage did you get?


Quote
No, you can't. It's clear you don't use any of the advanced settings, but that doesn't mean no one does.
I do not, yet aMule does its job perfectly. And my setup is not even common (Mac OS X + unbridged AP with dd-wrt). Again, what can it do for you that it doesn't for me?

Quote
Try again - this time without removing ANY of the settings, just clearing them up and organizing them. Tell yourself: just because I don't use it/know what it is doesn't mean no one does.
I'm sure some settings I'd remove are not useless in all cases and review is needed. But given the huge complexity of the current GUI imho only basic settings should be kept. You can edit the others from amule.conf if you are so in need of "advanced". With time some may be reinserted but with responsability and considering each added option as a big deal.
Title: Re: A new look for aMule 2.2.0
Post by: sneeka2 on December 28, 2007, 01:30:20 PM
Hi,
Sorry to butt in so late in the discussion, but as somebody who has to think about UI design professionally I wanted to weigh in on the whole issue.

First off, yes the aMule GUI is horrible. The non-nativity does play an important role (Mac user here), but there are simply of lot of really bad UI design choices being made as well. For starters, let's compare aMule to another app, Transmission.

(http://img171.imageshack.us/img171/9484/amulecd8.th.png) (http://img171.imageshack.us/my.php?image=amulecd8.png) (http://img257.imageshack.us/img257/4035/transmissionlk4.th.png) (http://img257.imageshack.us/my.php?image=transmissionlk4.png)

In these screenshots, both are doing the same thing: downloading stuff and presenting details about one download. Transmission does so using about 2.5 times less screen real estate. Here a direct comparison:

(http://img166.imageshack.us/img166/5774/amuletrel4.th.png) (http://img166.imageshack.us/my.php?image=amuletrel4.png)

If you go through the details of what information is available in both apps, you'll find that both present very much the same level of detail about what's going on. Transmission actually gives more information: Every currently active download + details about a selected one, while aMule only manages to squeeze one download + details about it into the same space. Lots of clunkyness and wasted real estate on aMule's part here.

(http://img262.imageshack.us/img262/4882/netvq6.th.png) (http://img262.imageshack.us/my.php?image=netvq6.png)

More of it on the network tab. Why two ED2k/Kad tabs? Why a huge, pretty useless graph on the Kad tab? The actually usable part of the Kad tab is so tiny, it could easily be put next to the server list. Why a separate ED2k Info/Server Info/Kad Info, all of which contain lots of free space (and the server info mostly spam messages)? The log would be entirely unnecessary for 95% of the users, if the other three tabs would present the contained information in a more orderly fashion. After all, the only purpose of these tabs is to let the user know whether he's connected or not, plus a few statistical details. But as it is, the information is all over the place in tiny bits and pieces, plus partially redundant in the status bar at the bottom.

Then there are the real usability issues like Global vs. Kad search. If I want to make sure I got every possible search result, I have to perform two searches. That's something the computer should do for me. Where's the "Search everywhere" option?

What struck me most in this thread is the hostility and ignorance of (some) of the main developers towards GUIs. I agree that users should familiarize themselves with the tools they're using, but that does not mean that everyone CAN do that. Fact is that aMule lives of the people using it (the ed2k network). Another fact is that only a tiny percentage of users will ever fully understand how it works. That's mainly you guys and a handful of technically minded people. If 90% of your users need a manual or and explanation for every other thing in the GUI, maybe it's just a bad GUI. If you don't get this, you shouldn't make GUIs. If aMule would be my creation, I'd take some more pride in my work and make sure it's as polished as possible. Sending people away with "If you don't get it, don't use it" is simply a lazy answer. Also, I do GET aMule. I'd love to use it more. I was a big eMule fan back when I had the luxury of a dedicated Windows machine in my old apartment. But now I just avoid using it unless absolutely necessary, because it's mainly a pain in the butt.

You first need to realize that you have a problem... Seeing the "official" reactions I think aMule will unfortunately continue to be a mediocre app.

Best Regards.

EDIT: Forgot to rebut a common rebuttal in this thread: making a better UI doesn't mean dumbing it down. A GUI can be more usable, even for "novices", without loosing functionality or information! It's a matter of striking the right balance.
Title: Re: A new look for aMule 2.2.0
Post by: wuischke on December 28, 2007, 02:12:14 PM
sneeka2: You say you are doing this professionally. Imho we should have a dedicated Mac remote GUI, if you would be willing to put some work in the design, I would appreciate this a lot.
Don't worry about the communication with aMule[d] (for now), just create a concept GUI, if you have the time.
Title: Re: A new look for aMule 2.2.0
Post by: sneeka2 on December 28, 2007, 02:20:37 PM
sneeka2: You say you are doing this professionally. Imho we should have a dedicated Mac remote GUI, if you would be willing to put some work in the design, I would appreciate this a lot.
Don't worry about the communication with aMule[d] (for now), just create a concept GUI, if you have the time.

I wouldn't mind to, actually. ;D
Having said that, I could only provide screenshots/mockups and guidelines, somebody else would have to code it.

Sent you a private message, let's email about it.
Title: Re: A new look for aMule 2.2.0
Post by: IsA on December 28, 2007, 03:00:32 PM
Imho we should have a dedicated Mac remote GUI

I agree, it seems the only way to have something prettier.
Just for curiosity, why is aMule so monolithic? Other apps like Pidgin are made by a library (libpurple) and a lot of other things. This allow everyone to code a native application. Adium uses libpurple and it's great. Why doesn't libmule exist?
Title: Re: A new look for aMule 2.2.0
Post by: Kry on December 28, 2007, 10:53:25 PM
First off, yes the aMule GUI is horrible.

Bad start.

The non-nativity does play an important role (Mac user here), but there are simply of lot of really bad UI design choices being made as well.

I am still curious about the non-nativity. What's the problem exactly? aMule uses wxWidgets, and wxWidgets use carbon/cocoa for the widgets.

For starters, let's compare aMule to another app, Transmission.

Sure

(screenshots)
(http://img171.imageshack.us/img171/9484/amulecd8.th.png) (http://img171.imageshack.us/my.php?image=amulecd8.png) (http://img257.imageshack.us/img257/4035/transmissionlk4.th.png) (http://img257.imageshack.us/my.php?image=transmissionlk4.png)

In these screenshots, both are doing the same thing: downloading stuff and presenting details about one download. Transmission does so using about 2.5 times less screen real estate.

You're forgetting aMule is showing space to hold 14 (FOURTEEN) downloads in the space Trnsmission is showing only 4 (FOUR(\) downloads. Vertical space is way less than horizontal space in EVERY monitor out there, and even worse now with the dawn of mainstream widescreen . So, in your screenshots, amule is showing a lot more downloads, and a lot more info per download. Transmission has a different window for peers, and amule can expand them in the same list. I like the aMule design, because I dislike applications that open 300 (THREE HUNDRED) windows to show me things. aMule is a file sharing program, not a peer inspection one, and as a file sharing program is presents not only more information per download, but also 250% (TWO HUNDRED AND FIFTY PERCENT) more downloads in the same space. Optimization for the main goal of the application is a must. You can even remove or resize the columns to your liking to present more or less information per download and take less horizontal space if needed. Can you remove the extra information on Transmission? Hint: You can't (!can).

I'm glad that you're such a big guy on the gui design business, but you need to rethink your approach to presenting information to the user, and apply it to the current users' possibilities and space.

If you go through the details of what information is available in both apps, you'll find that both present very much the same level of detail about what's going on. Transmission actually gives more information: Every currently active download + details about a selected one, while aMule only manages to squeeze one download + details about it into the same space. Lots of clunkyness and wasted real estate on aMule's part here.

Read above. Also, let's take a look about the file presentation on Transmission. What do you need a gigantic folder icon on the left for every file? Why is the icon under it (and what does it do anyway?) on the left, when other action icons for this file are on the right? You call this good GUI design, I'll begin to understand why I have to go through 12 (TWELVE) windows and scroll down 4 times to look for some info on some applications. People like you are the cancer that is killing the computer world.

(http://img262.imageshack.us/img262/4882/netvq6.th.png) (http://img262.imageshack.us/my.php?image=netvq6.png)
More of it on the network tab. Why two ED2k/Kad tabs?

Hint: they are different networks, with different capabilities, structure, and basis. So they are kept separated.

Why a huge, pretty useless graph on the Kad tab?

I am sorry, where is the useless graph? What I see there is a graph of the peers you have on the decentralized kad network, which helps a lot people on this forum looking for help, as they see that they lose kad contacts over time or other things. Why would I want to remove it from there? Does it not let you sleep at night? Do you have the compulsion of getting up at 2am to look at the graphic, which you have to ACTIVELY look for in the app by clicking the Kad tab on the Networks section, and feel so useles it is? When you buy a TV, do you feel like opening it and checking the circuit boards and complain that they are not covered by black fabric instead of being so complicated?


The actually usable part of the Kad tab is so tiny, it could easily be put next to the server list.

I like how you want to simplify the GUI design by mashing together two completely different parts of the application into a single window. Some people use the kad network, some people use the ed2k network, some people use both. I don't want to waste space on eithr of them with information from the other, because THEN it would be useless for users that only want to use one of them.

Why a separate ED2k Info/Server Info/Kad Info, all of which contain lots of free space (and the server info mostly spam messages)? The log would be entirely unnecessary for 95% of the users, if the other three tabs would present the contained information in a more orderly fashion.

Would it now? So, where are you going to put the information about EC if you get rid of the log? I only agree on something here: the ED2k and Kad network tabs can hold the information from the ED2K and KAd info tabs, but then again, we already have a log text and a server info text tabs, so why clutter the upper part with information we can put on the bottom one? The server info is not redundant: as much as it sends spam, the servers send that information and we have to show it, because they are providing a FREE service to you and all other users, so the least we could do is sho their advertising messages, on a tiny log on some place of the app. Beats having google adds everywhere on the main GUI or making a paid software application, don't you think?

After all, the only purpose of these tabs is to let the user know whether he's connected or not, plus a few statistical details. But as it is, the information is all over the place in tiny bits and pieces, plus partially redundant in the status bar at the bottom.

Redundant? The status bar is to show the status of the app at first glance, from all parts of it. Then you can check the details on every specific section. Just because something is in two places it doesn;t mean it's redundant. Just because you can add the speed of your downloads it doesn't mean you must remove the global speed, either.

Then there are the real usability issues like Global vs. Kad search. If I want to make sure I got every possible search result, I have to perform two searches. That's something the computer should do for me. Where's the "Search everywhere" option?

Nowhere. Because they are DIFFERENT NETWORKS, with DIFFERENT CAPABILITIES, DIFFERENT RESULTS, DIFFERENT SEARCH TIMES, and DIFFERENT RESULTS, which people can use SEPARATELY.

What struck me most in this thread is the hostility and ignorance of (some) of the main developers towards GUIs.

What struck me most on this thread is the ignorance of a self proclaimed GUI expert in, you know, usability and information display.

I agree that users should familiarize themselves with the tools they're using, but that does not mean that everyone CAN do that.

Cool. It works fine out of the box.

If 90% of your users need a manual or and explanation for every other thing in the GUI, maybe it's just a bad GUI.

If anyone needs must help having a SEARCH section, a SERVERS tab with a url they can get servers from in one click, and a DOWNLOADS tab where they can see their downloads, then I'm sorry but no dumbed down version of the app will help them.

If you don't get this, you shouldn't make GUIs.

Funny how you don't know what I do for a living[/quote].

If aMule would be my creation, I'd take some more pride in my work and make sure it's as polished as possible.

Where is it not polished? It has every advance and fine tune option you can find in this network, and it works out of the box[/quote]. It may need more "out of the box" improvements, maybe a first-time wizard, but man, what it doesn't need is to dumb it down. I take pride in how COMPLETE it is.

Sending people away with "If you don't get it, don't use it" is simply a lazy answer. Also, I do GET aMule. I'd love to use it more. I was a big eMule fan back when I had the luxury of a dedicated Windows machine in my old apartment. But now I just avoid using it unless absolutely necessary, because it's mainly a pain in the butt.

Why, doesn't it work without you clicking 200 (TWO HUNDRED) buttons every time?

You first need to realize that you have a problem... Seeing the "official" reactions I think aMule will unfortunately continue to be a mediocre app.

Ok, if we're going to go with insults, I might as well say that ur mum is mediocre.

EDIT: Forgot to rebut a common rebuttal in this thread: making a better UI doesn't mean dumbing it down. A GUI can be more usable, even for "novices", without loosing functionality or information! It's a matter of striking the right balance.

Sure, but so far you want to dumb it down in your proposals, or make it either show less information or mix apples with oranges. So you're pretty useless when it comes to improvement.
Title: Re: A new look for aMule 2.2.0
Post by: sneeka2 on December 29, 2007, 08:20:30 AM
...ignorance of a self proclaimed GUI expert...
Funny how you don't know what I do for a living.

Oh listen to you, now you're a self proclaimed GUI expert as well, aren't you? Welcome to the club.


I am still curious about the non-nativity. What's the problem exactly? aMule uses wxWidgets, and wxWidgets use carbon/cocoa for the widgets.

There are loads of elements that just look out-of-place on a Mac. It's not about whether it's technically using native widgets or not, it's about whether these widgets are placed where they're supposed to be and sized how they're supposed to be and look how you'd expect them to. The wxWidgets you're using may be translated to something near-native or really native looking on other OSes, they don't on the Mac. Spacing, position, different button types are off in many cases.


You're forgetting aMule is showing space to hold 14 (FOURTEEN) downloads in the space Trnsmission is showing only 4 (FOUR(\) downloads. Vertical space is way less than horizontal space in EVERY monitor out there, and even worse now with the dawn of mainstream widescreen . So, in your screenshots, amule is showing a lot more downloads, and a lot more info per download. Transmission has a different window for peers, and amule can expand them in the same list. I like the aMule design, because I dislike applications that open 300 (THREE HUNDRED) windows to show me things. aMule is a file sharing program, not a peer inspection one, and as a file sharing program is presents not only more information per download, but also 250% (TWO HUNDRED AND FIFTY PERCENT) more downloads in the same space. Optimization for the main goal of the application is a must. You can even remove or resize the columns to your liking to present more or less information per download and take less horizontal space if needed. Can you remove the extra information on Transmission? Hint: You can't (!can).

It's kind of hard to take this paragraph seriously with all the useless exaggerations in there. First, I never said Transmission is perfect and that aMule should look like Transmission. I don't really like the floating window either, but it's getting the job done quite well, and the overall GUI of Transmission is a lot tighter and more streamlined than aMule's.

Second, you can switch Transmission into a minimal view, which takes only one line per download as well.

Third, yes you got the part about horizontal vs. vertical space right. Why then is aMule wasting three entire columns of horizontal space?

(http://img257.imageshack.us/img257/7140/amulewasteuq2.th.png) (http://img257.imageshack.us/my.php?image=amulewasteuq2.png)

Why is it squeezing two different kinds of information into the limited vertical axis instead of displaying them side-by-side. You know, there's more horizontal space than vertical.


Read above. Also, let's take a look about the file presentation on Transmission. What do you need a gigantic folder icon on the left for every file? Why is the icon under it (and what does it do anyway?) on the left, when other action icons for this file are on the right? You call this good GUI design, I'll begin to understand why I have to go through 12 (TWELVE) windows and scroll down 4 times to look for some info on some applications. People like you are the cancer that is killing the computer world.

The ginormous file type icon serves as a quick visual identifier of what file type you're downloading. In this case all of them are a folders full of stuff, so yeah, it doesn't look very distinct. If you switch to minimal view it takes up the same space as the peer icon in aMule.

I don't really feel like defending Transmissions interface though, because I didn't make it and as I said before, I don't think it's perfect either, but it's a lot better in many points.

Which TWELVE windows and 4 (FOUR) scrolls are you taking about? Don't lose track of the topic please. And you're the cancer that is killing /b/, so there. :P

With that out of the way, trying to find out every information about my connection status in aMule DOES take about 6 (SIX) clicks and some scrolling.

Hint: they are different networks, with different capabilities, structure, and basis. So they are kept separated.

Hint: They're both just different means to the same end: finding and downloading files. You can present them on the same screen without risk of confusing them. If you can't figure out how, cancer, /b/, etc.

If they're so special and separate, what are they doing together in the same app? Why not two different download lists for each then? Oh wait, aMule uses BOTH to find peers for the SAME files! Why a separate search option then? There's NO distinction in presentation whatsoever between a Kad search and an ED2k search, except that I can't execute both at the same time. If you can't figure out how to populate the same list with results from two different networks: cancer, /b/, etc.

I am sorry, where is the useless graph? What I see there is a graph of the peers you have on the decentralized kad network, which helps a lot people on this forum looking for help, as they see that they lose kad contacts over time or other things. Why would I want to remove it from there? Does it not let you sleep at night? Do you have the compulsion of getting up at 2am to look at the graphic, which you have to ACTIVELY look for in the app by clicking the Kad tab on the Networks section, and feel so useles it is? When you buy a TV, do you feel like opening it and checking the circuit boards and complain that they are not covered by black fabric instead of being so complicated?

You're getting sidetracked again with analogies. The graph is simply too HUGE. There's no need for it to take up this amount of space. Make it smaller, put the server list and the Kad connect interface on the same page and I wouldn't need to click back and forth between the two.


I like how you want to simplify the GUI design by mashing together two completely different parts of the application into a single window. Some people use the kad network, some people use the ed2k network, some people use both. I don't want to waste space on eithr of them with information from the other, because THEN it would be useless for users that only want to use one of them.

How many people actually CARE which one they use? They're both just different means to the same end. I prefer to use both, because it helps me find all the available peers for my downloads. And I dare say that's what most people are mainly interested in as well. And using both is being complicated by the fact that I have to switch back and forth between them.


Would it now? So, where are you going to put the information about EC if you get rid of the log? I only agree on something here: the ED2k and Kad network tabs can hold the information from the ED2K and KAd info tabs, but then again, we already have a log text and a server info text tabs, so why clutter the upper part with information we can put on the bottom one? The server info is not redundant: as much as it sends spam, the servers send that information and we have to show it, because they are providing a FREE service to you and all other users, so the least we could do is sho their advertising messages, on a tiny log on some place of the app. Beats having google adds everywhere on the main GUI or making a paid software application, don't you think?

The log:

2007-12-29 12:58:23: Connecting to Skin Domination (72.172.89.131 - 72.172.89.131:0)
2007-12-29 12:58:24: Connection attempt to FuckFest101 (72.172.89.137:4661) timed out.
2007-12-29 12:58:24: Servers: Trying to connect
2007-12-29 12:58:25: Connecting to Donkey bad BeAts You No2 (72.172.89.143 - 72.172.89.143:0)
2007-12-29 12:58:49: Connection attempt to Skin Domination (72.172.89.131:4661) timed out.
2007-12-29 12:58:49: Servers: Trying to connect
2007-12-29 12:58:50: Connecting to 193.138.231.210 (193.138.231.210 - 193.138.231.210:4242)
2007-12-29 12:58:50: Lost connection to 193.138.231.210 (193.138.231.210:4242)
2007-12-29 12:58:50: Connection lost
2007-12-29 12:58:51: Connection attempt to Donkey bad BeAts You No2 (72.172.89.143:4661) timed out.
2007-12-29 12:58:51: Servers: Trying to connect
2007-12-29 12:58:51: Connecting to SEX & more SEX (66.135.59.149 - 66.135.59.149:4535)
2007-12-29 12:58:51: Connected to SEX & more SEX (66.135.59.149:4535)
2007-12-29 12:58:53: Servers: Connected
2007-12-29 12:58:53: Connection established with: SEX & more SEX
2007-12-29 12:58:53: New client ID is 4139653181
2007-12-29 12:58:53: Received 2 new servers
2007-12-29 12:58:53: Saving of server-list completed.
2007-12-29 13:08:30: Read 186 Kad contacts

Do I really need to know when and how often aMule tried to connect to which server? It's interesting sometimes, but it's debug information. It doesn't need to be that present in the main GUI. My client ID I can get from the ED2k Info tab. "Received x new contacts/servers" is, again, sometimes interesting, but mostly I don't care. The Kad contacts message is redundant with the huge graph anyway. "Saving of server list complete" -- debug info, I expect that to be done by the application, it doesn't have to tell me about it.

The Server message: Sure, have a small scrollable text field for it. It would actually expose the info better than the separate tab it is in now, because almost nobody clicks on it, since it usually doesn't contain anything worth reading.


Redundant? The status bar is to show the status of the app at first glance, from all parts of it. Then you can check the details on every specific section. Just because something is in two places it doesn;t mean it's redundant. Just because you can add the speed of your downloads it doesn't mean you must remove the global speed, either.

Make the status bar the one and only place to display the connection status and do not repeat it in the details section. Voila, space saved without losing functionality. I'd be thinking about moving the status information near the top of the app, where it would also function as the "intro" to the details section when there.


Nowhere. Because they are DIFFERENT NETWORKS, with DIFFERENT CAPABILITIES, DIFFERENT RESULTS, DIFFERENT SEARCH TIMES, and DIFFERENT RESULTS, which people can use SEPARATELY.

DIFFERENT NETWORKS - yes
DIFFERENT CAPABILITIES - err... finding files and peers?
DIFFERENT RESULTS - wrong, largely the same results.
DIFFERENT SEARCH TIMES - so? both take about 20 - 40 seconds for me. and the results list is populating little by little anyway.
DIFFERENT RESULTS - redundancy warning ;-P
which people can use SEPARATELY - correction: HAVE TO USE separately.


Why, doesn't it work without you clicking 200 (TWO HUNDRED) buttons every time?

The button clicking time could be dramatically reduced. Just with some optimization, without dumbing it down or losing anything. If you think (verbosity || power) == number of tabs and buttons: cancer, /b/, etc.


Ok, if we're going to go with insults, I might as well say that ur mum is mediocre.

LOL :D


Sure, but so far you want to dumb it down in your proposals, or make it either show less information or mix apples with oranges. So you're pretty useless when it comes to improvement.

Did I make any proposals in my first post that would show less apples or oranges?
You seem to be pretty useless too, thanks very much.

Regards.
Title: Re: A new look for aMule 2.2.0
Post by: fabtar on December 29, 2007, 12:11:06 PM

DIFFERENT NETWORKS - yes
DIFFERENT CAPABILITIES - err... finding files and peers?
DIFFERENT RESULTS - wrong, largely the same results.
DIFFERENT SEARCH TIMES - so? both take about 20 - 40 seconds for me. and the results list is populating little by little anyway.
DIFFERENT RESULTS - redundancy warning ;-P
which people can use SEPARATELY - correction: HAVE TO USE separately.
MLdonkey performs in this way (kad/server search at same time) and I think that is not right/wrong but  a philosofical choice, I think that Amule's separation between these  searches has a sense in order to spare network resources.
In the case  you have found out a fair number of sources with server search, why do you need to do a kad search too?This could be a waste of precious network resources.
I'm a Mldonkey user, personally I always suggest amule to linux's newbies  thanks to his Emule's Deja vu effect.
I think that emule interface as amule interface (which are similar) are fine/usable and I also think that detailed infos/logs has to be mantained cause they can be simply  ignored by newbies.
Personally I like a p2p project having jet a good/usable interface  which focuses developing resouces in strenghten reliability, fixing bugs, improving network support, optimizing resource usage.
Personally I use my sancho's  GUI interface about 1 time a day for 10 minutes, I don't need a perfect artwork but a reliable piece of software which doesn't  freak out, freezing my old box :-D , I think this is the same for lots of amule's users.
IMHO my cent.
Title: Re: A new look for aMule 2.2.0
Post by: Stu Redman on December 29, 2007, 05:02:42 PM
The aMule GUI layout is fine as it is. Kry, don't waste your time on this.  ::)
Title: Re: A new look for aMule 2.2.0
Post by: Xaignar on December 30, 2007, 03:51:50 PM
Bad start.

The first step is to admit that we have a problem*. ;)
The second step is to get completely wasted. That way, the problem won't seem so bad.


* And we do: The GUI would surely benefit from a shakeup. Which doesn't mean removing features or dumbing it down, it means improving the representation of information, avoiding "hidden" features, make the overall structure more sensible, and not using widgets in entirely novel ways, etc.
Title: Re: A new look for aMule 2.2.0
Post by: skolnick on December 30, 2007, 06:09:34 PM
I also enjoy amule's GUI a lot, but that's maybe because I like a software where I can have control of every aspect of its operation, and I hate software with only two-three stupid options (That's why I prefer KDE over GNOME). Mainly because the assumptions made in the dumbed-down software are not comfortable to me, so I dislike using the software.

Regards.
Title: Re: A new look for aMule 2.2.0
Post by: sup on December 31, 2007, 02:14:38 AM
Kry: I would also appreciate having an option to search kad and global server simulatenously, since I almost always use it together.

Title: Re: A new look for aMule 2.2.0
Post by: lfroen on January 02, 2008, 08:44:14 AM
This discussion went astray. We already have two people claiming to be GUI experts :) Here's my 5cents - if some company those people as GUI experts, may consider to hire me as spokesperson. You see, I know some English, and hey, I can speak.
No offense, Kry, but despite very broken arguments sneeka2 makes, you wrong about some points.

Quote from: Kry
The server info is not redundant: as much as it sends spam, the servers send that information and we have to show it, because they are providing a FREE service to you and all other users, so the least we could do is sho their advertising messages, on a tiny log on some place of the app. Beats having google adds everywhere on the main GUI or making a paid software application, don't you think?
And I think, that aMule is not advertising platform. No bloody way. Application log may serve its purpose, like providing info for troubleshooting purposes, but again - it is not a place for advertising.

Quote from: sneeka2
There are loads of elements that just look out-of-place on a Mac.
So may you please to point to those elements instead of wasting time on useless comparison with Transmission?

Quote from: sneeka2
First, I never said Transmission is perfect and that aMule should look like Transmission. I don't really like the floating window either, but it's getting the job done quite well, and the overall GUI of Transmission is a lot tighter and more streamlined than aMule's.
This one I don't get. Do you think that Transmission is good example or do you not? Can you choose your side, please? If you don't like floating window, WTF do you bring it to this discussion and wasting your and our time?

On different networks:
Quote from: sneeka2
How many people actually CARE which one they use? They're both just different means to the same end. I prefer to use both, because it helps me find all the available peers for my downloads.
Many people (including you it seems) mistakenly thing that aMule (or eMule or other P2P) is download manager. It is not. This is file sharing application. The concept of different networks is very basic one, like concept of "font" in word processing. You've got to know it, that's what this application is about. I don't know how to stress it more.
Same thing about graph and log. The purpose of application is to share files.

Kry definitely right about one thing - aMule's download control is fine. I have seen other implementations of same concept, and aMule/eMule with it's colored status bar is the best I've met.

On the other hand, search and network windows can be reworked.
Title: Re: A new look for aMule 2.2.0
Post by: Xaignar on January 02, 2008, 04:46:14 PM
Kry definitely right about one thing - aMule's download control is fine. I have seen other implementations of same concept, and aMule/eMule with it's colored status bar is the best I've met.
I almost agree with this. :)
The download queue is great for listing the downloads, but IMO it tries to do too much by also listing sources. And those two things really don't go all that well together in the same list.
Title: Re: A new look for aMule 2.2.0
Post by: eisa01 on January 02, 2008, 06:51:55 PM
Ok, here are some things that definitely doesn't look right on the Mac.

1. The box around the selected tab is awful. Check the Coda image to see how a much better solution looks like.
2. The text is not aligned vertically.
3. Maybe some room around these fields, it looks very cramped.
4. What's up with the form and image on this button. It's really out of place.

I'm no GUI expert, so there are surely things that I have missed. This was after looking 1 min at the left corner of the home screen.

edit: I'm pretty sure much of this is caused by limitations in wxWidgets. I wouldn't be surprised that it isn't possible to make a good GUI for the mac with it, that looks native.

One example of this, although not really GUI related, is that they removed the possibility to scroll sideways in wxWidgets apps in one of the recent versions. That worked great before, and for me was a good feature since the UI in aMule tends to show a lot of information in limited horizontal space. Coupled with the fact that every portable mac sold in the last 2 years have had the possibility to scroll sideways with the trackpad, and the mouse that comes with the desktops also have this possibility, this must be on of the most idiotic decisions ever regarding usability and wxWidgets.
Title: Re: A new look for aMule 2.2.0
Post by: Kry on January 02, 2008, 09:20:46 PM
One example of this, although not really GUI related, is that they removed the possibility to scroll sideways in wxWidgets apps in one of the recent versions. That worked great before, and for me was a good feature since the UI in aMule tends to show a lot of information in limited horizontal space. Coupled with the fact that every portable mac sold in the last 2 years have had the possibility to scroll sideways with the trackpad, and the mouse that comes with the desktops also have this possibility, this must be on of the most idiotic decisions ever regarding usability and wxWidgets.

That's, uh, not true. It might be OUR listctrl code having problems.
Title: Re: A new look for aMule 2.2.0
Post by: eisa01 on January 03, 2008, 01:58:55 AM
I read it in a changelog for wxMac.

http://wx.ibaku.net/changelog/?r=2&q=horizontal&qs.x=0&qs.y=0

Might have misunderstood the cause of it, as it wasn't mentioned the first time I read it, but it was disabled as you see.
Title: Re: A new look for aMule 2.2.0
Post by: sneeka2 on January 05, 2008, 08:23:09 AM
Happy new year everyone.

Some points about the GUI have already been made above, a bit more from me:

(http://img244.imageshack.us/img244/7062/networkmk4.th.png) (http://img244.imageshack.us/my.php?image=networkmk4.png)

1) Download server list button: Who would've guessed that this button downloads a server list? The icon doesn't look like it. The type of button is a secondary button, not a primary action. The button comes first in a two-step process (copy-paste, click Download). From the looks of it I'd have guessed the button is used to toggle something or other. It should be a primary push button and say "Download" or signify this action clearly with an icon.

2) Server count is mixed into the list download action, but does not appear in the ED2k Info tab, where I'd rather expect it.

3) The Manual Server Add controls look really squeezed in there. It's somewhat debatable if it needs to be there that prominently. The IP:Port field should be ONE field, for easy copy and paste. The application could easily figure out which part the port is with a standard REGEX. The IP field is too wide anyway, even a 12 digit IP only fills up about half of it. As an aside: Good use of the 'Add' button, that's how 1) should be.

4) Disconnect button looks like it has something to do with the Manual Server Add action, when in fact it does not at all.

5) The Log/Info/ED2k/Kad tabs are a huge space waster, both in the sense that they could be easily combined into one single pane, and that they have too much space above them right now. Also, the tab name is unnecessarily repeated as a headline inside the tab.

6) Reset button just looks out-of-place. Should be a secondary button with a simple icon.

7) Link Handler field shows a scrollbar, pointless on a one-line input. 'Commit' seems like a bad choice of words to me, even 'Enter' would be better. As an aside: doesn't resize correctly past a certain limit.

Apart from the above points, the ED2k/Kad list container should have both some more internal and external spacing.

(http://img244.imageshack.us/img244/3506/kadwb6.th.png) (http://img244.imageshack.us/my.php?image=kadwb6.png)

I've complained about the Kad tab before, here some more:

1) IP/Port field: again, make it one field for easy copy and paste. Currently it even allows input of more than three characters per field, even non-numeric characters. Port field is way too big for a typically 4 digit value.

2) Bootstrap and Disconnect button. Correct me on the technical details here, but Bootstrap doesn't appear to be doing much when Kad is up and running, and Disconnect doesn't do anything when already disconnected. Combine this into a single Connect/Disconnect button. Furthermore, the Bootstrap button is, again, secondary and appears to be for something completely different than the Disconnect primary push button. Also, bootstrapping may be the appropriate technical term for what's going on behind the scenes, but if you're looking for a Connect button it's a very unhelpful choice of words.

Also, more spacing issues between containers.

Most of the other views are arguably not quite as bad as the network tab, but most exhibit some form or other of spacing issues or sub-optimal choice of button types or labels.

My only point about Transmission was that it is possible to present very much the same amount of information using a lot less screen real estate. I did not suggest the use of a floating window or anything similar, nor did I want to reduce aMule to a download manager. I only spoke about the pixels used to present ongoing download and peer information. Something else that Transmission does very well though is prioritising information. When looking at the Transmission window, it's very easy and quick to tell which download progressed how far. It's somewhat harder in aMule since there are a lot of columns with many similar numbers, all using the same font size and colour, and even the status bar is somewhat hard to read at one glance (I DO like the parts display though, before I get flamed on this). Distinguishing between "primary" and "secondary" information visually can go a long way in cleaning up an interface, without losing any information.
Title: Re: A new look for aMule 2.2.0
Post by: lfroen on January 05, 2008, 02:04:31 PM
I have to agree all are valid points. All should be fixed. I would ask you to post a patch, but given the fact, that aMule uses wxDesigner it's impossible.
I'm working on .NET based remote gui and will take your complains to my attention.
Title: Re: A new look for aMule 2.2.0
Post by: sneeka2 on January 05, 2008, 02:25:43 PM
I'm already working on some mockups, but they're more of a complete redesign and optimisation of the whole interface, rather than single complaints. I already sent a first sketch to wuischke and he wants to handle the propagation it seems. Writing patches will indeed be next to impossible for me.
Title: Re: A new look for aMule 2.2.0
Post by: lfroen on January 05, 2008, 08:29:42 PM
please send it to me too. or post it here
Title: Re: A new look for aMule 2.2.0
Post by: wuischke on January 05, 2008, 09:31:05 PM
Here you go. Once I were finished with my Italian verbs (Did I ever mention how I don't like C?) and the extension of the skin code, I wanted to do some tests based upon this mockup with our current wx based GUI. (I got a wxDesigner license after all.)

I think that splitting the upper part in a section each for ed2k and kad is a really great idea. I'm not sure about the buttons to bootstrap / add a nodes.dat file, I think I would try to solve this differently.

Making the server list hidable is a nice thing, too.  Compare it to our current search dialog, but in contrast to the search dialog it is pretty obvious that and how you can expand the information. On a side note: a global search bar is a really cool feature.

The biggest problem for me is the log view. (There was some discussion some time ago about separating log and debug log as well, iirc). sneeka's mockup isn't designed to fit into our tabs, but is a bit like a "pull down window", if I understood this Mac OS X component correctly and thus it doesn't consider the log view.

Quote
Here a first sketch. I started with the network view, as that is what irks me most in the current GUI.
I'm still torn about the rest of the app. On one hand it makes sense to continue the "tabbed" View model, but I'd rather go for a different approach. In that case it'd make sense to implement the network view as a sheet on OS X, but I'm not sure how well that translates to other OSs (not sure how much Mac experience you have, look under "Window modal" here for a sheet example: http://www.answers.com/topic/dialog-box ).

In this first sketch you can already see several points I'm focusing on: No more tabs whenever possible, still a lot of information, but only always what's needed and always in the right place, a way to
simplify views (hiding of the server list) but easy switching to advanced views. Again, some of these are Mac specific strengths (the 'disclosure triangle' above the server list grows and shrinks the window) which I'm not too sure how to realize on other OSs, but that's gonna be later.
Title: Re: A new look for aMule 2.2.0
Post by: Kry on January 05, 2008, 10:11:57 PM
A 200x166 screenshot shows nothing at all.

About splitting in ed2k and Kad, I refer you to my previous post, wher eI pointed out that that forces wasted space for people using only one network. I have no idea what you mean for "a global search bar".

Title: Re: A new look for aMule 2.2.0
Post by: wuischke on January 05, 2008, 10:18:50 PM
Quote
A 200x166 screenshot shows nothing at all.
My bad, I saved the thumbnail instead of the real image.

Compare the global searchbar to what every browser nowadays has - a quick search. You type something in this field and you get a new tab with the search results. Only that we switch to the search window and show the search results after starting a search.
But I don't think this will fit our current GUI very well.
Title: Re: A new look for aMule 2.2.0
Post by: Kry on January 05, 2008, 10:26:52 PM
Don't think so either. My previous criticism stands: the ed2k server list, as much as you may want to hide it (why would anyone do that? to make the GUI smaller? What about the other sections of the app? would hiding the servers list make them smaller as well? We need a fixed main gui size to hold all components, so hiding things we have plenty of space for makes no sense - we have no dynamic PAGES, only dynamic component on pages to expand other components, and in this case no component would be expanded), is mixed with kad for NO reason, and kad or ed2k are shown when you only are interested in one network, which lots of people do.

I see no advantage over the current design. The current design could be improved on the networks section, but this is not the proper way to do it.
Title: Re: A new look for aMule 2.2.0
Post by: sneeka2 on January 06, 2008, 07:04:43 AM
I see no advantage over the current design.

No advantage whatsoever?! What about the current design having 28 clickable elements in the network tab, whereas this first mockup has 9*, offering the exact same settings?

*) plus one button in the menu bar for the link handler (not yet in the mockup), I counted that too.

As for why you'd want to hide the server list: you usually don't need it. I find a majority of the servers in that list are next to impossible to connect to, so aMule is usually going through the list by itself anyway. If you are interested in the list, it's only one click away and stays open forever.

As to how to implement it: As said above, on OS X it would make a lot of sense to implement it as a window-modal sheet dialog. It's perfect for a network dashboard like this. Also as noted above, this is a very Mac-centric design for now. How to realise it cross-platform is a problem for another day.

PS: I already have ideas for improvement of this first mockup, nothing final yet.
I'm very interested in other's opinions about the ED2k/Kad separation. I see no reason to keep them the way they are. If you want to ignore Kad, you are still perfectly free to do so. It does not in any way interfere with your usage of ED2k. In the current design you'll still have to ignore the Kad tabs on the network interface, the Kad entries in the status bar, the Kad entry in the Search dialog and the Kad entry in the Preferences. I fail to see how including Kad next to ED2k in the network tab is any worse.
Title: Re: A new look for aMule 2.2.0
Post by: lfroen on January 06, 2008, 10:07:02 AM
Quote
Here a first sketch. I started with the network view, as that is what irks me most in the current GUI.
No problem, start wherever you want, but let me note, that "Network" is most rare used page. "Downloads" and "Search" are.

Quote
I have no idea what you mean for "a global search bar".
Agree. WTF search doing here?
Quote
You type something in this field and you get a new tab with the search results.
But WHY show it globally? What you gonna search in "Network" window?!

Quote
No advantage whatsoever?! What about the current design having 28 clickable elements in the network tab, whereas this first mockup has 9*, offering the exact same settings?
Sorry, but that is irrelevant. Number of "clickable elements" is meaningless per say.

I do see advantage on this design, but I see disadvantages too:
* Hiding server list is wrong. This is key element of this page.
* Add/Remove/Rename/whatever you want to do with this list belong to "ED2K" section, not to bottom of page.
* What's wrong with right click? Contextual menu is one of GUI guidelines in Windows and Gnome
 
Title: Re: A new look for aMule 2.2.0
Post by: sneeka2 on January 06, 2008, 11:34:08 AM
Quote
You type something in this field and you get a new tab with the search results.
But WHY show it globally? What you gonna search in "Network" window?!

The point is that it's easy to search from anywhere in the app. It'll probably make more sense once the new design starts coming together more.

Sorry, but that is irrelevant. Number of "clickable elements" is meaningless per say.

True, meaningless per se. If the ratio of clickable elements to number of accessible functions is roughly 3:1 though, it's time to reduce 'clickable elements'.

* Hiding server list is wrong. This is key element of this page.

Sort of agree, but in terms of what (and that's subjective) I usually do in that view, the server list is pretty unnecessary. One connect button would do the trick for me.

* Add/Remove/Rename/whatever you want to do with this list belong to "ED2K" section, not to bottom of page.

It needs to be in a clear relation to the server list, which it is. At least in terms of Mac standards, there may be other assumptions being made on other platforms. I agree that the server list is not however in clear relation with the ED2k part above it. That's a point I was planning to address anyway.

* What's wrong with right click? Contextual menu is one of GUI guidelines in Windows and Gnome

Nothing's wrong with it, it can still be there. There's nothing wrong with having an obvious button at the bottom of the list plus a "shortcut" right click. Personally, I strongly dislike interfaces that bury some functions exclusively in a right click menu. And if you want to be as cross-platform compliant as possible: Mac GUIs usually avoid right-click-only functions.

The main improvement I'd highlight here is this: Something that was spread across no less than 5 tabs before is now all visible and accessible at once glance, and it's even less cluttered than before. And no part has been buried* or "dumbed down", they take the same amount of clicks as before, often even less.
*) hiding of the server list open to discussion
Title: Re: A new look for aMule 2.2.0
Post by: lfroen on January 06, 2008, 02:40:34 PM
Quote
Sort of agree, but in terms of what (and that's subjective) I usually do in that view, the server list is pretty unnecessary. One connect button would do the trick for me.
Are you suggesting that you going to get rid of global toolbar too? Because if not, you already have "connect" button there.

Quote
Personally, I strongly dislike ...
That's irrelevant. If you're choosing to ignore widely accepted practice (right click), please bring some arguments to your side.
Quote
Mac GUIs usually avoid right-click-only functions.
I saw plenty of opposite examples. And you know, in 21-st century Mac users should finally get used for mouse to have more that 1 button.

Quote
The main improvement I'd highlight here is this
I agree, there's improvement. I hope you will take points mentioned in this thread to your attention :)
Title: Re: A new look for aMule 2.2.0
Post by: sneeka2 on January 06, 2008, 03:13:46 PM
Are you suggesting that you going to get rid of global toolbar too?

Not at all.

If you're choosing to ignore widely accepted practice (right click), please bring some arguments to your side.
I saw plenty of opposite examples. And you know, in 21-st century Mac users should finally get used for mouse to have more that 1 button.

Again, I DO NOT want to get rid of the right click.

I hope you will take points mentioned in this thread to your attention

Certainly. :)
I'm still interested in more pro or contra server list opinions for example.
Title: Re: A new look for aMule 2.2.0
Post by: franz1789 on January 06, 2008, 05:15:45 PM
Can I ask a question? But by adjusting Mac GUI, will we have better GUI on GNU/Linux? Remember this software is multi-OS, not only Mac... Perhaps it could be better to divide people who are working into groups...
Title: Re: A new look for aMule 2.2.0
Post by: wuischke on January 06, 2008, 05:30:09 PM
Let me clarify this: sneeka2 is working on a GUI redesign concept with the focus on the Mac. This *might* lead to a new Mac remote GUI to give Mac users a native experience.

We on the other hand are interested in optimizing some elements of our current main GUI (i.e. what you call Linux GUI), so that we might use some of his ideas and apply them to the main GUI, where they fit.
Title: Re: A new look for aMule 2.2.0
Post by: sneeka2 on January 06, 2008, 11:17:18 PM
Since I'm a Mac guy and my tools are all on the Mac, my mockups will very much be Mac-based.

Having said that, I am keeping the cross-platform nature of aMule in mind. For now I am focusing on creating the most optimized version of the GUI I can come up with, which will probably mean that I'll rely on some specific Mac strengths and GUI guidelines. From there we'll see if it's possible to translate this into an acceptable cross-platform concept, or whether the Mac will get it's own GUI and some selected improvements will trickle through to the Linux side.

As far as I understand there's sort of a separate Mac-movement going on already, so a separate Mac GUI might happen first (and is very necessary too, if you ask me, as the current cross-platform code looks a lot worse on the Mac than it does on Linux). I'm only speculating out of my rear end here though. ;)
Title: Re: A new look for aMule 2.2.0
Post by: eisa01 on January 07, 2008, 03:27:24 PM
Very nice UI sneeka!

Although I have one gripe about it, as it is presented it's a bit tedious having to click connect on both the ed2k and kad button to get connected, but introducing a connect all button would just clutter up the interface...

What about having one button for connecting, and you can choose in the preferences what networks you want to use, and hide the information that no longer is necessary?
Title: Re: A new look for aMule 2.2.0
Post by: sneeka2 on January 08, 2008, 01:02:13 AM
Well, that multi-coloured placeholder in the menubar is supposed to hold a global connect button, just as it does now. As somebody said in this thread, sometimes you might want to emergency disconnect (not too sure why, but hey), so I don't want to throw the button out. It also allows you to handle the connection "task" without ever seeing the network tab.

About dis-/enabling networks in the preferences and hiding them if unused: not sure if the interface can be made that dynamically cross-platform. Also, I kind of dislike the idea of "hiding" an additional network in the prefs, as in "Woops, I never looked there and didn't know there was another network available".
Having said that, it's an interesting point and I'll keep it in mind!
Title: Re: A new look for aMule 2.2.0
Post by: sup on January 10, 2008, 01:23:08 AM
Quote
Well, that multi-coloured placeholder in the menubar is supposed to hold a global connect button, just as it does now. As somebody said in this thread, sometimes you might want to emergency disconnect (not too sure why, but hey)
I sometime use aMule over vpn because on my current connection it is forbiden, if the VPN connection drops, I need to close amule quickly. There goes a use case.
Although I rather like what you are suggesting, I think that a designer must not think only about how she uses something but about how other people use something, right?

Quote
About dis-/enabling networks in the preferences and hiding them if unused: not sure if the interface can be made that dynamically cross-platform. Also, I kind of dislike the idea of "hiding" an additional network in the prefs, as in "Woops, I never looked there and didn't know there was another network available".
Having said that, it's an interesting point and I'll keep it in mind!
What about defaulting to showing both? Then you need not to look anywhere to find it, but you can hide it if you do not use it.
Title: Re: A new look for aMule 2.2.0
Post by: sneeka2 on January 10, 2008, 04:56:11 AM
Although I rather like what you are suggesting, I think that a designer must not think only about how she uses something but about how
other people use something, right?

Sure, that's why I'm asking around... :D

What about defaulting to showing both? Then you need not to look anywhere to find it, but you can hide it if you do not use it.

I'd still like to keep the preferences out of this. Both sections take little enough space to be ignorable, and if the ED2k server list can be hidden, it's almost as good as disabling it completely /methinks. My idea would be to Start/Stop networks only in the network pane. All the statistics could be greyed out when a network is disabled, which would enforce the idea even more. Think about it: Currently, when you disable a network in the preferences and then try to connect, it only gives you an error message saying "please enable me". How useful is that really?

The tricky part is how the global connect button should work in this case. It always disconnects all networks, but it should only connect the network(s) you have manually started before. That needs to be made obvious somehow.
Title: Re: A new look for aMule 2.2.0
Post by: gulp on February 06, 2008, 11:39:55 PM
an amuleweb skin...

http://forum.amule.org/index.php?topic=14381.0
Title: Re: A new look for aMule 2.2.0
Post by: rufus on March 27, 2008, 09:10:26 PM
Where is the list of "show stopping bugs"?
Title: Re: A new look for aMule 2.2.0
Post by: GonoszTopi on March 27, 2008, 09:35:52 PM
Inside my head.