Hi. This summer I wrote Drupal's Plugin Manager module. It is designed to allow users to install modules and themes directly from drupal.org using local ftp or ssh. Now, after a few releases and with another person on the project (jabapyth,) I'm starting to notice the traps that we've carefully laid out for ourselves. Thus, Jabapyth and I are planning to rewrite the UI for the module. This is where I was hoping for some help. I hope for us to create an interface that is not a headache waiting to happen.
It may be that our organization is wrong. Maybe things should be named differently, or listed in a different order. Maybe it will take the usability group redesigning the entire interface to make it usable. That's fine too. Right now, these shots just show the way it looks. Since the interface is being rewritten, I believe we are open for ALL suggestions.
Note: For each "Search" page, there are two versions listed. The most recent release and current CVS. They are completely different.
This is the way the plugin manager looks when the user navigates to the plugin manager menu item, before they have given it any input whatsoever.
View CVS and Release
The next thing that a user would be likely to do is to search for a module (or theme) by name. In this particular case, 'Zen.'
View CVS and Release
Another thing the user is likely to do, is want to view the plugins by category. In this case, I chose 'Developer.'
View CVS and Release
Yet another way that users might like to view available plugins is alphabetically. Here, we chose 'K.'
View CVS and Release
Finally, the user might want to see / modify their queue.
View CVS and Release
There are a few options available that the user might want / need to set. They can set them here.
Settings Page
Also, before the user chooses to install new plugins, they might wish to queue the installation of any plugins that have versions more recent that the installed version.
Update Page
After all of this, it is time to install the selected plugins. The first thing that has to be done is the selection of a version to install. If a particular checkbox on the settings page is filled (which it is by default,) the user will not be show this page, instead, the system will default to the latest available version.
Install Page 1
After that, the user is sent to this page contain iframes of the release page. This is needed so that the user can more easily enter the md5sum for the selected package. (This is to prevent the module from falling prey to DNS Poisoning and installing something malicious.) Our hope is to be able to use cURL in a future release, allowing us to securely skip this page.
Install Page 2
On this page, the user must enter his/her username and password for either ftp or ssh, so that the module will be able to connect to the server and install the selected plugins.
Install Page 3
Finally, the user is given details about the success / failure of the install operation.
Install Page 4
Yet one more thing that the user might later want to do is uninstall anything that they have installed. This page should allow them to do so.
Uninstall Page
One more thing worth mentioning, we are moving toward an AJAX interface (that is, unless you say otherwise.) Do you believe that that will have any effect, positive or negative, on usability?
Sorry about the length of the post. I appreciate the time you've already given us.
Thanks,
Josh Rogers
Comments
Quick review
Hey, Josh
Thanks for stopping by, I think most of us would love to get involved in helping this project out. Apart from the suggestions I gave in http://groups.drupal.org/node/11678 it is hard to see what the most important interface issues are you want to tackle. I see a lot of screenshots, is it possible you just upload them on flickr or a similair service so that people can just browse trough them? (Next time do it on a Garland install, if possible)
Main page
1. As much as is this the most neutral approach to displaying all the modules, I doubt that it will be any good. Most likely we want to present them a couple of modules recommended and show them a couple of the categories. We are kinda overwhelming them from point 1, if we decide to just show a big list of items to choose from, without any guidance.
2. Revering to my comment on the other page, a user searching for a theme would want something visual.
3. Is the user to guess from the title what it does?
4. I am unsure where sorting alphabet would come in handy? I am one could come up with edge cases, but this is primarily for something where you already know or can guess the name off (Know-item seeking) in which case you would search, but for Exploratory seeking the use of alphabetic sorting is unlikely (for more about this - see http://www.bojhan.nl/task-focused-content )
5. No idea on this yet, the whole idea of a queue sounds a bit silly to me - but I could understand for who that would be helpfull.
Settings
6. You take this data out of the settings.php? Or does a user has to configure this himself?
7. Saying from what version to what version might be helpfull?
Installing
8. A drop down might be the wrong indicator for what version you are installing.
9. Just remove it, would be to much to comment upon :D.
10. Is a user supposed to specify this every single time? (Remove the note - it should only be displayed on the page where the actual process is ran)
11. Obviously this page needs a bit more if-themes. When one has selected a theme he should only be given the link where to select it. When one has enabled a module is enabled :). I think there is lot of potential for this page, to get the user to set up his modules/themes quickly, however it would require quite some re factoring.
12. Same on themes as on issue #2.
Conclusions
I quickly glanced over the interface and all its elements, but it seems to be really getting off. I think its worthy to look around in the landscape of system that does updates automatic (Windows, Apple, Wordpress). This would be a new way of interacting with Drupal.org, then just browsing modules on a site. I would love to get more involved, however its best to think about what information a person is looking for when he is using this module - not what is do-able trough drupal.org now.
What do you mean by moving towards an AJAX interface? We can't judge wheter it has a positive or negative effect, by just that :) We need thoughts!
Really appreciate you coming by this group again, hope that other people will jump in.
Re: Quick Review
I must admit, uploading the images to Flickr would have been a great idea. I'll also use Garland in the future for any screenshots.
Oh, and I have no problem with us refactoring everything if it will make for a better user experience. I don't plan on making the same mistake again! :P
There are some things we went over in http://groups.drupal.org/node/11678 that I am actually still wanting to do. I do not have an available feed to draw from at the moment for screenshots, descriptions or popularity. I actually hope to change that in the near future. (So pretend that I do have that available. That's my excuse for 1, 2 and 3. I do hope to be able to change that very soon however.)
4) Now that you've pointed it out, I can't really think of a scenario where displaying the available modules/themes by name would be very useful. That (removing it) could help the UI just a bit.
6) Actually, for the FTP path, we tried to make the plugin manager intellegently guess the correct location. I didn't think that the FTP was stored in settings.php
7) You're right. Displaying the installed and the to-be-installed version could be quite handy.
8) I should have taken this screenshot differently. The version dropdown is actually to let a user decide what version of the plugin they would like to install. Each dropdown contained a list of available candidates for installation.
9) Are you referring to the md5sum page? I would love to remove it. Unfortunately, having the user confirm the md5sums with data they get from d.o does help guard against dns poisoning attacks. I hope to be able to bypass it with cURL (on systems that support it) sometime in the future.
10) The user has to specify their username and password everytime. Storing the password could be dangerous.
My primary reason for asking about an all AJAX interface is that it would be unusable to anyone without javascript support. I didn't know if that would be likely to be a problem.
Thanks for the response!
Issues of my own
I have a few issues with the interface that I'm just not sure how to handle. Mainly with organization.
We have a search page, a manual installation page (mainly just a browse button with some backend handling.) and an update page. Each one does one thing. Search, allow a file to be uploaded and installed and show a list of plugins that have available updates. I feel as though these three are tied closely enough together that maybe, there is a better way to organize them. Maybe displaying the available updates on the search page?
Another things that bugs me just a bit is the install page. I feel like it should follow the search page, but I didn't know if that should be the only way to get to it. Should I leave it on the side menu?
The terminology seems to be awkward sometimes, but I'm not sure how to fix it. In the previous thread I know it was mentioned changing "backend" to "installation method." I really like that. I'm not sure how to clarify the rest though.
few sugestions
Hi!
I like the idea and will surely like to contribute to the project. Personally I like the wordpress plugin install and update page, its simple and easy to use. I have following queries about your initial post
1) Why you want user to enter ftp or ssh password ? You dont need this for starting downloads.
2) I am not able to understand how you identify the plugin details such as version number etc. from d.o . Is there a manifest file somewhere ?
3) Is the upgrade feature restricted to upgrading core drupal or can we upgrade installed plugins via this module ? If module upgrade is possible then it will be good to provide an indication somewhere about the available upgrades.
regards
Vivek
Re: few sugestions
1) The plugin manager module uses either ftp or ssh to install files. This is to help provide better security. (It's not a good idea to let your webserver write files that it will later execute.)
2) Each theme and module has an entry at http://updates.drupal.org/release-history/module_version/drupal_api_version. For instance, all releases of the plugin manager module for Drupal 6.x are listed at http://updates.drupal.org/release-history/plugin_manager/6.x
3) The upgrade feature shows all installed modules / themes that are out-of-date. It just so happens that the only thing that was outdated when I took the screenshot was the Drupal core.
In shared hosting
In shared hosting environment, even if you use ftp to download the files, it will be webserver that will download the files. In most shared hosting environments, the ftp user is a member of webserver group. So forcing ftp or ssh for download is not going to provide any special security, infact is going to annoy the user. Secondly we will be storing ftp/ssh credentials in a file which is a potential threat in itself.
Also, ssh introduces another level of complexity if the user is using key based login.
Waiting to hear your thoughts...
regards
Vivek
The credentials are not
The credentials are not stored, so that should not be an issue. FTP/SSH is used when uploading the extracted files to the server. Not when downloading the files. http://drupal.org/node/306210 mentions just a bit of why we are using ftp/ssh rather than simply extracting the files. Also, the user has the choice of using FTP or SSH, which is not a problem on most installations. All they really have to do is enter a username and password.
As someone who has worked in
As someone who has worked in Network Security I'm having trouble understanding how FTP and SSH is any safer than using the web server to download the files. No matter how they get to the /modules/ directory they are still executed by the web server and have the same permissions.
I considered an attacker intercepting the download with something like DNS Spoofing and making you download a malicious version of a legitimate module but this would affect both FTP and SSH as well.
The worst case scenario would actually be a malicious Drupal module intercepting the SSH login and gaining the permissions of the SSH user and lets face it a lot of people will be using root.
My other concern is I'd really like to use this module but our servers require key based login. While I could enable password based login I prefer key based and this is becoming a norm especially on Amazon EC2.
Let me know your security concerns and I'd be glad to help you as much as I can.
How is it done by Drush?
How is it done by Drush? Isn't that save enough? http://drupal.org/project/drush
Well Drush is executed
Well Drush is executed straight from the command line so it has whatever permissions your SSH/Shell user has, this could be as high as root in a worst case scenario or as a minimum it would need the same permissions as Apache (access to Drupal). In regards to Drush there is an issue about getting something similar into core http://drupal.org/node/233091
Another example is Wordpress's update function, although I haven't used it so I can't comment on exactly what it does.
I did just have something come to mind which I had originally overlooked (slap on head), you would have to give Apache write permissions so if an attacker gained a foot hole they might be able to perform an injection attack and write code to the server. It'd be good to know if this was the reason.
apache is it
Giving apache write permissions means opening up yourself to code execution via XSS etc., so that's completely out of the question. There's been several contrib modules which try to do it this way, and the security team has had to include prominent warnings on each of them since it's inherently insecure to allow apache to write to itself. While ftp + passwords isn't going to be perfect, combined with the md5 hash etc., there's a much more limited range of possible attacks.
Yeah, though it might be
Yeah, though it might be that. Such a shame.
I wonder what wordpress does, anyone know?
If memory serves...
I believe that both WordPress and Joomla both ignore the risk and attempt to write to local files. I've installed modules for different people on WP and Joomla. I know that Joomla can use FTP to install new goodies, but it's neither has ever bothered asking for any credentials.
I will agree with Sean,
I will agree with Sean, based on my experience I dont find any security in downloading modules from SSH/FTP as long as webserver is going to execute the code. Infact this approach will only annoy users. Secondly in most shared hosting environments the ftp user is same as the webserver user or ftp user is member of webserver group (for example CPanel), making no difference if you download as webserver user or you download as ftp/ssh user.
Hey Joshua, Really nice to
Hey Joshua,
Really nice to see there's work in progress on creating an install page for Drupal modules! I guess here's a to learn from how both Wordpress and Firefox deal with this.
I will create a mockup for the UI today.
All the best
A mock up will be nice..
A mock up will be nice.. will clarify lot of things.. looking forward for the mockup...
regards
Vivek
Here's a first sketch
Here are my first thoughts on the plugin manager.
WOW. THAT'S GORGEOUS! I
WOW. THAT'S GORGEOUS! I love it!
There are a few things that I'm not sure how to incorperate though.
1) Modules and themes are installed using either FTP or SSH, so the user has to enter his/her credentials before an install can take place.
2) I'm not sure how to make available updates obvious. (So that the entire list doesn't have to be searched.)
3) After removing the plugin manager menu link (or rather moving it,) I'm not sure where to place "uninstall", and "settings."
This is better looking than anything I could have imagined. :) If we can resolve those three issues, I'd love to use this as the look.
Oh, I forgot to mention that
Oh, I forgot to mention that we've been having a conversation at http://drupal.org/node/350598, trying to figure out a more suitable name for the plugin manager. If anyone wants to throw something into that conversation too, I'm all ears. ;)
Hmmm looks a lot like Adept ;)
@JoshuaRogers this is exactly what I was talking about
@skilip what'd you use to do the mock-up?
I used Photoshop for the
I used Photoshop for the mockup. What is Adept?
That's really nice and I
That's really nice and I totally agree that this needs to work in with the new module page. I really like the status button on your new module page screen shots integrated with this.
That status button states if the module needs upgrading and could be clicked to automatically perform the module update from the modules page. This would give users complete control of their modules from one page, the way it should be :)
It rockz
This UI rockz...
Plugin Manager should be a part of Modules page
Great UI here.
I would suggest the plug in manager functionality appear on admin/build/modules as a core function.
As for FTP/SSH Details, a modal dialog when clicking on 'Click to Install' to enter FTP/SSH details should be sufficient. Browsers (well fire fox at least) usually stores user names and passwords so re-entry of details (without the need to store them on-site) shouldn't be an issue.
Edit:
Attached is an edit (in B&W) of the above UI.
-Added options (to the right of the filter input field) for users to browse.
--All modules in the d.o module directory (modules compatible with the current installed version of Drupal.)
--All modules installed on the web server.
--All modules installed and activated.
--An option to browse disabled modules can be added as well.
-Re-arranged module name, rating and version numbering to improve scannability.
-Added General, Access Permissions and Block Permission options.
--The empty box (meant to be an icon) below the lorem ipsum text with the letter 'G' stands for General Options for relevant module
--B stands for Block Options
--A stands for Access Permissions
-Added a disable link for enabled modules
--Installed modules that are not active/enabled can have an 'enable' link in place of the disable link.
--If a module is not installed, an 'install' link can be used.
I really like the idea of
I really like the idea of merging both projects (this one and http://groups.drupal.org/node/10919). The only (big) problem with this is the amount of modules being displayed. Even now in D6 it is hard to manage your modules. I'll try to create a new mockup for this idea tomorrow.
Category checkboxes
With a check box for categories similar to the one in your mock up appearing on the modules page, it should help users browse faster through modules on admin/build/modules.
The module information area can also have a toggle between a condensed view of module details (no icon, ratings, description and download count.)
Attached is a mock up of the modules page with the category selector and a condensed view of module information.
The second attachment, is of the expanded view, re-arranged in a similar pattern to the condensed view.
Second attachment:
I really like this idea,
I really like this idea, [Installation Status] could also show if the module needs updating.
It can also display if an update is critical
Apart from showing available updates, additional states of installation could also be displayed such as:
-Critical security module update available (this would appear more urgent than a normal 'update available' status)
I've done a new iteration of the mock up with a radio selector on the left for filtering
-All available drupal modules
-All installed modules (enabled and disabled modules on the webserver)
-All enabled modules
-All disabled modules
-A list/history of previously module administration activity can be added as well. (not illustrated)
The module detail view switcher has been moved to the right of the filter/search bar
The G, B, A boxes (which stand for General settings, Block administration settings and Access Permission settings) can be grayed out for disabled or yet to be installed modules.
Edit: for some reason the image doesn't seem to attach itself (off-site image embed used below)
Edit:
Here's a more recent iteration with
-Module information text retained in the summarized view.
-'Module Selector' is a title that can be re-named (was 'installation state'.) into a more accurate title.
-Added an update module information link to tell drupal to check for recent updates (in the event a new module update is issued after the last cron run.)
-Moved Detailed/Summarized view toggle links.
Not to keen on the way the
Not to keen on the way the filter stretches across the top. Maybe this should be placed on the left hand side maybe under a menu "Search"
Two thoughts for this UI mock
Thought the first: I love the idea of a detailed vs. summary display for these boxes. It'll really help people narrow down what they're looking at. Just make sure that when they click between the two options, the list doesn't jump back to the top of the page, or they might have to scroll all the way down a list of 200 modules again to read the detailed description of the module they'd just found. Oh, and there's too much whitespace in the condensed version that I'm sure could be better utilized to make the 'list' display even more scannable?
Thought the second: Users don't comprehend the difference between an installed module and an enabled module. Until you've been Drupalling for at least a year, you'll assume that you have to either install/uninstall or enable/disable modules to get additional functionality on your site. Thus, I'd be VERY careful of putting both an 'enabled modules' and an 'installed modules' selection in that radio button group. It's liable to cause a lot of confusion when it's presented as a sorting selector, wheras the distinction is much more readily apparent while reading the links and icons of a Detailed View.
That said, I'm following this discussion with extreme interest, having just recently stumbled across the Plugin Manager while working with the Patterns module.
______________________________
Senpai
Joel Farris | my 'certified to rock' score
Transparatech
http://transparatech.com
619.717.2805
Forgot to mention: I've got
Forgot to mention: I've got a live version of the module page projects development. Please p.m. me for URL and login details.
Here's are the new mockups.
Here's are the new mockups. I still am not quite pleased with the scannability of the modules, compared to the mockups on the 'module page' discussion. Please do compare both ideas!!
I dont really like the
I dont really like the popups so much.... could they be jQuerized slide-down divs, below the module description?
other than that, it looks awesome.
The popups are inline
The popups are inline (http://drupal.org/project/float_window).
Amazing
Honestly, I love it. Even the popups, though I must admit that I'm not sure how well they would play with a popup-blocker. Some things might be a little overkill. Permissions are do-able. Help sounds good, but I'm not quite sure how to go about identifying configuration pages, apart from guessing about anything that it puts under /admin.
Also, what would we put under "Advanced?"
The configuration pages list
The configuration pages list are already presented on the module page project which I'm currently developing. I could send you login details of my development site.
Under advanced we could put more specific filter /search option, like this screenshot: http://pix-pack.nl/drupal/groups_images/plugin_manager_advanced_filter.png.
That's awesome can't wait to
That's awesome can't wait to see it on your demo site ;)
How about putting the ON/OFF button below the Install/Uninstall/Update
Search Functionality on the Left
I've updated the wire frames for search appearing on the left (not the best placement.)
I considered there would be an issue with differentiating the selection of categories of installed modules and modules that are not installed (in the repository.) I have addressed that by listing categories of uninstalled items under an item called 'universal list.' The wire frames below illustrates how the categories are displayed.
Browsing (not searching) only local Modules:
Browsing modules in the repository expands categories:
The above wire frames should reduce the height of the categories list as only categories of installed modules is displayed by default. The list expands when the user selects the category of Universal Modules.
The search function (not fully developed) is as follows:
-When a user selects search 'Universal Modules' for refining their search, they receive search results of modules that are in the repository and modules that are already installed (the icon used for installation status should make it easy to differentiate whats installed and not installed from the search results)
-When a user selects search 'Local Modules' for refining their search, they receive search results of only modules that are installed.
There are some furthur issues to be resolved concerning how the user refines their search results and one of Skilip's latest mock ups seems to be going in the right direction with the placement of the search criteria:
Could we have iframe-like
Could we have iframe-like scrolling for the modules, so that the filter bar & categories are always visible? (of course it wouldnt be an iframe, but a div thats the height of the browser window and has "overflow:auto")
Theres also the problem of having a crazy amount of categories....I know when I go the d.o looking for a module, i am astounded by the number of categories (and that a module can be in multiple categories...).
This might not be the place to discuss it, but could modules just be confined to one category? (then we could have between 5-10 core categories) and then....well, tagging might be a little father in the future ;)
But i think fewer categories would be an asset (or maybe sub-categories?)
Maybe another possibility
I believe the current modules page pulls off the floating bar with a little bit of css. We could probably just use that if we needed to, though I do agree, it would be nice.
And as much as it would simplify everything to just have one category, that's something that modules developers / d.o would have to enforce. I think that might be a conversation in and of itself. Until then, I'm afraid that we will just have to deal with it.
They'll probably be changing
They'll probably be changing how modules are categorized in the Drupal redesign because I don't think iteration 11 really worked it out http://drupal.markboultondesign.com/iteration11/modules.html
Separate the Admin Interfaces
I'm really tending to separate the 'module admin page' from the 'search for new modules' page, I am thinking about tabs here. With both the mockups and the ideas we currently have, things are getting too complicated. We're losing focus on what we are intending to do. We can divide this in two major aspects; 'administer modules' and 'get more modules'. To simplify the user interface we should separate this by tabs.
Still we could take much advantage, or merge, both modules functionalities. How are your thoughts on this?
Tabbing would simplify the
Tabbing would simplify the interface and make development easier.
I assume the two tabs would be:
Perhaps when both tabs have a fully developed UI, they could then be combined.
Very Nice
Is this paused due to all the UI work being done for D7?
Only suggestion I would make is to drop the dependency on float_window.
There's alot of steps to get all those JS file in place which means alot of room for error.
Instead, have you thought about using Popups API?
Not paused. Slow motion. ;)
Unfortunately, everything hinges around http://drupal.org/node/453718 being commited. (This will allow other modules to access the search results from project_solr.) The next patch http://drupal.org/node/363466#comment-1549546 relies on the first one. The second one allows for the descriptions and screenshots in search results, as well as removes the need for md5sums to be manually entered.
As soon as these go through, then I can get back to coding on the plugin manager.
module settings link
It's been about a year since the last post on this thread so I'm not sure if this conversation is going on someplace else.
I do love the mockups for the modules area shown above.... they look awesome.
One consistent problem I have with Drupal is finding the settings for any particular module. If they have a dedicated link under Site Configuration then it's no problem. But if they are some place else... perhaps Site Info, maybe the Theme... maybe just the Global Theme, maybe in Content or who knows where else... you have to hunt and peck for it all over .... VERY annoying.
I'm just voicing my desire to see a link to the page where you can modify settings for a particular module - directly on the modules page for each module.
Module builders should be expected to provide the link(s) to their settings page(s) or appropriate documentation if such a link does not apply.
I had this problem too -- and
I had this problem too -- and so I created moduleinfo: http://drupal.org/project/moduleinfo
See if it helps ;)
cheers
thx
Thx jabapyth! I just installed it and it looks great.
It's quite helpful for the modules that provide admin help or admin settings pages.