Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wireframe / Site Design #18

Open
RJP43 opened this issue Mar 24, 2019 · 2 comments
Open

Wireframe / Site Design #18

RJP43 opened this issue Mar 24, 2019 · 2 comments
Labels
development w{ebsite|iki development documentation project documentation

Comments

@RJP43
Copy link
Member

RJP43 commented Mar 24, 2019

The design of the podcast's website has been in development for over a year. @taylorcate and I developed wire-frames as part of the DIGH 402 course (available here). Our initial wire-frame had the primary page of the site displaying an elaborate, custom-built player taking up two-thirds of the page on the left and a scrollable panel on the right holding the plain text episode transcription. Seen here:
Original plain.txt podcast splash page wire-frame.
We envisioned the site to not scroll, except for within the transcription panel, and for a simple navigation bar at the top with a list icon that would give a drop-down list of the archived episodes and a connect button leading to the podcast's blog and social media links. We also planned to have a pop-up info. box within the transcription panel, called "meta", where all of the episode-specific metadata (host information, short description, etc.) would be available.
Connect Page:
Original plain.txt podcast connect page wire-frame.
Archive and Meta Pop-Ups:
Original plain.txt podcast archive and meta pop-up box wire-frame.

@RJP43
Copy link
Member Author

RJP43 commented Mar 24, 2019

Upon starting development of the podcast's website I quickly realized the complications of hosting large audio files directly on GitHub and the benefit of using a streaming service for handling these files as well as the RSS feed. From there I decided it was best to move forward with a streaming service (Soundcloud in particular) and to use the embedded player instead of worrying about creating a custom player. After this decision, I was still pretty set on the two column look of the site with the scroll-able transcription panel because I wanted users to be able to always have the player in view to quickly pause or scrub through the episode while reading the transcription given the emphasis of the podcast is the linked transcriptions. When @gmoe and I sat down to create the Jekyll framework of the site he explained how inaccessible the panel scrolling was and we began to redesign the look of the site. From the original wire-frame, we had the following list of features we saw as necessities to represent in the new design:

  • minimalist style; 2-3 page website with aesthetic, legible fonts
  • archive of available episodes
  • links to contact email, GitHub repo, RSS feed, twitter, wiki (replacing blog feature of the original design)
  • individual episode page (static; info changing pending episode selected) with a sticky player and scroll-able linked transcriptions
  • a section with episode-specific information (post date, host, brief summary)

The final design resulted in a two-page website with the main page hosting the list of available episodes as well as all of the desired links.
screenshot of the main page of the podcast website featuring an archive list of the episodes and all of the links
And the episode page with episode information, the sticky embedded SoundCloud player, and the linked scrollable transcriptions.
screenshot of the episode page of the podcast website featuring the episode-specific info and the embedded SoundCloud player
screenshot of the episode page of the podcast website featuring the sticky embedded SoundCloud player and the linked, scrollable transcriptions

@RJP43 RJP43 closed this as completed Mar 24, 2019
@RJP43 RJP43 reopened this Apr 2, 2019
@RJP43 RJP43 added documentation project documentation development w{ebsite|iki development labels Apr 2, 2019
@RJP43 RJP43 pinned this issue Apr 2, 2019
@RJP43
Copy link
Member Author

RJP43 commented Apr 25, 2019

Design Reflections

Post-Defense Design Considerations:

after 5-minute teaser @LUCTSDH 4/24/19

  • from Roberts' and Tay's perceived pronunciation of first publicized short description subtitle: add audio emoji that links at ~time of when "morphed word" is spoken in podcast audio 《in wiki transcription》and add link to the "morphed word" and (styled: small, grayed out) timestamp instead of emoji 《on plaintxtpodcast.com》
  • consider making sidebar with the linguistic diversion from process page for episode pages 《on plaintxtpodcast.com 》to match the wiki's Link Iconography/Travel Guide

after defense @ Crown Center for the Humanities 4/47/19 9 AM

  • include, at each level of development, the pre-existing theory and theorists also clarify the differences as well as theoretical points trying to build on

Pre-Defense Documentation To-Dos

  • need to develop and clarify community engagement theory expressed in issue Community Engagement  #19 on wiki process/progress page

Linguistic Diversion Theory

  • need examples for each special character

》 pipe:

Let's imagine you are writing a Halloween couplet and you want to play with the idea that there are multiple Halloween-themed animals with similar spellings/sounds/connotation that also might share a characteristic of pointed ears. Morphing bat and cat with the pipe you might write:

Pointy ears and beady-eyesight
Might you fear this curse of the black c|b}at's plight?

leaves the possibility of interpretation open to the linguistic diversion but expresses a shared thought or cohesive point no matter the word choice

must consider the author might have one particular intent or might not with the order of the listed words in the word-group and the nature of readers knowing there are instances where there is added meaning reliant on the word sequence that indicates authorial preference; nevertheless, the pipe intends to act more as a building/ripple-like effect with the inclusion of each word that collectively makes a more holistic claim. In addition to this stacking tactility vibe of the pipe, while we considered the somewhat similar use of the / in traditional writing that particular character is used at too high of frequency by a variety of computational processes, languages, and programming that I felt it worthwhile to choose a character that won't mistakenly set off unexpected but computationally logical effects. A similar rationale is why we additional authorial information or elaborations are going into 《》 instead of angle brackets to combat any adverse digital effects and instead of parentheses because we have already assigned a more specific function for text within ( ).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
development w{ebsite|iki development documentation project documentation
Projects
None yet
Development

No branches or pull requests

1 participant