Direct Map Download
-
There are some details to work out about this planned feature, so community feedback needed.
currently there's a button for 'download maps' on the main start screen.
Should direct download map be a different button on that same screen, or a button on the subscreen with the repository that it opens up? If the former then the names of both buttons will need to be changed to accommodate that both are means of downloading maps, and they need to be clear about which is which and what each does; it also means there will be two download maps button. If the latter then the repository would always be contacted and its list downloaded even when it's not needed, which represents a minor use of resources and also slightly delays the user in getting to the download, as there's a short loading time (maybe a couple seconds, then finding the button for direct download).
Next we get to the direct download interface, it seems like all we need is an input box for the direct URL, plus standard buttons for cancel and ok'ing the download. Unless anyone can think of something else that needs to be added.
Subissue: should the interface support multiple downloads before closing? In practice people using direct map download seem unlikely to do it for more than one map at a time. Should it allow downloads to be queued, like the repository does?Error handling: if the file, once downloaded, proves to not be a map, what should be done with the file? we don't want clutter, but we may not want to outright delete it either.
Side issue: should this section support anything other than urls? If someone downloaded a map via some other method, should a way be provided for it to be installed in the correct location? Perhaps via allowing a file on the computer to be selected rather than an url? ie if someone downloaded it as it was an attachment to an email.
And any other notes people have on the design or details that need to be decided upon.
-
@zlefin Are you also supporting accessing whatever repository (as it was possible in past TripleA versions), or will it be possible to access only the one given by the program?
They can be called "Download Some Maps" and "Download Any Map".
By the way, is the button "Install" in the "Download Maps" window correct at all? Are the maps actually ever installed? What is the difference between downloading something and installing something? Are we actually "installing" the maps we download? I'm not sure, but I tend to think that the button currently called "Install" should be called "Download the Selected Maps", shouldn't it? Or is it "Install" better a definition of what is being done? Is it not incongruous to have a button that tells you are going to download maps and then, instead, you have an "Install" button instead of a "Download" one? If the "Install" name is preferable, shouldn't the "Download Maps" button be called "Install Maps", for coherency?
-
Can you please help me understand what you want to implement? I think currently we have a "Direct Map Download" as every map download from within TripleA is the direct download of the repository's master.zip file.
Also today you can directly go to the repository and download the master.zip directly.
In case you just want to add something like a prompt to manually add any URL - would that be an added value? In case the user knows that URL, why would he want to take the detour via the TripleA-software?
In case the user already has a map file somewhere on his drive it woudn't be a download but a "move to" or a "copy to". Also in this case using TripleA would be a detour.
I must be missing something....
Thank you.
-
I''m just trying to implement the things on the list. Lafayette put direct map download on the list of features to implement for 2.6, so I'm trying to implement it. I assumed direct map download meant a button that would then download a map from the internet directly, without having to use the repository. I assume the reason to have a button at all, rather than people simply manually downloading it and putting it in the appropriate folder, is that people often have a hard time finding that folder; also the map could be validated on download. But as to added value, I don't know, you'd have to ask lafayette as he's the one with the list.
It seems like more than anything else, we need @LaFayette to clarify what he wanted the feature to do.
-
@zlefin If there are doubts about copyrights or a map under development is not yet playable enough, so that the map is not accepted into the TripleA repository, or it is expunged from it, anyone would be able to host the map somewhere (at his own risk), for others to download and play via TripleA by writing or pasting the URL.
-
I understand it would also allow playing maps featuring Nazist and otherwise white supremacist terms and symbols, which may not make to the TripleA repository, as well as other maps with unacceptable content. Pretty much whatever cannot, or it is not supposed to, make to the TripleA repository. Again, just my understanding of what this feature would allow (and it is currently already possible but only manually): feel free to correct me if I'm wrong.
-
Thank you, @zlefin and @Cernel , I am getting an idea now.
Yes, maybe @LaFayette could confirm or further clarify. -
From one perspective this update is an enhancement. Today users select a map name to download, the map name is mapped in the backend to a download URL, so the system knows the URL based
on the map name selected. Instead of selecting the URL via map-name, the user will input it directly.My thoughts on how the UX would flow:
- add a button to perhaps the corner of the existing download maps window
- when clicked, a modal dialog opens up that is little more than a text field for a URL and a 'download' button
- after the user enters a valid URL and clicks download:
- dialog closes
- URL download item is added to the 'in-progress' list (and is otherwise handled with existing code)
- if the entered URL is invalid: show an error alert to the user & leave the input dialog open. Consider building it so
that the 'download' button is not enabled until a valid URL has been typed)
It's worth keeping in mind that this will require iterations, so while we may have a nicer UI in mind, there might be some small stepping stones we have to do first no matter where we are going.
For example, another UX would be to put the direct-URL download button where the map progress indicators usually live. When clicked, a progress-like indicator shows up, but a user can enter a URL instead
and when they click 'download' the text field converts into the proper download progress indicator... This is arguably a much cooler way to do the feature, but you need to start somewhere and once the parts are connected together and working it might then make it easier to refine the UI.Subissue: should the interface support multiple downloads before closing?
This could look like an 'expand' button that converts the download URL text field into a text area.
Then URLs could be one-per-line and downloaded in bulk.In practice people using direct map download seem unlikely to do it for more than one map at a time. Should it allow downloads to be queued, like the repository does?
Depends, I can envision several use-cases:
- A multiplayer game is being hosted with a 'custom-url' map and another player needs to download that map
- Map-development/play-testing. Map makers today are hosting zip files, they would give a downoad URL to play-testers & collaborators.
- Download list, someone hosts a text file with a list of maps, copy/paste the list to download/update all
- Download list via website. Similar to how TripleA hosts a 'maps website', other map hosters can do the same and they no longer
need to explain how to install the map beyond copy/pasting the download URL.
Error handling: if the file, once downloaded, proves to not be a map, what should be done with the file? we don't want clutter, but we may not want to outright delete it either.
This should already be taken care of by the URL download processing logic. I think (memory is hazy on this, could be wrong) in this case the map is put into a quarantine folder and is then left alone.
ie if someone downloaded it as it was an attachment to an email.
Interesting use-case. Are you aware of anyone doing this? Would they switch to using the GUI if we built the 'install from hard-disk' option?
If no, would at least new people start doing this if there were a GUI option to install from file downloadSide issue: should this section support anything other than urls? If someone downloaded a map via some other method, should a way be provided for it to be installed in the correct location? Perhaps via allowing a file on the computer to be selected rather than an url?
Keep it simple IMO and focus on minimal working iterations. To help this you could put the initial work behind a feature flag.
With such a flag you could add to start just the button (and clicking it down nothing). Then a next iteration could show
the dialog but not yet do anything. The next iteration could add validation and if the download URL is valid then a pop-up
says the URL is valid, otherwise handle the error case. Then, instead of showing the 'URL is valid', actually do the download.For where you'll integrate with the existing system to do the URL download, check: 'DownloadCoordinator#accept'.
-
In case you just want to add something like a prompt to manually add any URL - would that be an added value? In case the user knows that URL, why would he want to take the detour via the TripleA-software?
Let's say you had to explain to someone how to manually download & install a map-zip file today. The steps are (A):
- copy download-URL
- paste download-URL into web browser, downloading the file
- open file system
- locate dowloaded zip file and the triplea downloaded-maps folder
- move downloaded zip file to download maps folder
- launch the game (TripleA)
- select game-scenario and start
With this feature that becomes (B):
- copy URL
- launch the game (TripleA)
- click download maps
- click direct-URL download
- paste URL, click download
- watch download progress
- select game-scenario and start
Of note, (A) could lead to bad file states if the in-progress download is done directly into the downloaded maps folder and TripleA starts up. There is a level of error handling here that is harder to handle.
There are additionally further tie-in features that we may want. For example when a map fails to start we have a cludgy text that says "failed to launch the map, would you like to download it?".
In that same flow we could place an option for a user to open the direct-URL dialog and then specify the URL then. In this scenario lets say you are hosting a map in lobby and a relatively new user joins. Instead of explaining how to install a map, can simply instruct people to enter in a specific URL to download. On the game joining screen, there is a 'download maps' button so a person could take care of the download without leaving the TripleA application window. -
@cernel said in Direct Map Download:
I understand it would also allow playing maps featuring Nazist and otherwise white supremacist terms and symbols, which may not make to the TripleA repository, as well as other maps with unacceptable content.
This is a really good point. I am also concerned about the security side of this, like malware maps, but the actual content is a concern too. Though, keep in mind that nothing prevents this situation from occurring today.
Overall, I think this is addressed with an update to our lobby rules and guidance. To do so we need to make a more official stance on exactly how maps and their content are handled. Any outcome to that question does not change this feature, here we are only enhancing how a user can specify a download-URL. While this guidance update is important, it should have it's own forum for discussion, it's a different question and needs its own proper consideration (where to best do that, I'm not sure)
-
@lafayette I'm unconfortable with the additional and unnecessary step of having to open the repository window to be able to download a map from an URL. I think it would be easier, especially for casual users (you may instruct to use the feature), if the button is available once launching the program (so, on main screen and somewhere near the current "Download Maps" button). I get that this is mainly meant to "hide" the new feature because it is less important than downloading via the repository.
-
@cernel If it is not wanted to have two buttons, then the most logical thing would be that the "Download Map" button gives an intermediate window prompting you to choose wheter to access the repository or paste a URL. It can simply give the ability to paste the URL and make you access the repository if you click OK leaving it blank.
-
@cernel said in Direct Map Download:
I'm unconfortable with the additional and unnecessary step of having to open the repository window to be able to download a map from an URL
Could you explain what you mean more precisely? I'm not sure how you mean by repository window?
-
@lafayette To firstly have to access the download list to be able to download from an URL. I think one should not be obliged to receive that list to be able to download from an URL, also since this means the feature will be likely visually marginalized.
-
@cernel If I understand correctly you're suggesting it be an either /or to download from repo's or to download directly from a URL.
The alternatives that would accomplish are not very palatable to me:
A) We add a second button to the main screen.
Cons:- too many buttons on main screen already, this makes it harder to use all existing controls, it's one more thing when considering what to cick next.
- putting a button on a screen that is not typically pushed is a bad UX, all UI elements should be relatively cohesive and used
- scatters download functionality, there are two places now to know about when downloading
\B) When clicking the 'download maps' button we ask whether to download from repo or direct URL. I don't like this very much as we introduce an extra button click when 99.9% of the time users will be downloading from repos.