From Vancouver to Vladivostok, from rotting in-house spaghetti to - PowerPoint PPT Presentation

osce.org Press and Public Information Section • Gottfried Nindl, Graham Patterson • Version 1.0 (26.11.09) From Vancouver to Vladivostok, from rotting in-house spaghetti to Drupal Migrating osce.org http://www.osce.org

Content About the OSCE Business Case Information Architecture Software Architecture Migration Usability Testing Conclusion 2

About the OSCE 3

What is the OSCE?  World’s largest regional security organization  History: Cold War and Berlin Wall  Comprehensive approach to security  Forum for dialogue  Practical work in the field 4

Where is the OSCE? 56 participating states, 18 field missions… ...from Vancouver to Vladivostok 5

Business Case 6

Motivation  Large decentralized website  Small central webteam  Inflexible technology (CMS)  Rigid content model  Confusing information architecture  Search engine (un)optimization 7

Objectives  Multilingual capability  Better workflow  Better content organization  Improved information architecture  Flexible, community-maintained CMS  SEO 8

Open Source CMS Evaluation  4 serious candidates Drupal (PHP) Repository Plone (Python) URL structure Security Building modules Technology Building forms TYPO3 (PHP) Content types Perspective Templating Content Delivery Search Engine OpenCMS (Java) Back-end Scalability  15 criteria 9

So, why Drupal?  Pros > Best balance between core features and simplicity > Small core (footprint), numerous useful modules > Large, friendly community > Reference sites  Cons > Back end usability > No high-level Ajax support > Ancient design (no OO!) 10

Proof of Concept  Can the chosen CMS deliver?  Tasks > Front end theme => easy, by templating > Content types => hard, custom modules > Workflow => good enough > Data migration => Use APIs, e. g. node > SEO => clean URLs, taxonomies  Lessons learned > Drupal can do almost anything we can think of  > Drupal needs a roadmap > Buggy modules > Active participation in community recommended 11

Information Architecture 12

Content Model  40 sub sites & portals  22 content types  12 field types  15 vocabularies  Node queues & rules  Numerous views 13

Implementation  Sub sites & portals as tagged pages  CCK for content typing  Vocabularies as conditionals  ‘Hot content’ as node queues  Views for generic lists 14

Software Architecture 15

High Availability/Performance Cluster  Cost-effective solution  Squid proxy boosts performance  Service failover  Heartbeat monitors servers  DRDB replicates databases/files 16

Software Design Patterns  Single entry point Front Controller  Notify responsible Observer/Visitor  Action  Procedure Modules  Extension by convention Transaction Script Class Table Db Inheritance Plugins  Flexible data model  Embedded markers & scriptlets Template View 17

Used Modules (currently 38) Content: Development: CCK, Content Taxonomy, Date, Email, Filefield Filefield Paths, Imageapi, Imagecache, Devel, SimpleTest Imagefield, Link, Nodereference Explorer, Nodequeue, Phone, Quotation (custom) Workflow: User Interface: Rules, Workflow Admin Menu, FCK Editor, JQuery UI, JQuery Update, Menu Block, Lightbox2 ,Views, Misc: Taxonomy Navigation (custom) Apache Solr, Hash tokens (custom), Import/Export: i18n, Pathauto, Querypath, Subscriptions, Token Data Migration (custom), Import, Node Export, Taxonomy Export, Gateway (custom) 18

Migration 19

Approach  Three phase strategy: > Data extraction > Data mapping > Data verification  Content Audit > Spot checks to fix biggest issues  Custom import script > CCK nodes & Aliases (ca. 50,000 items) > Menus > Taxonomies > Users > Subscriptions 20

Implementation  Complex data extraction strategies (SQL)  Flag and mark items  Import module: http://drupal.org/project/import > Uses batch API (progress bar) > Hook import_stage() > Hook import_process()  OO batch factory with identity map for creating assets, references & assignments  Verify results with Simpletests: http://drupal.org/project/simpletest 21

Usability 22

Problems  Back end usability poor (especially for non-geeks)  The UI is not very scalable  Built-in widgets are very cumbersome  No high-level Ajax library  Custom implementation required (Nodereference Explorer) 23

Nodereference Explorer Context 24

Our solution: Nodereference Explorer  Project http://drupal.org/project/nodereference_explorer  Metaphor: File Explorer  Responsive dialog (overlay)  Customizable components > Theme > Displays > Filters > Preview  Demo link 25

Community  Quite small project  Start February 2009  Maintaining is time intensive  73 issues focus on functionality, hardly on design  Great community => Thank you very much!!  BUT, think about new ways of collaboration, apart from issue list … 26

Testing 27

General testing  No battle plan survives contact with the enemy – Field Marshal von Moltke  No website survives contact with its users – OSCE webteam  Beta site under construction  Internal and external testers  Formal (recorded) and informal (ad-hoc) tests  Front-end and back-end 28

Usability testing  Front end > IA (clear enough?) > Navigation (ease of use) > Findability (organizational structure vs thematic vs geographic) > Responsiveness  Back end > Need to manage transition from a simpler CMS > Are typical users (non-geeks) comfortable with the interface? > Common tasks should be quick and easy > Are steps to complete a task memorizable? > How do users react if they can’t complete a task? > What help is available? 29

Conclusion 30

Conclusion  Drupal will be a big step forward for the OSCE  Great contributions from community – thank you!  Contributing back and maintaining: Nodereference Explorer  But… feedback from testing and post-launch crucial  Questions, comments…? 31

Contact  Velimir Alic (Public Website Manager): User ID 406104  Gottfried Nindl (Web Developer): User ID 421442  Webteam: webteam@osce.org  Front End Developer needed: apply at http://employment.osce.org till December 3 rd , 2009 32