The Problem

Over the years we have done numerous usability tests on the module page, and they all discoverd various problems that need to be solved in a redesign. The problems we found are :

  • The module page is overwhelming, thereby failing to inform users about Drupals extendability.
  • It is hard to find a module after you uploaded/downloaded it.
  • Additional information such as dependancies and links draw too much attention.

Process for finding a resolution

  • Prepare prioritized task list for the modules page, list of requirements for presentation and functionality.
  • Verify our assumptions with some interviews
  • Use those lists to find the best ideas for the most important tasks/requirements in all the mockups that have been posted.

With the information from this, we can continue our design iterations and finnally decide going down a certain path.

The list of things you want to do on this page, prioritized by importance:

  1. Find a module
  2. Enable / Disable / Uninstall module
  3. View module description to orientate what the module is about
  4. Change the permissions / configurations of a module
  5. View available updates / update module
  6. View current module versions
  7. View which modules are required to be able to enable, disable or uninstall a module

Current ideas for solution

It is quite messy to follow this topic around issue #88 the discussion for Drupal 8 started. In the past months we have consensus on a number of ideas but still have discussion about their specific design and implementation.

Agreed upon ideas

  • Using a accordion like interaction to encapsulate information such as dependancies.
  • Allow users to filter the list using search.
  • Have a signal for showing which modules are "new".
  • Have a signal for modules that require update(s).

Topics still under discussion

  • How to group modules; using packages, categories, tags, nothing?
  • How to filter modules (disabled, enabled etc.), what meta data is important?
  • How to handle dependancies, disabling and enabling modules that require other modules is currently too hard.

Research

As noted in the process for finding a resolution, we have concluded that we need to do interviews. The current progress of this is :

  • Test script has been written
  • 17 interviews have been conducted

Sub-Issues

#396478: Searchable modules page
#468208: Allow uninstalling modules with dependents by offering to recursively uninstall their dependents as well.
#492834: Hover operations for flooded state screens
#1296876: Make dependency list hidden on modules page until requested
#1348692: Vertical Tabs for the Modules page
#1353888: D8UX: Improve the position of the 'Save' button on Modules page.
#1355292: Come up with better alternatives for groupings on the modules page
#1355358: Allow searching for modules on Drupal.org from the modules page
#1355442: Add "Update available" indicator to the modules list
#1355526: Add a way to determine the date a module was added so the modules page can use it for sort
#1371524: Remove packages from modules list and .info files

Files: 
CommentFileSizeAuthor
#361 module_info_mess.png30.78 KBklonos
#361 module_info-only_necessary.png43.83 KBklonos
#360 module_filter-module_filenames.png134.8 KBklonos
#357 modulenames.png44.86 KBCydeWeys
#357 util_system_module_show_internal_names.png47.68 KBCydeWeys
#343 module.png1.07 MBNoyz
#336 modulespage-collapsed-305.png55.21 KByoroy
#336 modulespage-expanded-305.png156.5 KByoroy
#336 modulespage-expanded-305-annotated.png311.94 KByoroy
#305 drupal-modules-page_v6-1.png196.75 KBjstoller
#305 drupal-modules-page_v6-2.png188.08 KBjstoller
#305 drupal-modules-page_v6-3.png185.79 KBjstoller
#305 drupal-modules-page_v6-4.png190.62 KBjstoller
#305 drupal-modules-page_v6-5.png188.87 KBjstoller
#305 drupal-modules-page_v6.bmml_.zip18.48 KBjstoller
#284 wireframe-module-row-expanded2.png34.76 KBtheborg
#279 wireframe-module-row-expanded.png33.76 KBBojhan
#264 already-better.png128.45 KBjenlampton
#263 windows.jpg71.4 KBdroplet
#260 modules.jpg265.73 KBdroplet
#236 5293144-ux-module-page-redesign.patch11.33 KBcafuego
#236 Screenshot.png76.74 KBcafuego
#186 optional-Categories-permanent.jpg143.39 KBRobLoach
#217 modules-page_v4.png170.29 KBjstoller
#217 modules-page_v4-project.png169.54 KBjstoller
#217 modules-page_v4-project-dependency.png166.23 KBjstoller
#217 modules-page_v4-project-update.png164.67 KBjstoller
#217 modules-page_v4-mobile.png210.56 KBjstoller
#217 Drupal mockups.zip15.6 KBjstoller
#212 modules-page-all_updates_new.jpg331.16 KBMickL
#210 modules-page-all_updates.jpg327.07 KBMickL
#198 modulespage-search-no-results.png39.19 KByoroy
#198 modulespage-packages-expanded-within-list.png60.63 KByoroy
#198 modulespage-packages-on-next-page.png89.56 KByoroy
#198 538904-196-modulespage.graffle.zip472.85 KByoroy
#196 modulespage.graffle.txt1.03 MByoroy
#190 smallscreen-modulepage-1.png107.53 KByoroy
#184 optional-Categories-permanent.jpg121.04 KBeigentor
#180 modules-page-all_v2.png170.19 KBjstoller
#175 optional-Categories.jpg66.44 KBeigentor
#170 modules-page-category-updated.PNG325.16 KBShyamala
#153 filtered_results_warning.png30.58 KBklonos
#147 drupal-modules-page.bmml_.zip6.73 KBjstoller
#144 modules-page-all.png170.86 KBjstoller
#144 modules-page-all-w-detail.png169.27 KBjstoller
#144 modules-page-all-grouped.png163.35 KBjstoller
#144 modules-page-category.png96.12 KBjstoller
#127 module_filter 2.x screen 1.png303.55 KBgreenSkin
#127 module_filter 2.x screen 2.png202.67 KBgreenSkin
#127 module_filter 2.x screen 3.png229.17 KBgreenSkin
#132 module_list.png82.61 KBaspilicious
#70 Time Machine Slider Switch23.45 KBMark Trapp
#61 modules_mockup.png55.65 KBwretched sinner - saved by grace
#57 modules_selected.png49.85 KBleisareichelt
#56 Screenshot-181.jpg74.68 KBeigentor
#51 modulepage_d7_it4.png170.12 KBmcrittenden
#45 20090827-pjnicm94j7ywqai897jahmw8bi.png270.74 KBjix_
#42 modulepage_d7_it4.png161.53 KBskilip
#31 Module-Page-tweak-skilip.jpg89.02 KBeigentor
#32 Module-Page-tweak-skilip.jpg86.43 KBeigentor
#30 admin-modules-50.gif129.41 KBkaakuu
#26 modulepage_d7_it2.jpg312.64 KBskilip
#25 modulepage_d7_it2.jpg268.31 KBskilip
#21 modulepage_d7_it1.jpg231.76 KBskilip
#11 admin-modules-50.gif130.04 KBkaakuu
#10 MODULES.gif79.39 KBkaakuu
#10 Workflow-for-modules.gif93.12 KBkaakuu
#1 3667366471_3138f78d12_o.png168.98 KBeigentor
3667366471_006a0acf33.jpg91.36 KBeigentor

Comments

eigentor’s picture

StatusFileSize
new168.98 KB

Larger Image

Xano’s picture

Here's Marks latest mockup. If you want to help out with this issue, please come to #drupal-usability for some fierce discussions.

yoroy’s picture

Before we start to throw out more mockups, let's summarize the known issues with this page first,
then look at what could help solve these problems,
then wireframe,
then spin off seperate tasks that will have actual code patches posted to them.

What follows is a summary of our module page thinking during june ux sprint. One of the main ideas is to make 3 main buckets on this page: new, enabled and disabled. Please read:

__

Modules page is a typical example of a long list that gets hard to manage pretty quick. The categorization is not always ideal, with big modules providing their own category and a quickly growing 'misc' section.

Usability tests have shown that after installation, modules do not provide clear starting points to where you can find their configuration pages. Same goes for the new permissions a module might expose. No clear indication that there are new permissions and no clear pointers to where to find them.

http://sprint.drupalusability.org/content/design-module-page gives us a good summary of the main issues with this page:

1. Finding functionality once a module is installed
2. Finding functionallty a while after the module is installed
3. Finding functionality (with no knowledge of modules whatsoever)

In general, this gives us two areas of attention:

- Managing the big list of modules as a whole
- Finding related tasks per individual module

We need to show more info per module without cluttering the interface. Finding related tasks per module is something the accordion (yes, accordions, I mixed up my musical instruments there) concept could help improve by showing links to configuration and permission pages in context of the module itself.

During the UX sprint we discussed ways to make it managing the big list itself easier. The main idea is to provide 3 top level boxes for modules to live in:

- New
- Enabled
- Disabled

Let's take a look at how this would help solve some of the problems:

Box 1: New
This would make it pretty easy to find the module you just installed on the page. You'd find both enabled and disabled modules living in this box. Of course, we'd still have to provide messages on other admin pages (and maybe even in the admin header) so that you know you have to visit the modules page at all.

Box 2: Enabled
It seems sensible that below the list of 'New' modules is the list with 'Enabled' ones, no? These are the ones that provide the parts you built your site with.

Box 3: Disabled
For the modules that are installed and fully configured but are (kept) disabled, well, you probably don't want to have them clutter the top part of your screen.

Yes, but…

-- What about the categories?
It would still be handy to be able to filter on everything 'media' or 'ubercart' yes. Propose to make the categories a filter as a select list on top of the page.

-- What about modules that consist of multiple modules, like panels, views, ubercart? What if I enable some of them, some not?
Yes, the New/Enabled/Disabled segmentation would seperate these 'sub-modules' from each other. Currently these modules are grouped into their own category. I don't expect the seperation to be a real problem. On first usage (after installation) the module family would be shown in full in the 'New' box. After configuration, the category filter would allow you to see all panels, views, ubercart related modules together again.

-- This would mix up core and contrib modules!
From the users perspective, does that really matter? Again, the Category filter would come to the rescue in providing a filter to show 'Core modules' only. In itself it is not a very relevant disctinction to make.

-- How would the modules within each box be sorted?
Looking at an average use case with say, 30 installed contrib modules, there doesn't seem to be a need to make the sorting within each box 'smart' in some way. Sorting alphabetically, although about as helpful as 'random' in most cases, seems to be the most logical option here.

Any other edge cases I missed? Any other problems that might arise from this new grouping? Point them out please and talk us through it. If the concept still holds after discussing them, then just this new grouping of modules in New / Enabled / Disabled boxes would be a worthwhile improvement for the modules page.

Xano’s picture

I was thinking of a textfield that allows users to filter modules by name. In combination with AHAH this makes searching for specific modules in large lists a lot faster.

webchick’s picture

Issue tags:-D7UX usability+Usability, +D7UX

Fixing tags. Also, ninja subscribe. ;)

leisareichelt’s picture

great summary yoroy - really look forward to getting this one nailed, it has been a challenge!

webchick’s picture

Issue tags:+Drupal 7 priority

Also tagging with this. I think that it would be a shame for D7 to ship without this page having been re-worked, since it's one of our biggest usability WTFs currently.

eigentor’s picture

Great writeup. I guess you really thought of about everything.
Ah, no, there is an edge case: Drupal has just freakin' too many modules. What poor soul is gonna herd them?
I mean, this is a hard task.

Maybe we could create some typical module setups and find solutions for these examples. What is the average amount of modules?

In Designing for the 80% (that we mostly target) Things are much, much easier: I guess, a drupal newbie won't install 50+ modules.

Things like Ubercart are special, this monster in itself installed about 25-30+ modules last time I checked and clutters everything. So this and maybe there are some more should be an edge case: personally I would always keep together Ubercart modules, since they in themselves are often cryptical and confusing.

So for these "monster" modules sets a special plan might be good.... (haha fourth group at the very bottom: "Monsters". Allegory: go down and burn in Hell)

yoroy’s picture

I'd presume ubercart would add itself as a category to filter the list on.

kaakuu’s picture

StatusFileSize
new93.12 KB
new79.39 KB

As hinted by Yoroy in the other related issue, posting a mock-up diagram here which in my idea streamlines things more.
Please see the attachment here - the first diagram.

The second diagram is a rough diagram approximating an ideal workflow for modules

kaakuu’s picture

StatusFileSize
new130.04 KB

In conjunction with MODULES.gif above
a very, very rough skecth to show how this mockup handles when there are more than 50 modules or 500

The lists can have more sharpness in display with slightly more increasing the line-heights.
Can post a better diagram when have more time and if there is any enthusiasm here :)

derjochenmeyer’s picture

Without having read in depth about this issue (which is probably an advantage), i like the mockup #2 posted by xano >> Its intuitive it looks drupal like >> i feel at home.

I dont like #10

Just my thoughts about this starting from #2

  • A direct link to "Module settings", "Module permissions", "More detailed Description" should be added for every module. It would be even more userfriendly to also indicate if a module has "No module settings" or "No module permissions".
  • Modules (like ubercart, views, cck, panels) should be sub-grouped acording to the folder structure in /sites/all/modules to indicate if a submodule is a 3rd party addition or if its belonging to the original group of modules.
Gábor Hojtsy’s picture

Subscribe.

yoroy’s picture

So, I'd like to create a first spin-off issue for grouping the module list into 3 boxes "new, enabled, disabled", since that seems like a usefull thing to have regardless of any extra filters for sorting and regardless of any extra links offered per module.

Do we want to discuss the requirements for that here or in the seperate issue?

Gábor Hojtsy’s picture

Now that the "Configuration and modules" page is in, I've submitted a patch which moves the Modules page to the right place in the IA as a first step. I think it is best to get that in fast and then work on the inside of the page. See #545952: D7UX IA: move modules to config/modules.

skilip’s picture

Subscribing

webchick’s picture

Just a note that Gábor's issue in #15 was committed last week sometime, so we are no longer held up on that.

skilip’s picture

Most of you know I've spent dozens of hours in rethinking the module page earlier. I've been involved with many discussions, made many mockups and even made a contrib module which was intended to make it to core. A few months ago webchick advised me to stop further development until the D7UX team picked up this issue, to prevent me from doing a lot of work which wouldn't make it into core anyway. So I'm really committed to this issue.

As yoroy mentioned there are a few main targets here on which we must focus. The order of importance:

  1. Scannability: The list can be long, you should easily check the status of most modules by just a quick glance over the module list.
  2. Workflow: All tasks involved with modules (enabling, disabling, uninstalling, setting permissions and configuring a module's settings) should be quickly and easily doable.

As for scannability I am a bit disappointed by Mark's work. I don't agree it improves scannability, mostly due to the grouping. The hierarchy is to deep IMO. You have three parent groups (new, enabled, disabled), the categories as subgroups (which can appear in each parent groups as well), and a module can also be a group. We could easily tackle this by removing the uppermost categorization (new, disabled, enabled) and add a 'sort-by' select list to the filter system. From there you could sort by date added, enabled, disabled, and more. I also dislike the amount of whitespace between the modules and groups. I always have thought of the module page as a tabular data like list. That way you don't have to scroll down too much if you've got a huge amount of modules. iTunes! That could even avoid the pager (which worsens the workflow).

The tools made available in Mark's proposal really improve the workflow exponentially. The filters, bulk actions, floaded harmonica's, search field, on/off switches, and so on are all great features which improve the workflow. Still, the lack of scannability breaks the workflow.

Yoroy, Bojhan and me already have made a lot of mockups. The last mockup was really good, so why not work from there instead of taking again a new approach and restart bikeshedding?

eigentor’s picture

Great to have you on board, Philip!
I second skilip on the scannability issue. This should get more focus.
Still I do believe parting it into three groups can improve scannability, but it has to be three clearly separated groups. Wordpress here again does a great job by seperating enabled and disabled plugins very clearly: http://screencast.com/t/tNb6FG5MkV

If you have several groups you can scan each group seperately and you get less overwhelmed by an endless list.
So how to progress on this? Time gets shorter and shorter.
Yoroy asked in #3 to stop adding more wireframes before we got the specs right.

Still this is a huge one and we have not really progressed since then.

Personally I'd opt for any kind of working prototype and iterate on that. I don't know if this module is still any good as a prototype, as it is for D6? http://drupal.org/project/module_table

We could also do interactive prototypes in Omnigraffle or Axure RP, as this is quite dynamic and is not helped by static mockups. But we need to act soon as this is no easy one.

I heard Merlin saying he was passionate about that page so we might win him to support the coding part. Gabor does such a great job but he cannot be the only one helping out on this.

+1 for building upon mockups you have already done, for my part: show them here!

yoroy’s picture

Guys, of course show mockups. Just make sure to be really explicit about what you are proposing. #3 had to be written up, that was all.

1. Finding functionality once a module is installed
2. Finding functionallty a while after the module is installed
3. Finding functionality (with no knowledge of modules whatsoever)

Skilip: It's hardly time yet to nitpick white space issues. Better to support your argument with showing the mockups and explain how it helps (better) solve the 3 issues outlined above.

I hereby lift the ban on mockups in this thread!

skilip’s picture

StatusFileSize
new231.76 KB

Okay, here's a new mockup. I've merged Mark's proposal with our last mockup. It's not complete, but a good starting point IMO.

yoroy’s picture

the mockup in #21,:

webchick’s picture

Title:Redesign Modules Page» D7UX: Redesign Modules Page

It took me way too long to find this. Adding D7UX to the title to make it easier.

eigentor’s picture

This looks quite clean at a first look.
What I especially like is the solution for the flooded state. This keeps it clean.

Now let's try to do the grouping into "new" "installed" "not installed" which would adress yoroys 1.

I guess yoroys 2. is largely up to various sets of filters. but 1 is proposed to be the default filter, I guess.

3. Needs self-explanatory module names and - maybe - descriptions.
Since we cannot control the names and the general wording of the descriptions, we have to concentrate on Scannability and that module names can be read very easily. IMHO this would ask for more space between the module names and maybe not making them bold. While Marks last layout may not be the way to go, I like his approach to rather reduce than add - would mean not by itself make module names bold.

Descriptions: if we have any (probably in flooded state) they must be trimmed to say a one-liner. So we motivate module maintainers to be precise and say everything in one short sentence... :P

What about the dependencies? Do we want to do that? For if so, they must get into mockups.

skilip’s picture

StatusFileSize
new268.31 KB

New mockup. Still not finished but more detailed than the first one. What are we going to do with the dependencies?

skilip’s picture

StatusFileSize
new312.64 KB

Uploaded the wrong image

Xano’s picture

- The per-module package information is redundant, because modules are displayed grouped by package anyway.
- Dependencies sounds too much like techbabble to me. What about Requires or Depends on?
- Group by is a display setting. It should therefore not be put on the same line as Check all and With selected, because those are actions.

skilip’s picture

Here's a part of a conversation I had with Roy and Bojhan in irc about this issue.

[22:27] yoroy: skilip: I miss the three boxes for new, enabled, disabled
[22:28] yoroy: skilip: the tab-like design of the permissions and settings links suggest an inline form, not a link to another page
[22:28] skilip: yoroy: Yeah, I do not agree on prefixed grouping. I totally see the use of having the newly added modules on top, but that's obviously a usercase
[22:29] skilip: yoroy: for the permissions: since we now have an overlay, we have loads of more space available the the Garland mockups
[22:31] yoroy: skilip: So you see the use but don't like it?
[22:31] skilip: yoroy: Can we skype for that? It's a lot of typing
[22:33] skilip: Well, I'll start typing anyway.
[22:34] skilip: First reason I don't like the grouping in Mark's proposal is that you'll end up with groups within groups.
[22:34] • skilip hopes he doesn't have to explain that
[22:35] skilip: Secondly you could end up with modules which belong to one category but are divided between 'Recently added', 'Enabled' and 'Disabled'
[22:35] skilip: And lastly, the flexibility.
[22:37] skilip: For newcomers I assume Mark's proposal suits them well, but for advanced users, like Drupal developers (which is 80% of the users who visit the module page), this surely isn't preferable
[22:38] skilip: For developers, the most important thing is to find the right module(s) an do the administrative tasks required.
[22:38] skilip: And that's not only enabling a module during a site setup!!
[22:39] skilip: So we should ask ourselves: what's the 80% in this case
[22:39] skilip: ?
[22:40] yoroy: I don't see how this would make it harder for devs to find a module?
[22:40] skilip: So they newly installed isn't very helpfull when you're half way your development process
[22:41] skilip: The separation of the categorization
[22:42] yoroy: skilip: ok, I think it'd be good if you past these concerns into the issue
[22:42] skilip: yoroy: you need to be honest, Groups within groups which are divided over several places over the page, does not improve scannability
[22:43] skilip: I'll do that
[22:45] yoroy: skilip: I'm asking what your concerns are right? Implying I'm not being honest isn't really nice
[22:45] • yoroy thinks he prefers findability over scannability
[22:45] skilip: yoroy: I didn't imply that
[22:46] skilip: yoroy: what's the difference?
[22:48] skilip: yoroy: ??
[22:50] Bojhan: skilip: So basicly, what is the diffrence here is - that you imply that you prefer seeing everything over drilling down - visually.
[22:50] yoroy: skilip: scanning suggests eyes dashing all over the screen everytime. findability suggests putting stuff in place that lets you skip stuff, know where to go
[22:50] • skilip is thinking about that
[22:52] skilip: yoroy: So that's why the 'Recently added', 'Enabled' and 'Disabled' groups are born?
[22:53] skilip: So that you find the right modules in the place where you expect them?
[22:53] yoroy: skilip: yep
[22:53] skilip: yoroy: Ah
[22:53] yoroy: you drill down a part of the list, not the whole list all the time
[22:53] skilip: still
[22:54] yoroy: because you very likely do know if it's either on or off
[22:54] • skilip feels sorry for being a pain in the ass
[22:54] skilip: As a developer in a company, I often do not know where I could a module expect to be
[22:55] skilip: And when you visit the module page a week later than adding all required modules, you probably don't either
[22:56] skilip: If you're working in a team, anyone could have added modules
[22:56] skilip: So again, what's the 80%?
[22:56] skilip: Developers, or end users?
[22:57] Bojhan: skilip: We dont diffrentiate between the two
[22:57] Bojhan: skilip: its totally not about that either
[22:57] Bojhan: its about finding a good middleground,

kaakuu’s picture

In the above mock-up the two most important parts missing, imho, is that the user (admin or whoever in the team) is not being allowed to make a favorite list, so that he or they can have a quick look at what they wanted when they come back in future or what they need actually to. And the link to module plugin browser.

Not exactly eye-candy, and the typography, spacing, icons, alignment etc need re-dos but in principle this is what I suggested. Please have a relook at http://drupal.org/files/issues/admin-modules-50.gif
( the figure assumes in each box the modules are default sorted alphabetically, that way I do not have to learn or guess 'categories')

This is also the standard way standard admin panels (where lots of or minimal modules are there) are handling things.

kaakuu’s picture

StatusFileSize
new129.41 KB

Slight correction done in the diagram

eigentor’s picture

StatusFileSize
new89.02 KB

O.K. A tweak of skilips version that introduces grouping into New, Enabled and disabled. I like the fact that the "on" switch gives further color coding without being obtrusive. A bit of a problem imho is the large unused space between Name and switch, but the flooded stat tabs that skilip shows give a reason for that. A question to be solved is: how long is a module new? I guess it has to do if it gets enabled, so I believe new modules mostly will be disabled (mirrored in mockup). Should thing about if if makes sense to also take into consiereation if permissions have been set or they have been configured.

Depencencies not yet taken into account.

eigentor’s picture

StatusFileSize
new86.43 KB

Just a different picture for the above post

webchick’s picture

Hot damn, #31 looks really, really nice. I'm assuming that these will all be alphabetized. :P I'm further assuming that modules that come as part of the same download (such as Ubercart, Views, etc.) will expand out and have checkboxes for the sub-modules contained therein. If this is the case, it needs to be visually represented that some of these sections are expandable. I would also love to see what a mock of an expanded section looks like.

I am not sure I understand skilip's argument. I'm a developer with 4 years of Drupal experience and I never know where to find a frigging module once I add it, unless it's one I enable constantly like Views or CCK. And even then, I normally have to resort to cmd+F, because "Views" might be at the bottom, or second from bottom, or 4th from bottom, etc. depending on what other modules are installed. The current interface is a complete nightmare.

This new interface makes it easy. Is it enabled, disabled, or did I just turn it on? Once I ask myself that question, I can find it in no time flat.

skilip’s picture

@kaakuu: Your idea of tagging modules as favorite should definitely be taken into consideration. However it requires even more work, while we're currently stripping as much as we can to get the concept into core before code freeze. (think of how the modules should be tagged. This needs AJAX behaviors, database alterationsm, etc.).
Beside that, your mockup brings up a total new concept. The mockup we're currently discussing has already been widely discussed with Bojhan and yoroy, months before this issue has been opened.

@eigentor: I really like the coloring of the different groups. Only remark / concerns on that would be how to handle a situation where the modules are grouped by category. This will display an undefined number of groups. Should we predefine, say 50 colors?
Making the tiles of disabled modules lighter, is an extra indicator which is IMHO unneeded.
I guess a week is enough for marking a module new. Maybe even shorter.

@webchick: My main concern is having the 'new', 'enabled', 'disabled' grouping, without the possibility of grouping in a different way. It assumes you know which modules are new, or enabled. When working in a team, you're not the only one who can add, disable or enable modules.
Another drawback of this grouping is that we'll need subgrouping. The 'new' group can contain modules categorized under 'views', but so can 'enabled' and 'disabled'.

After thinking about the discussion I had with Roy and Bojhan, I now understand why the groups 'new', 'enabled', 'disabled' narrow down module searching. You only need to look where you'd expect the module to be. Since this primarily targets novice users and developers who are working alone, I think this type of grouping should be default. Beside that I'm thinking of putting both the filter and grouping select list under a collapsed fieldset, named 'Advanced'.

Working on a new mockup......

kaakuu’s picture

@skilip
Cannot we delay the code freeze so that
# there is a solid API or whatever that makes modules that will be old still work in future just like old Paint still works in win XP, new modules will work better but we don't have to discard the olds after 7
# remove half baked things once and for all like http://drupal.org/node/543914#comment-1903512
# it is a developer's game so far and perhaps commercial D's gain but let us have some new or needed features for those who actually use our sites http://drupal.org/node/544474

Was that out of topic? Perhaps. But this module redesign is being just cosmetic and lagging behind in useful "user" ergonomics, other admin panels like cpanel have moved much forwards.

Much thanks for the feedback.

mcrittenden’s picture

Subscribe.

webchick’s picture

Erm. If Drupal ever starts using CPanel as an example of what to strive for in a user interface, I officially resign. :) I cannot possibly think of a more overbearing and convoluted interface where it is quite literally impossible to do *anything* without cmd+F.

One other thing I notice about #31, which I think is just a mockup glitch, is that the checkboxes for disabled modules are themselves disabled. This would mean you could never enable disabled modules, so let's make sure we don't do that. ;)

@skilip, that's a good point about people enabling modules while working in teams. I still think this is preferable because it gives a maximum of 3 places to search for the module, but there will indeed be times where things are unexpectedly in the wrong places if 2-3 people are monkeying with this page at once. However, I think I'm willing to consider that an edge case at this point, since hopefully you and your team-mates are communicating well enough to understand what each other are doing.

kaakuu’s picture

:) @webchick - I too :) But I meant pick up the good things. The newest cpanel packs the most recent tasks or modules visited in a handy block automatically thus making frequent tasks available easily. It also groups modules in easily scannable and identifiable blocks that can be dragged and reordered. It 'remembers' those without needing to click save. Were you speaking about this new cpanel?
The new Drupal is/was meant to make things easier, isn't it ? Even with these mockups it will still be cmd+F to find out if I suddenly need my module X from a list of 70 modules. A long rigid list to scan plus vast wide horizontal space.

Anyway, I resign from this thread now. Will contribute something useful elsewhere. Thanks.

skilip’s picture

StatusFileSize
new291.6 KB
new301.66 KB

New mockups. This includes the expanded states of modules, module info and permissions.
Module page Iteration 4

Module page Iteration 4

skilip’s picture

I'm also considering dropping the whole filter form. Just having a 'search when you type' would be useful enough.

amc’s picture

Even with these mockups it will still be cmd+F to find out if I suddenly need my module X from a list of 70 modules. A long rigid list to scan plus vast wide horizontal space.

But if the lists are sorted alphabetically, it'll b.e obvious where it is even in a long list.

skilip’s picture

StatusFileSize
new161.53 KB

Ok, here's a new one. Quite near to finished I guess.

  • Removed the filter form. It only clutters the UI and isn't expected to be used often.
  • Removed the submit button 'Search'. The search field should be a 'search when you type' field. When js is disabled, the submit button will be present again.
  • Added a submit button to the 'With selected' select list for safety. You don't want to accidentally uninstall a whole bunch of modules.
  • I didn't remove the 'bulk actions'. If I would remove that, the checkboxes wouldn't be needed also. But then we'd have to add other UI elements which enables admins to uninstall modules as well. I was wondering whether it might be possible to use actions for the bulk actions thingy. That way other modules could hook into the bulk actions system.
  • Added vertical tabs for the 'Depends on', 'Required by' and 'More modules by this package' information. This avoids cluttering. The 'More modules by this package' section displays all the modules of the package the module belongs to
  • When the module has one settings / configuration page available, the 'settings' link will appear. If the module has more than one settings page available, a tab will be added in which a list of all pages is put.
skilip’s picture

mcrittenden’s picture

I love it! One question: is the Keyword search going to be used solely to filter modules on this page, or does it search the rest of the admin section as well? If the former, then we need to fill it with "Filter modules" or something like that instead of Keyword search, and if the latter, then that's just no fun at all :).

jix_’s picture

StatusFileSize
new270.74 KB

Looks pretty good skilip!

My comments:

Xano’s picture

I'm not sure about the background colour for disabled modules. It kind of suggests something went wrong there.

jix_’s picture

Hmm now that you mention it, I agree gray (for example) would be more suitable.

mcrittenden’s picture

Xano: good point, maybe just a light gray?

jrdixey’s picture

I'm a fairly new Drupalist, so take my comments with a large grain of salt.

This is all very encouraging in terms of where the UI for D7 is headed.

Two thoughts:

1. The Permissions and Settings tabs idea is brilliant! Finding where to set permissions for a new module is always a challenge, and this would even give module developers a place for a small explanation of what the options actually do, in context. Total win.

2. To my eye, a "New" box is not necessary. I don't usually download more than one or two modules at a time. Two boxes, Enabled and Disabled, with a "New" visual flag of some kind on those modules that are new, seems sufficient to me.

Hope this helps.

mcrittenden’s picture

@jrdixey: Glad to see you joining in the discussion...it's important to get the opinions of people who haven't already stared at the Drupal UI everyday for the last 5 years ;)

Re: the New box, I personally think it's a great idea, not only because you automatically want to enable all newly downloaded modules, but also because I tend to download 10-20 modules at the beginning of a site's development, so it'd be really helpful if they were all together. But I might be the exception and not the norm.

That being said, I would be OK with a "Check all new" checkbox right next to the "Check all" checkbox to accomplish the same task. But that would be a step backwards from the mockups IMHO.

mcrittenden’s picture

StatusFileSize
new170.12 KB

Updated skilip's mockup with gray instead of red.

Xano’s picture

I like jrdixey's idea. Something like the "new" flag used for nodes, but then for modules? It saves a lot of space (and it's consistent).

skilip’s picture

Hey guys, Thanks for commenting.

  • Change 'Keyword search' to 'Filter modules': I totally agree!
  • 'Select all' and 'With selected': I'll change 'Check all' to 'Select all'.
  • Change the text in the sliders to 'enabled', 'disabled': I've thought of the localization issue of having 'on' and 'off' in the sliders. It definitely isn't preferable to have long words in the sliders, so I'm actually thinking of on and off signs. (| and O). These can be just images and are known all over the world.
  • Change the background color of the disabled box to gray: That's a good idea as well
  • Remove the 'New' group and use 'new' flags instead: The 'new' box has already been discussed with our D7UX team. The advantage of having all recently added modules in a separate box is that you know where to expect them. There's no need for scanning the whole page anymore.
yoroy’s picture

So I'm seeing at least 3 spin-off issues here that could get actual code written for it:

- create the 3 boxes new, enabled and disabled
- bring permissions and config inline
- make the filters work

If there's no more architectural feedback here (discussing colors isn't) we could go ahead and start work on the implementation.

Skilip: excellent work so far.

eigentor’s picture

Will join the mockuping party in the weekend.

Some more filtering would not hurt and is easy to implement: by package, by whatever?

I have been using the collapsing feature of Admin Menu for a long time now, and it is a great help. Just when you search for something specific you are lost.

What we should also work on is the dependency thing. Though I like the idea of skilip, it feels a bit redundant.

Ack, the gray for disabled modules has been proposed already... ;)

Another thing we need to check is the settings tab. While I really love the idea: how to handle multi-page settings pages? At the moment module settings pages have real subpages like /admin/build/views/export/ that are used directly for funktionality and have to keep their integrity.

Should work on some real-life mockups that implement modules settings pages into the admin page, It may come out that it is wiser to just keep a link to the settings page here, and put links on the settings pages back to the modules page.

eigentor’s picture

StatusFileSize
new74.68 KB

That's how my module page has been looking for quite some time. As said, only thing I missed was searchability...

leisareichelt’s picture

StatusFileSize
new49.85 KB

I've just had a look at the module in 'open' state and have put together a little mockup (attached) that I think tidies up the tabs area a little more.

I feel like I need to better understand the use case for the 'Required by' functionality? What are the most likely scenarios of use for this?
Also, would it not be more helpful to have a listing of the modules that the select modules requires? (And the ability to install/enable those required modules?)

I'm going to take a look at some ideas for 'grouped' modules next and interested in your feedback on this.

yoroy’s picture

Leisa's above:

mcrittenden’s picture

The major problem I see from #57 mockup is that it removes the individual checkboxes from the modules within that package, meaning each of those modules has to be broken out as they currently are in 6.x which gets really messy really fast.

That said, I can see a potential problem when grouping all the modules in one package together: in the #42 mockup, there's a master checkbox on the top left of the package, which I assume just enables the Content module, but since it's over the whole package, it sort of seems like that checkbox enables every module in that package. Anybody else?

Leisa: the Required By is useful (for me at least) for determining which modules are preventing me from disabling a certain module. For example, if I want to disable the Comment module, but the checkbox is disabled, you can look at the Required By section to see that this module is required by the Tracker module, which is also enabled, so I need to disable Tracker before I disable Comment.

mcrittenden’s picture

wretched sinner - saved by grace’s picture

StatusFileSize
new55.65 KB

My view, coming from Mac OS X, is that if I see the switches, I want to be able to enable or disable a module with the switch. If I have switches telling me that they are enabled, but I can't use them to toggle the status, then it seems pointless having them, especially if we already group modules as to whether they are enabled or disabled.

My photoshop skills are non-existant, but I've tried to to piece together my ideas from the bits used above...

Only local images are allowed.

Basically, the idea is to replace the checkboxes with space that can indicate new modules. All modules are then in a single, scannable list, and the enabled/disabled status is reflected in the switches. Also, by bringing the switches into the requires/required box, it allows for enabling pre-requisites while looking at a single module.

Obviously to enable the modules via switches, we probably need to use AJAX to process each individual enable/disable in real time, but it would have the advantage of the support queries of a WSOD when PHP times out because someone has enabled all 50 modules they have just uploaded to start creating the site.

skilip’s picture

StatusFileSize
new155.94 KB

I've had a long discussion with Bojhan (in the Thalys on our way to Paris) about the grouping of modules per category. Here's a mockup which shows the idea.

skilip’s picture

Created an issue for the slider behavior: #565312: Textfield to slider behavior

skilip’s picture

Priority:Normal» Critical
Status:Active» Needs review
peterjmag’s picture

I've been working with Drupal for less than a year, but I'm extremely interested usability in general, so here's my input:

Slider toggles
I agree with #61 in that if sliders are to be displayed at all, they should be fully functional. A couple other things to think about:

--I think that the slider as an additional element (as in #62 and a couple of previous mockups) could be very confusing. I understand that the checkboxes now serve a different function (sort of a bulk operations thing, as opposed to the D6 enabled/disabled state), and while I think that could be a good thing, we need to think about how the user will interpret both of those elements. For example, will the user expect an enabled module to have its checkbox checked (as I do because of D6's behavior)? And what does the user expect to happen when he/she toggles the slider? Should he/she have to click "submit" to save their slider changes, as they do with a checkbox?
--If the slider does indeed become a functional toggle element, should the user drag the slider (a la the iPhone) or simply click on the entire "image" to switch states?
--Would the modules page be the only page to use sliders like this? Would other areas of the Drupal admin interface benefit from that kind of UI element as well?

Grouping
This may be a slightly more contentious issue, but I'm not a fan the New / Enabled / Disabled grouping as a default. It feels like many users would have just as much trouble finding a particular module as they do with the D6 layout; as skilip mentioned in #34, it "assumes you know which modules are new, or enabled," which is not always the case. I think that the user should be given a couple different grouping options, including enabled/disabled status.

I'm not sure if this idea has been proposed/suggested/shot down already, but how about using row background colors to indicate each module's status in a (more or less) ungrouped list, sort of like the status report and available updates pages? I realize that there are obstacles to that (e.g. how many different colors/states should there be? should that include colors indicative not only of enabled/disabled, but for up-to-date/in need of security update/etc as well?), but I think it'd be much easier for the user to see what's happening when he/she glances at the list. Any thoughts, or is this just a bad idea all around?

Expandable fieldsets for each module
I'm on the fence about this. On one hand, I love how much potential it has for cleaning up the list, especially with a large number of modules installed. However, I'm also really turned off by the prospect of being required to expand a fieldset before enabling a submodule. It feels like adding unnecessary clicks to me. Another issue: If a user checks the "Check all" box, how will it be indicated that all checkboxes in collapsed fieldsets have been checked as well? Should all collapsed fieldsets automatically expand to show that?

Including permissions
Awesome! I'd love to see this executed, but does that mean we'll lose the standalone permissions page? Or would it be just another method for sorting existing permissions?

Filter by module name
Also awesome, and very important in my mind. I agree that this should be a "search-as-you-type" field.

Add new module
Someone already asked this question in their mockup notes, but what would this link do? Maybe give the user a quick overview of how the module installation process works? I do think it's a good link to have on the page though, especially for new users that may be confused by the process or may expect to have to make Drupal "aware" of a module being added to the modules folder before installing it (I know I did at first).

Sorry for the somewhat disjointed feedback; just trying to be constructive. I hope it helps!

Sutharsan’s picture

After scanning the thread, I evaluated the last design for my 'daily' use as site builder.

* The "Check all" checkbox for all modules on the page has little or no use in combination with "Enable" or "Disable" action. How often do I disable all modules on a site (at upgrade) or enable all modules (never). However a 'Check all' per section (New, Enabled, Disabled) is very usefull and has a clear purpose.

* The section section title "New" confused me. I guess this is meant to be "Recently added (disabled)".

* The upgrade notification triangle could be repeated/placed on the grouping header when the group is collapsed.

For the rest the design is a big improvement compared to existing.

eigentor’s picture

To move this issue ahead, I had a talk with skilip and I promised to do clickable prototypes, becaues flat ones won't be enough for this complex and very important page.
But after Drupalcon :P

Just my 2 cents about package grouping inside the "new" "enabled" and "disabled" category.

I plain don't like it.

Reasoning: We want to improve scannability. The three groups is one semantic model, the package grouping is another. If you mix the two, the user is probably confused more than it helps.

Let's keep the grouping seperate and switchable: one grouping by the three big groups, inside them alphabetical, the other one by package and without the three big groups.

As filtering is really not expensive in programming (I guess) why not having a third one that is plain alphabetical without even the three big groups. Especially power users that know exactly what module name they are looking for will like it.

The default clearly will be the enabled, disabled and new.

We should do user testing on the interactive prototypes - for this needs feedback. If anybody wants to join in - will use axure rp for this so we could share files.

amc’s picture

Regarding #62 I"m not sure how I feel. It seems like the page is getting too busy and scannability is suffering while workflow is not necesarily improving (see #18). I fear the page is becoming more like the mess in #56...

The only upside is that it identifies the core modules. Since upgrading Drupal requires all contrib modules to be disabled, we need some way on the page to identify those. Even better would be a link or button that unchecks the boxes (like http://drupal.org/project/contrib_toggle does). We couldn't really have it recheck boxes after the upgrade unless Drupal somehow saved the state before deactivation.

eigentor’s picture

Have been working on a prototype for this a bit today. I realized that to do all that we layed out, this would be huge.

Knowing that even smaller changes need quite some discussion and polishing, I'd say Realistically, hardly a chance to get this in as a big chunk since no dev power is left for this issue.

So I propose to break out the most important parts of this into smaller issues that will have a chance to get in, and maybe add up to the bigger one in the end.
Leave it as a proposal for now to get some comments before creating a lot of of issue creep.

I see the following changes as the most important bits, that should be broken out into smaller issues:

1. Search field for full text search
2. Link to module's settings page
3. Description and Depenencies only when clicking the module (flooded state harmonica behaviour). Only show module name and enabled/disabled status by default. Also 2. is not shown.
4. Get the "collapse groups" settings from admin menu into core. This should be right at the top of the modules page
5. Format Dependencies and Description in a more readable way (Lists for dependencies like shown in the mockups)
6. Get the on/off slider in, to make it easier scannable if a module is enabled or disabled

Have I forgotten anything?
I see the list as hierachical, the further down, the less important. The first two alone would mean a huge improvement and man - this should be doable.

Mark Trapp’s picture

StatusFileSize
new23.45 KB

This might be hashed out elsewhere, but one thing to think about with the sliders is the confusion over whether it's enabled or disabled. In implementing sliders in the past, I've had users ask if it says "on", does that mean it's on, or does that mean if you slide it to the word on, it'll be "on"?

Apple in Mac OS X solved this confusion by putting the labels outside of the slider, so when you push the slider to the word "on", there's no question that the slider is set to the "on" position.

sun’s picture

Can someone please post a technical summary of this issue (and maintain that summary by subsequently posting revised summaries)?

That summary should NOT contain questions. If any point is unclear, list all possible ways that have been mentioned in this issue to solve the point, but no questions, nor personal opinions. For examples on how to do this, see http://drupal.org/node/8#comment-287088, http://drupal.org/node/8#comment-628434, http://drupal.org/node/8#comment-1178898, and http://drupal.org/node/8#comment-1184066

I'm referring to summaries of that issue, because this one has the potential to be equally challenging.

sun’s picture

Additionally, I'd really like to see a flexibility that allows modules like http://drupal.org/project/module_supports to do their job properly. That said - ideally, we put 90% of that module into core (only informational strings, no hard-wired logic), because I've stopped counting the issues requesting to put some "related" info on a project page or the project's handbooks.

eigentor’s picture

@sun: here is my stab at a summary:

Three main goals are targeted by this issue for the modules page:

1. Finding functionality once a module is installed
2. Finding functionallty a while after the module is installed
3. Finding functionality (with no knowledge of modules whatsoever)
4. Finding related tasks for each module (permissions, settings, help)

In the present state of the modules page, there are several issues that prevent these tasks from being easily performed. In the following the measures to be taken are collected behind each issue.

  1. The scannability of the page must be improved. This will be done by
  • Offering different grouping of modules. Apart from the present grouping by package alsoa grouping by the three statuses of the module: "New / enabled / disabled" will be offered.
    It is not yet decided if the grouping by status and package will be switchable or combined (like shown in http://drupal.org/node/538904#comment-1884088) It is also not decided if there will be more filters.
  • Not showing detailed informaton about the module all the time. To show things like the modules description, you click on a module and a detailed view is shown
  • To further improve the scannability for seeing if a module is enabled or disabled, an on / off slider is proposed. this slider is green when in "on" position. It is not decided yet if the slider will help scannability or adds confusion.
  • The page must be searchable. For this a search box that searches for module names will be implemented.
  • Findability of related tasks must be improved. For this, the aforementioned "detailed view" for each module is provided. This View provides the following:
  • chx’s picture

    Both scannability and searchability would be best done by an incremental filter. Ie #396478: Searchable modules page ...

    Bojhan’s picture

    @chx Agreed, searching this table is a required interaction. It would immediately increase the find ability of any module better. See #229193: Incremental filter for permissions page for how this was done on permissions page.

    skilip’s picture

    @eigentor: Thanks for the summary! Here's the status for what I know:

    Everything marked emphasized is still not sure.

    1. The scannability of the page must be improved.
      • The grouping has been widely discussed. The 'New' or 'Recently added' group is agreed with everyone. The 'enabled' and 'disabled' can be merged into one group.
      • The floaded state state harmonica's for expanding module's descriptions are excepted as well. These can be used as well for module permissions when the number of user roles don't exceed the number N. When the module has more than one settings/configuration page, a tab can be used as well. Otherwise it'll be a link instead of a tab.
      • The sliders are not really excepted. They are said to be more usable on mobile devices (multitouch screen) than on webpages (mouse interaction). Therefore using checkboxes for both enabling and disabling, and for indication the module statuses are proposed. The big disadvantage of checkboxes are that they aren't expected to behave like they could toggle the module status using AJAX. Therefore a submit action is required when using checkboxes. Any ideas on this?
    2. The page must be searchable.
      A search as you type box is widely accepted. I've built this behavior and know someone else did as well (forgot his name), so this shouldn't be hard to get into core. Something like a javascript behavior 'tableFilter'.
    3. Findability of related tasks must be improved.
      • For the dependencies: I've proposed to display only required modules inside the module's information tab. If should be possible to enable the required modules just as easy as the other modules. There's no agreement on this.
      • For the permissions: I thought doing this inline was widely supported. Correct me if I'm wrong.
      • Settings/configuration pages: . Display a list of links under a 'floaded state harmonica tab' when more than one config/settings page, only a link when it's only one page. There's no agreement on this.
    skilip’s picture

    @tha_sun: could you please explain why module_support could improve the current module page?

    @chx: I really hope you're not referring to the vertical tabs. This has been proposed before and has been rejected for several reasons.

    Dries’s picture

    Given that this was not a Drupal 7 code slush exception, I'm tempted to move this to Drupal 8. I'm happy to revisit that decision if there is Slush time left after we tackled more of the other exceptions. Until then, this is a low priority issue for me. Of course, it doesn't hurt to keep working on this in parallel, but I wanted to manage people's expectations.

    silverhosting’s picture

    darn it, I was looking forward to this in Drupal 7.

    luco’s picture

    one thing I really hate in Drupal is the excessive use of collapsible fieldsets. what's so wrong with vertical tabs that doesn't get even worse with them?

    the modules page is still hard to scan and more often than not you have to select a series of submodules to achieve what you're supposed to with your design. that's a lot of clicks. and it doesn't get any better with these sliders. their purpose is still unclear to me, except for enhancing carpal tunnel syndrome.

    OK, I'm not here only for stone throwing, so... my proposal is:

    1) a simple "flying" menu with all the module group titles in it (CCK, Views, Media, User Interface, Other etc). this flying menu would work like the excellent Table of Contents, but with the table headers javascript (that's part of drupal core) to stay with the admin while he/she scrolls down.

    2) also a sort of a "check all" feature for module groups. with it, you don't have to check CCK, link, text, filefield, imagefield, node reference etc etc etc. one by one.

    what do you think?

    eigentor’s picture

    Since the big revamp for this page is not going to happen for D7, let's break out the most important parts.

    The search field
    #598738: Modules page: add Search box for filtering by module name
    and the link to the module's settings page
    #598758: Modules page: add link to its settings page for each module
    have their own issues now. It would be great if we got those in.
    They should not be too hard from a technical aspect.

    catch’s picture

    Version:7.x-dev» 8.x-dev
    Status:Needs review» Active

    Moving.

    Bojhan’s picture

    Version:8.x-dev» 7.x-dev

    Sorry, not just yet.

    int’s picture

    Version:7.x-dev» 8.x-dev

    Now?

    catch’s picture

    Priority:Critical» Major

    Downgrading all D8 criticals to major per http://drupal.org/node/45111

    Kiphaas7’s picture

    sub

    yoroy’s picture

    RobLoach’s picture

    Slider Toggles...

    1. Do not actually improve usability
    2. Don't make sense when the user is holding a mouse, more appropriate on a touch interface
    3. Can't be done on the modules page since the modules page has a crazy dependency tree
    4. The modules page submit handler is a performance/memory hog, having to run that everytime the person uses a slider would kill the site
    5. We should use jQuery Mobile instead if we're going down that route, as they have it working nicely
    6. Can we please stop all the bike shedding and split this up into a number of different actionable items? :-)
    francis55’s picture

    Issue tags:+modules, +favorites

    I like the idea of favorites.
    We could use favorites in other contexts: favorite views, favorite nodes, etc.

    As a newbie user of packages like Drupal commons, I know I get submerged by the amount of stuff already in the application, and the items I add on get completely lost in the mass. If there could be a "my favorites" page where I could find links to my modules, nodes, views, blocks, etc, that would be a start to reducing the feeling of being lost in the wilderness.

    pillarsdotnet’s picture

    At the risk of bikeshedding... Would it be possible for the various tabs to be pluggable? For instance, I'd like to write an add-on that allows you to adjust module weights by filtering on a particular hook and drag-and-dropping the list of modules that implement it. It would be nice if I could add that as a tab on the modules page and maybe even re-use some of the search functionality.

    Also, per-module configurations could be added as inline per-module tabs in addition to their administrative menu locations.

    webchick’s picture

    pillarsdotnet: That's just hook_menu(), no? You can add tabs wherever you'd like.

    webchick’s picture

    Title:D7UX: Redesign Modules Page» D8UX: Redesign Modules Page
    Issue tags:-D7UX, -Drupal 7 priority+d8ux

    Also, this is D8UX at this point. :P

    webkenny’s picture

    I have to agree with #88 - Unless we plan on the modules screen only ever showing up on devices which have touch, we should ditch the sliders. No bike-shed here, just pointing out a big +1. (Also, subscribing)

    I don't see any fundamental problems with checkboxes as long as there are "normal" interactions for them like you'd find in just about any web application.

    Some requirements I can think off of hand:

    • Shift-Click of a checkbox preceded by a single click should select the range. GMail can do this so it's more than possible in a browser by now.
    • Select All

    I see the 2nd covered but we should have ways to deal with ranges.

    eigentor’s picture

    I guess the sliders are not the primary part of the layout, but somehow a part that was discussed a lot.
    Maybe we get to some fancy Ajax saving that follows the new interaction pattern I know from my Android Device: click an option and it is changed. No need to save.
    Still this might be trouble with modules, since this installs database tables.

    I guess what philip was after with this was a clear indication if a module is on or off.
    In wordpress I think they color the entire row green if it is on. We can sure find a way for that like in other parts of drupal:
    How about coloring it green when you check the select, and still having to save. When saved, some part stays green. Does not need to be the entire row, might be too much.

    webchick’s picture

    Do we have any evidence that people find it difficult to tell if a module is turned on or off with the checkboxes? I know I certainly have never seen that.

    eigentor’s picture

    You might have a point :)
    Finding the module at all and understanding all the crazy submodules and dependencies are a much bigger issue for sure.
    So maybe the wretched switch should be put in a solid last place in the queue of problems.

    webkenny’s picture

    The problem with color indicators is you have to also have some "as clear" alternative for those who don't perceive colors that well. For months, I wondered why a colleague of mine couldn't tell when a comment was "private" then I finally asked. He didn't see light colors well (the colors that make up most web apps indicators) - So maybe a larger checkbox is in order. But only slightly. The page is long enough. ;)

    luco’s picture

    @webchick do I ever miss a comment like yours in discussions like this. it's not over till it's tested! ;D

    however, UI-wise, both the checkbox and the ON|OFF switch serve the same purpose: to turn things on and off! so there could, I don't know, be a module for changing checkboxes into switches? :P

    @eigentor I've once suggested vertical tabs on the modules page, or at least a menu with anchors. I didn't cause much of a commotion, though.

    @webkenny totally. the colour blind are people too.

    catch’s picture

    The main advantage of the switch would be allowing modules to be enabled/disable in-line, we might be able to do that with a checkbox if the interaction is clear though.

    Having the interactions inline would allow for one at a time (or one + dependencies) at a time enabling / disabling to be enforced, which would avoid situations like trying to enable all modules at once and getting a big wsod when you hit submit (oh the memories).

    luco’s picture

    yes, catch, but when you install a module it creates tables. that would bloat the DB while a user is fidgeting with the modules they want, or even if you happen to switch something on by accident. so you switch it on and off and the tables get created then dropped?

    anyhow using both is overkill. I still haven't seen a use case for that.

    personally, I think people are waaay too much into their capacitive touch interfaces [tm].

    also. it'd be nice if you could check some module and its dependencies get checked automagically. now that would be cool.

    arcaneadam’s picture

    I think the use of sliders is really a moot point and something that is really more of a theme level issue anyways. If we can decide on whether or not to enable/disable module on the toggling of a checkbox, then some enterprising JS guru can create a mod/theme that implements toggle slider/buttons that swap out the checkbox. Who know's maybe that functionality could even be built into stark if people like it enough. But the system.module should only implement the ajax and checkboxes and let a theme or contrib module provide that extra cherry on top (IMHO).

    I'd also agree with Rob Loach that this should really be broken out into multiple actionable issues.

    jstoller’s picture

    Sorry to come late to this party, but here are some thoughts, in no particular order...

    1) Somewhere in the details provided about each module, we need to list the file name of the module. Or better yet, the file path. At some point during every site's development I go to delete the files for modules which I experimented with, but ultimately didn't use. Unfortunately, in many cases it is not very obvious which files go with which modules. Especially when you have several similar modules that you are testing.

    2) I like the idea of color-coded row backgrounds. Namely making the rows for enabled modules green and disabled modules gray. The one thing I'd add to that is a different color for modules that were once installed, but then disabled and not yet uninstalled. These colors should of course be checked by someone who's colorblind, to make sure they're differentiated enough. And I wouldn't rely on color coding alone. Each row should also have some text and/or icons that indicate its status.

    3) I agree that the sliders may be unnecessarily problematic and, in combination with the checkboxes, could cause confusion. I've been around for awhile and when I first started looking at the mockups on this issue, I was confused about the disconnect between which modules were checked and which modules had their sliders set to "on". Given this and many other slider issues which have been raised here, my vote is no sliders. Other elements (see 2) could be used to indicate status.

    I recognize that removing the sliders and returning to the checkbox as the mechanism for enabling/disabling modules does make the idea of bulk actions difficult to implement. Obviously you can't have one checkbox both signify which modules are enabled and allow you to select modules for bulk actions. I have two possible solutions to this. First, the checkbox could be used solely for selecting modules to be the subject of bulk actions. As long as the current status of those modules is clearly indicted with color-coding/text/icons, it should work just fine. This brings the benefit of bulk actions and is similar to other parts of Drupal, but only one type of action can be done at a time. Another option would be to keep the enable/disable checkboxes similar to how they are now, but add an "Actions" tab when you open a module's details. This would contain additional checkboxes for Update, Uninstall and anything else which might be appropriate. This could be a nice productivity boost—allowing users to string together a whole host of actions in one form submission—but it also could bring problems of its own.

    4) Disabling the checkboxes for modules with dependency issues is just annoying. This has been a long standing frustration of mine. I don't want to load a page five times just to disable all the modules I need to disable. If you really want to disable those checkboxes, then there should be a Java Script that enables them dynamically based on the other modules a user selects or unselects in the interface. Of course that seems really complicated to me. A better solution might be keep all checkboxes enabled, but put little warning icons next to them if the module either requires modules that are not yet enabled or is required by modules that have not been disabled. Then, when the form is submitted, Drupal can ask the user if they wish to automatically enable/disable these other modules, assuming they haven't already accounted for that in their other module selections.

    5) The new/enabled/disabled organization scheme is great, but to be honest I don't think I'd use it as often as category organization, or even just an alphabetical list. There should be an easy way to switch between these displays and the selection should be remembered between visits to the modules page. At least for the length of the session, if not saved as a user preference.

    6) If I've been following this correctly, we're not talking about a "text search box", but rather an as-you-type "title filter field". Much like what the Module Filter module now offers. This seems like an important distinction to me and I want to make sure it stays clear. Also, it's not absolutely necessary, but auto-complete might be nice in this filter field.

    7) Right now I appreciate the vertical tabs I get from the Module Filter module which let me quickly isolate one category in the module list. I understand people don't want to use vertical tabs here, which is fine, but there should be a quick and easy way to filter down to one category. A drop-down select list seems the likely candidate. This should work in conjunction with the title filter and should be available in all display modes.

    8) As has been pointed out by others, there seems to be a lot of unused space in each row of the table. Why not bring back a little bit more information. Sure, descriptions would be too long, but at the very least we should be able to include the version of each module. You could probably fit the file name as well, with room to spare. Something like:

    ———————————————————————————————————————————————————————————————————————————————————————————————————
    [] !! Content                          cck-8.x-4.2                                         Enabled
    ———————————————————————————————————————————————————————————————————————————————————————————————————
    []    Imagecache javascript crop       imagecrop-8.x-2.0                     Out-of-date | Enabled
    ———————————————————————————————————————————————————————————————————————————————————————————————————

    This would definitely help scannability. Often I just want to check what version of something I have installed.

    9) A reinstall option in the bulk actions drop-down might be nice.

    10) The "Permissions" tab in the detail view of each module is a very nice touch, but you should be prepared to deal with sites that have a lot of roles, as well as modules with lots of permissions. I don't think either of those are really edge cases.

    11) Looking at the module detail view, as shown in #43, it would be nice if each vertical tab indicated how many items it contained.

    12) If we're providing an "Update" action for modules, then there should be a section in the detail view (maybe another vertical tab) which shows all the applicable versions of the module and gives users the option of choosing which one would be installed. Perhaps they want to upgrade to a beta or dev version.

    Xano’s picture

    We could use PHP to disable a module's dependents, just as we enable a module's dependencies.

    luco’s picture

    @jstoller I agree with pretty much everything, especially the dropdown in (7).

    users select which module group they want to enable modules in, and the group shows up. the rest doesn't matter, so it's taken out of the way. as an added bonus, that gargantuan scroll is minced.

    that's pure UI gold. :]

    quicksketch’s picture

    Category:task» feature

    I'm moving this to a feature request, since our new policy adopted in http://drupal.org/node/1201874 puts a cap on all major/critical bugs/tasks. There are many other features just as worthy as this one; we shouldn't prevent them from moving forward just because this is categorized as a task instead of a feature.

    yoroy’s picture

    Considering the awful performance of this page in usability testing and it's relative importance to using Drupal succesfully this issue is more of a bug than a task even. Downgrading this to a feature request comes across as ignoring that problem imo.

    catch’s picture

    Category:feature» task

    Yeah I'm moving this back to a task for now, there is plenty of bad code around the modules page, #820054: Add support for recommends[] and fix install profile dependency special casing and #943772: field_delete_field() and others fail for inactive fields for example - so this is something that needs refactoring both at the API and UX level, and they will need to be done in concert to at least some extent (the field critical adds a new concept to the Modules UI that it's not really built for, for example).

    quicksketch’s picture

    Ugh, well I look forward to this being fixed in the next 6 months so I can get in my first feature patch in 2012. :P

    RobLoach’s picture

    Having the Batch API on there would be super duper helpful.

    RobLoach’s picture

    In case you missed it, How to fix the modules page, by Earl Miles. He makes a few points:

    • Add module "categories"
    • Have "package" actually retain to modules
    • Filter/sort
    • K.I.S.S. - Up front information should be limited
    • Status indicators to make enabling multiple modules not as expensive
    • File dates in the system table
    eigentor’s picture

    We had one thing during the last iteration that could help especially Drupal Newbies a lot: Sort newly uploaded Modules to the top (or assign a category to them when they have just been uploaded). Maybe they shold be color-coded as well. "Just uploaded" or whatever the category can be named.

    This way somebody who uploads a new module and wants to enable it, never has to scroll through the big table of desaster, but easily finds them at the top. Might be a bit tricky technically, but solve the biggest problem.

    As more people get used to Drupal, the more they will be willing to search on modules page. But especially the brandnew ones need help not to be apalled and confused. So for them this would help a lot.

    klonos’s picture

    I personally don't agree with all of Earl Miles suggestions (or for some I simply fail to see how much they'd improve things - if at all), but I surely like to see these implemented:

    1. Filtering and sorting (currently I use Module filter to achieve this).
    2. Modules' update status indication right there on the modules' page.

    Since this is about redesigning the modules' page, I am also cross posting my suggestion in #857090: D8 Modules' page: Add links to module help, project page + merge operations links to one cell.:

    3. Move the operations links to a single table cell. Please see how table widths are messed up and inconsistent in narrow themes (like the core bartik) and how much more clean it looks when the extra links are rendered in a single cell.

    klonos’s picture

    ..oh I forgot to mention:

    4. Enabling/disabling without page refresh (à la Views 3).

    droplet’s picture

    module page missing some important info / features:
    1. When a module is missing, it display shortname (machine/code name). It hard to find out the module if that is a sub module
    2. Missing a way to Delete modules from harddisk
    3. Missing an automatically way to download missing modules

    sub +1

    klonos’s picture

    Reading this issue from start one sees a lot of mockups (probably outdated/obsolete now) and there's no way to actually know where we stand right now since this stared back in August 2009 as a D7 issue. We need an up to date summary with currently decided/chosen battle plan or perhaps just ditch this one and start afresh.

    klonos’s picture

    ...breaking it down to smaller issues would help too.

    Cross-referencing #913712: Improve modules page table poor layout.

    bfroehle’s picture

    ~

    eigentor’s picture

    I guess just starting afresh with new Mockups with some Explanation would be just fine.
    Having worked some with Balsamiq recently I'd say the balsamiq level of detail is enough for these mockups, which saves time.
    http://www.thewebmadeeasy.com/AtomsNetwork/Files/238/basalmiq2.png

    droplet’s picture

    someone able to update Issue Summary ? Thanks.

    klonos’s picture

    I'd be willing to spend some time to do that, if only I knew what was finally decided. I mean, from reading the whole issue, I can see various mockups and ideas thrown here and there (most of them badly outdated too), but no fix on a specific target.

    As for updated mockups, I guess at least for the search/filtering feature that seems to be widely requested/desired, you can try the combination of Module filter and Instant filter as I've already suggested back in #112 for a live, working demo ;)

    I personally prefer the forked project Module filter NG instead of the original Module filter because:
    - it implements #1023252: UI should utilize Drupal 7 core more - new 7.x-2.x branch?
    - it is actively maintained/updated in tandem with Instant filter (same maintainer).
    - it implements my suggestion to merge operations in a single cell for a cleaner table layout.

    Bojhan’s picture

    @klonos Nothing has been decided yet from a UX perspective, other than it being neccairy to have a search function. I'd say thats one of the first things we need to get in and is currently lacking activity over at #396478: Searchable modules page

    bleen18’s picture

    subscribing

    RobLoach’s picture

    xjm’s picture

    #119: Most contributors can't edit the summary because of the input format used. If someone could swap the input format now that anyone can post images, then we can add a summary. :)

    Edit: the issue summary is now Filtered HTML.

    mannos’s picture

    Seconding yoroy's comments about sorting. Enabled vs. not, at the very least. After installing a new module it can be a pain to find it, though Mark Boulton's 7.x Seven theme has made it much less stressful on the eyes. A toggle for sorting by install date would be useful for enabled modules (and if applied across the board as opposed to filtering on enabled modules, would inherently implement enabled vs. not... to some degree).

    eigentor’s picture

    How about using module_filter as a solid starting point.
    We have started to use it on every site we create and never want to go back to default

    Only local images are allowed.
    http://drupal.org/project/module_filter

    It has a lot of good ideas, even stole the +1 idea from Wordpress to indicate where a new module is installed. It is basically lacking only some things:

    • hide checkboxes for additional filters behind "more filters"
    • Have a default tab at the top "Newly uploaded modules" (or different wording for the last modules that have not been enabled yet)
    • Maybe a more high-end and faster filtering mechanism like sun indicates. For the modules page I have always found it to be blazing fast enough, even with 100+ modules, though
    • second "save" button at the end of the module list to avoid scrolling up all the way again

    Maybe the module author greenSkin wants to join in here?

    greenSkin’s picture

    Let me begin by first explaining a little of Module Filter's evolution.

    Back in '08 I became overly annoyed with trying to find the module I was looking for and thus spawned Module Filter. At that time Module Filter only offered the ability to filter, no tabs or other UX tweaks. Eventually I dug deeper into improving the modules page (at least improvement in my own eyes) by implementing tabs instead of fieldsets (the tabs look was inspired by Views 2) and the addition of an "All" tab. This required Module Filter to override the theming of the page, partly to get rid of the fieldsets and partly to alphabetize the projects (modules). The "All" tab allowed the end user to filter over everything and to present everything in alphabetical order rather than alphabetical only within the package. Switching to a tab acts like a filter in of itself, filtering modules based on a package. I eventually added things like the +1/-1 count and their associated row colorings, the additional filtering checkboxes (a feature request), the count shown just below the title of the active tab of the number of enabled modules out of the total available modules for that tab, and the ability to keep the save configuration button accessible when scrolling.

    Several have asked that Module Filter's tabs would utilize the work done by Vertical Tabs. I recall when I was first implementing the tabs view that Vertical Tabs was being developed. At a point I had pondered requiring Vertical Tabs for the tabs implementation but decided against it for Drupal 6 as I didn't want the module to be dependent on another. As for Drupal 7 I have not been convinced to switch probably solely on the lack of being able to display an "All" listing in alphabetical order without some major JavaScript magic.

    Now comes the Drupal 7 2.x branch. Thanks to some spurring from both @klonos and @Kiphaas7 I begun an almost rewrite of the module, cleaning the code, making the tabs look a little more like Drupal 7's integrated vertical tabs, and improved performance. The improvements, though, have not stopped there, and is partly the reason 2.x is still only available as a dev release. The following, and what is more in context to this issue thread, are further additions made to the 2.x branch of Module Filter.

    Screenshot 1

    1. Replaced the +1/-1 with a CSV string of each module's name.
    2. Removed the Operations column and appended the operation links to the Description area. Formatted the operation links to display inline.
    3. You'll notice there is no longer an "All" tab. Now when no tab is selected, the list will show everything just like the "All" tab did. When a tab is selected, click it to deselect it. You might also notice that the "Other" tab is slightly lighter than the rest, this is because my mouse (which was not captured in the screenshot) was hovering over the "Advanced help" project which resides within the "Other" package. This allows the user to browse over the entire list of modules and be able to see what package it belongs to (as long as the tab area is visible).
    4. The "Save configuration" button area now by default will stick to the bottom of the window when the tabs list is longer than the visible area of the browser window, and sticks to the top when scrolling past the list of tabs.

    Screenshot 2

    1. You can see the "Save configuration" button area stickied to the bottom of the window.
    2. Shows what it looks like when a tab is selected.

    Screenshot 3

    1. Filter text is entered and the tabs not containing matches are hidden. This can be disabled in settings for Module Filter.
    2. A count of matches for each package is displayed in it's tab.
    3. Filter operators. Currently the 2.x branch offers three operators: requires, requiredBy, and description. I won't elaborate here as I think it's fairly self-explanatory, though the screenshot reflects the queries processing with AND I intend to make it process with OR. This is because I felt the chances of not finding what you need based on the use of a single query were slim and that by instead using OR allows for users to list modules like ones that require "Views" as well as ones with "Store" in the description.
    4. A simple clear link that clears the filter input.

    Not shown in any of the screenshots is the use of URL query strings. Basically URL query strings can be used to default the filter input and checkboxes. Currently the implementation is only half-baked, the URL queries can be entered by hand but not yet programmatically. This spawned from the desire to remember what filter criteria was set (including what tab was selected) when the form was submitted and to re-apply them. By using URL query strings the modules page becomes much more friendly via links. For example, module's help text (hook_help or perhaps advanced_help module) could link to the modules page and pre-define relevant criteria.

    I hope this helps to prove at least that the core modules page does in fact leave a lot to be desired. I am glad to see it is a priority to Drupal 8. And thank you @eigentor for bringing me in to this thread.

    yoroy’s picture

    Awesome write-up, thanks! One question that immediately came to mind was regarding your point 3: how to select no tab after you did select one? I'll have to play around with the module a bit.

    This also shows that Ubercart is a very bad boy :)

    greenSkin’s picture

    Ahh, yes, excuse my forgetfulness. Selecting the active tab would deselect it. I've edited the post to include this point.

    klonos’s picture

    Wow James! Thanx for taking the time to explain all the progress made in the 2.x branch. Perhaps you need to edit those img tags and reduce the screenshots' width so they fit nicely in smaller screens though ;)

    I kinda stopped following the progress of Module Filter around September 15th (that is the last 7.x-2.x-dev I have downloaded) because I switched to using Kiphaas7's fork instead: Module filter NG (NG stands for "New Generation"). The main two differences of this fork to your original module that made me decide the switch were that:

    a) it takes advantage of Instant filter (that I think should be in core btw). Instant filter implements a generic filter API (re)usable by other pages than just the modules pages like the users, content, admin/config and reports/updates pages. There are feature requests filed in order to also implement it in the permissions & reports/dblog pages - perhaps other pages could benefit too:

    #793478: Add instantfilter to permissions configuration form
    #1342072: Add Instant filter to the "Recent log messages" (admin/reports/dblog) page

    b) it implements #1023252: UI should utilize Drupal 7 core more - new 7.x-2.x branch? and uses core as much as possible (core vertical tabs for example).

    c) it implemented feature 2 shown in the 1st screenshot at post #127 (your module -the 1.x branch- didn't do that back then). #857090: D8 Modules' page: Add links to module help, project page + merge operations links to one cell. is the related issue filed against core.

    Can you please update on whether you decided to or have already implemented any of a or b above in the 2.x branch??

    yoroy’s picture

    Mind you, right now I think this discussion is better served with a clear definition of the different *problems* we want to solve on the module page. It's tempting to start discussing this in terms of which parts of which existing contrib module should be moved to core. There's value in that, but we need to be able to discuss this based on user goals first.

    This is not to discourage the discussion here, just pointing out what needs to be done to be able to move this forward. At 130 comments in we need to step back, regroup and outline the high-level objectives and create some better-scoped follow-up issues.

    Comment #73 has a good start for the summary we need. Anyone up to editing the original post on top and add an updated version of #73 there?

    Again, thanks for all the input & do continue :)

    aspilicious’s picture

    StatusFileSize
    new82.61 KB

    Hmm I always disliked the table inside a vertical tab idea. I think it's better to move tables and stuff outside the vertical tabs.
    Here is a screenshot to show what I mean. I just cut pasted a few things around.

    module_list.png

    And now we should do what yoroy says in 131 ;)
    After defining our goals I would brake up the patch in several sub tasks.
    The filter for example can be added afterwards. (if we choose to use a filter)

    xjm’s picture

    Personally I would hate the vertical tabs, because they'd prevent me from searching/scanning on the page for the module I wanted to enable, and I'd have to effing click around looking for it.

    Edit: Alright, aspilicious tells me that if you click a tab a second time, it disables it and shows the full list. (?) Doesn't seem intuitive to me, but I guess maybe the mockups don't convey everything.

    bleen18’s picture

    xjm: in addition to aspilicious' clarification, note that when you first get to the page all the modules are listed by default and you can scan all you want. IMO this makes the less-than-intuitive nature of clicking a tab a second time, much less important since that is the default view a user sees

    jstoller’s picture

    Click-to-deselect, while a welcome new feature, still seems unnecessarily unintuitive to me. I prefer to see the "All modules" tab come back.

    klonos’s picture

    @aspilicious, #132: having the table header as shown in your screenshot/mockup (on top of/outside the tabs) is kinda WTF for me UI-wise (and plain ugly if we count personal opinions here). It seems as if the categories tabs are actually some badly aligned cells or messed up rows. Most users (at least Windows apps/UI accustomed people) would expect different behavior from such a UI design. Tabs are there to group together a set of things. They don't need a header (IMO) and that goes for all vertical tabs used across all Drupal UI too - not only those that contain tables. It's simply a matter of consistency.

    I could live with the table headings being on top of the vertical tabs set, but we should definitely not add a "Category" heading for the tabs. On the other hand... if we don't, then why bother moving the table headings outside the tab?

    @xjm, #133:

    ...I would hate the vertical tabs, because they'd prevent me from searching/scanning on the page...

    When you say "searching/scanning" here, do you mean "looking"/"scrolling" at the whole of the page and "manually" looking for the desired module? I'm asking simply because the actual "searching" (as in "filtering" - not "looking") I believe is well taken care of by the filter thing: simply start typing a few keystrokes! I'm sure you'll agree that this is way more effective then one trying to "manually" locate things.

    klonos’s picture

    Updated issue summary.

    eigentor’s picture

    Issue summary:View changes

    Updated Issue Summary

    eigentor’s picture

    I had another stab at the issue summary, which thanks to the Project module improvements is now in the start post.
    Feel free to improve on it.

    Maybe we should listen to Yoroy and try to sort out the problems that have to be solved and take a step back from implementation details.
    This issue is so big that probably it needs sub-issues later anyway.
    I'd say this one can only serve as a meta issue, and in that, let's go meta :)

    klonos’s picture

    Yes, we shouldn't get too exited and kill any kittens at all on our way trying to solve this one. Thomas did a great job updating the issue summary (thanx), lets now define the problems and break this down to smaller issues. Shall we?...

    I was thinking to perhaps start by trying to solve the searching/filtering thing, since this would be a major UX improvement. As I previously said back in #130, I strongly believe that we should focus on using some sort of a generic API for form filtering so that we can re-use it in other forms all around the UI as well. The Instant filter contrib project is already doing a great job in doing that. I think that besides the standard filter field it also provides the ability to use sets of checkboxes in order to filter things by certain pre-defined properties.

    Then we can move to solving the grouping thing. It is generally agreed that the modules' page tents to get bulkier as more and more modules are added to any installation. The way we have it now is a major UX put-off for any site admin going through that page. This makes common tasks a really tedious job. We seem to agree that taking advantage of the core vertical tabs is the most preferred way to solve this.

    These are IMO the two major things that should be broken to two separate issues. Once we get these in (or in parallel - but definitely in separate issues), we can add in all the smart ideas like...

    - the easily accessible & always-in-view, sticky "Save configuration button",
    - the merging of the actions links, so they don't take that much space for no obvious reason
    - all the nice visual "goodies" like the indicator numbers & module names on the tabs etc
    - ...

    klonos’s picture

    ...so? Do we agree on:

    a) making this a meta-issue (it kinda already is)
    b) filing a new issue about having a generic, reusable form searching/filtering API in core
    c) filing a new issue for implementing the searching/filtering API in the /admin/modules page (for other admin pages we create separate issues)
    d) filing a new issue for implementing (better) grouping in the /admin/modules page by using core vertical tabs
    e) filing separate issues for implementing each smart UI improvement we already came up or might come up with in the future

    greenSkin’s picture

    I do think the addition of Instant Filter, or some variant, into core should be a high priority as it would ease use of several pages and who knows how many contrib modules. That being said, I do think that the filtering should take a back seat. I think we need to settle on where we need to go first. Let a separate issue of adding a core "instant filter" take care of the filtering, possibly then later coming back here to include specific filter rules and such. Especially for graceful JavaScript degradation.

    Considering graceful JavaScript degradation, I think we need to use a construct of form inputs for filtering the list. Though when JavaScript is available I think we should lend the filtering to core's instant filter.

    I like the idea of three groups (new, enabled, and disabled) but I wonder if it could be problematic at the same time. For example, say I'm looking for the Entity Tokens module and I'm not sure if it is new, enabled, or disabled. To make matters worse I have JavaScript disabled so I have to either use the browsers find feature (which we all know is a nuisance) or I have to look through each of the three groups. I think it would be simpler to just keep everything together, alphabetically, and let the filter do the work. Or perhaps even better, provide a toggle where the modules are all in one group or split into three.

    If elected to go with using the three groups, I think tabs should definitely be dropped and rely on the filter for reducing the list(s) to modules in selected categories.

    I'm a little wary about the batch processing, but other than that I'm liking where this is going.

    eigentor’s picture

    While looking into no-Javascript fallbacks I think it is a secure street to assume that 98%+ of users have it enabled. Javascript in itself becomes more important as Drupal has a strong emphasis of accessibility. But I do not think we need to think first of the possibility of disabled Javascript.

    Think of it, provide a decent fallback, but start with and concentrate on the 98% I'd say ;)

    Yes, grouping is no easy one. Maybe it is a good idea to think of probable and common use cases building on the personas? Who would be looking for the entity module and how could they find it.
    If there is an "All modules" view, I'd think this should be alphabetical. The current grouping by packages does help the more experienced users at best.
    You will always provide a default grouping whatever options you provide, and the default better be the one that suits everyone best :)

    But the discussion can get stuck easily on that. Maybe that would be best a spin-off issue "Grouping options for improved modules page"?

    yoroy’s picture

    Thanks for the summary eigentor!

    Sun outlines some todo's in http://drupal.org/node/396478#comment-5093082, including this yet to be opened issue:

    Enhancement of themed tables to contain a concept of "rowgroups" (which is yet unknown to me). That's a wide-ranging and pretty fundamental change on its own.

    #396478: Searchable modules page and
    #229193: Incremental filter for permissions page, too.

    Also, less words, more sketches in here :) There's older issues here and discussions on g.d.o/usability with other ideas. Research and collect these ideas and images will also be full of win.

    jstoller’s picture

    StatusFileSize
    new96.12 KB
    new163.35 KB
    new169.27 KB
    new170.86 KB

    Here are some visuals, as requested.

    First, I moved the filtering out of the vertical tabs. These filters will apply no matter which tab the user is on and should persist as the user navigates from tab to tab.

    I created two clusters of vertical tabs, to allow for different modes of searching and increase "findability" of modules. The first cluster includes the default "All modules" tab, as well as easy access to viewing just newly installed modules, enabled modules, or disabled modules. Below that are the familiar category tabs.

    modules-page-all.png

    In order to improve "scannability" I drastically reduced the information provided in each row. I propose that when scanning over the table, the important information is:

    • Is this module enabled?
    • The name of the module
    • The project name and version
    • Any reason I should pay attention to that module now (i.e. upgrade needed)

    Descriptions and required modules are important, but they contain too much text and inhibit scannability, so I've moved them lower in the hierarchy. Clicking on the module name or disclosure triangle will reveal details about that module (see "Context" in the image below). This includes the module description, any available actions and lists of other required/dependent modules. It also includes a list of available updates to this module. From here, the user can enable/disable any dependent modules, or pick an update to instal.

    modules-page-all-w-detail.png

    By default these lists will be in alphabetical order by module name. However, I envision that click-sorting can be used to sort them by project name as well. Also, all the tabs in the top tab cluster have a "Group by category" checkbox. Checking this will still list all the modules, but will group them by category (see image below). I thought about permitting the categories to be collapsed, as they are now, but decided that the category tabs negated that need.

    modules-page-all-grouped.png

    The category tabs work as you would expect. And of course, these tabs don't require the "Group by category" checkbox.

    modules-page-category.png

    Thoughts?

    bleen18’s picture

    re #145:

    1. AWESOME!
    2. What else is in the "module name" dropdown to the left of the filter input?
    3. How do we know what is "new"?
    4. I would suggest having a second save button just below the panel in case it is still long (perhaps we could use CSS media query to hide/show it only if page is tall enough?
    5. STUPENDOUS!!!
    eigentor’s picture

    Jstoller:
    This is an awesome start!
    Can we have a public decision somehow to use only tools like Balsamiq for Sketches in that first stages? That rocks in being quick and getting away from eye-candy in the early stages...

    What I like especially is: The Order of the tabs from top to down.
    Someone that is completely new to Drupal probably won't care at all about the lower tabs. He will only care for "New modules". The first time he really actively uses this page, he will have installed his first module. So he clicks "New modules", which is very near to the top.

    One might emphasize this more by color: making the "beginners tabs" more high-contrast.
    In the bottom, we could provide basically a myriad of filtering/grouping options. Only limit would be to not let the list get to long.
    The trick is: Only more advanced people would use them at all. Only limit would be to let the list not get too long and intimidating.

    It might even make sense to make the bottom part swappable by package/by module. I think tha actual module filter module uses by module, while you have used current drupal's by package grouping. Maybe this makes sense for some people, so there could be a switch for the bottom part to have the tabs by module or by package.
    Forget this part. Better decide for one :)

    Would you mind sharing your balsamiq files? I startet to re-build your mockups again, but isn't that a waste of time...

    jstoller’s picture

    StatusFileSize
    new6.73 KB

    I've attached my Balsamiq file, for those who are interested. It distracted me from getting any "real work" done today, so I'm glad to know it's useful. :-)

    @bleen18:

    1. Thanks!
    2. I was thinking "Module name", "Project name", possibly "Description", and perhaps "Anything". I'm open to suggestions though. Plus, there may be technical limitations.
    3. Not entirely sure. Perhaps Drupal could note the timestamp when a user loads the modules page and compare that to the time when modules were added/updated? It was a request from earlier in this issue, but I haven't worked out the technical details.
    4. It would be better, I think, if the button just followed the screen down as the user scrolled the page. That should be easy enough to do with jQuery.
    5. Thanks again!

    @eigentor:
    I wouldn't get too caught up in thinking of any of the tabs as for beginners or advanced users. I would have appreciated the category tabs, even as a beginner, and I'd appreciate the "New modules" tab now, even being strong in the ways of the Drupal.

    Color coding is something I considered and still think would be an excellent idea. I just thought the drawing would be more effective in black & white at this point. I don't think it would be appropriate for tabs though. I'm more interested in using color to code the rows of the list. For instance, we could do something like...

    • Light-green = enabled modules
    • Bright-green = modules that will be enabled on submission
    • Grey = modules that will be disabled on submission
    • Yellow = modules that have a recommended update pending
    • Red = modules that have a security update pending
    • Orange = modules that will be updated on submission

    All these details can be worked out later though. For now let's stick to big ideas.

    greenSkin’s picture

    +1 for #144 – Good job jstoller!

    I'm a little curious how the "requires" and "required by" checkboxes will be processed. Duplicate checkboxes can be a nuisance to deal with. I know it can be done but perhaps there's an easy solution I'm not familiar with. Or perhaps instead of these being checkboxes, a checkmark image is shown for the ones enabled or being enabled. Maybe the name of the "required by" or "requires" module links to it's module listing somehow. Similar thing for the dependent updates.

    greenSkin’s picture

    To the question bleen18 raised in #145 concerning how do we know what a "new" module is. I'd gander Drupal should glean a timestamp from the .info file for each module of when it was added/updated as jstoller describes in #147 and add this to the {systems} table so other modules can use it if ever there is another need for it. One of the many sub-issues to be created of course. :)

    bleen18’s picture

    So I did some VERY informal, VERY unscientific usability testing with my VERY non-technical wife and she scored really well with this design! My questions included:

    Q. How would you turn on a module?
    A. Click the "all modules" tab and then click the checkbox

    Q. How would you turn off a module?
    A. Click the "all modules" tab and then click the checkbox

    Q. What do you think happens if I click the "statistics" tab on the left
    A. It shows me a page of modules that show statistics.

    Q. How would you find info on the "foobar" module?
    A. She asked if there was a "foobar" tab on the left, and I said no, so she said she would type in the search box at the top of the table (note: she did not notice the arrow on the left - I had to show it to her)

    Q. (showing the design with module detail) What do each of these options do?
    A. The "help, Config, perms" links were obvious. The requires & required by lists were clear, but the meaning of the checkbox wasnt. Available updates made sense too. She assumes if you click the checkbox it will update the module.

    Based on this unscientific study I would say that the proposed design is extremely successful. I suspect that even the areas that were not totally clear (like the arrow on the left) would be much more clear once the design is fleshed out.

    Cant wait to start working on this ... :)

    yoroy’s picture

    Thanks for the report, good job getting some unexperienced eyes on this.
    How would dependencies be handled in this design?

    klonos’s picture

    Perfect!!! Thank you for all your hard work and time spent on this excellent write-up Jeremy. If we all agree that these mockups put together all the fundamental ideas discussed here (and elsewhere), lets then break this down to smaller issues and start implementing one feature at a time. Shall we?? Yes, details (such as coloring and filter list drop-down contents) can be worked on later on with successive issues. Two questions though...

    Do we re-invent the wheel with filtering, or simply work to get Instant filter in core as a reusable API and then use that?

    Are core vertical tabs able to do all we want? If not, do we file issues against vtabs in core or we do custom-coding?

    I'm asking because I think we'll have more chances to get things accepted if we depend on core features. If we don't, then I think that at some point we'll be eventually shown the contrib door (i.e. Module Filter/Module filter NG) ...which btw is fine with me - I already use Admin menu instead of the core toolbar like most people I guess.

    klonos’s picture

    StatusFileSize
    new30.58 KB

    ...btw, while I was at sf, I noticed this nice feature when filtering bugs. Just posting a screenie here so it doesn't get lost.

    yoroy’s picture

    @klonos: #143 has links to already existing issues for live filtering on admin pages

    bleen18’s picture

    re: #152

    Do we re-invent the wheel with filtering, or simply work to get Instant filter in core as a reusable API and then use that?

    I think we would be much beter off working to get Instant filter in core

    Are core vertical tabs able to do all we want? If not, do we file issues against vtabs in core or we do custom-coding?

    I *think* they should be fine ... if we find that we need to tweak, I would say we worry about that when we get there in the "Ok we decided on a direction, lets build the v-tabs for module admin page" issue

    That all said, it seems to me that we have 2 issues to open here:

    • Get "instant filter" into core
    • Implement vertical tabs on the module admin page
    eigentor’s picture

    Well, it is not for certain that vertical tabs are the way to go.
    While they work well in module filter, there may be other concepts for filters that have not yet been explored.

    That is what focussing on the problem instead of jumping to solutionls means. Of course, someone would have to post mockups with possible solutions.

    Personally I like the tabs as they may be a goable solution.
    But I know also I hated them first in module filter and always switched them off for the interface feels more cluttered with so many vertical tabs. In Core's UI Guide I think we have a rule that if you have to many items inside vertical tabs, you should not use them as scannability gets lost.

    I find it a bit disctracting to have a second long list besides the already long module list.

    So what options could we have to offer filtering?
    - do horizontal tabs
    - hide parts of the vertical tabs behind a "more filters" option to only show on demand
    - offer more options for the search field and center everything around the search field

    Again, it might help to research what the general main problems are with the module page for beginners and advanced users - which will be different.

    Offering a lot of filtering options is good. But if the options are overwhelming and people do not dare to click somewhere but leave the page in panic you win nothing.
    This will be less the case for advanced users. But users not so used to the available-option-overkill in general Drupal will probably be.
    Yet it has been decided I think (has it?) to concentrate the UX Efforts for D8 more on the Side Admin kind of Persona instead of the content creator.

    What has not been decided if these Administrators shall be Administrators rather new to Drupal or if it shall be more the power users.

    Xano’s picture

    This is something I have seen on a very big Dutch tech site. All filters are checkboxes on the left, even packages/categories. This would allow users to view modules from different packages at once, but it would make the 'single package view' require two clicks instead of just one.

    Bojhan’s picture

    Actually, I find that a very interesting approach. However I really question the use of enabling one to several categories?

    klonos’s picture

    @eigentor, #156: While I understand (some of) your concerns Thomas, -when it comes to vtabs- you do need to keep in mind the following:

    - the use of vtabs was "decided" mainly because they are in core and because that's what we used when we needed to address the same issue (group/organize a very long list of things that grows as people install more modules) for the content edit form in D7. In other words the main reasons were keeping UI consistency and reusing existing code that does what we're after (as opposed to figuring out a solution that required custom-coding something from scratch).
    - the "decision" might seem as if it was a bit rushed (without any actual UX studies etc), but if you consider the success vtabs had with providing sanity in content edit forms, one foresees how they could help with the modules page too.
    - one can actually see all that in action if they install either Module Filter or Module filter NG.
    - we might have not actually gone through any extensive UX study specifically for this before implementing it, but we did have a wide acceptance of its use (a lot of contrib modules use them in their UI - views for one) and great feedback regarding its usefulness on content edit forms.

    @Xano, #157: very intuitive design indeed Bart. I think this implements some kind of solr search type of filtering, but if you give it some more thought, it's not that different from the instant_filter approach:

    - instead of having to click on specific tabs, you now have to click on specific checkboxes
    - instead of having to click on a "All modules" tab, you would now have a "select/deselect all" checkbox
    - they'd both take about the same vertical and horizontal space
    - they'd both show the number of current tab/category results (solr search does that)

    ...most importantly:

    - I *think* that solr search type of filtering can also be reused in other admin forms. So we'll benefit in other ways in the future - same if we used instant_filter.

    The only advantage I see when using the solr search filtering is that one will be able to filter/select multiple categories at the same time. Don't know how useful that might prove to be, but it is an extra bonus to the features indeed.

    Can we implement selected vs total of results in solr? If not, then count that to the cons. Also on the cons: solr searching requires special setup on the server side, while instant_filter not.

    Personally, I don't mind which way we go and where we place the widgets as long as we are able to implement all (or at least the most important of) the features we have talked about in this issue. I'm prepared to get accustomed to whichever design, so long as it makes my life easier and every day drupal administration a less tedious task.

    webchick’s picture

    Focusing on the problems we're trying to solve, I think a lot of it boils down to use cases like:

    - As a site builder, I recently downloaded a new module, and want to enable its functionality.

    - As a site builder, I am trying to troubleshoot a specific module.

    - As a site builder, I would like to get an overview of what modules are installed on a new site that I recently inherited.

    Under none of those circumstances is the category helpful (in fact, it's damaging to the third use case if I can't see all modules at once without clicking 50 times), so its prominence as a primary navigation tool is a bit puzzling. I would actually love to see us get rid of categories altogether, and have sub modules automatically grouped together and the ability for modules such as Address Field to register themselves as submodules of other projects. Not sure if that's on-topic here or not.

    But +1 for a "New modules" or similar. That's almost exclusively what I land on this page to interact with.

    Xano’s picture

    Personally I like* categories, because it allows to me to see all modules that can be used with Drupal Commerce at one glance. I *don't* like the rigidity with which it works as it is now. Webchick's solution about registering modules as 'children' of other modules (even though they're in different projects) makes sense to me. This doesn't have to do anything with this page directly, but it does influence how this page can be redesigned and AFAIK the package information isn't used elsewhere.

    Regarding package vtabs versus checkboxes: the difference is that vtabs present modules in different fixed subgroups whereas checkboxes communicate that there is big list of modules that can be narrowed down with a lot of flexibility. If we continue with displaying/filtering by package, we have to find out if vtabs aren't too rigid and if checkboxes aren't overly flexible and time-consuming.

    The advantage* of checkboxes is that we can put all filters in one column/bar, which puts all tools to edit the modules list in one place, whereas vtabs would split these tools in two (the tabs and the remaining textfield/checkboxes).

    To address the issue of "new modules": it would be great if we could somehow link to a list that displays new modules only. Do vtabs provide this option? Checkboxes can be prepopulated via the URL.

    Another advantage of using a single column with filtering options is that even if JS is disabled for some reason, we can make the filter column position: fixed; so it will still be easily accessible if the list is horribly long. This will backfire if there are too many categories, unless we make the filters scrollable, but we'd end up with Facebook-like sidebar issues.

    *) disclaimer: never have I participated in any UX-related study about this horror of a page

    klonos’s picture

    @webchick, #160: I personally find categories very useful Angie, both as a filter for the installed modules page in each drupal installation and here in d.o in the module search page as well. It is the only way AFAIK that we *currently* have to help with somehow grouping modules (and thus reducing the length/havoc of the modules page). It is what makes life-saver contrib modules like Module Filter work.

    I do find very interesting the feature you propose of being able to define a project as being a submodule of another project or a core module (is there any issue filed for that btw??), but as a complement to the current categories system - not as a replacement. If introducing this ability proves to make categories fully redundant in the future, then yes lets remove categories - but only then. We can for example group various views complementing projects under views and the same for field-providing modules under CCK/Fields or Commerce/Ubercart as Bart mentioned, but where would you group admin_menu under for example?

    A similar idea I had was to add the ability to define custom categories and allow admins to group modules to their liking based on these (using the same drag 'n' drop mechanism we have for the blocks page). The continuously growing size of a site's "Other" generic category lead me to this "breakthrough". If we implemented the feature you propose as well, then combining the two one could also drag modules under other modules besides under custom categories (a-la menus' parents/children)

    ...I can't see all modules at once without clicking 50 times

    As long as there is a "All modules" tab or a "check all" checkbox available, it'd only be a single click ;)

    @Xano:

    Checkboxes can be prepopulated via the URL

    Yep, count that to the pros, but please provide a use case where that feature would be useful because I fail to see how it could be used in the modules page. Do we refer to the modules page from certain other admin sections? If we do, it would be great to be able to link and at the same time limit displayed modules down to the intended ones.

    I don't know about if tabs can do this. Do they work with #??

    As for having all controls in a single place, yes I like that too. In the mockup in #157 I don't see you include the filter filed though. That would still need to be on top someplace. Right?

    Xano’s picture

    Yep, count that to the pros, but please provide a use case where that feature would be useful because I fail to see how it could be used in the modules page. Do we refer to the modules page from certain other admin sections? If we do, it would be great to be able to link and at the same time limit displayed modules down to the intended ones.

    I think it will be helpful after installation or for use in documentation to be able to link to certain selection of modules.

    As for having all controls in a single place, yes I like that too. In the mockup in #157 I don't see you include the filter filed though. That would still need to be on top someplace. Right?

    Yes, the filters on the left of #157 don't show the keyword textfield, which would need to be added. My apologies if this wasn't clear. This was a very quick sketch I did this morning right before I had to leave home.

    cosmicdreams’s picture

    These are the user stories that have frustrated me over the years:

    * As a site builder, I want to quickly find a module by name. Current status (in D7): Completely broken

    If I hit Control+F and search for the module by name I get all of the modules that depend on it for search results.
    Module Filter provides a great way to handle this. Similarly, I like http://api.jquery.com/ 's solution.

    * As a site builder, I want to disable all the modules I'm not really using. Current status in D7: Workable, based on experience.

    An experienced site builder / developer can know what modules are actually being used by having viewing all of the nodes, views, and other content and know what's being used on that page. It would be nice for a program to do this.

    * As a site builder, I want to disable an entire family of modules without submitting the page multiple times. Current status: use drush

    I've worked around this issue by standardizing on drush, but it would be nice to provide a UX that
    1. informs the user of the consequences of their choice to disable a module that other modules depend on.
    2. informs the user that those dependent modules will also be disabled.
    3. provide the user a simple way to change their mind before the disabling happens.

    Bojhan’s picture

    @cosmicdreams Would be a great contrib project, I can see this being possible already but its tricky until proven to be possible.

    I really like webchicks focus, I want to avoid turning this into a like or don't like categories discussion though :) They have their use, but are quite limited in terms of find ability.

    How would we do, having "new modules" do we time their appearance in the sites/default/module folder?

    webchick’s picture

    Yeah, I picture basing that off of their file create time on the file system. I have no idea if that's possible in a cross-OS compatible way. :P But that's how I'd do it.

    webchick’s picture

    Hm. We could also add something like a timestamp column to the system table and have the function which finds new projects populate it upon inserting new records to that table.

    greenSkin’s picture

    Concerning how to determine what modules are new, my thought is up at #149.

    I do think, until a better alternative becomes apparent, we should stick with the current implementation of categorizing modules.

    jstoller’s picture

    Some of my typical use cases are...

    • As a site builder, I'm looking for a module and I know it has something to do with input filters.
    • As a site builder, I'd like to take a quick look at all the Views related modules I have installed.

    The "All modules" list is important to have and should be the default view, but it is huge and difficult to deal with. Often I may not know the name of a module, or even exactly what I'm looking for, but I know it has something to do with Fields. Having those category tabs lets me very quickly cut the list to a small number of relevant modules, which I can then easily scan to find what I need. From my perspective, the category tabs provide a huge boost to findability and scannability, by letting me quickly flip between focused chunks of data. I'd much rather click between three different category tabs than scroll down the entire list of modules.

    Re #157: I'm not as interested in the checkbox approach. That just seems cumbersome. It negates the best aspects of tabs and doesn't seem to provide much in return.

    As I said in #144, I think the filters in the form above the list should persist as the user clicks from tab to tab. Taking that a step further, I think that when the user applies filters, any tabs that don't contain relevant data should be visibly disabled. When I apply a filter, I may still have a sizable list of modules, but if I see that those modules fall into only three different categories, one of which is relevant to what I'm looking for, then I just shortened my search time.

    Shyamala’s picture

    StatusFileSize
    new325.16 KB

    +1 for #144

    Would be great if we made the Header sticky and let the module section scrollable. The Header could in addition to the search section introduce the bulk operation buttons, or the save configuration button.

    Screenshot 1

    eigentor’s picture

    A lot of what is useful and what not comes from Experience with using the module filter module. I would stongly encourage everybody to give that a solid try. :) (which means trying it on a site you regulary go to the modules page, so you have some kind of long-term test). This would give us more metrics of what is already good and could be used 1:1, and what areas are still difficult. The difficulty to find a way to go back to all modules appears to be already identified. But it appears to be already adressed in the latest version of module_filter, where there is an "All" tab wich is also default http://screencast.com/t/Yce91fnJ

    In my personal usage, as said, I always switched off tabs and categories first.
    But then I saw someone else use them and gave it a try. It is actually quite convenient to be able to filter down the entire list to categories, and mostly using it I find what I search for quite quickly. And it is kind of the "fuzzy search" that some mention. You are not completely sure where to find your module - click here and there. More systematic people might use the search box with different search terms.

    Entering text in the search box - I mostly am too lazy, if I coult get to my goal without probably some klicks on the tabs would go first.

    What is still a drag is the unholy "other" category which basically means a module author either was to lazy to implement a proper package name for his module, or had problems to find a suiting one.

    Actually it would be interesting if beginners would tend to use categories. I would guess rather not, because all they will have on their site is core and a very small selection of extra modules. So this may also take away from the argument that the categories list is confusing, because more exerienced Drupal site builders will not be confused by it, because the may know what it is, and beginners will only have very few categories and thus tabs.

    One could maybe also safely say, the more beginner a user is, the more the "where is my new module I just installed" panic needs to be adressed.

    Keeping the use cases separate may save quite some discussion.

    Xano’s picture

    With more and more distributions being developed, more and more beginners will have a modules page that shows more than just core packages.

    webchick’s picture

    The reason I feel categories are useless is that—apart from the "sub-module" use case, which is clearly valuable—they are one module maintainer's arbitrary decision as to what noun or set of nouns loosely describes the space their module sits in. And there is no consistency between these arbitrary nouns across modules. It's fairly common on a site with more than a handful of modules for your categories to include things like: "Administration", "User interface", "UI", "Admin improvements", "UI tweaks", and so on. So now I need to click 5 possible places to find that module (and in the end, it's probably in "Other" anyway), instead of just scrolling down one single alphabetical list where I could quickly locate something like "Quicktabs" between "Panels" and "Rules." :(

    "Entering text in the search box - I mostly am too lazy, if I coult get to my goal without probably some klicks on the tabs would go first."

    I don't understand why if you were looking for Quicktabs, you wouldn't just type "Qu" into a search box, which dymaically filters the list and finds it at once, as opposed to scanning down the list of categories (which might number 30 or more), trying to mentally filter those down to a "short list" of ones which most closesly match the thing you're trying to find, clicking the first one, guessing wrong, clicking the next one, reapeat, until you finally just give up and fall back to using the search box. :P

    Unless you are very experienced with building Drupal sites, and you happen to intuitively know the package of the most common modules, this is your current path. Putting them into vertical tabs or checkboxes doesn't change it.

    Xano’s picture

    In the past an "integrates with" property for modules/themes was suggested. The UI could show these relationships similarly to dependencies. Would this be an improvement over arbitrary predefined packages?

    eigentor’s picture

    StatusFileSize
    new66.44 KB

    Here is an idea for how to make the categories optional to reduce clutter. I also put all options for the search box into a "more options" Fieldset. Changed "Filter" to "search". This may not be the correct term, but maybe it is more common to people to search instead of filter. Might be a bad idea, though. :)

    optional categories

    Bojhan’s picture

    I had a short discussion with webchick, its an interesting idea to consider alphabetical order for this list without the categories exposed by default.

    I think we need to look at this without the "installing something new" usecase, which could be handled by a simple "new" switch". I wonder, if we cant have something like searching on a package?

    @Xano You touch an interesting point, for distributions this is also a "showing off" what you got point. Having limited to no unrelated modules here (such as core modules), would be beneficial. However I personally think this is better served by something like a marketplace/project browser.

    I really like the recent discussions, loads of good ideas!

    klonos’s picture

    ...I don't mind "hiding" most of the controls (filter checkboxes, categories tabs) as shown in the mockup in #175, but as long as the last hidden/shown state is remembered for successive visits to the modules page. I understand trying to present a less overwhelming UI to newcomers, but as a non-beginner I hate having to click an extra time for each set of controls/widgets I need to use.

    A couple of minor notes:

    The existence of both the "Enabled modules" & "Disabled modules" tabs along with the "Enabled" & "Disabled" checkboxes might seem redundant to a new user. Perhaps the tabs should be named "All enabled modules" & "All disabled modules".

    The "Enabled" & "Disabled" checkboxes should not be presented when one is viewing the "(All) Enabled modules" & "(All) Disabled modules" tabs. It simply makes no sense.

    Xano’s picture

    I am really curious how we're going to make this degrade gracefully. With tabs, we'll have multiple occurrences (new, disabled and the module's category, for instance) of most modules on the same page. Without Javascript, how will we know which occurrence's checkbox takes precedence?

    klonos’s picture

    I took the liberty to update the issue summary of #430180: Move module_filter (or its functionality) in core for D8 in Module Filter's issue queue since we seem to agree that it is the most suitable candidate in contrib. Despite the issue's title it doesn't necessarily mean that we'll move it in core as is. We can instead "borrow" code/ideas so we don't reinvent the wheel (I've clarified that there as well). Please check it and update as you see fit. Let's make that issue the first of the ones we intended to break this one here into.

    I think that -if everyone agrees- I'll open another issue to move Instant filter in core (as a reusable API so it can be used in other places all over the UI) and a third issue to implement it in the modules page.

    jstoller’s picture

    StatusFileSize
    new170.19 KB

    @Webchick:
    I understand your point about the lack of consistency when it comes to package names and I totally agree. However, I still find the category tabs (as currently offered by the Module filter module) incredibly useful. Your example presumes that I know I'm looking for Quicktabs, but more often than not, I don't. So, lets say there were five potentially relevant tabs for me to look in. That still cuts out at least 70-80% of the modules which now I don't need to concern myself with at all. Most of the tabs will only have a handful of modules in them, which I can quickly scan and the time it takes to click between tabs is easily less then the time I would spend scrolling through the whole list. Even when I do end up in the dreaded "Other" list, it just feels so much more manageable when that's all I'm presented with, rather than it floating in a giant list of hundreds of modules. And the categories, inconsistent as they are, still give me a bit of insight into the nature of the modules I'm looking at, which I find helpful.

    Perhaps I'm being overly optimistic, but I also think the consistency of package naming could be improved. There's nothing preventing us from coming up with some basic standards for this and adding it to the documentation for contrib developers. It still won't be perfect, but I'm betting we can get a lot closer. We could come up with a few general categories that most modules would fit in and allow the larger modules that have an ecosystem around them to break out into their own categories. That's really where the category tabs shine. I regularly want to see which Views modules I have, or which field modules I have, or which Core modules are enabled. That's not something I can do with a title search field and it's incredibly frustrating to do when presented with the full modules list, even if it is grouped by category.

    I think it is important to keep in mind that different users will have different preferred methods to approach this page. Even the same user will find different approaches more or less useful depending on the task at hand. Therefore, I think it behooves us to support as many different modalities as we can, to the extent that we can do so without completely confusing the user.

    With that in mind, the question is not so much would you find the category tabs useful, but rather, does the presence of the category tabs prevent you from using this page in a way that does work for you? If having them is not detrimental to your user experience, then we should seriously consider implementing them, since for at least tens of thousands of people, it will greatly improve their user experience.

    My goal in #144 was to visually segregate the category tabs into their own cluster, so they wouldn't interfere with other browsing/searching modes, while still providing an intuitive and easily accessible function to those who want it. @eigentor, my preference would be to keep the categories visible at all times, unless UX testing shows that they are causing a problem. And if we do hide them like you show in #175, then as klonos suggests, the expanded state needs to persist across page visits for the same user. Same with hiding advanced filter fields.

    @klonos: I think you may be right about not having enabled/disabled as both a filter and a tab. In my mind, the filter seems the more appropriate. Tabs are better for chunking small amounts of information and both of those lists would be way too long. I also can't really think of a time I would use a tab like that. Instead, I suggest adding an "Unused modules" tab, listing contrib modules where no module in the associated project is enabled and therefore the files can be safely deleted. That is something I would use all the time.

    Here's a slightly modified version of my original mockup, showing changes to the filters and the upper tab group.

    module page mockup

    klonos’s picture

    I like where this is going more and more! I think Jeremy nailed it -yet once more- with the enabled/disabled/both radio button set. This way, the "Enabled modules" & "Disabled modules" tabs are simply the "All modules" tab with the respective filter applied. Simple and brilliant.

    As for the collapsed or expanded categories dilemma, well... yes when in the "All modules" tab and without any filters applied, it doesn't seem that bad (nor will it seem when in the "Other" category tab that tents to be equally long or more). When one is in a category/tab with only a handful of modules in it, I admit that it does seem ugly to have such a long list to the left that also causes the window to be scrollable & long. Personally, I would easily "compromise" with such a minor ugliness compared to what we currently have.

    PS: (kinda off topic rant): If I seem a bit too "eager" in all my posts related to this initiative here as well as HTML5, Libraries API in core and getting core updated to jQuery 1.7 (or whatever is latest), it is only because I secretly hope and wish that if we implement these four features we'd then perhaps give in and release D8 sooner with only these changes ;)

    • Modules page redesign + instant_filter in other admin forms in the UI would "mend" some of the bitterness left by things that didn't make it in D7.
    • HTML5 would help us get "momentum" - now.
    • Libraries in core would provide some more structure sanity (now that we have /core and all) & easier upgradability.
    • An updated version of jQuery would provide the basis for other "goodies" -both in core UI and for site developers- by "proving" that core is not as... what's the word I'm looking for here? Archaic??
    yoroy’s picture

    @klonos: good energy :) I see you found the filter-related issues, it seems like the best place to start if you want to get some code without limiting the design discussion. Go for it!

    cosmicdreams’s picture

    Awesome, one quick question, because after reading/skimming through all of these comments I'm still not sure:

    Why do we need the "Filter list by module name" drop down?

    Seems to me that we can simply encode the search bar to be intelligent enough to search the listed modules by module name, category, dependencies, status all through javascript-empowered client-side code.

    like this, but better: http://api.jquery.com/

    eigentor’s picture

    StatusFileSize
    new121.04 KB

    Followup to optional categories switch:
    Keeping the categories open for people who want this is an easy one:
    (not beautiful, but gives the idea)

    categories permanent switch

    klonos’s picture

    ...no reason to have the checkbox that permanently keeps open things (categories or the "more search options"). If we implement a "remember state of controls" from last visit, then that feature would take care of it ;)

    RobLoach’s picture

    Issue tags:-mobile, -d8mux
    StatusFileSize
    new143.39 KB

    There is way to much going on here. Let's think of the kittens and get some scope in here by splitting this into a number of different issues. From the design eigentor proposed at #184, it looks like this could technically be split into the following topics:

    1. #1348692: Vertical Tabs for the Modules page
    2. Group modules by Category vs Package
    3. Group modules by Enabled/Disabled
    4. Group newly installed modules
    5. #396478: Searchable modules page
    6. #1296876: Make dependency list hidden on modules page until requested
    7. Update notification on modules page
    8. Toggle the vertical tabs on the modules page
    9. Table sorting by name/enabled on the modules page

    In the attached image, I've numbered each topic according to its design. We should create an issue for each of the previously mentioned.

    Xano’s picture

    Hiding categories would hardly remove clutter, since all it does it make an existing item smaller rather than removing unnecessary items from the interface. I'm not sure about hiding filter options either, since they're one row of elements and they're replace with one row of collapsible fieldset.

    Instead of using checkboxes for filtering by package, we can also use radios. With some custom JavaScript, they would give us exactly the same behavior as tabs. They degrade much gracefuller though. We would also have some extra space height-wise, since all filters would be located in the left column.

    However, before we continue it may be a good idea to decide whether we want to continue using packages or use a more suitable way of categorizing modules. Webchick and I both suggested an alternative. I don't necessarily think we should change this, but if we do want to change it after all, it's not really efficient to be stuck with a new design that was made to use our old-fashioned packages.

    Bojhan’s picture

    @Rob Loach you are thinking too much about the actual implementation, we are just exploring the design here.

    Bojhan’s picture

    Issue summary:View changes

    Updated Issue Summary once more. Added Link to Comment #88

    eigentor’s picture

    Issue summary:View changes

    Updated Issue Summary by entering Sub-Issues

    eigentor’s picture

    Rob has a point. Maybe not all eight issues need starting right now.
    Created #1348692: Vertical Tabs for the Modules page which is about the Tabs and an issue in itself for sure, as we spent most of the recent discussion on it. Not sure about the experience with splitting up issues too much or too little, so the audience decides if that part of the discussion should move over there.

    yoroy’s picture

    StatusFileSize
    new107.53 KB

    I thought a bit about what the simplest useful version of this page could look like for small screens.

    install link, search box, link to 'new' link to 'updates' followed by alphasorted listing

    klonos’s picture

    @Rob Loach, #186:

    It all seems a good starting point to me. Lets elaborate a bit further and break these down to separate issues so we can work on them. The issue you point to for #5 is already ~220 posts long and was initially started back in 2009. I'll go through it and try and get its summary updated. What's everyone's opinion on polishing Instant filter and getting it in D8 core instead?

    @Xano, #187:

    ...since they're one row of elements and they're replace with one row of collapsible fieldset.

    Good point Bart!

    @Bojhan, #188: ...keep exploring the design and pretty soon we'll be renaming the issue to "D9UX: Redesign Modules Page" :/

    @eigentor, #189: Thank you Thomas! Heading there...

    jstoller’s picture

    I think its good to continue with a more holistic discussion of this issue for now, rather than fragment it too much. It doesn't feel like we've reached enough of a consensus on the approach to start breaking this into tasks yet. Exceptions being that everyone seems to want some sort of instant filtering capability (details TBD) and there's broad support for tracking newly installed modules.

    @cosmicdreams: I included the dropdown because I thought there was benefit to letting users explicitly choose between searching on module name, package name, description, or all of the above. I think it would be great if we also implemented filter operators—like greenSkin mentioned in #127—but that's really an advanced user function. The dropdown seems more approachable for beginners.

    @Xano: I totally agree that hiding stuff doesn't seem necessary. Trading one row of filter settings for a collapsible fieldset doesn't seem worth it. The filter settings aren't providing so much visual clutter that they need to be hidden and doing so would hurt functionality. Again, if UX testing shows that the presence of these few checkboxes and radio buttons is preventing users from understanding the module filtering, then we can hide them. Otherwise, lets leave them out in the open.

    I'm against replacing the category tabs with radios. If the radios act like radios, requiring a separate submit button push, then that completely defeats the utility of the tabs. And if they act like tabs, then they should look like tabs.

    I also don't think we should try to stick the filter form in the tab sidebar. For me it works better having it above the tabs. Again, I'm trying to visually segregate functionality to make the page more approachable. The tabs are all about chunking data into smaller collections. The filter form is about further reducing the data within those chunks and it works across all tabs. I'm still standing by the mockup in #180.

    As for graceful degradation, it seems to me that the most graceful way to do it is simply to remove much of the JavaScript dependent functionality if JavaScript isn't present. Maybe all the tabs just go away, leaving an alphabetical listing of modules and a simple filter form at the top. Correct me if I'm wrong, but I expect the user base for doing administrative site-building tasks, without JavaScript enabled, must be infinitesimal.

    webchick’s picture

    Oh plus the heck 1 for #190 and designing for mobile first. That should help a great deal with the rest of the discussion. And I think/hope that makes it clear that adding another 50+ navigation items there per category/package is not going to be a workable solution and will only completely clutter-ify the page for no real gain.

    But in critiquing #190, the basic problem with that is CTools.

    While there is a module called CTools, CTools is an entire package (in the true sense of the word) of modules: Bulk Export, Page Manager, Stylizer, and so on. When I downloaded the module from Drupal.org, I downloaded "CTools". I am not going to know where the heck "Bulk Export" came from in my list, and I certainly won't know it's part of the CTools package unless there is visual grouping somewhere.

    We could solve this by adding > arrow things next to expandable elements, and make that on/off slider default to enabling all sub-modules for a package. But typically you don't really do that. You don't really enable EVERY module that comes with Ubercart, you pick and choose the ones you want. In fact some packages, like FileField in D6, iirc, come with some sort of "edge case" modules for meta-data gathering that require external libraries and the like. You don't want to not be able to install one module in the package because you can't install all modules in the package.

    Make sense?

    Then in terms of dependencies, I've made a case that dependency information should be obliterated from this page over at #1296876: Make dependency list hidden on modules page until requested, because they're only relevant at enable and disable time, and at no other time do you actually care about this info. So -1 to including dependency info in the search, unless there's a valid use case for it.

    klonos’s picture

    @webchick: 190? Really?? Did you perhaps mean 180?

    ...So -1 to including dependency info in the search, unless there's a valid use case for it.

    I can only think the case where one wants to disable a certain module required by a lot others. They then need to first locate all these and disable them before they are actually allowed to finally disable that initial one. If we figure a way to batch-disable modules and their dependencies (first informing the user like we do when enabling modules with dependencies), then yes there is no other use for it - not AFAICT.

    webchick’s picture

    No, #190. Because it filters down the problem to only the real, actual uses of that page.

    And yeah, I would love to fix the inability to disable modules at once. http://drupal.org/project/qamodules used to do it in D6. Moving that into core would be lovely.

    yoroy’s picture

    StatusFileSize
    new1.03 MB

    My .graffle file

    Xano’s picture

    @jstoller in #192:

    I'm against replacing the category tabs with radios. If the radios act like radios, requiring a separate submit button push, then that completely defeats the utility of the tabs. And if they act like tabs, then they should look like tabs.

    In a degraded version (no JS) they would act like classic radio buttons with a submit button. With JS. they would update instantly, just like vertical tabs would. From a technical point, this would make more sense than using vertical tabs where modules need to occur more than once. From a UX perspective I have no evidence what will work best.

    yoroy’s picture

    Webchick, bojhan & yoroy discussed the packaging and filter behavior a bit more.

    Wouldn't it be nice to offer a search through d.o. projects when searching locally yields no results we thought:

    when filtering yields no results for your install, offer a link to search d.o projects with the given search term

    Talked about the packaging thing some more. Some modules are hit singles, some modules are whole albums. Should we just show package contents directly in the list or put those on a seperate, deeper page:

    Within the main list:

    Ctools submodules listed indented within main module listingOn its own page:
    A seperate Ctools page that lists its submodules with a link back to main module list

    graffle file is a mess, start at the last pages.

    greenSkin’s picture

    #198: I'd rather see the page load with everything, no sub-pages, aka the expanded list. The user would toggle these open, but during filtering they should all open so the user can see what the results of the filter are.

    What if we stick with the current implementation of "packages" but throw out "Other". Modules that would normally fall under the "Other" package would only be viewable from the "All" tab. Or in the case of yoroy's wireframes for a mobile view, "Other" modules would mix in with the packages (click to show sub-list) in the main list. Scratch that thought, it would make it that much harder to browse over modules not categorized.

    cosmicdreams’s picture

    @yoroy Awesome work dude!

    I also like the one-page results with fancy in-page filtering via the search box.

    How about we provide descriptions onclick of the module title?

    webchick’s picture

    Love, love, love the stuff at #198. Simple and clear. It's missing the module descriptions and help/perm/settings links, but maybe those sort of "swoosh" down when you click on one of the items in the list (dependency stuff could show up there too I guess, if we really wanted it).

    cosmicdreams’s picture

    @webchick @yoroy:

    I imagine that we'd have jQuery Mobile at our disposal here. So here are some analogs to what we've been talking about:

    Search filtered list with inline categories: http://jquerymobile.com/demos/1.0/docs/lists/lists-search-with-dividers....
    Accordion style sets that start collapsed and expand: http://jquerymobile.com/demos/1.0/docs/content/content-collapsible-set.html

    These accordions that they demo unfortunately don't have much "swoosh".

    webchick’s picture

    Darn. Do they at least have cowbell? :)

    cosmicdreams’s picture

    @webchick, ha. I suppose a question for a future part of this discussion is: Should we adopt jQuery Mobile into core or implement these ideas some other way? Maybe that's a question for John Albin's Mobile initiative?

    klonos’s picture

    Are we talking about implementing something like #190/#198 only when administering an installation from mobile/small-screen devices here, or about implementing it as a global admin UI?

    Xano’s picture

    @yoroy in #198:
    - The second "no results" mockup makes more sense to me. It visually links the search result to the search input.
    - Your idea about nesting modules and using subpages is interesting. Do you suggest we nest modules based on their package or based on the project they belong to? Project information is not shipped with modules. AFAIK the only way Drupal knows about such things is if Update.module contacts drupal.org and retrieves the list of projects.
    - Using Update.module's information, if a search keyword matches a module name, can we link to its project on Drupal.org directly? This would add an extra link to the search results, but it would take users directly to the project page of the module they searched for.

    Xano’s picture

    Issue summary:View changes

    Sub Issues in hopefully correct format

    eigentor’s picture

    The nesting needs to be done by Javascript (collapsing) I guess that is rather sure to keep easy searchability through all modules and submodules and not open new cans of worms with subpages.

    The most important task to fulfil in nesting would be to me:
    How to make it unmistakably clear to the user this is nested, that if he clicks on it a greater selection opens up?
    We have failed in the past with collapsible fieldsets Drupal 6 and earlier and it is still not roses in core and contrib.
    Maybe we should have a close look at modern UI ideas like cosmicdreams listed in #202. Am pretty sure some of the clever UX guys out there have found almost foolproof solutions for that.

    Have added #1296876: Make dependency list hidden on modules page until requested to the issue summary. This issue list may get very long, but if it is for the good, be it :)

    yoroy’s picture

    I'll have to try some mockups for how the expanded view of for a single module in the list might work.

    I sense some disbelief around this simplefied approach to this UI though. Don't be put off by proposals that go counter to what was discussed before. The best way towards a *good* idea is to have *many* ideas. The modules page *will* get a serious overhaul for D8, I'm confident it will. We just need to take our time designing the best possible solution before starting implementation.

    Xano’s picture

    I agree with yoroy. Mobile first doesn't only work well to get things to work on, well, mobile devices, but it also forces you to focus on the key aspects rather than fancy extras (which may be useful, but just not as useful as the key aspects).

    MickL’s picture

    StatusFileSize
    new327.07 KB

    This looks pretty great!

    I added the group-title that was lost on the "All modules" page. Also i removed "new modules" and added "updates". I think this point is very important to have there.

    In addition to that, it could be possible to display the number of items beside to the link.

    mockup

    bleen18’s picture

    #210: Why remove the "new modules" tab? Arguably this is the most useful feature we could add to this page.

    MickL’s picture

    StatusFileSize
    new331.16 KB

    added "New" notifications to modules tabs.

    Only local images are allowed.

    klonos’s picture

    @yoroy, #208 & @Xano, #209: I cannot argue that implementing a UI for mobile first will keep one "restricted" to placing there only the basics and thus will keep the UI to a minimal look & feel. Honestly though, how many of us do routine site administration over their smartphone? Specifically, I cannot imagine real-life use cases where site admins would need (or dare) to manage their sites' modules on their smartphone on a regular basis.

    @benchi, #212: that design does solve the need to be able to spot newly installed modules, but by removing the dedicated tab we had in previous designs for that purpose forces admins to click through multiple tabs in order to enable freshly added modules. With the "New modules" tab we had, one would simply navigate there and perhaps with a "select-all" checkbox would only require a couple of clicks instead.

    cosmicdreams’s picture

    @klonos the need to do site administration via a web enabled device is very real. As someone who has been on call to support deployed websites, often times the call comes when you are least prepared. It would be great to have a UX that helps, instead of of harms, a mobile site admin from fixing the errant module upgrade or resource over utilization, or ...

    Later, when the crisis is over we can then apply the "proper" fix.

    That and in the future a small screen device may be the target UI for the majority of websites might as well prepare for that now. What's the harm in optimizing for mobile?

    For example, I'm still on my thanksgiving vacation and for once I didn't lug my laptop across the county. Typing these comments in has been frustrating because these text areas are annoyingly uncooperative with my mobile device.

    cosmicdreams’s picture

    Personally, The most annoying thing about the modules page is the save button. After I've enabled the module I want turned on, I don't care where I am on the page. I just want a freak'n save button to be on the page, plainly visible. I don't want to scroll. I don't want to press Ctrl+End. I likely had to use the mouse to click the checkbox so I don't want to have to switch devices so I can initiate the action I've queued up.

    Please provide the following:
    1. Allow the save button to be at the very top and the bottom of the left hand side bar.
    2. Make the bottom save button be "smart" so that as the user goes down the page, the save button always stays ont the screen. Like a sticky header.
    3. Remove the save button at the bottom of the page that is inline with the names of modules. This will enforce the expectation that the button will be in the side bar.

    For mobile devices, provide a save button at the top and bottom of the list of modules. This will allow a module that is near the top of the list to be turned on without needing to scroll way down to the bottom in order to execute the action.

    Xano’s picture

    Re #212: let's not confuse available updates with newly uploaded modules.

    jstoller’s picture

    I'm all for designing mobile first, as long as that doesn't mean mobile only. The ability to use a small screen in a pinch is fine, but when it comes to the site building tasks I might do on the modules page, "in a pinch" is the only time I can see myself turning to my smart phone. 99.9% of the time I'm going to want a nice big monitor, and I'd like to take advantage of the added interface enhancements that such screen real estate can provide.

    In any case, I started rethinking this a bit and it took me back to the info files. It seems to me that we are confusing the idea of "categories" with the idea of "packages" and it's making neither work particularly well. So, I'm proposing we add a few things to the info file to rectify this.

    Lets say we have a project called "example", with two modules: example.module and example_ui.module. I'm considering example.module to be the "base module" for this project, because its name matches the name space of the project itself, and I'd suggest making this a requirement for all projects.

    Within the base module's info file, I'm adding some new variables. In addition to project, I'm adding project_name and project_description. This allows the project overall to have a different human-readable name and description than any one of the modules it contains. If either of these variables are missing, the base module's name and/or description variables would be used in its place. In the end, the info file might look something like this:

    ; info file for example.module
    name = Example module
    description = Gives an example of a module.
    core = 8.x
    project = example
    project_name = Example
    project_description = This is a big project that does cool stuff.

    categories[] = Structure
    dependencies[] = views
    dependencies[] = context
    files[] = example.test

    Additional modules in the same project would simply include the project variable to properly associate them, like so:

    ; info file for example_ui.module
    name = Example module
    description = Provides a UI for the Example module.
    core = 8.x
    project = example
    configure = admin/config/content/example

    categories[] = Structure
    categories[] = Content authoring
    dependencies[] = example

    Modules that are intended to extend an existing project—like modules that add new fields, or views displays—would use the package variable. However, package now must refer to the machine name of a project and not an arbitrary string. For instance:

    ; info file for foo_bar.module
    name = Foo bar
    description = Adds functionality to the Example module.
    core = 8.x
    project = foo_bar
    configure = admin/config/content/example
    package = example

    categories[] = Structure
    dependencies[] = example

    You'll notice that I've also added a "categories" array to these info files. While categories would accept arbitrary strings, I propose that we develop a list of generally acceptable categories for developers to use, covering most of the situations one might come across. For inspiration I'd look to the menu structure. Off the top of my head, I'd see something like:

    • Administration
    • Appearance
    • Content authoring
    • Core
    • Development
    • Media
    • Other
    • People
    • Regional and language
    • Structure
    • System
    • Testing and examples
    • User interface
    • Web services
    • Workflow

    Note that we should never have anything like "Views", since that is a package, not a category. If you want to see a list of projects providing views displays, then you should look at the listing for Views. If you want to see a general list of modules that deal with site structure, you can look at the "Structure" category.

    I debated whether to allow multiple categories per module or not. I also debated whether categories should be associated with modules, or projects. I'm still not completely sure about either of these choices.

    So, what would this look like? I went back to my mockups and tried to re-work them, focusing more on projects than individual modules. It's still a little rough, but I ended up with this:

    modules-page_v4.png

    Each project indicates how many of its modules are enabled, as well as the total number of modules it contains. Hovering over any of the rows in this table would bring up a pop-up (see Dashboard above) containing the project's description and links to any admin pages. This way we can keep the descriptions hidden, improving scannability of the page, while still making them immediately available when needed.

    Clicking on any row in the table will expand a collapsed section with more information about the project, like so:

    modules-page_v4-project.png

    The default view in this section shows the project description and all the modules contained in this project, allowing the user to enable and disable them. It also provides links to any projects marked as being in the same package as this project. Dependency information is hidden, but can be exposed for individual modules:

    modules-page_v4-project-dependency.png

    A tab in the project detail then lets you view all possible updates to the project and pick one to install:

    modules-page_v4-project-update.png

    And just for fun, here's a quick mockup of what this all might look like on a mobile device. I've maintained all search options and tabbed views, though accessing them will require an extra tap to open a drop-down. At the bottom I show a project detail page and a module detail page.

    modules-page_v4-mobile.png

    I've attached a zip with the BMML file, for those who want it.

    klonos’s picture

    I'm about to become a dad in 30days or so!!! The Mrs just freaked out this morning (the baby wasn't kicking) and so we went to the clinic for a quick precautionary checkup before going to the market (we started buying baby things this week!! - I'm afraid I'll become the world's silliest dad!). While she & the baby were having a cardiogram, my brother and I were just hanging out in the waiting room (he just came along for the market part, since he is already a dad of two and we needed him for some experience-based shopping advice). After discussing many topics, we came to an agreement that most people seem to confuse "important" with "urgent". One of the topics we discussed was how my girl freaked the nurses out by making them believe she was actually having the baby then. It was amazing how our doctor's advice to "Just go and have a cardiogram just in case ...if it's not any trouble." magically became "Our doctor said it's urgent!!" for the mom! My brother also gave another example of such a case: he gives his personal cell-phone number to valued customers and tells them to call in cases of emergency. After some time of doing that he now has to explain to them that "emergency" means cases such as if a huge asteroid is heading Earth's way. He finishes his hilarious example by saying "Most of the times I also need to further explain: ...even then, don't call me unless I can actually do something about it."...

    ...what I'm trying to say with this rant of mine here is that I'm still not convinced that site admins will actually absolutely *need* to do routine administrative tasks via their handheld/small-screen device. If it's that urgent, I'm sure they'll find a "proper" device. Building Drupal with these cases in mind is far-fetched IMHO, since we can always have some custom minimal handheld-device-targeted admin theme.

    eigentor’s picture

    Created #1353888: D8UX: Improve the position of the 'Save' button on Modules page. inspired by cosmicdreams #215

    Think this is a pretty good spin-off-issue.
    Even if we keep discussion to this issue mainly for now, guess it does not harm to create the sub-issues already. Thanks to the editable issue summary, they can always be updatetd.

    eigentor’s picture

    eigentor’s picture

    Issue summary:View changes

    Added new sub-issue 1353888

    eigentor’s picture

    Re-added Sub-Issue

    eigentor’s picture

    Issue summary:View changes

    Edit sub-issue

    cosmicdreams’s picture

    Thoughts on #217

    I think I've finally pinpointed what I think is wrong about the searching mechanism that has been presented on many of these UX designs. It's not really a search, it's a filter. So if we present text next to the "searchbar" it should be something like: "Find", "Find a module", "filter for", "filter modules for", or something better I think that will both not impede on the site search's namespace and make it more clear to the user what will happen when they start typing in that textbox.

    BTW, I love that the search bar is first and the specifications of the search is immediately second. Most of the time people will use the top of the site's form fields to describe the thing they are looking for. If they cant get that done with one or two terms then they might have the patience to check a box to more clearly state their intent. I think user testing will prove that.

    I like the idea of grouping modules by project, but I don't like the idea of having to click on group to get to the checkbox of a module. Would like to have a checkbox next to each group that when checked marks all the members of the group.

    For mobile and large screen designs, any time we view a set of checkboxes from a group we should provide a "select all" action. That allows the site builder to do the likely intended action with fewer clicks. If we're talking grouping by project, it will become more likely that the admin will want to turn on everything from that project.

    I kind of like the idea of having a kind of favicon for projects. But if we have them it would be better to keep them organized by presenting them in the same vertical line. Float them to the right or something.

    The "Dependencies" link shouldn't take you to another page. A lot of interfaces are designed in such a way that if you go to another page, you end up having to redo every setting you made on the previous form. That will just cause frustration in user testing. Instead have those links open a modal or something.

    jstoller’s picture

    @klonos:
    Congratulations! And I agree.

    @ cosmicdreams:

    It's not really a search, it's a filter.

    I couldn't agree more and my initial mockups said as much, but several people seemed to prefer calling it search, so I tried it that way. I think perhaps we should start by using the accurate terminology and if that doesn't work in UX testing, we can switch back to search.

    I like the idea of grouping modules by project, but I don't like the idea of having to click on group to get to the checkbox of a module. Would like to have a checkbox next to each group that when checked marks all the members of the group.

    I thought about this, but it is problematic. If there is a checkbox next to the project name then most people—or at least most newbies—will likely just check the box and enable all the modules. This is a bad thing. For the majority of projects that include multiple modules, I don't enable all of them. In fact, sometimes doing so would be ill advised. We could include a checkbox just for single-module projects, but that could be clunky.

    I thought about including the module list in the pop-up when you mouse over a project, but that seemed like too much. As an alternative, what if mousing over the module name popped up the project description, as shown, but mousing over the number of enabled modules popped up a list of included modules with checkboxes? That might make things a little faster for experienced users, without confusing newbies too much.

    For mobile and large screen designs, any time we view a set of checkboxes from a group we should provide a "select all" action.

    For the reasons listed above, I'm not so sure this is a good idea. In most cases, I don't think enabling all modules is the "likely intended action".

    I kind of like the idea of having a kind of favicon for projects. But if we have them it would be better to keep them organized by presenting them in the same vertical line. Float them to the right or something.

    My intention was not to provide favicons for all projects. In fact, I think that would hurt the page more than it helps. I was just trying to call a little more attention to core modules. I'm not completely sold on this approach, but I thought it was worth consideration.

    The "Dependencies" link shouldn't take you to another page.

    Agreed. On my big-screen mockup, the link just opens a hidden container. On the small screen, it may look like you've opened a different page, but that doesn't necessarily need to be how its working behind the scenes. Of course, I'd be happy to table the mobile talk for now, for many of the same reasons klonos brought up.

    bleen18’s picture

    Question: There has been a lot of great discussion and some good points brought up... given that we will never have 100% consensus, at what point to we start taking these ideas and start building? What criteria needs to be met?

    klonos’s picture

    @jstoller: Thanx ;)

    ...I believe that the "Select all" checkbox's use is so "controversial" because people immediately associate it with enabling all items. While I agree that selecting *ALL* modules is not that common/advised, still people might find another common use of it. Consider this example:

    One might want to first select ...say all 10 and then deselect the 2 they want to leave out instead of selecting the 8 they want (3 clicks instead of 8). What I'm trying to say is that the "Select all" checkbox is there to help those that require it, as long as it doesn't bother the ones that don't ;)

    LewisNyman’s picture

    Issue tags:+mobile, +d8mux

    Adding mobile tags.

    klonos’s picture

    I honestly think that we should leave mobile out and move it to its own meta-issue. It only holds back this for D8 and as I've already said back in #191 you'll be changing that tag to "d9mux" before you know it. Developing websites & theming them on small-screen is simply crazy. Supporting small-screen as visitor devices is a completely different thing and can be solved by using a dedicated theme for that purpose along with Mobile tools/Browscap/Wurfl and Switchtheme.

    LewisNyman’s picture

    One of the benefits of thinking from a "Mobile First" mindset is it narrows the focus of the page. Instead of adding more and more UI elements we should start from the ground up and work out what the single main purpose of this page is. Drupal has always been guilty of trying to serve too many purposes at once and many pages in the UI reflect that.

    As for mobile being unimportant or irrelevant, that's just misinformation. It's not hard to find supporting data these days.

    MickL’s picture

    what about #222 ?

    klonos’s picture

    ...we should start from the ground up and work out what the single main purpose of this page is.

    Nobody minds working out the "main" purpose (enabling & disabling modules) - it is the "single" being suggested that bothers most. What is proposed here by most of those that brought up the mobile UI issue is not to simply redesign with the main purpose of the Modules page in mind - it instead feels as if you are proposing for it to become the *only* purpose of the page. At this point let me stress that "minimal" doesn't necessarily mean "mobile". It is simply that the later has no other option but to be minimal. Don't confuse the two or suggest that they either are or should be the same.

    We all understand that having so many things happening in this page is a complete mess as is right now. That's why we started this issue here in the first place - we aim to improve it. Along the way, some people instead of helping to tidy the page seem to have started proposing we should be "ditching" features instead and start "going mobile". The addition of "more and more UI elements" was not done for the fun of it - they are added as needed in order to help users achieve certain tasks. Removing them doesn't help the users in that end - it only ignores their problem in favor of "minimal". I personally don't mind keeping the "minimal" in mind as we go, but fixating on it absolutely bothers me to a point that I start seeing mobile UI suggestions in this issue as hijacking & I urge people to file a separate issue for that.

    From what I've read so far in the two articles linked in #226:

    1. "We have dug ourselves a hole": ...there seems to be concern that we are "left so far behind" in providing a mobile admin UI. Left behind compared to what? Do Joomla or WordPress for example currently provide that support? Any other of the competing CMSs out there perhaps? Even if there is one that does (I seriously doubt it, but please do point me to a screenshot/mockup to prove me wrong), still a "nice to have" feature is far from "necessary" or "the way to go".

    2. "We can't afford to ignore mobile": ...There seems to be concern that users are starting to use mobile devices more and there is a considerable amount of them that start using mobile *only*. That does not in any way prove that this audience is designing and/or administering websites. There is this quote:

    Photographers have a saying: "The best camera is the one you have with you when something worth photographing happens." This will often be a pocket camera or a phone camera; people typically carry professional-grade cameras only when they plan to shoot photos.

    Similarly, the best computer is the one you have with you when you want something done.

    ...used to make a point. Fine! Try saying that to a graphics designer and make them work on iPhone. Oranges & apples I say.

    I won't start a flame war over the 80/20 rule of using the admin UI in handheld/small-screen or "normal" devices without first having any *actual* usage stats. Here's a suggestion though: ...why not start a minimal, mobile-intended, admin-focused contrib theme coupled with a nice, also mobile-focused toolbar, give them enough time (we do have a long way till D8) and at some point see how these compare to module_filter's usage stats?? That would be a nice way to get some feedback on people's preference: a slick/basic admin UI or a full-fledged one. Don't you agree? Starting a separate issue for redesigning the Modules page for mobile devices and checking how many followers are there compared to this one here would also serve the same purpose fine.

    webchick’s picture

    The reason I like approaching this from a mobile POV isn't really related to how many people do or do not browse their Drupal admin pages with a mobile device, but more the fact that the reason this page needs redesigning is because right now it's totally crazy and does way too much. Narrowing our focus to "Well, what would a mobile interface look like?" is a really useful exercise, since it forces us to think through "What is the bare minimum you actually need on this page for it to be useful?" I love the idea of starting from there, and then figuring out what extra doo-dads we could put on the "big screen" version to streamline things for folks on desktops.

    yoroy’s picture

    Mobile versions are *not* seperate issues. What I'm seeing is that many of the proposals so far have been *adding* options and sections and ui patterns to the page in order to capture all the current complexity going on on this page. But adding stuff should never be the first option for solving a design problem. First you start looking for ways to remove, reorder or rephrase parts of the UI to see if that can solve things: "No matter how cool your interface, it would be better if there were less of it."

    If we cater for the current situation, the madness will only increase because we will have provided more wiggle room for contrib to pile on even more categories, packages and whatnot. We will have fixed symptoms only.

    Instead of argueing about mobile or not, it would be much more constructive to critique the minimal proposals and point out which (primary or secondary) functionality is *missing* that it won't let you enable, disable or configure modules.

    @bleen18 You ask the best question :) The way I see it we should aim to first strip away some of the apparent noise from the ui. We can then evaluate if we can simplefy further or need to bring back some info or tool to help people find their way around this page. Which is not a definitive answer I know, we'll have to discuss that a bit more. It would definately help to get agreement on the main scenarios, maybe write up some user stories that we want to verify design changes against.

    Xano’s picture

    The core issue remains: how do we display the long list of modules? For that we need to know the exact data to display.

    • Stuff that probably needs to be visible at all times:
      • title
      • method to enable particular module
      • update availability
    • Stuff we may hide by default:
      • description
      • version
      • link to help
      • link to configuration page
      • link to permissions
    • Stuff we don't want any longer:
      • dependencies
      • dependants

    (feel free to suggest changes for this list)

    That's all there is on the current modules page, except for the packages. I think everybody agrees packages are what we'd been discussing about the most here. Yet, we still don't know whether we want to keep them or want to throw them away, and possibly replace them with another way of showing relationships between modules. Since they make up a fair amount of the visible page, I think it's fair to say this is one of the most important things to figure out.

    droplet’s picture

    Issue tags:+mobile, +d8mux

    Important for everyone:

    • Modules Name
    • Machine Name (for Drush user)
    • Version (if we show the update status, it's less important
    • Enable status

    Important for everyone first time use that modules package:

    • description
    • link to configuration page

    also Important for newbie:

    • link to configuration page

    I think it also need the "Recently Added / Enabled / Disabled (recently activities)" filter

    jenlampton’s picture

    Issue summary:View changes

    Update sub-issue

    jenlampton’s picture

    I'm not sure anyone actually views which modules are required to enable, disable or uninstall a specific module. I think the workflow pattern is: 1) try, 2) fail, 3) find out why. I think if we moved the information off the page, no one would miss it as long as it were to appear on step 3. (more at #1296876: Make dependency list hidden on modules page until requested)

    I have never seen someone land on the module page without knowing the name or description of the functionality they want to enable. Does this use case exist?

    Core modules are usually what people are looking for least often, having them at the top of the list sometimes feels intrusive.

    From my experience, most "site builders" know either the module name, or the d.o project name, and currently do a search in the text to find their module. If possible, we should provide a page that can support this existing workflow (so we have at least one view where a command-f will find any module). I also think it would be useful to add the d.o project name, somehow, to this page as well (even if it's just a search criteria).

    Most new Drupal users read the names and descriptions to locate a module (after failing to find usefulness from the groupings, but see more on groupings at #1355292: Come up with better alternatives for groupings on the modules page). If someone doesn't know exactly what they are looking for, we should have a view make sure descriptions can still be found.

    cosmicdreams’s picture

    I mostly agree with #233 and #231 and I completely agree with #232.

    If all the module page had was an intelligent filter and the ability to call out the machine names a module has packaged up I'd be eternally grateful for D8.

    Listing the dependencies really screws up the modules page. I can't even use a Ctrl+F to find the module by name at that point. I'd be glad to be rid of them.

    #1296876: Make dependency list hidden on modules page until requested will rock

    Also, I agree that while we may not of 100% consensus on all of the issues here. I think we have enough consensus on the tasks listed in this issue's description (minus the whole packaging issue) to get started with productive work. May we be allowed to move this meta issue forward?

    webchick’s picture

    webchick’s picture

    Issue summary:View changes

    Add a new sub-issue

    cafuego’s picture

    StatusFileSize
    new76.74 KB
    new11.33 KB

    I've done a quick hack on my D8 to allow the modules to be ordered by modification time and grouped by interval. Screenshot attached. The change required to common.inc is minimal, but I've implemented the new list as a separate menu tab (in this patch).

    Intervals are 'today', 'yesterday', 'this week', 'more than a week ago'.

    greenSkin’s picture

    I disagree with removing the list of dependencies. I'm fine with hiding them except to show missing dependents. I know it is definitely a use case to be able to see what modules a module depends on. The only other way to determine this would be to open the module's info file.

    webchick’s picture

    Hm. What is the use case exactly, for viewing the dependency list of a module at any time?

    When I enable a module with dependencies, I get an interstitial screen that tells me "The following modules are required; foo, bar, baz" and the opportunity to turn them on at the same time. I click "OK" and I'm done. Never need to care about those dependencies again.

    When I try and disable a module, that doesn't currently happen because we disable checkboxes of modules with enabled dependencies. But it totally could. And if that happened, the same thing would occur if I tried to disable a module.

    Other than those two instances—enabling and disabling a module—when else do I care about dependencies?

    greenSkin’s picture

    @webchick: Other than the two instances—enabling and disabling a module—when else do I care to visit the modules page. :)

    webchick’s picture

    Well, for starters:

    1) You inherit a site and want to view what it's running. You visit the modules page to do some basic investigation.
    2) You just enabled a bunch of mondules and want to configure them. The modules page has a handy "Configure" and "Permissions" links for you.
    3) The site's having a problem, you view the modules page to see what's running to try and deduce where it's coming from.
    4) You want to configure module X and can't remember where it lives in the IA. The modules page has a handy "Configure" and "Permissions" links for you.

    But even when you go to the page to enable/disable a module, you are looking for a specific module(s) in the list. All of the dependency info from every other module you do not care about is just adding visual noise/clutter to your current task before you.

    designerbrent’s picture

    If I inherit a site and go to the modules page, I want to know why each module is there. I have had times where it is not clear why a module is there. If the dependency list is gone, there would be no telling why a certain module is installed.

    I would say the list should stay!

    eigentor’s picture

    1 more:
    5) You don't know the first thing about Drupal. You stumble upon the modules page and are amazed of the wonders of extensibility.

    Let's not forget this one.

    eigentor’s picture

    Issue summary:View changes

    Adding link to #1355358

    jstoller’s picture

    Is there anybody who is suggesting that the dependency list actually go away completely? It is my understanding that we're just talking about hiding the dependency list, to improve overall page scannability, while providing some way for users to call up that list for any given module as needed. Does anyone disagree with this approach? If not, then in order to avoid further confusion, perhaps we should stop talking about removing the dependency list and instead talk about hiding the dependency list.

    If I'm understanding this correctly, then I'm 100% behind it. I am often annoyed by the dependency lists. Yes, there are plenty of times when I want to see dependencies when looking at the modules page—often to determine why a module is there and whether or not I can get rid of it—but I've never had the desire to see all dependencies at a glance. As long as there is some mechanism whereby I can click once or twice and see the dependencies for the module in question, I'm a happy site builder. Stipulating, of course, that these clicks don't require a page load that would loose the current state of the form, as I may have already enabled/disabled some modules, but not yet be ready to submit.

    @jenlampton:

    I have never seen someone land on the module page without knowing the name or description of the functionality they want to enable. Does this use case exist?

    I do that all the time. For one, there are many modules with names that don't describe what they do, or at least not in a way that makes sense to everyone (I mean, what's a "View", or a "Bean"). And it doesn't help that my memory is like that cheese with all the holes in it, so I often can't remember exactly which modules I installed in the more experimental phases of my site development. I go to the modules page just so I can get a sense of what's happening with a site. Maybe I inherited a site and I'm trying to figure it out, or maybe its my own site and I'm checking to see what state it's in.

    I've grown to love the Module Filter module more for its tabs than for its search function (though I use that as well). The way it chunks information improves the quality of my life. Often I just want to see all the Views-related modules I have installed, or all the field modules, and I'm not looking for a specific name. And yes, there are plenty of times I want to look at all the Core modules. Usually so I can make sure there's nothing enabled that I don't really need. And if I want to find the Book module, clicking the Core tab and finding it in the list is faster than typing "book" in a search field and WAY faster than looking through an unfiltered list.

    jstoller’s picture

    Here are some of the user stories I think this page needs to address:

    1. I've installed a lot of modules during site development and I'd like to see which projects are not being used, so I can clean out my modules directory. (I'll need to know the file name of these projects.)
    2. I'm optimizing my site and I want to see which Core modules I have enabled.
    3. I know I've installed several modules to deal with media management on my site and I'd like to take a look at them all in one place.
    4. I want to take a quick look at the assortment of Views (or Field, or Filter, or Context, etc...) related modules I have on my site.
    5. I just installed some new modules and want to enable them.
    6. I need to enable/disable/update module X.
    7. I'm thinking about enabling module X and I want to see what other modules it requires.
    8. I'm not sure what I'm using module X for and I want to see if there are other modules I'm using that require it.
    9. I'm not sure what module X does and I'd like to read a description.
    10. I need to disable multiple modules, including some that are dependancies and I want to do it all in one form submission.

    And here are some of the functional requirements these stories imply:

    1. Modules need to be enabled individually, but project associations should be explicit. Module names cannot be counted on for this (i.e. Bulk Export is part of Chaos Tools).
    2. There should be a quick way to filter the module list by name and other meta-data.
    3. There should be a quick way to see a group of modules/projects that belong to a specific functional set, like Views, Fields and Input Filters. These are cases where the base functionality of one module is extended by other projects.
    4. There should be a quick way to see a group of modules/projects that belong to the same conceptual category, like all Core modules, or all administrative modules, or all modules dealing with media management.
    5. Module dependencies need not be displayed by default, but should be accessible on a module-by-module basis when needed.
    6. Module descriptions need not be displayed by default, but should be quickly accessible on a module-by-module basis when needed. Same with project descriptions, if implemented.
    7. When enabling/disabling modules, dependencies should be handled automatically, without the need for multiple form submissions.
    8. Accessing hidden module information should not require a page load, so the current form state is preserved when enabling/disabling modules.
    9. There should be a quick way to see a list of modules that have recently been installed.
    jenlampton’s picture

    ...I go to the modules page just so I can get a sense of what's happening with a site. Maybe I inherited a site and I'm trying to figure it out, or maybe its my own site and I'm checking to see what state it's in.

    But in that case you won't be *searching* the page for a specific module, in the use-case described you will actually want a list of all the modules. I was asking about if you come to the modules page for the purpose of turning a mondue on or off... Don't you always know *either* what it's called *or* what it does (what might be in it's description).

    I'm pretty sure that if someone is going to enable (or disable) a module they will know either what it's called, or what it does. If they don't, then they probably want the whole list anyway :)

    jstoller’s picture

    But in that case you won't be *searching* the page for a specific module, in the use-case described you will actually want a list of all the modules.

    The list of all modules scares me. It's too overwhelming to look at. I like my module list in smaller, bite-sized chunks—alla the Module Filter tabs—and I'd like to see that sort of functionality improved. Chunking the data for easier digestion.

    ...if you come to the modules page for the purpose of turning a module on or off... Don't you always know *either* what it's called *or* what it does (what might be in it's description).

    Many times I'm coming there to see what modules I can turn off, and I don't have something specific in mind. I just want to look at the Core modules and see if there's anything I don't really need enabled anymore. Or I want to look at the Field modules to see if there were some that I had enabled earlier in development, but ultimately didn't need. I think that qualifies.

    jenlampton’s picture

    @jstoller, #244 is *super* helpful :) I'd like to address some of the functional requirements these stories imply, to track our progress on each issue.

    Modules need to be enabled individually, but project associations should be explicit. Module names cannot be counted on for this (i.e. Bulk Export is part of Chaos Tools).

    This could potentially be solved by listing the modules by project, as #1355292: Come up with better alternatives for groupings on the modules page

    There should be a quick way to filter the module list by name and other meta-data.

    Working on that one in #396478: Searchable modules page

    There should be a quick way to see a group of modules/projects that belong to a specific functional set, like Views, Fields and Input Filters. These are cases where the base functionality of one module is extended by other projects.

    This may be solved in the way we handle dependanices (as mentioned in #1355292: Come up with better alternatives for groupings on the modules page)

    There should be a quick way to see a group of modules/projects that belong to the same conceptual category, like all Core modules, or all administrative modules, or all modules dealing with media management.

    This is what *some* maintainers were trying to turn "packages" into. I'm not sure we have a good way of defining or allowing modules to define these "categories" but if this turns out to be necessary, perhaps the issue can also be solved using dependancies.

    Module dependencies need not be displayed by default, but should be accessible on a module-by-module basis when needed.

    Being worked on in #1296876: Make dependency list hidden on modules page until requested

    Module descriptions need not be displayed by default, but should be quickly accessible on a module-by-module basis when needed. Same with project descriptions, if implemented.

    I'm not sure about this one. I think maybe they can still be shown by default, at least for web users. I'd agree to hiding them for mobile devices, but I think the descriptions are important for first-time drupal users. They don't even know what "modules" are yet, let's give them some help with "beans" :)

    When enabling/disabling modules, dependencies should be handled automatically, without the need for multiple form submissions.

    +1 for this, I had not been thinking about it, but it is really frustrating. It looks like there is also an issue for this, #468208: Allow uninstalling modules with dependents by offering to recursively uninstall their dependents as well.

    Accessing hidden module information should not require a page load, so the current form state is preserved when enabling/disabling modules.

    Agree completely. There's some interesting work going on over here on a new UI pattern we can maybe use: #492834: Hover operations for flooded state screens

    There should be a quick way to see a list of modules that have recently been installed.

    We've been talking about this in this issue, and I think it's a great idea. I just created a sub-issue for it over here: #1355526: Add a way to determine the date a module was added so the modules page can use it for sort

    jenlampton’s picture

    Issue summary:View changes

    added another sub-issue

    LewisNyman’s picture

    So when I was prototyping the mobile navigation I came to the conclusion that there should be common action links that operate on every list we have with in Drupal. Modal forms could pop up and filter or sort a list like modules similar to what we have on the content page. I've already come up with a prototype for how action links could display on mobile, we simply move the action links into the toolbar.

    The sort function can cover some of the use cases outlined in #244. For example; only make the package headings appear if someone chooses to sort by package. The default sort could be how recently it was added! Brilliant!

    I also think we should have module sub-pages that display all the information you could possibly want from a module like the machine name and dependencies. We only need to show enough for the user to identify the correct module they want to take action on.

    Luckily I already have a rough mobile prototype of this kind of page: http://nav.d8mux.org/modules.d8mux.html

    timmillwood’s picture

    I have not been following this through from the start but just had a quick scan and thought I would add my 2¢. Please feel free to ignore.

    I think the vertical tabs will make it harder to find things not easier. No one will know, realise or remember which module is under which tab. A lot of people will click through each tab until they find the module they want.

    I like the idea of having filters and search, I also like the idea of organising the modules by new, enabled and disabled.

    yoroy’s picture

    Bleen18 asked an important question in #222:

    There has been a lot of great discussion and some good points brought up... given that we will never have 100% consensus, at what point to we start taking these ideas and start building? What criteria needs to be met?

    We discussed this a bit during UX open hours yesterday. Here's what we (dcmistry, bojhan, yoroy, jenlampton) came up with:

    1. A first stab at a prioritized task list for the modules page
    2. We will verify those assumptions with some interviews
    3. We can use this list to find the best ideas for the most important tasks in all the mockups that have been posted.

    ### A prioritized list of tasks to complete on the modules page

    1. Find a module.
    2. Enable / Disable module
    3. Use description to orientate what the module is about
    4. Change the permissions / configurations of a module
    5. View available updates
    6. View current module versions
    7. View which modules are required to be able to enable, disable or uninstall a module

    ### The interviews

    Dharmesh agreed to write up interview questions. Dharmesh and bojhan will conduct some interviews. The more the merrier, leave a comment here if you want to help us getting a clearer picture of how people think of things to do on the module page.

    ### Use the task list + interview insights to find the best ideas in the mockups

    The prioritized tasks will help us get a clearer picture on which ideas supports which task the best. From there we should be able to cherry-pick our way towards a design we implement and then test. This will take several iterations.

    #244 does something similar, lets compare notes :)

    I want to thank everybody involved in this discussion so far. The thread is becoming huge but I don't see too much of a problem with that, we're spinning off actionable issues (links in the issue summary above) and it makes sense to keep all brainstorming ideas happening here.

    yoroy’s picture

    Issue summary:View changes

    Added more sub-issues

    tvn’s picture

    I've updated issue summary to incorporate latest comments and results of UX open hours discussion.

    Sutharsan’s picture

    @yoroy I can do interviews. Can this it be done by phone? I can do interviews with people with a wide range of Drupal experience.

    klonos’s picture

    @timmillwood, #249:

    I think the vertical tabs will make it harder to find things not easier.

    Funny thing... more than 14,000 users (including myself) of module_filter that adds vertical tabs think otherwise. Did you actually give it a try? ;)

    No one will know, realise or remember which module is under which tab.

    ...not no one. I agree that not for every single module, but for most of them I at least do. When unclear, the "Other" category/tab is usually a nice shot ;)

    A lot of people will click through each tab until they find the module they want.

    For starters, that's why we've been talking about having a "All modules" tab. That will satisfy these users that like the old way of having the whole list of modules out there in bulk. This tab will be the default when one visits the Modules page & the "Clear/Reset all filters" link/button is there to simply take users back to this "All modules" tab. (Of course all this can be optional or remembered across sessions).

    dcmistry’s picture

    Hi @Sutharsan,

    That is awesome. Yes, this can be done on the phone/skype/etc. I am going to send out a draft of the questions for the interview for everyone to review here soon. We will make sure we keep you in the loop.

    This is neat stuff. Thank you for doing this!

    webchick’s picture

    klonos: For me, Module Filter is great for the search box aspect of it, but not the vertical tabs. Don't assume all 14K of those users like everything Module Filter has to offer. :) The "click through each tab until they find what they want" behaviour is something we've observed countless times in multiple usability tests in multiple locations. It's a real problem for new users.

    And expert users know the module name they're looking for anyway, so they just type it, and don't use the categories. When was the last time you browsed for modules via going to http://drupal.org/download, then Modules, then filtered by category, then read down the list until you find what you're looking for? No, you'll either just go to http://drupal.org/project/[name], or search Google for "site:drupal.org [use case] module."

    So +100 for the keyword search that Module Filter offers, since that closely matches the problem-solving pattern of both new and expert users. But -1 to mis-using a UI pattern to emphasize something known to be confusing and useless for most people.

    jstoller’s picture

    @yoroy, re: #250:
    Your list of module page tasks seems overly focused on finding A module and enabling/disabling A module. These are highly directed tasks, but I can't emphasize enough how valuable this page is when undertaking a less directed exploration of the current state of a Drupal installation. This exploration may then lead to enabling/disabling modules, but the task of gaining an overview of how the site is constructed should place as #3 in your task list. I would reorder your list like so...

    1. Find a module
    2. Enable / Disable modules
    3. Explore overall site construction
    4. Determine what a module does
    5. View current module versions
    6. View project/file names
    7. View available updates for a module
    8. Update modules
    9. Change the permissions / configurations of a module
    10. View dependency information for a module
    jstoller’s picture

    If you know what you're looking for, then of course the full list of modules with a search box is the way to go. However, if you don't know exactly what you're looking for, then the grouping provided by category tabs can be incredibly valuable. And we shouldn't talk about clicking through multiple tabs like it's always a bad thing.

    To me, it's all in the implementation. The current implementation of "packages" leaves much to be desired, but could be improved. I think there should be a visual/spacial separation of the category navigation from other more direct search methods, so I wouldn't want a direct implementation of what's in Module Filter. There are solid use cases where this sort of capability is highly desirable. Ultimately, if well implemented, I think it would make for a greatly improved user experience.

    klonos’s picture

    @webchick, #255: why not use instantfilter instead that does the filtering part only? (that one counts less then 100 installations). But then again, I'm sure you'll argue that not all 14k users of module_filter knew that instantfilter even exists (take you for example) and then how am I supposed to argue over that one :p

    edit: here's how: #1356426: Clarify in the project's page that people not fond of the vertical tabs should use instantfilter instead.

    webchick’s picture

    klonos: Of course I know instantfilter exists. :) It came directly out of work on D7 to solve this very problem. But it's D7-only, doesn't have a stable release yet, and the maintainer isn't quite as active, so I imagine that's why more people use module_filter instead. Anyway, this is getting totally off-topic.

    jstoller: So you're after a means of "exploring" modules on a site you're unfamiliar with, and also a means of visually breaking up a huge list with 100+ things in it. That makes sense.

    I still am not sure though that arbitrary and mis-matched categories that were chosen by module developers in the ether, rather than hand-selected by the people who built a particular Drupal site to explain to fellow future site builders how those modules fit into the context of their specific implementation, helps with that. It's not purely about the fact that you have to click, read, nope, click, read, nope, click... It's more the fact that the categories to choose from are completely inconsistent across Drupal sites and purely depend on what modules you have downloaded, and they're also completely inconsistent across modules themselves, with some admin-related modules choosing "Administration" as their package, others "Views", and others "Other". This doesn't help with exploration, beyond exploring the vast and varied opinions of Drupal developers everywhere about module taxonomy. :)

    To me, I would handle the exploring bit with tighter integration with Drupal.org. Take a look at the demo for http://drupal.org/project/project_browser. Now imagine that browser had the capability to tell you that such and such a module you found was already installed on your site, and had links to jump directly to its configuration page? This would mean you have one "flow" for doing exploring for a module to solve a use case, and either it's already there, in which case you configure it, or it's not and you download/install it. And at either point, you're back to dealing with module names again.

    droplet’s picture

    StatusFileSize
    new265.73 KB

    Yeah, modules filter is simple enough for most actions. Comment #217 wireframe needed more CLICKS to do a simple action.

    here my thoughts base on modules filters:

    modules page
    (Requires / Required by will be removed)

    klonos’s picture

    Fine! (actually not - but anyways...)

    Whether a project on d.o has a "stable" release is purely a matter of maintainer policy (marketing trick if you ask me). To support that: instantfilter has 0 bugs and only 5 feature requests or tasks and still its maintainer chose to call its stable "beta2", while module_filter has 14 open bugs (and a total of 33 issues) and still has a "stable" release. So how stable(er) module_filter is or not when compared to instantfilter is not such an easy thing to conclude to. As is not a maintainer's activity - especially when their project has 0 bugs/criticals to be solved.

    The only thing that I'm trying to prove by insisting in vtabs is that I for one find it useful. I even like the fact that we have a working & popular solution in contrib right now to start with. So, I cannot leave some people's negative comments simply go by like that. You cannot simply say "I don't like it.", "It's not useful.", "It's the wrong way to use vtabs like so" without any actual data to support these claims (the 2nd & 3rd I mean - not the dislike part). On top of that when I try to support my claim & present some decent/legitimate proof, you persistently dispute it. So I research a bit more and think that you might be right about it. I say "Fair enough. Lets test it..." and instead of a "Fair enough. Let's see..." I get a "You're off topic!".

    Well, since I'm off-topic here let me say that I was under the impression that we were discussing vtabs - I wasn't aware that we've decided to not implement them. I know what! Lets discuss mobile!! ...since that makes more sense.

    Let me also take the opportunity to say that his whole thing reminds me how the "idea" of the Overlay got in core (because *most* users liked it and found it useful) and then strangely how I systematically find myself disabling it in every single installation - same with the Toolbar instead of admin_menu. I honestly cannot recall a single screencast or DrupalCon video where I saw Toolbar and Overlay left enabled. All cases of useless things not done the proper way in contrib - so we re-invented things for core instead.

    I know I'm a newbie and I cannot put code where my mouth is, but trying to convince the "core Gods" to at the very least try and find a way to actually get some sort of feedback before they implement what they "think" the users like is as hard as trying to make them understand and try to keep in mind that I too am one of these users.

    PS: ...and judging by how easily I "got off-topic" because of insisting in speaking my mind, I should next expect to also be told off now because I'm adding "noise" :/

    webchick’s picture

    Well, er, in an issue talking about redesigning the modules page, talking instead about my perceived knowledge or lack thereof of available contributed modules, or about the usefulness toolbar and overlay..? I'm not sure what else to call it than off-topic. :)

    But back on-topic, my comments/observations come from various usability studies done on Drupal, several years' experience teaching Drupal to new site builders and developers, feedback from readers on a Drupal book I wrote aimed at newcomers, training clients new to Drupal on how to use their sites, and just general intuition gleaned from reading books recommended by and working closely with the usability team during the D7 release. That's not to toot my own horn or anything, just explaining where I'm coming from. Others in this thread, such as dcmistry, yoroy, and Bojhan, have much deeper direct usability expertise, and folks such as jenlampton also teach new Drupal users way more often than I do, but all have a lot of additional "in the field" experience in terms of their reactions to various designs.

    But I'm all about dcmistry's efforts to get a script together so we can "crowd source" usability testing and start seeing some actual data in these threads rather than opinions. But to do that, we need to keep the discussion constructive. So let's get back to discussing mockups, hm? :)

    droplet’s picture

    StatusFileSize
    new71.4 KB

    more about #260, vtabs pattern is a bit close to Windows Vista / 7 start menu, also the Windows 8
    It has a default list, when perform search, it filtered out some apps & cats.

    I think order with Tags / Terms is useless and make things harder. You only care about what under Commerce modules when you use it. It doesn't like Modules Search in drupal.org, we don't want to see E-commerce modules in our filtering.

    jenlampton’s picture

    StatusFileSize
    new128.45 KB

    @klonos: Have you considered that maybe 14,000 people might actually hate the vertical tabs added by module_filter, but use it anyway because of it's search box? *ahem*speaking for herself*ahem* Plus, we do have an issue now for debating the use of vertical tabs: #1348692: Vertical Tabs for the Modules page so maybe all the vertical tabs talk should be moved over there ;)

    I'm also super excited about interviews and testing. I'd be glad to volunteer all the chapter three developers (sorry guys) as a pool of seasoned Drupal users, and maybe I can also get a classroom of students to help out as a pool of Drupal newcomers. This will be fun :)

    As for discussing mockups, I'd like to take it back a few steps. I think all the checkboxes, vertical tabs, bells, and whistles, may be overcomplicating the task at hand. I added a few of the things from our sub-issues into D8, and look how much better it looks already! :)

    I'm in favor of removing (or hiding) more things than we add, since the page is already overwhelming. Too many options in search/filters will make the ones we do provide less effective. Do we really need checkboxes for things like "unavailable" ? Less is more :) .02

    webchick’s picture

    Wow! LOVE. IT. <3 This indeed feels like it's headed in the right direction.

    Xano’s picture

    @#264: It feels way better, though it definitely needs to be tested with ungodly long lists. I imagine such lists will still slap you in the face when you see them.

    This takes @jenlampton's approach and takes it a little bit further:
    - descriptions are now spread out across multiple columns and are just like form descriptions: slightly smaller and grey.
    - Dependencies and dependents are now located under "more information", which simple is not there if there is no extra information to show.

    This is just based on personal feelings, but I wanted to share it so it can either be shot down or be used in future, more serious mockups.

    timmillwood’s picture

    I think the idea of having a new flag would be great, some way of showing the modules that have never been enabled before, because more often than not, these are the modules you want to enable.

    bleen18’s picture

    #267: I definitely dont agree that "new" should be defined as "never enabled before." By this definition, the "book" module would be "new" forever on most sites (sorry book module). To use an example from contrib, that means that "stylizer" would be "new" for every site that just downloaded ctools because they want to use views.

    "New" needs to be temporal ...

    While we're talking about "new" ... I'm going to tread lightly here because of everyone's feelings about vertical tabs, but one of the most exciting things (to me) introduced all the way back in #175 (and later refined) was the idea of tabs for "All Modules", "New Modules", "Installed Modules" & "Updates needed". #264 & #266 are without a doubt, cleaner & betterer than what we currently have, but this page could be so much more useful with these non-name-based filters.

    bleen18’s picture

    Issue summary:View changes

    Summary update to reflect current plans and discussed lists of tasks and requirements

    Bojhan’s picture

    Updated issue summary.

    Bojhan’s picture

    Issue summary:View changes

    first cleanup of summary

    Bojhan’s picture

    Updated issue summary.

    Bojhan’s picture

    Issue summary:View changes

    second cleanup

    Bojhan’s picture

    Issue summary:View changes

    third cleanup

    Bojhan’s picture

    Issue summary:View changes

    Updated issue summary.

    Bojhan’s picture

    Issue summary:View changes

    more cleanups

    Bojhan’s picture

    Issue summary:View changes

    ok text is now sexy clean

    Bojhan’s picture

    I have updated the summary to be more clean, and focus on what we agree upon and what we still have discussion over.

    jenlampton’s picture

    @timmillwood and @bleen18
    I created a new issue for "new" at #1355526: Add a way to determine the date a module was added so the modules page can use it for sort and agree we need it. I just didn't know how to represent it in the UI yet so I didn't build it into my example. :)

    @xano
    I love the new description location + style. I wonder about more / less information though. I'd like to use that text to tell people what kind of information is inside the accordian rather than leaving it so generic. How about "See dependancies" or "View requirements". I also think an indication of weather the modules are disabled (dim red) or missing (bright red) without having to expand the accordion is important and I wouldn't want to loose that.

    Suggestions for language and use of current colors?

    jenlampton’s picture

    @Taxoman brought up a good point in #1296876: Make dependency list hidden on modules page until requested that we mentioned here earlier, but I wanted to bring it back up for discussion.

    Should we build different pages for different user types rather than focusing on trying to improve this one display to make it work for everyone? We obviously need to improve the page we already have (and we are), but what about adding other pages? Is this something we should consider doing in core, or should we leave it to contrib to alter this page, or add other pages?

    jenlampton’s picture

    Issue summary:View changes

    ok, stronger now

    Taxoman’s picture

    jstoller’s picture

    @webchick:
    I completely agree that the current implementation of "packages" is totally arbitrary and not nearly as useful as it should be. I just disagree that the solution is to abandon any attempt to classify modules. I think that this can be handled much more effectively by: 1) separating what project your module extends from what conceptual categories it belongs to; 2) actually documenting a standard list of categories for module developers to use; and 3) allowing one module to be listed under multiple categories and extend multiple other modules. Lets not throw out a potentially useful tool because the current implementation is sub par. More on my thinking in this regard at #1355292: Come up with better alternatives for groupings on the modules page.

    And I looked at Project Browser—which is awesome—but I see that as a useful tool for exploring new modules. I don't think it would help me in exploring the state of the site I'm working on.

    @Bojhan:
    I still strongly feel that something along the lines of "Explore overall site construction" should be listed in your prioritized task list. See #256. I still peg it at #3 in the list.

    @jenlampton:
    I vote no for the additional pages. I think they'll just confuse things even more. I'd rather concentrate on finding ways that this page can successfully support multiple modalities. And of course, laying the ground work so contrib has what it needs to modify things further for those who wish it.

    Taxoman’s picture

    #273: when we talk about "pages", are some people thinking "urls" and some others different sections on the same url, "hidden" by for example vertical tabs or the like? Are some people arguing from a technical standpoint and others from a visual one?
    For example, while I am in favor or moving the details into its own "page", I dont really care if it is a tab on the same page or on its own new url entirely. "Page" to me in this context, is just "different list that fills the screen when you click somewhere". Performancewise, if it is a point to avoid loading more data than necessary on the initial load of the modules page, perhaps that means a separate page with its own url, I am not sure if that is strictly necessary, technically speaking.
    But it would be practical to know if some people are actualy agreeing on hiding from view, even if they seem to disagree about moving it to a tab or a new url.
    And, this is also a question of what exactly it is suitable for core to provide. I would be surprised if it turns out that we dont think Drupal itself should inform about its modules in detail.

    Taxoman’s picture

    Further on my last comment:
    I agree very much with the comment #256: "I can't emphasize enough how valuable this page is when undertaking a less directed exploration of the current state of a Drupal installation."
    ( https://drupal.org/node/538904#comment-5305312 )
    Item #3 in that list, "Explore overall site construction", is in my view related to having the information available about the dependencies, and a less directed exploration for someone without existing knowledge about Drupal, would be practical to do at a place where you can get the "full overview", not just part by part, therefore my emphasis on a full page or full view, or full modality or full tab or whatever full might mean in this context.

    Moreover, I think that a person who gets to explore a vanilla Drupal core site, before knowing how to (or even the need for) install extra modules, should expect to find one place to look at it all, to get a firm impression about what is "here", out of the box.

    jstoller’s picture

    @Taxoman:
    I for one assumed that "pages" meant the high-level horizontal tabs at the top of the page, which require a page load and change the URL, so can be thought of as different pages. This as opposed to vertical tabs within the content of a page, which just show/hide/filter content.

    I still think that having more than one of these pages devoted to listing modules is a mistake. Instead we should find a clean way to organize information in that list, with enough filter/control mechanisms that we can support most use cases. I have also yet to hear any use cases requiring the display of all information for all modules all at once, but I suppose we can keep discussing that at #1296876: Make dependency list hidden on modules page until requested.

    Bojhan’s picture

    @jstoller I understand your argument, however I think this is not a beginner/intermediate task. I removed it because I felt it had too much importance, it is a task often exercised by expert users and practically I am not sure beyond packages, how we really serve this usecase currently.

    Pages