We recently posted a proposal for a speaker feedback tool to be baked into WordCamp sites. The proposal included some ideas and mockups, with a call for feedback, suggestions and questions. Thanks to @adityakane, @imath, @andreamiddleton, @hlashbrooke, @karmatosed, @iandunn, @mrwweb, @dimensionmedia, @samsuresh and @wpfangirl for their input on that post.
Based on the feedback from that post, we have some more refined mockups to share with you, courtesy of @karmatosed. In addition to that, we are looking for input on the data storage method here, so check out the mockups and details below.
Front-end views
Initial view before selecting a talk to give feedback on:
Full form view after selecting a talk:
Dashboard views
The following mockups are based on the idea that we would store the feedback in a new custom post type with each feedback item being a separate post in that type.
List table view of feedback items in the dashboard:
Single view of the feedback post in the dashboard:
Considerations
The main decision that needs to be made at this stage is regarding how the feedback data will be stored. The three options are:
#1 Custom post type
This would appear as shown in the mockups above. Feedback would be stored in individual posts within a new custom post type.
Pros:
- Uses existing WordPress APIs, so no need for custom data structures
- Easy to extend with further features at a later date
- Familiar UI
Cons:
- Some WordCamp sites could get thousands of feedback items for a single event, this could slow everything down and make for a very tedious UI to look through for feedback items.
- Individual feedback items would require a click through to a new page in order to view them
#2 Comments
This would involve storing the feedback as comments on the session post using a custom comment type and comment meta.
Pros:
- Uses existing WordPress APIs, so no need for custom data structures
- Easy to extend with further features at a later date
- Familiar UI (this would use the
edit-comments.phptemplate in the dashboard - Dashboard comments view allows for full feedback content to be viewed in the list table, without a new page load
- Feedback is effectively a comment, so this would be a logical way of storing the data
Cons:
- Custom comment types and comment meta have historically been tricky to work with (although I think this has been largely fixed in recent Core releases)
#3 Custom database table
This would involve writing a custom data structure in custom database tables – the exact data structure and dashboard UI would still need to be planned out.
Pros:
- Flexibility of building things exactly how we want it, in the most performant way possible
- UI can be as optimised as possible
Cons:
- Lots of development hours for planning and building
- Dashboard UI would likely be unfamiliar and less predictable
- Custom database tables on a large multisite instance can be unpredictable
Questions and Feedback
With all of that in mind, please comment with your thoughts on the following:
- Which data structure do you think would be a good fit for session feedback?
- Is there anything further that you feel should be included in the feedback form for attendees?