A presentation to the BBC Product Management community, introducing the concepts, processes and techniques of Domain Driven Design, including Domain Modelling and URL design. Also talks briefly about the Semantic W
33. - INVESTIGATE AND UNDERSTAND THE DOMAIN OF YOUR PRODUCT
- A COMMON LANGUAGE BETWEEN USERS,
DEVELOPERS, DESIGNERS, PRODUCT MANAGERS
- A DOMAIN MODEL SHOWS YOU THE MOST
IMPORTANT THINGS, AND HOW THEY’RE CONNECTED
- EVERYTHING SHOULD FLOW FROM THE MODEL -
DATASTORE, DESIGNS, URL SCHEMAS
- ONE URL PER THING - MUST BE PERMANENT,
NICE IF IT’S READABLE & HACKABLE
- SEARCH ENGINES ARE YOUR LEAST ABLE USER -
DESIGN FOR THEM & ACCESSIBILITY WILL RESULT
- DESIGN FOR THE WEB FIRST, THEN MAKE APPROPRIATE
REPRESENTATIONS FOR EACH PLATFORM
IN SUMMARY, THEN...
34. “HOW WE MAKE WEBSITES”
HTTP://WWW.BBC.CO.UK/BLOGS/RADIOLABS/2009/01/HOW_WE_MAKE_WEBSITES.SHTML
“DESIGNING FOR YOUR LEAST ABLE USER”
HTTP://WWW.BBC.CO.UK/BLOGS/RADIOLABS/2009/03/DESIGNING_FOR_YOUR_LEAST_ABLE.SHTML
IF YOU READ TWO THINGS AFTER THIS PRESENTATION, MAKE IT...
35. WHY SHOULD WE CARE ABOUT THIS?
WHAT WE’RE DOING NOW...
Hello - I’m here to talk about Domain Driven Design (and the Semantic Web) at the BBC.\n\n“Common Sense, made complicated.” not really. It’s easy.\n
- There were* approx. 320 manually managed indexes\n on the BBC Sport site\n - 150 or so in football, 22 rugby clubs, 30 cricket teams\n \n - But we are missing some important ones:\n - No competition pages (e.g. Premier League, Champions League)\n - FC Barcelona\n - Real Madrid C.F.\n - F1 teams and drivers\n \n - All would have value from an audience & business perspective.\n \n \n *= we have recently launched dynamically-aggregated football team pages\n\nI was responsible for design\nFrustrated at limitations of system\n\n\nCurrently there are too many pages to manage manually for a small editorial team 7 days a week\nWe need to drastically reduce the number of pages that are manually managed - by approximately 300\n\nThere are approx 320 manually managed ‘indexes’ - 150 or so in football, rugby teams, cricket teams and further ambitions around F1\nDifficult to integrate statistical information with editorial\nwhich is why the metadata and tagging projects are an integral part of long term strategy\n\n
The first step is to relax. Forget about the product. Forget about the website.\n\nIn a nutshell, DDD is about designing around the subject area of interest to your defined user group.\n\nAnd that’s pretty much it.\n\nWhat I’m going to talk about:\n\n- The DDD process and why it’s a good thing.\n- A couple of techniques - Domain Modelling and URL design\n- How this fits into the “One BBC, four devices” strategy\n- How this fits in to the wider Web\n\n\n
OK, so the process. It’s all about understanding how your users (and indeed, you and your development team) think about the domain.\n\nDDD involves users from the beginning and every stage throughout the process - talk to users about the domain, make notes on the words they use and use those words all the way up the stack.\n
The idea here is that by taking note of how your users refer to things, the whole development team can use the same language - al the way up and down the development stack - from database to CSS mark-up.\n\nA shared language = better communication = a better product.\n
Never stop trying to understand the domain. James - sports competitions with defined structure vs editorial defined things e.g. Premier League, Wildlife Finder (Linnaenan Taxonomy) etc vs ‘Libya in Crisis’\n\nYou’re probably not going to get it right first time. Don’t worry. Keep talking to users, keep sketching - refine your understanding.\n
Another important thing here is the balance between experts and casual users - the experts probably have a very detailed understanding of the domain - which is great, but it might not be what you want to present to the majority of the audience.\n\nGet the model right, and precise, behind the scenes, and then simplify as you go up the stack. This allows you to introduce new features easily, without huge development cost.\n\nIf you model it now, then that gives you hooks to build new functionality later - if you leave it out now, you’re accruing technical debt..\n
Forget, for a short while, that you’re building a website. Just have a chat. Get involved. Understand the subject.\n\nNote down the concepts, the nouns, the things they talk about. Those will be your primary domain objects.\n\nYou’ll probably want to bear in mind some kind of scope, of course - so work out what the most important things are.\n
After capturing the things, talk to your users about how those things are related - the verbs.\n\nThis will be important later, because it’s how we can make the product linked up in a coherent, natural way - one which fits how we make sense of the world.\n
\n
\n\n
The easy bit, your nouns. The things people will want to talk about, will search for, will link to.\n
\n
One and only one = MUST\n\nZero and One/Many = CAN\n
\n
One to One = Is it the same thing?\n\nOne to Many = the most common - sometimes you might want to elaborate with ‘one and only one’, ‘zero or one’ etc.\n\nMany to Many = Suggests there’s something in the middle missing - but not always - all depends on what you’re trying to communicate.\n
\n
This can be a bit tricky - it takes a while to get used to it, but it’s just practise:\n\nA Stadium will host one or many Matches,\nA Match will take place at one and only one Stadium.\n\nThing, verb next to it, end of the line, other thing.\n
The domain model is where you get everyone involved - a shared understanding of the model helps everyone work together to give the users want they want & need. \n
Because it’s how Google works. If you care about SEO, if you care about your audience finding stuff, you should care about URL design.\nAlso, the Web has the potential to be the platform that supports all the other platforms - the 4 screens that Ralph talks about...they can all talk to, and fetch things from, the Web. Build it once, have it everywhere..\n
What is persistent? This means that your URL for any given resource should be the same today, tomorrow, and in 5 years time. Why? If you start changing your URLs I won’t be able to find that page I really liked tomorrow, and my link to you that I’ve published on my site won’t work.\n\nWe need persistency, or our experience is broken. Readable is a delight – I like being able to read URLs. I don’t know what “all that rubbish” at the end of a URL is. Hackable improves my user experience.\n\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
We’re not alone - link to external stuff as well (which is a BBC Trust requirement..)\n\nMusic editors contribute to Wikipedia, which is then brought in to BBC, also benefits wider web.\nSimilar with Wildlife Finder, and with Olympics & world cup, we’ve added our knowledge of stadia etc. which then everyone can use as a ‘public service’.\n
\n
\n
\n
Multi-platform:\n\nMake it easier to deliver 10 products to 4 screens\n\nAs content from different products is stored in the Content Store, we will increasingly be able to deliver richer experiences to mobile, IPTV and tablet devices, as well as desktop.\n
Contextual (or horizontal) navigation around BBC content would also be made easier.\n\nAt the moment the existing static infrastructure makes it very difficult to link to other relevant content within the BBC.\n\nUsing a dynamic infrastructure will make it easier for us to link to other relevant products.\n
Technology and publishing systems\n\nBegin working with the Newsgathering and other TV production teams to work out and define how we can keep data more consistent from programme creation to broadcast/web/mobile.\n
External Suppliers\n\nStart discussions with external suppliers to use linked data and content identifiers to minimise distribution and processing costs of feeds and data.\n
