Web Team 2011/2012 Priorities

[shaun]

We're having the first proper meeting of the new web & IT team this weekend. The main thing we'll be discussing is the priorities for site development this year. I've trawled through all the old threads I could find and have come up with this list of suggestions. I didn't include the small details type stuff, things that are now out of date or unnecessary... I also added a couple of things which have been floated verbally or in email but not on the forums.

There is a lot of crossover in the aims of these changes but I've stuck them under headers as best as i can. Please reply with thoughts on what should be prioritised or what approach would be best or if anything is missing.

1 Station wide content delivery
1.1 reorganisation of the homepage
The homepage is largely events or station news focused with infrequent updates and poor display of our primary content.

1.2 reorganisation of the listen content
Reduce prominence of now/next live studio feed and essential listening and increase automated recommendation streams like facebook based personalised suggestions, most recent, most popular and most interesting.

1.3 listen live opt-in
Only show episodes on listen live when the show has indicated it is going to attend - eg added a title and description and sounds. This will stop non-attended shows being displayed to listeners and will incentives metadata to be added in advance of broadcast.

1.4 solution to featured content delivery
Currently a mixture of the podcast section and creating a show profile specifically for individual features is how we deliver one offs and non show based content. The podcast section should probably be depreciated in favour of one delivery system for all audio - episodes system. However the process of creating a profile is cumbersome and the product often wasteful. A solution to this problem is needed.

1.5 Look and feel
A total reworking of the look and feel of the website has been suggested and mocked-up.

1.6 embeddable player
Mixcloud / soundcloud / youtube style embeddable player

1.7 Further development of the embedded player
Pseudo streaming to allow skipping to a time without loading the preceding audio, optional popout, more refined display and controls

1.8 Pagination of long pages (by year probably)
Some of our pages are very long like /events or /shows/shownews, we should paginate these by year or some smaller time unit. This might also help make archives easier to browse.

2 Improving content and its metadata
2.1 New Episode Management System
Adding a title, description and playlist as well as skipping or deactiving episodes are currently underused and awkward features. A streamlined back-end system with harsher penalties for not submitting the information has been suggested.

2.2 Manual trim/edit for episode time
Contributors should be able to trim deadspace at the start and end of their episode audio by typing in a time in the backend. They should also be able to indicate when they have ran on longer or started early. Perhaps even with a start episode now button.

2.3 Episode mp3 upload
Currently all prerecorded, re-edited or audio otherwise not from the logs of the studio output has to be manually uploaded by the IT team. Contributors should be able to upload their own episodes and replace their own audio when needed.

2.4 Per episode people data
Record which contributors contributed to each piece of content and in which way. Use this data to build better contributor profiles and to make related content suggestions more accurate.

2.5 Per episode sounds
Reduce the number of broad show tags like "varied music" and increase accuracy of content metadata to allow for better browsing and relation of content.

2.6 Per episode images and links
Defaulted to the show image and links but available to change for each episode.

2.7 Timestamping
Time stamped comments, time stamped playlists in the audio player like soundcloud/mixcloud/youtube

2.8 Programmes dept automated reports
Other automated reports to cut down on manual admin work like flagging falsified playlist information, poor attendance, summaries of changes to show profiles etc

3 Using the metadata to help the listener
3.1 Related content algorithm
Episode pages could have a section with links to similar content based upon the data we collect (sounds, artists, labels, people)

3.2 Interesting Algorithm
Automated recommendation of content based upon the uniqueness of the music data for the episode - eg playing a label that's never been played before.

3.3 Popular content algorithm
Record number of comments, likes, plays and views then display these and/or use the information to highlight popular content (or unpopular content that might be getting missed)

3.4 Artist, Label, sounds Graphs
We collect lots of data about what people are playing, it could be useful or interesting for visitors to display this information graphically.

4 Listener/community engagement
4.1 Comments system
Have oauth or similar based comments system directly on the episode pages rather than via the forum.

4.2 Contact this show/person system
Have a consistent way of contacting a show or person at the station

5 Income generation from content
5.1 Adverts via the player
Currently audio adverts and imaging has to be part of the content's audio, a system of adding an advert or imaging to the start of content which could be set to be there for x days or x plays would be good.

[shaun]

This is a list of the titles without the descriptions to help with copy pasta:

reorganisation of the homepage
reorganisation of the listen content
listen live opt-in
solution to featured content delivery
Look and feel
embeddable player
Further development of the embedded player
Pagination of long pages (by academic year probably)
New Episode Management System
Manual trim/edit for episode time
Episode mp3 upload
Per episode people data
Per episode sounds
Per episode images and links
Timestamping
Programmes dept automated reports
Related content Algorithm
Interesting Algorithm
Popular content Algorithm
Artist, Label, sounds Graphs
Comments system
Contact this show/person system
Adverts via the player

[shaun]

This is my thinking on it:

The following things are low priority:

embeddable player
Further development of the embedded player
Pagination of long pages (by year probably)
Programmes dept automated reports
Comments system
Contact this show/person system

These things are high priority:

reorganisation of the homepage
reorganisation of the listen content
listen live opt-in
solution to featured content delivery
New Episode Management System
Manual trim/edit for episode time
Episode mp3 upload

Order
some things require others to be done first. Like the reorganisation of the home and listen pages will need the interesting algorithm, popular content measures and so on.

I think we should probably start by doing these things first:

solution to featured content delivery
New Episode Management System
listen live opt-in
Episode mp3 upload
Manual trim/edit for episode time
Per episode people data
Per episode sounds
Per episode images and links
Interesting Algorithm
Popular content algorithm
Related content algorithm

And then do the home page, listen page and episode page upgrades to incorporate better useage of the new quality metadata.

In summary,
I think we need to do things in this order:

1. collect the right data (featured content solution, episode management system, manual time trimming, per episode data (people, sounds, images and links))
2. process the data (algorithms)
3. use the processed data (update the content and look of the homepage, listenpage, episode page etc)

[harry]

I think your logic is sound even if you did post this at 6 this morning.

[shaun]

Summary (TLDR)
We need to make episode pages the vehicle for all of our audio content
Episodes should have their own sounds, playlist, people, description, title etc
Episodes shouldn't have to be scheduled
Episodes shouldn't need to be attached to a show
--
A show is one way to group content
We have lots of other ways
We should use the same template for all of these ways of grouping
Some content is made by more than one show. The straight parent - child relationship doesn't work here.

full brain dump
One thing that I've thought about since writing the above that ties in with the featured content stuff but also the per episode sounds, people, images etc etc

Currently the website is structured such that all episodes are the children of shows.
In real life, not all episodes are the product of the shows system.

The current workarounds for this involve:
1 making catchall show profiles for a type of content (eg Subcity Sessions, Subcity Presents)
2 making a show profile specially for the piece of content (RnB me up, Freshers' Address)
3 posting as a podcast under a content genre/type (glasgow film festival under documentary)
4 posting as a direct mp3 link (event recordings mainly)
5 uploading to other sites (mixcloud, soundcloud) (mixtapes mainly)

All of these workarounds are bullshit in one way or another.

1 and 3 are bullshit because if we want to have one place for all of our content that is a session then what about sessions that are on shows like george's or pop cop or theeze boyz etc. What about other groupings like the podcast ones, can an interview not also be current affairs or documentary, can a documentary piece not also include a session? The solution here is tags. Per episode tags will allow us to have all sessions tagged as session and this then gives a way for us to group/package these sessions and display them to the user.

2 is bullshit because you are creating a page which is designed to be a consistent stream of content from a group of cunts doing their thing. When you are only ever going to have one episode what is the difference between the show description and the episode description? What is the purpose of the show profile? Why do we need this show profile?

4 & 5 are just clear workarounds to get away from having to make a profile, then schedule an episode, then get IT to upload the audio.

We don’t think it makes sense any longer to have a space on the listen page that’s dedicated to a way of covering subjects. People don’t use our site to listen to shows or podcasts, they’re here for our content - whether it’s a full radio show, podcast, mixtape, or review.

We mainly make audio content. All of our audio should have a playlist, image, sounds, description, people etc metadata and be delivered via the new player. Essentially, all audio should be an episode. However, not all episodes should have shows.

One way to do this would be to have two types of episode, ones that had shows and ones that didn't. Another way would be to change the relationship of shows to episodes making a show one of many possible tags or categories and making it optional to have a show at all. Personally I think the latter makes the most sense but if the end result for the user is the same and future development wise it is the same then it doesn't matter too much.

TLDR #1
We need to make episode pages the vehicle for all of our audio content
Episodes should have their own sounds, playlist, people, description, title etc
Episodes shouldn't have to be scheduled
Episodes shouldn't need to be attached to a show

The important thing following on from this is how the rest of the website directs people to content. The current website generally directs people to show profile pages. It used to be wholly to show profile pages but we updated a few bits to point to episodes (ie the content).

Currently show profile pages mainly consist of episode descriptions but lack obvious links to each episode's audio and lack structure to give each episode prominent space.

Artist, sound and label pages all follow the same model - a list of shows with a few episodes beneath each.

We should be trying to direct users to content at the earliest opportunity. Most of the time, sending them to a show page first only serves as a middleman page. One place where the show grouping can sometimes be of use is as a way of sub grouping a large list of episodes. For example the Disco sound will return many episodes but an italo disco show is different from a pop disco show which is different from a house show that plays some disco. A lot of the time this sort of clustering doesn't work well, many shows at the station don't do the same thing every week and not to the level where it would cluster well like this.

Shows are only one way of grouping the data, and a particularly unpredictable way of doing so. We should be able to use the episode sounds and playlist and other meta-data to group the episodes more intelligently.

Some of our content, and this is why for some of the content we used to have to make bullshit show profiles for (eg subcity presents, subcity soundclash), is made by more than one show in collaboration. We should allow for an episode to be attached to more than one show.

In terms of what a show is for a listener, and what a show profile is: a stream/feed of content grouped by shared properties/theme. Being the product of a show is only one way we can group our content. We can also group by the other metadata we have like sounds, people and artist data. It would make sense to use the same design and template for artist pages, sound pages, people pages... as we use for show pages. All of these pages are feeds of grouped content and all could have the same properties, we should look at writing or pulling the missing properties (descriptions, images) from somewhere.

TLDR #2
A show is one way to group content
We have lots of other ways
We should use the same template for all of these ways of grouping
Some content is made by more than one show. The straight parent - child relationship doesn't work here.

There's more in my brain but that is all for now. This kind of documents what I said at the recent web team meeting anyway.