Skip to content

Roadmap

Jump to bottom Edit New page
peakpg edited this page Dec 6, 2013 · 75 revisions

Here is a look at what is being planned for the future releases of BrowserCMS.

v4.0

  • UI Redesign/Simplification - Streamline the UI to make it more efficient (for users) and more moddable (for developers). This may involve using a CSS framework like Twitter Bootstrap as the underlying foundation.
  • ✓ -- Stage 1 - Add bootstrap based global and content sensitive buttons
  • ✓ -- Stage 2 - Rework the rest of the UI to use bootstrap based layout.
  • -- Stage 3 - Add better core theme design.
  • ✓ Improve Content API - Make blocks behave more consistently with ActiveRecord. (Principle of Least Surprise).
  • ✓ [#566] Improved In-context editing - Improve the efficiency of content editing
  • ✓ Addressable Content Blocks - [#588] Content blocks can be defined so they can be added directly to the sitemap. This should should reduce the custom code required for creating portlets on projects.
  • ✓ Rails 4 Upgrade - Ensure the CMS is compatible and works with Rails 4.x
  • ✓ Migration Cleanup - Remove pre-4.0 migrations
  • ✓ -- Enforce table prefixes - Ensure all CMS tables use cms_ regardless of whether they are in a rails app or not. Configurability adds complexity and bugs for no value.
  • ✓ Form Builder - Allow users to create their own forms to collect information via the website. Avoid requiring users needing to place fields, but generate them dynamically. This would allow the UI to be simplified.
  • ✓ -- Streamlined Forms - Replace the existing custom form UI with some like SimpleForm/Formtastic, to allow for more dynamic creation of blocks/UI elements.
  • ✓ [#619] Descriptions for portlets so user can tell why/when they should be using them. (Problem comes up with site with lot of portlets)
  • ✓ [#621] Remove need to register Content Types - Just defining the class is sufficient now.
  • Sitemap Optimization - Differ loading pages/sections/etc using AJAX. Avoid slow load time for large sites.
  • Asset Precompilation - Improve the speed of precompilation of assets for BrowserCMS projects (i.e. interim files, ensure assets compile, etc)
  • Custom Content Routes - Enable/Document how to easily create custom routes for content types (i.e. /news/:year/:month/:day/:slug). Both for creating modules (like BcmsNews) as well as extending existing modules. Can be done with very crude (could be tighter) routing code like:
# events/detail is page path
# Portlet on that page looks up by :event_id param.
# Clients can call events_path(event) to RESTfully link to this route.
get "/events/:event_id" => "cms/content#show", defaults: { path: 'events/detail' }, as: :events
  • Scheduling Content - Allow content to be scheduled for publishing and removal (archving)
  • Content Type Descriptions - Same as for portlets.
  • Improve Documentation
  • -- Update everything for 4.0
  • -- Create a single configuration guide (equivalent to http://guides.rubyonrails.org/configuring.html)
  • Built in CAS server - CMS should have a built in CAS server, that allows the login page to be styled using the CMS templates.
  • -- Other Protocols - Review other protocols (oAuth,etc) to determine if we should support them for authentication as well.
  • -- See http://stackoverflow.com/questions/549/the-definitive-guide-to-form-based-website-authentication
  • Open APIs - Provide standard JSON APIs for content with minimal configuration.
  • Global Configuration Store - Provide UI based key/value store (scoped by module)
  • Light Theming - Organize theming for specific project (central directory)
  • -- Prove easier hooks for developers to modify CSS via UI (along with partials and assets)
  • Better Authentication API - Current architecture is very hard to plugin, make adding CAS, Basic HTTP Auth or other external databases require the use of brittle monkey patching.
  • External User - Add a concept of 'External User' that can represent a user that was authenticated from an external datasource. These users would need some information stored either temporarily (session) or more permanently (database)
  • [Content Importing](Content Importing) - Allow for easy importing of content as text files (rather than migrations). Make setting up pages needed for a 'feature' easier than manually righting pseudomigrations (i.e. seed data)
  • -- Could use markdown format.
    • Update to use a solution like Devise that would provide solutions like:
  • -- Email password
  • -- Better integration into Rails projects.
  • Configurable Tables- More flexible table grid for content.
    • Users or developers should be configure which columns are present without needing to redeploy.
  • Taxonomy - Evaluate what it would take to build an enhanced Taxonomy feature.
  • Improved Security - Reduce chance of vulnerability by restricting/removing ERB templates via UI.
  • Infinite paging (for content library)
  • Testing Support - Provide factories and/or Cucumber DSL for testing with CMS projects. Projects require a lot of set up code to get working, so its hard to test.
  • Better Templating through UI - Improve the experience of developing templates through the UI (i.e. versioning, an editor,etc). [Lower Priority - We may de-emphasize template management in future releases since it makes it hard to manage content across environments]
  • Project Profiles - Make it easier to set up a standard 'build' profile of the CMS which would preconfigure a set of modules for projects.

Backlog

  • Multisite Capability - Allow a single CMS to serve content for multiple top level domains.
  • Search - Make a nav based search to allow users to find relevant content types.
  • Notifications - Provide editors essential notifications as in the toolbar (Low Priority)

General UI Observations

  • Nobody adds content besides portlets and text (Html) to pages. Images maybe, but even then its minor.
  • End 'Reuse Content'. Sharing content could be done less complexly and consistently (like how portlets reuse content)
  • A single page per block could work. Eliminate single block portlets and page routes.
  • Show where blocks are used (if shared) when eddting them. (i.e. indicate to editors that a block is used on multiple pages)

New/Improved Modules

  • News - Member Protected news
  • Sitemap - Show custom content (events, news) in sitemap

1. Custom Authentication

Spree folks have been doing work here: http://ryanbigg.com/spree-guides/authentication.html

2. Other Ideas

3. Module Improvements

  • Better seed data handling
  • Page Routes as Controllers (less DB tediousness)
  • allow :guest, :only => [:action_name]
  • Standard model security (exmaple: Blog module requires custom work)
  • Standards custom templates (Blog module requires custom work)
  • Standardize testing framework
Add a custom footer
Add a custom sidebar
Clone this wiki locally