shawncaza / compodio Goto Github PK

The orientation of the image associated with Show.id '1344' doesn't match the original.

Alternatively we could add a step in scrape_images.download_img to check image exif data for the orientation property.

Potential orientation values, based on this source, include:

1 = 0 degrees: the correct orientation, no adjustment is required.
2 = 0 degrees, mirrored: image has been flipped back-to-front.
3 = 180 degrees: image is upside down.
4 = 180 degrees, mirrored: image has been flipped back-to-front and is upside down.
5 = 90 degrees
6 = 90 degrees, mirrored
7 = 270 degrees
8 = 270 degrees, mirrored

Alternatively, we might be able to handle this with css, by updating the picture tag styles. This hinges on preserving the EXIF data which in not currently being done.

While I believe there's some pro's to keeping exif data on the image, there some downsides too. The example file mentioned above contains location information which might be desired to be publicly available. It also has a minor impact of file size. So I'd lean towards solving this problem without maintaining EXIF or relying of CSS.

Show images are a large contributor to layout shifts.

Reserving space for images, before the image has loaded, might already be happening in PictureTag since width and height are specified on the img element in the picture tag, but it might be worth adding height and width to each source element even though we're not using art direction/alternate image ratios.

Layout shift may also occur in between the show data becoming available, and the time it take to process size info before PictureTag can be added to the DOM. Calculations occur in useShowImgParams, CardImgContainer, ShowImgContainer, and GradientBg

Instead of returning null while calculations are being performed for PictureTag. We could render some kind of space placeholder as the overall height / width used around images is standard even if the image ratios are not.

GradientBg already does this around CardImgContainer, but PageSpeed Insights still occasionally renders it before it's taken its full height. Should we do something similar around CardImgContainer? Or develop a more universal and robust approach that works for both?

)

At present, in the DB shows.lang is populated during the ai_ep_summary process.

Generally this seems to work well. However, the results are not always what is desired. For example: An English show that plays world music may be incorrectly labelled. This is currently the case for show.'id = 146152.

A tricky component of this is it's computationally expensive to transcribe an entire hour+ long episode. So I have been determining language based on short snippets. A show may also contain station ads that don't necessarily reflect the language of the show itself.

There is also one unusual case where a show is officially trilingual (show.'id = 3033), and a show that is half English and half French(show.id = 269938)

It's probably too much to handle all of the rare special cases, but some improvement on the current situation might be possible.

A loosely related issue is that I don't wish to create summaries for shows that are music only. As a result I've manually entered the value 'skip' in the lang column for such shows as a short term band aid solution.

We've added the logic for Swiper use in #12 but we still need to integrate it visually into the site. I believe some initial refactoring will make this easier + make the layout pattern easier to reuse in the future.

Its current appearance is viewable here.

• Refactoring

Look at moving CardContent from ShowCards into its own component.

What's left of ShowCards could be renamed 'CardCollection' and should be generic enough to be located alongside the Card and Container component inside a new folder in card elements. I think it's worth coupling these 3 together more tightly as CardCollection will need to borrow css from the other two to style the swiper components.

• Styling

With the above in place let's attempt to normalize the card styles to work with swiper and see if we can get the pagination feature of swiper better positioned and using compodio colours.

As a starting point:

UUID:

• Lets assign new visitors a unique user ID when visiting for the first time.
• Store ID to DB and local storage.

Track actions:

• The following behaviours might help us make personalized recommendations:

  • Tag visits
  • Search Terms
  • Clicks to subscribe
  • Show page visits

• New DB table for user_activity could include columns for:

  • UUID
  • Action type
  • Action itself: ID of the tag / show the action was performed on, or the search term
  • DateTime.

  Do we store unique search terms in a separate table so we can refer to them by ID in user_activity? Or keep search out of this now for simplicity?

Based on a request here, I have added CKUT podcast feeds to the site. Some outstanding issues that arose in the process:

• Search behaves in unexpected ways when certain search terms are used. EX. searching for 'am' produces multiple results for a single show, and these results are not fully cleared when the search text is deleted.

• The date of the added show doesn't include a time. Unexpected difficulty getting the modified date from the mp3 header.

• In the apple podcast app, episodes do not always successfully play on the first attempt.

Hey Shawn!

I am writing to you because I found your issue with updating Typeform forms with a PATCH.

My name is Johannes, I am one of the co-founders of Formbricks (https://formbricks.com/)

We're building open-source form and survey infrastructure and will release our API this week. I'd love to hear more about what you have built with Typeform and how your developer experience has been.

We are looking for people exactly like you trying to tape custom code to Typeform. Many don't have the greatest experience and we would like to know what we should do right to get everyone building on top of Formbricks in the future.

If you have Discord we could chat there at https://formbricks.com/discord

Thanks a lot!
Johannes

This hasn't been done, and will likely add to the performance of the site.

• Let's start with identifying any such components
• Then work of preventing re-renders where possible.

At present only 3 stations have spiders(CFRU, CIUT, CKUT). I'd like to see more added. There is an outstanding request to add CFMU Hamilton here.

The shows page ([slug].tsx) should be updated to use the FeedLinks component instead of RssLink on this line.

This will display any external feeds that may be available for a show in addition to the internal compodio RSS feed. This component is already in use by the CardContent component.

Inside ShowCards add the optionality to present cards in a single row with horizontal scroll. Use a library like Swiper to achieve this.

This could improve UX when navigating across section like 'newest' or 'recommended' shows.

Show languages are identified during the episode summary generation process. At present there are at least 6 French shows, and 11 Spanish, and 259 English shows identified, 70 shows that do not yet have a language associated with it, and few others where language designation may not be accurate or important(music only shows).

With a growing number of French/Spanish shows, it could be nice to allow users to filter results by language preference in the UI. To do this we'd need to:

• Return the lang column from the shows table in get_all_shows
• Create filtering components for the UI
• Determine how to best track state of lang preference(likely a Zustand store since it's already in use), and store the filtered version of the useShowsQuery.
• Ensure all components that make use of the data from the useShowsQuery are using the filtered version when appropriate.