One thing that would be helpful about not using drop-down boxes for static options: Fewer clicks required to set up a search. Each of the drop-down boxes in use now requires the user to:
Read the text on the drop-down box to decide whether it’s relevant
Move the mouse to the drop-down box
Click to open it
Read the options within
Move the mouse to the best fitting option
Click to choose the option
The first drop-down box (search type) contains only five options, which could be replaced by buttons like the existing Subscribed/Local/All buttons. It would make discovering the available options easier because they would no longer be hidden behind a drop-down, and it would reduce the number of actions required of the user.
The second drop-down box (sort type / time frame) might be a good candidate for this change, too.
As for whether tabs would be a better choice than the button-style approach currently used by Subscribed/Local/All: I’m not sure right now, as I haven’t had much time to consider it. But I think things would get messy and possibly confusing if more than one of these input elements were converted to tabs, because it would mean nesting tabs within tabs. On the other hand, using a row of buttons for each category would allow them to coexist neatly, fit the existing visual style, and avoid adding the complexity of another widget type for users to navigate.
One thing that would be helpful about not using drop-down boxes for static options: Fewer clicks required to set up a search. Each of the drop-down boxes in use now requires the user to:
The first drop-down box (search type) contains only five options, which could be replaced by buttons like the existing Subscribed/Local/All buttons. It would make discovering the available options easier because they would no longer be hidden behind a drop-down, and it would reduce the number of actions required of the user.
The second drop-down box (sort type / time frame) might be a good candidate for this change, too.
As for whether tabs would be a better choice than the button-style approach currently used by Subscribed/Local/All: I’m not sure right now, as I haven’t had much time to consider it. But I think things would get messy and possibly confusing if more than one of these input elements were converted to tabs, because it would mean nesting tabs within tabs. On the other hand, using a row of buttons for each category would allow them to coexist neatly, fit the existing visual style, and avoid adding the complexity of another widget type for users to navigate.