Scaladoc enhancements: searching members version 2

Hello Rüdiger & list;
I like your change as it seems to better use available screen estate. On the other hand, it is true that it is not very visible and casual Scaladoc users may easily miss it. I am therefore a bit ambivalent, but overall in favour.
However, your current proposal only deals with the textual filter. This is a weakness as the other filters consume much more screen estate.
More precisely: the search field you moved was part of the "member selection" box, the grey area between template documentation an members. This box contained all available mechanisms for filtering members. "Text" is one of them, "inheritance" and "visibility" are two other currently implemented. We plan to add more. For example, an "abstract" filter could be used to only display members that must be implemented in concrete subclasses. We have also been considering adding a "category" attribute to comments (to annotate getters, factories, etc.), which would require yet another filter.
In your design, you move one aspect of member selection to the bottom of the page, while leaving the rest in their original place. This is not coherent. I think you should consider integrating the remaining filters into the bottom-of-page box. Obviously, it would require a more compact representation for these filters. 
We will have to make the member selection box more compact in order to add more filters, as we plan to do in any case. In that sense, an extension of your design dealing with filters would consume an item on our short-term "todo" list. This would definitely convince me of the value of your change ;)
One possible design for a more compact selection box is to display by default a simplified version of the filter that is reduced to a single button. That way, all filters could be displayed next to each other in a single row below the text field. For example, the single-button version of "by inheritance" could be a popup with only two option, "Hide All" and "Show All". To get more control (to select specific inheritance classes) the user would click on a "+" button next to the simplified filter to open the full filter as it exists now.
What are your thoughts about dealing with the other filters?
Cheers,
Gilles, of the Scaladoc development team.

On Tue, May 17, 2011 at 20:24, Gilles Dubochet wrote:
> Hello Rüdiger & list;
> I like your change as it seems to better use available screen estate. On the
> other hand, it is true that it is not very visible and casual Scaladoc users
> may easily miss it. I am therefore a bit ambivalent, but overall in favour.
> However, your current proposal only deals with the textual filter. This is a
> weakness as the other filters consume much more screen estate.
> More precisely: the search field you moved was part of the "member
> selection" box, the grey area between template documentation an members.
> This box contained all available mechanisms for filtering members. "Text" is
> one of them, "inheritance" and "visibility" are two other currently
> implemented. We plan to add more. For example, an "abstract" filter could be
> used to only display members that must be implemented in concrete
> subclasses. We have also been considering adding a "category" attribute to
> comments (to annotate getters, factories, etc.), which would require yet
> another filter.

I never realized it was a section of its own.

> One possible design for a more compact selection box is to display by
> default a simplified version of the filter that is reduced to a single
> button. That way, all filters could be displayed next to each other in a
> single row below the text field. For example, the single-button version
> of "by inheritance" could be a popup with only two option, "Hide All" and
> "Show All". To get more control (to select specific inheritance classes) the
> user would click on a "+" button next to the simplified filter to open the
> full filter as it exists now.
> What are your thoughts about dealing with the other filters?

How about making it a single line with a drop down, like we do for members?

At any rate, one advantage of Rüdiger's change is that the filter
_stays_ on screen. It is very annoying to scroll up to get to the
filter again. If the whole thing was reduced to a single single with
drop down, it would be easier to keep it locked.

Hi Gilles,

nice to hear from you. I had the impression that you were absent from
Scala's development during the last months, but now your back as the
maintainer of Scaladoc?

Thank you for your feedback and clarification. Let me say that I'd
really love to contribute to Scala and I would happily implement
further changes, like to ones you suggest.

I agree that my current suggestion only deals with one aspect of
filtering. That's because I think it's by far the most important
aspect. But I also agree that we should probably unify this again. I
would like to implement something along your proposed changes. I
imagine a fixed column/line for filtering at the bottom on the page
that always shows the most important options and that can either be
expanded to show all options or that has popup like controls to make
all options accessible.

I would like to work on this without duplicating work from someone of
the Scala team, if possible. What do you think, can you entrust this
to me?

Also, I would be happy to get more involved in the thinking/planning
of the Scala team as I'd be happy to contribute to other things as
well. Also, I'd like to avoid working on features that you already
decided to replace or someone else is already working on.

Regards,
Rüdiger

2011/5/18 Gilles Dubochet :
> Hello Rüdiger & list;
> I like your change as it seems to better use available screen estate. On the
> other hand, it is true that it is not very visible and casual Scaladoc users
> may easily miss it. I am therefore a bit ambivalent, but overall in favour.
> However, your current proposal only deals with the textual filter. This is a
> weakness as the other filters consume much more screen estate.
> More precisely: the search field you moved was part of the "member
> selection" box, the grey area between template documentation an members.
> This box contained all available mechanisms for filtering members. "Text" is
> one of them, "inheritance" and "visibility" are two other currently
> implemented. We plan to add more. For example, an "abstract" filter could be
> used to only display members that must be implemented in concrete
> subclasses. We have also been considering adding a "category" attribute to
> comments (to annotate getters, factories, etc.), which would require yet
> another filter.
> In your design, you move one aspect of member selection to the bottom of the
> page, while leaving the rest in their original place. This is not coherent.
> I think you should consider integrating the remaining filters into the
> bottom-of-page box. Obviously, it would require a more compact
> representation for these filters.
> We will have to make the member selection box more compact in order to add
> more filters, as we plan to do in any case. In that sense, an extension of
> your design dealing with filters would consume an item on our short-term
> "todo" list. This would definitely convince me of the value of your change
> ;)
> One possible design for a more compact selection box is to display by
> default a simplified version of the filter that is reduced to a single
> button. That way, all filters could be displayed next to each other in a
> single row below the text field. For example, the single-button version
> of "by inheritance" could be a popup with only two option, "Hide All" and
> "Show All". To get more control (to select specific inheritance classes) the
> user would click on a "+" button next to the simplified filter to open the
> full filter as it exists now.
> What are your thoughts about dealing with the other filters?
> Cheers,
> Gilles, of the Scaladoc development team.