colomar wrote:I agree with Heiko on the procedure: While I like many ideas from your mockups, before we put a lot of effort into discussing and iterating them, I'd prefer that we do the user research.

Now the question is: Who will do it? I must say that I won't have the time to do the actual interviews at the moment, but I can of course provide guidance for whoever does it.
So who would be interested in gaining some experience in user research?

Yeah, I keep jumping the gun. I'm willing to volunteer for user research; especially, if you are offering your expertise.

CTown wrote:Yeah, I keep jumping the gun. I'm willing to volunteer for user research; especially, if you are offering your expertise.

Great! We might want to hear from boom1992 about how much actually could be changed before going into the research, though. If we end up with tons of feature requests because we find that this is what users would need but there is no capacity for implementing them, it won't be of much use (apart from the experience we gain, of course).

Hello!

First of all thanks for all the replies and mockups already! That is way more activity than I was expecting in the first place!
I'm very open to doing user surveys and a complete redesign with possible new features. I cannot promise that I have time to implement all of them, but I will try my best. I'm currently based in Barcelona and working with the BlueSystems guys has given my KDE time a boost again!

Just to clarify, KGet is actually not a frontend for wget, but 100% based on KIO for HTTP/FTP downloads and other frameworks for different protocols. Also what is neglected sometimes is that it cannot only make scheduling of downloads easier, but should in some cases make them faster as well, as it has the possibility of opening multiple connections to one or different servers per file.

For that reason we are not limited to wget features etc.

It's awesome to already have people volunteering for user research and I can certainly play my part in that work as well!
I guess the first thing we need to create is an actual questionnaire and get users to answer it. I can also post on planetkde in order to recruit more people willing to give feedback.

So how do we start?

Lukas

PS: I'll try my best to be a bit more active here! Sorry for the waiting time!

@andreas_k
Thank you for the kind words. I try to be more patient this time around, though.

boom1992 wrote:Hello!

Hi Lucas!

boom1992 wrote:So how do we start?

Yesterday, I made a list of all the features I could think of in KGet: http://paste.kde.org/pf3m4gdw8

Using that, I tried to make a rough draft for a questionnaire. Though, I definitely overloaded it. Though, I'm hoping it will be a good starting point for us to work from.

KGet questionnaire v1: https://www.dropbox.com/s/ko0utdd41scky ... 1.odt?dl=0

Edit: If we left some open ended questions on the questionnaire we could probably use that data to make user-generated user personas!

boom1992 wrote:So how do we start?

I'd suggest to refine the basics. In order to start the discussion I created a pad with vision (what do you want KGet to be, eventually), persona (who uses it), and scenario (use cases plus reason).

http://paste.kde.org/pbr6pkcde

CTown wrote:Yesterday, I made a list of all the features I could think of in KGet: http://paste.kde.org/pf3m4gdw8

Second step, IMHO, is to define the requirements. Assuming the scenario above is correct and exhaustive, I took the freedom to reorganize CTown's ideas a little bit. Again, the list should be discussed.

http://paste.kde.org/pcjrzurz3

CTown wrote:Using that, I tried to make a rough draft for a questionnaire. Though, I definitely overloaded it.

Before we run a survey we need to clarify what we want to known from the participants. E.g. I wouldn't care about "how often" because the program might not have matched some basic requirements. And perhaps we benefit more from a qualitative interrogation like "what do you want". Or in case our brainstormed feature list comprises of all swiss-knife-stuff including coffee maker, we could ask "do you want it" questions as known from the Kano method.
But lets figure out first, if we are tuned to the same wavelength.

Hey!

I revised the first pad you posted: http://paste.kde.org/ppekseciz

I think I was supposed to choose (?) the vision line? I removed the second one, as we want to emphasize the actual user scenarios and not the technical background. Correct me if I'm wrong.

I also added more user scenarios with different people. What I added here is basically functionality that is implemented in KGet and fits those user types.

For the survey, I agree with Heiko. I think we might benefit the most from a question like "what do you want to do with it?" as opposed to "what kind of feature do you want?". This way we could collect the actual use cases and then brainstorm about solutions that fit into the UI and workflow.

Lukas

Edit: I forgot to mention: Questions like " V. Is there anything that would make you prefer an external download manager over an integrated one more often?" also make sense to me. In this case we already have a problem, but don't really know if it matters enough to be tackled.

boom1992 wrote:.

I saw yesterday that you (boom1992) is one of the main contributor of Chakra OS, so I'd like to say:

YOU are a hero. Chrakra OS is realy realy well done. Best KDE experience ever.

boom1992 wrote:I revised the first pad you posted: http://paste.kde.org/ppekseciz
I think I was supposed to choose (?) the vision line? I removed the second one, as we want to emphasize the actual user scenarios and not the technical background. Correct me if I'm wrong.

The vision is what you want to achieve with your program, sometimes. You can read the HIG part on conceptual considerations: https://techbase.kde.org/Projects/Usability/HIG/Concept

boom1992 wrote:I also added more user scenarios with different people. What I added here is basically functionality that is implemented in KGet and fits those user types.

Do we really need another persona? I believe, And Matt will rather use some shell script.
> Matt wants to keep his files organized.
And therefore he uses Dolphin
It's very useful to add the reason to those user stories. I addressed the what happens with the output at the second part, but have to admit that user stories and requirements are quite similar. Maybe someone is eager to write a real scenario.

> Matt wants to select multiple downloads from one web page.
My addendum (at comments) was "* Susan wants to download all files found in a directory or listed on a html page."
> Berna wants to download files and not care about the sources they come from.
I'm not sure about the reason. And doesn't the source is always shown?

@andreas_k: Thank you for the kind words, I'm glad you like it!

@Heiko:
To clarify: "doesn't want to care about the source" => That was basically my refrasing that it should implement all (?) possible protocols a user could need.

"Matt wants to keep his files organized." => This was about download files of certain types to certain directories (can be modelled with Transfergroups in KGet).

Fine about: "* Susan wants to download all files found in a directory or listed on a html page."

So do we need anything more for the vision? I have written something like that in university some weeks ago (although in spanish), but I never *really* understood what the deal with it was. I get it now that it's a starting point for user centered design!

Lukas

Hm, the proposed vision sounds like it would fit any download manager equally well. Or in fact, pretty much any application. Who doesn't want to be versatile and easy to use?
A vision should guide the design. A good vision is one on which one can base decisions.
It should make clear what's special about KGet, why someone would use it rather than other download managers.

See for example Krita's vision:
"Krita is a KDE program for sketching and painting, offering an end–to–end solution for creating digital painting files from scratch by masters.

Fields of painting that Krita explicitly supports are concept art,
creation of comics and textures for rendering.

Modelled on existing real-world painting materials and workflows,
Krita supports creative working by getting out of the way and with
snappy response."

Or KTp's: KDE Telepathy aims to provide Plasma users an awesome open communication experience that gives them a reason to switch away from proprietary services.
We provide rich text chat and video calls that aims to fit in seamlessly with the Plasma workspace and we provide sharing and collaboration features to KDE applications. We provide support for closed services such as Facebook, Steam etc. but our primary focus will always be on open protocols.

Or Clamares' : For recreational computer users who would like to install Linux on their existing computer, Calamares is an installer that makes it simple and fail-safe to install Linux. Calamares makes it easy understand what will be done at every step without overwhelming the user with detailed technical information, unless explicitly requested. Users with more technically advanced installation needs will find those supported by Calamares as well, although not visible by default. Where available, Calamares exposes advanced features on demand.

Hello,

I'm of the Matt user type, and I don't use KGet but Firefox's built-in manager. I won't leave Firefox just because another browser has a better download manager. Here's a description of my current workflow regarding downloads :

>> Matt wants to keep his files organized.
That's right.
>And therefore he uses Dolphin
Dolphin is about organizing files, not keeping them organized. Currently, I save everything in my ~/Downloads folder. Then, I use Dolphin to move the files where they should go. Thus my home folder is less organized after download, and I need using Dolphin to make it organized again. I don't use the "Save as" dialog because it's slower (by the time I reach the Dolphin icon, my files are often already downloaded).

When I download a file, I will likely put it into a folder which already contains similar documents. I'll put a video into ~/Videos. A syllabus will go into ~/Documents/University/3rd Year/Some Course. But the documentation of some LaTeX package will go into ~/Documents/LaTeX. Both are mainly PDFs. I think FF lacks an option : "Download and open", that would store the file elsewhere than in /tmp and open it.

I often download files just to open it just once (ex: archives). When I'm unsure about how long I will keep them, I leave them in the ~/Downloads folder, which I clean up periodically.

When downloading big files (mainly ISO images of the latest Linux distros, but others download movies), I don't like using Torrent or similar techs because they require more steps :
1. Choose to open the .torrent file with KGet (in FF)
2. Configure KGet (I don't do much here that because the default is "everything to ~/Downloads", but that's another window.)
3. Start the download
Http mirrors of big distros are pretty fast so I don't see the difference in speed.

One problem I hit sometimes is that Firefox stops downloading when closed. This is especially annoying for big files - think >10 minutes of download.

Louis

PS :
Maybe Philip is needed, too. He will likely download ISOs using Torrent, Metalink and is much more likely than Susan to use the many options KGet provides.
I don't think Susan will use an external manager for safety. She expects the default one to work.

PS2 :
I see two distinct needs KGet currently addresses :
- Manage where files are put
- Manage the running downloads.

I also think that for a separate download manager the powerfull when needed is very importend. For download files into ~/Downloads it is not ncessary to install an additional app.

I don't use kget (now I'll test the app). My wife (lets call her Matt) and I (Santiago) use the same computer (and user). We have different needs.

My wife (Matt)
She will open files from the web and download everything into downloads as dolphin supports groups the download folder is sorted by date in groups. This system works for her until she is looking after older files, because she don't want so search and so she download the file again. for her the only benefit of an external download manager would be that downloaded files want be downloaded again.

Me (Santiago)
I use the DownThemAll! firefox extension when I'd like to download more than one file from a webpage. When I download more than one file, I want to select a separate download folder. In addition I have a streaming extension to download streaming files. there I have a shortcut to download the streaming file from the page into a predefined folder. For iso files I use ktorrent, because you have a nice overview of your downloads and the transfer statistics.

needs of a download manager
(I have to test kget in future, so the list is generic not for kget)
- Download manager is more than show a list of your last downloads
- you can download everything (torrent, stream) with one application
The download manager help the user to download documents from the web.
- I don't like to click right button on the link, click on the download icon and show the user what he can download on this page will be nicer. In addition (only in additon) the user can see on the download symbol what he can download on this page (stream, pdf, ...)
The download manager help to organize the downloaded files
- Download manager means for me not only to manage to download files it means also to manage the downloaded files
- When you click the download button you will see the files you can download from the page (exclusive the html, php, js, ... files) The user can select the files to download (when the user use the right click on the web link function you get the same view with the selected file)
- [powerful when needed would mean the download manager show the user also the other download files]
- and where to save the file(s)
- in the file save area you can use automatic organisation or the last 5 (10) download folders (history)
- the automatic organisation can be configured in the settings menue (webpage, file extension, webpage youtube in ~/video/youtube webpage university in ~/downloads/university)
- the file management should not only help experts it should be help also susan.
transfere settings
- don't download files twiche. the download manager should know what the app has done in the past (meybe ask the user and have a setting)
- configure the transfere settings like download speed, download limitation (maximum data amount), safety settings, ... in the app settings
- it would be realy cool when you'd like to download a file like an distribution iso to download the file not only from the selected server. when you'd like to download for example ubuntu-14.04.x64.iso the download manager search for mirror's and ask if the user want to download also from other sources, maybe only when the traffic is very low.

result
- user survey would be realy nice and a perfect start
- both is a challenge simple and powerful
- you can separate the app into some parts (e.o. user want to download the file from a webpage, download transfere, manage the downloaded files in the file system)

Please use personas efficient. If we define two different user groups like the Susans and the Matts, we need two different views that address their special needs. Personas start to life in scenarios - Susan at work, Susan at home etc., which should be sufficient in most tasks.

@Andreas: KGet is integrated into the browser, AFAIK, so Matt would use it as well. About the requirements: You start the discussion here not referring to CTown's or my paste.kde.org texts. Probably its better to move the discussion to notes.kde.org. I created a KGet page there https://notes.kde.org/p/KGet

@louis94: You describe exactly my workflow

Heiko Tietze wrote:Please use personas efficient. If we define two different user groups like the Susans and the Matts, we need two different views that address their special needs. Personas start to life in scenarios - Susan at work, Susan at home etc., which should be sufficient in most tasks.

For me, the most important thing is that our target personas actually reflect our real target audience. If we choose only Susan as target persona, then features which she wouldn't need should be removed from the application. If we decide to target only recreational users but leave features that are mainly useful for professional users in the application "just in case", we might as well just drop the whole persona thing altogether.

Of course having a primary and secondary persona makes design more difficult, but if we decide we want to support also professional users, this has to be reflected in the choice of target persona(s).

@Andreas: KGet is integrated into the browser, AFAIK, so Matt would use it as well.

It is integrated in Rekonq and Konqueror, but Firefox uses its built-in download manager until you explicitly tell it to do otherwise. Not sure about Chromium atm.

About the requirements: You start the discussion here not referring to CTown's or my paste.kde.org texts. Probably its better to move the discussion to notes.kde.org. I created a KGet page there https://notes.kde.org/p/KGet

Hm, I'm not sure how to proceed here. The forum works better for discussing things asynchronously, whereas the current status of the results is better captured in the notes.
For me it does make sense to put new proposals into the forum first and then update the Notes file when we agree on a change.

Okay, I reworked the vision a bit:
"KGet is a versatile and user-friendly download manager for KDE. It keeps the user's files organized, while getting out of the way. KGet supports downloading files from all major sources (HTTP, FTP, Torrent etc.), while respecting user constraints like data limits."

I wanted to reflect the most important user stories I gathered so far, which are organizing files, data limits and that it should not bother the user too much in a sense of opening dialogs etc.

What do you think?

Also thanks to everyone who posted here so far, I'm learning a lot about what KGet is *actually* used for.

Lukas