Posted by marco.robotangel on December 18, 2007 at 11:47pm
16 followers
| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | usability |
| Category: | task |
| Priority: | normal |
| Assigned: | andreashaugstrup |
| Status: | closed (fixed) |
Issue Summary
Steps to reproduce: Try to configure a block.
The block configuration page is way too big. All those options are, especially for newbies, just overwhelming. The suggestion made at [1] is to shorten the page by collapsing 'role' and 'page specific visibility settings'. This would shorten the page a lot.
Comments
#1
tag for newbie
#2
I'm certainly a newbie. I have attached a patch that collapses the role visibility and page specific visibility fieldsets (setting collapsed to TRUE in the form definition in block.admin.inc).
#3
In the contrary to #202548, I'm not having major headaches with this. I'm just asking myself: Why do we collapse role and page visibility fieldsets and have the user specific visibility fieldset open. But I think it is okay this way.
#4
I assumed the user specific visibility would be used much more often than the other two.
#5
Applies cleanly. Code style is good.
We don't know this and have no easy way of finding out. Usability testing of this wouldn't give useful data because the result would be dependent on the task.
However my suspicion is that 'Page specific visibility settings' are the most commonly used. My opinion is that we should collapse 'User specific visibility settings', and move 'Page' first, leaving it collapsed. I think this is quite subjective though.
#6
collapse them all?
#7
collapsing them all is definitely edging on fieldsetitis -- wdyt?
#8
Collapsing all *looks* great on pages with custom blocks because they have a large textarea and the form just ends up looking like the node form. It looks a tiny bit more silly for blocks from modules because you are left with one textfield (the block title) and then three collapsed fieldsets.
Personally, I would collapse them all.
Collapsing all means having the submit button above the fold and that would remove the only annoyance I have when I configure blocks that only is to get a new title. It would help me when I'm only on the configure screen to check values (e.g. see what roles can see the block) because I only have to look through the 3 fieldset titles to find the info I need rather than browse over the entire form.
The trade off would be a more annoying block configuration screen when I have to use 2 or more of the fieldsets (setting roles *and* page visibility). In that case it would take marginally longer, but it's not something that would bother me a lot.
#9
I am going to set this to Drupal 7, but it should definitely get in. However it's a UI improvement, which is not allowed anymore in Drupal 6
#10
Patch attached that collapses all three fieldsets.
#11
What do others think about swapping the order to put 'page' first?
#12
It's impossible to say what people in general use the most. In my personal experience I would say that I use the "user specific" fieldset the least and I would enjoy to see that moved to the bottom. "role" and "page visibility" I use around the same amount and I have no opinion about which one should be the top-most fieldset.
#13
I use:
most - page
then - role
lastly - user
so +1 for page coming up the page.
#14
First I've seen of this issue but a couple of weeks ago I thought about submitting a patch to put 'page' first but never got round to doing it. So +1 here as well.
#15
Then this patch needs work to reorder the items on the block admin page.
#16
I complete agree with this.
I've reordered the fieldsets by:
page
role
user
See attached patch
#17
Applies nicely and functions as described. It's a great usability improvement!
The code looks fine too, I see no drastic changes or errors.
Finally, I get no fails from Simpletest on relevant tests (like block.test).
+1 for RTBC.
#18
The last submitted patch failed testing.
#19
Chasing HEAD, patch failed because the renaming of {blocks_roles} to {block_role}.
#20
The last submitted patch failed testing.
#21
Test failure : #335122: Test clean HEAD after every commit
#22
Moving this to usability - can we get a screenshot?
#23
Yes we can. :)
#24
IMO this is RTBC. Will leave it up to webchick/Dries whether it requires an official UX-team stamp of approval (just pinged some of them).
#25
New ordering with Page first, User last, makes total sense to me.
At first glance I was not so happy with all of them collapsed. This *always* requires an extra click before being able to configure stuff. But it *does* present all options above the fold this way and let's you make a conscious decision on which set of options you want to use.
And it is indeed near impossible to get sensible data on which one should be expanded by default since that will vary per block.
With that in mind, having all options above the fold at first glance is the bigger win here. Certainly a big improvement on the current situation. So, at least one UX-team member approves :-)
RTBC.
#26
Yeah, I think this is an improvement as well.
As a minor point, the use of keys like "user_vis_settings" and friends are somewhat problematic in light of the "no abbreviation" rules, but the original code uses this as well, so ok.
#27
Not sure if you're still looking for feedback. But when you go to create a block, will this mean all sections excepting the first "Block specific settings" will be collapsed? Or will all field groups be collapsed? Sorry I should probably just go and instal d7 and apply this patch to see!
#28
The screenshot is the default behavior right after clicking on "configure". In other words, the first fieldset, called "Block specific settings", is never collapsed at the start.
#29
Committed to CVS HEAD. Thanks.
--project followup subject--
Automatically closed -- issue fixed for two weeks with no activity.
#30
Automatically closed -- issue fixed for two weeks with no activity.