Skip to content

Roadmap

Jump to bottom Edit New page
peakpg edited this page Jul 11, 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).
  • -- @block.save should return false if validation fails so if @block.save logic works.
  • ✓ Improved In-context editing - Improve the efficiency of content editing (Done - #566)
  • ✓ 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
  • 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.
  • 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)
  • Descriptions for portlets so user can tell why/when they should be using them. (Problem comes up with site with lot of portlets)
  • Improve Documentation
  • -- Update everything for 4.0
  • -- Create a single configuration guide (equivalent to http://guides.rubyonrails.org/configuring.html)
  • Remove need to register Content Types - It may be possible to have Rails dynamically load these, rather than needing to register them in the database.
  • 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)
    • 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.
  • Streamlined Forms - Replace the existing custom form UI with some like SimpleForm/Formtastic, to allow for more dynamic creation of blocks/UI elements.
  • **Forms Module **- Allow users to dynamically create their own forms through the UI. Avoid requiring users needing to place fields, but generate them dynamically. This would allow the UI to be simplified.
  • Improved Security - Reduce chance of vulnerability by restricting/removing ERB templates via UI.
  • 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.
  • 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.

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