While waiting for the admin patch to finish gelling, tonight I got started on the modules page rework I want to do. First, here's the screenshot (thanks sepeck): http://www.blkmtn.org/node/347?size=_original 1) I'm using a module metadata file. It's a .ini file, because that's easy. All the discussions I've read/been involved with in the past showed the .ini file as being the least offensive of the various possibilities (of which there are many) due to the fact that it's extremely simple to code, and very familiar to use. One problem I immediately have with the .ini file, however, is translations. My best solution is to run items from the meta file through t() and modify the string grabber to grab appropriate strings from the meta file automatically? Not sure how we tag them, though. Maybe we put them as t() and then strip them? I welcome suggestions. 2) The meta file contains the following: * description (replacing the hook_help call) * version (arbitrarily filled in by module author) * package (currently: required modules, drupal core modules, contrib -- contributed modules can make stuff up if they need, but are otherwise encouraged to list themselves as contrib. *this is just an idea for now, but I think it's the easiest to get behind because it doesn't do *much* categorization but allows us to solve the problem I think needs solving). * links -- a list of administrative links (I couldn't think of a way to collect this automatically; possibly we could modify the menu system to mark them in some way which would be more consistent?) * dependencies -- (not implemented, but basically a list of modules that must be active before this module can be activated. It's a very simple dependency system and has flaws but we should start simple and improve over time rather than trying to get it completely right the first time). * drupal version -- what drupal version(s) this module works on. Only the major and minor numbers (i.e, 4.8) will be used. 4.8.x is assumed to have a stable API). 3) Given the above, I've reorganized modules by 'package'. The checkmark is moved to the left which is slightly easier. Throttle is gone entirely from here and will be its own page. The uncategorized module you see there is a module without a metafile; it will probably actually be disallowed in the future, rather than listed as uncategorized. This forces modules from 4.8 onward to have meta files, which forces a lot of useful things, such as modules only being allowed to be turned on if they have the password. I mean meta file with drupal version #. 4) Oh yea, I meant to automatically put 'help' links in the links section, but those aren't there yet. Those can appear, however, with relative ease. I'm actually much happier with what I've started than not, but I'd like to get some discussion on this. I think this is a good direction to take the module administration page. Some specific questions I have: a) Enabled modules are currently sorted only alphabetically. Should they be sorted by package, then alpha? I'm torn on this one. b) is 'drupal core modules' too long and should maybe just be 'drupal core' (and by extension, 'required' ?) c) There isn't a c) that's all I can think of just now.
Why yet another file with a .ini file? Why not simply add another hook that returns the information (as say an array)? The advantages to me are: A familiar interface Already allows use of translations Allows computed values.
Earl Miles wrote:
While waiting for the admin patch to finish gelling, tonight I got started on the modules page rework I want to do.
First, here's the screenshot (thanks sepeck): http://www.blkmtn.org/node/347?size=_original
I like the separation of required, enabled and not-enabled. However as far as the core/contrib goes.. I just realized that those terms will become less meaningful with the advent of "install profiles". Perhaps instead of splitting them into fieldsets, make the table sortable so you could sort by the "package" field (or name field)? -Rowan
1) I'm using a module metadata file. It's a .ini file, because that's easy. All the discussions I've read/been involved with in the past showed the .ini file as being the least offensive of the various
I'd still like to voice my dislike of this approach: * We've moved away from .sql to PHP .install files. * Inis are easy to parse for PHP, but PHP is even easier! * It presumes a "new" format that a developer has to know. * Your comments about translations are valid. Likewise, I don't like the idea of having multiple meta-files hanging around. There's been lots of talk about not having to load in help files for every module load, and that means sticking them in an external file. I'd hate to have an .ini, a .help, an .install, and a .module. There should be a .module (the code), an .install (get the code running) and a .meta (or whatever, to describe the code). -- Morbus Iff ( masochism-oriented recombinant bot (unlisted series) ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Morbus Iff wrote:
1) I'm using a module metadata file. It's a .ini file, because that's easy. All the discussions I've read/been involved with in the past showed the .ini file as being the least offensive of the various
* We've moved away from .sql to PHP .install files. * Inis are easy to parse for PHP, but PHP is even easier! * It presumes a "new" format that a developer has to know. * Your comments about translations are valid.
All of these are valid.
Likewise, I don't like the idea of having multiple meta-files hanging around. There's been lots of talk about not having to load in help files for every module load, and that means sticking them in an external file. I'd hate to have an .ini, a .help, an .install, and a .module. There should be a .module (the code), an .install (get the code running) and a .meta (or whatever, to describe the code).
Where'd you get that there'd be a .ini and a .help, etc? I only have one .meta file and it never even occurred to me that there might be multiple meta files. This confuses me.
* The page is too wide. I /hate/ tables that are meant to be single lines that then wrap (yes, that drupal.module description assaults my sensibilities every time!). Remove the word "modules" from the package name. We know we're on the modules page.
Are you saying this just because sepeck took his screenshot at an unusually wide browser width? Otherwise, I don't get what you mean by 'too wide'.
* I'm not sure I "get" the links thing. Why should they be in here?
Many (many many many) have said that they feel the most logical place to look to administrate a module is in the modules section. And it makes a great deal of sense to me as well. I consider this an additional set of links to a module's administration pages. It makes things easier to find by providing an alternate path.
* Why is help greyed out? In fact, I don't "get" what the greyed / active checkboxes are for? What's the purpose of this entirely new and unfamiliar UI element?
It's greyed out in the 'enable modules' section because you can't enable an already enabled module.
* I don't like the "required modules" section. It doesn't seem important to have this bit of information break from the alphabetical listing of the modules page. To some degree, I wonder if we even should list these modules /at all/. If they're so important as to be absolutely required (yes), then why should the user need to know about them? They are as necessary as bootstrap.inc, so should be as invisible as that. This can reduce the size of the page too.
I'd never really thought about simply hiding the required modules entirely. I'm not sure that's completely a good idea, but I'm not against it, either. What are other opinions?
* The version number is irrelevant and useless for a huge number of reasons. One, users don't upgrade core modules with out updating core, so there's no reason to have the version number for every damn line. Two, contrib modules don't have version information at all. A views.module that is a 4.8.0 release doesn't tell me anything when your July 2006 version is miles better than your January 2006 version. Here, you're using version to mean Compatibility, and if that's what we're aiming for, we need big red warning letters, not a string of numbers that can get lost in a column of duplicates.
This is a step toward allowing contrib to *have* version numbers. And no, I'm not using version to mean compatibility, it's just that core modules are going to have all the same version numbers. But as I said, what a contrib module puts there *is arbitrarily set by the author*. So even without the nice product release system, at least with this a module author can set a version number in a module's release, and when some commits go in, increase the version number. Now, when bug reports are filed, the module version number can be reported. Please, tell me again this is a bad thing.
* "drupal core modules" -> "core modules". Think Civicspace.
Well if I do away with the word 'modules' in the list (go all the way back to the top of this message) as you suggested, that's just 'core' and a little too short. Also, I think 'drupal core' is more descriptive. I like moshe's suggestion that 'drupal' could maybe be replaced by the install profile name or descriptor, perhaps. But even if you're using Civicspace, there are still drupal core and civicspace core modules and they are different things, and personally I'd want them categorized differently. It makes upgrading Drupal a little easier.
a) Enabled modules are currently sorted only alphabetically. Should they be sorted by package, then alpha? I'm torn on this one.
If the packages mean anything to contrib, then yes. This would be how ecommerce and CCK and og would stick together on the page, no?
Yea, this was a silly question and I knew the answer was yes as soon as I typed it.
Nice step forward, Earl. On Jul 29, 2006, at 12:18 PM, Earl Miles wrote:
It's greyed out in the 'enable modules' section because you can't enable an already enabled module.
I suggest filtering the enabled modules out of these lists completely. I.e. enabling a module moves it up to the enabled section, so the only thing listed below is disabled modules. This gets rid of greyed checkboxes in the lower section, as well as a bunch of duplicate info on the page.
I'd never really thought about simply hiding the required modules entirely. I'm not sure that's completely a good idea, but I'm not against it, either. What are other opinions?
I think it's a good idea. Whether some functionality is implemented in a required module or somewhere else in drupal core is completely irrelevant to the users of drupal, no? I'd completely get rid of the required modules from the modules page. This gets rid of more greyed checkboxes. I suppose a "Show required modules" checkbox somewhere, un-checked by default, would be even better.
This is a step toward allowing contrib to *have* version numbers. And no, I'm not using version to mean compatibility, it's just that core modules are going to have all the same version numbers. But as I said, what a contrib module puts there *is arbitrarily set by the author*. So even without the nice product release system, at least with this a module author can set a version number in a module's release, and when some commits go in, increase the version number. Now, when bug reports are filed, the module version number can be reported. Please, tell me again this is a bad thing.
With Derek's (and others) work to real versions/releases for contrib, this is clearly an essential piece of info.
a) Enabled modules are currently sorted only alphabetically. Should they be sorted by package, then alpha? I'm torn on this one. If the packages mean anything to contrib, then yes. This would be how ecommerce and CCK and og would stick together on the page, no?
Yea, this was a silly question and I knew the answer was yes as soon as I typed it.
Going with my first suggestion to remove enabled modules from the lower section, turning it into a disabled modules section, why not have a consistent layout for enabled and disabled sections? Either include a packages column and put them all in one table (as you have for enabled modules) or put them in separate sections and leave out the packages column. The latter allows you to collapse a section and hide details, the former would allow the possibility of a user specified sort. My 2 cents, Ray
Earl Miles schrieb:
Morbus Iff wrote:
[snip]
* I'm not sure I "get" the links thing. Why should they be in here?
Many (many many many) have said that they feel the most logical place to look to administrate a module is in the modules section. And it makes a great deal of sense to me as well. I consider this an additional set of links to a module's administration pages. It makes things easier to find by providing an alternate path.
+1 on the links. This can save so many clicks in some situations, especially together with the reorganized administration. We just offer another way to get where you want to get, without confusing people. What can we want more than to make life easier for some people without confusing others ;)
* I don't like the "required modules" section. It doesn't seem important to have this bit of information break from the alphabetical listing of the modules page. To some degree, I wonder if we even should list these modules /at all/. If they're so important as to be absolutely required (yes), then why should the user need to know about them? They are as necessary as bootstrap.inc, so should be as invisible as that. This can reduce the size of the page too.
I'd never really thought about simply hiding the required modules entirely. I'm not sure that's completely a good idea, but I'm not against it, either. What are other opinions?
Hmm, I won't hide them completely. They could be in a table that is collapsed by default, but I don't like hiding things that are there from people. They are modules, they have their .module file, so they should appear in the module listing. Becaue they're modules (and not .inc files or something). For example, it might be interesting to have them on the module table at least to have the links to administration and help, and the description. regards, frando
Frando (Franz Heinzmann) wrote:
Hmm, I won't hide them completely. They could be in a table that is collapsed by default, but I don't like hiding things that are there from people. They are modules, they have their .module file, so they should appear in the module listing. Becaue they're modules (and not .inc files or something). For example, it might be interesting to have them on the module table at least to have the links to administration and help, and the description. Can you come up with a real use for them? Having them there just because they exist seems gratuitous. It's not like they're really hidden - anyone who cares can look at the directory or docs. Given that the primary user stories for this page are to enable or disable modules, there would need to be a secondary story as to why a person might go to the modules page to do something with these modules. Neither administration nor help seem compelling, as it's not clear why someone would go to the module listing to get at those. Also, the mapping isn't one-to-one. Watchdog gets configured with the other system settings but also has its own page, while user has two separate settings pages. Letting the module organization determine the UI is letting the tail wag the dog.
Gary
Where'd you get that there'd be a .ini and a .help, etc? I only have one .meta file and it never even occurred to me that there might be multiple meta files. This confuses me.
Logical assumption. If { module help becomes its own separate file } and { module help requires PHP (often the case) } and { .ini files are for non-php meta data } then { we need a new .help file format } If we make a PHP-enabled .meta file, however, meta data (your .ini) and any eventual attempts to streamline the help system into an external file can be shoved into there too. I'm thinking about design for the future here.
Are you saying this just because sepeck took his screenshot at an unusually wide browser width? Otherwise, I don't get what you mean by 'too wide'.
No. Sentences that break apart like this. Are really annoying. We should strive for a modules page where a single sentence that doesn't wrap is a grande possibility. It makes scanning and reading a lot easier, and encourages strong design and understanding of the module itself (if you can't describe your module in a single sentence, you don't have a firm grasp of your module enough, IMO).
* Why is help greyed out? In fact, I don't "get" what the greyed / active checkboxes are for? What's the purpose of this entirely new and unfamiliar UI element?
It's greyed out in the 'enable modules' section because you can't enable an already enabled module.
Ok, then the corollary is, why is comment.module, in the enabled modules section, not greyed out?
This is a step toward allowing contrib to *have* version numbers. And no, I'm not using version to mean compatibility, it's just that core modules are going to have all the same version numbers. But as I said, what a contrib module puts there *is arbitrarily set by the author*. So
Thanks for the clarification.
Well if I do away with the word 'modules' in the list (go all the way back to the top of this message) as you suggested, that's just 'core' and a little too short. Also, I think 'drupal core' is more descriptive.
Why? Developers refer to "core" all the time. Anyways, distro name makes some degree of sense. -- Morbus Iff ( omnia mutantur, nihil interit ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Are you saying this just because sepeck took his screenshot at an unusually wide browser width? Otherwise, I don't get what you mean by
Some screenshots to prevent the thousand words thing. Low quality. wordwrap.jpg: An example of our current modules screen at a small width. The yellow areas are hideous to me - the word wrapping of one word is bad, and harms readability, IMO. The extra columns and links in your screenshot would make word wrapping common place. gallery2_before.jpg: The gallery2 plugin screen. Notice the three install states that you may have heard Earl and I talking about in the past. Per the Wordpress screenshot, these are actually links, not buttons, but same diff. gallery2_after.jpg: After clicking the "install" link, three things happen at once. First, "zip download" row is highlighted green temporarily (not shown in this screenshot - it fades out). A notice appears at the top of the page, also in green, which also fades out. Also, the links turn from "install" to "activate" and "uninstall". Also note that the state of the icons replaces the visual "enabled check in a checkbox". It actually appears Gallery 2 has five states: install, activate, deactivate, uninstall, and a rare "configure" (for when you activate a module but it /requires/ admin configuration before it will do anything useful). I'm not sure we need to deviate from our three states (most of our modules require some sort of configuration before use). -- Morbus Iff ( rootle-dee-tootle-dee-toot! ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On Saturday 29 July 2006 13:36, Morbus Iff wrote:
Are you saying this just because sepeck took his screenshot at an unusually wide browser width? Otherwise, I don't get what you mean by
Some screenshots to prevent the thousand words thing. Low quality.
wordwrap.jpg: An example of our current modules screen at a small width. The yellow areas are hideous to me - the word wrapping of one word is bad, and harms readability, IMO. The extra columns and links in your screenshot would make word wrapping common place.
I'm sure I'm going to ruffle some feathers here, but I don't mind descriptions that take up more than one line. While I agree that a module designer should be able to clearly and consicly describe their module, I think there are far too many who go to the other extreme and don't put enough words in the description to state what the module's purpose is. -- Jason Flatt http://www.oadae.net/ Father of Six: http://www.flattfamily.com/ (Joseph, 13; Cramer, 11; Travis, 9; Angela; Harry, 5; and William, 12:04 am, 12-29-2005) Linux User: http://www.sourcemage.org/ Drupal Fanatic: http://drupal.org/
Jason Flatt wrote:
I'm sure I'm going to ruffle some feathers here, but I don't mind descriptions that take up more than one line. While I agree that a module designer should be able to clearly and consicly describe their module, I think there are far too many who go to the other extreme and don't put enough words in the description to state what the module's purpose is.
I'm with you on this one, and so far am unswayed. Popular opinion might sway me, but Morbus' passion so far does not.
I'm definitely in support of the Gallery 2 module model. It's far superior to the Drupal one. I believe the new layout, while looks ok, is way too wide (for some layouts). May I suggest the following: Name|Description >>|Links Clicking on the >> presents the following: Name|Description <<|Links | Version: 4.8.0 | | Package: blah | Cheers, -- Sammy Spets Synerger Pty Ltd http://www.synerger.com/ On 29-Jul-06 16:36, Morbus Iff wrote:
Are you saying this just because sepeck took his screenshot at an unusually wide browser width? Otherwise, I don't get what you mean by
Some screenshots to prevent the thousand words thing. Low quality.
wordwrap.jpg: An example of our current modules screen at a small width. The yellow areas are hideous to me - the word wrapping of one word is bad, and harms readability, IMO. The extra columns and links in your screenshot would make word wrapping common place.
gallery2_before.jpg: The gallery2 plugin screen. Notice the three install states that you may have heard Earl and I talking about in the past. Per the Wordpress screenshot, these are actually links, not buttons, but same diff.
gallery2_after.jpg: After clicking the "install" link, three things happen at once. First, "zip download" row is highlighted green temporarily (not shown in this screenshot - it fades out). A notice appears at the top of the page, also in green, which also fades out. Also, the links turn from "install" to "activate" and "uninstall". Also note that the state of the icons replaces the visual "enabled check in a checkbox".
It actually appears Gallery 2 has five states: install, activate, deactivate, uninstall, and a rare "configure" (for when you activate a module but it /requires/ admin configuration before it will do anything useful). I'm not sure we need to deviate from our three states (most of our modules require some sort of configuration before use).
-- Morbus Iff ( rootle-dee-tootle-dee-toot! ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Earl Miles wrote:
Morbus Iff wrote:
I'd never really thought about simply hiding the required modules entirely. I'm not sure that's completely a good idea, but I'm not against it, either. What are other opinions?
Hiding required modules (if they are really, REALLY required) seems like a good idea to me.
* The version number is irrelevant and useless for a huge number of reasons.
This is a step toward allowing contrib to *have* version numbers. And no, I'm not using version to mean compatibility, it's just that core modules are going to have all the same version numbers. But as I said, what a contrib module puts there *is arbitrarily set by the author*. So even without the nice product release system, at least with this a module author can set a version number in a module's release, and when some commits go in, increase the version number. Now, when bug reports are filed, the module version number can be reported. Please, tell me again this is a bad thing.
I cannot disagree with Morbus any more vehemently. I've been trying to get some kind of version identification feature for modules for over 2 years. I waste way the hell too much time trying to remember wtf version of a site and contrib modules I'm running on a site that I administer from time to time. Having it all listed on the modules page is fantastic and will save me lots of time and headaches in the future. (And yes, we need contrib modules to have version numbers.) ..chrisxj
Chris Johnson wrote:
I cannot disagree with Morbus any more vehemently. I've been trying to get some kind of version identification feature for modules for over 2 years. I waste way the hell too much time trying to remember wtf version of a site and contrib modules I'm running on a site that I administer from time to time. Having it all listed on the modules page is fantastic and will save me lots of time and headaches in the future. (And yes, we need contrib modules to have version numbers.)
I think Morbus got this one, having not quite understood it at first, and is basically on board with it, except perhaps for the default versioning of core modules.
I cannot disagree with Morbus any more vehemently. I've been trying to get some kind of version identification feature for modules for over 2 years. I waste way the hell too much time trying to remember wtf version of a site and contrib modules I'm running on a site that I administer from time to time. Having it all listed on the modules page is fantastic and will save me lots of time and headaches in the future. (And yes, we need contrib modules to have version numbers.)
I think Morbus got this one, having not quite understood it at first, and is basically on board with it, except perhaps for the default versioning of core modules.
I'm fine with the core modules being Drupal release ver. -- Morbus Iff ( god less america ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Morbus Iff schrieb:
1) I'm using a module metadata file. It's a .ini file, because that's easy. All the discussions I've read/been involved with in the past showed the .ini file as being the least offensive of the various
I'd still like to voice my dislike of this approach:
* We've moved away from .sql to PHP .install files. * Inis are easy to parse for PHP, but PHP is even easier! * It presumes a "new" format that a developer has to know. * Your comments about translations are valid.
Likewise, I don't like the idea of having multiple meta-files hanging around. There's been lots of talk about not having to load in help files for every module load, and that means sticking them in an external file. I'd hate to have an .ini, a .help, an .install, and a .module. There should be a .module (the code), an .install (get the code running) and a .meta (or whatever, to describe the code).
I don't see the difference. I think it can ease a lot of pain to strip out things in different files. Especially if you're not yet too familiar with the piece of code you want to deal with. You find the pieces of code faster, and if you just want to edit the description of a module, or the help texts, you don't have to deal with the "real" code. So I'm for the meta files, and I don't mind wether they are ini or php, I think both is fine, as long as it's seperate file.
Generic comments: * The page is too wide. I /hate/ tables that are meant to be single lines that then wrap (yes, that drupal.module description assaults my sensibilities every time!). Remove the word "modules" from the package name. We know we're on the modules page. * I'm not sure I "get" the links thing. Why should they be in here? * Why is help greyed out? In fact, I don't "get" what the greyed / active checkboxes are for? What's the purpose of this entirely new and unfamiliar UI element? * I don't like the "required modules" section. It doesn't seem important to have this bit of information break from the alphabetical listing of the modules page. To some degree, I wonder if we even should list these modules /at all/. If they're so important as to be absolutely required (yes), then why should the user need to know about them? They are as necessary as bootstrap.inc, so should be as invisible as that. This can reduce the size of the page too. * The version number is irrelevant and useless for a huge number of reasons. One, users don't upgrade core modules with out updating core, so there's no reason to have the version number for every damn line. Two, contrib modules don't have version information at all. A views.module that is a 4.8.0 release doesn't tell me anything when your July 2006 version is miles better than your January 2006 version. Here, you're using version to mean Compatibility, and if that's what we're aiming for, we need big red warning letters, not a string of numbers that can get lost in a column of duplicates. * "drupal core modules" -> "core modules". Think Civicspace.
a) Enabled modules are currently sorted only alphabetically. Should they be sorted by package, then alpha? I'm torn on this one.
If the packages mean anything to contrib, then yes. This would be how ecommerce and CCK and og would stick together on the page, no? -- Morbus Iff ( take this ming! i'm sick of your dynasty! ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
looks like a big improvement to me. if you are into experimenting, i would try this out with just a table and no fieldsets. use subtabs for things like 'contrib', 'installed'. the default should show lots of modules i would think, like today.
* I don't like the "required modules" section. It doesn't seem
yeah, i think this can go.
* The version number is irrelevant and useless for a huge number
um, version is one of the main benefits of this. i like being able to look at my installed modules and then http://drupal.org/project/Modules and see if i am up to date. i'm all for metadata and ini format. jjeff is over here asking for icons for modules. even a tiny icon and a big icon. i reckon those would be metadata fields. personally, i think i like alpha by package first. as for 'drupal core', i think you want to follow the lead of the installer. i think even the word 'drupal' is a variable pointing to the name of the install profile.
On 29 Jul 2006, at 18:00, Moshe Weitzman wrote:
looks like a big improvement to me. if you are into experimenting, i would try this out with just a table and no fieldsets. use subtabs for things like 'contrib', 'installed'. the default should show lots of modules i would think, like today.
Here is WordPress' forthcoming plugin manager: http://www.brokenkode.com/wp-content/uploads/2006/05/Plugins.jpg My first impression is that it a lot easier to the eye than Earl's proposal. - The module names are links that take you to the corresponding settings page. - They are not using checkboxes but buttons. -- Dries Buytaert :: http://www.buytaert.net/
Dries Buytaert wrote:
On 29 Jul 2006, at 18:00, Moshe Weitzman wrote:
looks like a big improvement to me. if you are into experimenting, i would try this out with just a table and no fieldsets. use subtabs for things like 'contrib', 'installed'. the default should show lots of modules i would think, like today.
Here is WordPress' forthcoming plugin manager:
http://www.brokenkode.com/wp-content/uploads/2006/05/Plugins.jpg
My first impression is that it a lot easier to the eye than Earl's proposal.
- The module names are links that take you to the corresponding settings page.
This is an interesting idea. I'm not sure whether or not it's better than having the settings be a separate link (because making the module name a link doesn't make it clear -- to me, at least -- where it goes.) That said, I also have no problems with it, and would happily implement it that way if people like it.
- They are not using checkboxes but buttons.
I was originally going to change the checkboxes to buttons, but then I realized: What if I want to enable 4 modules at once? Enabling them one at a time would be kind of annoying. My thoughts are that the data is very much the same, even almost in the same order, but Drupal's default table theming is very harsh, while the Wordpress theming is very soft, and extremely well laid out (I'll notice that a lot of care was placed on the negative space on those pages) -- something that it takes someone with a really good eye + CSS/HTML knowledge to really do right. That, to me, points to a dedicated administrative theme (which I am pushing pretty hard as something we could use.)
This is an interesting idea. I'm not sure whether or not it's better than having the settings be a separate link (because making the module name a link doesn't make it clear -- to me, at least -- where it goes.) That said, I also have no problems with it, and would happily implement it that way if people like it.
i like the title as hyperlink
- They are not using checkboxes but buttons.
I was originally going to change the checkboxes to buttons, but then I realized: What if I want to enable 4 modules at once? Enabling them one at a time would be kind of annoying.
i think multi module upload is quite infrequent, and not all that painful. buttons work for me. please consider the subtabs as i suggested. they might not work as well, but i have a feeling they will look nicer than fieldsets
On 7/29/06, Moshe Weitzman <weitzman@tejasa.com> wrote:
This is an interesting idea. I'm not sure whether or not it's better than having the settings be a separate link (because making the module name a link doesn't make it clear -- to me, at least -- where it goes.) That said, I also have no problems with it, and would happily implement it that way if people like it.
i like the title as hyperlink
Yes, but a link to what? A module description? Its version? Updates to the module? Help on the module? It is not obvious.
- They are not using checkboxes but buttons.
I was originally going to change the checkboxes to buttons, but then I realized: What if I want to enable 4 modules at once? Enabling them one at a time would be kind of annoying.
i think multi module upload is quite infrequent, and not all that painful. buttons work for me.
Infrequent later in the process, but for a new install, several have to be clicked. So, new users are required to click many buttons and have many page reloads.
On Jul 29, 2006, at 1:20 PM, Earl Miles wrote:
I was originally going to change the checkboxes to buttons, but then I realized: What if I want to enable 4 modules at once? Enabling them one at a time would be kind of annoying.
Tradeoffs ... I agree with the above, but on the other hand enabling/ disabling a single module is much nicer with a button. It's annoying to have to check a box and then go scrolling to find the submit button. Is there a way to have both without it being too cluttered? I'm thinking of the phpMyAdmin display of a table where there is a check box and edit/delete buttons (icons actually) in each individual rows, with a set of buttons below the table to apply to all checked rows at once. Just an idea, Ray
I was originally going to change the checkboxes to buttons, but then I realized: What if I want to enable 4 modules at once? Enabling them one at a time would be kind of annoying.
No, no. I can hook you up with a Gallery 2 admin demo if you'd like. Basically, for Gallery 2, when you click activate, it's all AJAX'd or what have you. A little message says "<name> activated" at the top of the screen, and that's it. The word "activate" then changes to "deactivate" (and, in Gallery 2's case, adds "uninstall"). You never actually leave the screen, and can enable/disable modules at once. -- Morbus Iff ( be realistic. demand the impossible. ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Morbus Iff wrote:
I was originally going to change the checkboxes to buttons, but then I realized: What if I want to enable 4 modules at once? Enabling them one at a time would be kind of annoying.
No, no. I can hook you up with a Gallery 2 admin demo if you'd like. Basically, for Gallery 2, when you click activate, it's all AJAX'd or what have you. A little message says "<name> activated" at the top of the screen, and that's it. The word "activate" then changes to "deactivate" (and, in Gallery 2's case, adds "uninstall"). You never actually leave the screen, and can enable/disable modules at once.
That's nice but 1) any js guys willing to set that up and 2) does it degrade reasonably and 3) would the js pass Steven's code review? Other than that, sure, great idea. =)
[For onlookers, I sent a posting with screenshots that has been moderated by the list. Not sure if it'll make it through, but...]
1) any js guys willing to set that up and 2) does it degrade reasonably and 3) would the js pass Steven's code review?
Sounds like another one of those "Here's why jQuery would be a great addition to core. Look how easy this is!" things. -- Morbus Iff ( for safety's sake, don't humiliate me ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On 29 Jul 2006, at 22:39, Morbus Iff wrote:
[For onlookers, I sent a posting with screenshots that has been moderated by the list. Not sure if it'll make it through, but...]
I'll moderate it so it comes through. At your service, -- Dries Buytaert :: http://www.buytaert.net/
Morbus Iff schrieb:
[For onlookers, I sent a posting with screenshots that has been moderated by the list. Not sure if it'll make it through, but...]
1) any js guys willing to set that up and 2) does it degrade reasonably and 3) would the js pass Steven's code review?
Sounds like another one of those "Here's why jQuery would be a great addition to core. Look how easy this is!" things.
I totally agree. I think, we really should push the integration of jQuery into core forward right now, and not later, because it would be useful for many pieces of ui improvement. more information here: http://drupal.org/node/69786 regards, frando
I totally agree. I think, we really should push the integration of jQuery into core forward right now, and not later, because it would be useful for many pieces of ui improvement.
more information here: http://drupal.org/node/69786
AFAIK, the holdup is not on our side but in the completion of jQuery 1.0, which is currently in testing. I've used the patched jQuery with the patched copy of Drupal HEAD, and things seem to work very smoothly. Whether we're in a position to push forward before the 'final' version of jQuery is ready though... I'm not sure. --Jeff
Dries Buytaert wrote:
On 29 Jul 2006, at 18:00, Moshe Weitzman wrote:
looks like a big improvement to me. if you are into experimenting, i would try this out with just a table and no fieldsets. use subtabs for things like 'contrib', 'installed'. the default should show lots of modules i would think, like today.
Here is WordPress' forthcoming plugin manager:
http://www.brokenkode.com/wp-content/uploads/2006/05/Plugins.jpg
My first impression is that it a lot easier to the eye than Earl's proposal.
- The module names are links that take you to the corresponding settings page.
Not sure this is an improvement, it isn't really clear or intuitive. Maybe an extra column for this?
- They are not using checkboxes but buttons.
-- on buttons. Each button will need to trigger a page reload and enabling more than two or three modules will be a pain. Cheers, Gerhard
Earl/Steven P Screenshot is too wide. My laptop is set to 1024x768 and only part of the screen shot was showing.
On 29 Jul 2006, at 18:00, Moshe Weitzman wrote:
looks like a big improvement to me. if you are into experimenting, i would try this out with just a table and no fieldsets. use subtabs for things like 'contrib', 'installed'. the default should show lots of modules i would think, like today.
Here is WordPress' forthcoming plugin manager:
http://www.brokenkode.com/wp-content/uploads/2006/05/Plugins.jpg
My first impression is that it a lot easier to the eye than Earl's proposal.
- The module names are links that take you to the corresponding settings page.
Not sure this is an improvement, it isn't really clear or intuitive. Maybe an extra column for this?
I am with Gerhard on this. I hate non obvious settings. This sacrifices clarity for the sake of screen real estate. An explicit settings link would be best. If thereare objections to it then a title tag that says "settings for xxx module" is a must.
- They are not using checkboxes but buttons.
-- on buttons. Each button will need to trigger a page reload and enabling more than two or three modules will be a pain.
Again I agree. Buttons allow only one module to be enabled/disabled. That is a step backwards from what we have today.
-- on buttons. Each button will need to trigger a page reload and enabling more than two or three modules will be a pain.
I can give you a Gallery 2 demo too if you'd like. -- Morbus Iff ( be realistic. demand the impossible. ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Here is WordPress' forthcoming plugin manager: http://www.brokenkode.com/wp-content/uploads/2006/05/Plugins.jpg
This looks very much like Gallery 2's plugin manager, which I love. That's where my (and I believe Earl has plans to mimick this too) "activate", "deactivate" and "uninstall" scheme comes from. -- Morbus Iff ( be realistic. demand the impossible. ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Moshe Weitzman wrote:
looks like a big improvement to me. if you are into experimenting, i would try this out with just a table and no fieldsets. use subtabs for things like 'contrib', 'installed'. the default should show lots of modules i would think, like today.
My very first experiment used the javascript tabs, and I believe I am leaning toward going back to using normal tabs for that, but there's a lot of ideas coming at me and putting them all together could be tricky. 1) module status -- I hadn't gotten to that part yet, but there's a lot of potential for Great Good here by including a hook to let modules say if critical things need to be done. Also, it'd be an ideal place to record that update.php needs to be run for modules. 2) Hide required modules. I'm getting mixed response to this so far, there is some interest in retaining this data, some interest in hiding it. I'm on the fence at this time. 3) Reducing the lists to, perhaps, 'enabled modules', 'disabled modules' (note that I intend to have two actual status' there: disabled and uninstalled; disabled is not on but might have data (schema) in the system still, uninstalled does not have data in the system). Disabled modules, then, won't include the enabled modules at all. A 3rd table could list the required modules, which'd basically be there for information purposes. But then, removing them from the enabled modules list might be problematic as well. 4) Displaying said tables more like this: required modules node field field etc user etc ... drupal core aggregator ... archive ... blog ... ... contrib devel ... views ... ... ecommerce product ... store ... ... All in the same table. Of course, if package is just a field, we could implement click-sorting and the user could alphabetize the modules or sort them by package. Maybe we could even sort by status or some such.
* The version number is irrelevant and useless for a huge number
um, version is one of the main benefits of this. i like being able to look at my installed modules and then http://drupal.org/project/Modules and see if i am up to date.
Um, it's obvious you missed my point. Currently, the version number in his screen is for the major release of Drupal. Modules have many many smaller releases during the life cycle of a Drupal release. Knowing that a module has been released for 4.8.0 doesn't mean you have the latest version, because active development of a module could mean that you're out of date within a week. Basing module numbers off the core version doesn't allow any indication of module version and is thus useless. -- Morbus Iff ( i am the sexy alpha geek ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Morbus Iff wrote:
* The version number is irrelevant and useless for a huge number
um, version is one of the main benefits of this. i like being able to look at my installed modules and then http://drupal.org/project/Modules and see if i am up to date.
Um, it's obvious you missed my point. Currently, the version number in his screen is for the major release of Drupal. Modules have many many smaller releases during the life cycle of a Drupal release. Knowing that a module has been released for 4.8.0 doesn't mean you have the latest version, because active development of a module could mean that you're out of date within a week. Basing module numbers off the core version doesn't allow any indication of module version and is thus useless.
If we go with Derek's proposal, a contrib module would probably have a version of 4.8.x-1.0 or maybe even just '1.0' since 'required Drupal version' is a separate field and in the modules page, you know. But for core modules, I threw in the core version number because it's the only number that really makes a lot of sense. I suppose we can give core modules their own version numbers but that would likely be a major hassle and not worth it.
I've done another sort semi-functional mockup here: I'm continuing this in an issue http://drupal.org/node/76340 http://drupal.org/files/issues/modules-enabled.png http://drupal.org/files/issues/modules-disabled.png It could really benefit from some theming, but that's another minor issue. I made some comments about the decisions that went into this mockup. Further commentary would be lovely.
It could really benefit from some theming, but that's another minor issue. I made some comments about the decisions that went into this mockup. Further commentary would be lovely.
I don't think we should use | for delimiting the links. We don't do that elsewhere (such as watchdog logs, for example). -- Morbus Iff ( i put the demon back in codemonkey ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On 31 Jul 2006, at 13:06, Morbus Iff wrote:
It could really benefit from some theming, but that's another minor issue. I made some comments about the decisions that went into this mockup. Further commentary would be lovely.
I don't think we should use | for delimiting the links. We don't do that elsewhere (such as watchdog logs, for example).
Correct, and the table header should read 'Operations' for consistency with all other tables in core. -- Dries Buytaert :: http://www.buytaert.net/
Dries Buytaert wrote:
I don't think we should use | for delimiting the links. We don't do that elsewhere (such as watchdog logs, for example).
Correct, and the table header should read 'Operations' for consistency with all other tables in core.
Both easy enough changes.
participants (15)
-
Chris Johnson -
Dries Buytaert -
Earl Miles -
Frando (Franz Heinzmann) -
Gary Feldman -
Gerhard Killesreiter -
Jason Flatt -
Jeff Eaton -
Khalid B -
Morbus Iff -
Moshe Weitzman -
Ray Zimmerman -
Rowan Kerr -
Sammy Spets -
Steve Ringwood