wwoast
commented
4 years ago I killed https://github.com/wwoast/redpanda-lineage/issues/217 partly because I think different kinds of table views in the search results is preferable to the idea of a Zoo profile page.
Thinking about the tables a little bit... portrait mode for panda rows will be two lines high:
Profile | (gender) name
Photo | Birth Year -- (Death Year)Landscape mode for panda rows will be a single line high. Potentially I could include more information, but panda names are variable in length.
Profile photo | (gender) name | birth year -- death yearFor zoos, portrait mode rows will also be two lines high, and need to be considerate of what information is being summarized for the search mode given. These should be strings very similar to the ones in the Zoo Results cards for # of pandas at the zoo.
Profile | Zoo name
Photo | <panda-count> <summary string>Landscape mode will likely need to preserve the same format, two lines high, to manage variance in zoo name and summary string length.
It doesn't work well, but you can search redpandafinder by country name. It gives you zoo and pandas for that country. It doesn't work perfectly because we don't do country searches to only return zoo results yet, and there's not perfect standardization of address formats per zoo -- but it's doable.
I tried this, got a giant number of results, and then had an idea -- what if for any query with more than 30 results, RPF gave you a table of items, rather than just a spew of result blocks?
I'm not sure how I want the table to be structured, but if your output has both zoos and pandas, I figure it should be a simple enough table to allow quick navigation to what you want. Since there's no great way to sort by zoos if it's enough zoos, I figure an alphabetic list of pandas by name is needed too.
So zoo tables will be accordion-style, where selecting the zoo expands the rows of pandas for that zoo. Whereas panda tables will be alphabetic, with a list of starting letters for you to quickly select the portion of the table that's interesting.
daniele.tokyo suggested implementing an alphabet-scrollbar similar to how mobile music apps let you navigate by artist. For a large enough table of values this seems inevitable to make navigation not terrible on mobile. Potentially instead of a visible alphabet scrollbar, I could have a hover-over appear that animates based on the position of the scrollbar in the page. The first and last letters of the alphabet range could remain visible, while the scrolling would cause the middle 5-8 letters to cycle based on which alphabet values are nearby. A really slick effect would be if the hover-over also summarized what x-y/N range of animals the viewport was currently showing.