This roadmap defines the planned functionality and features of the Joind.in core code for future updates of the site. It is not in order, although “Upcoming Changes” are things we can imagine doing within about a year, and “Distant Future Changes” are just that, things that have many dependencies, involve a lot of change, or otherwise aren’t happening soon.
Allowing subdomains of joind.in to be branded as “mini sites” for individual events. This means flexible templating to support simple skin changes, with a CSS file and logo that can be changed to match event branding – and at the other end of the scale the option to replace templates if required to affect layout, using partial views.
Easy way for event admins to pull out all the data on their event. This includes talks, event comments, all the talk comments, and any voting. Probably this will be available via a series of links (one for each data set) in the event admin area.
Something you can feed a talk id into and drop into a page, to have it provide:
Session voting has been removed and needs implementing as an independent module. For sessions where voting is allowed, the talks will show up and down indicators and how many of each have been received, as well as the overall score. The voting can be closed (visible but no further votes allowed) or removed at any point. Bear in mind that we might want to vote on CfP submissions at a later date! We might want to ask whether up/down is the right kind of voting or if we might also want postive-only or even numbered scores, although that could be distinctly overkill to have all of them.
A bookmarkable page, per event, designed to be used while the event is on to show what is on now and in which track, and what is on next, and in which track. The iphone app already has this feature, but it would be nice to make it available generally.
A first step towards a customised timetable, allow users to mark sessions they are interested in, and display these as highlighted on the event screen, on the talks list, on the now/next view if there is one, and return this information over the API as a talk property for logged-in users.
In the next year the updated version of the CodeIgniter framework will be released. This update has some larger changes that will have to be considered in how the site currently functions. Changes will need to be made to accommodate this update with an emphasis on moving more towards features available in more current versions of PHP (including updates made in PHP 5.3).
Similar to twitter which has “from Spaz” or “from web” we could add information about where a comment came from. Since we have mostly the website and things which use the API, we could have API keys to be more specific about what was consuming the API, if those consumers wish.
Add wiki pages for “howto” things. The interface, especially on the admin side of things, is tricky. Screenshots and lots of help needed :)
A future API version will support OAuth for all calls which require authentication (much of the API is public so doesn’t need auth). At the same time we’ll introduce API keys (implied by consumer keys in OAuth). An important consideration is the use that the site makes of the API and how to handle auth for that.
Handle a call for papers process, speakers enter talks and just tick which ones they want to submit to the event, keeping their bio/photo/abstracts all in one place to reuse.
Print/output a timetable of the event, with favourite sessions marked
The current API has no error handling, slightly interesting security, and frightening output handling. The aim is to get the API stable and tested, and then replace it. Pagination for potentially large result sets would be a nice addition
Last edited by enygma,