#9500 closed (fixed)
Put the Google search that is in the main documentation page on *each* documentation page.
Reported by: | Beetle_B | Owned by: | nobody |
---|---|---|---|
Component: | *.djangoproject.com | Version: | 1.0 |
Severity: | Keywords: | ||
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Currently, if I'm deep in the docs, and I decide to search for something unrelated in the docs, I have to navigate to the main Documentation page, and then do the search (via Google).
It sure would be convenient if that search field was on each page in the docs.
(Hope this is the right place to submit this ticket).
Change History (3)
comment:1 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 by , 16 years ago
Component: | Uncategorized → Django Web site |
---|
Mea culpa. I always looked on the top.
I guess one could argue both ways on where it should be placed...
Doesn't Trac have a way to set the resolution to invalid...?
comment:3 by , 16 years ago
For things that are valid requests but happen to be already implemented it's a tossup whether I call them invalid or fixed. I really want an "already fixed" but we don't have that. I don't think it matters all that much since so far as I know nobody tracks stats on tickets closed by resolution or anything like that.
As for the placement of the Search yes I think it's debatable where is best. I too did not realize at first it was on every page, which argues always at the top might be better. On the other hand that seems to put undue emphasis on getting away from the current page vs. showing you what's available on the current page via the Contents, so I can see why Contents come first.
It is on every page, in the right sidebar, under the Contents for the page.