Hydranode Developer's Diary - Developer's Daily Diary: Full SP2 support, more GUI design topics

Alo Sarv
lead developer

Donate via
MoneyBookers

Latest Builds

version 0.3

tar.gz tar.bz2 Boost 1.33.1 Headers

MLDonkey Downloads Import Module Development

Payment completed
Development in progress.

Developer's Diary

irc.hydranode.com/#hydranode

Saturday, February 11, 2006

Full SP2 support, more GUI design topics

On GUI side, I'v been fine-tuning the transfer page somewhat - there were some issues with multi-selection while filters were enabled. Also, I added support for pasting links to the gui (to start downloads). Settings page saw initial layout today, but I haven't managed to review/discuss it with our designer yet, so nothing conclusive there yet. The current idea is to have settings page behave just like any other page - a PAGE, not a dialog. There are somewhat mixed feelings about this - on one hand, it's standard to have settings/preferences as separate dialog; on the other hand, it's bad practice to have a set of buttons (top navigation buttons) all having the same effect (change the content of the bottom side), and then have one button behave differently (open a modal dialog). You can find few entries in GUI Design Hall of Shame on this very thing, yet many (all?) P2P client interfaces seem to do this.

I also gave thought on the comment in previous blog post, regarding the mentioned usability issue with the filter bar. Yes, I agree that having a search box on the top-right corner is a growing standard; however that means in order to maintain the UI balance, I will also need to put something to the top-left corner (as you'v noticed, the UI is meant to be center-balanced - the bottom buttons are also centered now). Only logical thing to put to the top-left corner that I can think of right now would be a global status indicator, along the lines of "Ok, Online, Core up" etc - roughly same-sized, multi-function display element as the search-box on the right.

As for the filter-bar after we implement the above changes, I don't feel it works at the bottom, since the bottom is reserved for "action toolbar" or "taskbar" - logic being that you move in the UI from top to bottom - switch to correct page, find the object you'r interested in by filtering and/or clicking on list entries, and then perform the operation at the bottom. If you move the filter-bar to the bottom, it moves away from the natural flow in which the user would "parse" the interface.

There are some alternative solutions to the filterbar; for example, some interfaces allow "search-as-you-type" behaviour - when you start typing, a small text-edit box is displayed and filtering applied. This would make the entire filter-bar obsolete - the drop-downs on the filterbar weren't really useful anyway, perhaps only Status was, but the plans are to introduce grouped-view to the entire listing, where downloads are grouped to Complete [finished], Active [Waiting/Downloading] and Inactive [Paused/Stopped]. Canceled downloads should probably be removed from the listing instantly, since there are no operations you can perform on a canceled download (where-as you can "open" a Completed download).

On core-side, I finally added full support for XP/SP2 limitations workaround - there's a new configuration option, "ConnectingCount" (not the best choice of names, I admit), which basically limits number of concurrent outgoing (half-open) connections, defaulting to 9 on windows and unlimited on other systems. Users running Hydranode on other systems should be warned though that if you have an XP/SP2 box sharing internet, that TCP connection limitation apparently affects ALL systems behind it as well - so even if you'r running Hydranode on linux, but Windows box is sharing net, you still run into this limitation. At least this is what I noticed during my tests - don't take this as absolute truth though, I might be wrong here.

Related to the above, the "half-open" connections suddenly became a very scarce resource, which means I had to fine-tune both ed2k and BT code to lower outgoing connection timeout from 30s to 15s (ed2k) and 5s (bt). Regression tests didn't bring out any issues even when reducing the ed2k timeout to 5s, so it's expected we will drop it to 5s shortly.

I'm also tracking some memory-usage issues that I'v detected recently, with hydranode using 60+mb memory. Towards that end, I added new command in hnsh, 'memstat' (abbr. 'mem'), which displays the amount of memory used by PartData file buffers. In worst-case scenario this can be as high as 0.5*num_downloads (500kb per download), but the average should be much lower.

Madcat, ZzZz

posted by Madcat # 1:34 AM

Comments:

Regarding the GUI, I don't agree with centering the whole lot. It's common in the Western world to read from left to right, and then from top to bottom, and that's reflected in the way most user interfaces look. The buttons are on the left and the most information is shown on the left side of the screen. The search bar in Firefox and Opera are on the right but that's because they're less used then the navigation buttons and the location bar (and because they've been added later, and simply placed somewhere where there's place for it). With bigger screens and higher resolutions it takes more time to travel from one side of the screen to another, and you'ld want to limit that as much as possible.

# posted by Arathorn : 6:58 PM

There is still a lot of work to be done on that interface. The centered buttons are a bad idea, that is just not how a userinterface of that sort really works. Adding a search in the topright is a good idea, but since that bar can be stretched easily, you simply could use "whats left" of the sapce for that field. This way you have no big opening in the top part.

Your "action buttons" concept is good on the base, but does not stand up in reality. Your main problem is the general location of them changes with resizing the window. This is something you do not want in any interface with stationary buttons such as those should be. If firefoxs buttons were on the bottom and every time you wanted to use them and you have a different size of the window, you basically search for them and have to readjust.

Use rows to keep it simple.
First row main views, as you have it now with search and so on.
Second row the action buttons, you want to keep those basic functions handy at all times. There is a rightclick mania going on (try pausing a download on Emule without the use of your right mouse button).
Third row, main static content. For search that would be the base of the serach form. An advanced search form could be expanded by clicking a button of that sort. In transfer you would have the description of whats seen (downloads, uploads). In the library you might have some sort of hierarchy system and search gui, statistics would announce the currently displayed stats.
Fourth row comes the tabbed content. Example the search queries, or if you plan that, a category for downloads, etc.
Fifth row is the actual content part, with headers if needed, and the lists or graphs of the content.

For the filter, i would place it in the content part, above the lists, top right corner (like the search, for consistency). Use the "trick" with showing as you type, it filters as you type in. Add a button "reverse" filter, as in "linux" is the term and standard it only shows the one having that in it, but reverse hides all that have this in them.

# posted by Anonymous : 9:04 PM