The document discusses strategies for handling complexity when building complex websites with Joomla. It begins by defining what makes a site complex, such as migrations, complex content structures, or integrations. It then provides tips for managing complexity, including taking time to understand the customer's needs, structuring projects in phases, thoroughly analyzing and designing the site, handling complex content structures, using a robust architecture, developing migration tools, and planning for scalability. The overall message is that complex sites require planning, breaking work into manageable pieces, clear communication, and flexibility.

1. building complex sites with Joomla* j and beyond 2010 paul delbar, delius * and how not to get hurt doing it

2. objectives share experiences about handling complexity how to do this with joomla warning ! most of this presentation is not joomla-specific

3. what do we mean by a complex site ?

4. projects that tend to be complex migrations from other CMSs sites with complex content structures strongly typed or interrelated content online applications or platforms sites with an extensive functional element integrations with other (non-site) systems anything with vague requirements insufficiently clear and/or under constricted timelines building things you have never built before

5. customer issues that make it complex lack of skills low process maturity unrealistic expectations very complex requirements poor communication and coordination budget issues timeline issues lack of a strategic perspective

6. example : simplantacademy.org original project someone’s first Joomla site late and over budget (really) badly coded ‘can you fix this ?’ customer had bad experience little technical knowledge an unclear process

7. example : avrr.belgium.iom.int 25th anniversary of REAB academic session, press, … discussed in March started September customer had 5 weeks until the event had no content available runs web projects like any enterprise IT project joint project with

8. in general, areas of complexity are related to the technical architecture chosen how visitors wil experience the site visual design and user experience content and data to publish on the site features and functional elements other software solutions to integrate operational parameters (speed, size, …) the process driving changes to the site architecture navigation visuals content functionality integration operations process

9. how to handle complexity

10. 1. take the red pill

11. 2. get to know your customer

12. invest in effective communication to understand your customer, you should listen, listen, listen observe and learn about their way of doing business create a relationship based on mutual respect enabling open and factual discussions focused on your customer’s success

13. ways to mess this up start the relationship by talking about yourself make sure you demo at least three large sites make technology the centerpiece of your offer avoid discussions about budgets and timeline ignore what happens after the site is live do not challenge the customer’s requirements assume content will be available on time

14. the sales phase : foundation for success or … establish the correct sequence of events document and communicate your sales strategy my favorite quote structure background environment variables problem definition what the customer needs solution principle how you will fix it statement of work what you will do to get there estimate summary what efforts it will take financial offer what it will cost general conditions how you will do business

15. develop a long-term plan

16. 3. structure the project

17. avoid heroic project targets avoid big bang projects use prototypes, pilots, phased rollouts don’t be afraid to split the budget over phases be clear on go/nogo milestones cleanup jobs : fix one issue at a time chances are you’ll discover more problems as you go don’t kill the patient in surgery do not let budget and time constraints rush you walk away from the deal if you need to

18. help the customer understand how you work define each project phase analysis design implementation rollout maintenance by an explicit definition of phase objectives and end conditions deliverables

19. example of a methodology summary this approach agrees very well with Joomla

20. example of a quote

21. 4. take your time to analyze and design

22. the purpose of analysis to understand what the customer wants develop a common terminology not: teach them about components and modules break this into content, function, visual, navigation, … explain the process you propose to follow make progress visible : document what you learn use sketches, flipcharts, documents, … share results and actively request feedback

23. the purpose of design to describe what you will build must be some form of documentation should cover all elements of the stack try not to loose the customer in translation ensure they feel comfortable sharing that you lost them

24. analysis and design : navigation discuss the intended target audience translate this into a mindmap evolve into menu items for each tpe of visitor

25. analysis and design : navigation complete the navigation design (Excel sheet) build a ‘menu mockup’ will serve as an initial version once you start building

26. analysis and design : visual wireframes work well with Joomla very clear separation into components and modules our favorite: WireframeSketcher (Eclipse plugin) prepare work sessions with customers first, establish sample menu/component layouts print empty pages and sketch or cut/paste modules

27. analysis and design : visual

28. analysis and design : content discuss and document a conceptual content model and here’s where Joomla doesn’t really shine ...

29. 5. content: a matter of semantics

30. example: 11.be consortium of non-profits working in the south original site mambo 4.5.3 heavily hacked core objective upgrade to 1.5 migrate content add functionality

31. example: 11.be initial analysis: 3 weeks reviewing current site : what is being displayed review database structure : how is it stored conclusion everything is an article, a category or a section countries are categories articles (real) are articles (j) articles can describe multiple countries com_content was hacked to link articles to multiple categories

32. … and everything becomes an article !

33. translating the semantic content structure approach #1 : flatten into com_content approach #2: build your own component approach #3 : use a CCK extension approach #4: use one|content

34. do not make everything an article

35. 6. architecture : use a strong foundation

36. example : ngo-openboek.be

37. example : ngo-openboek.be three separate building blocks crisp interface definitions find a balance between does this make the project more complex ? does this make future modifications easier ? live public information data entry application data cube graph/grid API

38. architecture matters encapsulate and interface use tried & tested design patterns

39. 6. migrating: build the right tools

40. example: broederlijkdelen.be belgian nonprofit original site old-style CMS provider bankrupted here’s the data dump we’ll get another one just before go-live can you start building ? now ?

41. tools make your life so much easier migration tools script the entire conversion improve as you discover errors allows you to keep the live site running and update content just before go-live

42. 7. start small but plan to grow tall

43. example : biketowork.be

44. example : biketowork.be J1.5 integrated with SugarCRM (one|content) uses standard SugarCRM SOAP-interface for updates lots of personalized, real-time content (no caching) originally (NOV08) targeted at 500-1000 users currently 7000+ users and climbing fast 2000 visits/day in a short time window

45. how you can achieve scalability decouple components and (sub)systems makes it easier to replace/rescale a single element helps to encapsulate low-level caching strategies refactor often (evolution) monitor performance, fix the bottleneck, repeat be ready for a step change (revolution) sometimes, it just gets too big be prepared to question the initial architecture in this case, dump SugarCRM

46. good luck ! questions can be submitted at your own risk

47. and on a lighter note … http://www.youtube.com/watch?v=XgoKh-QbOMQ