Tnv3/platforms
Contents
framework selection criteria (non-technical summary)
- £1000 / month maintenance is due to high security requirements and framework dependent perfectionist updating. Wordpress does not publish it's security and update needs in the same way as Drupal and a new update and security attitude to match would bring maintenance down to £200 / month. This is because Wordpress will auto-install updates without cost and the framework is sufficiently static and better designed that those updates will not cause issues.
- WordPress has a more "Commercial feel" than Drupal. Drupal "feels" more underground, community. To some degree this is simply because WordPress is actually designed better and looks better. But the communities attract programmers and organisations based on that "feel". Neither actually has any significant extra cost, both are free for us.
- For the medium term, TransitionNetwork will be a 1/2 programmer team maximum. Version Control (GitHub) slows things down and is not required. Regular backups are of course.
- The current programmer, Annesley, is an expert in both frameworks.
- This is a technical and culture decision and those with understanding should be trusted to make it.
- The choice should not be made on comparison of how the different interfaces "feel".
- Both frameworks can do *anything*.
- Drupal has more pre-built functionality but is much more expensive to alter.
- Wordpress has less pre-built functionality but it is better designed and much easier to alter.
- Drupal is the favorite of Drupal programmers but dis-liked by better programmers
- There is a huge in-flux of amateur Drupal programmers in to the market who will make a very expensive mess. This has happened because PHP and the Drupal framework has become almost usable with just GUI configuration now and very little programming knowledge.
- Drupal will bite every non-expert organisation hard that tries to use it without expert programmers. about 5% of the available Drupal programmers will do a good job.
- Drupal and Wordpress are both LAMP (Linux Apache MySQL PHP) stack frameworks. They are approximately the same thing. We would not be moving to something substantially better or different here. That move will not necessarily cost more than a standard Drupal upgrade though.
- There are no good frameworks available currently.
framework selection criteria (technical)
Inclusive programming community: we should consider also the programming community we want to create and support. so, for example adopting a Java framework would exclude anyone not capable of using / learning Java. adopting LAMP stack frameworks includes everyone because it is easy.
Including less capable programmers: less capable or less knowledgeable programmers will produce in-secure, low performance code bases that cause a lot of errors and fire-fighting and code that is not flexible or future proof (no OO). a community of these can make a considerable mess. the industry is in a mess at the moment because of the extensive bad use of Drupal. we don't want to spend all our resources helping fix bad code. Programming is a technical and academic discipline. for example: the vast majority of PHP programmers do not understand OO, or systems architecture, critical to long term project health.
Programming Culture: the type of people attracted to each framework and how easy they are to work with. whether they are technology focused or goal focused. if they will want to champion the tech, contribute to the tech, conform to the way that the framework is, or try to achieve the organisational goals.
Messaging to partner organisations: Other organisations may implement the same framework as us but with less resources. Does our choice affect their choice and what is our responsibility here?
Framework architecture quality: PHP is a loosely typed, late compiled extremely error prone language. The vast majority of web requests are simply to take MySQL -> HTML which takes a relational structure and converts it in to a hierarchical one. PHP is far too flexible for this.
Programming quality: consideration of possibilities, server situations, variable types, generic and future proof naming of variables, classes, etc. Use of OO / XML / XSL. Use of DRI, Stored Procedures, Views, etc.
RAD (Rapid Application Development): availability of plugins (modules), caching levels and the effect on speed of development / bug resolution when writing custom code.
Security and updates: number of security issues per week, amount of work required to fix them.
TN developer network idea: we could cheaply and quickly produce a basic distro that includes in-built IM networking capability to connect developers up to share good practice. we would IM any new distros as they install to say hello and offer free peer-to-peer advice. this would prevent chaos before it happens and develop an Open Source community that could pay dividends in the future.
key message: With any hook based, community contributed LAMP stack is codeless, codeless, codeless! i.e. "have you tried this plugin", "there is something that we already use to do that". if we can't talk we can't prevent chaos...
availability and cost of Programmers
key feature sets we need (technical)
views-like filtering and presentation
for example, for the Resources Directory on the TN.org website.
- exposed fields
- WISIWYG filters
- entity selection across all data
- paging
- extensible
- field types
- template based presentation
CRM
- Critical system behind the scenes to handle relationships on a number of different planes - is this even more important than the web framework? We certainly need to know that whatever framework we use works brilliantly with whatever 'CRM' we use
- Transition Network to users Customer Relationshiop Management features: contacts management, targetted messaging, etc.
- National Hubs to users
- Users to Users Community Relationship Management features: proximity connections triggered by user actions, regional logic for connecting users, intellectual (taxonomies) logic for connecting users
- National Hubs to TN
- etc.
Page for documenting the available Tnv3/CRM options.
location handling
Integration with Google Maps for selecting and presenting TI locations
internationalisation
- Multiple languages and good international location critical
- National Hubs services
- option to share translate-able content with self-hosted national hub sites
- option to share translate-able functionality with self-hosted national hub sites
- option to share TN.org as translate-able national hub site with national hubs (e.g. fr.transitionnetwork.org)
