andreas_k wrote:And you need some features!

I also like the idea with the priority for web serfing, streaming pages, ... instad of a fast download and you can't watch a streaming page or send/recive your mails. That would be a nice feature.

You mean that KGet would throttle down if there is streaming etc going on?

I like the idea as well, but I currently have no clue if it's doable technically.

colomar wrote:

boom1992 wrote:@CTown: I'm not sure if managing bandwidth makes much sense anymore. At least for me the bandwidth has gone up rapidly the last years. When I started working on KGet having a download manager made absolute sense to me, I used it daily. Since moving to a Fiber-Connection and even now as I'm being downgraded to sth like 6000 MBit/s shared with 3 people, I have not really used it. Downloads are mostly fast enough.

It depends: With a few torrent transfers going on, for examples, bandwidth (especially upstream for ADSL) can still clog up pretty quickly.

For torrents I understand it, but with normal downloads?

Heiko Tietze wrote:Again, should we discuss this in a hangout? Otherwise I can prepare a survey based on the considerations at the pad.

I'm not sure if a hangout is the appropriate medium for brainstorming. We can go on with the survey, this will probably be the only real metric to find a solution to this.

I will start writing a blog post about the whole situation, I think it makes sense attaching the survey there and getting answers from a broad range of users. What do you think?

Lukas

+10 for the blog post to ask for feedback.

boom1992 wrote:

colomar wrote:It depends: With a few torrent transfers going on, for examples, bandwidth (especially upstream for ADSL) can still clog up pretty quickly.

For torrents I understand it, but with normal downloads?

If KGet would only support HTTP/FTP downloads, I'd agree, but since it also supports torrents, it makes sense to have such a feature, and I think it would be more confusing than helpful to introduce it only for a certain type of transfer.

-1 to a blog post on usability by the developer, esp. with qualitative, free QA
(Please don't get me wrong, you might doing well. But that's as if I would write about coding. You don't trust me, or rather you shouldn't).

Let me prepare a survey along with a posting. I have a "Do you use or consider to use KGet? Yes/No" in mind plus "If you say Yes, please answer a few question <here>, if No please use the comment section". This posting shouldn't go into detail. E.g. if you tell them that with less than 50% you would stop the development you bias the result; no one accepts the removal of functions, even unused.

The survey should be a little bit more comprehensive. As said before I favour the Kano method to find preferences. The method reveals quantitative results that we can combine with a few detailed questions.

Heiko Tietze wrote:-1 to a blog post on usability by the developer, esp. with qualitative, free QA
(Please don't get me wrong, you might doing well. But that's as if I would write about coding. You don't trust me, or rather you shouldn't).

Let me prepare a survey along with a posting. I have a "Do you use or consider to use KGet? Yes/No" in mind plus "If you say Yes, please answer a few question <here>, if No please use the comment section". This posting shouldn't go into detail. E.g. if you tell them that with less than 50% you would stop the development you bias the result; no one accepts the removal of functions, even unused.

The survey should be a little bit more comprehensive. As said before I favour the Kano method to find preferences. The method reveals quantitative results that we can combine with a few detailed questions.

Awesome, thank you!

Yes I was not going to write a blog post with survey questions that I built myself. What I wrote about (I have it saved as a draft) is my current story with KGet and the reasoning how I came here. Not sure if I'm introducing a bias with that though.

boom1992 wrote:Yes I was not going to write a blog post with survey questions that I built myself. What I wrote about (I have it saved as a draft) is my current story with KGet and the reasoning how I came here. Not sure if I'm introducing a bias with that though.

You're probably not, unless you say "I came to the VDG because they were supposed to tell me which features should stay and which should go" - and since that's not the impression we got, I don't think that's what you were going to write

Actually, I think it makes a lot of sense to set the context first, so that when Heiko writes his blog post, people already know that this is not some fantasy thing, but we're actually working with a dev and people's input will be used for an actual redesign.

@Boom

It would be cool if Firefox's traffic gets prioritized over KGet's when bandwidth gets sparse but, you're right, that's probably out of KGet's reach. Stuff like managing bandwidth should be done globally through Network Manager KCM. I guess all KGet should be able to do (bandwidth wise) is to prioritize downloads and pause/stop them as well.

Sites like RapidShare are a moving target. It may be to time consuming to support them anyways.

@Heiko

I think we discussed how we already feel in depth. Plus, there hasn't really been complaints to the etherpad. I would really like to hear what other users want. So, I am in a favor of a survey at this point.

The only thing I would change on the etherpad is that I think torrent/magnet links support should be considered just as important as HTTP and FTP:
(1) Free support through libktorrent (which is the current case)
(2) KGet is much simpler than a torrent client (in my opinion)
(3) BitTorrent is an extremely popular protocol when it comes to downloading files (even if those users never upload back).

Edit: Wikipedia says that the BitTorrent protocol has "been estimated to collectively account for approximately 43% to 70% of all Internet traffic (depending on geographical location) as of February 2009." Though, I bet Netflix put a huge dent to that in the United States!

I normally just use browser or wget -c, but gave KGet a go just for this thread, in it's default untweaked form, just window resized. Look at this:


First thing wrong with it are the columns. Name of file is almost completely hidden. Hovering over doesn't help. Removing "status" column would be a good first step, since it shows the status prepended to name anyways.

Second thing wrong is names on toolbar. Those could be shorter for even more compact display.

Third thing wrong is actions in download category, especially queue priorities. Those are not easily accessible with right-click. I suggest making those more discoverable by making the file in download area clickable so that it would expand (four-five rows) and reveal actions applicable to the file such as position in queue and more file details.

Hopefully my input has any value.

daedaluz wrote:I normally just use browser or wget -c, but gave KGet a go just for this thread, in it's default untweaked form, just window resized. Look at this:
http://a.pomf.se/lhrgaw.png

First thing wrong with it are the columns. Name of file is almost completely hidden. Hovering over doesn't help. Removing "status" column would be a good first step, since it shows the status prepended to name anyways.

Second thing wrong is names on toolbar. Those could be shorter for even more compact display.

Third thing wrong is actions in download category, especially queue priorities. Those are not easily accessible with right-click. I suggest making those more discoverable by making the file in download area clickable so that it would expand (four-five rows) and reveal actions applicable to the file such as position in queue and more file details.

Hopefully my input has any value.

The problem is that KGet already requires A LOT of horizontal space. Then there is the fact that these new "Breeze" or "Core" (what was the official name?) apps all have sidebars instead of the normal tool bars taking more vertical space. So, that's why my mockups from the beginning of the thread look the way they do.

This was my last attempt (since I finally got the message that the usability study comes before the redesign): https://imgur.com/ggAvPQ0

Here is my proposal for the study. I would start in the blog post with a poll:

Do you use KGet?
* Yes, regularly
* No, but I consider it
* No

And ask "If you use Kget or consider to use it, please answer a couple of question in this survey".

http://user-weave.com/survey/ad0e0142c9 ... c6cd0d9?49

With the first question I want to get an idea about how many people do not use KGet. Lukas should think about a threshold here when to retire KGet (No vs. Yes and Not yet).

The survey for interested users consists of two parts. First page is about how people use KGet today, what they like and what not. After that I would run another test with the Kano method to get insights about which requirements are of particular interest.

All text has not been proofread yet, both tests are just for discussing the survey design. Opinions?

Heiko Tietze wrote:Here is my proposal for the study.

Thank you for setting this survey up!
I really like most of the first part, especially the question which aims for associating the participants with one of our personas, and also the "Why do you use KGet?" question.

With the first question I want to get an idea about how many people do not use KGet. Lukas should think about a threshold here when to retire KGet (No vs. Yes and Not yet).

It seemed to me more like Lukas considered abandoning KGet if no valid usage scenario for it turns up. This is not the same as a too low number of people saying that they are currently using it. What if there is a perfectly valid usecase for a download manager but only few people use KGet at the moment because it doesn't support that usecase well enough?
In that case by abandoning it because of the survey, we'd miss the chance of improving KGet to a point where it would be useful to more people.

Therefore instead of setting a threshold, I'd ask those who indicated they are not using KGet today why they don't. Some ideas for answers:
- Simple tools like the browser's built-in download queue and/or wget already satisfy all my download needs
- I use a different download manager: _________
- KGet would be useful to me if: ______________

If the majority chooses 1, then we might conclude that there simply is no place for a download manager in 2014. If the majority chooses 2, Lukas has to decide whether it's worth the effort trying to come up with a download manager which is better than the one people use.
However, if it turns out that KGet just doesn't work well for the things they need a download manager for, then we should improve KGet instead of scrapping it.

About the Kano survey, I'm still unsure: For me, it's asking users what they want instead of identifying what they need, and it might limit our creativity instead of supporting it. I'd want to find out more about what they're doing with KGet or what they'd want to do with it and then come up with the features needed to support that, instead of asking them "Should we keep feature A"? Of course the results from the survey aren't gospel and do not actually restrict our freedom of creativity, but since they are so specific, we might tend to just put every feature intot he redesigned KGet which is considered a core feature, even if we might have solved the underlying problem in a better way than with this specific feature.

colomar wrote:It seemed to me more like Lukas considered abandoning KGet if no valid usage scenario for it turns up. This is not the same as a too low number of people saying that they are currently using it.

I thought it was clear that 'No' is different from 'Not yet'. If we forward all people to the survey it might bias the result because those people who refuse to use a download manager might not care about its features. Therefore I want to known first whether or not they use it or can imagine to use it. And only those are asked to do the survey. All others should comment at the blog, of course.

colomar wrote:About the Kano survey, I'm still unsure: For me, it's asking users what they want instead of identifying what they need, and it might limit our creativity instead of supporting it.

I don't feel a diminished creativity if participants dislikes a presupposed requirement.
For example, some people could imagine to use KGet but do not care about bittorrent since KTorrent does the job well (first two questions). And the advantage of Kano is that we get a prioritization in terms of which features constitutes the application, what is a killer-feature, a show-stopper, etc. The theoretical foundation is Herzberg's two way model: the absence of basic, so called hygiene factors (payment, environment, leadership etc.) reduces job satisfaction, whereas motivator factors (appreciation, responsibility) improve it.
I understand your objection as the fear to get controlled or driven by the results. In my opinion the opposite will happen.

But I don't stick to the proposal. Let's here other opinions...

Very interesting survey Heiko! I cannot wait for the results.

Heiko Tietze wrote:

colomar wrote:It seemed to me more like Lukas considered abandoning KGet if no valid usage scenario for it turns up. This is not the same as a too low number of people saying that they are currently using it.

I thought it was clear that 'No' is different from 'Not yet'.

Sure it is, but if we stop asking questions fto those who say "No", we still don't know why they're not using it.

If we forward all people to the survey it might bias the result because those people who refuse to use a download manager might not care about its features. Therefore I want to known first whether or not they use it or can imagine to use it. And only those are asked to do the survey. All others should comment at the blog, of course..

I completely understand why you don't want to push those who don't use KGet through the whole survey. Hm. I have two ideas for fixing this, but neither is technically feasible
Okay, so third suggestion, these options:

Do you use KGet?

Yes, regularly

• Yes, occasionally.
• No, but I'd consider it if it had some features I'm missing
• No, I don't need a download manager

That way it would be more clear that we'd have no chance to convince those who chose option 3.

colomar wrote:About the Kano survey, I'm still unsure: For me, it's asking users what they want instead of identifying what they need, and it might limit our creativity instead of supporting it.

I don't feel a diminished creativity if participants dislikes a presupposed requirement.
For example, some people could imagine to use KGet but do not care about bittorrent since KTorrent does the job well (first two questions). And the advantage of Kano is that we get a prioritization in terms of which features constitutes the application, what is a killer-feature, a show-stopper, etc. The theoretical foundation is Herzberg's two way model: the absence of basic, so called hygiene factors (payment, environment, leadership etc.) reduces job satisfaction, whereas motivator factors (appreciation, responsibility) improve it.
I understand your objection as the fear to get controlled or driven by the results. In my opinion the opposite will happen.

Don't get me wrong, I have no issue with the Kano method in general. I found the categorization into Core/Performance/Buzz/Exotic features we did for Active Mail really helpful! It just feels a bit strange to me to explicitly ask about features so early in the design phase.
But well, as long as we allow ourselves to replace "Core Feature A" with a Feature B that we are convinced will serve the needs of those features who voted for it even better than Feature A, then it's fine with me

colomar wrote:Okay, so third suggestion, these options:

Do you use KGet?

Yes, regularly

• Yes, occasionally.
• No, but I'd consider it if it had some features I'm missing
• No, I don't need a download manager

Sounds good. Are people who use a different download manager covered by "No, but I'd consider..."?