December 29, 201411 yr Hey everyone, just wanted to give you guys a heads up on some of the final refinements we're planning for unRAID 6. Thanks to the tremendous work of gfjardim, the unRAID Docker Manager tool got a major upgrade shortly after it was introduced in beta 6. The upgrade enabled users to more easily add Dockerized applications to their system without needing to drop to command line or download/install plugin files manually. On behalf of all of us at Lime Technology and the unRAID user community, I'd like to take a second to thank gfjardim for his hard work here and commend him on a job well done! All of that said, we have had a desire to update the management tool a bit further to simplify the interface and change how it functions. Our primary goals in this endeavor are the make the interface less intimidating to new users and remove non-actionable information from being displayed on the page. As such, I'd like to introduce you to an early concept screenshot of the new Docker manager tool and highlight some of the key differences we are planning to implement. Please note that this screenshot is of a development build that is a work in progress: Note: we have yet to modify / update the "add container" page, but will be working on refinements to that in the near future. So for starters, let's go through the simple changes we've made, then we'll get into the bigger ones: [*]We now have a indicator overlay that identifies container status on top of the application icon. [*]The overlay indicators we will use are not only going to vary in color, but in shape, to ensure color blind users can recognize the status as well. [*]Icons now display in the table list of the applications as well as in the "Docker Apps" section at the top of the page (for faster recognition). [*]We've dramatically simplified the table layout for containers, removing / consolidating numerous fields. [*]Instead of using a "status" column to indicate whether or not an update is available to the container, we renamed it to "Version" and the two indicators are "current" or "update available" to simplify. [*]We removed the "ports" column, but may add that back later. [*]We removed the "control" column. [*]We removed the "container ID" column. [*]We changed the Status/Log column to just an icon. [*]We removed the "created" column. [*]We performed a number of "under the covers" code changes to improve page load performance in the webGui. Now I'd like to take a second to explain why we removed the "images" table. The fact is that the previous table didn't provide any additional information that was helpful or provided actionable intelligence for the user. The primary purpose for it's existence was so that if a user removed a container, but not the image, the image could be removed later from that table. In our new design, we are consolidating that functionality into the primary table of containers. Our tentative design plan (still potential for this to change a bit) is to make it so that if an application has an image present on the system, but no container for it, it will appear in the list of containers, but not have a status indicator over it and there will be an option to remove it entirely. This way we can eliminate the images table, but still offer that functionality to users. The only information presented in the images table that was truly unique to that table was the "Virtual Size." That said, this size is not indicative of how much space a container / image actually consumes on the system. It's simply a representation of what it WOULD be had we used something like VFS for the Docker image instead of a filesystem that supports snap shotting. The point is that the size listed in the "Virtual Size" column in the current tool is not a true representation of space consumption and therefore is non-actionable information. In fact, many times this could lead someone to think an app/image is consuming far more space than it actually is. Another major update that you can't see in this current screenshot is support for the tabbed view mode. After the inclusion of Dynamix in Beta12, the current Docker Manager ignores the Display Settings preference and forces the page to be rendered in "Plain" mode. In the new version, the tool will respect the user's display preference setting appropriately. So why remove so much? The reality is that sometimes less is more, and in this instance, we had too many different ways to accomplish the same task (e.g. performing actions on containers is a prime example). Our goal with this refreshed design is to simplify the page and make it less "scary" for new users that aren't familiar with Docker, containers, virtualization or Linux for that matter. We have other enhancements planned to this tool that will happen over time, but those are for discussion on another day ;-). We'd love to hear feedback on this (good and bad) and hope that these changes will make for a much better user experience going forward! Thanks!
December 29, 201411 yr Stuff that for me needs thought about: • Knowing what the base OS is of each container is currently a lot of work. This is something we need to work towards presenting in the GUI. • Knowing what real size on disk a container is and the associated base OS (as you pointed out this is ridiculously complex to work out) • "We removed the "container ID" column." Is potentially a problem as it was the hook that allowed you to visually search for text on the web GUI to match what docker command line tells you. See next point. • The GUI has always struggled conceptually IMO with the fundamental docker design tenant of run the same container as many times as you like. Given what is happening is a step back redesign this should be seriously considered. Appdata folder naming should be formally standardised and designed in such as way as to be scalable and potentially snap-shot’able (whats the point of having docker power to roll forward and back the app if there is no way for the appdata to follow along with it). We may want to start using container ID as the appdata folder name and then handle upgrades with FS layers or something. I know this is no small task but we ignore it at the risk of later having to go back and start again. • Template repository’s should be handled in the same way as apps. i.e. when you add a repo you should get an icon that is clickable that pops up some words by the author, crucial links and list of the containers on offer. You should also be able to remove a repo without having to resort to ssh. • Design wise removing port mappings from the gui makes no sense when volume mappings remain. They are both unique and equally important. In situations like this GUI designers often have a simple/expert toggle switch. This might be the way to go as it is easier to remove something from the basic view (but keep it in expert view) than it is justify its complete removal (someone always needs it).
December 30, 201411 yr Author Stuff that for me needs thought about: • Knowing what the base OS is of each container is currently a lot of work. This is something we need to work towards presenting in the GUI. • Knowing what real size on disk a container is and the associated base OS (as you pointed out this is ridiculously complex to work out) • "We removed the "container ID" column." Is potentially a problem as it was the hook that allowed you to visually search for text on the web GUI to match what docker command line tells you. See next point. • The GUI has always struggled conceptually IMO with the fundamental docker design tenant of run the same container as many times as you like. Given what is happening is a step back redesign this should be seriously considered. Appdata folder naming should be formally standardised and designed in such as way as to be scalable and potentially snap-shot’able (whats the point of having docker power to roll forward and back the app if there is no way for the appdata to follow along with it). We may want to start using container ID as the appdata folder name and then handle upgrades with FS layers or something. I know this is no small task but we ignore it at the risk of later having to go back and start again. • Template repository’s should be handled in the same way as apps. i.e. when you add a repo you should get an icon that is clickable that pops up some words by the author, crucial links and list of the containers on offer. You should also be able to remove a repo without having to resort to ssh. • Design wise removing port mappings from the gui makes no sense when volume mappings remain. They are both unique and equally important. In situations like this GUI designers often have a simple/expert toggle switch. This might be the way to go as it is easier to remove something from the basic view (but keep it in expert view) than it is justify its complete removal (someone always needs it). Awesome feedback! Definitely understand where you're coming from, but also try to remember our need to primarily cater towards the "users" not "developers" in terms of the UI design. Knowing the base distro doesn't seem to offer any value from a "user" perspective. Having a "developer view" is an idea to address this. The point I'm making here applies to many of your requests, but there are others I agree with completely (e.g. port mappings). The one point I want to ask you to really think about is the idea of being able to run multiple concurrent instances of the same application (e.g. multiple plex instances off one container image). What is the applicable use case for the majority of unRAID users to do this? To me, most (meaning 99.999% of users) will only have a 1:1 ratio between images/containers. Where do you see the edge cases for this NOT being the case? I get that longer-term, maybe these shake out, but I'm less concerned about what Docker CAN do and more concerned about what folks are actually going to use it for the majority of the time. That said, someone could add multiple containers for a single image in this new interface and simply name them differently. As far as appdata folder naming conventions, I agree standardization is needed but that is to me a separate topic from GUI design itself at this point. Just trying to keep this thread focused on "look / feel" not "please add X functionality or capability that isn't present today."
December 30, 201411 yr something i've found in the current incarnation of dockerman, is that if i load up a docker from a template and the window gets closed mid loading etc for whatever reason, the whole unraid gui gets borxed for about 15 minutes or so.
December 30, 201411 yr Fwiw I run 2 x Couchpotato dockers. 1 to push movies into a main movies folder, and another for kids movies.
December 30, 201411 yr Author Had a few minutes and wanted to address a few more of your points: • Knowing what the base OS is of each container is currently a lot of work. This is something we need to work towards presenting in the GUI. Can you explain why this is important and for what audience? Any suggestions on how we would detect this using docker exec? Another suggestion for doing this? • Knowing what real size on disk a container is and the associated base OS (as you pointed out this is ridiculously complex to work out) I agree this would be a good thing to add but not sure we can solve this problem effectively in the downstream or if this is something we at Lime Tech should even be expending time on in development at this point. Bottom line is this is an obvious enhancement request we would like to support, but its not a bug fix or critical component to implement in the short term. • "We removed the "container ID" column." Is potentially a problem as it was the hook that allowed you to visually search for text on the web GUI to match what docker command line tells you. See next point. Not sure I understand the importance here. If you are in command line, you can get this information already. Again, the primary focus is to be a user tool, not a developer tool, although I do see a developer view mode in the future or a plugin that could achieve the same thing. • The GUI has always struggled conceptually IMO with the fundamental docker design tenant of run the same container as many times as you like. I don't think it struggles with it at all, it just doesn't address it because for 99% of users, there will be a 1:1 ratio between an application image and a container. The docker design tenant you refer to addresses devops and cloud hosting providers, not average users (my humble opinion). Appdata folder naming should be formally standardised and designed in such as way as to be scalable and potentially snap-shot’able (whats the point of having docker power to roll forward and back the app if there is no way for the appdata to follow along with it). We may want to start using container ID as the appdata folder name and then handle upgrades with FS layers or something. I know this is no small task but we ignore it at the risk of later having to go back and start again. OK, this is a different desire than being able to run multiple containers concurrently. This is a desire to support roll back of an app and its app data using the equivalent of an Apple Time Machine capability. E.g. snapshot the container and app data before an update, then let the user "click to roll back." I put this in the same category as disk consumption reporting for containers. Something we want to do, but this is an enhancement request that would take some serious effort to accomplish. Something for the roadmap. What do you mean by "later having to go back and start again"? • Template repository’s should be handled in the same way as apps. i.e. when you add a repo you should get an icon that is clickable that pops up some words by the author, crucial links and list of the containers on offer. You should also be able to remove a repo without having to resort to ssh. OK, another enhancement request to how repos can be implemented with more capability than simply adding options to the drop down when adding a container. Good idea, but not a " if we don't do this, docker on unraid is unusable or severely limited." Trying to bite development into logical, achievable short term goals. This is more lofty and would require participation by all repo owners. Not saying no, just prioritizing our focus on useable useful features first, and "icing on the cake" like this as a secondary list. • Design wise removing port mappings from the gui makes no sense when volume mappings remain. They are both unique and equally important. In situations like this GUI designers often have a simple/expert toggle switch. This might be the way to go as it is easier to remove something from the basic view (but keep it in expert view) than it is justify its complete removal (someone always needs it). This I whole heartily agree with you on. I think we pulled it at one point because we were going to change how this worked / looked and just hadn't added it back yet. It'll be readded. Again, this is a good list of feedback and would like to hear more from you on these topics. Thanks NAS and keep it coming!!!
December 30, 201411 yr Author Fwiw I run 2 x Couchpotato dockers. 1 to push movies into a main movies folder, and another for kids movies. Interesting. Why do you do it that way may I ask?
December 30, 201411 yr Author something i've found in the current incarnation of dockerman, is that if i load up a docker from a template and the window gets closed mid loading etc for whatever reason, the whole unraid gui gets borxed for about 15 minutes or so. So what is happening here is when you click off that window, its actually still running that process and the GUI is inaccessible during that. We are changing this in the redesign to prevent that.
December 30, 201411 yr something i've found in the current incarnation of dockerman, is that if i load up a docker from a template and the window gets closed mid loading etc for whatever reason, the whole unraid gui gets borxed for about 15 minutes or so. unRAID's embedded PHP don't have PCNTL, so no fork, unfortunately.... I got somewhat disappointed, I always thought that the Docker section would be better tabbed, like the Main Page, so more advanced/less used info would stay less visible. It now appear more like the Xen Manager, so maybe that's the point, maintain a certain homogeneity in the webgui. There's a lot of room to improve. The "--device" modifier would possibly allow services like printer servers or tv backends to be dockerized. CPU pinning and memory limitation should be added too, IMHO. Thanks for keeping it alive.
December 30, 201411 yr Fwiw I run 2 x Couchpotato dockers. 1 to push movies into a main movies folder, and another for kids movies. Interesting. Why do you do it that way may I ask? Because I have my sons xbmc setup with access to a share "kids movies" and it saves me manually moving kids movies from one folder to another.
December 30, 201411 yr Author Fwiw I run 2 x Couchpotato dockers. 1 to push movies into a main movies folder, and another for kids movies. Interesting. Why do you do it that way may I ask? Because I have my sons xbmc setup with access to a share "kids movies" and it saves me manually moving kids movies from one folder to another. Gotcha! Any issues with accomplishing this in our current docker implementation? I assume no. We won't prevent this in the future (it will still work as it does today).
December 30, 201411 yr Author something i've found in the current incarnation of dockerman, is that if i load up a docker from a template and the window gets closed mid loading etc for whatever reason, the whole unraid gui gets borxed for about 15 minutes or so. unRAID's embedded PHP don't have PCNTL, so no fork, unfortunately.... I got somewhat disappointed, I always thought that the Docker section would be better tabbed, like the Main Page, so more advanced/less used info would stay less visible. It now appear more like the Xen Manager, so maybe that's the point, maintain a certain homogeneity in the webgui. There's a lot of room to improve. The "--device" modifier would possibly allow services like printer servers or tv backends to be dockerized. CPU pinning and memory limitation should be added too, IMHO. Thanks for keeping it alive. CPU pinning and memory limits will be added. Cpuset is easy to apply and we have a way to set a policy to affect all containers and enable overrides on specific containers. Memory limits we haven't tested yet, but should be easy as they are supported by docker.
December 30, 201411 yr I'm very very new to unRAID and linux in general so I may somewhere in your wheelhouse of a target audience. Anyway, my comments and questions (which may be obvious to many, but bear in mind i had never heard of a docker before about a week ago) are: 1. Would it be possible to create separate input lines/entries for Template repositories (instead of one big entry box like it is now)? Also, if that's possible, perhaps a symbol of some sort (like a check mark or something) to indicate it's a valid and working link? I was attempting to use two repositories, because each one had some apps the other didn't, so I put each one on a separate line but I couldn't seem to get the second one to work. So I wasn't sure if the link was bad, or if I put it in incorrectly, or what. Plus the only way I knew that it didn't seem to be working was because when I clicked add container, the templates from my first link were there, but not the second link. Personally I think it would help make it a little more fool proof if there was a separate entry box for each repository, with some sort of visual confirmation that it's a valid and working link. 2. I'm not sure that this is possible, but is there a way to access a settings or information page from the GUI for each app? This seems to exist for some apps in dockers and not others? If we developed some sort of standard I think it would be helpful to people like myself and I'll give two examples. 2a. I have a docker running for Crashplan right now... I THINK i have it setup correctly. But to be 100% honest I have no idea if it's working or not, nor do I know how to even check if it is. And if it is running properly, I don't know how to get into it to change any settings to specify what to backup or anything. If it has a web GUI like plex, I don't even know how to get to that currently. When i click the WebGUI from the crashplan icon in the docker tab it just takes me to the crashplan website. I'm sure I'm missing something pretty dumb, or i just flat out set it up wrong. But based on what i see from the docker tab, everything looks normal and it tells me its been running for 7 days...just like my plex docker which works fine. But I can't figure how to do anything with it. 2b. I have the plex app, and there was some extra steps i had to follow to get it work. Thanks to the forum I got it working just fine.... but I think it might be helpful is developers were able to offer a set of instructions with each app that could be accessed through the GUI even after its installed. It could include FAQ's, or basic info or what ever. I was thinking this could be located under the pop-up menu that comes up with you click on the app icon on your docker page. 3. I'm not sure this is at all possible or easy, but would it be possible to add some GUI functionality to build our own Docker? For example if I have an app (say apcUPS) and I'd prefer to run it in docker then as a plugin and I have the plugin downloaded. Could the GUI walk me through taking those files and converting it to a docker for me? I think this would have use for people who have a want or need for an app that isn't currently made or supported by unRAID. If i understand correctly that's sort of the beauty of dockers right, that it allows virtually any app to run in unRAID? If so, I think if we could simplify that process for non-developers that would help expand its usefulness. It'd be nice as a novice end user to say, OK here's this app I want that's designed for Unbutu or what ever, be able to point the Docker to it, and have it walk me through making it usable as a docker in the GUI. Again I could be way off base here, but in my very basic understanding of Dockers I thought I understood this to be the case. But I honestly have no idea what goes into doing this, so it may not be a reality. 4. Overall I like all the changes you've made... it allows for a cleaner screen. 5. I think the idea of a simple and advanced view is a really good idea. 6. Is there any real reason we need access to edit the Docker Volume info? Speaking as a novice I'm not sure I need access to this or why I would ever want to change it. I'm sort of afraid I'm accidentally going to change something in it one of these times. I would think if you do a 'simple' view this could simply be pulled up a link in a pop-up menu or something much like the various options you can select from pop-ups on App icons under "Docker Apps", or its just part of a collapsing menu view or something. Anyway, that's just my initial impression based on my use of it so far. I hope it helps is some way
December 30, 201411 yr Author I'm very very new to unRAID and linux in general so I may somewhere in your wheelhouse of a target audience. Definitely fit in the target and welcome to the forums! Anyway, my comments and questions (which may be obvious to many, but bear in mind i had never heard of a docker before about a week ago) are: 1. Would it be possible to create separate input lines/entries for Template repositories (instead of one big entry box like it is now)? Cleaning this up for a future release is on the to-do list. I agree that it's a little less than intuitive now and can make it difficult to ascertain whether an issue with a repo is the result of the repo itself or the way it's been typed into the GUI. Expanding on that to support a "checkmark" for validity or availability is another feature request we could consider. All in due time, but good feedback and consistent with our theme to make this more intuitive and less cumbersome. 2. I'm not sure that this is possible, but is there a way to access a settings or information page from the GUI for each app? This seems to exist for some apps in dockers and not others? If we developed some sort of standard I think it would be helpful to people like myself and I'll give two examples. So are you asking for a shortcut link within the unRAID web interface that takes you directly to a specific app's web interface and more directly, to the settings page in that app web interface? E.g. for plex, tower:32400/web/index.html#!/settings. Is that what you mean? If so, I guess this would be possible, but seems like it's unnecessary. We already offer a way to get to the app's web interface directly by clicking on the icon and selecting "WebUI" from the drop down. No this doesn't work for all Docker apps because not all Docker apps use a WebUI, which leads me to your 2a example: 2a. I have a docker running for Crashplan right now... I THINK i have it setup correctly. But to be 100% honest I have no idea if it's working or not, nor do I know how to even check if it is. And if it is running properly, I don't know how to get into it to change any settings to specify what to backup or anything. If it has a web GUI like plex, I don't even know how to get to that currently. When i click the WebGUI from the crashplan icon in the docker tab it just takes me to the crashplan website. I'm sure I'm missing something pretty dumb, or i just flat out set it up wrong. But based on what i see from the docker tab, everything looks normal and it tells me its been running for 7 days...just like my plex docker which works fine. But I can't figure how to do anything with it. Crashplan does not have a WebUI for control and management. Instead, there is a semi-easy way to install the GUI on a Windows machine, but then point it to connecting to the app instance running on your unRAID system for management. It's not super-intuitive and longer term, I hope they change how this works (Code42 software that is). See here: http://support.code42.com/CrashPlan/Latest/Configuring/Configuring_A_Headless_Client 2b. I have the plex app, and there was some extra steps i had to follow to get it work. Thanks to the forum I got it working just fine.... but I think it might be helpful is developers were able to offer a set of instructions with each app that could be accessed through the GUI even after its installed. It could include FAQ's, or basic info or what ever. I was thinking this could be located under the pop-up menu that comes up with you click on the app icon on your docker page. There is some basic helper text that is displayed when adding a container from a template repo. That is the appropriate place to put this type of information / instructions. 3. I'm not sure this is at all possible or easy, but would it be possible to add some GUI functionality to build our own Docker? Not really possible or easy to do for what you described. Nice idea, but it's kind of like that self-driving car thing. Great idea, but LOTS of work to make that really feasible. 4. Overall I like all the changes you've made... it allows for a cleaner screen. Thanks! We're going for simplicity and removing that "intimidation factor" that folks seem to get when they see too many columns in a table ;-). 5. I think the idea of a simple and advanced view is a really good idea. Agreed. 6. Is there any real reason we need access to edit the Docker Volume info? Yes. For appdata, this could be pre-populated for you, but with Plex, for example, you need to tell it where you store your movies on the array. I DO, however, think we can make this easier in the not too distant future. Anyway, that's just my initial impression based on my use of it so far. I hope it helps is some way It does and thank you for your contribution! Feedback is always useful, especially from folks far removed from the project, as it gives a fresher perspective. Being so close to development sometimes prevents us from seeing the forest for the trees, but posts like this help us see the bigger picture more clearly.
December 30, 201411 yr Comments inline. I get bored doing all the quoting Had a few minutes and wanted to address a few more of your points: Quote from: NAS on December 29, 2014, 03:15:42 PM • Knowing what the base OS is of each container is currently a lot of work. This is something we need to work towards presenting in the GUI. Can you explain why this is important and for what audience? Any suggestions on how we would detect this using docker exec? Another suggestion for doing this? [NAS] Choice (if presented with many options this would be a key differentiator), elegance (there is a neatness from using all the same base OS) and efficiency (less base OS deviation is more efficient on disk, potentially much more efficient). I am not sure this can be done with docker command line at all other than running cat /etc/version etc on install. Another option is for the template to include a link to the dockerfile and parse it from that. This is my preferred option as it opens up the possibiltys of not leaving the GUI for advanced users that want to review. Quote from: NAS on December 29, 2014, 03:15:42 PM • Knowing what real size on disk a container is and the associated base OS (as you pointed out this is ridiculously complex to work out) I agree this would be a good thing to add but not sure we can solve this problem effectively in the downstream or if this is something we at Lime Tech should even be expending time on in development at this point. Bottom line is this is an obvious enhancement request we would like to support, but its not a bug fix or critical component to implement in the short term. [NAS] That’s fine but you need to consider the unRAID implementation of BRTFS fixed since image files makes this a bigger problem for us than others. Consider that in the proposed design if a image file is full there are is no way to really know why. This is general housekeeping not an advanced task. Quote from: NAS on December 29, 2014, 03:15:42 PM • "We removed the "container ID" column." Is potentially a problem as it was the hook that allowed you to visually search for text on the web GUI to match what docker command line tells you. See next point. Not sure I understand the importance here. If you are in command line, you can get this information already. Again, the primary focus is to be a user tool, not a developer tool, although I do see a developer view mode in the future or a plugin that could achieve the same thing. [NAS] I accept this but I do honestly think we are in danger of pushing the users out of the GUI prematurely. Quote from: NAS on December 29, 2014, 03:15:42 PM • The GUI has always struggled conceptually IMO with the fundamental docker design tenant of run the same container as many times as you like. I don't think it struggles with it at all, it just doesn't address it because for 99% of users, there will be a 1:1 ratio between an application image and a container. The docker design tenant you refer to addresses devops and cloud hosting providers, not average users (my humble opinion). [NAS] I think we have already seen people posting why they do this even in this limited time and very limited exposure thread. Here are some more examples: multiple headless kodi, polipo for local and VPN bouncing, public and private torrent, multiple nginx (revese proxy and plain www). Also there are plenty of tools in Linux that don’t have multi user/upstream service support e.g nntp proxy. Or what about people just trying out some new container feature in beta before destroying their old live setup. Also it is used for debugging in a new instance allowing support on a identical but duplicate system. Certainly most people will have a one to one relationship but it is far from all and we limit ourselves by ignoring it from day 1. Quote from: NAS on December 29, 2014, 03:15:42 PM Appdata folder naming should be formally standardised and designed in such as way as to be scalable and potentially snap-shot’able (whats the point of having docker power to roll forward and back the app if there is no way for the appdata to follow along with it). We may want to start using container ID as the appdata folder name and then handle upgrades with FS layers or something. I know this is no small task but we ignore it at the risk of later having to go back and start again. OK, this is a different desire than being able to run multiple containers concurrently. This is a desire to support roll back of an app and its app data using the equivalent of an Apple Time Machine capability. E.g. snapshot the container and app data before an update, then let the user "click to roll back." I put this in the same category as disk consumption reporting for containers. Something we want to do, but this is an enhancement request that would take some serious effort to accomplish. Something for the roadmap. What do you mean by "later having to go back and start again"? [NAS] I understand it is one for later but the on disk naming standard for appdata is a building block we need to decide now so that future development isn’t hindered by it. For example there should be no way that by mistake someone wipes/breaks an existing appdata folder because the current naming scheme uses the default container name i.e. a user creates container #2 and kills appdata #1. Quote from: NAS on December 29, 2014, 03:15:42 PM • Template repository’s should be handled in the same way as apps. i.e. when you add a repo you should get an icon that is clickable that pops up some words by the author, crucial links and list of the containers on offer. You should also be able to remove a repo without having to resort to ssh. OK, another enhancement request to how repos can be implemented with more capability than simply adding options to the drop down when adding a container. Good idea, but not a " if we don't do this, docker on unraid is unusable or severely limited." Trying to bite development into logical, achievable short term goals. This is more lofty and would require participation by all repo owners. Not saying no, just prioritizing our focus on useable useful features first, and "icing on the cake" like this as a secondary list. [NAS] You can slim the request down to being able to delete a repo which you currently cant. Quote from: NAS on December 29, 2014, 03:15:42 PM • Design wise removing port mappings from the gui makes no sense when volume mappings remain. They are both unique and equally important. In situations like this GUI designers often have a simple/expert toggle switch. This might be the way to go as it is easier to remove something from the basic view (but keep it in expert view) than it is justify its complete removal (someone always needs it). This I whole heartily agree with you on. I think we pulled it at one point because we were going to change how this worked / looked and just hadn't added it back yet. It'll be readded. Again, this is a good list of feedback and would like to hear more from you on these topics. Thanks NAS and keep it coming!!!
December 30, 201411 yr So for starters, let's go through the simple changes we've made, then we'll get into the bigger ones: [*]We now have a indicator overlay that identifies container status on top of the application icon. [*]The overlay indicators we will use are not only going to vary in color, but in shape, to ensure color blind users can recognize the status as well. [*]Icons now display in the table list of the applications as well as in the "Docker Apps" section at the top of the page (for faster recognition). [*]We've dramatically simplified the table layout for containers, removing / consolidating numerous fields. [*]Instead of using a "status" column to indicate whether or not an update is available to the container, we renamed it to "Version" and the two indicators are "current" or "update available" to simplify. [*]We removed the "ports" column, but may add that back later. [*]We removed the "control" column. [*]We removed the "container ID" column. [*]We changed the Status/Log column to just an icon. [*]We removed the "created" column. [*]We performed a number of "under the covers" code changes to improve page load performance in the webGui. Interestingly, I'd just been having thoughts on this topic earlier today! My conclusion was that it would help if there were some consistency between the docker page and the plugins page. For instance, plugins use the very clear status of 'up-to-date' - why not use the same for the dockers? I know that they're different beasts, but why not try to replicate the plugins layout for the dockers? The docker page always takes a little while to load, because it goes off to query for available updates. Do you still plan to do this, or can we have an 'unknown' status and a 'Check for Updates' button, like the plugins? Is this part of your "under the covers" performance changes? Will this 'removed' information still be available in the gui, or will we be forced to revert to command line? My view is that there is more information which could, helpfully, be added to the gui. Perhaps this is for your future discussion? For instance, will the 'status/log' icon still be able to indicate 'uptime', or will we find that information elsewhere? If you remove the 'control' column. is the only way to stop/start to click the check box and then click the action? I've never been fond of the check boxes down the left hand side, and action buttons below. This would appear to cater for applying the same action to multiple containers - but how often do you need to do this? Can you re-think this? Now I'd like to take a second to explain why we removed the "images" table. The fact is that the previous table didn't provide any additional information that was helpful or provided actionable intelligence for the user. [snip] I agree with this paragraph - the separate table has always annoyed me! Another major update that you can't see in this current screenshot is support for the tabbed view mode. After the inclusion of Dynamix in Beta12, the current Docker Manager ignores the Display Settings preference and forces the page to be rendered in "Plain" mode. In the new version, the tool will respect the user's display preference setting appropriately. Okay, it would be good to know more detail of the plans for the 'tabbed view' - what info will be presented in tabs, etc - when you get to detailed design. So why remove so much? The reality is that sometimes less is more, and in this instance, we had too many different ways to accomplish the same task (e.g. performing actions on containers is a prime example). Our goal with this refreshed design is to simplify the page and make it less "scary" for new users that aren't familiar with Docker, containers, virtualization or Linux for that matter. We have other enhancements planned to this tool that will happen over time, but those are for discussion on another day ;-). We'd love to hear feedback on this (good and bad) and hope that these changes will make for a much better user experience going forward! Thanks! I hope this helps. However, I would say that there are three major factors to consider: consistency, consistency and consistency!
December 30, 201411 yr Author Comments inline. I get bored doing all the quoting Had a few minutes and wanted to address a few more of your points: Quote from: NAS on December 29, 2014, 03:15:42 PM • Knowing what the base OS is of each container is currently a lot of work. This is something we need to work towards presenting in the GUI. Can you explain why this is important and for what audience? Any suggestions on how we would detect this using docker exec? Another suggestion for doing this? [NAS] Choice (if presented with many options this would be a key differentiator), elegance (there is a neatness from using all the same base OS) and efficiency (less base OS deviation is more efficient on disk, potentially much more efficient). I am not sure this can be done with docker command line at all other than running cat /etc/version etc on install. Another option is for the template to include a link to the dockerfile and parse it from that. This is my preferred option as it opens up the possibiltys of not leaving the GUI for advanced users that want to review. Your desire for better choice, elegance, and efficiency are all in the spirit of making the use of Docker better on unRAID. I totally get that. Eventually we should provide a way for users to see the image dependency hierarchy for their running containers. This would be not only slick and cool, it would be useful in helping users understand the footprint an application and it's dependencies put on a system. It would also help them better understand why aligning use of Containers with the same underlying base image would be optimally efficient. That said, I think the amount of efficiency to be gained here is rather minimal right now. Add every application in the repos to a Docker image and how big does it get? 20GB? 50GB? 100GB? These figures would have been unacceptable in 2005, but as we are entering 2015 where 8TB drives are available for $260 a pop, a 100GB Docker image would represent 1.25% consumption of disk space on one of those big guys. So saving $3.25 worth of storage capacity for even the most intensive users doesn't seem like something we should be focusing on right now when there are bigger fish to fry. With respect to doing something in docker exec, /cat/version isn't universally used (I don't think) by all Distros, so that isn't a valid method. Depending on the template to point to the Dockerfile is also a non-starter. What stops a container author from putting the wrong Dockerfile in the template as a link? The only way this would ever be considered for implementation would be if there was a way to detect this from the running container instance on the host. Without that, we are resorting to putting more work on container authors for very little end-user benefit. If you or anyone else can figure out a way to do that, we can consider implementing this in the shorter term. If no one has a better suggestion, as cool as this idea sounds, it's just not worth the effort right now. Quote from: NAS on December 29, 2014, 03:15:42 PM • Knowing what real size on disk a container is and the associated base OS (as you pointed out this is ridiculously complex to work out) I agree this would be a good thing to add but not sure we can solve this problem effectively in the downstream or if this is something we at Lime Tech should even be expending time on in development at this point. Bottom line is this is an obvious enhancement request we would like to support, but its not a bug fix or critical component to implement in the short term. [NAS] That’s fine but you need to consider the unRAID implementation of BRTFS fixed since image files makes this a bigger problem for us than others. Consider that in the proposed design if a image file is full there are is no way to really know why. This is general housekeeping not an advanced task. Fair enough. Will consider this in review with Eric / Tom. Quote from: NAS on December 29, 2014, 03:15:42 PM • "We removed the "container ID" column." Is potentially a problem as it was the hook that allowed you to visually search for text on the web GUI to match what docker command line tells you. See next point. Not sure I understand the importance here. If you are in command line, you can get this information already. Again, the primary focus is to be a user tool, not a developer tool, although I do see a developer view mode in the future or a plugin that could achieve the same thing. [NAS] I accept this but I do honestly think we are in danger of pushing the users out of the GUI prematurely. Not users...developers. Again, users shouldn't need the container id...ever. There is no reason for it. Developers may need it, but developers should be comfortable with command line. This is a feature request for the "developer view" or "advanced view" that we've already brought up. Quote from: NAS on December 29, 2014, 03:15:42 PM • The GUI has always struggled conceptually IMO with the fundamental docker design tenant of run the same container as many times as you like. I don't think it struggles with it at all, it just doesn't address it because for 99% of users, there will be a 1:1 ratio between an application image and a container. The docker design tenant you refer to addresses devops and cloud hosting providers, not average users (my humble opinion). [NAS] I think we have already seen people posting why they do this even in this limited time and very limited exposure thread. Here are some more examples: multiple headless kodi, polipo for local and VPN bouncing, public and private torrent, multiple nginx (revese proxy and plain www). Also there are plenty of tools in Linux that don’t have multi user/upstream service support e.g nntp proxy. Or what about people just trying out some new container feature in beta before destroying their old live setup. Also it is used for debugging in a new instance allowing support on a identical but duplicate system. Certainly most people will have a one to one relationship but it is far from all and we limit ourselves by ignoring it from day 1. Yes, some folks are doing this and sharing here today (and it works). What's the problem then? I don't understand what isn't available in the GUI today that needs to be in order to make running multiple app instances possible. It's all there and functional right now. Appdata folder naming should be formally standardised and designed in such as way as to be scalable and potentially snap-shot’able (whats the point of having docker power to roll forward and back the app if there is no way for the appdata to follow along with it). We may want to start using container ID as the appdata folder name and then handle upgrades with FS layers or something. I know this is no small task but we ignore it at the risk of later having to go back and start again. OK, this is a different desire than being able to run multiple containers concurrently. This is a desire to support roll back of an app and its app data using the equivalent of an Apple Time Machine capability. E.g. snapshot the container and app data before an update, then let the user "click to roll back." I put this in the same category as disk consumption reporting for containers. Something we want to do, but this is an enhancement request that would take some serious effort to accomplish. Something for the roadmap. What do you mean by "later having to go back and start again"? [NAS] I understand it is one for later but the on disk naming standard for appdata is a building block we need to decide now so that future development isn’t hindered by it. For example there should be no way that by mistake someone wipes/breaks an existing appdata folder because the current naming scheme uses the default container name i.e. a user creates container #2 and kills appdata #1. I see what you're getting at here. We are in active discussions on the naming conventions. I think the simple tweak for now could be that if adding a container from a template for which there is already another container based on that template present on the system, enumerate a "#" after the appdata default folder name. e.g. PlexMediaServer would be the first container default name, then PlexMediaServer2 would be the second, and so on. This would require more thought and I'm open to feedback on this, but is it any more complicated than what I'm suggesting here? • Template repository’s should be handled in the same way as apps. i.e. when you add a repo you should get an icon that is clickable that pops up some words by the author, crucial links and list of the containers on offer. You should also be able to remove a repo without having to resort to ssh. OK, another enhancement request to how repos can be implemented with more capability than simply adding options to the drop down when adding a container. Good idea, but not a " if we don't do this, docker on unraid is unusable or severely limited." Trying to bite development into logical, achievable short term goals. This is more lofty and would require participation by all repo owners. Not saying no, just prioritizing our focus on useable useful features first, and "icing on the cake" like this as a secondary list. [NAS] You can slim the request down to being able to delete a repo which you currently cant. How can you not? Isn't deleting a repo just removing the link from the template repositories? Or do you mean deleting a template that you pre-configured? Please help narrow this down for me. Thanks!
December 30, 201411 yr Running out the door so the one line answer versions: you might be bandwidth rich but most of the world isnt. For many even 1GB is a big deal. Downloading and storing 1GB of OS for a 10MB app is far from ideal especially (and this is the point) when there are usually other versions using the same base OS that cost almost nothing to use. Empower user informed choice. re base os version. We already trust our docker devs and the content they put int he template. theres no reason to stop trusting them now. A link to the dockerfile is better than the current situation where you have to dig about online. Users sometimes do need container IDs. For example thats what is in the logs. Yes they dont need them all the time but were talking about a complete removal from the GUI so even edge case uses become relevant. The problem is that the templates require users to manually change the appdata folder and the container name for each extra instance and never make a mistake doing so. It might not sound much but this if the difference between a slick safe system and one where a small user gotcha could break irreplaceable appdata. You can remove the repo from the list but all the back end files for it stay on disk going stale. Then if you re-add the repo later unpredictable things happen.
December 30, 201411 yr Author Interestingly, I'd just been having thoughts on this topic earlier today! My conclusion was that it would help if there were some consistency between the docker page and the plugins page. For instance, plugins use the very clear status of 'up-to-date' - why not use the same for the dockers? I know that they're different beasts, but why not try to replicate the plugins layout for the dockers? I think longer term, the Plugins page will conform to the Docker page, not the other way around. That said, changing the nomenclature of "current" to "up-to-date" is probably not a bad idea considering that is the existing nomenclature for which everyone is accustomed. As you say later in your post: "Consistency, consistency, consistency!" The docker page always takes a little while to load, because it goes off to query for available updates. Do you still plan to do this, or can we have an 'unknown' status and a 'Check for Updates' button, like the plugins? Is this part of your "under the covers" performance changes? Way ahead of you. Take a look: This is functional now. The docker page loads significantly faster thanks to the removal of an automatic "check for updates" every time the page is displayed. In addition, clicking "check for updates" is also significantly faster thanks to the remove of the pop-in that was used before (similar to how plugins work now). The screenshot above is off the page footer during a "check for updates." Again, the longer term plan is get Plugins to conform to this as well. The pop-in is really unnecessary for "check for updates" as it just slows down the user experience without providing any real valuable or actionable information. Will this 'removed' information still be available in the gui, or will we be forced to revert to command line? My view is that there is more information which could, helpfully, be added to the gui. Perhaps this is for your future discussion? For instance, will the 'status/log' icon still be able to indicate 'uptime', or will we find that information elsewhere? The original Docker Extended Configuration Manager project from gfjardim was definitely aligned more toward a developer audience than average users. Yes users can "figure it out" and just ignore the fields that aren't relevant to them, but for many, just having those fields displayed can be intimidating. The process for adding an app to unRAID needs to ultimately be like adding an app to your smartphone / tablet. No questions except for permissions really. The app can ask for more information post install, but the OS doesn't require that information to be provided prior to the install. That said, I agree that catering to both audiences (average users and developers) is something that we should be doing. Even Google has a "developer mode" on android for that very purpose. That said, this is really going to end up being a discussion on "display settings" and "interface customization". Example: it would probably suffice to make it possible to let users choose what columns are displayed in the Docker Containers table. The default view would be for users, but developer could then turn on additional columns for the advanced fields they want to see. That said, this is not a minor effort to develop and would take A LOT of design / coding just to implement it on Docker, then we would need to traverse the rest of the unRAID web interface and add this capability there as well. Point is: this is a future enhancement we can discuss at a later time. In addition, our plan is to conform the look/feel of Plugins, Docker, and VMs from a manageability perspective. Adding custom display settings for each of these would result in several unique columns of data per extension type (remember, unRAID extensions are Plugins, Containers, and VMs). Bottom line: there is a lot of work to be done to do this right and we want to do it, but in due time. For now, we will ask that developers do one of two things: Now all of that said, Eric and I did discuss this today and he said that adding an "advanced mode" toggle to this isn't a big request and he will do it. The advanced mode view will display the following additional data over standard view mode: Container ID (will not display this in its own column, but just as additional text under the name in the existing "application" column (we have enough vertical space to do this) Image ID (same as container ID for how it will be displayed) Uptime (will be in its own column and sortable) Created On (will be in its own column and sortable) To toggle this, Eric is going to add a similar toggle to the "autostart" field you see above but it will be in the upper right corner (essentially where gfjardim had it before). This should make you, NAS, and the others happy. Let us know if there are additional columns / data you want. We'll do the best we can do fulfill your requests. If you remove the 'control' column. is the only way to stop/start to click the check box and then click the action? I've never been fond of the check boxes down the left hand side, and action buttons below. This would appear to cater for applying the same action to multiple containers - but how often do you need to do this? Can you re-think this? Actually as you see above, we removed the checkboxes as well. No real need for that. You want to stop all your containers? Stop Docker. You want to start all your containers? Set auto-start policies then start Docker. Want to start/stop an individual container? Click the icon then click "start" or "stop" from the context menu (this will work from the Dashboard as well). The primary reason for this is to ensure multiple clicks are required to stop a container. We don't want someone accidentally clicking something and killing an important process that's running in a container. Now I'd like to take a second to explain why we removed the "images" table. The fact is that the previous table didn't provide any additional information that was helpful or provided actionable intelligence for the user. [snip] I agree with this paragraph - the separate table has always annoyed me! Glad you agree this is a change for the better! Another major update that you can't see in this current screenshot is support for the tabbed view mode. After the inclusion of Dynamix in Beta12, the current Docker Manager ignores the Display Settings preference and forces the page to be rendered in "Plain" mode. In the new version, the tool will respect the user's display preference setting appropriately. Okay, it would be good to know more detail of the plans for the 'tabbed view' - what info will be presented in tabs, etc - when you get to detailed design. The tabbed view is essentially the same as plain, but with the x-menus turned into individual tabs. The content displayed on each tab is the same from before, but we removed the Docker Apps x-menu entirely as it was redundant on that page (it's now on the dashboard for quicker accessibility). There is more planned for the dashboard and apps than I can speak to right now, so I'll just ask you to use your imagination for now ;-). Here's the new dashboard view with Apps at the top: So why remove so much? The reality is that sometimes less is more, and in this instance, we had too many different ways to accomplish the same task (e.g. performing actions on containers is a prime example). Our goal with this refreshed design is to simplify the page and make it less "scary" for new users that aren't familiar with Docker, containers, virtualization or Linux for that matter. We have other enhancements planned to this tool that will happen over time, but those are for discussion on another day ;-). We'd love to hear feedback on this (good and bad) and hope that these changes will make for a much better user experience going forward! Thanks! I hope this helps. However, I would say that there are three major factors to consider: consistency, consistency and consistency! You hit the nail on the head. We are aiming to make consistency in the webGui a top priority before we go final. That and good help text (for which there is none on the Docker page right now) and good documentation (been working on that for some time now, but it's a work in progress). Again, thanks for the feedback and let me know your thoughts on "Advanced View" mode and the newer screen shots!
December 30, 201411 yr Author Running out the door so the one line answer versions: you might be bandwidth rich but most of the world isnt. For many even 1GB is a big deal. Downloading and storing 1GB of OS for a 10MB app is far from ideal especially (and this is the point) when there are usually other versions using the same base OS that cost almost nothing to use. Empower user informed choice. Ok, so for bandwidth considerations, I will concede to your point that there are plenty of folks in the world with less than ideal internet connections. That said, check this out: http://www.netindex.com/ GLOBAL BROADBAND DOWNLOAD 21.8 Mbps UPLOAD 9.9 Mbps QUALITY 84.3 R-Factor VALUE $5.51 USD PROMISE 87.2 % These are average speeds for worldwide bandwidth. You can break these down per country too: US: 31.9mbps Canada: 25.3mbps UK: 29.8mbps Mexico: 11.9mbps Russia: 27.0mbps 1 gigabyte of data translates to 8 gigabits of bandwidth consumed. With even a 10mbps connection, that is only 13.3 minutes to download. Is that as fast as installing a mobile app on your phone / tablet? No. Is it acceptable for now? Yes. Why? Because the apps that folks can download are all designed to be used over the internet anyway. So BT Sync, Crashplan, Plex (for streaming out of your home), etc, are all apps that use your internet connection to download / upload data to others. In addition, we are working to make offerings for folks to purchase servers from Lime Technology that are pre-configured with apps, so for folks that don't want to wait for apps to download, that will be an alternative. I just don't see bandwidth as that big of an issue because where bandwidth is limited, usage of apps is probably going to be limited as well. There are a few edge cases to this, but again, let's start by designing for the masses, then we can focus on edge / corner case optimizations. Fair? Now as far as the 1GB vs. 10mb analogy, I think this is a pretty rare occurrence right now and its a trade-off for the ability to isolate the app and it's underlying software dependencies from other apps. The cost of flexibility is a sacrifice of some capacity, but for improved reliability, portability, consistency, and capability...yeah, I'll take that trade. re base os version. We already trust our docker devs and the content they put int he template. theres no reason to stop trusting them now. A link to the dockerfile is better than the current situation where you have to dig about online. Eric and I discussed this. The issue comes down to the fact that the Dockerfile doesn't specify the base distro, just the base image. So for phusion, you would have to just KNOW that phusion uses Ubuntu or we'd have to continue to traverse the "FROM" statement upwards to find the absolute base image that is initially used. In addition, Docker provides an ability to build from scratch (no base image), so what do we do there? Biggest point here is that this is really not necessary to do in the short term for it provides little value to the everyday user. Longer term, I could see us corralling developers into aligning template repos to a common base image. So instead of a repo per developer, it's a repo per base image for which multiple developers can participate and submit their apps. This is just a short-hand idea and would require much more design time to implement, which is why it is something we can look at later when we want to further optimize our Docker implementation. Again, not a short term need. Users sometimes do need container IDs. For example thats what is in the logs. Yes they dont need them all the time but were talking about a complete removal from the GUI so even edge case uses become relevant. I don't get your example. User's probably won't read logs very much except to see if there is an error, which will rarely be an image-specific issue. Sorry NAS, this is a devops need, not a user need. I have never needed a container ID and I would wager that neither has anyone else that doesn't dig deeper into containers than just the usage of the apps they support. I'll be man enough to admit I'm wrong if a bunch of folks come in here and set me straight. That said, see my reply to Peter. We are putting these back in under "advanced view" mode so you will still have access to them. The problem is that the templates require users to manually change the appdata folder and the container name for each extra instance and never make a mistake doing so. It might not sound much but this if the difference between a slick safe system and one where a small user gotcha could break irreplaceable appdata. Eric and I discussed this. The simple solution I presented is one we are considering implementing for this. Longer term, we want to have a similar approach to port mappings (e.g. if two apps are set to by default use the same port, we should not let that happen or prompt the user to fix that before letting them click "apply"). You can remove the repo from the list but all the back end files for it stay on disk going stale. Then if you re-add the repo later unpredictable things happen. Tested this out earlier since I was confused by your statement. This is a bug and will be fixed. We are also working to make template repos work similar to how you can add volume / expose mappings on the add container screen (each template repo will be in its own textbox on the gui with a "remove" button next to it). Hopefully some of the changes I've posted here today will satisfy your requests.
December 30, 201411 yr Speed is not an issue, but total bandwidth is. Even in the US nearly all fast pipes have monthly quotas on total bandwidth consumed. I'm in a balancing act each and every month and I'm even on a 100mbit pipe. In other parts of the world it is more dire.
December 30, 201411 yr Author There's a lot of room to improve. The "--device" modifier would possibly allow services like printer servers or tv backends to be dockerized. The challenge with --device is that it requires drivers to be present on the host OS (unRAID OS) to support this. For device pass through to a virtualized application instance, VMs are a better platform for this than Containers at the present moment. With VMs, we can use a generic driver (VFIO for KVM or pciback for Xen) to eliminate the need to support a wide-variety of kernel drivers directly on the host. The VMs can then supply the drivers needed directly in an underprivileged state. I agree that device pass through with Containers could be really slick (imagine GPU pass through to a SteamOS or XBMC [OpenELEC] instance using Docker), but this is definitely a ways out from even being possible. Docker would need to somehow implement support for VFIO (or their own equivalent) within the Docker Engine. I don't know if that's on their roadmap or not, but could see this as something that will eventually happen. CPU pinning and memory limitation should be added too, IMHO. Yes, this is being added.
December 30, 201411 yr Author Speed is not an issue, but total bandwidth is. Still not an issue. You don't download apps every day or every month even. The updates to containers do not represent a significant volume of bandwidth, just the initial base image downloads. Also, I would be careful making gross generalizations like this: Even in the US nearly all fast pipes have monthly quotas on total bandwidth consumed. I'm in a balancing act each and every month and I'm even on a 100mbit pipe. In other parts of the world it is more dire. Generally speaking, yes, there are limitations written into the SLAs with customers that state that if you exceed the amount, they MAY throttle you or otherwise penalize you for your overage, but I know many that have consistently gone over without penalty. The quotas enforced on most caps are in the 250GB-500GB range. So for someone to have to download even 20GB worth of apps in a single month, that's a fairly small percentage of your data cap. We have done our research on this...it is a non-issue for the majority of users. That said, eventually I still agree that having a common, thin, unRAID-optimized base image and standard approach to container development will go a long way in both helping developers work together and address this issue of bandwidth. I just don't see this as a major issue in the short term. In fact, I wouldn't put this even on the top 10 list of needs for Docker enhancement on unRAID at this point. The truth of the matter is that the "cleanliness" of using a master base image and consolidating apps that way is more of a mental desire for us as technologists who just want ultimate efficiency at all times. That said, we can strive towards that goal in the longer term, but let's not mince words: this is not a short term need.
December 30, 201411 yr So are you asking for a shortcut link within the unRAID web interface that takes you directly to a specific app's web interface and more directly, to the settings page in that app web interface? E.g. for plex, tower:32400/web/index.html#!/settings. Is that what you mean? If so, I guess this would be possible, but seems like it's unnecessary. We already offer a way to get to the app's web interface directly by clicking on the icon and selecting "WebUI" from the drop down. No this doesn't work for all Docker apps because not all Docker apps use a WebUI, which leads me to your 2a example: SNIP... There is some basic helper text that is displayed when adding a container from a template repo. That is the appropriate place to put this type of information / instructions. My response to both of these is really kind of tied together. I'm not looking for a link to a settings page within the WebUI, the link you provide is plenty good. Ideally every app would have a WebUI but I realize that's outside your control. What I'd like to see though is ideally two things. A link to help....whether its somewhere in this forum, or some support page specifically for that app. Something.... because for instance in my crashPlan example, I really didn't know where to go for help. As a novice user, not knowing if I've done it properly, I didn't really know where to turn to for help. I'm being vague here because I don't have the specific answer, but I just think it would be helpful if there was some easy way for a novice user to say Ok, I don't know whats wrong... let me press this button to get help. And to that end, on the second part of your quote. I 100% agree that helper text is displayed when adding a container and is perfect. But I'm saying it'd be nice to have a FAQ, or settings....something that the end user could pull up/refer to AFTER the app/docker has been installed. I don't expect unRAID to write this up for every app... but it'd at least be nice if there was a space for it if the community developed them for each app. This could be something added to the popup menu for each app (like where the hyperlink for WebUI is). It could just be a text document the developer has created and put in with the template or something. Maybe neither request is really the right answer. But what I'm trying to get at is from a beginners stand point getting the app installed is only about 75% of the battle....sometimes we could use a little help after the app has been successfully installed. Like with crashPlan, your help/answer made total sense. But I had no idea that was the case, if there was some sort of way that a developer could convey that information post installation from inside the GUI that would be tremendously helpful to beginners. So I'm just requesting some thought be put into how help can be provided to us from the GUI post installation is all.
December 31, 201411 yr Ok, so for bandwidth considerations, I will concede to your point that there are plenty of folks in the world with less than ideal internet connections. That said, check this out: http://www.netindex.com/ GLOBAL BROADBAND DOWNLOAD 21.8 Mbps UPLOAD 9.9 Mbps QUALITY 84.3 R-Factor VALUE $5.51 USD PROMISE 87.2 % Ha - Philippines, out in the provinces: Download 1.6Mbps Upload 0.7Mbps Quality -R-Factor Value 29.88Dollars Promise 65.0Percent Daily quota on a 1Mbps connection is 3GB.
Archived
This topic is now archived and is closed to further replies.