[drupal-devel] [task] Improvments to Filter UI
Bèr Kessels
drupal-devel at drupal.org
Fri Sep 9 15:27:47 UTC 2005
Issue status update for
http://drupal.org/node/27364
Post a follow up:
http://drupal.org/project/comments/add/27364
Project: Drupal
Version: cvs
Component: filter.module
Category: tasks
Priority: normal
Assigned to: Bèr Kessels
Reported by: Bèr Kessels
Updated by: Bèr Kessels
-Status: patch (code needs work)
+Status: patch (code needs review)
Attachment: http://drupal.org/files/issues/filter_module_UI_consistancy_2.patch (13.57 KB)
* Bugs as reported by dries fixed.
* The [add] tab not appearing is due to your menu caching, refresh that
please.
* Fixed an additional bug: Some agents do not send TRUE for disabled
checkboxen. Also in current filter admin.
and people: we have a problem. Deleting a filter trows errors, due to
the revisions changes. that happens in filter module now, but also
after this patch. I have too little knowledge of the filter system to
fix that, and IMO that is a separate issue. It should be fixed right
after this patch is committed.
Bèr Kessels
Previous comments:
------------------------------------------------------------------------
Sun, 24 Jul 2005 09:30:54 +0000 : Bèr Kessels
This is a mockup for the Filter UI. Currently it is soo complex, that I
dare to call it broken.
Please comment on this, for I will not ake any patches, when the
general idea is disliked.
The idea is t split filters and input formats better. Filters are
filters, defined in modules. Input formats are bundles of filters. This
is how we have it ATM, but the interface fails to communicate that. I
tried to develop a consistent (with the rest of Drupal) interfce that
makes it clearer what is what.
The menu is as follows:
* administer
** ....
** settings
*** input formats
*** filters
** ...
------------------------------------------------------------------------
Sun, 24 Jul 2005 09:37:10 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-formats_list1.png (16.34 KB)
* administer
** ....
** settings
*** input formats >> see attachement 1
*** filters
**
------------------------------------------------------------------------
Sun, 24 Jul 2005 09:39:02 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-formats_add.png (23.42 KB)
* administer
** ....
** settings
*** input formats >> see attachement 2, tab 2
*** filters
**
Note: The default checkbox lmay seem a bit odd. But checking it will
remove the "default status" from the current "default" one and make
this one "default". The help text, and a drupal_set_message should
explain this.
------------------------------------------------------------------------
Sun, 24 Jul 2005 09:40:08 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-formats_edit_format.png (22.17 KB)
* administer
** ....
** settings
*** input formats >> clicking a 'configure' link in the table of
attachement 1
*** filters
**
------------------------------------------------------------------------
Sun, 24 Jul 2005 09:40:55 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-filters_list.png (36.24 KB)
* administer
** ....
** settings
*** input formats
*** filters >> see attachement 4
**
------------------------------------------------------------------------
Sun, 24 Jul 2005 09:41:40 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-formats_edit.png (22.63 KB)
* administer
** ....
** settings
*** input formats
*** filters >> clicking a 'configure' link in the table of attachement
4
**
------------------------------------------------------------------------
Mon, 25 Jul 2005 14:46:27 +0000 : Bèr Kessels
IMO this makes the interface easier. But other disagree. And because it
also removes one feature: (being able to use E.g. HTML in different
input formats, with different settings)
I'll simply wont fix this :(
------------------------------------------------------------------------
Thu, 28 Jul 2005 13:36:12 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/filter_module_UI_consistancy.patch (10.28 KB)
I decided to go for it anyway. Be it in a slightly different way then my
initial mockups. The difference is that I left the filters where they
are, hidden beneath the formats.
So, here is the patch that makes the filter UI more consistent with
screens like blocs, menus, vocabularies et al
also nice to note is that:
93 lines are added, 104 are removed. So netto we have less code :)
(cvs diff filter.module | grep ^+ | wc -l)
------------------------------------------------------------------------
Thu, 28 Jul 2005 13:37:02 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-formats_list_html.png (44.64 KB)
Here is how the listing now looks.
------------------------------------------------------------------------
Thu, 28 Jul 2005 13:37:57 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-formats_edit_format_html.png (113.71 KB)
And the "configure" screen.
The 'add' screen looks exactly the same, only with the default values
pre-filled.
------------------------------------------------------------------------
Thu, 28 Jul 2005 13:39:19 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-formats_edit_format_too_long.png (121.82 KB)
Oh, And here is a really nice example of why the current screen is no
good.
And here I "only" have four roles. I run a site with 12 roles, imagine
this screen then!
------------------------------------------------------------------------
Thu, 28 Jul 2005 13:48:35 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/filter_module_UI_consistancy_HEAD.patch (10.24 KB)
And here is a pathc for HEAD (I forgot that I developed this on a 4.6.2
codebase. Sorry)
------------------------------------------------------------------------
Thu, 28 Jul 2005 13:55:25 +0000 : stefan nagtegaal
I like this very, very much!
This is - indeed - much better than the current UI. This always fits,
and makes the life of people who use a fixed width theme much nicer..
Ber, FYI (you probably know this too), 'admin/access' does also break
fixed width themes due to the fact that it expands the width of the
table when more roles are being added..
Good catch! I like it much more this way..
+1 from me...
------------------------------------------------------------------------
Fri, 29 Jul 2005 07:27:34 +0000 : Dries
The code style needs work (spaces, tabs, 'as' -> 'AS'), the code
comments need work, and debug statements should be removed.
Screenshots look good to me. db_query('UPDATE {filter_formats} SET
cache = %d, name = \'%s\', roles = \'%s\' WHERE format = %d',
(int)$cache, $name, $roles, $format); can be written better/shorter
quote-wise.
------------------------------------------------------------------------
Fri, 29 Jul 2005 09:04:16 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/filter_module_UI_consistancy_HEAD_0.patch (10.37 KB)
Dries, thanks a lot for the review. OI fixed your comments. Or so I
hope. code-style.pl was of no use (can that *please* be removed from
core?) because it chokes on the help texts. It also pointed out a lot
of old formatting isues, whic, when fixed wuold flood this patch with
unrelated fixes. I tried to narow my style-searching to the areas I
touched. And I made the comments more verbous.
The query is fixed. it saves no characters, but looks better now.
Thanks for the tip.
The print_r..... blush. thats what I get for not running my default
grep -r print_r on my code after finishing up...
I could not find a lot of spaces and tabs. So it lmight be that i
missed one. I triple checked it though.
------------------------------------------------------------------------
Fri, 29 Jul 2005 09:32:21 +0000 : Steven
Moving the role settings inward does fix the wide-table problem, but it
makes the filter configuration much more opaque. We could perhaps fix
this by showing the roles as a comma-separate list in the input formats
table. Such a list can wrap and will not stretch the table.
Other than that:
* Having the instructions for the Roles and Filters form_group() at the
bottom is a bit weird. The distance is too big.
* The table that was used for toggling filters on/off was much more
compact before, and IMO a lot clearer. Why change to a flat list with
the description staggered below each item?
------------------------------------------------------------------------
Fri, 29 Jul 2005 10:31:30 +0000 : Bèr Kessels
consistancy, consistancy and more consistancy.
There really is nothing worse that having a different 'concept' of UI
for every thing in Drupal. We are going in the right direction, with
the blocks being editable objects, menus acting like that, taxonomy,
users, etc..
I wanted to make this act similar. I am not at all happy with the fact
tah the list is still a form. But we need this, for setting the
default.
A big -1 for a comma-separate list. That is extremely hackish, even
worse useabilitywise and just silly
* we should avoid typing when not needed.
* we should avoid errors on input, when they can be avoided (a typo
is made very easy, I know all about it) Form set errors won't fix that
usability -wise.
I agree that you sort-of loose the overview. But IMO that is a minor
loss comared to what we gain, usability-wise.
The wtoo-wide was onlywhat triggered me. But do not think that I am
noly making this patch to fix that issue. This patch is there to
improve usability, through consistancy. o make drupal behave the same
in most places in admin. If you know one screen, you know most of them.
We really should move away from custom-hacks for every page, because
that is useability rule #1: consistancy. Stadardisation, even if
sometimes a custom hack might make things easier in that single case,
it will reduce your overall usability so much that nearly ever it is
worth that hack.
That select-boxes instead of the table issue: consistancy. As well that
it completely broke fluid CSS layouts, my solution is more consistant,
and uses forms the way they are meant. If we cannot use $descritption
in checkboxes they should be removed. but IMO it feels much more
consistant. Tables are for tabular data, and this is simply a list of
items, with additional data.
And i do not really get what you mean with "too far down". Do you mean
that you would like to see the order of the groups different?
------------------------------------------------------------------------
Fri, 29 Jul 2005 13:31:24 +0000 : Dries
I haven't tested Ber's patch yet but looking at the screenshots, it like
what I see. I remember being confused by the current filter UI, and
often, I still am.
------------------------------------------------------------------------
Fri, 29 Jul 2005 19:53:26 +0000 : moshe weitzman
I dislike the recent movement away from overview pages. I think we can
still provide and overview while allowing editing to happen in a
dedicated form. An example in the wrong direction is 'content types'
admin. It is impossible to get an overview, and the listing page is
worthless. I agree with Steven on this one.
It is true that consistency is desirable. But consistent crap is not.
------------------------------------------------------------------------
Fri, 29 Jul 2005 20:02:39 +0000 : killes at www.drop.org
I agree with Moshe. Getting a quick overview about what is set how is
essential for an admin.
------------------------------------------------------------------------
Sat, 30 Jul 2005 00:27:15 +0000 : Robrecht Jacques
Overall I like the screenshots. Did not test the patch.
Bèr, what I think Steven (#15) meant by "showing the roles as a
comma-separate list in the input formats table" is that as an overview
page it would be better if you added a list (not an input box!) to
screenshot "input-formats_list1.png" (comment #1). Add a column that
reads "Roles" (or "Enabled for") and then for each row a comma
seperated list of the roles that can use this input format (or maybe
even better a HTML list). You would still need to click "configure" to
_change_ the roles.
The "Default" text (not a radio button) you already show in the
"Options" column is something similar: it immediately shows that this
input format is the default without you having to go to the "configure"
page. Why not do the same for "roles"?
If this is what Steven meant, then I tend to agree with him.
And to help moshe and killes: maybe you could even add a column that
_lists_ the used input filters. Again, only a list, not a way to change
it. That's what the "operations" column is for.
A table like that will "fluid" better than what we have now, still it
is a _complete_ overview of the settings.
I could have misunderstand someone... I have the tendency to do that...
------------------------------------------------------------------------
Mon, 22 Aug 2005 08:21:32 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/filter_interface_improvements.patch (14.52 KB)
by popular demand: a comma separated list.
------------------------------------------------------------------------
Mon, 22 Aug 2005 08:24:31 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/format_now_contains_roles.png (22.09 KB)
and a screenshot
------------------------------------------------------------------------
Mon, 22 Aug 2005 18:39:44 +0000 : Dries
Please check your use of print theme('page', $output). Normally, you
just return $output.
------------------------------------------------------------------------
Mon, 29 Aug 2005 18:54:28 +0000 : Bèr Kessels
All instances of theme('page',...) in filter.module are now changed to
return ... ;
furthermore, the patch is the same.
------------------------------------------------------------------------
Mon, 29 Aug 2005 20:04:02 +0000 : Uwe Hermann
Bèr, I think you forgot to attach your updated patch.
------------------------------------------------------------------------
Mon, 29 Aug 2005 20:27:39 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/filter_interface_improvements_2.patch (13.52 KB)
my email client has this nice warning system for attachements. Maybe
drupal should search for the word attachement too, and when no att.
found give an error ;). Or maybe i should just learn to pay attention.
Guess that is easier.
Anyway, here it is.
------------------------------------------------------------------------
Thu, 08 Sep 2005 20:22:54 +0000 : Dries
I wanted to apply this patch but:
1. I can't change the default input format. 'Save'-button doesn't
work.
2. I got confused by the fact I can't change the roles of the default
filter. I think the form group description should explain this.
3. form_group(t(filter)) should be form_group(t('filter'), ...).
------------------------------------------------------------------------
Thu, 08 Sep 2005 20:51:24 +0000 : m3avrck
Found a few more issues:
If I go into 'Configure' for 'PHP Code' and click the 'Configure' tab
at the top and then click 'list filters' link in the text, I get this
warning with PHP5 warning: Missing argument 1 for filter_admin_format()
in \drupal\modules\filter.module on line 378.
Also, it is sort of confusing as to what the 'List' tab implies. For
example, if I click on 'input formats' in the admin menu, I get a list
of the current filters. When I click 'configure' for one of those, I
see the options for that filter. However, it says 'list' in one of the
tab, which doesn't really mean much. I thought that was the list of
filters, not the options for that filter. That should be cleaned up.
Also, there is no way to get back to the full list of filters unless
you click on 'input formats' in the admin menu. A setting/link to fix
this would be great.
Also, where is the link to add filters???
I think the options/layout/tabs should mimic of that of admin > users.
So on admin > input formats, it has the tabs 'list', 'add format' ...
very clear and consistent.
On a configure page for a filter, it should have 'list', 'view',
'configure', 'rearrange' ... this would make it easier to navigate and
get back to the original list of filters.
Make sense? I think this and Dries' comments put this patch over the
top :)
------------------------------------------------------------------------
Fri, 09 Sep 2005 01:48:55 +0000 : tag
In my initial battle to figure out this module's (quite nice)
functionality, what tripped me up the most was actually the
nomenclature.
The way I keep it straight in my head now is to translate "input
format" to "filter set". If you view those (the current) screens with
this in mind, I think it's a lot easier to understand what's what. It
sort of describes this in the help text, but the terms "filter" and
"input format" don't really convey the relationship between the two --
there's no way to intuit that an "input format" is a collection of
"filters". Not to my mind at least... and well, we know nobody reads
instructions...
Are there any technicalities that make renaming "input format" to
"filter set" not accurate? Or does someone have a better term/terms to
better show the relationship of these elements? (I'm aware of filters
in servlet architectures but I don't think there's much of a collision
with that usage).
Anyhow, I guess this doesn't quite address the UI controls and/or
layout, but would still help a lot.
------------------------------------------------------------------------
Fri, 09 Sep 2005 06:35:34 +0000 : Bèr Kessels
I prefer filter set. In fact: I like it a lot. Anyone else ideas on
this?
------------------------------------------------------------------------
Fri, 09 Sep 2005 10:18:18 +0000 : Dries
I too had problems with the terminology; it took me months to get used
to 'input formats' versus 'filters'. Using 'filter sets' might improve
the situation -- especially from an administrator's point of view when
you have to wrap your head around the UI/difference. I'm not native
English, but 'filter set' sounds more explanatory, yet slightly more
geeky so I'm not sure if it flies for users who don't need to
understand the underlying concepts (eg. under the node and comment
submission forms).
------------------------------------------------------------------------
Fri, 09 Sep 2005 11:00:05 +0000 : Bèr Kessels
a heads up: I ma redoing the patch. But decided no to change the name
yet. That is a too big change. IT should be in a separate issue, IMO.
More information about the drupal-devel
mailing list