The swot analysis so far covers:
- 1) installation of both cm's
- 2) modules, plugins, core and concrete5.org
- 3) user Interface and learning curve
Further options available such as server settings and update notifications
- Only two installation stages
- Ability to install sample data
- Very welcoming installation successful screen (screenshot cr5-welcome-screen.png)
- Inline editing is comprehensive and easy. For example features like revisioning, permissions handling and most impressively design control is done in “edit mode”. This gives context to what the user is doing as they will associate these settings with this individual page.
This “one to one” relationship design is user friendly does require extensive backend knowledge or digging into the theme to be able to add items like spacing, background image, css stylesheets (screenshot inline-edit-design.png).
- Consistent way of entering content into the cms. Everything is a block and content is placed into that block and entered into the cms through the front end.
- Due to the front end capabilities I think it's fair to say it's a very simple cms to learn.
- Built in meta data, xml sitemap capabilities in core
- Individual page caching capabilities? Not just on/off
- Good video support to help get the user started with concrete5 core.
Little instructions on how to correctly fill in install form. Assumption of user knowledge
- To minimize the amount of stages to install Drupal. This could be done via a 2 column panel install which is responsive so this should work nice with mobile, tablet devices.
- Links to different Drupal distros like spark on setup?
- The choose language, verify requirements, set up database, install profile “stage” be moved onto the second page (stage) to minimize the amount of stages and therefore clicks?
- Would it make more sense for the first page to have a list of system requirements rather than the user filling in several stages worth information? If they fail the system requirements they will have to keep filling this info in until passed
- Could the language option and server setting options have a relationship? Eg, if the user selects english language to install could the default country be set to a sensible default dependant on Drupal user location statistics? Eg USA or UK. Maybe not a good idea as the server location and the language spoken could be different, but worth putting this out as an idea as a more plausible variation of this might could be spawned out of the idea.
- Could the server location drop down list have a “commonly used countries” section at the top to save the user scrolling through the list. Eg, if Drupal is installed in say five countries more than others these would be added.
- Panels has individual node caching built in so this rivals the one addressed
- To give Drupal additional frontend “edit” mode options. These options could be on a page by page or “one to one” basis. Current http://drupal.org/project/edit & http://drupal.org/project/aloha modules provides these capabilities. Adding the ability to assign a theme variant on a page by page basis would be a great addition. Currently panels has this ability through IPE editor (panels-ipe-screenshot.png) to assign a theme on a node by node basis. So possible integration between panels, edit & aloha.
- Simplicity of install
- Less stages and a nicer (graphically) interface
- http://www.concrete5.org/marketplace has a filter by skill level option. Would this be handy on drupal.org? to give users an indication of how easy it is going to be to implement that module.
- The simplicity of the learning curve. Can master this entire cms easily within a month due to minimalistic approach
Drupal does need to be concerned by how user friendly concrete5 installation process is. It's less clicks and appears graphically to be more welcoming.
I believe the popularity of system is due largely to it's front end handling of system features. I know someone who regularly uses the system and says his clients love the cms. This should be our user interface mission, to make drupal simpler for clients and users alike to master. I believe some of these queries are being addressed with drupal 8 and the spark distribution.
To break down the current 7 step installation of drupal into 3 (attached file install-stage2.png illustrates potential setup). This would result in a quicker installation with less clicks.
Stage 1 is the system requirements test. It makes no sense to have this test on anything other than the first page, given that failure of this will result in user having to re-enter first 2 stages of information again.
Stage 2 is the complete drupal configuration before installation (screenshot attached). This is by no means the completed "look" but just a potential layout.
Stage 3 could be similar to screenshot attached cr5-welcome-screen.png. From this page the user is taken to the default theme homepage.