![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
LJSV-1068 redux
I appreciate all the feedback I got on my previous post. Here's my thinking based on the comments there:
Tag list: wait for the new update page. The LJ implementation looks pretty buggy anyway, judging from initial reports.
Tag search: yes, we should make a GUI the primary interface to tag search on our site. It should:
* support complex boolean operations
* use either a POST to avoid the URL parsing problem, or an entirely new URL format (since you can't bookmark the result of a POST), or possibly both
* allow you to search for tags in more journals than just your own, as a paid feature (which means it should be a site page like "Manage Tags", not a journal page)
* allow further refinement of results based on date range and/or security level, possibly even mood (yes, that has already been suggested elsewhere)
However, that should be a new bug (or several bugs), perhaps more accurately titled "Metadata Search" to complement the existing Content Search. It need not immediately replace the basic tag search we inherited from LJ, which was never so ambitious.
A codemerge from LJ, if possible, would close the existing bug (which came from suggestions) for fixing the basic URL search in the current syntax, with added support requested for using ALL as the keyword instead of AND (although we should allow both for compatibility). If our code has changed too much to merge, or if it proves difficult to take only that part of the change and leave out the tag list code, we could reconsider whether it's worth the effort - but compared to the "all that and a pony" spec outlined above, it seems simple enough.
I think this approach would give us a usable (if "ugly") short term solution with minimal effort for the most basic use case, plus space to plan for a better long term solution in the future.
Tag list: wait for the new update page. The LJ implementation looks pretty buggy anyway, judging from initial reports.
Tag search: yes, we should make a GUI the primary interface to tag search on our site. It should:
* support complex boolean operations
* use either a POST to avoid the URL parsing problem, or an entirely new URL format (since you can't bookmark the result of a POST), or possibly both
* allow you to search for tags in more journals than just your own, as a paid feature (which means it should be a site page like "Manage Tags", not a journal page)
* allow further refinement of results based on date range and/or security level, possibly even mood (yes, that has already been suggested elsewhere)
However, that should be a new bug (or several bugs), perhaps more accurately titled "Metadata Search" to complement the existing Content Search. It need not immediately replace the basic tag search we inherited from LJ, which was never so ambitious.
A codemerge from LJ, if possible, would close the existing bug (which came from suggestions) for fixing the basic URL search in the current syntax, with added support requested for using ALL as the keyword instead of AND (although we should allow both for compatibility). If our code has changed too much to merge, or if it proves difficult to take only that part of the change and leave out the tag list code, we could reconsider whether it's worth the effort - but compared to the "all that and a pony" spec outlined above, it seems simple enough.
I think this approach would give us a usable (if "ugly") short term solution with minimal effort for the most basic use case, plus space to plan for a better long term solution in the future.
no subject
no subject
no subject
no subject
-Mark, who is always sad that the stupid and terrible UIs he makes tend to end up living on for years (content filter management, community management, content search, latest things)