More consistent presentation of search fields about django-suit

[jonashaag]

Great idea! Something along the lines of "Search persons by first name, last name, city". That probably doesn't fit into the text box because it's too much text but maybe you could expand it on focus.

[darklow]

Yes there is not enough place to fit such long placeholder and if you have many filters, expanding on focus will be very distracting. I thought about some tooltip, but don't liked that feature either.

But does user has to know fields in which search will be performed in first place? It can be relational data in third level, like company__enterprise__industry__name__icontains, what to show then?

Also it could be some full text search fields and so on. I think user doesn't care where search is performed, he cares will he find what he is looking for. We - developers think users care, but they don't :) Does github, google, linkedid, imdb show you where will it search? i guess no, so maybe it is not so important at all :)

[skndn60]

@darklow When you do not know how or what is searched but you find your stuff than you're possibly right. But when you can't find your stuff and the search criteria are unknown, than things become confusing and irritating to the user and the user will abandon the feature. I don't care how Google searches because they always find what I'm looking. Things would be different if they did not.

Say, I present my users with thousands and thousands of bookings and my search is limited to a search on the bookers last name and my user only knows where the bookers home town. Would it not be really helpful if the search field displayed a placeholder "Enter last name to search bookings"? I think so... It would be equally helpful if it says "Enter any value to search bookings". In my experience bad use cases find a root in phrases like "the user doesn't care". Users do care and do want to know; especially(!) when things perform differently from how they think they should. We developers tend to say "users don't care" when we have to solve apparently easy things which potentially involve a lot of screen real estate that is not easily available :-)

All in all, it's not a matter of life and death :-) There are more important features to chase...

[darklow]

In my experience bad use cases find a root in phrases like "the user doesn't care"

You took my words out of context :)
Of course users care, but they don't care the details, they care that item must be found that's it. They don't care you looked in 1 or 100 fields. They care "where is my item". And if item is there, but user didn't found it then it is your fault you didn't predicted user will want to search for this field.

"Enter last name to search bookings"? I think so... It would be equally helpful if it says "Enter any value to search bookings"

The first part would be helpful, but second is the same as just text "Enter keyword to search".
If you are in category "Apples" and there is search bar, is it really necessarily to write "Enter any value to find apples", don't take user as an idiot, that is one more rule, people don't like it :) What else could user find here except apples, oranges suddenly? :)

I just think, if we can't put all the search fields there in one textfield like Enter value to search in name, surname, address, phone, company name, company address, company enterprise name, ... Then better put something generic, than specify to search by name, if actual search is performend in more fields.

So maybe we can agree on some generic text or word?
Also it would be perfect if we could put something that is already in original translation files.

[jonashaag]

Maybe make the search field placeholder configurable?

[darklow]

If i add configurable variable you won't be able to use model verbose_name or verbose_name_plural or none of context variables.
What if i add {% block search_placeholder %}Keyword{% endblock %} to change_form.html ?
Then if somebody wants, he can override in project level with anything he wants, including model name etc.
Also i agree on changing current "Keyword" to something more meaningful, any suggestions?

[skndn60]

I think we agree :-)

In the case of apples the user will obviously not expect oranges but if apples are qualified by a rather large set of attributes and there are a lot of different species on file, it would be a good thing to know if there are limitations to the search capabilities provided. If there's one searchable attribute, then name it. If all attributes are searchable, then go for a generic placeholder like "Enter any value to search" or something along that line.

When there's a sizeable subset of searchable attributes (but not all), things will be more tricky as you then run into a screen real estate issue... I have no easy answer. Obviously naming them all is no option as it would look really silly. Maybe something like "Enter a value to search..."

[skndn60]

What if i add {% block search_placeholder %}Keyword{% endblock %} to change_form.html ?
Then if somebody wants, he can override in project level with anything he wants, including model name etc.
Also i agree on changing current "Keyword" to something more meaningful, any suggestions?

Sounds like an excellent solution to me

[vkorichkov]

Overwrite search_form.html:

....
{% load i18n admin_static suit_list admin_list suit_tags cs_tags %}
....

<div style="display:inline;" class="couponcode">  <!-- !!! class="couponcode" -->
                <input type="text" size="40" name="{{ search_var }}" ....
<span class="coupontooltip">
                        <b>Search in:</b><br/>
                        &nbsp;<b><i>Column (type of search)</i></b><br/>
                        {% for field in cl.search_fields %}
                                {% if field|slice:':1' == '=' %}
                                        {% with ff=field|slice:'1:' %}
                                                &nbsp;<i>{% get_verbose_field_name cl.model ff %} (equal)</i><br/>
                                        {% endwith %}
                                {% elif field|slice:':1' == '^' %}
                                        {% with ff=field|slice:'1:' %}
                                                &nbsp;<i>{% get_verbose_field_name cl.model ff %} (starts with)</i><br/>
                                        {% endwith %}
                                {% else %}
                                        {% with ff=field %}
                                                &nbsp;<i>{% get_verbose_field_name cl.model ff %} (contains)</i><br/>
                                        {% endwith %}
                                {% endif %}
                        {% endfor %}
                </span>
# ....

cs_tags is ...templatetags/cs_tags.py:

from django import template

register = template.Library()

@register.simple_tag
def get_verbose_field_name(instance, field_name):
    """
    Returns verbose_name for a field or field if missing.
    """
    verbose_name = field_name
    try:
        verbose_name = instance._meta.get_field(field_name).verbose_name.title()
    except:
        pass
    return verbose_name

css (I put the style in base.html)

<style type="text/css">
        .couponcode:hover .coupontooltip {
            display: block;
        }

        .coupontooltip {
            display: none;
            background: #EDEFF1;
            margin-left: 15px;
            padding: 10px;
            margin-top: 10px;
            position: absolute;
            z-index: 1000;
            width: 200px;
            border: 1px solid #DDDDDD;
            border-radius: 10px;
        }
</style>