Designing a Public Facing Reservation Form

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
dfrazier's picture

RETN is planning to open Reservations to our public users later this year and is interested in integrating equipment inventory images into the public-facing Reservation form. Have any other Community Media Centers out there using Reservations looked into this?

I know the Open Media Foundation has inventory images in their reservation form, and what we have in mind for design and functionality is similar to that implementation. We are envisioning a horizontally oriented carousel of inventory images. User would select a reservable content type group taxonomy term, which would bring up that term's carousel. User would then click on images or titles below the image to make their selections.

Obviously this needs to be scoped out in greater detail, but I'd be interested in feedback from other CMCs before doing that.

Although RETN is not currently part of the MOU that structures the collaborative work being done by MNN, Channel Austin, and PCM, we would like to contribute to the Reservations form in a way that supports that work. If anyone is planning on or currently examining modifications to the public-facing Reservation form, I'd love to talk. In the meantime, I'm hoping to gather any ideas or needs that other CMCs have relating to the Reservation form.

Comments

Drew, Before you start

kreynen's picture

Drew,

Before you start conversations about improving the UI of another part of CMD, please finishing share the code for improvements RETN has already made. Emily created a video about RETN's Airings based schedule 2 months ago and a sandbox project 2 days ago, but still hasn't shared any code.

There is a lot work required to support modules other stations can just download and use, but committing the code literally requires typing....

git init
git add *
git commit -m "Initial commit."
git remote add origin [USERNAME]@git.drupal.org:project/[PROJECT-NAME]
git push origin master

It normally takes about 5 minutes.

True collaboration requires a lot more work than taking code other groups publish publicly and making videos about the features your organization has built using that code combined with other code other users don't have access to.

By using code other stations have shared and skipping the steps required to get to point another station can implement the same features RETN has, you've successfully reduced RETN costs... but unfortunately this is at the expense of the groups that share and support a lot of the code RETN is using.

As an organization, RETN needs to invest time understanding how other organizations use these modules and be willing to invest even more time in supporting the contributions you make. Otherwise the only way anyone else gets code and support is if they pay the contractors RETN decides to hire.

Staff members from RETN need to sign https://drupal.org/node/1860560.

The UI of Reservations is already separated from API that enforces the rules for who can make reservations. The current UI is completely optional and the form can be passed the ids of specific pieces of reservable resources or the name of a bucket. Views of reservable items can be filtered by weather the item is currently checked out or not, but there's no functionality to pass a future date range to that View so the equipment users see may or may not be available when they want to reserve it.

This UI separation was funded by MNN largely to support MNN's more complicated, multi-location/inventory requirement, but it had to be written in a way that Reservations still worked for channelAustin and other groups using Reservations. Making updates in a way taht worked for everyone cost MNN significantly more than simply hiring a contractor to change Reservations to meet their specific needs.

MNN is planning on allowing producers to log into their system sometime this summer. Currently https://drupal.org/project/reservations_inventory is only designed to work for staff so additional work needs to be done for that UI.

OMF's Drupal Commerce based reservation system is already available for anyone who wants to use that https://github.com/omfound/OMP-Commerce-Reservations.

Have you tried just using that?

What features does Reservations have that OMF's Drupal Commerce based reservation doesn't that RETN needs?

I hope this is a

emilyf's picture

I hope this is a misunderstanding on what RETN has contributed, because it certainly is not just "taking code other groups publish publicly and making videos about the features your organization has built using that code combined with other code other users don't have access to."

To help clear that up, here is a partial and summarized list of some patches/contributions RETN has contributed on drupal.org that share new features and improvements/bug fixes with the community:

  • Functionality of auto checkin/out for Reservations 2
  • Integration with field mapping for Telvue Push
  • Extensive work to Media Cloudcast
  • Patch to Feeds: MediaRSS to include title, description, keywords, and categories
  • Cue Builder, cue field popcorn js, and media youtube popcornjs modules for chapter integration with youtube
  • Numerous patches to CM Airing and Reservations 1&2, as well as documentation and attempts to help identify current issues in the queue
  • Patches, screencast tutorials and documentation to a wide variety of other modules

These do not require a station to hire me as a developer to implement any more than the code you contribute requires stations to hire you.

I've been a member of this Drupal group since it first started and was called PEGspace, and I believe the founding goal of the group has not changed. That goal was to be an open forum for positive discussion, communication, and collaboration in Community Media in Drupal. Constructive criticism is certainly beneficial as long as it remains constructive. I would really hope everyone in this group shares that goal and supports/recognizes different levels and types of contributions.

It also surprises me to see such harsh comments about the delayed release of a module (which is being delayed because of a critical bug as elaborated on in the relevant post - it will be released soon). MNN modules posted at https://groups.drupal.org/node/416168 were very delayed. It's fantastic those finally came out in some capacity, and it seems people are understanding of the delay. RETN deserves the same treatment and understanding. Ongoing development across multiple projects at one time is something I think we are all familiar with, so I don't see why RETN "shouldn't" be working on multiple things at once just like MNN, cA, and others are.

I hope this is just a misunderstanding as there is a lot of collaboration and work to be done to help Community Media Centers and their online goals. I also hope we can move things forward together when opportunities to collaborate driven by CMC's are present.

If you do have other constructive comments or questions about RETN, me, or our contributions it would be good to start a different thread dedicated to that so that CMC's can further discuss the reservations form here. Thanks for your suggestions directly related to other options on that topic, those suggestions can definitely help spark more discussion.

The original "pegspace"

kreynen's picture

The original "pegspace" project wasn't adopted by any organization other than MNN for many reasons, but everyone involved has to acknowledge that one big reason was that the code was never released as installable, reusable modules other people could contribute to. I was given a demo from @ericG during a screensharing sessions and a code/database dump with most of MNN's configuration removed, but it wasn't something I could actually work with.

No one can build on or improve code they only know exists from seeing it in a video. That approach didn't work for pegspace and it doesn't work 7 years later.

As anyone working for MNN will tell you, I'm not going to be nice about ignoring/deprioritizing the responsibility organizations have to share improvements they make to this project. If I didn't bring it up in every conversation with MNN and Open Flows, getting the code posted as sandboxes probably still wouldn't have happened... and @libkuman can confirm that I haven't let up just because he got the sandboxes posted. At CiviCon we worked together to start the application review process for CM Project Picker... because to really be useful to other organizations, modules need downloadable, version stamped releases.

For an open collaboration to succeed, any developer working for any community media group needs to be able to find the modules that enable the features their organization wants on Drupal.org, download those modules, and install them... but once they done that, the developer needs to be encouraged to share any improvements that could benefit another organization. We proved that works with https://www.arlingtonmedia.org/ (though someone from the staff at that station eventually needs to get involved).

When I first started working with community media groups, PEGEvent was the only community media specific module shared on Drupal.org. While there were dozens of people with the skills to write PHP and CSS building Drupal sites for community media groups, code just wasn't being written or shared in "the Drupal way".

It has taken a long time to get to the point where we have this many people who understand how code is shared and issues are managed on Drupal.org, but if you consider pointing out where things aren't working they way they should "being harsh", then I'm going to continue to be harsh.

You mention Cue Builder. Googling that points to this module which is only provides a link that doesn't exist. I can find Cue Field PopcornJS, but it has no releases. Neither does Media YouTube PopcornJS.

The constructive criticism is that you've been using Drupal to build sites for more than 7 years. That wouldn't have been possible if other developers shared code the way you share it. You use Drupal.org enough to know what module project pages are supposed to look like. All of the information on how to maintain modules is available and there is plenty of support if you ask for help, but you need to make that a priority and/or the organizations you work for need to make that your priority.

Many of the contributions you list are improvements or updates to code I originally wrote. I hope you can see that you are really making my point for me. You can improve that because the organizations I work for to prioritize making the code public so it CAN be improved. RETN didn't force you to commit the TV Schedule as a module and then use the published module on their site, so you didn't and months later no one else has access to it.

Correcting that is really all the MoU was designed to do.

By signing the agreement, organizations force themselves to prioritize open collaboration while investing in improvements. RETN does most of what the other MoUs groups are doing with the exception of...

  • sharing code/improvements from any contractor they hire before they are "done"
  • using the same shared code all organizations have access to
  • investing staff time supporting other station's adoption of improvements
  • making improvements in ways that keeps the code compatible with how the other MoU organizations are using it

If you have a critical error in the TV Schedule Code, why not post the code and the error and let the other developers interested in using the code help figure it out?

What are the relevant posts about this critical error you are referring to?

How is this code running on RETN and Battleboro if it has a critical error?

one of my biggest lessons from this all

ericG's picture

this was one of the most important lessons I learned from the 8 years of attempted collaboration on PEG related Drupal code.

do not wait until it is right or done, release it now. do not worry about those rough edges, release it now. do not fear that people will think you took hackish shortcuts, release it now.

Had we followed that suggestion, the collaboration would have been better and stronger. Had we followed that suggestion, by the time we were able to handle merging MNN's code with the other station's systems, it would have been easier. And most importantly, we would have been able to keep some of what I felt were the best parts of our data structure instead of having to give that up in order to merge with everyone else -- because that better design would have been shared by the others involved.

Community Media

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week