Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 6
Next »
\uD83D\uDDD3 Date
\uD83D\uDC65 Participants
\uD83E\uDD45 Goals
\uD83D\uDDE3 Discussion topics
Item | Notes |
---|
Updates | |
Search Design
| Abhiram Tadepalli : Side Filtering Sidebar to search 3 things Takes you to results page with filters Ex, search “1200” find all courses with 1200 Locally filters data, no API calls Filters appear based on what you search Is Professor filter required? Might be duplicating data If we want multiple professors, we can search “1200” first then narrow down prof Only relevant if there’s a lot of Professors Time range filter might be nice How do we handle profs that don’t teach anymore Decision: Should be under the bar, like Google, not on the side. Typing is limited to entering chips.
Tyler Hill : typing tokens “from:” is less intuitive than side panel or other discrete UI RMP, time are parameters Inspired by Google Trends Search tokens: Search bar is for more free text, but tokens (chips) can also be in there for setting parameters. Buttons below it (see Google Trends) are for more numerical things. Could also be professors
Autosuggestion User is typically searching for specific courses or professors So, we should be fairly strict on our autocomplete - “John” should only mean profs who are “John” User knows what they’re looking for usually
Is autocomplete a core feature? Exact match should turn into tokens “John Cole” becomes a chip after hitting space Current autocomplete backend, but show chips in the UI? Decision: Course identifiers like “CS” aren’t needed as chips
Prof name, course prefix+number, course name (maybe) can be chips If Prof isn't specified, should we include “all professors” in the search options?
|
✅ Action items